It's their organization. They are allowed to make decisions about what software their employees use. I'm a die-hard Mozilla fan, but I don't find this unreasonable.
The problem is Google appears to label this as a security feature. I'm fine with the feature existing, but it should say something like "require Chrome" or "block Firefox" not "require a secure browser (wink wink we actually mean Chrome)"
The wording here is bad, but basically CAA supports non browser specific policy and, in some cases, browser specific policy (GSuite offers a "Managed Chrome" policy). Firefox users can leverage much of the non browser specific policy, they obviously can not be a part of the "Managed Chrome" offering.
There's no contradiction here; it's totally possible for a company to make a feature configurable so that it doesn't block their competitors but also intentionally design and market it in a way that's misleading in ways that will lead to their competitors getting blocked. When we're talking about a company as large as Google and a product with as much market share as Chrome, I don't think it's that crazy to think that things like this add up to encouraging even more hegemony, and when that happens to align perfectly with the incentives of the company making said product decisions, I also don't think it's crazy to think it's unlikely to be a coincidence.
If the argument is that Google has built a product that encourages use of Google products, of course. The question is whether that's some sort of trickery or odd or bad. "Google offers Managed Chrome as a service" hardly seems controversial to me.
Google offering managed chrome as a service is a completely sensible thing. The problem is that they are nearly a browser monopoly, and making Google Workspace work in such a way with Google Chrome feels to me like anti-competitive practices. If we didn't have one giant megacorp that did both things, it would be different.
Of course, so far the only workable model for web browsers is having a giant megacorp fund their development and maintenance. Which is a huge issue, and we will do basically nothing about it.
(Don't get me wrong. I have high hopes for Ladybird and even Servo, but they may come too late if effectively-proprietary features force most users to stick to Chrome anyways.)
I'm not sure what the alternative is. Is there will from Firefox to support a "standard browser config", at which point GSuite could add support for managed Firefox config? If you want managed Firefox, Mozilla could offer that as well (they have something but it's different enough).
The alternative that we've used for the past 100+ years is to force such companies apart. Is Google Docs allowed to offer a "managed chrome" policy? Sure. Is Google Chrome allowed to be a browser? Absolutely!
But if either side is close to a monopoly, both cannot be part of the same company, even if that means breaking an existing company up.
There's really nothing particularly wrong with the Chrome feature itself. There is a bit of a problem with the way it inherently results in browser vendor lock-in (regardless of whether it is a stated goal) with Google Workspace, which is by the same company. That's the main problem.
I may be missing something because I feel like this specific point has been reiterated a few times in this thread but I haven't seen it actually rebuked directly.
Look man, this is absolutely getting into the semantics phase. I know you're not stupid, don't treat me like I am.
Firstly, some Chrome features (like Chrome Remote Desktop) are delivered partly as extensions. This does not make them not features of Chrome. It makes them features that happen to be delivered in some part as extensions.
Doesn't matter. Let's say Endpoint Verification is not a Chrome feature. Thankfully, we don't actually need that for our argument. The crux of this argument is simple:
- Google Workspace depends on proprietary Chrome features,
- Chrome has specific proprietary features designed to support Google Workspace (and other proprietary Google offerings.)
What is the proprietary features I am referring to? Well, I'd just say "Endpoint Verification", but we can go a layer deeper. In order to implement Endpoint Verification, we need privileged, private extension APIs. These APIs are not for use with non-Google extensions, and Endpoint Verification uses enterprise.reportingPrivate.
You can disagree that it is a problem that Google Chrome and Google Workspace are developing proprietary integrations with each-other, that's your prerogative, but I'm not humoring this gaslighting attempt.
I'm not trying to treat you like you're stupid or to gaslight you. There is a "slice" of this that is absolutely a native, Chrome-only interface, but I just don't think that this is particularly exceptional. These sorts of Firefox-only APIs exist as well in order to support Mozilla's goals, and this is quite normal - you wouldn't expect every single aspect of the browser to be built in lockstep with every other browser.
For the most part, Mozilla could build out Endpoint Verification (and it supports a subset of the APIs anyways). Similarly, there could be a web proposal for device attestation APIs that are more generalized, etc, which I think would be great.
It is a security feature. In a corporate environment, you generally don't want users installing their own software. If it's a remote access thing from a personal device, you still generally want to be able to establish some kind of baseline. I don't like Chrome - not even a little bit - but I will admit that they have a pretty damn good security track record. I'd rather my remote users be on there than some crusty Firefox installation with 40 extensions. Organizations have the right to make these decisions when they are the ones that own the data. For example, when I was still in that world, we required personal phones to be encrypted to access corporate email. This was when a lot of people would still walk around with devices without a pin. People complained, but it was non-negotiable.
Literally the only reason they can argue Chrome is more secure than Firefox in that kind of setting is because they can Google can push Google Chrome profiles via Google Workspaces but they’ve never working with Mozilla to create an interop for Firefox.
When Microsoft did this with Windows, AD, and Internet Explore, it was deemed a breach of anti-trust laws. The question is whether such laws apply to Google given they don’t have a monopoly in the identity services domain.
If you’d asked me 5 years ago, I’d have said “no way”, but recent judgements with Apple and their App Store lead me to think there is still hope. Regardless of how remote that might be.
And Google would probably say the same thing Microsoft used to say back in the day. Their customers aren't asking for the ability to manage profiles in Firefox. I wouldn't doubt for a second that it's true.
Almost nobody outside of the minority of internet users fighting against chromium hegemony cares about Firefox. Firefox lost its casual users years ago. Hell, even most of those people sticking with it out of principle are doing it while gritting their teeth. It's been a subpar browser for a long time and the Mozilla organization kinda sucks.
Why would any for-profit enterprise waste their time or money on Firefox?
Note that making lock-in features like this effectively proprietary to the Chrome browser is only possible because of the fact that it's the same company making Google Workspace and Google Chrome.
I absolutely see many problems with this and you really ought to as well.
I didn't mean it would be physically impossible, which is hopefully implied, I mean, it would be de-facto impossible. Absent the perverse forces of anticompetitive behavior, browsers don't really have a good incentive to diminish the open nature of web standards by doing partnerships that bypass standards altogether. If you are not affiliated with Google and there is a healthy ecosystem of browsers, you just simply can tell them to bug off if they want some web feature you feel wouldn't be good for the health of the web. The interaction between browser vendors and certificate authorities has traditionally been a great example of how things can work out between different entities in an ecosystem, though outside Mozilla I am guessing most of the browser vendors are also CAs (but still have very little to no incentive to compromise or weaken the system.)
Meanwhile, in our current reality, both Google and Apple have or currently are shoehorning platform level attestation into the web in various different ways, something they are mostly able to do because they have so much control over multiple major ecosystems (among platforms, browsers, web services.) Mostly, even making them "standards", which would be hilarious if it wasn't literally evil. (Apple's approach to sneaking this in is innovative, in that it technically is a hardware platform attestation mechanism, but it was sold and initially implemented as a convenience feature. That and the underlying PAT technology can be used in strictly non-evil ways, like Kagi's rather clever application.)
It's a lot of words to say that I didn't mean literally impossible, but if we're going to get pedantic then a lot of words it is.
Why wouldn't money be an incentive. If businesses are willing to pay to have locked down browser access their cloud files, and the cloud file website wants to make money by charging businesses for this feature it makes sense that they may pay a browser to develop such a feature to use with their website.
I dunno, it just seems like the set of circumstances that would be needed to overcome the inherent friction in a "healthy" ecosystem is a lot more gymnastics than the current situation where the browser company with the vast majority of marketshare is the company that has conflicts of interest to fuck with the browser.
If a corporation with my data allowed access to its internal tools using any browser running any arbitrary and possibly compromised third party extensions, that's a data leak and class action lawsuit waiting to happen.
It's a paid product, they are actually allowed to do this. Google is obviously going to focus on security testing with their own browser. It's understandable that organizations want to require chrome for their employees to access their workspace in the interest of security, but it's not the default.
> It's understandable that organizations want to require chrome for their employees to access their workspace in the interest of security, but it's not the default.
Can you elaborate on why you think that Firefox is inherently insecure in some way for accessing Google workspaces?
> It's a paid product, they are actually allowed to do this.
If that were the only metric, then no monopoly would ever be broken up for any reason (which I guess is the way regulation seems to work nowadays, but at least in theory it's supposed to be possible for it to happen sometimes). The idea that using market pressure from one product a company sells to squeeze out competition in another is totally fine as long as the first product is paid is not a premise I agree with.
> Can you elaborate on why you think that Firefox is inherently insecure in some way for accessing Google workspaces?
Allowing users running who knows what version of Firefox (or any "non-validated"/unmanaged browser, not necessarily just Firefox) browser running who knows what extensions can be pretty unsafe. There are lots of malicious extensions out there that are stupid simple to install.
In the Workspace world, Chrome can be configured and enforced to have certain kinds of settings applied. Only allowing certain extensions. Ensure certain version ranges. That sort of thing.
It can, along with a bunch of other GPOs in an admx template.
But how many companies are running Workspace + Windows with on-prem AD? I suspect that number is shrinking pretty rapidly. You can do it with InTune as well, but it starts to get real messy if your users aren't on Windows or you have non-windows endpoints.
If you're a mac shop, on google workspace, and using something like JamF (or even Intune+EntraID), you are stuck deploying .plist files to each endpoint, you don't get compliance reporting back, and you lose a ton of visibility.
These are all things that don't matter to each individual user, but are hugely important to IT/security in the company, and Firefox unfortunately just doesn't have any centralized management platform for it.
Sure. But there's generally no standardized function ensuring they're actually only using that specifically configured browser when logging in. What happens when they try to log in from some other device? What happens when they manage to load a browser on to that machine?
This feature supposedly ensures (or at least pushes users to) only the approved browsers running approved configurations are allowed to log in to the company's instances of Workspace.
What if a company decides that their preferred browser is Firefox. Can you use this feature to only enable logins from Firefox? Or is it only for Chrome?
They can't use this feature to enforce only Firefox. Firefox doesn't have support for this feature, they really don't offer anything like Chrome Enterprise. Its just as much a feature of Chrome Enterprise that Workspace leverages rather than only a feature of Workspace that leverages Chrome.
You can still use Firefox with Workspace though, but if you want the management features of Chrome Enterprise you need to use Chrome Enterprise. Firefox itself just doesn't even begin to offer the same kind of endpoint verification.
With Firefox today, how would a web app have any serious clue the client was running approved versions of Firefox configured in approved ways on approved hardware with approved OS configurations? It wouldn't, and I take it Firefox wouldn't bother implementing that kind of technology. Which is fine, but if the customer wants to be able to ensure a certain kind of policy compliance that's just not possible when using Firefox. And that's just as much if not more of the ball being in Firefox's court as it is Google Workspace's. There's nothing for Workspace to even interface with at all from the Firefox side to ensure policy compliance.
Its like asking "can I print on this printer with this app?" when the app itself doesn't even have a concept of printing things. The basic underlying feature set just doesn't even exist, before we're even talking about some form of platform compatibility.
I don’t think anyone is saying Firefox is inherently bad. What I’m reading, and what I believe, is Google just has a better product for secure enterprise browsing because of the controls they offer
The browser is where basically all your work happens, especially as a Workspace customer—think about how much of your work is done in the browser. That makes it a huge, attractive attack surface. And attackers don't even need a browser vulnerability; they can just convince an employee to install a malicious browser extension, and suddenly they can steal passwords, watch everything you do, and hijack your sessions on other sites.
So security teams need visibility into what's happening in the browser. Google does a decent—not great—job of providing this through Managed Chrome: centralized logs, control over which extensions can be installed, even alerts when someone reuses their Workspace password elsewhere.
Firefox, Safari, and most others don't offer these business controls, which means a security team allowing them is flying blind. And a blind security team is gonna have a bad time… mmmkay.
On support: someone mentioned using Firefox to verify their app works across browsers—god's work, truly. But not every vendor does that, so IT ends up fielding "this site just isn't working" tickets that turn out to be browser compatibility issues. Fewer supported browsers means a smaller surface to support and a better experience all around.
This can't be enforced where you're not using your corporate identity. A Dropbox account on your personal email is still accessible from any browser.
I would say it's common to find dark patterns that involves ambiguity like the discussion we are having here. We can't know for sure but Google can increase the probability of being on their ecosystem.
