Request for Position: Web Environment Integrity API

[gacelperfinian]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Web Environment Integrity API
• Specification or proposal URL (if available): https://rupertbenwiser.github.io/Web-Environment-Integrity/ (spec), https://github.com/RupertBenWiser/Web-Environment-Integrity/ (repo)
• Explainer URL (if available): https://github.com/RupertBenWiser/Web-Environment-Integrity/blob/main/explainer.md

Other information

Chromium's propotype is currently relying on Play Integrity (https://developer.android.com/google/play/integrity), but the specification is clear that it is vendor-neutral. However, I have personal concerns since that while EME in theory is vendor-neutral, in practice there is only three vendors which are widely-recognized: Google Widevine (which is used by Firefox in most platforms plus in Chrome and Android), Microsoft PlayReady (used by Microsoft Edge and Windows plus in some Android devices alongside Widevine), and Apple FairPlay (used in Safari and everything Apple).

It is reasonable that the current situation in EME would translate into this specification. This may hinder users of other browsers since while in theory websites would just try to verify the identity by other means in practice this would lead to websites requiring pre-approved browsers.

[teh-maxh]

While such a "feature" would be great marketing for Firefox, I still think it should be opposed.

[Zipdox2]

This API offers nothing to the end user, and can only be used to restrict the user. It is not in users' interests to implement it.

Furthermore, this specification is vague and the underlying mechanism is unclear.

[bgrins]

Mozilla opposes this proposal because it contradicts our principles and vision for the Web.

Any browser, server, or publisher that implements common standards is automatically part of the Web:

Standards themselves aim to avoid assumptions about the underlying hardware or software that might restrict where they can be deployed. This means that no single party decides which form-factors, devices, operating systems, and browsers may access the Web. It gives people more choices, and thus more avenues to overcome personal obstacles to access. Choices in assistive technology, localization, form-factor, and price, combined with thoughtful design of the standards themselves, all permit a wildly diverse group of people to reach the same Web.

Mechanisms that attempt to restrict these choices are harmful to the openness of the Web ecosystem and are not good for users.

Additionally, the use cases listed depend on the ability to “detect non-human traffic” which as described would likely obstruct many existing uses of the Web such as assistive technologies, automatic testing, and archiving & search engine spiders. These depend on tools being able to receive content intended for humans, and then transform, test, index, and summarize that content for humans. The safeguards in the proposal (e.g., “holdback”, or randomly failing to produce an attestation) are unlikely to be effective, and are inadequate to address these concerns.

Detecting fraud and invalid traffic is a challenging problem that we're interested in helping address. However this proposal does not explain how it will make practical progress on the listed use cases, and there are clear downsides to adopting it.

[tantek]

Thanks @bgrins for this summary write-up. Per this analysis I’m going to label our position on this proposal as negative.

Since this is a proposal in a personal GitHub repo, and not standards track work nor in any open incubation group, there is no need for a dashboard entry. Closing accordingly.

(Originally published at: https://tantek.com/2023/205/t1/)

[pglpm]

The API proposal mentions the "user" a lot. Has anyone actually asked real users and collected any statistics?

I actually am a user and I don't want this nor do I find it useful. They shouldn't try to deceive me saying that this is "for me", when it actually isn't.

[pax-k]

So they actually borrow ideas from Decentralized Identifiers / Verifiable Credentials and want to force adoption by building this tech into the browser. Obviously Google's intent is to monopolize & profit, and less about "privacy", "user security", etc, which are just facade words.

[abdul]

Mozilla opposes this proposal because it contradicts our principles and vision for the Web.

Any browser, server, or publisher that implements common standards is automatically part of the Web:

Standards themselves aim to avoid assumptions about the underlying hardware or software that might restrict where they can be deployed. This means that no single party decides which form-factors, devices, operating systems, and browsers may access the Web. It gives people more choices, and thus more avenues to overcome personal obstacles to access. Choices in assistive technology, localization, form-factor, and price, combined with thoughtful design of the standards themselves, all permit a wildly diverse group of people to reach the same Web.

Mechanisms that attempt to restrict these choices are harmful to the openness of the Web ecosystem and are not good for users.

Additionally, the use cases listed depend on the ability to “detect non-human traffic” which as described would likely obstruct many existing uses of the Web such as assistive technologies, automatic testing, and archiving & search engine spiders. These depend on tools being able to receive content intended for humans, and then transform, test, index, and summarize that content for humans. The safeguards in the proposal (e.g., “holdback”, or randomly failing to produce an attestation) are unlikely to be effective, and are inadequate to address these concerns.

Detecting fraud and invalid traffic is a challenging problem that we're interested in helping address. However this proposal does not explain how it will make practical progress on the listed use cases, and there are clear downsides to adopting it.

I guess, even if " it contradicts our principles and vision for the Web.", it might happen just like the past:

• https://hacks.mozilla.org/2014/05/reconciling-mozillas-mission-and-w3c-eme/
• Formal objection: FLOSS and EME w3c/encrypted-media#378
• https://daniele.tech/2014/05/firefox-drm-and-w3c-eme-complicated-technical-matter/

[pglpm]

@abdul It might. Yet please let's fight. Every epoch is unique. And a fight not fought is automatically lost.

[JohnCoconut]

Though I've disagreed with Mozilla's decisions or directions in the past, today I am very grateful for Mozilla's objection towards "Integrity API". I couldn't imagine the future of web if proposal like this getting accepted and implemented.

Just donated $100 to Mozilla.

[martinthomson]

Thanks for your contributions everyone, but I think we're straying a little bit off topic.