Unpacking Google’s new “dangerous” Web-Environment-Integrity specification

ruffsl@programming.dev to Programming@programming.dev – 167 points –
Unpacking Google’s new “dangerous” Web-Environment-Integrity specification
vivaldi.com

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.

12

You are viewing a single comment

The Firefox team responded saying that it's an awful idea and that plenty of people rely on being able to appear human, for example screen readers who need to interact as a human would but then translates it into a format their users can understand.

These propositions are just full of drawbacks for the user, the user actually gains nothing at all. Let's hope this rubbish doesn't take a foothold.

The biggest issue I see is not being able to block malicious scripts from running. An all or nothing approach is a terrible terrible idea.

Even if you were to diminish any valid reasons to not add this DRM feature, what are the actual reasons they think are pro consumer?

Harder for scammers/hackers iirc.

But this also makes it harder for devs to run tests.

How do you figure?

Saw some Google bootlicker on GitHub issues talking about how the policy will prevent a lot of automated stuff including bots and many hacker tools.