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.
