The Web Environment Integrity is yet another Google proposal for making the web worse for everyone but them.
Links of interest:
Issues with the RFC
Request For Comments, a nice way to make proposals and ask for comments and feedback. Well, usually when one comes out it's at least polished enough to feel like a complete unit.
As of today, very crucial and important parts of the RFC are marked as "TODO". Things like, you know, definitions of "web environment" and "content binding", nothing that important /s.
Hell, even whole sections are missing like "Browser Acceptance Criteria" and "Privacy considerations" which gives off strong "I'll leave the morality of it out of the talk" vibes (no that is not a parody, it's an actual serious talk, you should definitely check it out).
The biggest issue with the RFC is, if you're like me, the first time you read this and looked at the API you certainly thought: "wow... that's actually useless":
- Craft a token and... encode it in base64? No asymmetrical encryption? Just Base64? Wth!?
- Cool, but how can it be verified?
- The token is crafted on the user's device and verified on another?
- What is the use exactly?
- What prevents it from being spoofed or polyfilled?
- This is to fight against fingerprinting? But that introduces a wayyyy better way of fingerprinting users, on a literal MAC address/machine level
- You can't remove the need for an anti-virus software on each machine
- Making a "web anti-virus solution" is the single dumbest and most useless idea ever! Sure let's give any website a way to inspect (the integrity of) your memory, that sounds like a great idea!
And of course, these questions are absolutely not addressed in the RFC. All you can read is something that feels like someone's draft of an RFC (that needs to be finalized before being published), not an actual RFC. Which probably means that whoever was behind this idea thought of it last minute and pushed it way too hard to have it go out ASAP.
And with the explainer, all the evil is unveiled
You see, before reading the explainer (which is dumb, why external explanation for an RFC) you were already thinking about how this is terrible, a DRM-ization of the web, etc.
But within the first few lines of the explainer, you actually understand that one of the main goals of this is absolutely not to protect users in any way, but to make sure ads are shown to real users and never bots.
It's pretty much a Comic book Villain (or politician) tactic: pretend to do things for others' interest, but in reality you do them for your own.
Goals
Allow web servers to evaluate the authenticity of the device and honest representation of the software stack and the traffic from the device.
That's a mouthful way of saying "we want website to be able to very accurately fingerprint your device". How's the EU doing btw?
Offer an adversarially robust and long-term sustainable anti-abuse solution.
Now that's just absurd and wishful thinking at best. There's a reason anti-virus and anti-cheat software run at system startup and in a different "context" than other programs... You can't do that from inside a web browser.
Plus, that would only cover mid-execution corruption. You couldn't detect prior-to-execution corruption like, let's say, a computer full of malware?
Don't enable new cross-site user tracking capabilities through attestation.
Sure, try to act like you won't use that in GA or GTM at all. How's the EU doing btw?
Continue to allow web browsers to browse the Web without attestation.
Oh thank god, you actually admit yourself that your proposal is a waste and totally useless since you can just skip it...
"Non-goals"
Enforce or interfere with browser functionality, including plugins and extensions.
Oh I'm sure it won't interfere...
In addition to Manifest V3, you'd also like to further kill extension/plugin users and developers? Wow. You really hate adblockers huh? Despite them being a minority in the vast user base? Are you looking for pennies under the couch Google? I have 4 bucks in my pocket if you want.
Enable reliable client-side validation of verdicts
Yes, "reliable client-side" the famous oxymoron. Thank you for "clarifying" that. I hope Google doesn't connect to their production databases directly from the browser...
Access to this functionality from non-Secure Contexts.
What do you not get about "non-Secure"? Are you serious?
Use cases
Detect social media manipulation and fake engagement.
So it's not about users. Got it. And how do you plan on doing that exactly?
Detect non-human traffic in advertising to improve user experience and access to web content
So it's not about users. Got it. And how do you plan on doing that exactly? I'm pretty sure I can make Selenium do things and it'd go through your wide net.
Detect phishing campaigns (e.g. webviews in malicious apps)
How exactly?
Detect bulk hijacking attempts and bulk account creation.
How? Oooooh, by fingerprinting of course!
Detect large scale cheating in web based games with fake clients
See the above about execution contexts of anti-cheat and anti-virus software...
Detect compromised devices where user data would be at risk
There's no reason a malware-infested system couldn't spoof that. It's not an anti-virus...
Detect account takeover attempts by identifying password guessing
Literally how? Do you have any idea of the intrinsic unsolvability of the problem you claim this would solve? Why do you think 2FA/MFA exist? Google literally has one of the strictest ones out there, how do you fain ignorance like that?
Does the explainer, explain or address anything?
No lmfao. Read it for yourself, it's pretty funny how it makes everything worse than the RFC already did.
The final words
You cannot circumvent the Blind Trust Issue. (i.e. the fact that any trust is always blindly given, otherwise it'd be knowledge)
Hell, the whole thing relies on a 3rd-party attester which is an even bigger joke in and of itself.
It's not even like HTTPS, DNS Sec, or whatever intelligent and well thought out security thing. That one is just useless junk if you're not Google Ads.
The only way to circumvent the Blind Trust Issue is to turn trust into knowledge, that much is obvious. The only issue is that you can't have knowledge about a site being compromised (e.g. downloading a renowned browser), that your IP packets are not being intercepted (network layer), that your TCP packets are not being logged or intercepted (ISP), that your machine doesn't have spyware built into the OS, that the software you use is what it's advertised as (that's why we need reproducible builds), etc...
It's the same thing with "Decentralized Web". You don't eliminate the need for trust at all, you just move it elsewhere.
Top comments (4)
Let's be honest. The main uses of this tech will be things like
And by "proving" those things, what I mean is your next android phone will have a google key on some HSM that will only attest google-approved browsers and won't be usable from a rooted phone.
This is just another attempt at ensuring users don't own their hardware anymore.
Most definitely. One could also think their goal is to limit access to those who don't interact much with ads, while making those who do have a very pleasant and ad-filled experience.
Its so nice to read someone else talking about how transparently dishonest Google is about all its "ideas" for "better security" that are just ways to stiffle its competition.
Any hey, better comply, wouldn't want your website effectively vanish from the web by slipping to page 2 of the Google Results now!
Thank you for bringing this all to light.