> It does not tell you what browser the user is using. Websites can not block a specific browser.

This is unbelievably silly. It's like saying that Play Integrity doesn't tell you if the user is running LineageOS, so it doesn't mean that apps can block LineageOS. This is not a serious argument.

> It's about reducing the rate of those things.

Again, this is incredibly silly. There is zero evidence this will reduce the rate of those things. Extensions are very likely the most common vector for this.

And if you genuinely can't see a clear path in this proposal where website operators will say, "we can block Headless Chromium, but people are still getting their bank passwords stolen by malicious extensions, lock the extensions down too" -- then, I don't know, it must be nice to be able to somehow trust corporations that much despite the entire history of how advertisers and corporations have interacted with the web standards process.

Regardless, blocking Headless Chromium on its own is a restriction of user autonomy and a restriction of user freedom. That is still blocking me from using a specific browser. And if your argument is that scriptable browsers aren't going to be blocked, then this entire proposal is a waste of time. This proposal will affect extensions for obvious reasons, but even if it didn't it would still be a problem.

> When Linux distributions start to actually care about security yes I do see plenty.

:) Come on. Linux security is not the reason it would be blocked in these situations, user agency to run headless browsers like Headless Chromium is the reason it would be blocked.

You're trying to shift this conversation to be about security, but security is only one of four use-cases proposed, and three of them are about preventing the user from doing actions that the website owner considers harmful. This is not primarily a security proposal, it is a proposal about blocking off user capabilities that website authors would rather the user not have.

That is the reason why attestation won't be coming to Linux: because Arch Linux won't lock me out of my own system and prevent me from running software that I choose.

Of course, it does not escape my notice that you haven't provided an argument for why Linux won't be blocked, you've provided an excuse for why Linux should be blocked. What you're telling me is "yes, your device won't support attestation and you won't be able to use your bank website on that device, but that's Linux's fault. And maybe eventually Linux will support attestation in the future."

Okay, it's nice to know I'll only be locked out using the OS I prefer for an ambiguous amount of time until it caves and meets an unspecified standard of security at some unspecified point in the future. But I'm still going to be blocked from Linux. And you've moved from "this doesn't block an OS" to "it does block an OS and that's actually a good thing to do."

> Play Integrity covers both attesting to if the system is in a secure state and if the app you are running is from the play store. This proposal only has an equivalent for the former.

Luckily the former is the part I care about and is the primary part that is abused. Rooting an Android device is the part we're talking about and the part this has implications for. You started out this conversation by asking me to read the proposal. Let me extend the same request to you: please do some research on this.

Also, please don't make claims that aren't substantiated about how attestation will work. This proposal does not specify that attestation on Android wouldn't use the Play Integrity API. It is extremely likely that Google would use the same underlying system and that Android would refuse to provide attestation for apps that aren't from the Play Store.

Nothing in this proposal preempts them from doing that, there is no reason to trust you when you say that sideloaded apps will be able to pass attestation. The proposal specifically does not lay out what attestation requirements will be.

> Chrome has worked on CNAME stuff since that was written and most of it does not really matter to most people.

"Chrome works on CNAME stuff": where? The API isn't supported, what are you talking about :)

And if a nearly 20% reduction in adblocking capability doesn't matter to you, great! But don't pretend that it doesn't exist. Chrome objectively has a worse adblocking experience than Firefox. Manifest V3 will make that experience worse.

Maybe you don't care about that, which is fine for you, but "this won't affect adblocking" and "meh, what adblocking you'll have will be good enough, stop caring so much about adblocking" are very different arguments.

> It's the users who are losing privacy due to cross site tracking.

FLOC would not have stopped cross site tracking or improved user privacy. None of the proposals Google made about restricting cross site tracking needed FLOC (Firefox and Safari were able to block cross site cookies just fine without FLOC).

In addition, it's not really even accurate to say that Google is clamping down on cross site tracking; in fact First Party Sets exposes mechanisms to treat cross site cookies as if they are first party.

Chrome was last to the table on blocking common cross site tracking techniques, specifically because they refused to implement industry wide defenses until they had another user targeting solution implemented. Chrome very literally delayed user privacy improvements until they could make sure that advertisers were taken care of. They were the last browser to add those improvements because they were worried about advertisers more than users. And they immediately proposed specification changes that weakened the user protections that other browsers had already launched.