Web Environment Integrity API

jxxe commented 1 year ago

WebKittens

No response

Title of the spec

URL to the spec

https://rupertbenwiser.github.io/Web-Environment-Integrity/

URL to the spec's repository

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

Issue Tracker URL

No response

Explainer URL

https://github.com/RupertBenWiser/Web-Environment-Integrity/blob/main/explainer.md

TAG Design Review URL

No response

Mozilla standards-positions issue URL

https://github.com/mozilla/standards-positions/issues/852

WebKit Bugzilla URL

No response

Radar URL

No response

Description

Quoting @gacelperfinian:

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.

lukewarlow commented 1 year ago

This is just my perspective on potential concerns labels that could be added, it in no way represents the official position.

(Read DRM to mean the platform attestation system not sure if it's truly DRM)

Based on the concerns label I think this would fall under

"annoyance": Preventing a user from using a certain browser is pretty annoying.
"device indepedence"?: If it's reliant on underlying DRM tech that limits the OS availablity.
"interopability": An effective reliance on existing DRM tech would limit all browsers from being interopable as some may not be able to use / may not want to use DRM tech.
"portability": I'm unsure on the Linux aspect of this (haven't looked too deep into if this is implementable)
"usability": If some browsers are excluded
"use cases": While the motivations are explained it's unclear to me that there's an actual need for this API. The status quo (the alternative) seems to have plenty of online games and social media websites. There appears to be very limited to none benefits to the users of any USER agents that implement this.
"venue": Personal repo

mcatanzaro commented 1 year ago

I think this would eliminate not just WebKit ports, but also Linux web browsers in general. We do not have attesters and cannot build them. Websites would never trust them if we did.

Don't think there's much need to debate this one....

othermaciej commented 1 year ago

We have Private Access Tokens (aka Privacy Pass) for some of the claimed use cases of this spec. We think it's a more privacy-respecting solution. The Explainer isn't very clear on why specifically Web Environment Integrity is better. It mentions a feedback mechanism, but not the specific mechanism. It also exposes more info to the page.

othermaciej commented 1 year ago

The Explainer claims this spec is necessary because Privacy Access Tokens don't support feedback from websites on false positives / false negatives, however, neither the spec nor the explainer include a feedback mechanism. Without more specifics, we would not be enthusiastic about duplicating an existing standards-track solution for the same use cases.

othermaciej commented 1 year ago

Doesn't seem implementable on platforms that lack a trusted attestation mechanism.

othermaciej commented 1 year ago

Doesn't seem great to do something this potentially controversial in a personal repo rather than a recognized standards or incubation group.

cybik commented 1 year ago

Doesn't seem great to do something this potentially controversial in a personal repo rather than a recognized standards or incubation group.

Forgive me for the opinion, but I'm assuming they did it this way for a reason.

martinthomson commented 1 year ago

There is an important point to make about Private Access Tokens here. There is a substantial difference in terms of the scope of the assertions that are made here and some real advantages to having used Privacy Pass.

However, there are also fundamental similarities. Private Access Tokens currently assert a single bit that might approximate to "paid Apple $1000", which is not ideal. However, that's not an essential property of the signal. @tfpauly and others are actively engaged in a discussion about how that particular signal might be generalized in a way that is less problematic.

tfpauly commented 1 year ago

Indeed. The goal for the signal for privacy pass is one bit that says "this is some user my token issuer trusts" which should ideally be defined as (has a legit iPhone || has a legit android || has an account signed in || solved a captcha before and has an IP that is trusted || many other things).

The main point here is that the bit of information is abstracted from what went into getting the bit, and can expand and change to include a much broader set of platforms, including open platforms.

xacky commented 1 year ago

Private keys leak all the time from organizations, it will be inevitable that a rogue attestor will be made to let bots and spammers through, it only needs to happen once.

UInt2048 commented 1 year ago

Mozilla already has a negative position: mozilla/standards-positions#852

I hope WebKit takes a negative position as well, for those reasons, and for the continuation of my WebKit fork.

johnwilander commented 1 year ago

Why are we asked to comment on a proposal in a personal repo? We have web incubation groups with rules of commitment on intellectual property, how we treat each other, and fundamentals for what the web is about. Please move to a standards group.

nschonni commented 1 year ago

@johnwilander neither this issue or the Mozilla requests were opened by Google employees or the people working on those specs

johnwilander commented 1 year ago

@johnwilander neither this issue or the Mozilla requests were opened by Google employees or the people working on those specs

Thanks! It's unfortunately hard to see/know account affiliation too.

Cuteistfox commented 1 year ago

i think it is bad it is a DRM for the web

lukewarlow commented 1 year ago

As per comments in the chrome intent to prototype and seen here https://android-developers.googleblog.com/2023/11/increasing-trust-for-embedded-media.html?m=1 this proposal is no longer being pursued.

WebKit / standards-positions