Web Environment Integrity
Google’s newest proposed web standard is… DRM? Over the weekend the Internet got wind of this proposal for a “Web Environment Integrity API. “ The explainer is authored by four Googlers, including at least one person on Chrome’s “Privacy Sandbox” team, which is responding to the death of tracking cookies by building a user-tracking ad platform right into the browser.
[…]
The goal of the project is to learn more about the person on the other side of the web browser, ensuring they aren’t a robot and that the browser hasn’t been modified or tampered with in any unapproved ways. The intro says this data would be useful to advertisers to better count ad impressions, stop social network bots, enforce intellectual property rights, stop cheating in web games, and help financial transactions be more secure.
[…]
Google’s plan is that, during a webpage transaction, the web server could require you to pass an “environment attestation” test before you get any data. At this point your browser would contact a “third-party” attestation server, and you would need to pass some kind of test. If you passed, you would get a signed “IntegrityToken” that verifies your environment is unmodified and points to the content you wanted unlocked. You bring this back to the web server, and if the server trusts the attestation company, you get the content unlocked and finally get a response with the data you wanted.
Web-Environment-Integrity (via Hacker News, Chromium, Hacker News):
This repository details the proposal to add a new API for determining the integrity of web environments[…]
[…]
The explainer goes gives a high level overview of the proposal.
The spec currently describes how this is being prototyped in Chromium.
Chrome Proposal (via Hacker News):
Users often depend on websites trusting the client environment they run in. This trust may assume that the client environment is honest about certain aspects of itself, keeps user data and intellectual property secure, and is transparent about whether or not a human is using it. This is frequently established through the collection and interpretation of highly re-identifiable information.
The web environment integrity API provides a token that attests key facts about the environment their client code is running in while keeping the response low-entropy.
Interpeer (via Hacker News):
Ostensibly, this is to ensure for the user that the environment has not been tampered with in any way. The described use cases, however, make fairly clear that it is for the business that this feature exists.
In particular, the proposal suggests that “Google Play” could provide such attestations, and also provides an example case which intends to ensure that ads are served only to legitimate users, not to automated processes.
[…]
What Google is really after is ad blockers.
The downside of this approach is that it opens up a door for arbitrary abuse. Websites can refuse service unless you install their proprietary data collection agent.
Between this and features like PassKeys, you can imagine browsing a web where you are less frequently challenged to prove your identity and, when that happens, it is less interruptive.
Unfortunately, the likely reality is more worrisome.
[…]
It goes without saying — so I will anyway — that publishers and advertisers want to ensure humans look at ads. Google does as well. As the world’s largest online ad company — perhaps criminally so — Google has to toe a fine line between doing right by its advertising customers and doing right by the users of its web browser, which just so happens to be the world’s most popular. […] But what that could look like in practice is for unauthenticated users to be aggressively challenged by login prompts and CAPTCHAs.
Alex Ivanovs (via Hacker News):
Google’s proposal pivots on a key premise: enhancing trust in the client environment. It introduces a new API that allows websites to request a token, providing evidence about the client code’s environment. Google’s engineers elaborate, “Websites funded by ads require proof that their users are human and not bots…Social websites need to differentiate between real user engagement and fake engagement…Users playing online games want assurance that other players are adhering to the game’s rules.”
However, the critics argue that the quest for trust may come at the expense of privacy. While Google ensures that the tokens will not include unique identifiers, critics fear that this system, if misused, could lead to unwarranted surveillance and control.
[…]
A significant concern stemming from the tech community is the potential for monopolistic control. By controlling the “attesters” that verify client environments, Google, or any other big tech company, could potentially manipulate the trust scores, thereby deciding which websites are deemed trustworthy. This opens up a can of worms regarding the democratic nature of the web.
[…]
However, how this plays out with browsers that allow extensions or are modified remains a grey area.
Tim Perry (via Hacker News):
Of course, Google isn’t the first to think of this, but in fact they’re not even the first to ship it. Apple already developed & deployed an extremely similar system last year, now integrated into MacOS 13, iOS 16 & Safari, called “Private Access Tokens”:
Private Access Tokens are powerful tools that prove when HTTP requests are coming from legitimate devices without disclosing someone’s identity.
The focus here is primarily on removing captchas, and as such it’s been integrated into Cloudflare (discussed here) and Fastly (here) as a mechanism for recognizing ‘real’ clients without needing other captcha mechanisms.
Fundamentally though, it’s exactly the same concept: a way that web servers can demand your device prove it is a sufficiently ‘legitimate’ device before browsing the web.
[…]
Free usage of different clients & servers on the web is what has built the open web, and is a large part of why it’s so successful. Attestation breaks this by design.
Neel Chauhan (via Dare Obasanjo):
Supposedly, this is to make sure a browser environemnt can be “trusted”, but it seems Google wants this so they can kill ad blockers.
This looks a lot like Microsoft’s ill-fated “Palladium” they wanted to ship with Vista. Palladium was an attempt to improve Windows security by adding attestation and integrity, but could also be abused to enforce DRM everywhere on your PC, block competing but “untrusted” applications such as Firefox. The only saving grace was Vista’s very painful and long development period where Palladium was eventually killed so Vista could actually ship.
[…]
Even on the web today, there are bad actors like Chase Bank who claims to “require” only Windows or Mac (like it’s still 2003) and uses this as justification to block BSD and Linux-on-ARM without user agent switchers. The only reason why this isn’t in the media is because Chase allows Linux-on-x86 and Chrome OS, due to both having >2-3% market share each. In fact, I can log into Chase.com on my Fedora laptop fine without modifications.
gacelperfinian (via Hacker News):
I have personal concerns since that while [Web Environment Integrity API proposal] in theory is vendor-neutral, in practice there is only three vendors which are widely-recognized: Google Widevine (which is used by Firefox in most platforms plus in Chrome and Android), Microsoft PlayReady (used by Microsoft Edge and Windows plus in some Android devices alongside Widevine), and Apple FairPlay (used in Safari and everything Apple).
It is reasonable that the current situation in EME would translate into this specification. This may hinder users of other browsers since while in theory websites would just try to verify the identity by other means in practice this would lead to websites requiring pre-approved browsers.
Conniving third parties can thus use this scheme to ensure that they are interacting with a device running the attacker’s software, and thus that the device is restricting the user behavior as the attacker specifies. For instance, it can ensure that the device is running the accomplice’s code unmodified, preventing the user from being able to run software of their choice, and it can ensure that the user is using device as desired by the attacker and their accomplices.
This attack is already running against Android smartphone users (orchestrated by Google, in the form of SafetyNet and the Play Integrity API) and iOS smartphone users (orchestrated by Apple) and this extends the attack to the web.
Can I just say I appreciate the framing of this as an attack? Somehow I hadn’t yet mentally filed Google and friends under “Man in the middle” but that’s pretty much exactly what’s going on.
This Web Integrity API is just a means to cement themselves as obligatory man in the middle, as opposed to an optional one.
Mozilla opposes this proposal because it contradicts our principles and vision for the Web.
[…]
Mechanisms that attempt to restrict these choices are harmful to the openness of the Web ecosystem and are not good for users.
Additionally, the use cases listed depend on the ability to “detect non-human traffic” which as described would likely obstruct many existing uses of the Web such as assistive technologies, automatic testing, and archiving & search engine spiders. These depend on tools being able to receive content intended for humans, and then transform, test, index, and summarize that content for humans. The safeguards in the proposal (e.g., “holdback”, or randomly failing to produce an attestation) are unlikely to be effective, and are inadequate to address these concerns.
Julien Picalausa (Hacker News):
Why Vivaldi browser thinks Google’s new proposal, the Web-Environment-Integrity spec, is a major threat to the open web and should be pushed back.
If someone drafted a proposal to the W3C that only a pre-approved set of existing browsers should be allowed to render web pages, the correct response would not be to “take the stance that you oppose that proposal,” it would be to seriously question whether the party should even participate in the group. Make no mistake, that is what is happening now.
Previously:
- Firefox 115’s Two-Tier Extensions System
- iOS 16 Automatic Verification
- Forged Emergency Data Requests
- Android Privacy Sandbox
- iCloud Private Relay White Paper
Update (2023-07-31): Karl Fogel (via Hacker News):
In the normal world, you show up at the store with a five dollar bill, pick up a newspaper, and the store sells you the newspaper (and maybe some change) in exchange for the bill. In Google’s proposed world, five dollar bills aren’t fungible anymore: the store can ask you about the provenance of that bill, and if they don’t like the answer, they don’t sell you the newspaper. No, they’re not worried about the bill being fake or counterfeit or anything like that. It’s a real five dollar bill, they agree, but you can’t prove that you got it from the right bank. Please feel free to come back with the right sort of five dollar bill.
This is not the Open Web that made what’s best about the Internet accessible to the whole world. On that Web, if you send a valid request with the right data, you get a valid response. How you produced the request is your business and your business alone. That’s what software freedom is all about: you decide how your machinery works, just as other people decide how their machinery works. If your machine and their machine want to talk to each other, they just need an agreed-on language (in the case of the Web, that’s HTTP) in which to do so.
Google’s plan, though, steps behind this standard language to demand something no free and open source software can ever deliver: a magical guarantee that the user has not privately configured their own computer in any way that Google disapproves of.
Update (2023-08-09): Peter Snyder:
Brave strongly opposes Google’s “Web Environment Integrity” (WEI) proposal. As with many of Google’s recent changes and proposals regarding the Web, “Web Environment Integrity” would move power away from users, and toward large websites, including the websites Google itself runs. Though Brave uses Chromium, Brave browsers do not (and will not) include WEI. Further, some browsers have introduced other features similar to, though more limited than, WEI (e.g., certain parts of WebAuthn and Privacy Keys); Brave is considering how to best restrict these features without breaking benign uses.
Update (2023-08-15): Philippe Le Hégaret (via Hacker News):
For a few weeks now we have been hearing concern in the Web community in regard to Web Environment Integrity, and are asked more and more about it. Our silence is due to the fact that the Web Environment Integrity API is not being worked on in W3C, nor has there been any submission to W3C for W3C Technical Architecture Group (TAG) review.
2 Comments RSS · Twitter · Mastodon
Seeing how unreliable is the Android Integrity API, I don't wait much from this initiative.
I'm using Apple Integrity API for iOS, Huawei Security API on Huawei device, and Google Play API on Android, and the Android API is the only one I can't use to enforce request validation as has a too high failure rate, and would bother too much legitimate users.
I quite never understood the need to hand over browsing experience and all to Google. Are not Firefox and Edge good enough for 90% of Windows users? And Safari is optimized for Apple’s hardware so it is actually counter-effective to replace it.