How Google’s Web Environment Integrity Proposal Could Change the Web

In July, four Google employees published on GitHub a proposal entitled Web Environment Integrity (WEI), a system that they claim will make the internet more secure and help ensure that users are who they say that they are.

To be clear, WEI is just a proposal at this phase. However, Google has been working on the implementation at least since April and a prototype is already available in Chromium, though not in Google Chrome or any other browser (Yet). 

The response to the proposal has been overwhelmingly negative. Vivaldi and Brave, two browsers that are also based on Chromium, have already said that they will not include WEI in their projects, citing privacy concerns as well as fears that it could harm the openness of the internet.

The criticism isn’t just coming from competing browsers. Journalists, such as Ron Amadeo at Ars Techinica, are referring to the new system as a “DRM Gatekeeper” and, according to an article by Thomas Claburn at The Register, developers are referring to it as a “freedom grab.”

However, Google seems determined to push forward with the system, defending the proposal on GitHub and elsewhere. As such, it’s likely that we will see at least some public testing of this system, making it worthwhile to take a moment and understand how it works and what it may mean for users and content creators alike.

The answer, it turns out, is both complicated and unclear.

How Web Environment Integrity Would Work 

Fundamentally, WEI is an attestation system. It creates a trusted third party to sit between the website and the user, ensuringto the website, app or service that the user is who or what they claim to be.

We already have something of a similar system when it comes to Secure Sockets Layer (SSL) certificates. Trusted entities, such as Let’s Encrypt, vouch for the authenticity of the certificates they issue, which are then used by user browser to verify the site that they are. This is how you get the green lock in your browser that lets you know the site is secure. 

However, where SSL certificates vouch for the site that the user is visiting, WEI would work the other way, vouching for the user to the website. 

The stated goal of this proposal is to separate the humans from the bots. By attesting to the authenticity of the device, the authors hope that this will help keep bots out and also do things such as reducing cheating in online games, mitigating bot manipulation of social media and even help users avoid being hacked by malicious software.

While all that sounds great, the problem is in the implementation. Right now, all the WEI API gives to the website is a yes or a no. Yes, we authenticate this user or no, we do not. However, the proposal is very early in development and details are very sparse. There is an open question to what signals, if any, WEI would include beyond that yes or no.

But, even if the end product is just a thumbs up or thumbs down, there are a slew of unanswered questions. What standard makes one an authentic user? Who will decide what users are authentic and which are not? How will sites and apps decide which attestation services are to be trusted?

The first question could be particularly thorny. For example, an attester could refuse to authenticate any user with an ad blocker or privacy-protection tool installed. Taking it even farther, attesters could, theoretically, just refuse to authenticate users on certain browsers or operating systems.

Since websites and apps would be able to choose which attesters they trust, they could require an attester that verifies the lack of an ad blocker, not trusting those that don’t examine those issues.

Finally, there’s the serious questions about privacy between the user and the attester. Any process here is going to involve a detailed examination of the user’s system. That makes the attester a potential reservoir of personal information and raises questions about what information should be passed on to the site or app that is requesting authentication. 

In short, as Julien Picalausa at Vivaldi put it, the details of the proposal are “nebulous” and that makes it difficult to discuss what the proposal would actually do, just what it COULD do.

Potential Impacts on Copyright

When detractors describe WEI as DRM for the web, they’re not wrong. Theoretically, it’s a tool that could be used to restrict access to copyright-protected works by applying a set of standards the user must meet.

To that end, there are obvious benefits for content creators, those include:

1. Blocking Bots: Blocking bots has long been a cat and mouse game, bot blocking a key feature of many content delivery network services. This could help websites separate the humans from the bots and better protect their content.
2. Reducing Piracy: WEI could prevent access by users with screen or audio recording software to prevent streaming piracy. It could also verify that the viewer is human, helping to ensure that view counts are accurate and avoiding wasted bandwidth on bots.
3. Blocking Access to Unwanted Visitors: Finally, websites would have greater control over which visitors they do or do not allow. In addition to blocking bots, it could be used to prevent ad blockers from accessing the site, which is already a cottage industry on the web, deny access to people using virtual private networks and prevent people from accessing it on certain browsers or operating systems.

However, those benefits come at a pretty high cost.

First and foremost, no matter how it is implemented, it will never be perfect. It will allow some of the unwanted users through and block desired users. False positives and false negatives are unavoidable. 

Second, for the system to work, it will need widespread adoption. However, that’s looking unlikely as some browser makers have already outright rejected it. Because of this, using such a system would mean excluding those who don’t or can’t participate in it, likely to be a significant percentage of the web.

Finally, the burden placed on the user is incredibly high. The potential privacy issues alone are enough to make many wary, but requiring that they use a particular browser or attester is a perceived added cost that, even if users are willing to meet, they will not be happy about it.

In short, the alternatives for the system are basically to either weaken it and limit its effectiveness, or pass on a high burden to users, who unilaterally have to take risks and make changes that are largely for the sole benefit of webmasters and rightsholders.

Bottom Line

To be clear, there are potentially useful cases for a system like this one and the use cases listed in the original proposal are good examples. 

In anything involving financial or personal data, it makes sense to verify both the user and the site. This provides real benefits to users as well as the sites they’re visiting.

However, most applications on the internet aren’t that security-intensive. Where the risks of a bank account intrusion are carried by both the bank and the user, those risks become unilateral when you start talking about streaming sites or just regular sites on the public internet.

As we talked about way back in 2010 and then again in 2012, DRM itself is rarely the problem. Systems like Steam show that DRM can be popular and loved, as long as they create benefits for users.

That, in turn, is the question when it comes to WEI. What does the user gain? While fewer bots on social media sites and rightsholders better able to exploit their work are real benefits that may, in the long run, help users, they’re also abstract, and those benefits are far from certain.

If WEI is to gain any traction, it needs to be more than something that is forced upon users. It needs to protect both the idea of an open internet, but also provide real benefits to the users who do choose to participate. 

That is the difference between creating a system that people flock to join versus one they flock to avoid.