Closed tbrandirali closed 11 months ago
yoavweiss
commented
11 months ago Thanks for being constructive! :) This is roughly the same issue as #108, so I think we can fold the discussion there. I think that clarifying the stated goals and the risks involved in the explainer and spec can help bridge the gap.
Snukii
commented
11 months ago Thanks for being constructive! :) This is roughly the same issue as #108, so I think we can fold the discussion there. I think that clarifying the stated goals and the risks involved in the explainer and spec can help bridge the gap.
@yoavweiss If this is the same as that issue then you should comment on that issue.
The proposal's first two stated goals,
and its fourth goal,
are pretty clearly opposed and incompatible. The first and obvious use of an attestation system is the prevention of unattested usage. Almost all of the example use cases, despite only talking about the "detection" of illegitimate activity, clearly imply the prevention of it (for example: nobody builds an anticheat system that doesn't act upon its detections). If we follow @yoavweiss' suggestion on thinking about a new proposal and use Occam's razor, we should assume that the goal of such an attestation system would be first and foremost to enable the gatekeeping of unattested traffic. This proposal is building a gate, and expecting it not to be used as a gate.
This internal contradiction is further demonstrated by the fact that the proposed solution to prevent misuse by websites - holdbacks - is to simply sabotage the functionality of the system itself, by making attestation probabilistic. This is not a workable solution to the problem: if the holdback rate of requests is low enough, the denial of service to legitimate users will simply be a cost of business that websites will accept; if instead it is high enough, websites will not use this system as it does not provide meaningful enough information, even for analytics purposes, due to the high uncertainty. There is no goldilocks zone where this system is useful but not open to abuse by implementer websites. You're either implementing a feature that can - and most likely will - be used by websites to exclude unattested clients, or you're implementing a useless feature.
This contradiction cannot be solved by technical fixes to the API. If you want to be internally consistent, you can either drop the goal of allowing unattested traffic and admit that you are building a system for gatekeeping web browsing, or you retract this proposal entirely. As it stands now, these contradictory goals, combined with the disingenuous policing of tone in the discussions and lack of engagement with legitimate criticism, are giving out the impression of a lack of good faith from the authors and the organization they represent (Google). In order to demand good faith from the community there needs to be good faith from the authors in the first place.