RFC 8890 Compliance

[rektide]

Hello. I'm very concerned about this specification.

For example, this API will show that a user is operating a web client on a secure Android device.

This for example says that me, who has a rooted phone that I enjoy, would be locked out of the web. This seems like a pretty bold & infernal twist to the world, that user's can only use computers that they cannot control to access the web.

This specification defies the broadly known & accepted RFC 8890, The Internet is For End Users. https://datatracker.ietf.org/doc/html/rfc8890 It is creating a system which, instead of being "user-focused", locks out users, instead preferring to give sites the ability to shape & define. There is big "negative end-user impact" to these changes, in that only limited classes of computing will be able to participate on these parts of the web.

[rektide]

See #14 and #15 for related topics of concern.

[RupertBenWiser]

Thanks for opening this @rektide. I agree that we don’t want to lock down the web to particular devices. An explicit goal of this proposal is "Continue to allow web browsers to browse the Web without attestation." due to the concern over locking out users based on their devices and software.

I believe that there is a definite user need the explainer is attempting to solve. Popularity rankings can be manipulated by fake engagement, users trying to purchase concert tickets are outcompeted by innumerable bots, to name two examples. There are a few more examples in the 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.

Anti-fraud companies help protect against things like fake engagement but today’s data-hungry approaches may also give cover to widespread tracking, as the signals may be freely re-purposed once collected. My north star is for these existing approaches to be dropped for a more reliable, and more private alternative.

Protecting the experience of users with unattestable devices is the kind of problem the hold back proposal is trying to solve. The idea is that the hold-back would prevent developers from being able to enforce this capability on any particular network request, but it would allow developers to still look at the overall traffic and see if there is anything fishy. Eg: Why does today’s top article have a disproportionately low proportion of traffic from attested devices?

There should hopefully be an issue with more options regarding the hold back (and similar proposals) that I can share soon. I’ll be sure to link it back to this issue.

I think voices like yours will be critical in countering fraud, while keeping the internet awesome. It is close to the end of the day for me and I want to make sure I give you comprehensive answers so I’ll get back to you on issues #14 and #15.

[RupertBenWiser]

I'm following up to drop a link to the holdback discussion: https://github.com/RupertBenWiser/Web-Environment-Integrity/issues/16

[jfmcbrayer]

I think the "allow browsers without attestation" goal is probably unachievable if major browsers (i.e., Chrome) implement this proposal. Over time, there will be incentives for both website operators and browser vendors (i.e., Google) to erode the effectiveness of the holdback mechanism, and I'm sure that when that happens, it will be done in the name of user experience. Whatever the wording of the standard, there's simply no incentive for anyone implementing it to uphold that part.

[hiredman]

Major websites are already locking themselves down to avoid scraping without this. I already cannot scrape the fedex delivery data for my packages, data fedex publishes in a page for me to see, because fedex has locked down their site with some kind of finger printing.

This proposal will make this worse and further destroy my ability to programmatically access data.

This proposal is not for the users, this is for giants to exert control over users.

[AshtonKem]

I think the "allow browsers without attestation" goal is probably unachievable if major browsers (i.e., Chrome) implement this proposal. Over time, there will be incentives for both website operators and browser vendors (i.e., Google) to erode the effectiveness of the holdback mechanism, and I'm sure that when that happens, it will be done in the name of user experience. Whatever the wording of the standard, there's simply no incentive for anyone implementing it to uphold that part.

And of course that's the positive spin. The negative interpretation is that Google is lying, and they'll willfully abandon the holdback mechanism the moment they think that they can get away with it.

The whole holdback mechanism rests on the assumption that Google will make a good faith effort to do something that is against their economic interests.