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.
