This is not a Google-wide thing… this is from Google’s Context-Aware Access product, which is configurable in Google Workspace environments. OP should direct their ire at their corporate IT or infosec team.
Some IT departments just see a “more secure” checkbox and will always check it, even if it doesn’t make sense holistically- sometimes compliance incentivises (or forces) this behaviour.
A common example is forcing intune/device enrolment for mobile devices (including ipads)- but not for the infinitely less secure laptops: because no such endpoint enforcement checkbox exists
Its a normal choice, given a checkbox on page which advertises that checking it would make your security posture more safe. The IT person is safeguarding their own job.
Other way to look at it is, the company is paying for everything, and they get to make decisions based on what suits their security needs.
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.
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.
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.
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.
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.
Well, it could als also be argued that Chrome _is_ more secure, for example because it uses app-bound encryption using Windows DPAPI system, for cookies, so that it at least tries to protect cookies from malicious applications running on the device. Firefox does not do this: https://security.stackexchange.com/questions/279629/are-cook...
If course the reverse can also be argued, for example that Firefox supports proper adblocking.
Well - it does make sense. If an organisation that contracts me has to chose between a) BYOD - but restrict downloads, etc, enforce export control, directly in the browser - I happily take that, vs getting a Windows laptop that is locked down and forced to work with that.
Using a maintained and up-to-date browser is a reasonable requirement for an IT department (should be for anyone really). Would you suggest they should be allowing IE6 just because a user might prefer it?
Of course Google is going to suggest using Chrome, if they detect that the browser might be out of date.
We don't know. The author doesn't mention how current the Firefox browser is/was.
If the organization is indeed enabling a specific check for Chrome that seems a little over the top but they're the ones supporting their users and if they want to make their life easier by only dealing with one browser that's their decision to make. It's like saying that everyone has to use Windows, or a specific line of laptops, or any other standardization to simplify the support workload.
It's not clear to me that Context-Aware Access is as configurable as you're implying. At a glance, the docs seem to suggest that Chrome is the only browser you can force standardization on, which IMO does push this towards being Google's fault.
If we are meant to believe that this is a Chrome-invasion-move, it's the least effective lever of all times. Most of the time the more plausible explanations are just the likely ones.
Chrome was created because Google felt that the IE monopoly was hindering the advancement of web standards and improved browser capabilities. I suppose you could argue that was a different Google at a different time, but at one point they did feel that browser diversity was a good thing.
CAA is one of the most powerful security features you can enable in an org. You can manage browser extensions, device password policy, encryption, configuration, cookie attestation, etc.
CAA is completely based on trust, it's not one of the most powerful security feature. It's completely voluntary reporting by the browser, and any attacker who cares can just lie without issues.
You can make Firefox pass CAA if you want. You take the Chrome "SecureConnect Reporting" (Context-Aware Access) plugin, port it to Firefox with some light changes, and you can report whatever you want to CAA.
That's not entirely true. For example, on ChromeOS CAA is hardware backed. But obviously CAA is not intended to be our entire MDM solution, an attacker in a position to spoof your entire browser can bypass some of the policies on some operating systems. Similarly, attackers in that same position can bypass TLS. An attacker who owns the kernel can bypass much of your MDM. An attacker who owns the hardware can bypass just about anything.
Unrelated to this news, but this is so rudimentary, when the correct solution instead is:
1. Make it ridiculously easy to install hardware vendor keys and register it with OS of choice. (like a standardized dialog box in UEFI and a standardized/regulated IPMI-like interface)
2. Allow for only measured boot on those devices.
3. Provided facility to verify signatures.
Do this on consumer and enterprise laptops and desktops alike and all of these weird set of conditions just go out of play and replaced by something much much simpler.
It appears website developers desperately want to return to a world where browsers actively pretend to be another browser*.
Want to check for DBSC? Enjoy not knowing whether the browser vendor decided to just roll a simple software implementation.
Nothing good comes from browser detection over feature detection anyways. It's time to do away with user-agents and other overt identifying markers, and if we're still not in a better place, aggressively start stubbing features.
* to some degree they still are. Firefox still ships with an user-agent override list for certain websites that have outdated user-agent sniffing for feature detection (and other fixes in about:compat).
And yet, claiming support for a feature doesn't tell all. Different implementations can have subtle differences. Knowing the browser and version can allow a client to survive that.
Yes, that is the price developers will have to pay. Development will be harder, but users are going to prefer somewhat broken sites over being outright refused entry.
At the end of the day user-preference is what dictates which browser is used and how it is configured. Developers will have to deal with what users choose to do on their end.
You can only patronize people for so long before they look for a way around silly restrictions. Trying to keep someone safe by putting up walls, whether the threat is real or imaginary, is pointless when it is in the user's power to trivially defeat those walls - and when extension and browser developers are going to line up to sell them demolition tools (see ad blocking).
Advice is going to go much further than roadblocks, long term.
It states something about "your organisation's security requirements", do they document what requirements cause this rejection page? Some kind if changed default perhaps?
No, this is easily the biggest flaw in CAA - there is no way to discover which policy broke your access. I have reported this to Google multiple times, even sent this directly to a Google SecEng (a well known one) to route internally. The issue persists and makes configuring CAA extremely painful and error prone.
At least you got a heads-up. Few months back GCP "Agent Studio - Build" failed compiling the code in sandbox with a vague error message. Spent weeks troubleshooting, spoke to google engineers and reps, sending code, step by steps, screenshots. No one had a clue, until I switched from Firefox to Chrome out of desperation and it worked without a hitch.
Not defending it, but given that they use the word "secure" three times in two sentences, I'm wondering if it's shown to browsers that don't support DBSC. Google has been really pushing/overselling this as a magical solution to cookie theft.
Is it possible for a non-google browser to be said to meaningfully support this given that implementing the features wouldn't necessarily accomplish anything insofar as it wouldn't let you past the google only security gate and would represent a moving target in any case.
I use Google as a secondary search and as of roughly last week it gives me a captcha every time I try to do a search. That had never been the case before.
I browse over Tor for most things and most sites give me a captcha or just simply fail to load these days. I just close the window and move on to something else.
I am seeing it a lot more lately with uBlock Origin. I've used DDG for search for a while now, but the last few times I've tried Google I got a captcha within a couple of queries if not immediately.
This is not a Google-wide thing… this is from Google’s Context-Aware Access product, which is configurable in Google Workspace environments. OP should direct their ire at their corporate IT or infosec team.
it shouldn’t be an option.
Some IT departments just see a “more secure” checkbox and will always check it, even if it doesn’t make sense holistically- sometimes compliance incentivises (or forces) this behaviour.
A common example is forcing intune/device enrolment for mobile devices (including ipads)- but not for the infinitely less secure laptops: because no such endpoint enforcement checkbox exists
Its a normal choice, given a checkbox on page which advertises that checking it would make your security posture more safe. The IT person is safeguarding their own job.
Other way to look at it is, the company is paying for everything, and they get to make decisions based on what suits their security needs.
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.
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.
Google and Microsoft shouldn’t be giving levers that bake you more into their ecosystem regardless.
Your corporate serfdom is not in question, but I disagree with that notion too.
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.
There is zero problem here guys.
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.
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.
Well, it could als also be argued that Chrome _is_ more secure, for example because it uses app-bound encryption using Windows DPAPI system, for cookies, so that it at least tries to protect cookies from malicious applications running on the device. Firefox does not do this: https://security.stackexchange.com/questions/279629/are-cook...
If course the reverse can also be argued, for example that Firefox supports proper adblocking.
Well - it does make sense. If an organisation that contracts me has to chose between a) BYOD - but restrict downloads, etc, enforce export control, directly in the browser - I happily take that, vs getting a Windows laptop that is locked down and forced to work with that.
Using a maintained and up-to-date browser is a reasonable requirement for an IT department (should be for anyone really). Would you suggest they should be allowing IE6 just because a user might prefer it?
Of course Google is going to suggest using Chrome, if they detect that the browser might be out of date.
Is the implication that Firefox is not maintained or?
The issue presented doesn’t seem to be “an up to date browser check” it seems to be a “is it latest chrome” check, which is a very different thing.
We don't know. The author doesn't mention how current the Firefox browser is/was.
If the organization is indeed enabling a specific check for Chrome that seems a little over the top but they're the ones supporting their users and if they want to make their life easier by only dealing with one browser that's their decision to make. It's like saying that everyone has to use Windows, or a specific line of laptops, or any other standardization to simplify the support workload.
> This was for a Google Workspace Business Plus account and workspace, from an up to date browser and OS.
Not a little over the top, it is anticompetitive behavior.
It's not clear to me that Context-Aware Access is as configurable as you're implying. At a glance, the docs seem to suggest that Chrome is the only browser you can force standardization on, which IMO does push this towards being Google's fault.
It's not a little over the top its an antitrust issue and clearly and obviously wrong.
No, not at all. The implication is that the organization is dictating the software that employees are to use. There's nothing unusual about this.
If we are meant to believe that this is a Chrome-invasion-move, it's the least effective lever of all times. Most of the time the more plausible explanations are just the likely ones.
you’d probably say something different if it were microsoft.
I don’t see why I should give affordances of good will to Google here.
They’re not stupid, they know that this is an effective lever to further cement full-fat chrome as the default browser for the internet.
Chrome was created because Google felt that the IE monopoly was hindering the advancement of web standards and improved browser capabilities. I suppose you could argue that was a different Google at a different time, but at one point they did feel that browser diversity was a good thing.
CAA is one of the most powerful security features you can enable in an org. You can manage browser extensions, device password policy, encryption, configuration, cookie attestation, etc.
CAA is completely based on trust, it's not one of the most powerful security feature. It's completely voluntary reporting by the browser, and any attacker who cares can just lie without issues.
You can make Firefox pass CAA if you want. You take the Chrome "SecureConnect Reporting" (Context-Aware Access) plugin, port it to Firefox with some light changes, and you can report whatever you want to CAA.
That's not entirely true. For example, on ChromeOS CAA is hardware backed. But obviously CAA is not intended to be our entire MDM solution, an attacker in a position to spoof your entire browser can bypass some of the policies on some operating systems. Similarly, attackers in that same position can bypass TLS. An attacker who owns the kernel can bypass much of your MDM. An attacker who owns the hardware can bypass just about anything.
Is it not:
https://knowledge.workspace.google.com/admin/security/create...
The Org admin can put all sorts of restrictions on who can do what based on the client device setup.
Unrelated to this news, but this is so rudimentary, when the correct solution instead is:
1. Make it ridiculously easy to install hardware vendor keys and register it with OS of choice. (like a standardized dialog box in UEFI and a standardized/regulated IPMI-like interface)
2. Allow for only measured boot on those devices.
3. Provided facility to verify signatures.
Do this on consumer and enterprise laptops and desktops alike and all of these weird set of conditions just go out of play and replaced by something much much simpler.
Why is there a policy to require “Chrome” and not a policy to require another browser, hmm?
Google offers "Managed Chrome" as a service. What would you like them to do, offer "Managed Firefox"? Should AWS offer "Managed GCP"?
I don’t think Google should also offer a product that detects “managed Chrome”
I don't think Google should also be allowed to remain in charge of Chrome at all but here we are.
Uh, why? Context Aware Access is a policy attestation service. Managed Chrome is exactly the sort of thing you'd have policies for.
Because Google is able to configure Chrome to the admin's liking.
"wow look at all these options available...to limit users to only use software provided by the same corp" you are missing the point entirely.
It appears website developers desperately want to return to a world where browsers actively pretend to be another browser*.
Want to check for DBSC? Enjoy not knowing whether the browser vendor decided to just roll a simple software implementation.
Nothing good comes from browser detection over feature detection anyways. It's time to do away with user-agents and other overt identifying markers, and if we're still not in a better place, aggressively start stubbing features.
* to some degree they still are. Firefox still ships with an user-agent override list for certain websites that have outdated user-agent sniffing for feature detection (and other fixes in about:compat).
You mean the same that gave Chrome its market share, by adopting ChromeOS features, and shipping Electron apps?
And yet, claiming support for a feature doesn't tell all. Different implementations can have subtle differences. Knowing the browser and version can allow a client to survive that.
Yes, that is the price developers will have to pay. Development will be harder, but users are going to prefer somewhat broken sites over being outright refused entry.
At the end of the day user-preference is what dictates which browser is used and how it is configured. Developers will have to deal with what users choose to do on their end.
You can only patronize people for so long before they look for a way around silly restrictions. Trying to keep someone safe by putting up walls, whether the threat is real or imaginary, is pointless when it is in the user's power to trivially defeat those walls - and when extension and browser developers are going to line up to sell them demolition tools (see ad blocking).
Advice is going to go much further than roadblocks, long term.
It states something about "your organisation's security requirements", do they document what requirements cause this rejection page? Some kind if changed default perhaps?
No, this is easily the biggest flaw in CAA - there is no way to discover which policy broke your access. I have reported this to Google multiple times, even sent this directly to a Google SecEng (a well known one) to route internally. The issue persists and makes configuring CAA extremely painful and error prone.
Maybe not, but I have the feeling Google doesn't like that FF continues to support manifest v2.
I think it's just that some of the device policy restrictions the Org admin can choose to enable don't work in FF. So if they require them, no FF.
At least you got a heads-up. Few months back GCP "Agent Studio - Build" failed compiling the code in sandbox with a vague error message. Spent weeks troubleshooting, spoke to google engineers and reps, sending code, step by steps, screenshots. No one had a clue, until I switched from Firefox to Chrome out of desperation and it worked without a hitch.
I know Google finally kicked all their employees off alternate browsers but doing it for external customers is definitely a choice
I'm not so sure that enforcing an internal digital monoculture is a productive way to achieve innovation & resilience.
Not defending it, but given that they use the word "secure" three times in two sentences, I'm wondering if it's shown to browsers that don't support DBSC. Google has been really pushing/overselling this as a magical solution to cookie theft.
I was thinking it could be a Context-Aware Access thing. Firefox doesn’t support Endpoint Verification plugin
Is it possible for a non-google browser to be said to meaningfully support this given that implementing the features wouldn't necessarily accomplish anything insofar as it wouldn't let you past the google only security gate and would represent a moving target in any case.
Seems like a monopolistic move.
Google doesn’t have a monopoly in workspace applications.
You don't have to have a monopoly to be monopolistic.
The Sherman Act says that any action by an individual, or conspiracy of a group of individuals, to "restrain trade" or seek a monopoly is illegal.
Monopolies aren't a prerequisite for antitrust action, they're the failure state when you should have acted sooner.
I doubt Microsoft would qualify as a monopoly under present-day excuses being made for Google yet here we are with Internet Explorer Part Deux.
Sounds like you have a device policy configured and you should talk to your internal IT/Security team?
Does Chromium would still work?
I use Google as a secondary search and as of roughly last week it gives me a captcha every time I try to do a search. That had never been the case before.
I browse over Tor for most things and most sites give me a captcha or just simply fail to load these days. I just close the window and move on to something else.
I am seeing it a lot more lately with uBlock Origin. I've used DDG for search for a while now, but the last few times I've tried Google I got a captcha within a couple of queries if not immediately.
For a few years now Google has given me a captcha whenever my VPN is on (Private Internet Access)
Smells anticompetitive to me
Oh look, a monopolist is making settings "more secure" by enshrining monopoly more.
And good fucking luck getting the FTC to follow monopoly law.
Do it then