Mr.J
Skilled
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 intro to the Web Integrity API starts out: "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."
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.
Perhaps the most telling line of the explainer is that it "takes inspiration from existing native attestation signals such as [Apple's] App Attest and the [Android] Play Integrity API." Play Integrity (formerly called "SafetyNet") is an Android API that lets apps find out if your device has been rooted. Root access allows you full control over the device that you purchased, and a lot of app developers don't like that. So if you root an Android phone and get flagged by the Android Integrity API, several types of apps will just refuse to run. You'll generally be locked out of banking apps, Google Wallet, online games, Snapchat, and some media apps like Netflix. You could be using root access to cheat at games or phish banking data, but you could also just want root to customize your device, remove crapware, or have a viable backup system. Play Integrity doesn't care and will lock you out of those apps either way. Google wants the same thing for the web.
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.
Google’s nightmare “Web Integrity API” wants a DRM gatekeeper for the web
It's just a "proposal," but it's also being prototyped inside Chrome right now.
arstechnica.com
Googlers have proposed a way to determine whether browsers can be trusted, as a defense against criminal fraud and other bad behavior. Some in the internet community fear this is the end of the web as we know it.
The proposal, dubbed Web Environment Integrity (WEI), showed up as code in April and was announced in May. It elicited a handful of concerned comments among those who follow the development of the Chromium open source project's Blink rendering engine, but didn't attract much attention from the technical community until it was published on Friday as a working draft specification.
Google's engineers describe WEI as a way for browser clients to establish trust with a server through a third party (eg, Google Play) that presents a token attesting to the integrity of the client environment.
In simpler terms, WEI provides a way for a browser to prove it is working as a website operator expects, and hasn't been manipulated. If you have a website that offers in-browser gaming, and you want to make sure no player is cheating, you could use WEI to determine that connected clients are pure, legit, and not running any cheat code.
Same goes for websites that don't want automated bots posting or liking posts – engagement has to be done via an accepted, unaltered browser. And for publishers that only want to serve content and ads to browsers that definitely aren't just bots.
This therefore starts to slide the web toward a time in which only authorized, officially released browsers will be accepted by websites.
And since Chromium serves as the foundation of not just Google Chrome, but also Microsoft Edge, Brave, and a number of other browsers, WEI could have a broad effect on the web – if and when it gets deployed and adopted.
Google Web Environment Integrity draft draws developer rage
Safe to say, this proposal has gone down like a poweroff -fn
www.theregister.com
Mozilla opposes this proposal because it contradicts our principles and vision for the Web.
Any browser, server, or publisher that implements common standards is automatically part of the Web:
Standards themselves aim to avoid assumptions about the underlying hardware or software that might restrict where they can be deployed. This means that no single party decides which form-factors, devices, operating systems, and browsers may access the Web. It gives people more choices, and thus more avenues to overcome personal obstacles to access. Choices in assistive technology, localization, form-factor, and price, combined with thoughtful design of the standards themselves, all permit a wildly diverse group of people to reach the same 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.
Detecting fraud and invalid traffic is a challenging problem that we're interested in helping address. However this proposal does not explain how it will make practical progress on the listed use cases, and there are clear downsides to adopting it.
Request for Position: Web Environment Integrity API · Issue #852 · mozilla/standards-positions
Request for Mozilla Position on an Emerging Web Specification Specification Title: Web Environment Integrity API Specification or proposal URL (if available): https://rupertbenwiser.github.io/Web-E...
github.com
This is very, very, very bad. Hopefully EU will do something about this. Can't expect anything from US or any other governments.