On Thu, Mar 14, 2024 at 10:27 PM Ari Chivukula <aric...@chromium.org> wrote:
> Contact emails > > aric...@chromium.org, wanderv...@chromium.org, johann...@chromium.org, > rosh...@google.com > > Specification > > https://privacycg.github.io/saa-non-cookie-storage/ > This appears to be (a rendered version of) an explainer, not a specification. The actual spec, at https://privacycg.github.io/storage-access/ , seems to not be updated yet: https://privacycg.github.io/storage-access/#storage . > Design Doc > > > https://docs.google.com/document/d/19qCGb4qwOcGiNrQM3ptWvRmB4JtpaTFgFVlWLXNOQ6c/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 > > 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/CAGpy5DKXaZ4S%2B2W6GB_cpuE5i_UDBOMCwcuUYt9Qh1PpQz%3D11w%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGpy5DKXaZ4S%2B2W6GB_cpuE5i_UDBOMCwcuUYt9Qh1PpQz%3D11w%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/CAM0wra_7JmJvw7_1D6Xm%2BQ68x-BYFTnTyZrLsBG%2B7a0mNB2bsw%40mail.gmail.com.
