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/613f8599-5a58-4f54-8254-0403b180cefen%40chromium.org.
