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/CAL5BFfUqSF%3DxW_wAOgCwnBVb7kmVx0Y6pe1Tcg17-Q%3DoZXr7TQ%40mail.gmail.com.
