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). 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 sligh...@chromium.org 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 <famu...@gmail.com> 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 sligh...@chromium.org >> 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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2d45c45f-3128-4540-82e0-49837c389da3n%40chromium.org.
