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/CAOmohSK6-9%2BNojMYFn5sZk4mxsEszxiqaY350UBHjTJ7bxqvfg%40mail.gmail.com.
