I've also been worried about this space as there seems to be a fundamental tradeoff with no win-win solutions. As with other debates around tradeoffs with privacy, I think it would be naive to think that we can know the ideal balance ahead of time, or that it won't need to change over time. Anything we might decide would ultimately be influenced by the larger societal debate around privacy (regulations etc.) since perfect privacy means perfect immunity for criminals. Perhaps then a productive line of discussion for this forum is what is the apparatus that we should try to design into chromium and our processes to enable the balance to be effectively tuned over time? Such an apparatus would include both the output metrics (eg. theoretically perfect measures of fraud rates, rates of legit users being locked out) and the knobs we can tune to adjust the balance between the output metrics.
The chromium project has a history of tackling some seemingly previously intractable tradeoffs with apparatus like this. For example, we designed origin trials to let us tune the balance between efficiency and velocity of evolving the web platform with the risk of "excluding vendors" (sites working only in Chrome). We used knobs like how long do we allow a feature to be in an OT state for and what are the page usage limits to try to prevent a repeat of "vendor prefix" hell web developers faced and I think it's fair to say that it's largely been effective. We started conservatively but gradually relaxed some of our OT rules as we've learned about the effect of the ecosystem dynamics in practice and I'd hope we could do the same here. If we found instances of sites unreasonably locking out non-Chrome browsers, we'd adapt our OT rules to try to compensate. IMHO this has been extremely empowering in removing all the fear and uncertainty we used to face around experimental web APIs. Autoplaying audio and Chrome's media engagement system is another example where we finally resolved polarizing fights by a probabilistic system we worked hard to tune to maintain a good balance. I like the discussion of holdback groups in the explainer as a key knob we could design to permit tuning the balance. I don't think we'll be able to get consensus on a binary question of holdback groups as phrased, but perhaps we could agree on the apparatus around them? Perhaps chromium should have a knob for holdback group size that starts relatively large but plans to fall as long as we see evidence of the value along with absence of evidence of the harms in practice? Ben, the explainer says holdback groups are problematic because of the desire for "deterministic" solutions, right? But aren't the existing solutions (like fingerprinting) all probabilistic in some way too? Do deterministic solutions really exist at all? At the extreme, even for a fully attested device, I can just plug in a bot-controlled monitor, keyboard and mouse that uses AI to simulate a human, right? It seems to me that this problem space gets a lot more tractable if we give up any pretense of "deterministic solutions" and just focus on providing probabilistic signals to risk engines, because then we can hopefully keep the debate to largely the setting of the position of those knobs based on the outcomes we see, rather than in the intractable space of just guessing at very complex game theory? Rick On Fri, May 12, 2023 at 11:58 AM 'Ben Wiser' via blink-dev < blink-dev@chromium.org> wrote: > > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1e2f3a79-3e73-4994-bcbd-40388e1ed64an%40chromium.org?utm_medium=email&utm_source=footer> > . > -- 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/CAFUtAY-EAgYn8PzFPbiZrQm3_CbbqUnk1ywTM24BOGbP37u9WQ%40mail.gmail.com.
