Re: [blink-dev] Re: Intent to Ship: WebGPU maxBindGroupsPlusVertexBuffers limit

[Philip Jägenstedt]

Hi François, Corentin,

I greped for "maxBindGroupsPlusVertexBuffers" in a checkout of
https://github.com/gpuweb/cts but couldn't find any tests. Should there be
shared tests there?

Best regards,
Philip

On Wed, Oct 25, 2023 at 4:25 PM Mike Taylor  wrote:

> LGTM2
> On 10/25/23 4:32 AM, 'François Beaufort' via blink-dev wrote:
>
>
>
> On Wed, Oct 25, 2023 at 10:28 AM Yoav Weiss 
> wrote:
>
>> LGTM1
>>
>> On Tuesday, October 24, 2023 at 3:32:23 PM UTC+2 blink-dev wrote:
>>
>> Contact emails
>>
>> fbeauf...@google.com, cwal...@google.com
>>
>> Specification
>>
>> https://gpuweb.github.io/gpuweb/#dom-gpusupportedlimits-
>> maxbindgroupsplusvertexbuffers
>>
>> Summary
>>
>> The WebGPU maxBindGroupsPlusVertexBuffers limit is the maximum number of
>> bind group and vertex buffer slots used simultaneously, counting any empty
>> slots below the highest index. It is validated in createRenderPipeline()
>> and in draw calls. This change adds maxBindGroupsPlusVertexBuffers to the
>> GPUSupportedLimits interface, and as an accepted key by the
>> GPUDeviceDescriptor.requiredLimits record.
>>
>> Blink component
>>
>> Blink>WebGPU
>> 
>>
>> TAG review
>>
>> None
>>
>>
>> Presumably not required as this has landed in the standard and
>> implemented by another engine.
>>
>
> Yes. It has landed in the WebGPU specification and it is added to other
> engines as shown below.
>
>
>>
>>
>>
>> TAG review status
>>
>> Not applicable
>>
>> Risks
>>
>> Interoperability and Compatibility
>>
>> The maxBindGroupsPlusVertexBuffers limit has not yet been implemented in
>> any browser, but it has been fully approved by the GPU for the Web
>> Community Group, with representatives from Safari, Firefox, and Chrome. See
>> https://github.com/gpuweb/gpuweb/issues/2749#issuecomment-1447717468
>>
>> Gecko: Positive (https://hg.mozilla.org/mozilla-central/rev/5ed1439037c4)
>>
>> WebKit: In development (https://github.com/WebKit/WebKit/commit/
>> 26f539228dd0a3ee85e38e886753c41955e93971)
>>
>>
>> I'm guessing this is implemented in both? I agree with your request on
>> another thread that it'd be simpler if we had a "stages" system here
>> similar to WASM and JS.
>>
>
> It is being implemented, yes. Linking to their repo was a way for me to
> show their support.
> Let's hope we'll have "stages" soon ;)
>
>
>>
>>
>>
>> Web developers: Positive (https://github.com/gpuweb/gpuweb/issues/2749)
>>
>> 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 at the moment, WebGPU currently does not ship on Android WebView.
>> Parallel work is occurring to launch WebGPU on Android.
>>
>>
>> Debuggability
>>
>> No DevTools changes are required, treated like any other attribute.
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)?
>>
>> No
>>
>> All platforms will eventually have support. Will immediately be available
>> on ChromeOS, Mac, and Windows, since those platforms already support
>> WebGPU. Linux and Android are planned to have WebGPU support in the future,
>> so this feature will become available when WebGPU does.
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?
>>
>> Yes
>>
>> WebGPU/WGSL have a conformance test suite (https://github.com/gpuweb/cts)
>> that is regularly pulled into Chromium and part of the testing of Dawn/Tint
>> in Chromium.
>>
>> Requires code in //chrome?
>>
>> False
>>
>> Tracking bug
>>
>> https://bugs.chromium.org/p/dawn/issues/detail?id=1849
>>
>> Availability expectation
>>
>> Feature is available only in Chromium browsers for the near future, on
>> the order of months. Other browsers intend to ship WebGPU support, but
>> don't have specified timelines.
>>
>> Non-OSS dependencies
>>
>> Does the feature depend on any code or APIs outside the Chromium open
>> source repository and its open-source dependencies to function?
>>
>> No
>>
>> Estimated milestones
>>
>> Shipping on desktop
>>
>> 120
>>
>> Anticipated spec changes
>>
>> Open questions about a feature may be a source of future web compat or
>> interop issues. Please list open issues (e.g. links to known github issues
>> in the project for the feature specification) whose resolution may
>> introduce web compat/interop risk (e.g., changing to naming or structure of
>> the API in a non-backward-compatible way).
>>
>> None
>>
>> Link to entry on the Chrome Platform Status
>>
>> https://chromestatus.com/feature/5081403763195904
>>
>> This intent message was generated by Chrome Platform Status
>> .
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and 

Re: [blink-dev] Re: Intent to Ship: WebGPU maxBindGroupsPlusVertexBuffers limit

['François Beaufort' via blink-dev]

Here's the CTS issue for maxBindGroupsPlusVertexBuffers:
https://github.com/gpuweb/cts/issues/2983
Once we'll have validation, we'll be able to add CTS tests. See
https://source.chromium.org/chromium/chromium/src/+/main:third_party/dawn/src/dawn/native/Device.cpp;l=1808;drc=b6a33c6fb6097fb097b7e60ad63cb552724cf60e
In the meantime, we have web platform tests to check its existence:
https://chromium-review.googlesource.com/c/chromium/src/+/4952541/3/third_party/blink/web_tests/virtual/stable/webexposed/global-interface-listing-expected.txt


On Fri, Oct 27, 2023 at 10:58 AM Philip Jägenstedt 
wrote:

> Hi François, Corentin,
>
> I greped for "maxBindGroupsPlusVertexBuffers" in a checkout of
> https://github.com/gpuweb/cts but couldn't find any tests. Should there
> be shared tests there?
>
> Best regards,
> Philip
>
> On Wed, Oct 25, 2023 at 4:25 PM Mike Taylor 
> wrote:
>
>> LGTM2
>> On 10/25/23 4:32 AM, 'François Beaufort' via blink-dev wrote:
>>
>>
>>
>> On Wed, Oct 25, 2023 at 10:28 AM Yoav Weiss 
>> wrote:
>>
>>> LGTM1
>>>
>>> On Tuesday, October 24, 2023 at 3:32:23 PM UTC+2 blink-dev wrote:
>>>
>>> Contact emails
>>>
>>> fbeauf...@google.com, cwal...@google.com
>>>
>>> Specification
>>>
>>> https://gpuweb.github.io/gpuweb/#dom-gpusupportedlimits-
>>> maxbindgroupsplusvertexbuffers
>>>
>>> Summary
>>>
>>> The WebGPU maxBindGroupsPlusVertexBuffers limit is the maximum number of
>>> bind group and vertex buffer slots used simultaneously, counting any empty
>>> slots below the highest index. It is validated in createRenderPipeline()
>>> and in draw calls. This change adds maxBindGroupsPlusVertexBuffers to the
>>> GPUSupportedLimits interface, and as an accepted key by the
>>> GPUDeviceDescriptor.requiredLimits record.
>>>
>>> Blink component
>>>
>>> Blink>WebGPU
>>> 
>>>
>>> TAG review
>>>
>>> None
>>>
>>>
>>> Presumably not required as this has landed in the standard and
>>> implemented by another engine.
>>>
>>
>> Yes. It has landed in the WebGPU specification and it is added to other
>> engines as shown below.
>>
>>
>>>
>>>
>>>
>>> TAG review status
>>>
>>> Not applicable
>>>
>>> Risks
>>>
>>> Interoperability and Compatibility
>>>
>>> The maxBindGroupsPlusVertexBuffers limit has not yet been implemented in
>>> any browser, but it has been fully approved by the GPU for the Web
>>> Community Group, with representatives from Safari, Firefox, and Chrome. See
>>> https://github.com/gpuweb/gpuweb/issues/2749#issuecomment-1447717468
>>>
>>> Gecko: Positive (https://hg.mozilla.org/mozilla-central/rev/5ed1439037c4
>>> )
>>>
>>> WebKit: In development (https://github.com/WebKit/WebKit/commit/
>>> 26f539228dd0a3ee85e38e886753c41955e93971)
>>>
>>>
>>> I'm guessing this is implemented in both? I agree with your request on
>>> another thread that it'd be simpler if we had a "stages" system here
>>> similar to WASM and JS.
>>>
>>
>> It is being implemented, yes. Linking to their repo was a way for me to
>> show their support.
>> Let's hope we'll have "stages" soon ;)
>>
>>
>>>
>>>
>>>
>>> Web developers: Positive (https://github.com/gpuweb/gpuweb/issues/2749)
>>>
>>> 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 at the moment, WebGPU currently does not ship on Android WebView.
>>> Parallel work is occurring to launch WebGPU on Android.
>>>
>>>
>>> Debuggability
>>>
>>> No DevTools changes are required, treated like any other attribute.
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>>> Linux, Chrome OS, Android, and Android WebView)?
>>>
>>> No
>>>
>>> All platforms will eventually have support. Will immediately be
>>> available on ChromeOS, Mac, and Windows, since those platforms already
>>> support WebGPU. Linux and Android are planned to have WebGPU support in the
>>> future, so this feature will become available when WebGPU does.
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?
>>>
>>> Yes
>>>
>>> WebGPU/WGSL have a conformance test suite (https://github.com/gpuweb/cts)
>>> that is regularly pulled into Chromium and part of the testing of Dawn/Tint
>>> in Chromium.
>>>
>>> Requires code in //chrome?
>>>
>>> False
>>>
>>> Tracking bug
>>>
>>> https://bugs.chromium.org/p/dawn/issues/detail?id=1849
>>>
>>> Availability expectation
>>>
>>> Feature is available only in Chromium browsers for the near future, on
>>> the order of months. Other browsers intend to ship WebGPU support, but
>>> don't have specified timelines.
>>>
>>> Non-OSS dependencies
>>>
>>> Does the feature depend on any code or APIs outside the Chromium open
>>> source repository and its open-source dependencies to function?
>>>
>>> No
>>>
>>> Estimated milestones
>>

Re: [blink-dev] Re: Intent to Ship: WebGPU maxBindGroupsPlusVertexBuffers limit

[Philip Jägenstedt]

LGTM3 given some basic tests added to CTS.

François discussed in chat, and some basic tests are possible to confirm
existence and relationship to other attributes, tracked by
https://github.com/gpuweb/cts/issues/3106.

On Fri, Oct 27, 2023 at 11:13 AM François Beaufort 
wrote:

> Here's the CTS issue for maxBindGroupsPlusVertexBuffers:
> https://github.com/gpuweb/cts/issues/2983
> Once we'll have validation, we'll be able to add CTS tests. See
> https://source.chromium.org/chromium/chromium/src/+/main:third_party/dawn/src/dawn/native/Device.cpp;l=1808;drc=b6a33c6fb6097fb097b7e60ad63cb552724cf60e
> In the meantime, we have web platform tests to check its existence:
> https://chromium-review.googlesource.com/c/chromium/src/+/4952541/3/third_party/blink/web_tests/virtual/stable/webexposed/global-interface-listing-expected.txt
>
>
> On Fri, Oct 27, 2023 at 10:58 AM Philip Jägenstedt 
> wrote:
>
>> Hi François, Corentin,
>>
>> I greped for "maxBindGroupsPlusVertexBuffers" in a checkout of
>> https://github.com/gpuweb/cts but couldn't find any tests. Should there
>> be shared tests there?
>>
>> Best regards,
>> Philip
>>
>> On Wed, Oct 25, 2023 at 4:25 PM Mike Taylor 
>> wrote:
>>
>>> LGTM2
>>> On 10/25/23 4:32 AM, 'François Beaufort' via blink-dev wrote:
>>>
>>>
>>>
>>> On Wed, Oct 25, 2023 at 10:28 AM Yoav Weiss 
>>> wrote:
>>>
 LGTM1

 On Tuesday, October 24, 2023 at 3:32:23 PM UTC+2 blink-dev wrote:

 Contact emails

 fbeauf...@google.com, cwal...@google.com

 Specification

 https://gpuweb.github.io/gpuweb/#dom-gpusupportedlimits-
 maxbindgroupsplusvertexbuffers

 Summary

 The WebGPU maxBindGroupsPlusVertexBuffers limit is the maximum number
 of bind group and vertex buffer slots used simultaneously, counting any
 empty slots below the highest index. It is validated in
 createRenderPipeline() and in draw calls. This change adds
 maxBindGroupsPlusVertexBuffers to the GPUSupportedLimits interface, and as
 an accepted key by the GPUDeviceDescriptor.requiredLimits record.

 Blink component

 Blink>WebGPU
 

 TAG review

 None


 Presumably not required as this has landed in the standard and
 implemented by another engine.

>>>
>>> Yes. It has landed in the WebGPU specification and it is added to other
>>> engines as shown below.
>>>
>>>



 TAG review status

 Not applicable

 Risks

 Interoperability and Compatibility

 The maxBindGroupsPlusVertexBuffers limit has not yet been implemented
 in any browser, but it has been fully approved by the GPU for the Web
 Community Group, with representatives from Safari, Firefox, and Chrome. See
 https://github.com/gpuweb/gpuweb/issues/2749#issuecomment-1447717468

 Gecko: Positive (https://hg.mozilla.org/mozilla-central/rev/
 5ed1439037c4)

 WebKit: In development (https://github.com/WebKit/WebKit/commit/
 26f539228dd0a3ee85e38e886753c41955e93971)


 I'm guessing this is implemented in both? I agree with your request on
 another thread that it'd be simpler if we had a "stages" system here
 similar to WASM and JS.

>>>
>>> It is being implemented, yes. Linking to their repo was a way for me to
>>> show their support.
>>> Let's hope we'll have "stages" soon ;)
>>>
>>>



 Web developers: Positive (https://github.com/gpuweb/gpuweb/issues/2749)

 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 at the moment, WebGPU currently does not ship on Android WebView.
 Parallel work is occurring to launch WebGPU on Android.


 Debuggability

 No DevTools changes are required, treated like any other attribute.

 Will this feature be supported on all six Blink platforms (Windows,
 Mac, Linux, Chrome OS, Android, and Android WebView)?

 No

 All platforms will eventually have support. Will immediately be
 available on ChromeOS, Mac, and Windows, since those platforms already
 support WebGPU. Linux and Android are planned to have WebGPU support in the
 future, so this feature will become available when WebGPU does.

 Is this feature fully tested by web-platform-tests
 
 ?

 Yes

 WebGPU/WGSL have a conformance test suite (
 https://github.com/gpuweb/cts) that is regularly pulled into Chromium
 and part of the testing of Dawn/Tint in Chromium.

 Requires code in //chrome?

 False

 Tracking bug

 https://bugs.chromium.org/p/dawn/issues/detail?id=1849

Re: [blink-dev] Intent to Ship: CSS masking

[Philip Jägenstedt]

LGTM1

Thanks for writing that up, Philip! I believe that should be helpful for
release notes and MDN docs down the line.

On Thu, Oct 26, 2023 at 7:20 PM 'Philip Rogers' via blink-dev <
blink-dev@chromium.org> wrote:

>
>
> On Wednesday, October 25, 2023 at 7:24:34 AM UTC-7 Mike Taylor wrote:
>
> On 10/25/23 10:00 AM, Philip Rogers wrote:
>
> Contact emails p...@chromium.org, tca...@chromium.org, yo...@chromium.org
> , f...@opera.com
>
> Explainer None
>
> Specification https://drafts.fxtf.org/css-masking/#positioned-masks
>
> Design docs https://developer.mozilla.org/en-US/docs/Web/CSS/mask
>
> Summary
>
> CSS mask, and related properties such as mask-image, mask-mode, etc, are
> used to hide an element (partially or fully) by masking or clipping the
> image at specific points. This feature unprefixes the -webkit-mask*
> properties and brings them up to spec. This includes mask-image, mask-mode,
> mask-repeat, mask-position, mask-clip, mask-origin, mask-size, and
> mask-composite, as well as the "mask" shorthand. Local mask-image
> references are supported, serialization now matches the spec, and accepted
> values now match the spec (for example, "add" instead of "source-over" for
> mask-composite).
>
>
> Blink component Blink>CSS
> 
>
> TAG review None
>
> TAG review status Not applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> There is some compatibility risk in adding an unprefixed feature while
> still supporting the prefixed version. This is minimized as we are
> following the same pattern Webkit has already shipped. In addition, Firefox
> supports several of the legacy -webkit- prefixed properties too.
>
> Is there anywhere that documents the differences, beyond what is written
> in the summary? It would be nice if we can capture that in the Compat
> standard, where they are no longer simple aliases.
>
>
> Good idea. I've created a document describing the differences at the
> following link:
>
> https://docs.google.com/document/d/14TtdFgYJ6TJuVzSE2Ra_gtuy20VNRgIKcbwiF3hg9aQ/preview?usp=sharing
>
>
>
>
> *Gecko*: Shipped/Shipping Firefox has nearly 100% pass rate on
> css-masking WPT tests.
>
> *WebKit*: Shipped/Shipping Safari has shipped much of the unprefixing of
> these properties (https://bugs.webkit.org/show_bug.cgi?id=229082), as
> well as many implementation improvements, though some interop fixes are
> still in development.
>
> *Web developers*: Strongly positive (
> https://github.com/web-platform-tests/interop/issues/148) This is part of
> interop-2023.
>
> *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
>
> Basic debugging support with existing CSS support in devtools.
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)? Yes
>
> Is this feature fully tested by web-platform-tests
> 
> ? Yes
>
>
> https://wpt.fyi/results/css/css-masking?label=master&label=experimental&product=chrome&product=firefox&product=safari&aligned&view=interop
>
>
> Flag name on chrome://flags None
>
> Finch feature name CSSMaskingInterop
>
> Requires code in //chrome? False
>
> Tracking bug https://crbug.com/1418401
>
> Measurement https://chromestatus.com/metrics/css/timeline/popularity/772
>
> Estimated milestones Shipping on desktop 120 DevTrial on desktop 120 Shipping
> on Android 120 DevTrial on Android 120 Shipping on WebView 120
>
> Anticipated spec changes
>
> Open questions about a feature may be a source of future web compat or
> interop issues. Please list open issues (e.g. links to known github issues
> in the project for the feature specification) whose resolution may
> introduce web compat/interop risk (e.g., changing to naming or structure of
> the API in a non-backward-compatible way).
> None
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5839739127332864
>
> Links to previous Intent discussions Intent to prototype:
> https://groups.google.com/a/chromium.org/g/blink-dev/c/C6hENTlF0NM
>
> This intent message was generated by Chrome Platform Status
> .
>
> --
> 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+...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJgFLLsO8COSdLuHsEaM2TQWzAf6%2B5wJLt0PcR3QEoyyOb4Rhw%40mail.gmail.com
> 
> .
>
> --

Re: [blink-dev] Intent to Ship: CSS masking

[Mike Taylor]

LGTM2.

(I filed https://github.com/whatwg/compat/issues/252 - thanks for the doc!)

On 10/27/23 5:55 AM, Philip Jägenstedt wrote:

LGTM1

Thanks for writing that up, Philip! I believe that should be helpful 
for release notes and MDN docs down the line.


On Thu, Oct 26, 2023 at 7:20 PM 'Philip Rogers' via blink-dev 
 wrote:




On Wednesday, October 25, 2023 at 7:24:34 AM UTC-7 Mike Taylor wrote:

On 10/25/23 10:00 AM, Philip Rogers wrote:


Contact emails p...@chromium.org, tca...@chromium.org,
yo...@chromium.org, f...@opera.com

Explainer None

Specification
https://drafts.fxtf.org/css-masking/#positioned-masks

Design docs https://developer.mozilla.org/en-US/docs/Web/CSS/mask

Summary

CSS mask, and related properties such as mask-image,
mask-mode, etc, are used to hide an element (partially or
fully) by masking or clipping the image at specific points.
This feature unprefixes the -webkit-mask* properties and
brings them up to spec. This includes mask-image, mask-mode,
mask-repeat, mask-position, mask-clip, mask-origin,
mask-size, and mask-composite, as well as the "mask"
shorthand. Local mask-image references are supported,
serialization now matches the spec, and accepted values now
match the spec (for example, "add" instead of "source-over"
for mask-composite).



Blink component Blink>CSS



TAG review None

TAG review status Not applicable

Risks


Interoperability and Compatibility

There is some compatibility risk in adding an unprefixed
feature while still supporting the prefixed version. This is
minimized as we are following the same pattern Webkit has
already shipped. In addition, Firefox supports several of the
legacy -webkit- prefixed properties too.


Is there anywhere that documents the differences, beyond what
is written in the summary? It would be nice if we can capture
that in the Compat standard, where they are no longer simple
aliases.


Good idea. I've created a document describing the differences at
the following link:

https://docs.google.com/document/d/14TtdFgYJ6TJuVzSE2Ra_gtuy20VNRgIKcbwiF3hg9aQ/preview?usp=sharing




/Gecko/: Shipped/Shipping Firefox has nearly 100% pass rate
on css-masking WPT tests.

/WebKit/: Shipped/Shipping Safari has shipped much of the
unprefixing of these properties
(https://bugs.webkit.org/show_bug.cgi?id=229082), as well as
many implementation improvements, though some interop fixes
are still in development.

/Web developers/: Strongly positive
(https://github.com/web-platform-tests/interop/issues/148)
This is part of interop-2023.

/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

Basic debugging support with existing CSS support in devtools.



Will this feature be supported on all six Blink platforms
(Windows, Mac, Linux, Chrome OS, Android, and Android
WebView)? Yes

Is this feature fully tested by web-platform-tests

?
Yes


https://wpt.fyi/results/css/css-masking?label=master&label=experimental&product=chrome&product=firefox&product=safari&aligned&view=interop





Flag name on chrome://flags None

Finch feature name CSSMaskingInterop

Requires code in //chrome? False

Tracking bug https://crbug.com/1418401

Measurement
https://chromestatus.com/metrics/css/timeline/popularity/772

Estimated milestones Shipping on desktop 120 DevTrial on
desktop 120 Shipping on Android 120 DevTrial on Android 120
Shipping on WebView 120

Anticipated spec changes

Open questions about a feature may be a source of future web
compat or interop issues. Please list open issues (e.g. links
to known github issues in the project for the feature
specification) whose resolution may introduce web
compat/interop risk (e.g., changing to naming or structure of
the API in a non-backward-compatible way).

None

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5839739127332864

Links to previous Intent discussions Intent to prototype:
https:/

Re: [blink-dev] Intent to Ship: CSS masking

[Chris Harrelson]

LGTM3

On Fri, Oct 27, 2023, 4:24 AM Mike Taylor  wrote:

> LGTM2.
>
> (I filed https://github.com/whatwg/compat/issues/252 - thanks for the
> doc!)
> On 10/27/23 5:55 AM, Philip Jägenstedt wrote:
>
> LGTM1
>
> Thanks for writing that up, Philip! I believe that should be helpful for
> release notes and MDN docs down the line.
>
> On Thu, Oct 26, 2023 at 7:20 PM 'Philip Rogers' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>>
>>
>> On Wednesday, October 25, 2023 at 7:24:34 AM UTC-7 Mike Taylor wrote:
>>
>> On 10/25/23 10:00 AM, Philip Rogers wrote:
>>
>> Contact emails p...@chromium.org, tca...@chromium.org, yo...@chromium.org
>> , f...@opera.com
>>
>> Explainer None
>>
>> Specification https://drafts.fxtf.org/css-masking/#positioned-masks
>>
>> Design docs https://developer.mozilla.org/en-US/docs/Web/CSS/mask
>>
>> Summary
>>
>> CSS mask, and related properties such as mask-image, mask-mode, etc, are
>> used to hide an element (partially or fully) by masking or clipping the
>> image at specific points. This feature unprefixes the -webkit-mask*
>> properties and brings them up to spec. This includes mask-image, mask-mode,
>> mask-repeat, mask-position, mask-clip, mask-origin, mask-size, and
>> mask-composite, as well as the "mask" shorthand. Local mask-image
>> references are supported, serialization now matches the spec, and accepted
>> values now match the spec (for example, "add" instead of "source-over" for
>> mask-composite).
>>
>>
>> Blink component Blink>CSS
>> 
>>
>> TAG review None
>>
>> TAG review status Not applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> There is some compatibility risk in adding an unprefixed feature while
>> still supporting the prefixed version. This is minimized as we are
>> following the same pattern Webkit has already shipped. In addition, Firefox
>> supports several of the legacy -webkit- prefixed properties too.
>>
>> Is there anywhere that documents the differences, beyond what is written
>> in the summary? It would be nice if we can capture that in the Compat
>> standard, where they are no longer simple aliases.
>>
>>
>> Good idea. I've created a document describing the differences at the
>> following link:
>>
>> https://docs.google.com/document/d/14TtdFgYJ6TJuVzSE2Ra_gtuy20VNRgIKcbwiF3hg9aQ/preview?usp=sharing
>>
>>
>>
>>
>> *Gecko*: Shipped/Shipping Firefox has nearly 100% pass rate on
>> css-masking WPT tests.
>>
>> *WebKit*: Shipped/Shipping Safari has shipped much of the unprefixing of
>> these properties (https://bugs.webkit.org/show_bug.cgi?id=229082), as
>> well as many implementation improvements, though some interop fixes are
>> still in development.
>>
>> *Web developers*: Strongly positive (
>> https://github.com/web-platform-tests/interop/issues/148) This is part
>> of interop-2023.
>>
>> *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
>>
>> Basic debugging support with existing CSS support in devtools.
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)? Yes
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ? Yes
>>
>>
>> https://wpt.fyi/results/css/css-masking?label=master&label=experimental&product=chrome&product=firefox&product=safari&aligned&view=interop
>>
>>
>> Flag name on chrome://flags None
>>
>> Finch feature name CSSMaskingInterop
>>
>> Requires code in //chrome? False
>>
>> Tracking bug https://crbug.com/1418401
>>
>> Measurement https://chromestatus.com/metrics/css/timeline/popularity/772
>>
>> Estimated milestones Shipping on desktop 120 DevTrial on desktop 120 Shipping
>> on Android 120 DevTrial on Android 120 Shipping on WebView 120
>>
>> Anticipated spec changes
>>
>> Open questions about a feature may be a source of future web compat or
>> interop issues. Please list open issues (e.g. links to known github issues
>> in the project for the feature specification) whose resolution may
>> introduce web compat/interop risk (e.g., changing to naming or structure of
>> the API in a non-backward-compatible way).
>> None
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5839739127332864
>>
>> Links to previous Intent discussions Intent to prototype:
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/C6hENTlF0NM
>>
>> This intent message was generated by Chrome Platform Status
>> .
>>
>> --
>> 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+...@chromium.org.
>> To view

Re: [blink-dev] Intent to Experiment: Cookie Deprecation Labeling

[Rick Byers]

Exposing a new header and JS API temporarily for the purposes of an
experiment (outside the context of an OT) is not something we've ever done
before. But given the scope and requirements of this experiment and our
desire to help enable the ecosystem to reason about it, it seems absolutely
like the right pragmatic approach to me. Burn in risk seems like it would
be low even at 100%, and effectively zero due to the 10% exposure. I don't
see any interop concerns given that this API is useful only for
understanding Chrome-specific behavior variation.

LGTM1 to "experiment" with this, but I'd like to get two other LGTMs given
that it's a very unusual I2E.


On Wed, Oct 25, 2023 at 5:06 PM John Delaney  wrote:

> *Contact emails*
> johni...@chromium.org, wanderv...@chromium.org, lin...@chromium.org
>
> *Explainer*
>
> https://github.com/privacysandbox/tpcd-labeling/blob/main/cookie_deprecation_labeling_explainer.md
> https://developer.chrome.com/en/docs/privacy-sandbox/chrome-testing
>
> *Specification*
> None
>
> *Summary*
> To prepare for the third-party cookie deprecation, it is important to
> understand the full impact of Chrome’s planned transition from third-party
> cookies to the Privacy Sandbox Ads APIs.
>
> This experiment exposes a temporary set of APIs which provide access to
> browser-determined treatment and control groups to support opt-in server
> side testing of the third-party cookie deprecation.
>
> *Blink component*
> A-N/A
>
> *TAG review*
> Not requesting TAG review as this API is a temporary Chrome-specific
> experiment.
>
> *Risks*
>
> *Interoperability and Compatibility*
> This feature is only shipping in Chrome to support the third-party cookie
> deprecation, and will not be interoperable with other vendors.
>
> *WebView application risks*
> Not available on WebView
>
>
> *Goals for experimentation*
> The goal of this experiment is to allow adtechs to evaluate the impact of
> third party cookie phase out through opt-in server side testing. We expect
> partners to run experiments downstream from the browser provided treatment
> and control groups.
>
> *Experiment Behavior and Risks*
> This experiment will expose temporary APIs which allow access to browser
> provided experiment labels.
>
> To ensure all parties can easily get access to labels, we intend to expose
> the APIs without a traditional origin trial.
>
> To limit burn-in risk, the new APIs will only be available to at most ~10%
> of users. These APIs should have very little utility to developers outside
> of this specific temporary experiment, it seems unlikely that user-visible
> breakage would occur as a result of the eventual removal.
>
> *Timeline*
> We intend to remove the labeling APIs when Mode B of the experiment ends,
> which we expect to be by the end of Q2 2024 at the earliest.
>
> This experiment temporarily adds a new surface to the web that could be
> used for active fingerprinting. This is mitigated by the fact that:
>
>- only a subset are assigned labels, reducing the usefulness of the
>label for fingerprinting
>- labels are not sent for users who block third-party cookies, to
>ensure consistency with those users’ current settings
>- the labeling APIs will be removed by the time third-party cookies
>are phased out
>- label assignment is independent of users' browsing activity
>
>
> *Ongoing technical constraints*
> None
>
> *Debuggability*
> None
>
> *Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?*
> No, not supported on WebView.
>
> *Is this feature fully tested by web-platform-tests?*
> No
>
> *Flag name on chrome://flags*
> #tpc-phase-out-facilitated-testing
>
> *Requires code in //chrome?*
> False
>
> *Estimated milestones*
>   Experiment desktop first 119
>   Experiment Android first 119
>
> *Intent to Prototype*
>
> https://groups.google.com/a/chromium.org/g/blink-dev/c/8mlWTOcEzcA/m/NZJSW0weAQAJ
>
> *Link to entry on the Chrome Platform Status*
> https://chromestatus.com/feature/5189079788683264
>
> --
> 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/232aa6ed-bb1e-4954-b290-f178b7edd7c1n%40chromium.org
> 
> .
>

-- 
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/CAFUtAY8UhQ%2BVm2NJDZRwF0wvmO-WkVdexPMgT%3DKh07NWauUmKg%

[blink-dev] Web-Facing Change PSA: Set IndexedDB transaction durability to `relaxed` by default

[Evan Stade]

Contact emailsest...@chromium.org, a...@chromium.org

Specificationhttps://www.w3.org/TR/IndexedDB

Summary

IndexedDB offers two durability modes for readwrite transactions: `relaxed`
and `strict`. This may be specified via the optional `options` struct when
creating a transaction. See
https://developer.mozilla.org/en-US/docs/Web/API/IDBDatabase/transaction
for more details. If not specified, the current default in Chromium is
`strict`. Due to performance considerations, we plan to change the default
to `relaxed`, which also aligns Chromium with FireFox and Safari.


Blink componentBlink>Storage>IndexedDB


Search tagsIndexedDB ,
fsync , durability
, relaxed
, strict


TAG reviewNone

TAG review statusNot applicable

Risks


Interoperability and Compatibility

This change aligns Chromium with the behavior of other major browser
vendors (behavior which is left up to the implementation in the standard),
so it is improving interoperability. There is some historical context here:
https://github.com/w3c/IndexedDB/issues/50


*Gecko*: N/A

*WebKit*: N/A

*Web developers*: No signals

*Other signals*:

Ergonomics

No new API surface.


Security

No known security implications. No extensions to behavior that wasn't
already accessible to web apps without security or privacy controls.


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

No new DevTools support (but DevTools support for IndexedDB is already
good).


Will this feature be supported on all six Blink platforms (Windows, Mac,
Linux, Chrome OS, Android, and Android WebView)?Yes

Is this feature fully tested by web-platform-tests

?Yes

https://wpt.fyi/results/IndexedDB?label=master&label=experimental&aligned&q=indexeddb


Flag name on chrome://flagsindexed-db-default-durability-relaxed

Finch feature nameDefaultBucketUsesRelaxedDurability

Requires code in //chrome?False

Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=965883

Estimated milestones
Shipping on desktop 121
DevTrial on desktop 120
Shipping on Android 121
DevTrial on Android 120
Shipping on WebView 121

Anticipated spec changes

Open questions about a feature may be a source of future web compat or
interop issues. Please list open issues (e.g. links to known github issues
in the project for the feature specification) whose resolution may
introduce web compat/interop risk (e.g., changing to naming or structure of
the API in a non-backward-compatible way).
None

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5084460341264384

This intent message was generated by Chrome Platform Status
.


-- Evan Stade

-- 
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/CAO4XGS9bwW-Tv2D9WtwF5C3%3D1VeRea0CqyJZTZQMkF2kJ2iWMg%40mail.gmail.com.

[blink-dev] Re: Intent to Ship: Shared Storage API Enhancements

[Cammie Smith Barnes]

FYI: Update Shared Storage API HTTP request header name to
'Sec-Shared-Storage-Writable'

As previously mentioned in our Intent to Ship, as part of the M119
Enhancements to the Shared Storage API
, M119 will allow
writing and deleting from Shared Storage via HTTP response header. The
details can be found in the explainer
 with examples
,
as well as in the specification
.

The HTTP request header name for requests that opt-in and are eligible was
originally specified as  'Shared-Storage-Writable'. For Chrome stable
versions 119 and later, however, the HTTP request header name has been
updated to 'Sec-Shared-Storage-Writable' as discussed in pull requests #120
 and #121
.

Hence, the new request header attached to eligible outgoing requests will
be 'Sec-Shared-Storage-Writable: ?1'.


On Wed, Sep 27, 2023 at 2:13 PM Cammie Smith Barnes 
wrote:

> Contact emails
>
> cam...@chromium.org
>
> jkar...@chromium.org
>
> ale...@chromium.org
>
> yao...@chromium.org
>
> Explainer
>
> https://github.com/WICG/shared-storage
>
> Specification
>
> https://wicg.github.io/shared-storage/
>
> Summary
>
> We plan to ship the following changes to the Shared Storage API:
>
>1.
>
>Only allow Private Aggregation reports for up to 5 seconds after a
>worklet operation starts
>1.
>
>   This is a privacy measure to prevent timing attacks.
>   2.
>
>   Reports sent after this point are silently dropped
>   2.
>
>Allow writing to and deleting from Shared Storage via HTTP response
>header
>1.
>
>   This is a performance improvement and is backwards compatible
>   3.
>
>Per-site privacy budgeting
>1.
>
>   This change enforces budgets to per-site rather than per-origin
>
>
> Blink component
>
> Blink>Storage>SharedStorage
> 
>
>
>
>
> Risks
>
>
> Interoperability and Compatibility
>
> Change [1] will drop the private aggregation contributions issued after 5
> seconds after a worklet operation starts. 5 seconds should be sufficient
> for all known use cases, so this change should have negligible backward
> compatibility issues.
>
> Change [2] is optional and fully backwards compatible.
>
> Change [3] could decrease budget for those that are using multiple origins
> today that are considered part of the same eTLD+1. Since the API is new
> (shipped in M115), the expectation is for the impact to be low. It will not
> break script since the APIs gracefully handle situations where the budget
> is exceeded, but could impact the overall quality of the returned data for
> that site.
>
> Gecko: No signal
>
> WebKit: No signal
>
> Web developers: No signals
>
> 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
>
> Shared Storage database contents for an origin can be viewed and modified
> within devtools. Support for debugging Shared Storage worklets will be
> available within the next couple of milestones.
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?
>
> All but WebView
>
> Is this feature fully tested by web-platform-tests
> 
> ?
>
> Yes
>
> Flag name
>
> Finch feature name
>
> SharedStorageAPIM118
>
> Requires code in //chrome?
>
> No
>
> Estimated milestones
>
> We intend to ship in  M119.
>
> Anticipated spec changes
>
>1.
>
>Timeout enforcement:
>https://github.com/patcg-individual-drafts/private-aggregation-api/pull/102
>2.
>
>Allow writing to Shared Storage via response headers
>
> https://github.com/WICG/shared-storage/pull/110
>
>1.
>
>Per-site privacy budgeting
>
> https://github.com/WICG/shared-storage/pull/118
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5112254843846656
>
>

-- 
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/CAJ8xcq4koZH%3DhN8bK2J66Yhbvm8qfeQRk6wFhqEcu_b8tA%2Bubw%40mail.gmail.com.

Re: [blink-dev] Intent to Experiment: Cookie Deprecation Labeling

[Ben Kelly]

FYI, the specific labels to be sent are listed here:

https://developer.chrome.com/en/docs/privacy-sandbox/chrome-testing/#mode-a

Specifically, the "label_only_1", "label_only_2", "label_only_3",
"label_only_4", and "label_only_5" labels.  Note, the "control_1.*" labels
are not being enabled yet.

On Fri, Oct 27, 2023 at 3:27 PM Rick Byers  wrote:

> Exposing a new header and JS API temporarily for the purposes of an
> experiment (outside the context of an OT) is not something we've ever done
> before. But given the scope and requirements of this experiment and our
> desire to help enable the ecosystem to reason about it, it seems absolutely
> like the right pragmatic approach to me. Burn in risk seems like it would
> be low even at 100%, and effectively zero due to the 10% exposure. I don't
> see any interop concerns given that this API is useful only for
> understanding Chrome-specific behavior variation.
>
> LGTM1 to "experiment" with this, but I'd like to get two other LGTMs given
> that it's a very unusual I2E.
>
>
> On Wed, Oct 25, 2023 at 5:06 PM John Delaney 
> wrote:
>
>> *Contact emails*
>> johni...@chromium.org, wanderv...@chromium.org, lin...@chromium.org
>>
>> *Explainer*
>>
>> https://github.com/privacysandbox/tpcd-labeling/blob/main/cookie_deprecation_labeling_explainer.md
>> https://developer.chrome.com/en/docs/privacy-sandbox/chrome-testing
>>
>> *Specification*
>> None
>>
>> *Summary*
>> To prepare for the third-party cookie deprecation, it is important to
>> understand the full impact of Chrome’s planned transition from third-party
>> cookies to the Privacy Sandbox Ads APIs.
>>
>> This experiment exposes a temporary set of APIs which provide access to
>> browser-determined treatment and control groups to support opt-in server
>> side testing of the third-party cookie deprecation.
>>
>> *Blink component*
>> A-N/A
>>
>> *TAG review*
>> Not requesting TAG review as this API is a temporary Chrome-specific
>> experiment.
>>
>> *Risks*
>>
>> *Interoperability and Compatibility*
>> This feature is only shipping in Chrome to support the third-party cookie
>> deprecation, and will not be interoperable with other vendors.
>>
>> *WebView application risks*
>> Not available on WebView
>>
>>
>> *Goals for experimentation*
>> The goal of this experiment is to allow adtechs to evaluate the impact of
>> third party cookie phase out through opt-in server side testing. We expect
>> partners to run experiments downstream from the browser provided treatment
>> and control groups.
>>
>> *Experiment Behavior and Risks*
>> This experiment will expose temporary APIs which allow access to browser
>> provided experiment labels.
>>
>> To ensure all parties can easily get access to labels, we intend to
>> expose the APIs without a traditional origin trial.
>>
>> To limit burn-in risk, the new APIs will only be available to at most
>> ~10% of users. These APIs should have very little utility to developers
>> outside of this specific temporary experiment, it seems unlikely that
>> user-visible breakage would occur as a result of the eventual removal.
>>
>> *Timeline*
>> We intend to remove the labeling APIs when Mode B of the experiment ends,
>> which we expect to be by the end of Q2 2024 at the earliest.
>>
>> This experiment temporarily adds a new surface to the web that could be
>> used for active fingerprinting. This is mitigated by the fact that:
>>
>>- only a subset are assigned labels, reducing the usefulness of the
>>label for fingerprinting
>>- labels are not sent for users who block third-party cookies, to
>>ensure consistency with those users’ current settings
>>- the labeling APIs will be removed by the time third-party cookies
>>are phased out
>>- label assignment is independent of users' browsing activity
>>
>>
>> *Ongoing technical constraints*
>> None
>>
>> *Debuggability*
>> None
>>
>> *Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)?*
>> No, not supported on WebView.
>>
>> *Is this feature fully tested by web-platform-tests?*
>> No
>>
>> *Flag name on chrome://flags*
>> #tpc-phase-out-facilitated-testing
>>
>> *Requires code in //chrome?*
>> False
>>
>> *Estimated milestones*
>>   Experiment desktop first 119
>>   Experiment Android first 119
>>
>> *Intent to Prototype*
>>
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/8mlWTOcEzcA/m/NZJSW0weAQAJ
>>
>> *Link to entry on the Chrome Platform Status*
>> https://chromestatus.com/feature/5189079788683264
>>
>> --
>> 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/232aa6ed-bb1e-4954-b290-f178b7edd7c1n%40chromium.org
>> 

Re: [blink-dev] Intent to Ship: MediaCapabilities: Query HDR support with decodingInfo()

[Dale Curtis]

Looks like this got approved on chrome status, but is still missing an
LGTM3. Anyone else want to weigh in?

- dale

On Wed, Oct 25, 2023 at 12:35 PM Mike Taylor  wrote:

> LGTM2
> On 10/25/23 3:06 PM, 'Rick Byers' via blink-dev wrote:
>
> Looks pretty straightforward to me, especially with Safari already
> shipping. LGTM1
>
> On Wed, Oct 18, 2023 at 7:18 PM Dale Curtis 
> wrote:
>
>> Contact emails v...@microsoft.com, gw...@microsoft.com,
>> gur...@microsoft.com, dalecur...@chromium.org
>>
>> Explainer
>> https://github.com/w3c/media-capabilities/blob/main/explainer.md#decode-capabilities
>>
>> Specification https://www.w3.org/TR/media-capabilities/#hdrmetadatatype
>>
>> Summary
>>
>> Extends the Media Capabilities API to allow detection of HDR rendering
>> support via three new VideoConfiguration dictionary fields:
>> hdrMetadataType, colorGamut, transferFunction. Chromium implements its own
>> tone-mapping algorithms so will always return true for HDR10 (smpteSt2086)
>> static metadata. HDR10+ (smpteSt2094-10) and Dolby Vision (smpteSt2094-40)
>> dynamic metadata are not currently supported, so will return false. We
>> anticipate adding support for dynamic metadata in the future, so this API
>> will allow developers to select the appropriate content for users with
>> support.
>>
>>
>> Blink component Blink>Media>Capabilities
>> 
>>
>> TAG review Already shipping by another UA. The now-closed Media
>> Capabilities TAG review covered similar discussions:
>> https://github.com/w3ctag/design-reviews/issues/218
>>
>> TAG review status Not applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> Low interop risk: Already shipping in Safari.
>>
>>
>> *Gecko*: Neutral (
>> https://github.com/mozilla/standards-positions/issues/910)
>>
>> *WebKit*: Shipped/Shipping (
>> https://www.w3.org/2019/11/19-mediawg-minutes.html)
>>
>> *Web developers*: Positive (
>> https://github.com/w3c/media-capabilities/issues/118#issuecomment-511461132
>> )
>>
>> *Other signals*:
>>
>> Activation
>>
>> Will start returning false for some DolbyVision and HDR10+ metadata types
>> on the web -- playback would have been broken already for these.
>>
>>
>> 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?
>>
>> No risks unique to WebView.
>>
>>
>> Debuggability
>>
>> Debuggable through media dev tools and chrome://gpu information.
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)? Yes
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ? Yes
>>
>>
>> https://wpt.fyi/results/media-capabilities/decodingInfo.any.html?label=experimental&label=master&aligned
>>
>
> Thanks! Is there a bug filed for the three  tests failing in Chrome?
>
> Flag name on chrome://flags
>>
>> Finch feature name MediaCapabilitiesDynamicRange
>>
>> Requires code in //chrome? False
>>
>> Tracking bug
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1048045
>>
>> Estimated milestones
>> Shipping on desktop 120
>> Shipping on Android 120
>> Shipping on WebView 120
>>
>> Anticipated spec changes
>>
>> Open questions about a feature may be a source of future web compat or
>> interop issues. Please list open issues (e.g. links to known github issues
>> in the project for the feature specification) whose resolution may
>> introduce web compat/interop risk (e.g., changing to naming or structure of
>> the API in a non-backward-compatible way).
>> Spec changes have already been submitted since the feature is shipping in
>> Safari.
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/6640863931269120
>>
>> Links to previous Intent discussions Intent to prototype:
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/jBzVLBz-Yk4/m/ORuQg2zAEwAJ
>>
>> This intent message was generated by Chrome Platform Status
>> .
>> --
>> 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/CAPUDrwforrrpNE5RLc_OVa9uwa-63UX03VgijptNU5E8sVcD7g%40mail.gmail.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...@chromiu

Re: [blink-dev] Intent to Ship: MediaCapabilities: Query HDR support with decodingInfo()

[Chris Harrelson]

LGTM3

On Fri, Oct 27, 2023 at 1:01 PM Dale Curtis  wrote:

> Looks like this got approved on chrome status, but is still missing an
> LGTM3. Anyone else want to weigh in?
>
> - dale
>
> On Wed, Oct 25, 2023 at 12:35 PM Mike Taylor 
> wrote:
>
>> LGTM2
>> On 10/25/23 3:06 PM, 'Rick Byers' via blink-dev wrote:
>>
>> Looks pretty straightforward to me, especially with Safari already
>> shipping. LGTM1
>>
>> On Wed, Oct 18, 2023 at 7:18 PM Dale Curtis 
>> wrote:
>>
>>> Contact emails v...@microsoft.com, gw...@microsoft.com,
>>> gur...@microsoft.com, dalecur...@chromium.org
>>>
>>> Explainer
>>> https://github.com/w3c/media-capabilities/blob/main/explainer.md#decode-capabilities
>>>
>>> Specification https://www.w3.org/TR/media-capabilities/#hdrmetadatatype
>>>
>>> Summary
>>>
>>> Extends the Media Capabilities API to allow detection of HDR rendering
>>> support via three new VideoConfiguration dictionary fields:
>>> hdrMetadataType, colorGamut, transferFunction. Chromium implements its own
>>> tone-mapping algorithms so will always return true for HDR10 (smpteSt2086)
>>> static metadata. HDR10+ (smpteSt2094-10) and Dolby Vision (smpteSt2094-40)
>>> dynamic metadata are not currently supported, so will return false. We
>>> anticipate adding support for dynamic metadata in the future, so this API
>>> will allow developers to select the appropriate content for users with
>>> support.
>>>
>>>
>>> Blink component Blink>Media>Capabilities
>>> 
>>>
>>> TAG review Already shipping by another UA. The now-closed Media
>>> Capabilities TAG review covered similar discussions:
>>> https://github.com/w3ctag/design-reviews/issues/218
>>>
>>> TAG review status Not applicable
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> Low interop risk: Already shipping in Safari.
>>>
>>>
>>> *Gecko*: Neutral (
>>> https://github.com/mozilla/standards-positions/issues/910)
>>>
>>> *WebKit*: Shipped/Shipping (
>>> https://www.w3.org/2019/11/19-mediawg-minutes.html)
>>>
>>> *Web developers*: Positive (
>>> https://github.com/w3c/media-capabilities/issues/118#issuecomment-511461132
>>> )
>>>
>>> *Other signals*:
>>>
>>> Activation
>>>
>>> Will start returning false for some DolbyVision and HDR10+ metadata
>>> types on the web -- playback would have been broken already for these.
>>>
>>>
>>> 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?
>>>
>>> No risks unique to WebView.
>>>
>>>
>>> Debuggability
>>>
>>> Debuggable through media dev tools and chrome://gpu information.
>>>
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>>> Linux, Chrome OS, Android, and Android WebView)? Yes
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ? Yes
>>>
>>>
>>> https://wpt.fyi/results/media-capabilities/decodingInfo.any.html?label=experimental&label=master&aligned
>>>
>>
>> Thanks! Is there a bug filed for the three  tests failing in Chrome?
>>
>> Flag name on chrome://flags
>>>
>>> Finch feature name MediaCapabilitiesDynamicRange
>>>
>>> Requires code in //chrome? False
>>>
>>> Tracking bug
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1048045
>>>
>>> Estimated milestones
>>> Shipping on desktop 120
>>> Shipping on Android 120
>>> Shipping on WebView 120
>>>
>>> Anticipated spec changes
>>>
>>> Open questions about a feature may be a source of future web compat or
>>> interop issues. Please list open issues (e.g. links to known github issues
>>> in the project for the feature specification) whose resolution may
>>> introduce web compat/interop risk (e.g., changing to naming or structure of
>>> the API in a non-backward-compatible way).
>>> Spec changes have already been submitted since the feature is shipping
>>> in Safari.
>>>
>>> Link to entry on the Chrome Platform Status
>>> https://chromestatus.com/feature/6640863931269120
>>>
>>> Links to previous Intent discussions Intent to prototype:
>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/jBzVLBz-Yk4/m/ORuQg2zAEwAJ
>>>
>>> This intent message was generated by Chrome Platform Status
>>> .
>>> --
>>> 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/CAPUDrwforrrpNE5RLc_OVa9uwa-63UX03VgijptNU5E8sVcD7g%40mail.gmail.com
>>> 
>>> .
>>>
>> --
>> You

[blink-dev] Intent to Ship: WebGPU on Android

['Brandon Jones' via blink-dev]

Contact emailsbajo...@chromium.org, cwal...@chromium.org

Explainerhttps://gpuweb.github.io/gpuweb/explainer/

Specificationhttps://www.w3.org/TR/webgpu

Design docs
https://gpuweb.github.io/gpuweb
https://gpuweb.github.io/gpuweb/wgsl
https://gpuweb.github.io/gpuweb/explainer

Summary
This Intent to Ship is specifically for enabling WebGPU by default on
Android. WebGPU previously launched on Windows, MacOS, and ChromeOS in
M113. See https://chromestatus.com/feature/6213121689518080 for details.

WebGPU has been available on Android behind a flag since M111, during which
time we have gathered feedback from developers, partners, and Chrome's
testing infrastructure to find and address issues on multiple mobile GPU
architectures.

WebGPU is the successor to the WebGL and WebGL 2 graphics APIs for the Web.
It provides modern features such as “GPU compute” as well as lower overhead
access to GPU hardware and better, more predictable performance. WebGPU is
developed by the “GPU for the Web” W3C community group.


Blink componentBlink>WebGPU


TAG reviewhttps://github.com/w3ctag/design-reviews/issues/626

TAG review statusIssues addressed

Risks


Interoperability and Compatibility

With positive signals (and at least WIP implementations) from all browsers
and few unresolved issues in the spec repo, the compatibility risk is low
and mostly if other implementers find bugs in the spec as they flesh out
their WebGPU implementation.


*Gecko*: Positive (https://mozilla.github.io/standards-positions/#webgpu)

*WebKit*: In development (
https://github.com/WebKit/WebKit/tree/main/Source/WebGPU/WebGPU) Standards
position issue: https://github.com/WebKit/standards-positions/issues/107

*Web developers*: Strongly positive

Security

See detailed security explainer:
https://gpuweb.github.io/gpuweb/#malicious-use


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

Warnings and errors are exposed via dev tools. Specialized tools can be
built directly in JavaScript, integrated in applications or as devtools
extensions.


Will this feature be supported on all six Blink platforms (Windows, Mac,
Linux, Chrome OS, Android, and Android WebView)?No

Once enabled on Android, the only Blink platform where WebGPU will not be
enabled by default yet is Linux.


Is this feature fully tested by web-platform-tests

?Yes

The WebGPU Conformance Test Suite is being built at
https://github.com/gpuweb/cts and can be integrated as a subdirectory of
WPT. It is already integreated into the Chromium CI infrastructure.

DevTrial instructions
https://github.com/gpuweb/gpuweb/wiki/Implementation-Status#chromium-chrome-edge-etc

Flag name on chrome://flags--enable-unsafe-webgpu

Finch feature nameWebGPUService

Requires code in //chrome?False

Availability expectationFeature will initially be enabled for Adreno and
Mali GPUs (the majority of the mobile market) on Android 12+, with other
hardware and OS versions added in the future as additional testing and bug
fixes allow. More broadly while there is no timeline commitment from
Firefox or Safari both browsers are known to be actively implementing
WebGPU and are anticipated to ship once their implementations are
sufficiently conformant.

Sample links
https://github.com/austinEng/webgpu-samples

Estimated milestones
Shipped on desktop 113
OriginTrial desktop last 114
OriginTrial desktop first 94
Shipping on Android 121
DevTrial on Android 111

Anticipated spec changesDiscussion on the core WebGPU and WGSL
specification has been minimal since the API was shipped on desktop, with
most ongoing discussion centered around additional features that can be
layered onto the API. While we are still open to minor spec bug fixes at
this point the overwhelming majority of the spec should see no behavioral
changes.

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5119617865613312

Links to previous Intent discussionsIntent to prototype:
https://groups.google.com/a/chromium.org/g/blink-dev/c/dxqWTSvyhDg/m/1UDaFD17AQAJ

-- 
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/CAEGwwi0ReGtfej_JbQPVHEbutrB%3DpDsEOdg9kfHTHYpyojkA-A%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: WebGPU on Android

[Chris Harrelson]

LGTM1 - this is an easy one :)

On Fri, Oct 27, 2023 at 1:21 PM 'Brandon Jones' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emailsbajo...@chromium.org, cwal...@chromium.org
>
> Explainerhttps://gpuweb.github.io/gpuweb/explainer/
>
> Specificationhttps://www.w3.org/TR/webgpu
>
> Design docs
> https://gpuweb.github.io/gpuweb
> https://gpuweb.github.io/gpuweb/wgsl
> https://gpuweb.github.io/gpuweb/explainer
>
> Summary
> This Intent to Ship is specifically for enabling WebGPU by default on
> Android. WebGPU previously launched on Windows, MacOS, and ChromeOS in
> M113. See https://chromestatus.com/feature/6213121689518080 for details.
>
> WebGPU has been available on Android behind a flag since M111, during
> which time we have gathered feedback from developers, partners, and
> Chrome's testing infrastructure to find and address issues on multiple
> mobile GPU architectures.
>
> WebGPU is the successor to the WebGL and WebGL 2 graphics APIs for the
> Web. It provides modern features such as “GPU compute” as well as lower
> overhead access to GPU hardware and better, more predictable performance.
> WebGPU is developed by the “GPU for the Web” W3C community group.
>
>
> Blink componentBlink>WebGPU
> 
>
> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/626
>
> TAG review statusIssues addressed
>
> Risks
>
>
> Interoperability and Compatibility
>
> With positive signals (and at least WIP implementations) from all browsers
> and few unresolved issues in the spec repo, the compatibility risk is low
> and mostly if other implementers find bugs in the spec as they flesh out
> their WebGPU implementation.
>
>
> *Gecko*: Positive (https://mozilla.github.io/standards-positions/#webgpu)
>
> *WebKit*: In development (
> https://github.com/WebKit/WebKit/tree/main/Source/WebGPU/WebGPU)
> Standards position issue:
> https://github.com/WebKit/standards-positions/issues/107
>
> *Web developers*: Strongly positive
>
> Security
>
> See detailed security explainer:
> https://gpuweb.github.io/gpuweb/#malicious-use
>
>
> 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
>
> Warnings and errors are exposed via dev tools. Specialized tools can be
> built directly in JavaScript, integrated in applications or as devtools
> extensions.
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?No
>
> Once enabled on Android, the only Blink platform where WebGPU will not be
> enabled by default yet is Linux.
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?Yes
>
> The WebGPU Conformance Test Suite is being built at
> https://github.com/gpuweb/cts and can be integrated as a subdirectory of
> WPT. It is already integreated into the Chromium CI infrastructure.
>
> DevTrial instructions
> https://github.com/gpuweb/gpuweb/wiki/Implementation-Status#chromium-chrome-edge-etc
>
> Flag name on chrome://flags--enable-unsafe-webgpu
>
> Finch feature nameWebGPUService
>
> Requires code in //chrome?False
>
> Availability expectationFeature will initially be enabled for Adreno and
> Mali GPUs (the majority of the mobile market) on Android 12+, with other
> hardware and OS versions added in the future as additional testing and bug
> fixes allow. More broadly while there is no timeline commitment from
> Firefox or Safari both browsers are known to be actively implementing
> WebGPU and are anticipated to ship once their implementations are
> sufficiently conformant.
>
> Sample links
> https://github.com/austinEng/webgpu-samples
>
> Estimated milestones
> Shipped on desktop 113
> OriginTrial desktop last 114
> OriginTrial desktop first 94
> Shipping on Android 121
> DevTrial on Android 111
>
> Anticipated spec changesDiscussion on the core WebGPU and WGSL
> specification has been minimal since the API was shipped on desktop, with
> most ongoing discussion centered around additional features that can be
> layered onto the API. While we are still open to minor spec bug fixes at
> this point the overwhelming majority of the spec should see no behavioral
> changes.
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5119617865613312
>
> Links to previous Intent discussionsIntent to prototype:
> https://groups.google.com/a/chromium.org/g/blink-dev/c/dxqWTSvyhDg/m/1UDaFD17AQAJ
>
> --
> 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/CAEGwwi0

Re: [blink-dev] Intent to Experiment: Cookie Deprecation Labeling

[David Dabbs]

Per that document, Mode B Chrome instances will also be labeled. 

On Friday, October 27, 2023 at 2:52:33 PM UTC-5 wande...@chromium.org wrote:

> FYI, the specific labels to be sent are listed here:
>
> https://developer.chrome.com/en/docs/privacy-sandbox/chrome-testing/#mode-a
>
> Specifically, the "label_only_1", "label_only_2", "label_only_3", 
> "label_only_4", and "label_only_5" labels.  Note, the "control_1.*" labels 
> are not being enabled yet.
>
> On Fri, Oct 27, 2023 at 3:27 PM Rick Byers  wrote:
>
>> Exposing a new header and JS API temporarily for the purposes of an 
>> experiment (outside the context of an OT) is not something we've ever done 
>> before. But given the scope and requirements of this experiment and our 
>> desire to help enable the ecosystem to reason about it, it seems absolutely 
>> like the right pragmatic approach to me. Burn in risk seems like it would 
>> be low even at 100%, and effectively zero due to the 10% exposure. I don't 
>> see any interop concerns given that this API is useful only for 
>> understanding Chrome-specific behavior variation. 
>>
>> LGTM1 to "experiment" with this, but I'd like to get two other LGTMs 
>> given that it's a very unusual I2E.
>>
>>
>> On Wed, Oct 25, 2023 at 5:06 PM John Delaney  
>> wrote:
>>
>>> *Contact emails*
>>> john...@chromium.org, wande...@chromium.org, lin...@chromium.org
>>>
>>> *Explainer*
>>>
>>> https://github.com/privacysandbox/tpcd-labeling/blob/main/cookie_deprecation_labeling_explainer.md
>>> https://developer.chrome.com/en/docs/privacy-sandbox/chrome-testing
>>>
>>> *Specification*
>>> None
>>>
>>> *Summary*
>>> To prepare for the third-party cookie deprecation, it is important to 
>>> understand the full impact of Chrome’s planned transition from third-party 
>>> cookies to the Privacy Sandbox Ads APIs.
>>>
>>> This experiment exposes a temporary set of APIs which provide access to 
>>> browser-determined treatment and control groups to support opt-in server 
>>> side testing of the third-party cookie deprecation.
>>>
>>> *Blink component*
>>> A-N/A
>>>
>>> *TAG review*
>>> Not requesting TAG review as this API is a temporary Chrome-specific 
>>> experiment.
>>>
>>> *Risks*
>>>
>>> *Interoperability and Compatibility*
>>> This feature is only shipping in Chrome to support the third-party 
>>> cookie deprecation, and will not be interoperable with other vendors.
>>>
>>> *WebView application risks*
>>> Not available on WebView
>>>
>>>
>>> *Goals for experimentation*
>>> The goal of this experiment is to allow adtechs to evaluate the impact 
>>> of third party cookie phase out through opt-in server side testing. We 
>>> expect partners to run experiments downstream from the browser provided 
>>> treatment and control groups.
>>>
>>> *Experiment Behavior and Risks*
>>> This experiment will expose temporary APIs which allow access to browser 
>>> provided experiment labels. 
>>>
>>> To ensure all parties can easily get access to labels, we intend to 
>>> expose the APIs without a traditional origin trial. 
>>>
>>> To limit burn-in risk, the new APIs will only be available to at most 
>>> ~10% of users. These APIs should have very little utility to developers 
>>> outside of this specific temporary experiment, it seems unlikely that 
>>> user-visible breakage would occur as a result of the eventual removal.
>>>
>>> *Timeline*
>>> We intend to remove the labeling APIs when Mode B of the experiment 
>>> ends, which we expect to be by the end of Q2 2024 at the earliest.
>>>
>>> This experiment temporarily adds a new surface to the web that could be 
>>> used for active fingerprinting. This is mitigated by the fact that: 
>>>
>>>- only a subset are assigned labels, reducing the usefulness of the 
>>>label for fingerprinting
>>>- labels are not sent for users who block third-party cookies, to 
>>>ensure consistency with those users’ current settings
>>>- the labeling APIs will be removed by the time third-party cookies 
>>>are phased out
>>>- label assignment is independent of users' browsing activity
>>>
>>>
>>> *Ongoing technical constraints*
>>> None
>>>
>>> *Debuggability*
>>> None
>>>
>>> *Will this feature be supported on all six Blink platforms (Windows, 
>>> Mac, Linux, Chrome OS, Android, and Android WebView)?*
>>> No, not supported on WebView.
>>>
>>> *Is this feature fully tested by web-platform-tests?*
>>> No
>>>
>>> *Flag name on chrome://flags*
>>> #tpc-phase-out-facilitated-testing
>>>
>>> *Requires code in //chrome?*
>>> False
>>>
>>> *Estimated milestones*
>>>   Experiment desktop first 119
>>>   Experiment Android first 119
>>>
>>> *Intent to Prototype*
>>>
>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/8mlWTOcEzcA/m/NZJSW0weAQAJ
>>>
>>> *Link to entry on the Chrome Platform Status*
>>> https://chromestatus.com/feature/5189079788683264
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "blink-dev" group.
>>> To unsubsc

Re: [blink-dev] Re: Intent to Ship: FedCM extensions: Error API and Auto-Selected Flag API

[Mike Taylor]

Thanks Nicolás and Yi.

LGTM1 % the PRs landing before this ships, and assuming Mozilla does not 
have feedback that materially changes the API shape. If that's the case, 
can you report back?


thanks,
Mike

On 10/26/23 10:27 AM, Nicolás Peña wrote:
For the record, we did request reviews: here 
 
and here 
. 
I'll ask to see if they can be added to the set of users from whom we 
can 'request review' in GitHub UI.

On Wednesday, October 25, 2023 at 7:17:53 PM UTC-4 Yi Gu wrote:

We sync’d with @bvandersloot-mozilla
 in FedIdCG [1] and they
have confirmed that it’s on their list.

[1]
https://github.com/fedidcg/meetings/blob/main/2023/2023-10-02-notes.md#notes



On Wed, Oct 25, 2023 at 6:51 PM Mike Taylor
 wrote:

On 10/25/23 4:14 PM, Yi Gu wrote:


Thanks Yoav for the review!

> It'd be useful to write a short (inline?) explainer here
outlining what this does and how it'd look like.
Specifically, would we start throwing on errors in scenarios
that silently failed before?

For the Error API, it allows IdP to signal to the browser
about the sign-in failure details such that the browser can
make sure the user is kept informed with possibly next steps.
Without this API, when a user clicks the "Continue as Name"
button to sign-in, if it fails for whatever reasons, the
browser rejects the promise silently so the user could be
confused about the status. The fact that we are delaying
rejecting the promise (for privacy reasons) would make it
worse because the website wouldn't learn about the failure
immediately either. With this API, the browser will first
show a native UI with proper strings to explain the error to
users and possibly allow users to learn more about next
steps. It will also reject the promise with the errors (if
provided by IdP) via IdentityCredentialError instead of a
generic DOMException (which we currently use). You could find
more details here
.

For the AutoSelected Flag API, it shares whether auto
re-authentication has been triggered during the flow with
both IdP and RP. By default the CredentialManagement API
supports credential auto selection when possible. However,
the browser may decide not to trigger auto selection for
legitimate reasons. While the exact reason should be opaque
to IdP or RP, we could share with them the outcome such that
they can better understand the flow and handle things
differently. e.g. for metrics purposes they could know how
many transactions were done with auto re-authentication to
better understand the performance; in addition, an IdP can
use the signal (boolean) to support some security related
features. e.g. a user may prefer explicitly selecting an
account with an IdP, if the IdP gets a token request that
shows the account was automatically selected, they could
reject the request and trigger a new sign-in flow to ask for
explicit user mediation. You could find more details here.


> What's preventing these PRs from landing?

We aligned with Mozilla, who is prototyping FedCM in Firefox
right now, that such spec changes should be reviewed by at
least two implementers before merging. While we have
discussed the two APIs

at FedIdCG and it "generally looks reasonable", it's not yet
formally reviewed by Mozilla (hence the "Under consideration"
signal).

I don't see anyone from Mozilla as a reviewer for either PR -
is there a plan to request review from them?


Thanks.
Yi

On Wed, Oct 25, 2023 at 11:19 AM Yoav Weiss
 wrote:



On Monday, October 23, 2023 at 3:03:59 PM UTC+2 blink-dev
wrote:

Contact emails

y...@chromium.org


Explainer

https://github.com/fedidcg/FedCM/issues/488



It'd be useful to write a short (inline?) explainer here
outlining what this does and how it'd look like.
Specifically, would we start throwing on errors in
scenarios that silently failed before?

https://github.com/fedidcg/FedCM/issues/497
 

Re: [blink-dev] Intent to Experiment: Cookie Deprecation Labeling

[Chris Harrelson]

Hi,

This plan makes sense to me. It's an unusual situation but IMO justified
given the difficulty of the goal. One last piece though: per the Blink
launch process
 you need
to specify an end milestone that is <= 6 release after the start milestone,
so no later than M125 in this case. And extensions of up to 3 milestones
each are always possible to ask for later, also per the Blink launch
process.

On Fri, Oct 27, 2023 at 1:28 PM David Dabbs  wrote:

> Per that document, Mode B Chrome instances will also be labeled.
>
> On Friday, October 27, 2023 at 2:52:33 PM UTC-5 wande...@chromium.org
> wrote:
>
>> FYI, the specific labels to be sent are listed here:
>>
>>
>> https://developer.chrome.com/en/docs/privacy-sandbox/chrome-testing/#mode-a
>>
>> Specifically, the "label_only_1", "label_only_2", "label_only_3",
>> "label_only_4", and "label_only_5" labels.  Note, the "control_1.*" labels
>> are not being enabled yet.
>>
>> On Fri, Oct 27, 2023 at 3:27 PM Rick Byers  wrote:
>>
>>> Exposing a new header and JS API temporarily for the purposes of an
>>> experiment (outside the context of an OT) is not something we've ever done
>>> before. But given the scope and requirements of this experiment and our
>>> desire to help enable the ecosystem to reason about it, it seems absolutely
>>> like the right pragmatic approach to me. Burn in risk seems like it would
>>> be low even at 100%, and effectively zero due to the 10% exposure. I don't
>>> see any interop concerns given that this API is useful only for
>>> understanding Chrome-specific behavior variation.
>>>
>>> LGTM1 to "experiment" with this, but I'd like to get two other LGTMs
>>> given that it's a very unusual I2E.
>>>
>>>
>>> On Wed, Oct 25, 2023 at 5:06 PM John Delaney 
>>> wrote:
>>>
 *Contact emails*
 john...@chromium.org, wande...@chromium.org, lin...@chromium.org

 *Explainer*

 https://github.com/privacysandbox/tpcd-labeling/blob/main/cookie_deprecation_labeling_explainer.md
 https://developer.chrome.com/en/docs/privacy-sandbox/chrome-testing

 *Specification*
 None

 *Summary*
 To prepare for the third-party cookie deprecation, it is important to
 understand the full impact of Chrome’s planned transition from third-party
 cookies to the Privacy Sandbox Ads APIs.

 This experiment exposes a temporary set of APIs which provide access to
 browser-determined treatment and control groups to support opt-in server
 side testing of the third-party cookie deprecation.

 *Blink component*
 A-N/A

 *TAG review*
 Not requesting TAG review as this API is a temporary Chrome-specific
 experiment.

 *Risks*

 *Interoperability and Compatibility*
 This feature is only shipping in Chrome to support the third-party
 cookie deprecation, and will not be interoperable with other vendors.

 *WebView application risks*
 Not available on WebView


 *Goals for experimentation*
 The goal of this experiment is to allow adtechs to evaluate the impact
 of third party cookie phase out through opt-in server side testing. We
 expect partners to run experiments downstream from the browser provided
 treatment and control groups.

 *Experiment Behavior and Risks*
 This experiment will expose temporary APIs which allow access to
 browser provided experiment labels.

 To ensure all parties can easily get access to labels, we intend to
 expose the APIs without a traditional origin trial.

 To limit burn-in risk, the new APIs will only be available to at most
 ~10% of users. These APIs should have very little utility to developers
 outside of this specific temporary experiment, it seems unlikely that
 user-visible breakage would occur as a result of the eventual removal.

 *Timeline*
 We intend to remove the labeling APIs when Mode B of the experiment
 ends, which we expect to be by the end of Q2 2024 at the earliest.

 This experiment temporarily adds a new surface to the web that could be
 used for active fingerprinting. This is mitigated by the fact that:

- only a subset are assigned labels, reducing the usefulness of the
label for fingerprinting
- labels are not sent for users who block third-party cookies, to
ensure consistency with those users’ current settings
- the labeling APIs will be removed by the time third-party cookies
are phased out
- label assignment is independent of users' browsing activity


 *Ongoing technical constraints*
 None

 *Debuggability*
 None

 *Will this feature be supported on all six Blink platforms (Windows,
 Mac, Linux, Chrome OS, Android, and Android WebView)?*
 No, not supported on WebView.

 *Is this feature fully tested by web-platform-

Re: [blink-dev] Intent to Ship: Fenced Frame - Functionality Updates

[Chris Harrelson]

LGTM2

On Thu, Oct 26, 2023 at 10:30 AM Mike Taylor  wrote:

> Thanks for the design doc! The quote from kleber@ really helped me to
> understand the use case and developer need. It sounds like this is a small
> tweak to fenced frame event-level reporting, which is itself a temporary
> stepping stone on the path to a more private ads ecosystem. AIUI, this does
> not regress privacy by revealing the event data to more parties, just the
> event itself (by default).
>
> Based on that, LGTM1 to ship.
> On 10/26/23 11:33 AM, Liam Brady wrote:
>
> Hi Mike,
>
> Apologies for the confusion. I have a design document written that
> explains the motivation for this change:
>
> https://docs.google.com/document/d/1vLifppH8TC86sl4kbam57egttqb4VNwEkVvZdefGIuQ/edit?usp=sharing
>
> Essentially, if registerAdBeacon() is called for some destination, that
> destination is going to expect to receive automatic beacons. However, with
> the current design, the ad frame is able to arbitrarily prevent automatic
> beacons from reaching certain destinations. We don't think an ad frame
> should determine if a destination gets automatic beacons, but it should
> still be allowed to determine if data is attached to the beacon that is
> sent to destinations.
>
> The explainer PR is waiting for final reviews and approval (I'll try to
> get that taken care of today). The spec PRs have landed. In the future,
> I'll link commits instead of PRs to avoid any confusion.
>
> - Liam
>
> On Wed, Oct 25, 2023 at 7:44 PM Mike Taylor 
> wrote:
>
>> Hi Liam!
>>
>> On 10/20/23 4:37 PM, 'Liam Brady' via blink-dev wrote:
>>
>> Contact emails
>>
>> shivani...@chromium.org jkar...@chromium.org lbr...@google.com
>> Explainer(s)
>>
>> Send Automatic Beacons To All Registered Destinations
>>
>> https://github.com/WICG/turtledove/pull/808
>>
>> FWIW, it's a bit challenging to read an explainer as diffs on GitHub and
>> infer the motivation. For future intents, could you write up the motivation
>> and use cases for the "updates" elsewhere (gist, comment, inline here), or
>> just land the PR in the existing explainer? Is there any reason the PR
>> hasn't landed?
>>
>> Attempting to mentally patch the diffs to
>> https://github.com/WICG/turtledove/blob/main/Fenced_Frames_Ads_Reporting.md#support-for-attribution-reporting,
>> it seems like this intent is intended to support attribution reporting. And
>> it seems like sending a reporting beacon for the "reserved.top_navigation"
>> event to *all* registered URLs *without* event data is useful. But I
>> don't really know. :) Can you elaborate, assuming my understanding is
>> correct?
>>
>> (One more note - sending a title like "Fenced Frames - Send Automatic
>> Beacons To All Registered Destinations" is a lot more clear than
>> "Functionality Updates")
>>
>>
>> Spec(s)
>>
>> Send Automatic Beacons To All Registered Destinations
>>
>> (Initial version) https://github.com/WICG/fenced-frame/pull/122
>>
>> (Post-security review updates)
>> https://github.com/WICG/fenced-frame/pull/129
>>
>> Similarly, is there any reason the spec PRs haven't landed?
>>
>>
>> Summary
>>
>> One of the capabilities of fenced frames and URN iframes loaded through
>> Protected Audience or Shared Storage is being able to send reporting
>> beacons automatically
>> 
>> after a top-level navigation. We would like to modify that functionality:
>>
>> Automatic beacons will now send to URLs registered via registerAdBeacon()
>> on reserved.top_navigation calls, but they will not have beacon data
>> attached to the request. Previously, only URLs registered via
>> setReportEventDataForAutomaticBeacons received beacons, and they do have
>> beacon data attached.
>>
>> Note: This chromestatus entry also includes changes to Protected Audience
>> ad size macros. However, it is small enough that it will be taken care of
>> in a separate PSA:
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/3JfA8EUBEgQ
>>
>> Blink component
>>
>> Blink>FencedFrames
>> 
>>
>> TAG reviews and status
>>
>> Fenced frames existing TAG review appended with these spec changes
>> https://github.com/w3ctag/design-reviews/issues/838#issuecomment-1765061770
>>
>> Link to Origin Trial feedback summary
>>
>> No Origin Trial performed
>>
>> Is this feature supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)?
>>
>> Supported on all the above platforms except Android WebView.
>>
>> Debuggability
>>
>> Additional debugging capabilities are not necessary for these feature
>> changes.
>>
>> Risks
>>
>> Compatibility
>>
>> There are no compatibility risks, as described below:
>>
>> The API shape as exposed to ad frames is not changing. While the
>> assumptions of which sites receive the beacon after calling
>> setReportEventDataForAutomaticBeacons

Re: [blink-dev] Intent to Experiment: Cookie Deprecation Labeling

[Ben Kelly]

On Fri, Oct 27, 2023 at 4:45 PM Chris Harrelson 
wrote:

> Hi,
>
> This plan makes sense to me. It's an unusual situation but IMO justified
> given the difficulty of the goal. One last piece though: per the Blink
> launch process
>  you
> need to specify an end milestone that is <= 6 release after the start
> milestone, so no later than M125 in this case. And extensions of up to 3
> milestones each are always possible to ask for later, also per the Blink
> launch process.
>

Thank you.  We will set the end data at M125 for now, but we expect to come
back to request an extension based on current timeline commitments.  We
will provide an assessment of the situation at that time.


>
> On Fri, Oct 27, 2023 at 1:28 PM David Dabbs 
> wrote:
>
>> Per that document, Mode B Chrome instances will also be labeled.
>
>
This is true, but I was trying to highlight the labels that would be
starting in M119.  Sorry for the confusion.


>
>>
>> On Friday, October 27, 2023 at 2:52:33 PM UTC-5 wande...@chromium.org
>> wrote:
>>
>>> FYI, the specific labels to be sent are listed here:
>>>
>>>
>>> https://developer.chrome.com/en/docs/privacy-sandbox/chrome-testing/#mode-a
>>>
>>> Specifically, the "label_only_1", "label_only_2", "label_only_3",
>>> "label_only_4", and "label_only_5" labels.  Note, the "control_1.*" labels
>>> are not being enabled yet.
>>>
>>> On Fri, Oct 27, 2023 at 3:27 PM Rick Byers  wrote:
>>>
 Exposing a new header and JS API temporarily for the purposes of an
 experiment (outside the context of an OT) is not something we've ever done
 before. But given the scope and requirements of this experiment and our
 desire to help enable the ecosystem to reason about it, it seems absolutely
 like the right pragmatic approach to me. Burn in risk seems like it would
 be low even at 100%, and effectively zero due to the 10% exposure. I don't
 see any interop concerns given that this API is useful only for
 understanding Chrome-specific behavior variation.

 LGTM1 to "experiment" with this, but I'd like to get two other LGTMs
 given that it's a very unusual I2E.


 On Wed, Oct 25, 2023 at 5:06 PM John Delaney 
 wrote:

> *Contact emails*
> john...@chromium.org, wande...@chromium.org, lin...@chromium.org
>
> *Explainer*
>
> https://github.com/privacysandbox/tpcd-labeling/blob/main/cookie_deprecation_labeling_explainer.md
> https://developer.chrome.com/en/docs/privacy-sandbox/chrome-testing
>
> *Specification*
> None
>
> *Summary*
> To prepare for the third-party cookie deprecation, it is important to
> understand the full impact of Chrome’s planned transition from third-party
> cookies to the Privacy Sandbox Ads APIs.
>
> This experiment exposes a temporary set of APIs which provide access
> to browser-determined treatment and control groups to support opt-in 
> server
> side testing of the third-party cookie deprecation.
>
> *Blink component*
> A-N/A
>
> *TAG review*
> Not requesting TAG review as this API is a temporary Chrome-specific
> experiment.
>
> *Risks*
>
> *Interoperability and Compatibility*
> This feature is only shipping in Chrome to support the third-party
> cookie deprecation, and will not be interoperable with other vendors.
>
> *WebView application risks*
> Not available on WebView
>
>
> *Goals for experimentation*
> The goal of this experiment is to allow adtechs to evaluate the impact
> of third party cookie phase out through opt-in server side testing. We
> expect partners to run experiments downstream from the browser provided
> treatment and control groups.
>
> *Experiment Behavior and Risks*
> This experiment will expose temporary APIs which allow access to
> browser provided experiment labels.
>
> To ensure all parties can easily get access to labels, we intend to
> expose the APIs without a traditional origin trial.
>
> To limit burn-in risk, the new APIs will only be available to at most
> ~10% of users. These APIs should have very little utility to developers
> outside of this specific temporary experiment, it seems unlikely that
> user-visible breakage would occur as a result of the eventual removal.
>
> *Timeline*
> We intend to remove the labeling APIs when Mode B of the experiment
> ends, which we expect to be by the end of Q2 2024 at the earliest.
>
> This experiment temporarily adds a new surface to the web that could
> be used for active fingerprinting. This is mitigated by the fact that:
>
>- only a subset are assigned labels, reducing the usefulness of
>the label for fingerprinting
>- labels are not sent for users who block third-party cookies, to
>ensure consistency with tho

Re: [blink-dev] Intent to Experiment: Cookie Deprecation Labeling

[Chris Harrelson]

LGTM2!

On Fri, Oct 27, 2023 at 1:50 PM Ben Kelly  wrote:

>
>
> On Fri, Oct 27, 2023 at 4:45 PM Chris Harrelson 
> wrote:
>
>> Hi,
>>
>> This plan makes sense to me. It's an unusual situation but IMO justified
>> given the difficulty of the goal. One last piece though: per the Blink
>> launch process
>>  you
>> need to specify an end milestone that is <= 6 release after the start
>> milestone, so no later than M125 in this case. And extensions of up to 3
>> milestones each are always possible to ask for later, also per the Blink
>> launch process.
>>
>
> Thank you.  We will set the end data at M125 for now, but we expect to
> come back to request an extension based on current timeline commitments.
> We will provide an assessment of the situation at that time.
>
>
>>
>> On Fri, Oct 27, 2023 at 1:28 PM David Dabbs 
>> wrote:
>>
>>> Per that document, Mode B Chrome instances will also be labeled.
>>
>>
> This is true, but I was trying to highlight the labels that would be
> starting in M119.  Sorry for the confusion.
>
>
>>
>>>
>>> On Friday, October 27, 2023 at 2:52:33 PM UTC-5 wande...@chromium.org
>>> wrote:
>>>
 FYI, the specific labels to be sent are listed here:


 https://developer.chrome.com/en/docs/privacy-sandbox/chrome-testing/#mode-a

 Specifically, the "label_only_1", "label_only_2", "label_only_3",
 "label_only_4", and "label_only_5" labels.  Note, the "control_1.*" labels
 are not being enabled yet.

 On Fri, Oct 27, 2023 at 3:27 PM Rick Byers  wrote:

> Exposing a new header and JS API temporarily for the purposes of an
> experiment (outside the context of an OT) is not something we've ever done
> before. But given the scope and requirements of this experiment and our
> desire to help enable the ecosystem to reason about it, it seems 
> absolutely
> like the right pragmatic approach to me. Burn in risk seems like it would
> be low even at 100%, and effectively zero due to the 10% exposure. I don't
> see any interop concerns given that this API is useful only for
> understanding Chrome-specific behavior variation.
>
> LGTM1 to "experiment" with this, but I'd like to get two other LGTMs
> given that it's a very unusual I2E.
>
>
> On Wed, Oct 25, 2023 at 5:06 PM John Delaney 
> wrote:
>
>> *Contact emails*
>> john...@chromium.org, wande...@chromium.org, lin...@chromium.org
>>
>> *Explainer*
>>
>> https://github.com/privacysandbox/tpcd-labeling/blob/main/cookie_deprecation_labeling_explainer.md
>> https://developer.chrome.com/en/docs/privacy-sandbox/chrome-testing
>>
>> *Specification*
>> None
>>
>> *Summary*
>> To prepare for the third-party cookie deprecation, it is important to
>> understand the full impact of Chrome’s planned transition from 
>> third-party
>> cookies to the Privacy Sandbox Ads APIs.
>>
>> This experiment exposes a temporary set of APIs which provide access
>> to browser-determined treatment and control groups to support opt-in 
>> server
>> side testing of the third-party cookie deprecation.
>>
>> *Blink component*
>> A-N/A
>>
>> *TAG review*
>> Not requesting TAG review as this API is a temporary Chrome-specific
>> experiment.
>>
>> *Risks*
>>
>> *Interoperability and Compatibility*
>> This feature is only shipping in Chrome to support the third-party
>> cookie deprecation, and will not be interoperable with other vendors.
>>
>> *WebView application risks*
>> Not available on WebView
>>
>>
>> *Goals for experimentation*
>> The goal of this experiment is to allow adtechs to evaluate the
>> impact of third party cookie phase out through opt-in server side 
>> testing.
>> We expect partners to run experiments downstream from the browser 
>> provided
>> treatment and control groups.
>>
>> *Experiment Behavior and Risks*
>> This experiment will expose temporary APIs which allow access to
>> browser provided experiment labels.
>>
>> To ensure all parties can easily get access to labels, we intend to
>> expose the APIs without a traditional origin trial.
>>
>> To limit burn-in risk, the new APIs will only be available to at most
>> ~10% of users. These APIs should have very little utility to developers
>> outside of this specific temporary experiment, it seems unlikely that
>> user-visible breakage would occur as a result of the eventual removal.
>>
>> *Timeline*
>> We intend to remove the labeling APIs when Mode B of the experiment
>> ends, which we expect to be by the end of Q2 2024 at the earliest.
>>
>> This experiment temporarily adds a new surface to the web that could
>> be used for active fingerprinting. This is mitigated by the fact that:
>>>

Re: [blink-dev] Intent to Experiment: Cookie Deprecation Labeling

[Mike Taylor]

LGTM3.

(I verified off-list that the temporary navigator.cookieDeprecationLabel 
API will indeed not be exposed to all users, so I feel pretty confident 
and the low burn-in risks.)


On 10/27/23 4:51 PM, Chris Harrelson wrote:

LGTM2!

On Fri, Oct 27, 2023 at 1:50 PM Ben Kelly  wrote:



On Fri, Oct 27, 2023 at 4:45 PM Chris Harrelson
 wrote:

Hi,

This plan makes sense to me. It's an unusual situation but IMO
justified given the difficulty of the goal. One last piece
though: per the Blink launch process

you need to specify an end milestone that is <= 6 release
after the start milestone, so no later than M125 in this case.
And extensions of up to 3 milestones each are always possible
to ask for later, also per the Blink launch process.


Thank you.  We will set the end data at M125 for now, but we
expect to come back to request an extension based on current
timeline commitments.  We will provide an assessment of the
situation at that time.


On Fri, Oct 27, 2023 at 1:28 PM David Dabbs
 wrote:

Per that document, Mode B Chrome instances will also be
labeled.


This is true, but I was trying to highlight the labels that would
be starting in M119.  Sorry for the confusion.



On Friday, October 27, 2023 at 2:52:33 PM UTC-5
wande...@chromium.org wrote:

FYI, the specific labels to be sent are listed here:


https://developer.chrome.com/en/docs/privacy-sandbox/chrome-testing/#mode-a

Specifically, the "label_only_1", "label_only_2",
"label_only_3", "label_only_4", and "label_only_5"
labels. Note, the "control_1.*" labels are not being
enabled yet.

On Fri, Oct 27, 2023 at 3:27 PM Rick Byers
 wrote:

Exposing a new header and JS API temporarily for
the purposes of an experiment (outside the context
of an OT) is not something we've ever done before.
But given the scope and requirements of this
experiment and our desire to help enable the
ecosystem to reason about it, it seems absolutely
like the right pragmatic approach to me. Burn in
risk seems like it would be low even at 100%, and
effectively zero due to the 10% exposure. I don't
see any interop concerns given that this API is
useful only for understanding Chrome-specific
behavior variation.

LGTM1 to "experiment" with this, but I'd like to
get two other LGTMs given that it's a very unusual
I2E.


On Wed, Oct 25, 2023 at 5:06 PM John Delaney
 wrote:

*Contact emails*
john...@chromium.org, wande...@chromium.org,
lin...@chromium.org

*Explainer*

https://github.com/privacysandbox/tpcd-labeling/blob/main/cookie_deprecation_labeling_explainer.md

https://developer.chrome.com/en/docs/privacy-sandbox/chrome-testing

*Specification*
None

*Summary*
To prepare for the third-party cookie
deprecation, it is important to understand the
full impact of Chrome’s planned transition
from third-party cookies to the Privacy
Sandbox Ads APIs.

This experiment exposes a temporary set of
APIs which provide access to
browser-determined treatment and control
groups to support opt-in server side testing
of the third-party cookie deprecation.

*Blink component*
A-N/A

*TAG review*
Not requesting TAG review as this API is a
temporary Chrome-specific experiment.

*Risks*

*Interoperability and Compatibility*
This feature is only shipping in Chrome to
support the third-party cookie deprecation,
and will not be interoperable with other vendors.

*WebView application risks*
Not available on WebView


*Goals for experimentation*
The goal of this experiment is to allow
adtechs to evaluate the impact

Re: [blink-dev] Intent to Ship: WebGPU on Android

[Mike Taylor]

LGTM2 % requesting all of the review gates in the chromestatus entry.

On 10/27/23 4:25 PM, Chris Harrelson wrote:

LGTM1 - this is an easy one :)

On Fri, Oct 27, 2023 at 1:21 PM 'Brandon Jones' via blink-dev 
 wrote:



Contact emails

bajo...@chromium.org, cwal...@chromium.org


Explainer

https://gpuweb.github.io/gpuweb/explainer/


Specification

https://www.w3.org/TR/webgpu


Design docs


https://gpuweb.github.io/gpuweb
https://gpuweb.github.io/gpuweb/wgsl
https://gpuweb.github.io/gpuweb/explainer


Summary

This Intent to Ship is specifically for enabling WebGPU by default
on Android. WebGPU previously launched on Windows, MacOS, and
ChromeOS in M113. See
https://chromestatus.com/feature/6213121689518080for details.

WebGPU has been available on Android behind a flag since M111,
during which time we have gathered feedback from developers,
partners, and Chrome's testing infrastructure to find and address
issues on multiple mobile GPU architectures.

WebGPU is the successor to the WebGL and WebGL 2 graphics APIs for
the Web. It provides modern features such as “GPU compute” as well
as lower overhead access to GPU hardware and better, more
predictable performance. WebGPU is developed by the “GPU for the
Web” W3C community group.


Blink component

Blink>WebGPU





TAG review

https://github.com/w3ctag/design-reviews/issues/626


TAG review status

Issues addressed


Risks



Interoperability and Compatibility

With positive signals (and at least WIP implementations) from all
browsers and few unresolved issues in the spec repo, the
compatibility risk is low and mostly if other implementers find
bugs in the spec as they flesh out their WebGPU implementation.



/Gecko/: Positive
(https://mozilla.github.io/standards-positions/#webgpu)

/WebKit/: In development
(https://github.com/WebKit/WebKit/tree/main/Source/WebGPU/WebGPU)
Standards position issue:
https://github.com/WebKit/standards-positions/issues/107

/Web developers/: Strongly positive


Security

See detailed security explainer:
https://gpuweb.github.io/gpuweb/#malicious-use



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

Warnings and errors are exposed via dev tools. Specialized tools
can be built directly in JavaScript, integrated in applications or
as devtools extensions.



Will this feature be supported on all six Blink platforms
(Windows, Mac, Linux, Chrome OS, Android, and Android
WebView)?

No

Once enabled on Android, the only Blink platform where WebGPU will
not be enabled by default yet is Linux.



Is this feature fully tested by web-platform-tests

?

Yes

The WebGPU Conformance Test Suite is being built at
https://github.com/gpuweb/cts and can be integrated as a
subdirectory of WPT. It is already integreated into the Chromium
CI infrastructure.


DevTrial instructions


https://github.com/gpuweb/gpuweb/wiki/Implementation-Status#chromium-chrome-edge-etc


Flag name on chrome://flags

--enable-unsafe-webgpu


Finch feature name

WebGPUService


Requires code in //chrome?

False


Availability expectation

Feature will initially be enabled for Adreno and Mali GPUs (the
majority of the mobile market) on Android 12+, with other hardware
and OS versions added in the future as additional testing and bug
fixes allow. More broadly while there is no timeline commitment
from Firefox or Safari both browsers are known to be actively
implementing WebGPU and are anticipated to ship once their
implementations are sufficiently conformant.


Sample links


https://github.com/austinEng/webgpu-samples


Estimated milestones

Shipped on desktop  113
OriginTrial desktop last114
OriginTrial desktop first   94

Shipping on Android 121
DevTrial on Android 111



Anticipated spec changes

Discussion on the core WebGPU and WGSL specification has been
minimal since the API was shipped on desktop, with most ongoing
discussion centered around additional features that can be layered
onto the API. While we are still open to minor spec bug fixes at
this point the overwhelming majority of the spec should see no
behavioral changes.

Re: [blink-dev] Intent to ship: Interoperable Pointer and Mouse boundary events after DOM changes

[Chris Harrelson]

Hi Mustaq,

"web developer facing change to existing code" is meant for "bugfix-level
changes to web APIs", which is why it only requires a PSA (sorry for the
confusion - this has been a common issue and the chromestatus team is
working on improved UI to be less confusing).

In your case you are making a change that adjusts web-exposed behavior
enough that it requires an I2S. So you'll need to update the feature type
and file for all 5 review bits before the API owners can re-review.

On Tue, Oct 24, 2023 at 9:30 AM Mustaq Ahmed  wrote:

> Hi Mike:
>
> Through our offline discussion I learned that for "web developer facing
> change to existing code", the new intent process requires merely a "PSA"
> without (perhaps) any need for additional approvals.  I changed the email
> template subject here from "PSA" to "I2S" only to secure "API Owners"
> approval, finding no obvious way to do it through the chromestatus UI!
>
> Anyway, the updated chromestatus entry now seems to say those additional
> approvals are not needed.  Please let me know if I missed anything.
>
> Mustaq
>
>
>
> On Mon, Oct 23, 2023 at 10:39 AM Mike Taylor 
> wrote:
>
>> Hi Mustaq,
>>
>> Please take a moment to request the other review bits (API OWNERs will
>> wait until those are in progress to begin our review). See
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/bqvB1oap0Yc/m/YlO8DEHgAQAJ
>> for more info.
>>
>> thanks!
>> Mike
>> On 10/19/23 3:41 PM, Mustaq Ahmed wrote:
>>
>> Contact emails mus...@chromium.org, fla...@chromium.org
>>
>> Specification
>> https://www.w3.org/TR/uievents/#events-mouseevent-event-order
>>
>> Summary
>>
>> After an event target gets removed from the DOM, the logical target of
>> the pointer as implied by the Pointer and Mouse boundary events (i.e. over,
>> out, enter and leave events) should be the nearest ancestor still attached
>> to the DOM. PEWG has recently reached consensus on this behavior, see
>> https://github.com/web-platform-tests/interop/issues/380. Chrome has
>> been keeping track of a node even after it gets removed from DOM. As a
>> result, if the pointer moves to a new node B after the hit-test node A is
>> removed from DOM, the boundary event sequence (pointerover, pointerout,
>> pointerenter, pointerleave events and the corresponding mouse events) used
>> to imply a pointer movement from A to B. As per the new consensus, the
>> event sequence should imply a pointer movement from the "parent of A" to B.
>>
>>
>> Blink component Blink>Input
>> 
>>
>> TAG review None
>>
>> TAG review status Not applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> There is no interop risk because major browsers are currently all
>> slightly different from one another. We are strictly improving the
>> situation through the intent here by having Chrome match an agreed-upon
>> behavior that's already tested (
>> https://github.com/web-platform-tests/interop/issues/380). The compat
>> risk is negligible for the same reason, existing sites could not rely on
>> the current behavior in all browsers. This is also changing a very narrow
>> use-case.
>>
>>
>> *Gecko*: Positive (
>> https://github.com/web-platform-tests/interop/issues/380) Mozilla
>> originally called out the interop problem here.
>>
>> *WebKit*: No signal
>>
>> *Web developers*: Positive (https://crbug.com/1147998)
>>
>> *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
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)? Yes
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ? Yes
>>
>>
>> https://wpt.fyi/results/pointerevents?label=master&label=experimental&aligned&q=pointerevent_after_target_appended.html%20or%20pointerevent_after_target_removed.html%20or%20pointerup_after_pointerdown_target_removed.html
>>
>>
>> Flag name on chrome://flags None
>>
>> Finch feature name BoundaryEventDispatchTracksNodeRemoval
>>
>> Requires code in //chrome? False
>>
>> Tracking bug https://crbug.com/1147998
>>
>> Sample links
>> https://output.jsbin.com/yumacid
>>
>> Estimated milestones
>> Shipping on desktop 121
>> Shipping on Android 121
>> Shipping on WebView 121
>>
>> Anticipated spec changes
>>
>> Open questions about a feature may be a source of future web compat or
>> interop issues. Please list open issues (e.g. links to known github issues
>> in the project for the feature specification) whose resolution may
>> introduce web compat/interop risk (e.g., changing to naming or structure of
>> the API in a non-backward-compatible way).
>> None
>>
>> Link to entry on the Chrome Platform Sta

Re: [blink-dev] Intent to Ship: WebGPU on Android

[Chris Harrelson]

On Fri, Oct 27, 2023 at 1:57 PM Mike Taylor  wrote:

> LGTM2 % requesting all of the review gates in the chromestatus entry.
>
Ah yes - please do start those reviews. Likely you can mark them as N/A
because this is just shipping an existing API on a new platform.


> On 10/27/23 4:25 PM, Chris Harrelson wrote:
>
> LGTM1 - this is an easy one :)
>
> On Fri, Oct 27, 2023 at 1:21 PM 'Brandon Jones' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Contact emails bajo...@chromium.org, cwal...@chromium.org
>>
>> Explainer https://gpuweb.github.io/gpuweb/explainer/
>>
>> Specification https://www.w3.org/TR/webgpu
>>
>> Design docs
>> https://gpuweb.github.io/gpuweb
>> https://gpuweb.github.io/gpuweb/wgsl
>> https://gpuweb.github.io/gpuweb/explainer
>>
>> Summary
>> This Intent to Ship is specifically for enabling WebGPU by default on
>> Android. WebGPU previously launched on Windows, MacOS, and ChromeOS in
>> M113. See https://chromestatus.com/feature/6213121689518080 for details.
>>
>> WebGPU has been available on Android behind a flag since M111, during
>> which time we have gathered feedback from developers, partners, and
>> Chrome's testing infrastructure to find and address issues on multiple
>> mobile GPU architectures.
>>
>> WebGPU is the successor to the WebGL and WebGL 2 graphics APIs for the
>> Web. It provides modern features such as “GPU compute” as well as lower
>> overhead access to GPU hardware and better, more predictable performance.
>> WebGPU is developed by the “GPU for the Web” W3C community group.
>>
>>
>> Blink component Blink>WebGPU
>> 
>>
>> TAG review https://github.com/w3ctag/design-reviews/issues/626
>>
>> TAG review status Issues addressed
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> With positive signals (and at least WIP implementations) from all
>> browsers and few unresolved issues in the spec repo, the compatibility risk
>> is low and mostly if other implementers find bugs in the spec as they flesh
>> out their WebGPU implementation.
>>
>>
>> *Gecko*: Positive (https://mozilla.github.io/standards-positions/#webgpu)
>>
>> *WebKit*: In development (
>> https://github.com/WebKit/WebKit/tree/main/Source/WebGPU/WebGPU)
>> Standards position issue:
>> https://github.com/WebKit/standards-positions/issues/107
>>
>> *Web developers*: Strongly positive
>>
>> Security
>>
>> See detailed security explainer:
>> https://gpuweb.github.io/gpuweb/#malicious-use
>>
>>
>> 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
>>
>> Warnings and errors are exposed via dev tools. Specialized tools can be
>> built directly in JavaScript, integrated in applications or as devtools
>> extensions.
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)? No
>>
>> Once enabled on Android, the only Blink platform where WebGPU will not be
>> enabled by default yet is Linux.
>>
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ? Yes
>>
>> The WebGPU Conformance Test Suite is being built at
>> https://github.com/gpuweb/cts and can be integrated as a subdirectory of
>> WPT. It is already integreated into the Chromium CI infrastructure.
>>
>> DevTrial instructions
>> https://github.com/gpuweb/gpuweb/wiki/Implementation-Status#chromium-chrome-edge-etc
>>
>> Flag name on chrome://flags --enable-unsafe-webgpu
>>
>> Finch feature name WebGPUService
>>
>> Requires code in //chrome? False
>>
>> Availability expectation Feature will initially be enabled for Adreno
>> and Mali GPUs (the majority of the mobile market) on Android 12+, with
>> other hardware and OS versions added in the future as additional testing
>> and bug fixes allow. More broadly while there is no timeline commitment
>> from Firefox or Safari both browsers are known to be actively implementing
>> WebGPU and are anticipated to ship once their implementations are
>> sufficiently conformant.
>>
>> Sample links
>> https://github.com/austinEng/webgpu-samples
>>
>> Estimated milestones
>> Shipped on desktop 113
>> OriginTrial desktop last 114
>> OriginTrial desktop first 94
>> Shipping on Android 121
>> DevTrial on Android 111
>>
>> Anticipated spec changes Discussion on the core WebGPU and WGSL
>> specification has been minimal since the API was shipped on desktop, with
>> most ongoing discussion centered around additional features that can be
>> layered onto the API. While we are still open to minor spec bug fixes at
>> this point the overwhelming majority of the spec should see no behavioral
>> changes.
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5119617865613312
>>
>> Links to previous

Re: [blink-dev] Intent to Ship: WebGPU on Android

['Brandon Jones' via blink-dev]

Thanks! It was unclear what the procedure was here since this isn't a new
feature, just enabling it on a new platform. I'll make sure they are
updated appropriately.

--Brandon

On Fri, Oct 27, 2023 at 2:04 PM Chris Harrelson 
wrote:

>
>
> On Fri, Oct 27, 2023 at 1:57 PM Mike Taylor 
> wrote:
>
>> LGTM2 % requesting all of the review gates in the chromestatus entry.
>>
> Ah yes - please do start those reviews. Likely you can mark them as N/A
> because this is just shipping an existing API on a new platform.
>
>
>> On 10/27/23 4:25 PM, Chris Harrelson wrote:
>>
>> LGTM1 - this is an easy one :)
>>
>> On Fri, Oct 27, 2023 at 1:21 PM 'Brandon Jones' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> Contact emails bajo...@chromium.org, cwal...@chromium.org
>>>
>>> Explainer https://gpuweb.github.io/gpuweb/explainer/
>>>
>>> Specification https://www.w3.org/TR/webgpu
>>>
>>> Design docs
>>> https://gpuweb.github.io/gpuweb
>>> https://gpuweb.github.io/gpuweb/wgsl
>>> https://gpuweb.github.io/gpuweb/explainer
>>>
>>> Summary
>>> This Intent to Ship is specifically for enabling WebGPU by default on
>>> Android. WebGPU previously launched on Windows, MacOS, and ChromeOS in
>>> M113. See https://chromestatus.com/feature/6213121689518080 for
>>> details.
>>>
>>> WebGPU has been available on Android behind a flag since M111, during
>>> which time we have gathered feedback from developers, partners, and
>>> Chrome's testing infrastructure to find and address issues on multiple
>>> mobile GPU architectures.
>>>
>>> WebGPU is the successor to the WebGL and WebGL 2 graphics APIs for the
>>> Web. It provides modern features such as “GPU compute” as well as lower
>>> overhead access to GPU hardware and better, more predictable performance.
>>> WebGPU is developed by the “GPU for the Web” W3C community group.
>>>
>>>
>>> Blink component Blink>WebGPU
>>> 
>>>
>>> TAG review https://github.com/w3ctag/design-reviews/issues/626
>>>
>>> TAG review status Issues addressed
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> With positive signals (and at least WIP implementations) from all
>>> browsers and few unresolved issues in the spec repo, the compatibility risk
>>> is low and mostly if other implementers find bugs in the spec as they flesh
>>> out their WebGPU implementation.
>>>
>>>
>>> *Gecko*: Positive (https://mozilla.github.io/standards-positions/#webgpu
>>> )
>>>
>>> *WebKit*: In development (
>>> https://github.com/WebKit/WebKit/tree/main/Source/WebGPU/WebGPU)
>>> Standards position issue:
>>> https://github.com/WebKit/standards-positions/issues/107
>>>
>>> *Web developers*: Strongly positive
>>>
>>> Security
>>>
>>> See detailed security explainer:
>>> https://gpuweb.github.io/gpuweb/#malicious-use
>>>
>>>
>>> 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
>>>
>>> Warnings and errors are exposed via dev tools. Specialized tools can be
>>> built directly in JavaScript, integrated in applications or as devtools
>>> extensions.
>>>
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>>> Linux, Chrome OS, Android, and Android WebView)? No
>>>
>>> Once enabled on Android, the only Blink platform where WebGPU will not
>>> be enabled by default yet is Linux.
>>>
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ? Yes
>>>
>>> The WebGPU Conformance Test Suite is being built at
>>> https://github.com/gpuweb/cts and can be integrated as a subdirectory
>>> of WPT. It is already integreated into the Chromium CI infrastructure.
>>>
>>> DevTrial instructions
>>> https://github.com/gpuweb/gpuweb/wiki/Implementation-Status#chromium-chrome-edge-etc
>>>
>>> Flag name on chrome://flags --enable-unsafe-webgpu
>>>
>>> Finch feature name WebGPUService
>>>
>>> Requires code in //chrome? False
>>>
>>> Availability expectation Feature will initially be enabled for Adreno
>>> and Mali GPUs (the majority of the mobile market) on Android 12+, with
>>> other hardware and OS versions added in the future as additional testing
>>> and bug fixes allow. More broadly while there is no timeline commitment
>>> from Firefox or Safari both browsers are known to be actively implementing
>>> WebGPU and are anticipated to ship once their implementations are
>>> sufficiently conformant.
>>>
>>> Sample links
>>> https://github.com/austinEng/webgpu-samples
>>>
>>> Estimated milestones
>>> Shipped on desktop 113
>>> OriginTrial desktop last 114
>>> OriginTrial desktop first 94
>>> Shipping on Android 121
>>> DevTrial on Android 111
>>>
>>> Anticipated spec changes Discussion on the core WebGPU and WGSL
>>> specification has been minimal since the API was ship

Re: [blink-dev] Intent to Ship: Private Aggregation API: aggregation coordinator selection

[Chris Harrelson]

LGTM1

On Fri, Oct 20, 2023 at 9:44 AM Alex Turner  wrote:

> Contact emails
>
> ale...@chromium.org
>
> Explainer
> https://github.com/patcg-individual-drafts/private-aggregation-api#aggregation-coordinator-choice
> Specification
> https://github.com/patcg-individual-drafts/private-aggregation-api/pull/106
> Summary
>
> Modification to the Private Aggregation API to provide a mechanism for
> selecting which coordinator to use for payload encryption (from a
> vendor-specified allowlist). The choice of service is made with an
> additional option in Shared Storage’s run() and selectURL() calls, and in
> Protected Audience’s runAdAuction() and joinAdInterestGroup() calls. The
> broad approach largely aligns with Attribution Reporting’s approach (see
> https://chromestatus.com/feature/5197591256236032).
>
> Blink component
>
> Blink>PrivateAggregation
> 
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/846 (We have not
> requested a signal for these changes specifically.)
>
> TAG review status
>
> Pending
>
> Risks
>
> Interoperability and Compatibility
>
> This feature is optional and backwards compatible.
>
> Gecko: No signal (
> https://github.com/mozilla/standards-positions/issues/805) We have not
> requested a signal for these changes specifically. The Gecko position on
> Shared Storage (one of the ways Private Aggregation is exposed) is negative.
>
> WebKit: No signal (
> https://github.com/WebKit/standards-positions/issues/189) We have not
> requested a signal for these changes specifically.
>
> Web developers: No signals
>
> 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
>
> No new debug capabilities beyond the existing internals page
> (chrome://private-aggregation-internals) and temporary debug mode.
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?
>
> All but Webview
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?
>
> WPTs will be added when the feature is enabled.
>
> Flag name on chrome://flags
>
> None
>
> Finch feature name
>
> PrivateAggregationApiMultipleCloudProviders
>
> Requires code in //chrome?
>
> False
>
> Tracking bug
>
> https://crbug.com/1481761
>
> Launch bug
>
> https://launch.corp.google.com/launch/4272421
>
> Estimated milestones
>
> We intend to ship in M120.
>
> Anticipated spec changes
>
> None
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5140711678935040
>
> Links to previous Intent discussions
>
> Original I2S
> ,
> Follow-up enhancements I2S
> 
>
>
> This intent message was generated by Chrome Platform Status
> .
>
> --
> 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/CAA%2BBiFmJSK39%3D%3DRoWBmxnmZ2Y3h4krDKFBa_CUHAH%2BzjXj-T3A%40mail.gmail.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 on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_P9BF5jKV9%3DFLY4CfJXHy%2BiCR%2Bofg6gMS%3DLDcbUDxkVw%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Array.fromAsync

[Chris Harrelson]

LGTM3

On Thu, Oct 26, 2023 at 4:04 PM Johnny Stenback 
wrote:

> +1 to what Chris said. And if you feel a gate doesn't apply, you can state
> in a comment that you believe the result of the review should be n/a. And
> we're in fact in the midst of landing a short-hand button that does that
> for all approval gate chips.
>
> Cheers,
> Johnny
>
> On Thu, Oct 26, 2023 at 8:21 AM Chris Harrelson 
> wrote:
>
>>
>>
>> On Wed, Oct 25, 2023 at 5:05 PM Shu-yu Guo  wrote:
>>
>>> Those gates are not applicable for most TC39 stage 3 features, including
>>> this one. Are you asking them to be marked as such or that we requested
>>> reviews for it?
>>>
>>
>> I think they are. TC39 stage 3 features can skip a TAG review and
>> signals, but the other fields are still required.
>>
>>
>>>
>>> On Wed, Oct 25, 2023 at 4:00 PM Mike Taylor 
>>> wrote:
>>>
 Oops... sent too early. Can you also please request reviews for the
 rest of the review gates
 
 in the chromestatus entry?
 On 10/25/23 6:57 PM, Mike Taylor wrote:

 LGTM1. It's encouraging that Firefox Nightly shipped this a few months
 back  with no
 reported regressions thus far.
 On 10/25/23 6:39 PM, Rezvan Mahdavi Hezaveh wrote:

 Contact emails s...@chromium.org, rez...@chromium.org

 Explainer https://github.com/tc39/proposal-array-from-async

 Specification https://tc39.es/proposal-array-from-async

 Summary

 Array.fromAsync is the async version of Array.from. It takes async
 iterables, iterates them, and collects the results into an array.


 Blink component Blink>JavaScript>Language
 

 TAG review None

 TAG review status Not applicable

 Risks


 Interoperability and Compatibility

 No known interop or web compat risk.


 *Gecko*: Positive (https://bugzilla.mozilla.org/show_bug.cgi?id=1746209)
 This is a TC39 Stage 3 proposal.

 *WebKit*: Positive This is a TC39 Stage 3 proposal.

 *Web developers*: Positive (
 https://twitter.com/erickwendel_/status/1555206623836127232) Seems
 positive, lots of likes on Twitter.

 *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

 It is debugged as any other static method in JavaScript.


 Will this feature be supported on all six Blink platforms (Windows,
 Mac, Linux, Chrome OS, Android, and Android WebView)? Yes

 Is this feature fully tested by web-platform-tests
 
 ? Yes

 https://github.com/tc39/test262/issues/3725


 Flag name on chrome://flags --harmony_array_from_async

 Finch feature name None

 Non-finch justification None

 Requires code in //chrome? False

 Tracking bug https://bugs.chromium.org/p/v8/issues/detail?id=13321

 Estimated milestones
 DevTrial on desktop 120
 DevTrial on Android 120

 Anticipated spec changes

 Open questions about a feature may be a source of future web compat or
 interop issues. Please list open issues (e.g. links to known github issues
 in the project for the feature specification) whose resolution may
 introduce web compat/interop risk (e.g., changing to naming or structure of
 the API in a non-backward-compatible way).
 None

 Link to entry on the Chrome Platform Status
 https://chromestatus.com/feature/5069575759069184

 This intent message was generated by Chrome Platform Status
 .
 --
 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/CACJ3t%2Bg4MwKGhiGJg%2B0WdgJXTD0rGJ22ZFGAF8bnOtGoLhszzA%40mail.gmail.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 on the web visit
 https://groups.google.c

Re: [blink-dev] Re: Intent to Ship: FedCM extensions: Error API and Auto-Selected Flag API

[Rick Byers]

FedCM has decided to follow a WHATWG-like working mode
 where normative PRs land only
with 2+ implementer support. Given that reviews were requested almost 2
months ago, and the blink launch process is designed not to stall
indefinitely on consensus, I don't think API owners should be blocking this
intent further on the PRs landing. Mike, WDYT?

Rick

On Fri, Oct 27, 2023 at 4:45 PM Mike Taylor  wrote:

> Thanks Nicolás and Yi.
>
> LGTM1 % the PRs landing before this ships, and assuming Mozilla does not
> have feedback that materially changes the API shape. If that's the case,
> can you report back?
>
> thanks,
> Mike
> On 10/26/23 10:27 AM, Nicolás Peña wrote:
>
> For the record, we did request reviews: here
>  and
> here .
> I'll ask to see if they can be added to the set of users from whom we can
> 'request review' in GitHub UI.
> On Wednesday, October 25, 2023 at 7:17:53 PM UTC-4 Yi Gu wrote:
>
>> We sync’d with @bvandersloot-mozilla
>>  in FedIdCG [1] and they have
>> confirmed that it’s on their list.
>>
>> [1]
>>
>> https://github.com/fedidcg/meetings/blob/main/2023/2023-10-02-notes.md#notes
>>
>> On Wed, Oct 25, 2023 at 6:51 PM Mike Taylor 
>> wrote:
>>
>>> On 10/25/23 4:14 PM, Yi Gu wrote:
>>>
>>> Thanks Yoav for the review!
>>>
>>> > It'd be useful to write a short (inline?) explainer here outlining
>>> what this does and how it'd look like. Specifically, would we start
>>> throwing on errors in scenarios that silently failed before?
>>>
>>> For the Error API, it allows IdP to signal to the browser about the
>>> sign-in failure details such that the browser can make sure the user is
>>> kept informed with possibly next steps. Without this API, when a user
>>> clicks the "Continue as Name" button to sign-in, if it fails for whatever
>>> reasons, the browser rejects the promise silently so the user could be
>>> confused about the status. The fact that we are delaying rejecting the
>>> promise (for privacy reasons) would make it worse because the website
>>> wouldn't learn about the failure immediately either. With this API, the
>>> browser will first show a native UI with proper strings to explain the
>>> error to users and possibly allow users to learn more about next steps. It
>>> will also reject the promise with the errors (if provided by IdP) via
>>> IdentityCredentialError instead of a generic DOMException (which we
>>> currently use). You could find more details here
>>> .
>>>
>>> For the AutoSelected Flag API, it shares whether auto re-authentication
>>> has been triggered during the flow with both IdP and RP. By default the
>>> CredentialManagement API supports credential auto selection when possible.
>>> However, the browser may decide not to trigger auto selection for
>>> legitimate reasons. While the exact reason should be opaque to IdP or RP,
>>> we could share with them the outcome such that they can better understand
>>> the flow and handle things differently. e.g. for metrics purposes they
>>> could know how many transactions were done with auto re-authentication to
>>> better understand the performance; in addition, an IdP can use the signal
>>> (boolean) to support some security related features. e.g. a user may prefer
>>> explicitly selecting an account with an IdP, if the IdP gets a token
>>> request that shows the account was automatically selected, they could
>>> reject the request and trigger a new sign-in flow to ask for explicit user
>>> mediation. You could find more details here.
>>> 
>>>
>>> > What's preventing these PRs from landing?
>>>
>>> We aligned with Mozilla, who is prototyping FedCM in Firefox right now,
>>> that such spec changes should be reviewed by at least two implementers
>>> before merging. While we have discussed the two APIs
>>> 
>>> at FedIdCG and it "generally looks reasonable", it's not yet formally
>>> reviewed by Mozilla (hence the "Under consideration" signal).
>>>
>>> I don't see anyone from Mozilla as a reviewer for either PR - is there a
>>> plan to request review from them?
>>>
>>>
>>> Thanks.
>>> Yi
>>>
>>> On Wed, Oct 25, 2023 at 11:19 AM Yoav Weiss 
>>> wrote:
>>>


 On Monday, October 23, 2023 at 3:03:59 PM UTC+2 blink-dev wrote:

 Contact emails

 y...@chromium.org

 Explainer

 https://github.com/fedidcg/FedCM/issues/488


 It'd be useful to write a short (inline?) explainer here outlining what
 this does and how it'd look like.
 Specifically, would we start throwing on errors in scenarios that
 silently failed before?


 https://github.

Re: [blink-dev] Intent to Experiment: Extending Storage Access API (SAA) to non-cookie storage

[Chris Harrelson]

Can you please also fill out the *Goals for experimentation* section?

On Thu, Oct 26, 2023 at 8:21 AM Ari Chivukula  wrote:

> Contact emails
>
> aric...@chromium.org, wanderv...@chromium.org, johann...@chromium.org,
> hele...@google.com
>
>
> Specification
>
> https://arichiv.github.io/saa-non-cookie-storage/
>
>
> Feedback
>
> https://github.com/arichiv/saa-non-cookie-storage/issues
>
>
> Intent to Prototype
>
> https://groups.google.com/a/chromium.org/g/blink-dev/c/inRN8tI49O0
>
>
> Summary
>
> An origin trial
> ,
> StorageAccessAPIBeyondCookies, will be made available which enables the
> proposed extension of the Storage Access API
>  (backwards
> compatible) to allow access to unpartitioned (cookie and non-cookie)
> storage in a third-party context. The current API only provides access to
> cookies, which have different use-cases than non-cookie storage (discussed
> more in the Motivation section). The API can be used as follows (JS running
> in an embedded iframe):
>
>
> // Request a new storage handle via rSA (this should prompt the user)
>
> let handle = await document.requestStorageAccess({all: true});
>
> // Write some 1P context sessionstorage
>
> handle.sessionStorage.setItem("userid", "1234");
>
> // Write some 1P context localstorage
>
> handle.localStorage.setItem("preference", "A");
>
> // Open or create an indexedDB that is shared with the 1P context
>
> let messageDB = handle.indexedDB.open("messages");
>
> // Use locks shared with the 1P context
>
> await handle.locks.request(“example”, …);
>
>
> The same flow would be used by iframes to get a storage handle when their
> top-level ancestor successfully called rSAFor
> , just that in this
> case the storage-access permission was already granted and thus the rSA
> call would not require a user gesture or show a prompt, allowing for
> “hidden” iframes accessing storage.
>
>
> Beyond calling this additional extension, access to non-cookie storage
> would match the current requirements for cookie access through the Storage
> Access API. For example, in Chrome, no prompt is shown when the origins are
> in the same RWS (Related Website Sets, the new name for First Party Sets).
> Origins that are not part of the same RWS would be subject to the prompting
> requirements of the Storage Access API in Chrome
> .
>
>
> The origin trial will be available from M120 until M124 (or after Tue,
> June 11, 2024 in any milestone).
>
>
> Only Session Storage, Local Storage, Indexed DB, and Web Locks will be
> available initially, but other storage and communication mechanisms will be
> added to the Origin Trial in future milestones. These additions will be
> announced in this thread after each branch cut. Feedback from developers
> would aid us in prioritizing specific mechanisms for inclusion.
>
>
> Blink component
>
> Blink>StorageAccessAPI
> 
>
>
> Motivation
>
> There has been increasing developer
> 
> and implementer 
> interest in first-party DOM Storage
>  and Quota
> Managed Storage
>  being
> available in third-party contexts the same way that Cookies already can be
> . In the absence of such a
> solution, we would in effect be pushing developers to migrate to Cookies
> from other storage mechanisms. There are tradeoffs between Cookie and
> non-Cookie storage (size, flexibility, server exposure, network request
> size, etc.) that could impact user experience from a privacy, security and
> performance perspective (e.g., cookies are included in HTTP requests and
> not just available via JavaScript). To prevent sub-optimal use of cookies
> and to preserve context, we propose a solution for developers to regain 3p
> access to unpartitioned storage to avoid user-facing breakage in browsers
> shipping storage partitioning.
>
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/906
>
>
> Compatibility
>
> The Storage Access API is already implemented in Safari, Firefox, and
> Chrome , but
> the proposed API shape would not change existing behavior without new
> arguments added.
>
>
> Interoperability
>
> Gecko: No Position Yet
> https://github.com/mozilla/standards-positions/issues/898
>
> WebKit: No Position Yet
> https://github.com/WebKit/standards-positions/issues/262
>
> Web developers: Positive
> 

Re: [blink-dev] Re: Intent to Ship: FedCM extensions: Error API and Auto-Selected Flag API

[Chris Harrelson]

However, even for WHATWG specs we have in the past blocked approval until
spec PRs landed in cases where the only blocker was editorial review. This
appears to be a similar situation.

On Fri, Oct 27, 2023 at 2:17 PM Rick Byers  wrote:

> FedCM has decided to follow a WHATWG-like working mode
>  where normative PRs land
> only with 2+ implementer support. Given that reviews were requested almost
> 2 months ago, and the blink launch process is designed not to stall
> indefinitely on consensus, I don't think API owners should be blocking this
> intent further on the PRs landing. Mike, WDYT?
>
> Rick
>
> On Fri, Oct 27, 2023 at 4:45 PM Mike Taylor 
> wrote:
>
>> Thanks Nicolás and Yi.
>>
>> LGTM1 % the PRs landing before this ships, and assuming Mozilla does not
>> have feedback that materially changes the API shape. If that's the case,
>> can you report back?
>>
>> thanks,
>> Mike
>> On 10/26/23 10:27 AM, Nicolás Peña wrote:
>>
>> For the record, we did request reviews: here
>>  and
>> here .
>> I'll ask to see if they can be added to the set of users from whom we can
>> 'request review' in GitHub UI.
>> On Wednesday, October 25, 2023 at 7:17:53 PM UTC-4 Yi Gu wrote:
>>
>>> We sync’d with @bvandersloot-mozilla
>>>  in FedIdCG [1] and they have
>>> confirmed that it’s on their list.
>>>
>>> [1]
>>>
>>> https://github.com/fedidcg/meetings/blob/main/2023/2023-10-02-notes.md#notes
>>>
>>> On Wed, Oct 25, 2023 at 6:51 PM Mike Taylor 
>>> wrote:
>>>
 On 10/25/23 4:14 PM, Yi Gu wrote:

 Thanks Yoav for the review!

 > It'd be useful to write a short (inline?) explainer here outlining
 what this does and how it'd look like. Specifically, would we start
 throwing on errors in scenarios that silently failed before?

 For the Error API, it allows IdP to signal to the browser about the
 sign-in failure details such that the browser can make sure the user is
 kept informed with possibly next steps. Without this API, when a user
 clicks the "Continue as Name" button to sign-in, if it fails for whatever
 reasons, the browser rejects the promise silently so the user could be
 confused about the status. The fact that we are delaying rejecting the
 promise (for privacy reasons) would make it worse because the website
 wouldn't learn about the failure immediately either. With this API, the
 browser will first show a native UI with proper strings to explain the
 error to users and possibly allow users to learn more about next steps. It
 will also reject the promise with the errors (if provided by IdP) via
 IdentityCredentialError instead of a generic DOMException (which we
 currently use). You could find more details here
 .

 For the AutoSelected Flag API, it shares whether auto re-authentication
 has been triggered during the flow with both IdP and RP. By default the
 CredentialManagement API supports credential auto selection when possible.
 However, the browser may decide not to trigger auto selection for
 legitimate reasons. While the exact reason should be opaque to IdP or RP,
 we could share with them the outcome such that they can better understand
 the flow and handle things differently. e.g. for metrics purposes they
 could know how many transactions were done with auto re-authentication to
 better understand the performance; in addition, an IdP can use the signal
 (boolean) to support some security related features. e.g. a user may prefer
 explicitly selecting an account with an IdP, if the IdP gets a token
 request that shows the account was automatically selected, they could
 reject the request and trigger a new sign-in flow to ask for explicit user
 mediation. You could find more details here.
 

 > What's preventing these PRs from landing?

 We aligned with Mozilla, who is prototyping FedCM in Firefox right now,
 that such spec changes should be reviewed by at least two implementers
 before merging. While we have discussed the two APIs
 
 at FedIdCG and it "generally looks reasonable", it's not yet formally
 reviewed by Mozilla (hence the "Under consideration" signal).

 I don't see anyone from Mozilla as a reviewer for either PR - is there
 a plan to request review from them?


 Thanks.
 Yi

 On Wed, Oct 25, 2023 at 11:19 AM Yoav Weiss 
 wrote:

>
>
> On Monday, October 23, 2023 at 3:03:59 PM UTC+2 blink-dev wrote:
>
> Contact emails
>
>>>

Re: [blink-dev] Intent to Ship: Private Aggregation API: aggregation coordinator selection

[Mike Taylor]

LGTM2

On 10/27/23 5:13 PM, Chris Harrelson wrote:

LGTM1

On Fri, Oct 20, 2023 at 9:44 AM Alex Turner  wrote:


Contact emails

ale...@chromium.org


Explainer



https://github.com/patcg-individual-drafts/private-aggregation-api#aggregation-coordinator-choice




Specification



https://github.com/patcg-individual-drafts/private-aggregation-api/pull/106




Summary

Modification to the Private Aggregation API to provide a mechanism
for selecting which coordinator to use for payload encryption
(from a vendor-specified allowlist). The choice of service is made
with an additional option in Shared Storage’s run() and
selectURL() calls, and in Protected Audience’s runAdAuction() and
joinAdInterestGroup() calls. The broad approach largely aligns
with Attribution Reporting’s approach
(seehttps://chromestatus.com/feature/5197591256236032
).


Blink component

Blink>PrivateAggregation




TAG review

https://github.com/w3ctag/design-reviews/issues/846
(We have not
requested a signal for these changes specifically.)


TAG review status

Pending


Risks



Interoperability and Compatibility

This feature is optional and backwards compatible.


Gecko: No signal
(https://github.com/mozilla/standards-positions/issues/805
) We
have not requested a signal for these changes specifically. The
Gecko position on Shared Storage (one of the ways Private
Aggregation is exposed) is negative.


WebKit: No signal
(https://github.com/WebKit/standards-positions/issues/189
) We
have not requested a signal for these changes specifically.


Web developers: No signals


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

No new debug capabilities beyond the existing internals page
(chrome://private-aggregation-internals) and temporary debug mode.



Will this feature be supported on all six Blink platforms
(Windows, Mac, Linux, Chrome OS, Android, and Android
WebView)?

All but Webview



Is this feature fully tested by web-platform-tests

?

WPTs will be added when the feature is enabled.


Flag name on chrome://flags

None


Finch feature name

PrivateAggregationApiMultipleCloudProviders


Requires code in //chrome?

False


Tracking bug

https://crbug.com/1481761 


Launch bug

https://launch.corp.google.com/launch/4272421



Estimated milestones

We intend to ship in M120.


Anticipated spec changes

None


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5140711678935040



Links to previous Intent discussions

Original I2S

,
Follow-up enhancements I2S





This intent message was generated by Chrome Platform Status
.
-- 
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/CAA%2BBiFmJSK39%3D%3DRoWBmxnmZ2Y3h4krDKFBa_CUHAH%2BzjXj-T3A%40mail.gmail.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.

Re: [blink-dev] Re: Intent to Ship: HTTPS Upgrades

[Franky Rios]

I have a website that needs to receive "Header Enrichment" over HTTP, which 
reads the MSISDN when the user browses via their mobile data.

Previously, the user accessed via HTTPS, and we would switch to HTTP to 
perform the "Header Enrichment" reading and then switch back to HTTPS.

With this update, I see that there is a Non-Authoritative-Reason: 
HttpsUpgrades. It stops the HTTP request and switches it to HTTPS. This 
prevents me from performing the "Header Enrichment" injection reading over 
HTTP.

What solution could you provide? Is there any way from my infrastructure to 
block this Non-Authoritative-Reason: HttpsUpgrades, in other words, to 
block Chrome from redirecting me to HTTPS?






El martes, 17 de octubre de 2023 a la(s) 01:50:31 UTC-5, Mike West escribió:

> Fantastic, thanks for the update. Hope it sticks!
>
> -mike
>
> On Mon, Oct 16, 2023 at 20:15 Chris Thompson  wrote:
>
>> We enabled HTTPS-Upgrades by default on trunk last week, and are 
>> currently rolling out to 100% Stable.
>>
>> On Thu, Oct 5, 2023 at 10:42 AM Chris Thompson  
>> wrote:
>>
>>> This week we increased the rollout of HTTPS Upgrades up to 35% Stable. 
>>> We are continuing to monitor issues and feedback. Given that we have not 
>>> heard any unexpected feedback yet we are planning to proceed to 100% Stable 
>>> next week.
>>>
>>> On Fri, Sep 1, 2023 at 10:42 AM Chris Thompson  
>>> wrote:
>>>
 This is currently enabled at 20% Stable. We have not heard any 
 unexpected feedback yet, and are continuing to monitor for issues and 
 feedback.

 On Thu, Aug 24, 2023 at 9:51 AM Daniel Bratell  
 wrote:

> Same (LGTM).
>
> I assume you have also not had any unexpected feedback. The methods 
> you added to force http seemed adequate but you never know when you 
> encounter the wild wild web.
>
> /Daniel
> On 2023-08-23 18:45, Chris Harrelson wrote:
>
> Still LGTM from me too.
>
> On Wed, Aug 23, 2023 at 8:58 AM Yoav Weiss  
> wrote:
>
>> Still LGTM
>>
>> On Wed, Aug 23, 2023 at 5:47 PM Chris Thompson  
>> wrote:
>>
>>> We have iterated on the Fetch spec PR 
>>>  and believe it is ready 
>>> to land modulo some editorial tweaks.
>>>
>>
>> Please be sure to follow up on the PR once the reviewers get back to 
>> it.
>>  
>>
>>>
>>> From our 1% Stable experiment, we saw a substantial decrease in 
>>> insecure plaintext HTTP navigation requests, and no regressions in Core 
>>> Web 
>>> Vitals metrics.
>>>
>>> We would like to proceed with this Intent-to-Ship, doing a gradual 
>>> rollout to 100% in order to continue monitoring potential breakage.
>>>
>>> We did see a possible regression in renderer crash proportion, but 
>>> we have not been able to identify a plausible cause or crash signature. 
>>> Due 
>>> to this possible stability risk we will be coordinating our gradual 
>>> rollout 
>>> with release owners. I can update this thread each time we increase our 
>>> rollout percentage.
>>>
>>> - Chris
>>>
>>>
>>>
>>>
>>> On Wed, Jul 19, 2023 at 9:01 PM Yoav Weiss  
>>> wrote:
>>>
 LGTM3 with similar conditions. If the PR takes an unreasonable 
 amount of time to land, please let us know.

 On Wed, Jul 19, 2023 at 9:02 PM Chris Harrelson <
 chri...@chromium.org> wrote:

> LGTM2 with the same conditions as Daniel. Thanks also for 
> following up with a summary before proceeding with rollout!
>
> On Wed, Jul 19, 2023 at 11:56 AM Chris Thompson <
> cth...@chromium.org> wrote:
>
>> Thanks Daniel. As a quick update, this was just enabled at 1% 
>> Stable in M115 (released yesterday). We have not seen any blockers 
>> come up 
>> from Beta, but since issues may arise mainly in the long tail of 
>> sites we 
>> might not see anything until Stable anyway. We'll keep an eye on our 
>> experimental rollout and follow up here with a summary.
>>
>> On Wed, Jul 19, 2023 at 11:52 AM Daniel Bratell <
>> brat...@gmail.com> wrote:
>>
>>> I've been waiting a bit to see if the experiment would blow 
>>> anything up, but if it doesn't, and continue to not do so, then
>>>
>>> LGTM1 as soon as the PR has landed.
>>>
>>> /Daniel
>>> On 2023-06-14 17:40, Yoav Weiss wrote:
>>>
>>>
>>>
>>> On Thursday, June 8, 2023 at 5:53:49 PM UTC+2 Chris Thompson 
>>> wrote:
>>>
>>> On Wed, Jun 7, 2023 at 9:41 PM Yoav Weiss  
>>> wrote:
>>>
>>> Thanks for working on this!
>>>
>>> On Wed, Jun 7, 2023 at 11:44 PM Chris Thompson <
>>> cth...@chromium.org> 

[blink-dev] Intent to Prototype: WebAuthn related origins

[Adam Langley]

*Contact emails*
a...@chromium.org

*Explainer*
https://github.com/w3c/webauthn/wiki/Explainer:-Related-origin-requests

*Summary*
All WebAuthn credentials are associated with a single Relying Party ID (“RP
ID”), which is essentially a domain name, and all WebAuthn requests are
processed in the context of an RP ID. This RP ID system has existed since
WebAuthn level one, but creates a number of challenges, most prominently
for sites that have any country-specific domains. The related-origins
facility is a well-known URL where an origin can list other origins that
are authorized to use it as an RP ID.

*Blink component*
Blink>WebAuthentication

*TAG review status*
Pending

*Risks*

Interoperability and Compatibility: fragmentation risk if other browsers
don't adopt it. We don't intend to have something that isn't commonly
supported because that wouldn't be useful for sites.

WebKit / Mozilla: No signal yet


Web developers: Affected sites are keen in private conversations.


*WebView application risks*
There isn't support for WebAuthn in general WebViews.

*Finch feature name*
WebAuthenticationRelatedOrigin

*Requires code in //chrome?*
No. (Only tests.)

*Chrome Platform Status*
https://chromestatus.com/feature/4635336177352704

-- 
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/CAL9PXLxAa9zkjZMvBHMxC57w%2Bs9j7XpUcV6rKv7y7cCvNAB3Eg%40mail.gmail.com.

Re: [blink-dev] Intent to Experiment: Extending Storage Access API (SAA) to non-cookie storage

[Ari Chivukula]

Done.

~ Ari Chivukula (Their/There/They're)


On Fri, Oct 27, 2023 at 5:25 PM Chris Harrelson 
wrote:

> Can you please also fill out the *Goals for experimentation* section?
>
> On Thu, Oct 26, 2023 at 8:21 AM Ari Chivukula 
> wrote:
>
>> Contact emails
>>
>> aric...@chromium.org, wanderv...@chromium.org, johann...@chromium.org,
>> hele...@google.com
>>
>>
>> Specification
>>
>> https://arichiv.github.io/saa-non-cookie-storage/
>>
>>
>> Feedback
>>
>> https://github.com/arichiv/saa-non-cookie-storage/issues
>>
>>
>> Intent to Prototype
>>
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/inRN8tI49O0
>>
>>
>> Summary
>>
>> An origin trial
>> ,
>> StorageAccessAPIBeyondCookies, will be made available which enables the
>> proposed extension of the Storage Access API
>> 
>> (backwards compatible) to allow access to unpartitioned (cookie and
>> non-cookie) storage in a third-party context. The current API only provides
>> access to cookies, which have different use-cases than non-cookie storage
>> (discussed more in the Motivation section). The API can be used as follows
>> (JS running in an embedded iframe):
>>
>>
>> // Request a new storage handle via rSA (this should prompt the user)
>>
>> let handle = await document.requestStorageAccess({all: true});
>>
>> // Write some 1P context sessionstorage
>>
>> handle.sessionStorage.setItem("userid", "1234");
>>
>> // Write some 1P context localstorage
>>
>> handle.localStorage.setItem("preference", "A");
>>
>> // Open or create an indexedDB that is shared with the 1P context
>>
>> let messageDB = handle.indexedDB.open("messages");
>>
>> // Use locks shared with the 1P context
>>
>> await handle.locks.request(“example”, …);
>>
>>
>> The same flow would be used by iframes to get a storage handle when their
>> top-level ancestor successfully called rSAFor
>> , just that in
>> this case the storage-access permission was already granted and thus the
>> rSA call would not require a user gesture or show a prompt, allowing for
>> “hidden” iframes accessing storage.
>>
>>
>> Beyond calling this additional extension, access to non-cookie storage
>> would match the current requirements for cookie access through the Storage
>> Access API. For example, in Chrome, no prompt is shown when the origins are
>> in the same RWS (Related Website Sets, the new name for First Party Sets).
>> Origins that are not part of the same RWS would be subject to the prompting
>> requirements of the Storage Access API in Chrome
>> .
>>
>>
>> The origin trial will be available from M120 until M124 (or after Tue,
>> June 11, 2024 in any milestone).
>>
>>
>> Only Session Storage, Local Storage, Indexed DB, and Web Locks will be
>> available initially, but other storage and communication mechanisms will be
>> added to the Origin Trial in future milestones. These additions will be
>> announced in this thread after each branch cut. Feedback from developers
>> would aid us in prioritizing specific mechanisms for inclusion.
>>
>>
>> Blink component
>>
>> Blink>StorageAccessAPI
>> 
>>
>>
>> Motivation
>>
>> There has been increasing developer
>> 
>> and implementer 
>> interest in first-party DOM Storage
>>  and Quota
>> Managed Storage
>>  being
>> available in third-party contexts the same way that Cookies already can
>> be . In the absence of such
>> a solution, we would in effect be pushing developers to migrate to Cookies
>> from other storage mechanisms. There are tradeoffs between Cookie and
>> non-Cookie storage (size, flexibility, server exposure, network request
>> size, etc.) that could impact user experience from a privacy, security and
>> performance perspective (e.g., cookies are included in HTTP requests and
>> not just available via JavaScript). To prevent sub-optimal use of cookies
>> and to preserve context, we propose a solution for developers to regain 3p
>> access to unpartitioned storage to avoid user-facing breakage in browsers
>> shipping storage partitioning.
>>
>>
>> TAG review
>>
>> https://github.com/w3ctag/design-reviews/issues/906
>>
>>
>> Compatibility
>>
>> The Storage Access API is already implemented in Safari, Firefox, and
>> Chrome , but
>> the proposed API shape would not change existing behavior without new
>> arguments added.
>>
>>
>> Interoperability
>>
>> Gecko: No Position Yet
>> htt