Mike, Thank you for the response. To address your comments:
This is trending positive, but > https://github.com/mozilla/standards-positions/issues/1084#issuecomment-2471319900 > some > possible renaming. Can we try to sort that out with Mozilla before shipping? Thank you for pointing this out, we will discuss the naming with Mozilla again. > What feedback have you received so far from participants? One piece of feedback we received was that the SAH retry behavior with cross-site redirects was unintuitive, which led us to create this issue <https://github.com/privacycg/storage-access/issues/210>, and update the behavior in chromium <https://chromium-review.googlesource.com/c/chromium/src/+/6020980> accordingly. This rationale sounds like using the OT as a soft-launch, which isn't > great. Do you think your partners will learn something in the requested > extra 4 weeks such that you might meaningfully incorporate the feedback > ahead of a launch? (I think the answer is probably no, but I'd love to hear > your perspective). One of our main motivators for extending the origin trial was feedback from a partner that they have not had a chance to begin experimenting and would appreciate having an additional milestone to do so. An extra 4 weeks may not be much time, but having any additional feedback from this partner experimenting would be helpful ahead of the launch. Can you also comment on substantial progress for the following (as > relevant), since the original OT? > > - Draft spec (early draft is ok, but must be spec-like and associated > with the appropriate standardization venue, or WICG) > > We have published a spec since the original OT, here <https://privacycg.github.io/storage-access-headers/>. A link can also be found in the platform status entry. > > - WPT tests > > We have written a suite of WPTs for Storage Access Headers that were recently merged into the wpt repo <https://github.com/web-platform-tests/wpt/pull/49502>. Best, Sam LeDoux On Tue, Dec 10, 2024, 8:14 AM Mike Taylor <miketa...@chromium.org> wrote: > On 12/9/24 3:39 PM, 'Sam LeDoux' via blink-dev wrote: > > Contact emails > > sled...@google.com, johann...@chromium.org, cfred...@chromium.org > > Explainer > > https://github.com/privacycg/storage-access-headers > > Specification > > https://privacycg.github.io/storage-access-headers > > Summary > > Storage Access Headers offer an alternate way for authenticated embeds to > opt in for unpartitioned cookies. These headers indicate whether embedded > resources would like to load with permission they have already been > granted, reducing loads and latency overall for these use cases. > > > Blink component > > Blink>StorageAccessAPI > <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EStorageAccessAPI> > > Search tags > > storage access api > <https://chromestatus.com/features#tags:storage%20access%20api>, storage > access headers > <https://chromestatus.com/features#tags:storage%20access%20headers> > > TAG review > > Not needed, per https://github.com/w3ctag/design-reviews/issues/982. > > TAG review status > > Not applicable > > (This should probably be changed to Resolution: satisfied, per the above > link) > > > Origin Trial Name > > Storage Access Headers > > Chromium Trial Name > > StorageAccessHeader > > Origin Trial documentation link > > https://github.com/cfredric/storage-access-headers > > WebFeature UseCounter name > > kStorageAccessAPI_requestStorageAccess_Method > > Risks > > Interoperability and Compatibility > > This feature poses minor compatibility risk, since the Origin header is > now included on requests that include the "Sec-Fetch-Storage-Access: > inactive" header - and some servers do not yet properly handle the Origin > header. However, this risk is low, because: > > * The "inactive" header is only included on clients that already block > third-party cookies. > > * The presence of the "inactive" header implies that the request is > cross-site, and that the site in question already uses the Storage Access > API (which is relatively new to the web platform) or that the context is an > "A > B > A" embedding scenario (which are not expected to be common). > > * This feature omits the Origin header from requests whose `credentials` > mode is not "include". > > > Gecko: No signal ( > https://github.com/mozilla/standards-positions/issues/1084) > > This is trending positive, but > https://github.com/mozilla/standards-positions/issues/1084#issuecomment-2471319900 > some possible renaming. Can we try to sort that out with Mozilla before > shipping? > > > WebKit: No signal ( > https://github.com/WebKit/standards-positions/issues/412) > > Web developers: Positive ( > https://github.com/privacycg/storage-access/issues/130) Other feature > requests: * https://github.com/privacycg/storage-access/issues/170 * > https://github.com/privacycg/storage-access/issues/189 > > Other signals: > > WebView application risks > > None > > > Goals for experimentation > > This experiment would allow us to receive and incorporate feedback on the > browser's application of the `Sec-Fetch-Storage-Access` request header, as > well as the browser's handling of the `Activate-Storage-Access` header > before the feature is fully launched. > > What feedback have you received so far from participants? > > Reason this experiment is being extended > > We are currently targeting M133 for the stable launch of Storage Access > Headers; therefore, we would like to extend the Origin Trial to last > through M132, as partners have expressed a desire to continue experimenting > with the Storage Access Headers feature up until it begins launching to > stable. > > This rationale sounds like using the OT as a soft-launch, which isn't > great. Do you think your partners will learn something in the requested > extra 4 weeks such that you might meaningfully incorporate the feedback > ahead of a launch? (I think the answer is probably no, but I'd love to hear > your perspective). > > Can you also comment on substantial progress for the following (as > relevant), since the original OT? > > - Draft spec (early draft is ok, but must be spec-like and associated > with the appropriate standardization venue, or WICG) > - TAG review (see exceptions) > - bit.ly/blink-signals requests > - Outreach for feedback from the spec community > - WPT tests > > > > Ongoing technical constraints > > None > > Debuggability > > Currently best debugged via chrome://net-export logs, as Chrome DevTools > does not show the full chain of network events. We may add improved > debugging capabilities in the future. > > > Will this feature be supported on all six Blink platforms (Windows, Mac, > Linux, ChromeOS, Android, and Android WebView)? > > No. > > Supported for Mac, Windows, Linux, Chrome OS, and Android. > > Is this feature fully tested by web-platform-tests > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> > ? > > Yes > > Flag name on chrome://flags > > #storage-access-headers > > Requires code in //chrome? > > Yes > > Tracking bug > > https://issues.chromium.org/issues/332335089 > > Launch bug > > https://launch.corp.google.com/launch/4309903 > > Estimated milestones > > Shipping on desktop > > 133 > > Origin trial desktop first > > 130 > > Origin trial desktop last > > 131 > > Origin trial extension 1 end milestone > > 132 > > DevTrial on desktop > > 130 > > Shipping on Android > > 133 > > Origin trial Android first > > 130 > > Origin trial Android last > > 131 > > DevTrial on Android > > 130 > > > Link to entry on the Chrome Platform Status > > https://chromestatus.com/feature/6146353156849664?gate=5788202676518912 > > Links to previous Intent discussions > > Intent to Prototype: > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABa1CXyMJzMmpQkZMwQUFGK8-f%3DEerhR2VQbTZephdmE22W%2ByA%40mail.gmail.com > > Intent to Experiment: > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABa1CXyYbxwh%3DPdnigTW80d9jez_835R1SV1bQPDjvk1ra5G4g%40mail.gmail.com > > > This intent message was generated by Chrome Platform Status > <https://chromestatus.com/>. > -- > 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 visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABa1CXxhJJVGame57-BhbW5r_XX2DgRaVcmo1fDu740S7b_hbg%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABa1CXxhJJVGame57-BhbW5r_XX2DgRaVcmo1fDu740S7b_hbg%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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABa1CXybMNNg34qATRY7mJ2Hxh%3D9H7391hV2fhLJ6HmuN2_x%3Dg%40mail.gmail.com.
