With regard to my examples, WEI provides full confidence and stability in identifying the browser.

Relying on detecting browsers by differentiating between their features and quirks involves on having a large suite of checks to run, some of which might become incorrect as browsers change over time. It’s a maintenance burden, to say the least.

I believe there’s a misunderstanding somewhere. I wasn’t suggesting anything; I was explaining how Web Environment Integrity could be altered in the future to kill extensions.

The current form of WEI does not have the ability to enforce anything. It isn’t itself DRM, and it can’t prevent extensions from running on pages. What it can do and the only thing it does, is tell websites about the browser environment.

Right now, the only thing it tells websites is the name of the browser. A website having the browser name can’t directly enforce page integrity. It’s already possible to find out the browser name through the user agent or by fingerprinting it with JavaScript.

If WEI is approved and implemented, that opens up the possibility for future additions to the specification. Those changes could require that the browser sends more info to websites. I gave the example of a change that would require WEI tells the website that the browser has an extension which could modify the page contents.

A website having that information would turn WEI into DRM. It gives the website the choice to refuse service to any browser that is running an extension that could change what the user sees.

I hope that was more clear. I don’t expect Google to make changes that immediately block extensions, and then be kind enough to allow some of them back. I suspect they would make changes that don’t prevent extensions, and then revise them to prevent certain types of extensions.

I don’t disagree, and I’m personally aware of the consequences. Adding the API would be the first step, and future proposals and changes could amend it to add other environment details to tell a website that there are browser extensions that can read or modify the page.

I don’t really think summarizing WEI as though it already includes those really helps people understand what WEI currently is or does, though. Nobody reads the actual documentation before repeating what they were told, and that’s going to lead to the spread of factually-incorrect information. It’s not a bad thing for people to be aware of the long-term issue with having a WEI API, but users’ lack of understanding of WEI in its current form is just going to be used by Google as proof to dismiss dissenting feedback as FUD.

To elaborate on why I’m saying a citation is needed: I read the entire proposal and specification myself, and I couldn’t find evidence affirming the statement.

The Web Environment Integrity explainer document doesn’t require, suggest, or mention script or DOM integrity status under what information is in the signed attestation. Neither does the draft specification, which is pretty devoid of details. The closest it comes to that kind of thing is only enabling the API within a secure context, which basically means “the page was served over HTTPS using a valid certificate”.

That doesn’t mean that WEI can’t be used to enforce page integrity in an extremely roundabout way¹, but lacking a citation showing that it directly does that, it needs to be explained to people who are out of the loop how it can do that.

¹: One of the environment details sent to a website is a unique identifier for the browser. Blocking every browser except Android Chrome would limit the ability to use extensions to modify the website, since that browser doesn’t support them.

I’m not saying you’re wrong or that Web Environment Integrity is a good thing, but a primary source and citation is needed for this statement:

It enforces the original markup and code from a server to be the markup and code that the browser interprets and executes, preventing any post-loading modifications.

Firefox will probably survive if they bow and add WEI support.

I can’t imagine Google, Microsoft, and Apple opening themselves up to further monopolization scrutiny by trying to keep attestation restricted to their own browsers on their own operating systems.

Self-built or community forks are probably screwed, though.

And here’s a concern about the decentralized-but-still-centralized nature of attesters:

From my understanding, attesting is conceptually similar to how the SSL/TLS infrastructure currently works:

• Each ultimately-trusted attester has their own key pair (e.g. root certificate) for signing.

• Some non-profit group or corporation collects all the public keys of these attesters and bundles them together.

• The requesting party (web browser for TLS, web server for WEI) checks the signature sent by the other party against public keys in the requesting party’s bundle. If it matches one of them, the other party is trusted. If it doesn’t, they are not not trusted.

This works for TLS because we have a ton of root certificates, intermediate certificates, and signing authorities. If CA Foo is prejudice against you or your domain name, you can always go to another of the hundreds of CAs.

For WEI, there isn’t such an infrastructure in place. It’s likely that we’ll have these attesters to start with:

• Microsoft
• Apple
• Google

But hey, maybe we’ll have some intermediate attesters as well:

• Canonical
• RedHat
• Mozilla
• Brave

Even with that list, though, it doesn’t bode well for FOSS software. Who’s going to attest to various browser forks, or for browsers running on different operating systems that aren’t backed by corporations?

Furthermore, if this is meant to verify the integrity of browser environments, what is that going to mean for devices that don’t support Secure Boot? Will they be considered unverified because the OS can’t ensure it wasn’t tampered with by the bootloader?

Adding another issue to the pile:

Even if it isn’t the intent of the spec, it’s dangerous to allow for websites to differentiate between unverified browsers, browsers attested to by party A, and browser attested to by party B. Providing a mechanism for cryptographic verification opens the door for specific browsers to be enforced for websites.

For a corporate example:

Suppose we have ExampleTechFirm, a huge investor in a private AI company, ShutAI. ExampleTechFirm happens to also make a web browser, Sledge. ExampleTechFirm could exert influence on ShutAI so that ShutAI adds rate limiting to all browsers that aren’t verified with ShutAI as the attester. Now, anyone who isn’t using Sledge is being given a degraded experience. Because attesting uses cryptographic signatures, you can’t bypass this user-hostile quality of service mechanism; you have to install Sledge.

For a political example:

Consider that I’m General Aladeen, the leader of the country Wadiya. I want to spy on my citizens and know what all of them are doing on their computers. I don’t want to start a revolt by making it illegal to own a computer without my spyware EyeOfAladeen, nor do I have the resources to do that.

Instead, I enact a law that makes it illegal for companies to operate in Wadiya unless their web services refuse access to Wadiyan citizens that aren’t using a browser attested to by the “free, non-profit” Wadiyan Web Agency. Next, I have my scientists create and release a renamed versions of Chromium and Firefox with EyeOfAladeen bundled in them. Those are the only two browsers that are attested by the Wadiyan Web Agency.

Now, all my citizens are being encouraged to unknowingly install spyware. Goal achieved!

But the real questions is, can we change them?

Imagine this:

• Good thing → Zelda chest opening sound.
• Bad thing →The Office “Oh, god, please no.”
• User interaction → Honking goose.
• Log in → Futurama “Welcome to the world of tomorrow!”
• Log out →AOL “You’ve got mail”

Having thought about it for a bit, it’s possible for this proposal to be abused by authoritarian governments.

Suppose a government—say, Wadiya—mandated that all websites allowed on the Wadiyan Internet must ensure that visitors are using a list of verified browsers. This list is provided by the Wadiyan government, and includes: Wadiya On-Line, Wadiya Explorer, and WadiyaScape Navigator. All three of those browsers are developed in cooperation with the Wadiyan government.

Each of those browsers also happen to send a list of visited URLs to a Wadiyan government agency, and routinely scan the hard drive for material deemed “anti-social.”

Because the attestations are cryptographically verified, citizens would not be able to fake the browser environment. They couldn’t just download Firefox and install an extension to pretend to be Wadiya Explorer; they would actually have to install the spyware browser to be able to browse websites available on the Wadiyan Internet.