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
<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 <mailto:sled...@google.com>,
johann...@chromium.org
<mailto:johann...@chromium.org>,
cfred...@chromium.org <mailto:cfred...@chromium.org>
Explainer
https://github.com/privacycg/storage-access-headers
<https://github.com/privacycg/storage-access-headers>
Specification
https://privacycg.github.io/storage-access-headers
<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
<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
<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
<https://github.com/mozilla/standards-positions/issues/1084>)
This is trending positive, but
https://github.com/mozilla/standards-positions/issues/1084#issuecomment-2471319900
<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
<https://github.com/WebKit/standards-positions/issues/412>)
Web developers: Positive
(https://github.com/privacycg/storage-access/issues/130
<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/170>*
https://github.com/privacycg/storage-access/issues/189
<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 <http://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
<https://issues.chromium.org/issues/332335089>
Launch bug
https://launch.corp.google.com/launch/4309903
<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
<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
<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
<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
<mailto: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>.
