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.
