Unpacking Google’s Web Environment Integrity specification

Very controversial take but I think this benefits the vast majority of users by allowing them to bypass captchas. I’m assuming that people would use this API to avoid showing real users captchas, not completely prevent them from browsing the web.

Unfortunately people who have rooted phones, who use nonstandard browsers are not more than 1% of users. It’s important that they exist, but the web is a massive platform. We can not let a tyranny of 1% of users steer the ship. The vast majority of users would benefit from this, if it really works.

However i could see that this tool would be abused by certain websites and prevent users from logging in if on a non standard browser, especially banks. Unfortunate but overall beneficial to the masses.

Edit: Apparently 5% of the time it intentionally omits the result so it can’t be used to block clients. Very reasonable solution.

> I think this benefits the vast majority of users by allowing them to bypass captchas.

I don't think it does that. Nothing about this reduces the problem that captchas are attempting to solve.

> i could see that this tool would be abused by certain websites and prevent users from logging in if on a non standard browser, especially banks.

That's not abusing this tool. That's the very thing that this is intended to allow.

The explicit goals are thus:

* Allow web servers to evaluate the authenticity of the device and honest representation of the software stack and the traffic from the device.

* Offer an adversarially robust and long-term sustainable anti-abuse solution.

* Don't enable new cross-site user tracking capabilities through attestation. Continue to allow web browsers to browse the Web without attestation.

From: https://github.com/RupertBenWiser/Web-Environment-Integrity/...

If it actually won't do any of those things, then that should be debated first.

Captchas are intended to stop bots. WEI is intended to vet that the hardware and browser has been validated. That doesn't impact bots, because you can implement bots on top of a valid hardware and browser so it will pass the WEI check.

I remember the discussions on Slashdot many years ago about the "analog hole"; you can have all the DRM you want, but people can still point a camera at the screen and record a non-encumbered copy that way. This is definitely the case with automating web activities; you take a trusted computer, point a camera at it, and have your bot synthesize keypresses and mouse movements. There is absolutely no way for a website at the other end of the Internet to know that a human is using the computer. (I see this as the "end game" for FPS cheating. I don't think anyone is doing it yet, but it's bound to happen.)

I'm guessing the reason we want attestation is so that Chrome can drop ad blockers and websites can drop non-Chrome browsers. But there is no reason why you can't do the thing where you point a video camera at a monitor, have AI black out the ads, and then view the edited video feed instead of the real one.

The only use for attestation I see is for work-from-home corporate Intranets. Sure, make sure that OS is up to date before you're willing to send High-Value Intellectual Property to the laptop. That... already works and doesn't involve web standards. (At my current job, I'm in the hilarious position where all of our source code is open-source and anyone on Earth can edit it, but I have to use a trusted computer to do things like anti-discrimination training. It's like opsec backwards. But, the attestation works fine, no new tech needed.)

> and have your bot synthesize keypresses and mouse movements

Is this truely going to work though? Captcha provider already monitor mouse and keyboard movement while on the page. Can you really "synthesize" human-like mouse movements around the page? I'm not so sure.