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/CAA44PQhHeZAH4kV8_cM_kTKSd1%3D8fSZF0eGJa4BZ5S2-m9M%2B%2BA%40mail.gmail.com.
