Noting this here for future discoverability: one of the APIs that was launched as part of this was a new name for hasStorageAccess <https://developer.mozilla.org/en-US/docs/Web/API/Document/hasStorageAccess> : hasUnpartitionedCookieAccess <https://developer.mozilla.org/en-US/docs/Web/API/Document/hasUnpartitionedCookieAccess>. This was documented in the linked explainer <https://github.com/privacycg/saa-non-cookie-storage/blob/main/omit-unpartitioned-cookies.md> and spec <https://privacycg.github.io/saa-non-cookie-storage/#dom-document-hasunpartitionedcookieaccess>, but failed to make the text of the I2E/S as it probably should have.
This was included to make the meaning of the boolean returned by the function clearer, as hasStorageAccess <https://developer.mozilla.org/en-US/docs/Web/API/Document/hasStorageAccess> does *not* indicate if access to non-cookie storage via requestStorageAccess <https://developer.mozilla.org/en-US/docs/Web/API/Document/requestStorageAccess> was granted, it *only* indicates if unpartitioned cookies are available in the given context (which may have been granted via a requestStorageAccess <https://developer.mozilla.org/en-US/docs/Web/API/Document/requestStorageAccess> call). hasUnpartitionedCookieAccess <https://developer.mozilla.org/en-US/docs/Web/API/Document/hasUnpartitionedCookieAccess> is effectively an alias for hasStorageAccess <https://developer.mozilla.org/en-US/docs/Web/API/Document/hasStorageAccess>, and there are no plans to remove hasStorageAccess <https://developer.mozilla.org/en-US/docs/Web/API/Document/hasStorageAccess> as far as I'm aware. For example: // In a cross-site iframe with third-party cookies disabled let access1 = await document.hasStorageAccess(); let access2 = await document.hasUnpartitionedCookieAccess(); // access1 equals access2 equals false. // Request access only to unpartitioned localStorage let handle = await document.requestStorageAccess({localStorage: true}); access1 = await document.hasStorageAccess(); access2 = await document.hasUnpartitionedCookieAccess(); // access1 equals access2 equals false. // Request access to unpartitioned cookies as well await document.requestStorageAccess(); // the above is similar to calling requestStorageAccess({cookies: true}) access1 = await document.hasStorageAccess(); access2 = await document.hasUnpartitionedCookieAccess(); // access1 equals access2 equals true. ~ Ari Chivukula (Their/There/They're) On Wed, Apr 3, 2024 at 11:57 AM Rick Byers <rby...@chromium.org> wrote: > LGTM3 > > On Wed, Apr 3, 2024 at 11:30 AM Daniel Bratell <bratel...@gmail.com> > wrote: > >> LGTM2 >> >> /Daniel >> On 2024-03-20 16:14, Yoav Weiss (@Shopify) wrote: >> >> LGTM1 >> >> The signals from other vendors and the CG discussion seem encouraging and >> I agree that the future risk from an "all" value is probably outweighed by >> its developer-facing benefits. >> >> On Wed, Mar 20, 2024 at 12:56 PM Ari Chivukula <aric...@chromium.org> >> wrote: >> >>> I'd guess that, in the future, the semantics around 'all' may change in >>> one of two ways: >>> >>> (A) If storage methods included are deprecated, (1) we would start >>> warning developers via a DevTools issue when they use 'all', (2) we would >>> start requiring the deprecated method was specifically included in the call >>> to rSA rather than it being automatically included in all, (3) the storage >>> method would be removed from rSA. The timeline for this would likely be >>> rather long (alongside the timeline for the deprecation of the storage >>> method itself). >>> >>> (B) If a new storage method were proposed, (1) we would allow developers >>> to use it if explicitly included in rSA (but not add it via all) and then >>> (2) add it under 'all' once it had fully launched. >>> >>> The chances of a new storage method being added we (1) do want in rSA >>> but (2) wouldn't ever want under 'all' is low I think. All of the >>> storage/communication mechanisms besides local/session storage either have >>> async APIs or don't expose events to monitor changes that would require >>> full loading of data simply because the handle/constructor was made >>> available. I agree there is a potential for a footgun here, but given the >>> direction these APIs seem to be heading I don't think the risk is high. >>> What are the chances vendors decide to add new storage mechanisms that are >>> loaded at document initialization with all data synchronously available? >>> >>> ~ Ari Chivukula (Their/There/They're) >>> >>> >>> On Wed, Mar 20, 2024 at 7:48 AM Yoav Weiss (@Shopify) < >>> yoavwe...@chromium.org> wrote: >>> >>>> >>>> >>>> On Wed, Mar 20, 2024 at 12:40 PM Ari Chivukula <aric...@chromium.org> >>>> wrote: >>>> >>>>> I think the last place it came up was in this thread: >>>>> https://github.com/mozilla/standards-positions/issues/898#issuecomment-1745688352 >>>>> >>>>> I think it came up at TPAC, but I might me missing the right line: >>>>> https://github.com/privacycg/meetings/blob/a27d3ee4c596efb5aec7d16feda2708fbd60eacf/2023/tpac/minutes.md?plain=1#L302 >>>>> >>>>> Either way, there hasn't been further concern raised recently so we >>>>> moved forward with 'all' since the function is async (the delay from >>>>> loading local/session storage isn't high, and it was often already loaded >>>>> given the requirement to have interacted with the iframe's site in a >>>>> top-level context in the past). >>>>> >>>> >>>> The only concern I may have on the "all" front is related to changing >>>> semantics. How likely are we to add future storage mechanisms that users >>>> would not want to expose along with current ones? >>>> >>>> >>>>> >>>>> ~ Ari Chivukula (Their/There/They're) >>>>> >>>>> >>>>> On Wed, Mar 20, 2024 at 7:29 AM Yoav Weiss (@Shopify) < >>>>> yoavwe...@chromium.org> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Thursday, March 14, 2024 at 2:27:20 PM UTC+1 Ari Chivukula wrote: >>>>>> >>>>>> Contact emails >>>>>> >>>>>> aric...@chromium.org, wanderv...@chromium.org, johann...@chromium.org, >>>>>> rosh...@google.com >>>>>> >>>>>> Specification >>>>>> >>>>>> https://privacycg.github.io/saa-non-cookie-storage/ >>>>>> >>>>>> Design Doc >>>>>> >>>>>> https://docs.google.com/document/d/19qCGb4qwOcGiNrQM3ptWvRmB4Jtpa >>>>>> TFgFVlWLXNOQ6c/edit >>>>>> >>>>>> Feedback >>>>>> >>>>>> https://github.com/privacycg/saa-non-cookie-storage/issues >>>>>> >>>>>> >>>>>> Intent to Prototype >>>>>> >>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/inRN8tI49O0 >>>>>> >>>>>> Intent to Experiment >>>>>> >>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/SEL7N-xIE5s >>>>>> >>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/AjH7tGxuVuw >>>>>> >>>>>> Summary >>>>>> >>>>>> This launches the proposed extension of the Storage Access API >>>>>> <https://webkit.org/blog/8124/introducing-storage-access-api/> >>>>>> (backwards compatible and currently in OT) to allow access to >>>>>> unpartitioned >>>>>> cookie and non-cookie storage in a third-party context. The current API >>>>>> only provides access to cookies, which have different use-cases than >>>>>> non-cookie storage (discussed more in the Motivation section). The API >>>>>> can >>>>>> be used as follows (JS running in an embedded iframe): >>>>>> >>>>>> >>>>>> // Request a new storage handle via rSA (this may prompt the user) >>>>>> >>>>>> let handle = await document.requestStorageAccess({all: true}); >>>>>> >>>>>> // Write some 1P context sessionstorage >>>>>> >>>>>> handle.sessionStorage.setItem("userid", "1234"); >>>>>> >>>>>> // Write some 1P context localstorage >>>>>> >>>>>> handle.localStorage.setItem("preference", "A"); >>>>>> >>>>>> // Open or create an indexedDB that is shared with the 1P context >>>>>> >>>>>> let messageDB = handle.indexedDB.open("messages"); >>>>>> >>>>>> // Use locks shared with the 1P context >>>>>> >>>>>> await handle.locks.request(“example”, …); >>>>>> >>>>>> >>>>>> The same flow would be used by iframes to get a storage handle when >>>>>> their top-level ancestor successfully called requestStorageAccessFor >>>>>> <https://github.com/privacycg/requestStorageAccessFor>, just that in >>>>>> this case the storage-access permission was already granted and thus the >>>>>> requestStorageAccess call would not require a user gesture or show a >>>>>> prompt, allowing for “hidden” iframes accessing storage. >>>>>> >>>>>> >>>>>> Beyond calling this additional extension, access to non-cookie >>>>>> storage would match the current requirements for cookie access through >>>>>> the >>>>>> Storage Access API. >>>>>> >>>>>> >>>>>> DOM Storage (session and local storage), Indexed DB, Web Locks, Cache >>>>>> Storage, Origin Private File System, Quota, Blob Storage, Broadcast >>>>>> Channel, and SharedWorkers will be available. >>>>>> >>>>>> >>>>>> Blink component >>>>>> >>>>>> Blink>StorageAccessAPI >>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EStorageAccessAPI> >>>>>> >>>>>> >>>>>> Motivation >>>>>> >>>>>> There has been increasing developer >>>>>> <https://github.com/GoogleChromeLabs/privacy-sandbox-dev-support/issues/124> >>>>>> and implementer >>>>>> <https://github.com/privacycg/storage-access/issues/102> interest in >>>>>> first-party DOM Storage >>>>>> <https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage_API> >>>>>> and Quota Managed Storage >>>>>> <https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API> >>>>>> being available in third-party contexts the same way that cookies >>>>>> can be today <https://github.com/privacycg/storage-access>. In the >>>>>> absence of such a solution, browsers would in effect be pushing >>>>>> developers >>>>>> to migrate to cookies from other storage mechanisms. There are tradeoffs >>>>>> between cookie and non-cookie storage (size, flexibility, server >>>>>> exposure, >>>>>> network request size, etc.) that could impact user experience from a >>>>>> privacy, security and performance perspective (e.g., cookies are included >>>>>> in HTTP requests and not just available via JavaScript). To prevent >>>>>> sub-optimal use of cookies and to preserve context, we propose a solution >>>>>> for developers to regain 3p access to unpartitioned storage to avoid >>>>>> user-facing breakage in browsers shipping storage partitioning. >>>>>> >>>>>> TAG review >>>>>> >>>>>> https://github.com/w3ctag/design-reviews/issues/906 >>>>>> >>>>>> Compatibility >>>>>> >>>>>> The Storage Access API is already implemented in Safari, Firefox, >>>>>> and Chrome >>>>>> <https://caniuse.com/mdn-api_document_requeststorageaccess>, but the >>>>>> proposed API shape would preserve existing behavior until the web >>>>>> developer >>>>>> adds new arguments. >>>>>> >>>>>> >>>>>> Interoperability >>>>>> >>>>>> Gecko: No Position Yet https://github.com/mozilla/ >>>>>> standards-positions/issues/898 >>>>>> >>>>>> >>>>>> Despite the lack of an official position, the discussion seems >>>>>> encouraging. I sympathize with concerns around "all"'s semantics and >>>>>> their >>>>>> future compat impact. >>>>>> Was this point discussed in the CG or elsewhere? >>>>>> >>>>>> >>>>>> WebKit: No Position Yet https://github.com/WebKit/ >>>>>> standards-positions/issues/262 >>>>>> >>>>>> Web developers: Positive >>>>>> <https://github.com/GoogleChromeLabs/privacy-sandbox-dev-support/issues/124> >>>>>> >>>>>> Debuggability >>>>>> >>>>>> Storage written can be examined in devtools. >>>>>> >>>>>> Is this feature fully tested by web-platform-tests? >>>>>> >>>>>> Yes >>>>>> <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/storage-access-api/> >>>>>> >>>>>> Tracking bug >>>>>> >>>>>> https://issues.chromium.org/40282415 >>>>>> >>>>>> >>>>>> Link to entry on the Chrome Platform Status >>>>>> >>>>>> https://chromestatus.com/feature/5175585823522816 >>>>>> >>>>>> -- >> 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/CAOmohSJvYhyvgmmBgXxH3rXoQtdMJ1_kk4PRqOrNc9Qq16HeEg%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSJvYhyvgmmBgXxH3rXoQtdMJ1_kk4PRqOrNc9Qq16HeEg%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/a640c694-e866-45dd-9268-55f2f992885a%40gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a640c694-e866-45dd-9268-55f2f992885a%40gmail.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/CAGpy5DKqyuyK_79%3D%2B9YS-GA0KR_xY%3DWo50godCew4dPZqO69PQ%40mail.gmail.com.
