Google’s nightmare “Web Integrity API” wants a DRM gatekeeper for the web

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.

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.

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.

This is very, very, very bad. Hopefully EU will do something about this. Can't expect anything from US or any other governments.
 
EU will defintely not allow this. YOU are not VISITING a website.
You are ALLOWING a website to run on YOUR machine, so you dictate terms.
Now Google wants to plaster ads over every square inch of every page under the guise of DRM, as in protecting their intellectual property of their webpage, like how streaming movies and shows are protected under copyright? This is just a ploy to block ad blockers. That's not gonna happen in EU at least.

Regardless, rest of the world has crappy laws, so will probably happen here.
 
Is this relevant to the op? If so, how?
1. Google's dominance makes 'Web Integrity' mandatory in browsers.
2. Adblockers can not be used on this new web as they work by modifying the webpages.
3. Advertisers give zero f***s about what they are serving in ads as they have no reason to spend money on making sure their ads are safe. Web is more unsecure than before without adblockers.

I hope you've got it.

If Google wants to 'make internet secure' they should do something about advertisers and SEO spam websites instead of dictating what users can or can't do with their devices. But this web integrity API is not about security or anything. It's about serving ads to you and me. Cause that's Google/Alphabet's main business. It is first and foremost an ad company which earned them $42billion in Q2 2023. Meanwhile, Google Cloud earned them $8 billion, less than 20% in the same period.

 
You're a bit mixed up there... Regular advertisers were not involved in that malware attack you linked. There's no action advertisers can take to prevent those ads from showing up. Those malicious advertisers, the ones driving the ads in question, managed to circumvent Google's ad review mechanisms to get malicious ads to serve.

You're right that the integrity thing is just to protect their bottom line, but the malware ads arenot really relevant to the initial discussion.
 
Back
Top