LGTM3 On the compat front this is technically a breaking change for shipped APIs. Normally we'd want to see a more thorough a compat analysis <http://bit.ly/blink-compat> to back up the claim of sites not being functionally broken. However, running through a compat analysis in my head I think what you've provided is sufficient, because:
- Our primary tool of UseCounters isn't going to be too helpful here. We know these APIs are being widely tested and we know we can't realistically measure whether errors are being handled properly. I don't have any easy suggestions for how to quantify this particular risk well. - These are brand new APIs with a generally small number of customers who are probably actively experimenting - All the APIs are for use cases which aren't directly relevant to the core functioning of a site - so any breakage is unlikely to be noticed by users, except possibly by ads not showing (though unhandled exceptions in async functions in initialization routines are potentially a problem) - I know these launches are being rolled out and watched carefully. I assume we'll do some small percentage first and verify we don't hear complaints before ramping up? And worst case and there's significant functional breakage, we can use a killswitch to roll back, right? While I know the utility of this system remains to be seen, I personally like the added transparency compared to the current state where these APIs are just available to anyone - especially given the new ground we're breaking with these APIs. I imagine researchers and others can get some value out of the .well-known file such as by crawling popular sites. However I can imagine some forms of research would benefit from access to the enrolled-sites list being used in Chrome (to analyze less popular sites that might not show up in a top sites list). Are you able to provide instructions for easily extracting the site list from a Chrome install? Or do you have a date by which you expect you can make the enrolled-sites list available elsewhere? I don't see a particular interoperability concern here since we're not aware of any other browsers who have said they're shipping these APIs (right?), and if they were they could probably just make it available to all sites, clone our system, or use their own system for gating access (a similar cross-browser dynamic we have with the origin trials system, which doesn't appear to have been a problem so far). But we should keep our ears open for any other browser who might want to use a similar system and be open to collaboration. Thanks, Rick On Mon, Sep 11, 2023 at 7:09 PM Shivani Sharma <shivani...@chromium.org> wrote: > > > On Fri, Sep 8, 2023 at 10:40 AM Chris Harrelson <chris...@chromium.org> > wrote: > >> LGTM2 conditioned on the spec PRs landing (some are still open). >> > Thanks Chris! The spec PRs are now all merged. > >> >> On Fri, Sep 8, 2023 at 6:02 AM Mike Taylor <miketa...@chromium.org> >> wrote: >> >>> On 9/7/23 6:06 PM, Shivani Sharma wrote: >>> >>> On Friday, September 1, 2023 at 6:20:34 PM UTC-4 Mike Taylor wrote: >>> >>> Thanks. One last question here: how confident are y'all that consumers >>> of these APIs are well-equipped for errors in case they don't enroll? Have >>> you looked at any Privacy Sandbox API usage in the wild to verify that >>> early adopters aren't going to break? >>> >>> >>> The Impact of not enrolling has been well publicized over the past few >>> months on multiple levels and through various form factors, including blog >>> posts and 1:1 conversations with ad tech companies testing the APIs. >>> While we have been thoughtful in our design, allowing sufficient time >>> between outreach and enforcement, and supporting adtechs in their migration >>> journey, adtechs would need to enroll if they plan to call the APIs >>> post-enforcement successfully. >>> We also think it’s important to launch this process now, to provide time >>> for API callers to complete enrollment and work out any issues that may >>> arise, ahead of expanded API testing in early 2024. >>> >>> Thanks for the answer. It sounds like there is some compat risk for >>> early adopters, but y'all have mechanisms in place to communicate the >>> changes and do outreach if needed. >>> >>> LGTM1 to ship. >>> >>> -- >>> 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/1688dcc9-8dca-4e89-bc06-4b58725c22a9%40chromium.org >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1688dcc9-8dca-4e89-bc06-4b58725c22a9%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/CADAcp0_M%3D2sAK%3DfVs_qgXON2pnxVcricnejtJUExm34fdgfgqw%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADAcp0_M%3D2sAK%3DfVs_qgXON2pnxVcricnejtJUExm34fdgfgqw%40mail.gmail.com?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_sgYXhtQ4sQgm9Wi3uD-iomZt%3DQm1tPGd5dg4t_8SjKw%40mail.gmail.com.
