>Conflating serverside generated code to native app restrictions is nonsensical, they are not the same thing > You did it first. Attestation has nothing to do with extentions.

First of all, extensions are not serverside code, so... no, that doesn't make any sense. Second of all, attestation has a lot to do with extensions because extensions are based on browser functionality, and attestation impacts which software you can run. In this case, attestation means websites can check to see if you're running modified or forked browsers that might allow for broader extension APIs.

And attestation has even more to do with extensions when extended to websites than it normally would because if the point of this is to established "trusted" environments, then arbitrary extension access to a web page means the environment is not trusted. If you allow arbitrary extension access, you can't provide guarantees about whether someone is human or not -- extension APIs allow for automation and scraping and ad fraud. And blocking that behavior is explicitly one of the use-cases listed in this proposal for the integrity API.

If this doesn't block extensions, then it's not a useful proposal for blocking bots. Quite literally every single use-case that this proposal lists are impossible if extensions are not restricted. Blocking ad fraud, blocking bots, blocking malware from a banking site, and blocking cheating in web games -- all of that requires blocking extensions. A "trusted environment" the way the proposal describes it can not have arbitrary extension access because extensions can do all of that stuff; from posting automated content to fraudulently clicking on ads to cheating at online games to stealing your bank password.

> With attestation doesn't reveal what OS you are using, so it owned still be impossible to reliably block Linux.

Do you genuinely think that an Open Linux environment is going to support attestation? We're having a hard enough time getting Passkey to support Linux, there is zero chance that Arch Linux becomes a trusted attestation provider for the Web Environment Integrity API.

And if it did, this whole proposal would be useless, because I'd be able to use Headless Chromium on Arch Linux and just have Arch Linux say that my computing environment was secure. There is no definition of "trusted computing environment" for a website provider that doesn't involve blocking access to arbitrary user-controlled code execution at the OS and browser level.

Because if you couldn't block that access, you wouldn't have any security guarantees. The entire premise falls apart if fully user-controlled environments are supported. It would be a useless proposal.

> And there is a ton of evidence that attestation will be used for DRM and to prevent adblocking > Please share it.

https://developer.android.com/google/play/integrity -- please do any amount of research into how this has played out.

> uBlock Origin already objectively runs worse on Chrome than Firefox > I use it just fine on Chrome and do not see any ads.

https://github.com/gorhill/uBlock/wiki/uBlock-Origin-works-b... -- this is also not very difficult to look up, I kind of feel like you should have been able to find this link yourself.

> FLOC is [another long explanation of why advertisers are the victim and FLOC is actually making the web more private]

I have to say again, I don't know if you expect this to sway anyone reading these comments, but it's not going to. No one is going to read that paragraph and think, "you know what, this person probably does care about adblockers and probably is really committed to making sure they're not harmed."