> This seems to create a large power for site owners to dictate & control user behavior.
I want to be forthright in saying that I have the same concerns. For this reason, it is an explicit goal in the explainer to "Continue to allow web browsers to browse the Web without attestation." (ref <https://github.com/RupertBenWiser/Web-Environment-Integrity/blob/main/explainer.md#goals> ). This is of course easier said than done. One idea is to introduce a holdback mechanism (ref <https://github.com/RupertBenWiser/Web-Environment-Integrity/blob/main/explainer.md#holdback>) that only allows a portion of traffic to be attestable so that web developers are not able to enforce any particular request on the attestation verdicts. In the rooting example, this would ensure that a web author could not prevent you from browsing without also locking out a sizable number of potentially attestable (but held back) users. Regarding how this addresses user needs, I think there are many legitimate reasons why users do not want fraud on the services they use. For example, fake engagement can be used to promote spam and disinformation to unsuspecting users. In other cases, real users may compete to buy concert tickets, but lose out to innumerable instances of fake users. There are a few more examples in the explainer’s introduction (ref <https://github.com/RupertBenWiser/Web-Environment-Integrity/blob/main/explainer.md#introduction> ). Another user-facing consideration is that these same inferences are made today using highly identifiable information from the browser, and inadvertently allow for widespread tracking of users. Given the deprecation of third party cookies and other privacy efforts, we recognize an urgency to create a well-lit path for anti-fraud use cases that does not rely on widespread collection of re-identifiable signals. My north star is for these existing approaches to be dropped for a more reliable, and more private alternative. On Friday, May 12, 2023 at 7:50:51 AM UTC+1 Morgaine (de la faye) wrote: > > This can be sent to websites’ web servers to verify that the environment > the web page is running on is trusted by the attester. > > > I'm not sure how RFC 8890 compliant this proposal is. This seems to create > a large power for site owners to dictate & control user behavior. But RFC > 8890 says that The Internet Is For End Users. This seems to work against > that. > > From the explainer: > > For example, this API will show that a user is operating a web client on > a secure Android device. > > As a user with a rooted phone, it would be highly upsetting & disturb my > ability to use the web if you were to create this feature & allow me, a > legitimate user, to be locked out of pieces of the web. Trying to narrow > down the computing world to only run on attested hardware is the definition > of the War Against General Purpose Computing, and it much discussed in > intelligent circles as the worst possible dystopian hell that can be > brought against users. I hope this feature is abandoned, and if not, I hope > it is quickly & readily subverted. This is an indignity to introduce > against users. > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1e2f3a79-3e73-4994-bcbd-40388e1ed64an%40chromium.org.