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.
