Thanks Antonio! As mentioned on the issue, I think this sounds like a reasonable idea, though we'll have to think through some of the details of it a bit more, and will update the explainer accordingly.
On Tue, Apr 23, 2024 at 4:15 PM Antonio Sartori <antoniosart...@chromium.org> wrote: > Hi, > > after discussing this in the OWP Security&Privacy reviews, we would like > to have an allowlisting of the embedding origins as discussed in > https://github.com/cfredric/storage-access-headers/issues/7, implementing > arturjanc's proposal ("Require Activate-Storage-Access to specify not only > permission, but also the origin that is meant to receive the ability to > load the resource with credentials.") > > Reading cfredric's response to that, it looks like there might be > consensus around that. > > Thanks! > Antonio > > On Friday, April 19, 2024 at 4:23:01 PM UTC+2 Sam LeDoux wrote: > >> Contact emails >> >> sled...@chromium.org <sled...@chromium.orggoogle.com>, >> cfred...@chromium.org, johann...@chromium.org >> >> >> Explainer >> >> https://github.com/cfredric/storage-access-headers >> >> >> Specification >> >> None >> >> >> Summary >> >> Storage Access Headers extends the Storage Access API to offer a way for >> non-iframe cross-site subresources to opt in for unpartitioned cookies, and >> a way for cross-site iframes to activate the `storage-access` permission >> during the frame's load. These headers leverage permissions that have >> already been granted to reduce loads and latency for authenticated embeds >> and unlock new embedded use cases. >> >> >> Blink component >> >> Blink>StorageAccessAPI >> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EStorageAccessAPI> >> >> >> Motivation >> >> The Storage Access API currently supports the ability of authenticated >> embeds to opt in for unpartitioned cookies by requiring them to call a >> JavaScript API. Iframes that load credentialed subresources may therefore >> load, then invoke document.requestStorageAccess(), then reload >> themselves to re-trigger the subresource fetches. This creates latency, as >> the process includes unnecessary network round trips and/or document loads, >> and it limits use cases by requiring the embedded resources to use an >> iframe. >> >> >> Initial public proposal >> >> https://github.com/privacycg/storage-access/issues/130 >> >> >> TAG review >> >> None >> >> >> TAG review status >> >> Not yet requested. >> >> >> Risks >> >> >> Interoperability and Compatibility >> >> None >> >> >> >> Gecko: Tentatively Positive >> <https://github.com/privacycg/meetings/blob/b5005a8790e8ac7d9972832c36bbfc38a678a53e/2024/telcons/01-25-minutes.md?plain=1#L16> >> (we will request a formal standards position as well) >> >> >> WebKit: Tentatively Neutral >> <https://github.com/privacycg/proposals/issues/45#issuecomment-1860770360> >> (we will request a formal standards position as well) >> >> >> Web developers: Positive (feature request >> <https://github.com/privacycg/storage-access/issues/170>, feature request >> <https://github.com/privacycg/storage-access/issues/130>, feature request >> <https://github.com/privacycg/storage-access/issues/72>) >> >> >> Other signals: >> >> >> 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? >> >> None >> >> >> >> Debuggability >> >> None >> >> >> Is this feature fully tested by web-platform-tests >> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >> ? >> >> No >> >> >> Flag name on chrome://flags >> >> None >> >> >> Finch feature name >> >> None >> >> >> Non-finch justification >> >> None >> >> >> Requires code in //chrome? >> >> False >> >> >> Tracking bug >> >> https://issues.chromium.org/u/0/issues/332335089 >> >> >> Estimated milestones >> >> TBD >> >> >> Link to entry on the Chrome Platform Status >> >> https://chromestatus.com/feature/6146353156849664 >> >> -- > 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/6441c492-b1d2-4897-909e-3c5fbbf5e459n%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6441c492-b1d2-4897-909e-3c5fbbf5e459n%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/CAD_OO4iHAG%2BRph8FCfT1aSY6vOydJXxpVZQCkHiUG-%2BXx57pUw%40mail.gmail.com.
