Controversy Swirls Around Google API, Accused of Granting Excessive Control to Site Owners

Google's proposed Web Environment Integrity API has ignited a heated discussion in the developer community, with concerns over privacy and potential misuse. According to an ongoing discussion between Google engineers and developers, the stakes and consequences of this development are being seriously considered.

A forum participant 'Morgaine (de la faye)' previously expressed concerns about the proposed API, arguing that it may grant too much power to site owners, potentially infringing upon the rights of Chrome users. Morgaine mentioned the risks for users of rooted Android devices who might find themselves unfairly locked out of certain websites or functionalities. They referred to RFC 8890, stating, "The Internet Is For End Users," implying that the proposed API might contravene this principle:

"I'm not sure how RFC 8890 compliant this proposal is. This seems to create a large power for site owners to dictate & control user behavior. But RFC 8890 says that The Internet Is For End Users. This seems to work against that."

Further adding:

"As a user with a rooted phone, it would be highly upsetting & disturb my ability to use the web if you were to create this feature & allow me, a legitimate user, to be locked out of pieces of the web. Trying to narrow down the computing world to only run on attested hardware is the definition of the War Against General Purpose Computing, and it much discussed in intelligent circles as the worst possible dystopian hell that can be brought against users. I hope this feature is abandoned, and if not, I hope it is quickly & readily subverted. This is an indignity to introduce against users."

Ben Wiser, the original author of the proposal and a software engineer at Google, responded directly to these concerns. He acknowledged the potential for misuse, affirming that one of the explicit goals of the proposal was to allow web browsers to browse the Web without attestation:

"I want to be forthright in saying that I have the same concerns. For this reason, it is an explicit goal in the explainer to "Continue to allow web browsers to browse the Web without attestation."

Wiser suggested the implementation of a holdback mechanism, which would restrict only a portion of traffic to be attestable. This could help to ensure that web developers could not enforce attestation verdicts, potentially barring legitimate users from accessing content:

"This is of course easier said than done. One idea is to introduce a holdback mechanism that only allows a portion of traffic to be attestable so that web developers are not able to enforce any particular request on the attestation verdicts. In the rooting example, this would ensure that a web author could not prevent you from browsing without also locking out a sizable number of potentially attestable (but held back) users."

He noted that there are many valid reasons why users would want to limit fraud, such as combatting spam, disinformation, and unfair competition for services like ticket purchases:

"Regarding how this addresses user needs, I think there are many legitimate reasons why users do not want fraud on the services they use. For example, fake engagement can be used to promote spam and disinformation to unsuspecting users. In other cases, real users may compete to buy concert tickets, but lose out to innumerable instances of fake users. There are a few more examples in the explainer’s introduction."

Wiser also pointed out that such inferences are currently made using highly identifiable information from the browser, contributing to widespread tracking of users. As third-party cookies are being phased out and other privacy efforts advance, he sees an urgent need for a more private alternative to prevent fraud:

"Another user-facing consideration is that these same inferences are made today using highly identifiable information from the browser, and inadvertently allow for widespread tracking of users. Given the deprecation of third party cookies and other privacy efforts, we recognize an urgency to create a well-lit path for anti-fraud use cases that does not rely on widespread collection of re-identifiable signals. My north star is for these existing approaches to be dropped for a more reliable, and more private alternative."

Also Read

Google Engineers Propose New "Web Environment Integrity" API for Chrome Browser