Following up on this - we'd like to amend this I2EE to request an extension for another *3* milestones, to M135, to give ourselves more buffer to resolve any issues. (We understand that a feature may run an origin trial for up to 6 milestones. The first release with this OT was M130.)
We still see shipping in M133 as a possibility, provided that we resolve Mozilla's outstanding concern quickly. We're working to do so and plan to send an I2S for review once it is resolved. On Wednesday, December 11, 2024 at 3:51:17 PM UTC-5 Sam LeDoux wrote: > Alex, > > Thank you for the context, and that caveat sounds fair. > To answer your question, we have not seen much traffic under the current > OT. > > Best, > Sam LeDoux > > On Wed, Dec 11, 2024 at 11:33 AM Alex Russell <slightly...@chromium.org> > wrote: > >> Hey Sam, >> >> Thanks for the updates. >> >> We discussed this at this morning's API OWNERS meeting, and given that >> there's some renaming risk, it sounds like there's support to extend you >> past the 1 extra milestone you're asking for under the caveat that breaking >> changes (e.g., a renaming) be implemented ASAP. Is there much traffic under >> the current OT? >> >> Best, >> >> Alex >> >> On Wednesday, December 11, 2024 at 5:06:24 AM UTC-8 Sam LeDoux wrote: >> >>> 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/9522d50a-c8a3-4d2c-88ec-51949b8b9e71n%40chromium.org.
