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/CAFUtAY9oV00r5VN9fMqC-YWFvJDQkzSNSwT%2BkmQWNc_5vDJOgA%40mail.gmail.com.
