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