NOTE: This proposal is no longer pursued.
Thank you for all the constructive feedback and engagement on the topic. An Android-specific API that does not target the open web is being considered here.
The android specific proposal is only adding support for it to WebView, which developers actually could already by combining the WebView and play integrity APIs, so that as much as I don't love it that doesn't seem too terrible if it is just saving developers from writing some boilerplate code to connect the two. Here is the recent discussion about the WebView changes https://news.ycombinator.com/item?id=38118627>> NOTE: This proposal is no longer pursued.
[0]: https://github.com/RupertBenWiser/Web-Environment-Integrity
First let me add some snippets on what the authors of WEI think can be gained from it:
* This is beneficial for anti-fraud measures. Websites commonly use fingerprinting techniques to try to verify that a real human is using a real device[1]
One of the proposed use cases: Detect non-human traffic in advertising to improve user experience and access to web content* [2]
Another snippet :
we could standardize the set of signals that browsers will receive from attesters, and have one of those signals be whether the attester recommends the browser for sites to trust (based on a well-defined acceptance criteria). As new browsers are introduced, they would need to demonstrate to attesters (a relatively small group) that they pass the bar, but they wouldn't need to convince all the websites in the world [2]
This is clearly an attempt at gatekeeping both web client software and the clients themselves.
> What do they gain from it?
I think we can agree that Google is primarily an advertising and search company. One of the threats to Google's revenue as an advertising company is ad-fraud and this 'anti-fraud' measures protect their bottom-line. Another threat is ad-blocking and though they don't explicitly mention it, the WEI "bar" mentioned above can potentially be used to prevent ad-blocking by denying attestation to clients capable of ad-blocking (either directly or by allowing plugins).
Client attestation also prevents bots(both good & bad bots of all types including new search indexing bots) from accessing websites. This has a nice side-effect for Google that it restricts building a new search engine(a competitor) without its blessing. Search is a gateway to Google's advertising.
> And why exactly do you think they'd want to do that?
Like any product that any company introduces, it is to drive adoption? The more websites use it, the more normalized and legitimate WEI becomes. Once it becomes a standard and an integral part of web, it is easier to dictate terms that keep their position entrenched.
We can argue whether ad-blocking or bots are good or not and whether these concerns are all pure speculation or hyperbole. But once the technical capability is there and it is only the ethical/moral belief of corporate executives( and probability of government intervention) that prevent it, I wouldn't trust them to do the right thing especially when money is involved.
[1] - https://groups.google.com/a/chromium.org/g/blink-dev/c/Ux5h_...
[2] - https://github.com/RupertBenWiser/Web-Environment-Integrity/...
https://github.com/RupertBenWiser/Web-Environment-Integrity/...
Explicit non-goals for WEI:
"Enforce or interfere with browser functionality, including plugins and extensions."
https://github.com/RupertBenWiser/Web-Environment-Integrity/...
""" Attester-level acceptable browser policy If the community thinks it's important for the attestation to include the platform identity of the application, and is more concerned about excluding certain browsers than excluding certain OS/attesters, we could standardize the set of signals that browsers will receive from attesters, and have one of those signals be whether the attester recommends the browser for sites to trust (based on a well-defined acceptance criteria). As new browsers are introduced, they would need to demonstrate to attesters (a relatively small group) that they pass the bar, but they wouldn't need to convince all the websites in the world. """
In other words, they realise it's infeasible for sites to keep up with new browsers and figure out whether to trust them. This is an implicit whitelist (I believe the preferred term is allowlist) because each site would have to keep a list of attested "platform identities" that they trust.
Instead, in the above paragraph, Google proposes that new browsers demonstrate to Google that they are worth attesting, and then Google will get the attester to say "Additionally, as the Google attester, I trust this browser". This is an explicit allowlist.
In other words, if you want to write a new browser, or fork an existing browser, or write or a site scraper, or whatever else, you either have to convince every site using WEI in the world to trust you, or you have to convince Google to trust you. Both methods involve an allowlist.
To use your example, as a Web admin, you wouldn't get information like "forges user agent". You would get a signal like "Genuine Chrome running on unrooted stock Android" (the attestation), plus "Google's attester recommends this browser for sites to trust" (the extra signal proposed by the paragraph I quoted above).
If you use the former signal, you have an explicit allowlist on your site. If you use the latter signal, you are relying on Google's allowlist.
Read the proposal: https://github.com/RupertBenWiser/Web-Environment-Integrity/...
>That's settled then. Full filesystem, location, camera, and microphone access should therefore come on by default without a permission dialog. Why not bring back Java and Flash while we're at it! It's not the browser vendor's fault that websites are misusing it.
Now who is arguing in bad faith? if you have read the proposal, it's clear that they are being careful and are upfront about the some potential misuses and the proposed handing of them.
> to verify that your system is using a Google-approved bootloader to load a Google-approved operating system which only loads Google-approved drivers and Google-approved software (or worse, website-approved software).
again there is no such thing proposed. The "attester" is not specifically Google. anyone can become an "attester". The chain of trust is a chain that trusts tokens not specific "things". if you for example would trust let's say Opera as the attester, Opera would need to trust windows or Linux or Android as the OS attester.
The analogy here is the certificate Authorities. You may very well have a "let's encrypt" attester that democratizes the good parts (certification) without the bad parts (too much information) .
I didn't see many people debating the actual text of the WEI explainer[0] on the HN posts about WEI, and that's probably because they were links to articles about WEI. The HN post for the explainer with the most upvotes only has 89[1], likely because most of HN treats the upvote as "I agree/like this" instead of "boost this topic for discussion".
0: https://github.com/RupertBenWiser/Web-Environment-Integrity/...
to play the devil's advocate, this is why google proposed the WEI (https://github.com/RupertBenWiser/Web-Environment-Integrity/...). Be careful what you wish for...
The first example in the WEI doc is enforcing that ads are viewed by humans: https://github.com/RupertBenWiser/Web-Environment-Integrity/...
https://github.com/mozilla/standards-positions/issues/852 https://github.com/RupertBenWiser/Web-Environment-Integrity/...
I stopped reading after the explainer’s intro section. The first example is making it easier for websites to sell adds (lmao) and the other 3 are extremely questionable whether if the proposed remedy even helps. And it’s presented as a benevolent alternative to browser fingerprinting, as if we must choose between these two awful choices. It’s an absolute joke of a proposal.
Google's PR strategy is to say "no need to worry, it's just like this Apple thing". But as Google themselves note in their explainer¹, they're quite different, and Google considers PAT insufficient for the kind of enforcement they intend to do.
For example, PAT is ultimately just "not a bot" attestation and so doesn't involve the exchange of device and browser environment data. In contrast, WEI needs that data to enable the kind of "DRM for the web" use cases we're reading about.
https://github.com/RupertBenWiser/Web-Environment-Integrity/...
Pass
> Token or NFT sales
Pass
>Voting in DAOs
Pass
>A way to "seed" graph-based reputation systems Quadratic voting
Pass
>Protection against bots / sybil attacks in social media >An alternative to captchas for preventing DoS attacks
Hmmm, those are probably the real reasons behind all of that, it is just the bullet-proof way to de-anonymize the internet users, and building a database that can be purchased later for billions by other entities, ones that likes to “end the captchas” aka web environment integrity [1], or the ones who buy it to force serving ads regardless of any ad blockers and having a fully detailed profile about you, or the ones who integrate that identity to their fingerprinting services, or the ones who will use to “fight misinformation” aka opinions doesn’t align with our narrative, or the ones who will integrate it to social media signup process or votes [2], or the ones will add it to their electric cars, and the list goes on I could write a book how’s that a horrible bad evil idea. It’s all power and control game, The article tries to list ways to protect and prevent such cases, but we all know it won’t be applied as the motivation is against that, luring people for the $20 is just the bait, literally a bait.
[1] https://github.com/RupertBenWiser/Web-Environment-Integrity
[2] in the article itself “If proof of personhood is not solved, decentralized governance (including "micro-governance" like votes on social media posts)”
I'm not really seeing how we're reaching that conclusion. Suppressing GET request noise isn't any of the use cases described at https://github.com/RupertBenWiser/Web-Environment-Integrity/...
a galactic irony that Ben Wiser, the Googler who posted this proposal, has a blog where his most recent post is a rant about how he's being unfairly restricted and can't freely run the software he wants on his own device.
https://benwiser.com/blog/I-just-spent-%C2%A3700-to-have-my-...
https://github.com/RupertBenWiser/Web-Environment-Integrity/...
And here's why it may be bad:
https://vivaldi.com/blog/googles-new-dangerous-web-environme...
And the HN discussion on the latter:
- 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".
The page must first load, then it requests an attestation using js and sends it back to the server for further use (like a recaptcha token).
So for something like curl it could be no change.
https://github.com/RupertBenWiser/Web-Environment-Integrity/...
> As new browsers are introduced, they would need to demonstrate to attesters (a relatively small group) that they pass the bar,
Good luck with that.
> Stakeholder feedback / opposition
> [Implementers and other stakeholders may already have publicly stated positions on this work. We will list them here with links to evidence as appropriate.]
> [Implementor A] : Positive
> [Stakeholder B] : No signals
> [Implementor C] : Negative
Google, W3C, Apple|Mozilla?