In practice, this will make it harder, but not impossible, to run ad blockers. Now instead of just finding and installing a plugin, you'll have to first find and install a forked browser that implements the attestation as something like 'return true'. This will predictably decrease the number of people blocking ads.
Personally, I don't object to this. The easy solution for most people is simply: don't consume the content. Or pay money instead of watching ads. Content creators, it must be said, also have the option of self-hosting and/or creating content as a hobby rather than a career. As someone who has grown more and more despairing of any paid-for speech, especially by ads, I welcome this change.
Far more troubling is the possibility of attestation for "important apps" like banking or government. In general this mechanism gives the org a way to prevent you from doing what you want with your data. For example, they can prevent you from scraping data and automating end-user tasks. This takes away your degrees-of-freedom, and using a modified browser will certainly become an actionable offense. In my view this is by far the more troubling aspect of this change, since it take away significant aspects of user autonomy in a context where it matters most.
Technically sophisticated users will note that it's not possible to secure a client, and foolish to try. This misses the point. These changes stochastically change behaviors "in the large", like a shopping center that offers two lanes in and one lane out, or two escalators in and one out. This represents a net transfer of power from the less powerful to the more powerful, and therefore deserves to be opposed.
EDIT: please don't downvote, but rather reply with your objection.
There is no option to "implements the attestation as something like 'return true'". There is a chain of verification from the hardware manufacturers building in software surveillance, through OS developers treating the device owner as an attacker, this proposal of carrying the same user-hostile dynamic through browsers, and finally to the website that by verifying the signatures can force a user to only use software that enforces all of the above.
You should very much object to this! Today, "unsupported browser" is a CYA term that doesn't really mean much besides that the website has limited testing budget (and who doesn't?). With this proposal it would become a hard blocker. Goodbye Linux/BSDs/etc. Goodbye `make install`. Goodbye virtual machines. Goodbye computers that last longer than the rapid e-waste treadmill of mobile phone land. You will of course be able to keep running user-representing operating systems, old computers, "jail" breaking them, etc. You just won't be able to access banking websites, followed by web stores, then general sites. Basically anywhere today that hassles users with CAPTCHAs will be looking to implement these restrictions eventually (which is basically everywhere).
Your second paragraph, about chain of trust, gets a little more wobbly, but this is a matter of fact, not opinion. Will this change require a chain of trust from hardware up? That's startling. Do you have a link? I read the proposal but don't recall seeing that.
The third paragraph seems to articulate the worry that systems will now be closed with centralized gate keepers determining what we can do with our systems. Or at least, that will be the default unless you can get grandpa's old TPM-free linux laptop working again. And even if you do, you won't be able to connect it to the future internet to do anything real. That's not a good future. It's one which makes individuals passive and controlled by central authority - and even if you don't object to this morally, you must admit that an ignorant and disabled population is weak and susceptible to attack.
> With the web environment integrity API, websites will be able to request a token that attests key facts about the environment their client code is running in. For example, this API will show that a user is operating a web client on a secure Android device. Tampering with the attestation will be prevented by signing the tokens cryptographically.
I don't see what else this could be referring to besides bringing TPM "remote attestation" up through the software stack to the level of a web browser. By "secure" Android it must mean one running a corporate Android distribution (see: SafetyNet), where Google has already been pushing this lockdown dynamic for a few years at least. Without tying it into the TPM, there would be literally no point to this specification as it could always be faked.
The insidious thing about this spec is that it's not an immediate prescriptive lockdown the way corporate "secure" boot is. Rather if it turns on tomorrow, Firefox, extensions, and community Linux distributions will all still work fine. But the long term dynamic is that each of these nonstandard things will be stamped out in the name of "security" - look at how the SafetyNet requirements on Android are getting incrementally harder to "pass".
Fundamentally this is entirely about consensual interactions. Right now, the demarcation point between user interests and website/server/company interests is the communications protocol itself. Your computer represents your interests, my computer represents my interests, and they possibly communicate with each other while still representing each of our interests. Remote parties that you're communicating with being able to verify what code you are running means they are then able to dictate what code you must run, even when it undermines your interests. Your only recourse becomes to not communicate, which doesn't work in our world of imbalanced power relationships. Computing's revolutionary spark of personal autonomy gets shoved back in the bottle as far as the Web is concerned.
> centralized gate keepers determining what we can do with our systems. Or at least, that will be the default unless you can get grandpa's old TPM-free linux laptop working again
There's some nuance here. Likely you will still be able to "jail break" new devices, or even root them in a supported way like Google's current Android devices. But doing so will make the device useless for accessing any website that insists on performing the verification. So sure, you can keep on using your nonstandard development environments just fine - most of the Web will be unavailable to it though.
You will just need a second WebTV like device for accessing banking websites, then shopping websites, then news websites. As I said, anywhere that currently pops up CAPTCHAs when browsing from less-surveillable IPs is a good indicator for the eventual adoption path. Said device will implement all the restrictions the website publishers can dream of - ads, lack of copy/paste, no screenshots, no access by VNC, no browser extensions, no protection from corporate surveillance, etc.
> And even if you do, you won't be able to connect it to the future internet to do anything real
That's a long way off and doesn't have any technical connection to this proposal. But one can imagine this proposal being one step in a chain of developments/legislation that brings us to that point.