![](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="830" height="830"><rect fill-opacity="0"/></svg>)
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 is possible that it is 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 of deciding 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.
A lot of Linux users, (can't speak for all of them), refuse to even use a browser with a Chromium base. For them, it's all about Firefox, or the Firefox forks because that way they don't give Google/Chrome the market share as much as they have now.
@scottytrees: Linux user here. Typing this from Vivaldi, it's usually one of the first pieces of software I download whenever I install a fresh Linux distro
lovely article julien. omz google are pathetic!
Google has been testing a similar concept in Android 13: basically a site can now restrict the list of apps you can use to browse it. This was applied f.i. by Reddit long before the recent API debacle: the system would open Reddit URLs only with Chrome or with the official Reddit app. Want to open Reddit URLs with any of the myriad of unofficial clients, such as Slide, Boost, RedditSync, etc., as you did in Android 12? You lose, that's now blocked by the OS. Again, it happened long before the API debacle.
@lcd047 said in Unpacking Google's new "dangerous" Web-Environment-Integrity specification:
Yea just got the update today and as soon as I landed back on my phones home screen I had to turn off 3 items. Think it's time I look into then non Google phone OS's.
how do you get people to use your browser? update it and put in useful features so people would consider using it? no you force them
@cashelgisme
Hi, Vivaldi does not force anybody to anything, not even to use it.
You can disable auto update during the install of Vivaldi or later in the settings.
User create an account only to write such a post usually don`t answer.
Anyway, have a nice day, mib
@mib2berlin said in Unpacking Google's new "dangerous" Web-Environment-Integrity specification:
Pretty they were referring to Google not Vivaldi.
@LocutusOfBorg @Comissar
I responded from this statement:
"how do you get people to use your browser?"
I guessed our browser is Vivaldi, isn´t it?
@mib2berlin: He isn't talking about Vivaldi. It was a rhetorical question about Google's way of doing things.
@mib2berlin I'm shure he was referring to chrome and not Vivaldi.
@mib2berlin: I was talking about Google and their chrome browser. I love using Vivaldi.
@cashelgisme
Ah OK, then please excuse the misunderstanding.
Cheers, mib
Let's see how many more dirty tricks Google can come up with in its attempt to govern the internet and profile users.
@julien_picalausa, read the post:
Wow, honestly Google, now another way? I hope Vivaldi Browser can stop this.
About: "but so does reducing their market share."
It hard to do so when Vivaldi identifies itself as Google Chrome.
Maybe implement an auto-toggle or setting (who knows) to be Vivaldi and when site isn't cooperative, auto-switch to the fake Chrome id.
Or a setting that we can turn on to use real id so that those of us than can tolerate a bit more of this nonsense can id Vivaldi as Vivaldi.
Thanks for the writeup @julien_picalausa .
So how does Vivaldi strategically think if this is forced through in the Chromium upstream?
@777pirat If it is added upstream, vivaldi will just remove it. The code being added is not the problem here. The problem is if websites start to expect the proposed behaviour, then vivaldi may be impacted.
@LonM Totally agree - it's the standard proposed and expectations from "the web" which is the scary part. Just was curious if Vivaldi would oppose strategically by moving to another "core" than chromium.
@777pirat At this stage moving to a different core would be a monumental effort. And even if they did switch to something else, it wouldn't make a difference. Firefox will face the same questions as well if the proposal gains traction.
@lonm: This is exactly right. If websites start to enforce the presence of the API, then Firefox will have to implement it as well or disappear.
@777pirat said in Unpacking Google's new "dangerous" Web-Environment-Integrity specification:
Not feasible. It would take years.
I see Google planning something evil again..
@Stardust
maybe you'll find more browsers to move to.
maybe Vivaldi.
that was a joke. haha. fat chance.
monopolies are really great
when you're above the congress
Chromium devs commited this ugly "feature" Web-Environment-Integrity
https://github.com/chromium/chromium/commit/6f47a22906b2899412e79a2727355efa9cc8f5bd
via: https://blog.fefe.de/?ts=9a3fa96c
@DoctorG It's the Google/Chromium way - the Fast Track from "idea", completely bypassing standards bodies and committing an experiment into code. It will probably be hidden by a flag first for web devs to test, then enabled by default and and the flag removed.
Game Over, the Open Web lost.
Google can do what Google wants. It's their browser after all - and they control 70% of the browser market. It's about as close to a monopoly as it gets these days.
At the time of the US vs. Microsoft antitrust case in 2001, Internet Explorer had about 85% of the market. But with Chrome we are dealing with users who have actually chosen willingly (or been coerced by constant nags) to install a browser...
Powered by Vivaldi Forum • View original thread