Google seems to love creating specifications that are terrible for the open web and it feels like they find a way to create a new one every few months. This time, we have come across some controversy caused by a new Web Environment Integrity spec that Google seems to be working on.
At this time, I could not find any official message from Google about this spec, so it may be just the work of some misguided engineer at the company that has no backing from higher up, but it seems to be work that has gone on for more than a year, and the resulting spec is so toxic to the open Web that at this point, Google needs to at least give some explanation as to how it could go so far.
What is Web Environment Integrity? It is simply dangerous.
The spec in question, which is described at https://github.com/RupertBenWiser/Web-Environment-Integrity/blob/main/explainer.md, is called Web Environment Integrity. The idea of it is as simple as it is dangerous. It would provide websites with an API telling them whether the browser and the platform it is running on that is currently in use is trusted by an authoritative third party (called an attester). The details are nebulous, but the goal seems to be to prevent “fake” interactions with websites of all kinds. While this seems like a noble motivation, and the use cases listed seem very reasonable, the solution proposed is absolutely terrible and has already been equated with DRM for websites, with all that it implies.
It is also interesting to note that the first use case listed is about ensuring that interactions with ads are genuine. While this is not problematic on the surface, it certainly hints at the idea that Google is willing to use any means of bolstering its advertising platform, regardless of the potential harm to the users of the web.
Despite the text mentioning the incredible risk of excluding vendors (read, other browsers), it only makes a lukewarm attempt at addressing the issue and ends up without any real solution.
So, what is the issue?
Simply, if an entity has the power to decide which browsers are trusted and which are not, there is no guarantee that they will trust any given browser. Any new browser would by default not be trusted until they have somehow demonstrated that they are trustworthy, to the discretion of the attesters. Also, anyone stuck running on legacy software where this spec is not supported would eventually be excluded from the web.
To make matters worse, the primary example given of an attester is Google Play on Android. This means Google decides which browser is trustworthy on its own platform. I do not see how they can be expected to be impartial.
On Windows, they would probably defer to Microsoft via the Windows Store, and on Mac, they would defer to Apple. So, we can expect that at least Edge and Safari are going to be trusted. Any other browser will be left to the good graces of those three companies.
Of course, you can note one glaring omission in the previous paragraph. What of Linux? Well, that is the big question. Will Linux be completely excluded from browsing the web? Or will Canonical become the decider by virtue of controlling the snaps package repositories? Who knows. But it’s not looking good for Linux.
This alone would be bad enough, but it gets worse. The spec hints heavily that one aim is to ensure that real people are interacting with the website. It does not clarify in any way how it aims to do that, so we are left with some big questions about how it will achieve this.
Will behavioral data be used to see if the user behaves in a human-like fashion? Will this data be presented to the attesters? Will accessibility tools that rely on automating input to the browser cause it to become untrusted? Will it affect extensions? The spec does currently specify a carveout for browser modifications and extensions, but those can make automating interactions with a website trivial. So, either the spec is useless or restrictions will eventually be applied there too. It would otherwise be trivial for an attacker to bypass the whole thing.
Can we just refuse to implement it?
Unfortunately, it’s not that simple this time. Any browser choosing not to implement this would not be trusted and any website choosing to use this API could therefore reject users from those browsers. Google also has ways to drive adoptions by websites themselves.
First, they can easily make all their properties depend on using these features, and not being able to use Google websites is a death sentence for most browsers already.
Furthermore, they could try to mandate that sites that use Google Ads use this API as well, which makes sense since the first goal is to prevent fake ad clicks. That would quickly ensure that any browser not supporting the API would be doomed.
There is hope.
There is an overwhelming likelihood that EU law will not allow a few companies to have a huge amount of power in deciding which browsers are allowed and which are not. There is no doubt that attesters would be under a huge amount of pressure to be as fair as possible.
Unfortunately, legislative and judicial machineries tend to be slow and there is no saying how much damage will be done while governments and judges are examining this. If this is allowed to move forward, it will be a hard time for the open web and might affect smaller vendors significantly.
It has been long known that Google’s dominance of the web browser market gives them the potential to become an existential threat to the web. With every bad idea they have brought to the table, like FLOC, TOPIC, and Client Hints, they have come closer to realizing that potential.
Web Environment Integrity is more of the same but also a step above the rest in the threat it represents, especially since it could be used to encourage Microsoft and Apple to cooperate with Google to restrict competition both in the browser space and the operating system space. It is imperative that they be called out on this and prevented from moving forward.
While our vigilance allows us to notice and push back against all these attempts to undermine the web, the only long-term solution is to get Google to be on an even playing field. Legislation helps there, but so does reducing their market share.
Similarly, our voice grows in strength for every Vivaldi user, allowing us to be more effective in these discussions. We hope that users of the web realize this and choose their browsers consequently.
The fight for the web to remain open is going to be a long one and there is much at stake. Let us fight together.
The latest development on Google’s WEI as of 03.11.2023
Hot off the press, we have learned that Google is not proceeding with its Web Integrity API.
This is massively positive for the neutrality of the open Web. Though of course, with Google being so heavily driven by their interests rather than the benefit of the Web in general, it remains to be seen (and we strongly suspect it won’t take long) what they choose to replace it with. Are they, for example, just preparing a seemingly less obnoxious spec that is actually just as harmful to users (as they did with FLOC and Topics)? It also seems highly suspicious that it coincides with their very recent announcement to move from pay-per-click to pay-per-impression for ads.
Generally, Google hasn’t shown itself to be a trustworthy custodian of the web and we can’t let this apparent victory lure us into resting on our laurels. As always, a strong diversity of browsers and browser engines is going to be crucial to counteract any future attempt by a single party to dictate the future of the web.
Last edited on 11.10 am on 03.11.2023.