Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google workspace threatening to block Firefox access

tales.fromprod.com

Post reply on HN
Print view View original

61–70 of 194 posts

Re: Google workspace threatening to block Firefox access

#61

Post by inquirerGeneral »

kolinko wrote: post #44
SoftTalker wrote: post #32

Earlier quoted context omitted.

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 an…

Not a little over the top, it is anticompetitive behavior.

[dead]

Re: Google workspace threatening to block Firefox access

#62

Post by eli »

saagarjha wrote: post #56
insanitybit wrote: post #39

Earlier quoted context omitted.

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.

Re: Google workspace threatening to block Firefox access

#63

Post by insanitybit »

saagarjha wrote: post #56
insanitybit wrote: post #39

Earlier quoted context omitted.

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”

Uh, why? Context Aware Access is a policy attestation service. Managed Chrome is exactly the sort of thing you'd have policies for.

Re: Google workspace threatening to block Firefox access

#64

Post by ktm5j »

dijit wrote: post #46
ktm5j wrote: post #43

Earlier quoted context omitted.

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.

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.

Re: Google workspace threatening to block Firefox access

#65

Post by tux3 »

insanitybit wrote: post #38
dijit wrote: post #18

Earlier quoted context omitted.

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

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.

Re: Google workspace threatening to block Firefox access

#66

Post by Doohickey-d »

dijit wrote: post #18
bgc wrote: post #11

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

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.

Re: Google workspace threatening to block Firefox access

#67

Post by insanitybit »

tux3 wrote: post #65
insanitybit wrote: post #38

Earlier quoted context omitted.

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.

Re: Google workspace threatening to block Firefox access

#68

Post by sandeepkd »

dijit wrote: post #18
bgc wrote: post #11

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.

Re: Google workspace threatening to block Firefox access

#69

Post by tadfisher »

insanitybit wrote: post #67
tux3 wrote: post #65

Earlier quoted context omitted.

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 j…

Understand that, in this conversation, your use of "attacker" is referring to "end user of the hardware". Which might be part of the Chrome team's definition, or might not, but gosh it would be nice to cater to the folks who are using the dang computer.

Re: Google workspace threatening to block Firefox access

#70

Post by tux3 »

insanitybit wrote: post #67
tux3 wrote: post #65

Earlier quoted context omitted.

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 j…

I haven't dug into the native helper to see how much it checks, I can believe that ChromeOS does full remote attestation. If it's anything like Android Play Integrity, there's not a lot of flexibility without hardware exploits.

But who outside of Google is running exclusively ChromeOS? My impression from looking at the JS part is that it's mostly obfuscation, with the possible exception of ChromeOS.

I feel like the secure connect client being closed source would have been an effective deterrent 5 years ago, but these days everyone's throwing LLMs at everything. So an attack that would have taken effort doesn't present nearly as much of a barrier anymore. At least as long as there remain some platforms that don't enforce full attestation...

Post reply on HN