Google has proposed adding the “Web environment integrity API” to Chrome. The goal of this API is to ensure that the user does not have control over their device. The API will provide cryptographically secure attestation that a “trusted party” is in control of the device.
The proposed API is very harmful to individual freedoms and will destroy the open web. The consequence of Chrome implementing this API is that everyone using hardware or software that isn’t entirely under control of a small number of massive corporations will begin to get cut off from the web.
These “trusted parties” will very likely be Apple, Google and Microsoft. If you don’t have a device controlled by one of these for-profit companies you will be cut of from many websites. No Linux, no Steam Deck, no custom Android ROMs, no rooted devices. If you are in control of your device you will be locked out. There will be no easy or reliable workarounds. I do not welcome our new corporate overlords.
Stated Goals
The stated goals are:
- Detect social media manipulation and fake engagement.
- Detect non-human traffic in advertising to improve user experience and access to web content
- Detect phishing campaigns (e.g. webviews in malicious apps)
- Detect bulk hijacking attempts and bulk account creation.
- Detect large scale cheating in web based games with fake clients
- Detect compromised devices where user data would be at risk
- Detect account takeover attempts by identifying password guessing
I find this rationale an unconvincing argument for such extreme measures.
Anti-Bot
1, 2, 4 and 7 are effectively the same and don’t actually seem to be significantly impaired by this API. These are all aimed at preventing “bot traffic”. This is any sort of traffic (usually automated) that is high volume and not by the intended users of the service. This is often spam, scraping or brute force attacks. While this API would inconvenience botters I don’t see how this API actually prevents this traffic. There is nothing stopping these “bots” from using an “Approved” Chrome browser on an “Approved” OS on “Approved” hardware. These bots are actually low-paid humans more often than one would expect.
Anti-Malware
3 and 6 are similar. They are trying to ensure that the client device is “trustworthy” as defined by the server. For example this API could detect if an OS has been compromised by malware either at the OS level or a modified browser. For example your bank could deny you access to their website if your device seems to be compromised.
This seems reasonable at first, but falls apart after brief consideration. If your device has malware which is going to steal banking credentials why bother actually connecting to the legitimate bank website? Spoofing login pages is trivial and would completely bypass the need to produce a valid attestation. The attacker can then use an “Approved” device to log into the bank account. This does add minor obstacles but doesn’t seem to provide any fundamental security that justifies such a heavy-handed approach.
Trusted Client-side Computing
Number 5 appears to be the real goal. Google wants to be able to run code on your device that you have no control over. They want to verify that you can’t access any data that they send and can’t modify how the code works. They want to ensure that the user has no control over their computing.
Upsides
The upsides of this API are few and far between. Trusted clients can be useful for a small number of things. For example anti-cheat may be an acceptable use case if users agree to use it. Many games want to send data to the client for performance reasons but the user should not be able to access it. For example the location of an enemy that is about to walk around a corner. This is useful for lag compensation but the precedence of the enemy should not be revealed until the correct time.
Unfortunately we have been shown time and time again that we can’t trust capitalist corporations with these powerful interfaces to control users. Their goal is to make money, not to promote the public good. This API will be abused.
Downsides
The downside is that we lose all agency in our computing. The websites we visit will place requirements on the software and hardware that we can use. In practice this means that you better be running an OS and Browser developed by Google, Apple or Microsoft. If you aren’t a big corporation you won’t be able to make or modify a browser or an operating system. You won’t be able to access your bank, government services or even McDonald’s from any “unapproved” software or hardware.
This is effectively banishing Free Software from accessing the web. Let’s reflect on the 4 essential freedoms for software that respects the user.
- The freedom to run the program as you wish, for any purpose.
- The freedom to study how the program works, and change it so it does your computing as you wish. Access to the source code is a precondition for this.
- The freedom to redistribute copies so you can help others.
- The freedom to distribute copies of your modified versions to others. By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.
Freedom 0 is violated. I am unable to run the software on the operating system or hardware of my choice, and if the remote Attestation API is disabled I can not continue to use these features.
Freedom 1 is violated. If I change the program in any way I can no longer run it. So I am unable to compute as I wish. It is Google’s way or the highway.
Freedom 2 is mostly preserved. However, the signature can be revoked or the remote Attestation API can start refusing to sign attestations at any time.
Freedom 3 is violated as it depends on being able to modify the program (Freedom 1) which is not available.
So any “trustworthy web environment” can provide at most ½ of the four essential freedoms. It is clear that this program is no longer an agent of the user, but an agent of mega-corporations that will be the attestation providers.
Are You Just Being Dramatic?
I don’t think so. We have already seen this happen on Android with SafetyNet Attestation API and then the Play Integrity API. These APIs are already used to restrict the freedom of users. The most common examples are Google Pay and banking apps but there is a long tail of others such as Netflix, Snapchat, Pokemon Go, McDonald’s and even Mario Run. That’s right, if you want to play Mario you need a device that is certified to be in control of Google, not the user.
If this interface becomes available on the web the same thing is sure to happen. More and more sites will start requiring it. After all 95% of users are running “Approved” setups anyway. That other 5% is probably just bots anyway /s
What Can We Do About It?
Browser Diversity
The best long-term option is to use a different browser. Google can push these user-hostile features because Chrome has 70% market share (or up to 85% depending on how you count). If there were a diversity of competitive browsers Google wouldn’t be able to force their features into the web. They would have to get agreement from the other browsers.
But with the majority of users using Chrome, they can just push features. Sites will start using them and this will push more people to Chrome because if their bank refuses to support Firefox most people will switch so that they can access their bank. Extend and Extinguish.
In general, I would say that the best options are Firefox and Safari. But Safari already shipped an equivalent API and attestation is in their favour because it means that they get to sell more locked down hardware. So in this case Firefox is our best option.
Other options are Chromium derivatives like Brave, Edge and Opera. However, these still provide power to Google as new Chromium features end up in derivatives by default. While specific derivatives may block specific features it is infeasible for them to maintain too many patches on top of Chromium due to ongoing cost. For example Brave has made some claims around supporting Manifest v2 features after Chrome removes them, but it is clear that they are careful what they are promising, as maintaining full support and a new extension store is clearly too much work for the company. So while using a derivative is better than using Chrome directly it still gives Google power over the web. Power that they have shown they can’t be trusted with.
Regulatory Interference
It is clear that Google is abusing its dominant position to push features that are hostile to the public. Regulatory bodies should be able to prevent them from doing this. Please reach out to whoever you can.
Raise Awareness
The last is making noise. Enough user backlash will likely make them back out. Or at least it will drive users away from Chrome and leave a big stain on any websites refusing to support other browsers.
How is This Possible?
The attestation will be cryptographically signed. It will ensure that you are only running supported hardware and software in a supported configuration. At a high level it looks like this:
- When your device boots the first code to execute is firmware on a hardware security module (HSM).
- This module will cryptographically verify the bootloader before launching it.
- The bootloader will cryptographically verify the operating system before starting it.
- The operating system will cryptographically verify the browser.
- When the JavaScript Web Integrity API is called the browser will request a signature from the OS.
- The OS will request a signature from the HSM.
- The signature will be provided to the JavaScript caller to be relayed to the website.
- The website will validate that this signature is from a trusted party and deny entry otherwise.
If at any point a signature verification fails or an untrusted operation is performed either the computer will stop (refuse to boot) or trust will be revoked. For example if you attach a debugger to the browser the process will be marked as tainted and the OS will refuse to perform signatures (step 5). If an untrusted driver is loaded into the OS it will inform the TPM which will lock the signing key until a clean boot can restore the system to a trusted state. The TPM is a hardened device specifically designed to make extracting the private key difficult.
This system is well designed. It will likely not be possible to work around it without finding exploits. Exploits will be found as this is a large software stack but they will be fixed rapidly, and the external signing service can refuse to sign attestations from unpatched machines. Apple has shown us that large companies can maintain an OS stack like this with minimal exploits. While iOS jailbreaks are found they are rare and quickly fixed. This isn’t just something that we can hack around with a patched browser.
Other Overviews
These are in no particular order and I haven’t read them all carefully, but they appear to give valuable insights and different explanations of the topic that may be interesting.
Top comments (0)