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

Reply via email to