What does HackerNews think of Web-Environment-Integrity?

  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.

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/...

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/...

1: https://news.ycombinator.com/item?id=36785516

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/...

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/...

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

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:

https://news.ycombinator.com/item?id=36875940

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/...