Web Environment Integrity API Proposal

Even the ad example is about not charging advertisers for bot views, which is a huge problem right now.

The problem is that a tool can often be used for evil as easily as for good, and the more the standard was used to block ad blockers over simply filtering out User Agent spoofing bots, the more this tool ends up evil.

And even if the limited scope in the proposal was the true intent, there's nothing preventing scope creep.

Though reading over it all, I do think the assumption of motivations in most of the comments here are misaligned. This does seem to be primarily focused on the issue of growth in bot activity and making it harder on bots to act as if human to servers.

Still, the spirit of who controls the client is very much at stake, and the comments here are ostensibly right that this is a measure that should not happen.

(And frankly, given the bubbling attitudes about enshittification coupled with the coming lowered barrier of entry for competition against software firms and content production, I think this is very much the kind of thing that may backfire horribly if forced though.)

I never thought I'd see a CoC being used as ammo against this, but it's excellent.

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

That's exactly what we need to do. More specifically, we need to decouple the app web from the document web. Most of the value of the web to society lies in text, images, and video, in that order. We need a version of the web refocused around basic content with a spec simple enough for a small team to implement a browser for. A subset of HTML/CSS is probably the only way to succeed, since sites would need to work with current browsers. I think a few HTML tags + flexbox + fonts + colors would get you pretty far.

The only way in which Chrome is more secure at anything appears to be securely forcing you to view ads via this API. And a shocking amount of malware fails to work when you use a running environment that 95% of society are not using.

You are far safer on Firefox than Chrome.