We're now rolling this feature out to 100% on Chrome Stable (M117 and later).
On Tuesday, September 26, 2023 at 11:20:29 AM UTC-4 Chris Fredrickson wrote: > Belatedly updating this thread in case folks are monitoring it -- we've > enabled this feature on 1% of Chrome Stable (M117) clients. We'll update > this thread again when we roll out to a higher percentage. > > As a reminder: if people would like to test this feature out before we've > fully shipped it, they can can follow the testing instructions here: > https://github.com/cfredric/chrome-storage-access-api#testing-instructions > > On Tuesday, August 22, 2023 at 1:26:10 PM UTC-4 Mike Taylor wrote: > >> LGTM3 >> On 8/22/23 10:49 AM, Yoav Weiss wrote: >> >> LGTM2 >> >> On Wed, Aug 16, 2023 at 7:31 PM Chris Harrelson <chris...@chromium.org> >> wrote: >> >>> I agree with Chris F. that it's not worth the disruption to change the >>> name or its location, and that leaving the name as-is, even if suboptimal, >>> is a better outcome for web developers. >>> >>> LGTM1 >>> >>> On Wed, Aug 16, 2023 at 9:37 AM 'Jeffrey Yasskin' via blink-dev < >>> blink-dev@chromium.org> wrote: >>> >>>> I see this as the other vendors endorsing Blink's general policy, >>>> implied by the wording in >>>> https://www.chromium.org/blink/guidelines/web-platform-changes-guidelines/#browser-engine-reviews, >>>> >>>> that there's a high bar for name changes after shipping. If this API, >>>> which >>>> has a clearly inaccurate name and was shipped with no invitation for >>>> cross-vendor feedback, isn't worth changing after shipping, then it's not >>>> worth changing most APIs that Blink ships first either. >>>> >>>> Jeffrey >>>> >>>> On Wed, Aug 16, 2023 at 8:52 AM Alex Russell <slightly...@chromium.org> >>>> wrote: >>>> >>>>> Hrm; the TAG had (many years ago, when I served) noted big problems >>>>> with the shape of this API. It's surprising we're taking it as-is. >>>>> >>>>> On Tuesday, August 8, 2023 at 9:08:43 AM UTC-7 Chris Fredrickson wrote: >>>>> >>>>>> Hi Alex, >>>>>> >>>>>> I hear you about the method names. However since Safari, Firefox, and >>>>>> Edge had all previously shipped this API using these names and web >>>>>> developers have already begun using it, it would have been disruptive >>>>>> for >>>>>> Chrome to force a rename. We opted to limit the disruption we caused to >>>>>> improving the ergonomics and security posture of the API instead (1 >>>>>> <https://github.com/privacycg/storage-access/pull/138>, 2 >>>>>> <https://github.com/privacycg/storage-access/pull/141>, 3 >>>>>> <https://github.com/privacycg/storage-access/pull/132>, 4 >>>>>> <https://github.com/privacycg/storage-access/pull/159>, 5 >>>>>> <https://github.com/privacycg/storage-access/pull/169>, 6 >>>>>> <https://github.com/privacycg/storage-access/pull/174>), since that >>>>>> was indeed disruptive but there was at least cross-browser interest in >>>>>> making those changes. >>>>>> >>>>>> Re: navigator vs document, there was previous discussion of this here >>>>>> <https://github.com/privacycg/storage-access/issues/22>. We did not >>>>>> specifically ask the TAG about which object they preferred, but they >>>>>> closed >>>>>> their review with no comments. Considering that each document's access >>>>>> is >>>>>> independent of access obtained by other documents (due to the per-frame >>>>>> security model), the choice of document makes some sense to me, >>>>>> personally >>>>>> - but there may be some best practice I'm unaware of. >>>>>> >>>>>> FWIW, Chrome is exploring >>>>>> <https://github.com/privacycg/storage-access/issues/102#issuecomment-1550967682> >>>>>> >>>>>> ways to use document.requestStorageAccess() to provide access to >>>>>> unpartitioned DOM storage in the future, in which case the current name >>>>>> would be more appropriate. >>>>>> >>>>>> Chris >>>>>> >>>>>> On Monday, August 7, 2023 at 6:46:41 PM UTC-4 Alex Russell wrote: >>>>>> >>>>>>> Hey Chris, >>>>>>> >>>>>>> Thanks for the details here. >>>>>>> >>>>>>> Can you perhaps outline why we didn't take the opportunity here to >>>>>>> rename this to better represent what the API actually does? E.g., >>>>>>> `requestUnpartitionedCookieAccess()`? And was any effort made to move >>>>>>> the >>>>>>> API to a more suitable object; e.g. `navigator`? Was this discussed >>>>>>> with >>>>>>> the TAG? >>>>>>> >>>>>>> Best, >>>>>>> >>>>>>> Alex >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Monday, August 7, 2023 at 11:47:45 AM UTC-7 Chris Fredrickson >>>>>>> wrote: >>>>>>> >>>>>>>> Hi Mike, >>>>>>>> >>>>>>>> Sure. MDN has a section >>>>>>>> <https://developer.mozilla.org/en-US/docs/Web/API/Storage_Access_API#browser_storage_access_policy_variations> >>>>>>>> >>>>>>>> (which may be incomplete or outdated) on the implementation >>>>>>>> differences >>>>>>>> between Safari, Firefox, and Chromium-based browsers. But specifically >>>>>>>> related to the prompt requirements, there are two aspects that may >>>>>>>> cause >>>>>>>> compat issues: >>>>>>>> >>>>>>>> 1. >>>>>>>> >>>>>>>> Permission lifetime. Storage Access grants have different >>>>>>>> lifetimes in different browsers, so web developers may have to show >>>>>>>> a >>>>>>>> prompt more often than they expect: >>>>>>>> 1. >>>>>>>> >>>>>>>> Firefox: 30 calendar days. >>>>>>>> 2. >>>>>>>> >>>>>>>> Chrome: 30 calendar days. >>>>>>>> 3. >>>>>>>> >>>>>>>> Safari: 30 days of browser usage. >>>>>>>> 2. >>>>>>>> >>>>>>>> User interaction requirement. Whether a user gesture is >>>>>>>> required by document.requestStorageAccess() is inconsistent across >>>>>>>> browsers: >>>>>>>> 1. >>>>>>>> >>>>>>>> Firefox: always requires user interaction. (This is a >>>>>>>> nonstandard behavior, but it appears Firefox is being updated >>>>>>>> <https://phabricator.services.mozilla.com/D183175> to not >>>>>>>> require user interaction in some cases.) >>>>>>>> 2. >>>>>>>> >>>>>>>> Chrome: requires user interaction unless the user has >>>>>>>> already granted access. >>>>>>>> 3. >>>>>>>> >>>>>>>> Safari: always >>>>>>>> >>>>>>>> <https://github.com/privacycg/storage-access/issues/172#issuecomment-1521653447> >>>>>>>> >>>>>>>> requires user interaction. (This is a nonstandard behavior.) >>>>>>>> >>>>>>>> >>>>>>>> Since Firefox and Safari currently impose stricter user interaction >>>>>>>> requirements than what the spec dictates, this could lead to compat >>>>>>>> issues >>>>>>>> if web developers assume that browsers don't impose additional >>>>>>>> browser-specific constraints. >>>>>>>> >>>>>>>> There's one additional aspect, where web developers may not need to >>>>>>>> call document.requestStorageAccess() at all in certain situations in >>>>>>>> some >>>>>>>> browsers (which could lead to broken experiences if web developers >>>>>>>> assume >>>>>>>> they can always omit the explicit call): >>>>>>>> >>>>>>>> - Firefox: if foo.example has obtained storage access while >>>>>>>> embedded under bar.example, and the user loads a bar.example page >>>>>>>> that >>>>>>>> includes a foo.example iframe, then that iframe will load with >>>>>>>> implicit >>>>>>>> storage access -- without having to call >>>>>>>> document.requestStorageAccess() >>>>>>>> first. (This is a deviation from the specification, but this part >>>>>>>> of the >>>>>>>> spec was changed relatively recently >>>>>>>> <https://github.com/privacycg/storage-access/issues/113> for >>>>>>>> security reasons; Firefox is planning >>>>>>>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1837648> to >>>>>>>> incorporate the recent changes.) >>>>>>>> >>>>>>>> Chris >>>>>>>> On Wednesday, August 2, 2023 at 5:02:35 PM UTC-4 Mike Taylor wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> On 8/2/23 4:47 PM, Chris Fredrickson wrote: >>>>>>>>> >>>>>>>>> Contact emails >>>>>>>>> >>>>>>>>> cfred...@chromium.org, johann...@chromium.org, >>>>>>>>> shuu...@chromium.org >>>>>>>>> >>>>>>>>> Explainer >>>>>>>>> >>>>>>>>> https://github.com/privacycg/storage-access/blob/main/README.md >>>>>>>>> >>>>>>>>> >>>>>>>>> https://github.com/cfredric/chrome-storage-access-api/blob/main/README.md >>>>>>>>> >>>>>>>>> Specification >>>>>>>>> >>>>>>>>> https://privacycg.github.io/storage-access >>>>>>>>> >>>>>>>>> Summary >>>>>>>>> >>>>>>>>> The Storage Access API provides a means for authenticated >>>>>>>>> cross-site embeds to check whether access to unpartitioned cookies is >>>>>>>>> blocked and request access if it is blocked. This request may be >>>>>>>>> surfaced >>>>>>>>> to the user as a prompt, or auto-granted/auto-denied. Chrome will >>>>>>>>> support >>>>>>>>> the Storage Access API by implementing all the behaviors listed in >>>>>>>>> the >>>>>>>>> specification, i.e. with user prompts, and additionally having its >>>>>>>>> own >>>>>>>>> user-agent-specific behaviors. Chrome’s implementation is available >>>>>>>>> for testing >>>>>>>>> <https://github.com/cfredric/chrome-storage-access-api#testing-instructions> >>>>>>>>> >>>>>>>>> starting in Chrome 117. >>>>>>>>> >>>>>>>>> The Storage Access API is related to other cookie-focused projects >>>>>>>>> like CHIPS >>>>>>>>> <https://developer.chrome.com/en/docs/privacy-sandbox/chips/> and >>>>>>>>> First-Party >>>>>>>>> Sets <https://github.com/WICG/first-party-sets> as preparation >>>>>>>>> for phasing out third-party cookies >>>>>>>>> <https://developer.chrome.com/en/docs/privacy-sandbox/third-party-cookie-phase-out/> >>>>>>>>> >>>>>>>>> in Chrome. >>>>>>>>> >>>>>>>>> Note that Edge previously sent an I2I >>>>>>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/e5fu5Q06ntA/m/UUqPuA8hEQAJ> >>>>>>>>> >>>>>>>>> for the Storage Access API feature (with their own >>>>>>>>> user-agent-specific >>>>>>>>> behavior), and Chrome has previously sent an I2S >>>>>>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/V9PzoCvIIIs/m/CZ4JT7YaAgAJ> >>>>>>>>> >>>>>>>>> for support for the Storage Access API gated on First-Party Sets >>>>>>>>> membership >>>>>>>>> (without user prompts). This I2S is intended for support for the API >>>>>>>>> across >>>>>>>>> sites that are not within the same First-Party Set. >>>>>>>>> >>>>>>>>> Blink component >>>>>>>>> >>>>>>>>> Blink>StorageAccessAPI >>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EStorageAccessAPI> >>>>>>>>> >>>>>>>>> TAG review >>>>>>>>> >>>>>>>>> https://github.com/w3ctag/design-reviews/issues/807 (review of >>>>>>>>> overall API, not of prompts) >>>>>>>>> >>>>>>>>> TAG review status >>>>>>>>> >>>>>>>>> Positive >>>>>>>>> <https://github.com/w3ctag/design-reviews/issues/807#issuecomment-1431464692> >>>>>>>>> >>>>>>>>> Risks >>>>>>>>> >>>>>>>>> Interoperability and Compatibility >>>>>>>>> >>>>>>>>> There is minor compatibility risk as Firefox and Safari already >>>>>>>>> differ slightly in their user-agent-specific prompt requirements. >>>>>>>>> Chrome's >>>>>>>>> planned behavior >>>>>>>>> <https://github.com/cfredric/chrome-storage-access-api> is >>>>>>>>> closest to Safari's current behavior, and we aim to standardize as >>>>>>>>> much of >>>>>>>>> this user-agent-specific behavior as possible over time. >>>>>>>>> >>>>>>>>> Could you elaborate on the differences for prompt requirements, >>>>>>>>> and how that might lead to compat issues? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Gecko: Shipping >>>>>>>>> >>>>>>>>> WebKit: Shipping >>>>>>>>> >>>>>>>>> Web developers: There has been great developer interest in the >>>>>>>>> Storage Access API, given that it provides the only predictable way >>>>>>>>> of >>>>>>>>> working with cross-site cookies in many browsers. Various developers >>>>>>>>> have >>>>>>>>> chimed in on https://github.com/whatwg/html/issues/3338 and filed >>>>>>>>> issues on https://github.com/privacycg/storage-access. >>>>>>>>> >>>>>>>>> Other signals: Edge has shipped Blink's previous implementations >>>>>>>>> of this API, which differ from Chrome's plans. We have kept (and >>>>>>>>> intend to >>>>>>>>> continue keeping) Edge engineers in the loop about these changes and >>>>>>>>> there >>>>>>>>> will be feature flags to control Blink's behavior. >>>>>>>>> >>>>>>>>> WebView application risks >>>>>>>>> >>>>>>>>> Does this intent deprecate or change behavior of existing APIs, >>>>>>>>> such that it has potentially high risk for Android WebView-based >>>>>>>>> applications? No. >>>>>>>>> >>>>>>>>> >>>>>>>>> Debuggability >>>>>>>>> >>>>>>>>> None >>>>>>>>> >>>>>>>>> Will this feature be supported on all six Blink platforms >>>>>>>>> (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? >>>>>>>>> >>>>>>>>> No. It will be supported on all Blink platforms except Android >>>>>>>>> WebView initially. We may add WebView support in the future. >>>>>>>>> >>>>>>>>> Is this feature fully tested by web-platform-tests >>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>>>>> ? >>>>>>>>> >>>>>>>>> No. Browser UI is not testable by WPTs, since that is UA-specific. >>>>>>>>> (The Storage Access API spec itself is tested by WPTs >>>>>>>>> <https://wpt.fyi/results/storage-access-api>.) >>>>>>>>> >>>>>>>>> Flag name on chrome://flags >>>>>>>>> >>>>>>>>> #storage-access-api, #permission-storage-access-api >>>>>>>>> >>>>>>>>> Finch feature name >>>>>>>>> >>>>>>>>> StorageAccessAPI, PermissionStorageAccessAPI >>>>>>>>> >>>>>>>>> Non-finch justification >>>>>>>>> >>>>>>>>> None >>>>>>>>> >>>>>>>>> Requires code in //chrome? >>>>>>>>> >>>>>>>>> True >>>>>>>>> >>>>>>>>> Estimated milestones >>>>>>>>> Shipping on desktop: 117 >>>>>>>>> Shipping on Android: 120 >>>>>>>>> >>>>>>>>> Anticipated spec changes >>>>>>>>> >>>>>>>>> Some minor changes are expected in order to properly take user >>>>>>>>> settings into account: >>>>>>>>> https://github.com/privacycg/storage-access/pull/174 and an >>>>>>>>> analogous change for document.requestStorageAccess. >>>>>>>>> >>>>>>>>> There is ongoing discussion >>>>>>>>> <https://github.com/privacycg/storage-access/issues/102> on how >>>>>>>>> to offer access to unpartitioned DOM storage via this API. >>>>>>>>> >>>>>>>>> The spec has been in incubation being co-developed by all three >>>>>>>>> browser engines for a while and is close to graduation as tracked >>>>>>>>> here: >>>>>>>>> https://github.com/whatwg/html/issues/9000. >>>>>>>>> >>>>>>>>> >>>>>>>>> Link to entry on the Chrome Platform Status >>>>>>>>> >>>>>>>>> https://chromestatus.com/feature/5085655327047680 >>>>>>>>> >>>>>>>>> Links to previous Intent discussions >>>>>>>>> >>>>>>>>> Intent to prototype: Intent to Prototype: Storage Access API with >>>>>>>>> Prompts >>>>>>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/zt-nqGpURNY/m/FF6ciM6qAwAJ> >>>>>>>>> >>>>>>>>> This intent message was generated by Chrome Platform Status >>>>>>>>> <https://chromestatus.com/>. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> 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/5e44f071-97ba-41e0-a0cd-7bd3a210d6bdn%40chromium.org >>>>>>>>> >>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5e44f071-97ba-41e0-a0cd-7bd3a210d6bdn%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/8884e737-21c8-4c01-9cc3-caaf125e52e2n%40chromium.org >>>>> >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8884e737-21c8-4c01-9cc3-caaf125e52e2n%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/CANh-dXnGvxVw8CwP1sPk-%2Bxf-ObjuTxXe2a9LdaSe2g6wv0d1w%40mail.gmail.com >>>> >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANh-dXnGvxVw8CwP1sPk-%2Bxf-ObjuTxXe2a9LdaSe2g6wv0d1w%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/CAOMQ%2Bw9iRq4Z75qEhWP9rFAGUStasGVCi6wc4btVT2-CoJiuHw%40mail.gmail.com >>> >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw9iRq4Z75qEhWP9rFAGUStasGVCi6wc4btVT2-CoJiuHw%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/944eeb21-8059-42f0-9742-010293250540n%40chromium.org.
