- Mozilla is already publicly and officially opposed (https://github.com/mozilla/standards-positions/issues/852#is...), on principle ("Any browser, server, or publisher that implements common standards is automatically part of the Web") as well as on technical concerns around the safeguards and downsides of the proposal.
- WebKit is not committed to a position, but has mentioned several concerns (https://github.com/WebKit/standards-positions/issues/234):
"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. 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."
- Vivaldi is clearly opposed, per this blog post.
- Holdback as a mechanism is a weak defense against abuse. Some potential stakeholders are already suggesting to scrap holdback to support their use-cases (https://github.com/RupertBenWiser/Web-Environment-Integrity/...), leading to the possibility that it may not even be part of the final standard. Holdback is not technically enforced: a user agent can choose not to hold back, and if they are sufficiently popular they may induce web site operators to rely on their signal (at least for that browser) which would have the exact "DRM" effect that the proposal claims to avoid. The exact implementation of holdback matters a lot: if it's e.g. per-request, a site can simply ask repeatedly; if it's per-session or per-user, a malicious agent can pretend to be heldback the entire time.
- Since holdback is being touted as essentially the only defense against "DRMing" the web, it's a real mistake to have it be so poorly specified. The way it's currently specified makes it sound more like an afterthought than a serious attempt to mitigate harm.
- Compared to Private Access Tokens, WEI leaks far more information. WEI allows attesters to provide arbitrary metadata in their (signed) attestation verdict, whereas PAT tokens are fully opaque and blindly signed. Furthermore, PAT tokens can be in principle obtained through alternate attestation mechanisms (e.g. captcha, authentication, ...) without leaking the details of how that attestation is performed. WEI does not provide for this, and instead is designed around explicitly validating the "web environment".