On Fri, Aug 20, 2021 at 10:02 AM Alan Stearns <[email protected]> wrote:
> Thanks for the additional background. I still do not see how this “tackles > the arguments” I have seen in Mozilla and WebKit’s objections to this > feature. > > I understand the objections to be something like “the user harm inherent > in this feature outweighs the developer benefit.” So it looks to me like > the argument is over whether this summit is worth approaching at all, > directly or indirectly. To my mind, tacking the arguments presented would > either include showing why the developer benefit is being devalued, or > providing additional mitigations for user harm (to the current proposal, > not theoretical future protections). > There is an unsubstantiated *claim *of user harm here, to which Hitchen's Razor applies. I had assumed that was clear, which is why I outlined the space of possibilities, since the status quo won't change much (except to potentially reduce already frustrating user experiences) without other changes that tamp down on the fingerprinting/tracking potential. If folks want to bring quantification and weigh up impacts, I (and the rest of the OWNERs) welcome that. But polemic without data isn't much of an argument. I do get the argument that this is a relatively responsible way to work on > the feature. But when your vantage point is “this is a relatively > responsible way to add user harm to the platform” it is not very convincing. > > On Friday, August 20, 2021 at 9:39:07 AM UTC-7 [email protected] > wrote: > >> Hey Alan, >> >> Good question. Let me try again. Progress in stable platforms is often a >> two-step process. Not leaping blindly is an *asset,* over time. >> >> If we did not have a strategic interest in a platform that is >> sufficiently capable to meet developer needs, we wouldn't need to be >> responsible towards developers as well as users. That, however, is not the >> situation we're in. Winning developers to "our side" (building on the web) >> requires developing and retaining their trust[1] while making changes that >> improve life for users. This is why we take deprecations seriously, set >> usage limits for OTs to prevent "burn in", etc. We don't YOLO changes on >> our platform because our reputation for responsible evolution underpins >> nearly everything else we attempt. >> >> So, when UAs begin to introduce policies like the Privacy Sandbox which >> will begin to take a more sophisticated approach to capping fingerprinting, >> we need to have semantically transparent APIs in place that developers can >> migrate towards *to the extent that we care about developer success*. If >> we didn't have that balance in mind (and, as always, putting users first), >> any policy would do. >> >> Because we do not want to lose developers[2] while repair things for >> users, providing transition windows and alternatives is the responsible >> thing to do. Many things we do in evolving the web responsibly look like >> switch-backs rather than direct runs to the summit. That's better because >> it makes it more likely we'll bring everyone to the summit, not just folks >> who can re-work the content of their sites every quarter. >> >> Regards >> >> [1]: https://infrequently.org/2020/06/platform-adjacency-theory/ >> [2]: https://infrequently.org/2021/07/the-core-web-loop/ >> >> >> On Thu, Aug 19, 2021 at 1:06 PM Alan Stearns <[email protected]> wrote: >> >>> I am a bit confused on this point. If the new explicit surface does not >>> also disable the previous hack, I don’t see how adding the new surface >>> (however it might theoretically be limited) is an improvement. >>> >>> On Thursday, August 19, 2021 at 11:58:13 AM UTC-7 [email protected] >>> wrote: >>> For all of those reasons, in this and in other APIs that provide >>> explicit surface for what was previously an implicit hack-based mechanism >>> that was not similarly limited, cabined, and semantically transparent, my >>> vote will be an LGTM. It is bad policy for UAs to be in the business of >>> saying "something bad might happen!" rather than weighing up the real >>> consequences and maintaining a position through APIs to most-probably >>> mitigate harms directly. >>> >>> -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA44PQj1xb7KRCbkgRrS4vxE6gB5RnQPe3ua5OrO8wRq7tk9wg%40mail.gmail.com.
