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.

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...

My point was that CAA's threat model is flexible based on your requirements. If your requirement is "an attacker with the ability to make arbitrary network requests from the host can not pretend to be Chrome", CAA does not work unless you have OS/Hardware support (which ChromeOS provides).

I just don't think that matters much. CAA is policy enforcement, it is not a full MDM solution, nor is it antimalware.

If it can't prove what it purports to prove, then it is not policy enforcement, because it is not anything enforcement.

But someone thinks it is, which is harmful to them on top of being an annoyance to everyone else.

That's just a misunderstanding of the threat model. It's like saying "if someone can just mitm TLS it's pointless" when that "someone" is in the position to run arbitrary code on the client. Mitigations map to specific attacker positions.

> But who outside of Google is running exclusively ChromeOS?

I think Chromebooks are pretty common in school settings

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.

We're talking about a device managed by a corporation. I have no idea what your point is.