date:20240313

Awesome! LGTM1.

On Thu, Mar 14, 2024 at 1:35 PM 'Stephanie Zhang' via blink-dev <
blink-dev@chromium.org> wrote:

> Thanks for clarifying! Updated the Chrome Status' "Finch Feature Name"
> field to kWritingSuggestions and removed the "Non-finch justification"
> field.
>
> On Wednesday, March 13, 2024 at 9:20:57 PM UTC-7 Domenic Denicola wrote:
>
>> On Thu, Mar 14, 2024 at 12:54 PM 'Stephanie Zhang' via blink-dev <
>> blin...@chromium.org> wrote:
>>
>>> We do have a runtime feature flag 'WritingSuggestions
>>> '.
>>> We didn't think a Finch Trial was necessary, as the bulk of the changes were
>>> just adding the attribute and IDL functions
>>> .
>>> Since everything is implemented on the blink side, is a Finch feature flag
>>> still necessary? If it is, then I'll add that flag :)
>>
>>
>> A runtime feature flag automatically generates
>> 
>> a Finch flag, unless you turn that off :). So I think this is just a matter
>> of updating the Chrome Status entry.
>>
>>
>>>
>>> On Wednesday, March 13, 2024 at 6:55:48 PM UTC-7 Domenic Denicola wrote:
>>>

 On Thursday, March 14, 2024 at 2:08:28 AM UTC+9 Stephanie Zhang wrote:

 *Contact emails*
 *sa...@microsoft.com*, *dan...@microsoft.com*,
 *stephanie.zh...@microsoft.com*

 *Explainer*

 *https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/WritingSuggestions/explainer.md*

 *Specification*

 *https://html.spec.whatwg.org/multipage/interaction.html#writing-suggestions*

 *Summary*
 UAs are starting to provide writing suggestions to users as they type
 on various editable fields across the web. While this is generally useful
 for users, there are cases when developers may want to turn off UA-provided
 writing assistance, such as extensions or sites that wish to provide
 similar functionality on their own. To that end, developers need a solution
 that would turn on/off UA-provided writing assistance. The new attribute
 'writingsuggestions' has values 'true'/'false' that would allow developers
 to turn on/off browser-provided writing suggestions. The attribute's state
 for an element can also be inherited from ancestor elements, thereby
 allowing developers to control this functionality at a per-element or
 per-document/sub-document scale.

 *Blink component*
 *Blink>Editing*

 *TAG review*
 *https://github.com/w3ctag/design-reviews/issues/924*

 *TAG review status*
 Issues addressed

 *Risks*

 *Interoperability and Compatibility*
 None

 *Gecko*: No signal (
 *https://github.com/mozilla/standards-positions/issues/855*
 )

 *WebKit*: In development (
 *https://github.com/WebKit/standards-positions/issues/308*
 ) WebKit
 Implementation PR: *https://github.com/WebKit/WebKit/pull/24051*

 *Web developers*: No signals

 *Other signals*:

 *Ergonomics*
 None

 *Activation*
 None

 *Security*
 None

 *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, ChromeOS, Android, and Android WebView)?*
 Yes
 Attribute is available on all platforms.

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

 *?*
 Yes

 *https://wpt.fyi/results/html/editing/editing-0/writing-suggestions/writingsuggestions.html?label=master&label=experimental&aligned*

 *Flag name on chrome://flags*
 None

 *Finch feature name*
 None

 Per the flag guidelines

Re: [blink-dev] Re: Intent to Ship: 'writingsuggestions' attribute

2024-03-13 Thread 'Stephanie Zhang' via blink-dev

Thanks for clarifying! Updated the Chrome Status' "Finch Feature Name" 
field to kWritingSuggestions and removed the "Non-finch justification" 
field. 

On Wednesday, March 13, 2024 at 9:20:57 PM UTC-7 Domenic Denicola wrote:

> On Thu, Mar 14, 2024 at 12:54 PM 'Stephanie Zhang' via blink-dev <
> blin...@chromium.org> wrote:
>
>> We do have a runtime feature flag 'WritingSuggestions 
>> '.
>>  
>> We didn't think a Finch Trial was necessary, as the bulk of the changes were 
>> just adding the attribute and IDL functions 
>> . 
>> Since everything is implemented on the blink side, is a Finch feature flag 
>> still necessary? If it is, then I'll add that flag :)
>
>
> A runtime feature flag automatically generates 
> 
>  
> a Finch flag, unless you turn that off :). So I think this is just a matter 
> of updating the Chrome Status entry.
>  
>
>>
>> On Wednesday, March 13, 2024 at 6:55:48 PM UTC-7 Domenic Denicola wrote:
>>
>>>
>>>
>>> On Thursday, March 14, 2024 at 2:08:28 AM UTC+9 Stephanie Zhang wrote:
>>>
>>> *Contact emails*
>>> *sa...@microsoft.com*, *dan...@microsoft.com*, 
>>> *stephanie.zh...@microsoft.com*
>>>
>>> *Explainer*
>>>
>>> *https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/WritingSuggestions/explainer.md*
>>>  
>>> 
>>>
>>> *Specification*
>>>
>>> *https://html.spec.whatwg.org/multipage/interaction.html#writing-suggestions*
>>>  
>>> 
>>>
>>> *Summary*
>>> UAs are starting to provide writing suggestions to users as they type on 
>>> various editable fields across the web. While this is generally useful for 
>>> users, there are cases when developers may want to turn off UA-provided 
>>> writing assistance, such as extensions or sites that wish to provide 
>>> similar functionality on their own. To that end, developers need a solution 
>>> that would turn on/off UA-provided writing assistance. The new attribute 
>>> 'writingsuggestions' has values 'true'/'false' that would allow developers 
>>> to turn on/off browser-provided writing suggestions. The attribute's state 
>>> for an element can also be inherited from ancestor elements, thereby 
>>> allowing developers to control this functionality at a per-element or 
>>> per-document/sub-document scale.
>>>
>>>
>>> *Blink component*
>>> *Blink>Editing* 
>>> 
>>>
>>> *TAG review*
>>> *https://github.com/w3ctag/design-reviews/issues/924* 
>>> 
>>>
>>> *TAG review status*
>>> Issues addressed
>>>
>>> *Risks*
>>>
>>>
>>> *Interoperability and Compatibility*
>>> None
>>>
>>>
>>> *Gecko*: No signal (
>>> *https://github.com/mozilla/standards-positions/issues/855* 
>>> )
>>>
>>> *WebKit*: In development (
>>> *https://github.com/WebKit/standards-positions/issues/308* 
>>> ) WebKit 
>>> Implementation PR: *https://github.com/WebKit/WebKit/pull/24051* 
>>> 
>>>
>>> *Web developers*: No signals
>>>
>>> *Other signals*:
>>>
>>> *Ergonomics*
>>> None
>>>
>>>
>>> *Activation*
>>> None
>>>
>>>
>>> *Security*
>>> None
>>>
>>>
>>> *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, ChromeOS, Android, and Android WebView)?*
>>> Yes
>>> Attribute is available on all platforms.
>>>
>>>
>>> *Is this feature fully tested by* *web-platform-tests* 
>>> 
>>> *?*
>>> Yes
>>>
>>> *https://wpt.fyi/results/html/editing/editing-0/writing-suggestions/writingsuggestions.html?label=master&label=experimental&aligned*
>>>  
>>> 
>>>
>>>
>>> *Flag name on chrome://flags*
>>> None
>>>
>>> *Finch feature name*
>>> None
>>>
>>>
>>> Per the flag guidelines 
>>> ,
>>>  
>>> all new features are required to be placed behind a Finch feature flag 
>>> (i.e. base::Feature flag). Ca

Re: [blink-dev] Re: Intent to Ship: 'writingsuggestions' attribute

On Thu, Mar 14, 2024 at 12:54 PM 'Stephanie Zhang' via blink-dev <
blink-dev@chromium.org> wrote:

> We do have a runtime feature flag 'WritingSuggestions
> '.
> We didn't think a Finch Trial was necessary, as the bulk of the changes were
> just adding the attribute and IDL functions
> .
> Since everything is implemented on the blink side, is a Finch feature flag
> still necessary? If it is, then I'll add that flag :)


A runtime feature flag automatically generates

a Finch flag, unless you turn that off :). So I think this is just a matter
of updating the Chrome Status entry.


>
> On Wednesday, March 13, 2024 at 6:55:48 PM UTC-7 Domenic Denicola wrote:
>
>>
>>
>> On Thursday, March 14, 2024 at 2:08:28 AM UTC+9 Stephanie Zhang wrote:
>>
>> *Contact emails*
>> *sa...@microsoft.com*, *dan...@microsoft.com*,
>> *stephanie.zh...@microsoft.com*
>>
>> *Explainer*
>>
>> *https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/WritingSuggestions/explainer.md*
>> 
>>
>> *Specification*
>>
>> *https://html.spec.whatwg.org/multipage/interaction.html#writing-suggestions*
>> 
>>
>> *Summary*
>> UAs are starting to provide writing suggestions to users as they type on
>> various editable fields across the web. While this is generally useful for
>> users, there are cases when developers may want to turn off UA-provided
>> writing assistance, such as extensions or sites that wish to provide
>> similar functionality on their own. To that end, developers need a solution
>> that would turn on/off UA-provided writing assistance. The new attribute
>> 'writingsuggestions' has values 'true'/'false' that would allow developers
>> to turn on/off browser-provided writing suggestions. The attribute's state
>> for an element can also be inherited from ancestor elements, thereby
>> allowing developers to control this functionality at a per-element or
>> per-document/sub-document scale.
>>
>>
>> *Blink component*
>> *Blink>Editing*
>> 
>>
>> *TAG review*
>> *https://github.com/w3ctag/design-reviews/issues/924*
>> 
>>
>> *TAG review status*
>> Issues addressed
>>
>> *Risks*
>>
>>
>> *Interoperability and Compatibility*
>> None
>>
>>
>> *Gecko*: No signal (
>> *https://github.com/mozilla/standards-positions/issues/855*
>> )
>>
>> *WebKit*: In development (
>> *https://github.com/WebKit/standards-positions/issues/308*
>> ) WebKit
>> Implementation PR: *https://github.com/WebKit/WebKit/pull/24051*
>> 
>>
>> *Web developers*: No signals
>>
>> *Other signals*:
>>
>> *Ergonomics*
>> None
>>
>>
>> *Activation*
>> None
>>
>>
>> *Security*
>> None
>>
>>
>> *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, ChromeOS, Android, and Android WebView)?*
>> Yes
>> Attribute is available on all platforms.
>>
>>
>> *Is this feature fully tested by* *web-platform-tests*
>> 
>> *?*
>> Yes
>>
>> *https://wpt.fyi/results/html/editing/editing-0/writing-suggestions/writingsuggestions.html?label=master&label=experimental&aligned*
>> 
>>
>>
>> *Flag name on chrome://flags*
>> None
>>
>> *Finch feature name*
>> None
>>
>>
>> Per the flag guidelines
>> ,
>> all new features are required to be placed behind a Finch feature flag
>> (i.e. base::Feature flag). Can you ensure this is done and update the
>> Chrome Status entry?
>>
>>
>>
>> *Non-finch justification*
>> No finch trial needed.
>>
>>
>> *Requires code in //chrome?*
>> False
>>
>> *Estimated milestones*
>> Shipping on desktop 124
>>
>> Shipping on Android 124
>>
>> Shipping on WebView 124
>>
>>
>>
>> *Anticipated spec changes*
>> *Open questions about a feature may be a source of future web compat or
>> interop issues. Ple

[blink-dev] Re: Intent to Ship: 'writingsuggestions' attribute

2024-03-13 Thread 'Stephanie Zhang' via blink-dev

We do have a runtime feature flag 'WritingSuggestions 
'.
 
We didn't think a Finch Trial was necessary, as the bulk of the changes were 
just adding the attribute and IDL functions 
. Since 
everything is implemented on the blink side, is a Finch feature flag still 
necessary? If it is, then I'll add that flag :)

On Wednesday, March 13, 2024 at 6:55:48 PM UTC-7 Domenic Denicola wrote:

>
>
> On Thursday, March 14, 2024 at 2:08:28 AM UTC+9 Stephanie Zhang wrote:
>
> *Contact emails*
> *sa...@microsoft.com*, *dan...@microsoft.com*, 
> *stephanie.zh...@microsoft.com*
>
> *Explainer*
>
> *https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/WritingSuggestions/explainer.md*
>  
> 
>
> *Specification*
>
> *https://html.spec.whatwg.org/multipage/interaction.html#writing-suggestions* 
> 
>
> *Summary*
> UAs are starting to provide writing suggestions to users as they type on 
> various editable fields across the web. While this is generally useful for 
> users, there are cases when developers may want to turn off UA-provided 
> writing assistance, such as extensions or sites that wish to provide 
> similar functionality on their own. To that end, developers need a solution 
> that would turn on/off UA-provided writing assistance. The new attribute 
> 'writingsuggestions' has values 'true'/'false' that would allow developers 
> to turn on/off browser-provided writing suggestions. The attribute's state 
> for an element can also be inherited from ancestor elements, thereby 
> allowing developers to control this functionality at a per-element or 
> per-document/sub-document scale.
>
>
> *Blink component*
> *Blink>Editing* 
> 
>
> *TAG review*
> *https://github.com/w3ctag/design-reviews/issues/924* 
> 
>
> *TAG review status*
> Issues addressed
>
> *Risks*
>
>
> *Interoperability and Compatibility*
> None
>
>
> *Gecko*: No signal (
> *https://github.com/mozilla/standards-positions/issues/855* 
> )
>
> *WebKit*: In development (
> *https://github.com/WebKit/standards-positions/issues/308* 
> ) WebKit 
> Implementation PR: *https://github.com/WebKit/WebKit/pull/24051* 
> 
>
> *Web developers*: No signals
>
> *Other signals*:
>
> *Ergonomics*
> None
>
>
> *Activation*
> None
>
>
> *Security*
> None
>
>
> *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, ChromeOS, Android, and Android WebView)?*
> Yes
> Attribute is available on all platforms.
>
>
> *Is this feature fully tested by* *web-platform-tests* 
> 
> *?*
> Yes
>
> *https://wpt.fyi/results/html/editing/editing-0/writing-suggestions/writingsuggestions.html?label=master&label=experimental&aligned*
>  
> 
>
>
> *Flag name on chrome://flags*
> None
>
> *Finch feature name*
> None
>
>
> Per the flag guidelines 
> ,
>  
> all new features are required to be placed behind a Finch feature flag 
> (i.e. base::Feature flag). Can you ensure this is done and update the 
> Chrome Status entry?
>  
>
>
> *Non-finch justification*
> No finch trial needed.
>
>
> *Requires code in //chrome?*
> False
>
> *Estimated milestones*
> Shipping on desktop 124 
>  
> Shipping on Android 124 
>  
> Shipping on WebView 124 
>  
>
>
> *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/5153375153029120* 
> 
>
> *Links to previous Intent discussions*
> Intent to prototype: 
> *https://groups.google.com/a/chromium.org/g/blink-dev/c

[blink-dev] Re: Intent to Ship: 'writingsuggestions' attribute



On Thursday, March 14, 2024 at 2:08:28 AM UTC+9 Stephanie Zhang wrote:

*Contact emails*
*sa...@microsoft.com* , *dan...@microsoft.com* 
, *stephanie.zh...@microsoft.com* 


*Explainer*
*https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/WritingSuggestions/explainer.md*
 


*Specification*
*https://html.spec.whatwg.org/multipage/interaction.html#writing-suggestions* 


*Summary*
UAs are starting to provide writing suggestions to users as they type on 
various editable fields across the web. While this is generally useful for 
users, there are cases when developers may want to turn off UA-provided 
writing assistance, such as extensions or sites that wish to provide 
similar functionality on their own. To that end, developers need a solution 
that would turn on/off UA-provided writing assistance. The new attribute 
'writingsuggestions' has values 'true'/'false' that would allow developers 
to turn on/off browser-provided writing suggestions. The attribute's state 
for an element can also be inherited from ancestor elements, thereby 
allowing developers to control this functionality at a per-element or 
per-document/sub-document scale.


*Blink component*
*Blink>Editing* 


*TAG review*
*https://github.com/w3ctag/design-reviews/issues/924* 


*TAG review status*
Issues addressed

*Risks*


*Interoperability and Compatibility*
None


*Gecko*: No signal (
*https://github.com/mozilla/standards-positions/issues/855* 
)

*WebKit*: In development (
*https://github.com/WebKit/standards-positions/issues/308* 
) WebKit 
Implementation PR: *https://github.com/WebKit/WebKit/pull/24051* 


*Web developers*: No signals

*Other signals*:

*Ergonomics*
None


*Activation*
None


*Security*
None


*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, ChromeOS, Android, and Android WebView)?*
Yes
Attribute is available on all platforms.


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

*?*
Yes
*https://wpt.fyi/results/html/editing/editing-0/writing-suggestions/writingsuggestions.html?label=master&label=experimental&aligned*
 



*Flag name on chrome://flags*
None

*Finch feature name*
None


Per the flag guidelines 
,
 
all new features are required to be placed behind a Finch feature flag 
(i.e. base::Feature flag). Can you ensure this is done and update the 
Chrome Status entry?
 


*Non-finch justification*
No finch trial needed.


*Requires code in //chrome?*
False

*Estimated milestones*
Shipping on desktop 124 
 
Shipping on Android 124 
 
Shipping on WebView 124 
 


*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/5153375153029120* 


*Links to previous Intent discussions*
Intent to prototype: 
*https://groups.google.com/a/chromium.org/g/blink-dev/c/rHyRCx-hJhE* 

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/c5c0ac22-10ec-41e3-8588-c6cc8fa82d14n%40chromium.org.

Re: [blink-dev] Intent to Ship: Document picture-in-picture: add option to hide back-to-tab button

I found an issue with the API design here that might result in a
backward-incompatible change:
https://github.com/WICG/document-picture-in-picture/issues/115

With my spec mentor hat on, sorry for not catching it sooner!

On Thu, Mar 14, 2024 at 2:12 AM 'Tommy Steimel' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emailsstei...@chromium.org, liber...@chromium.org
>
> ExplainerNone
>
> Specificationhttps://github.com/WICG/document-picture-in-picture/pull/114
>
> Summary
>
> This adds a new parameter ("allowReturnToOpener") to the document
> picture-in-picture API that, when set to false, hints to the user agent
> that they should not show a button in the picture-in-picture window that
> allows the user to return to the opener. While having a button to return
> content to the opener always makes sense in the video picture-in-picture
> case (the video stream can be returned to the video element in the opener
> tab), this is not always the case for document picture-in-picture
> experiences. This gives developers more control over the user experience
> when they determine that such a button does not make sense for their use
> case.
>
>
> Blink componentBlink>Media>PictureInPicture
> 
>
> TAG review
> https://github.com/w3ctag/design-reviews/issues/798#issuecomment-1967916721
>
> TAG review statusPending
>
> Risks
>
>
> Interoperability and Compatibility
>
> None
>
>
> *Gecko*: No signal (
> https://github.com/mozilla/standards-positions/issues/670#issuecomment-1967919675)
> Added comment to existing standards position issue for document
> picture-in-picture. No response yet
>
> *WebKit*: No signal (
> https://github.com/WebKit/standards-positions/issues/41#issuecomment-1967918830)
> Added comment to existing standards position issue for document
> picture-in-picture. No response yet
>
> *Web developers*: Positive (
> https://github.com/WICG/document-picture-in-picture/issues/113) We have
> received feature requests for the ability to hide the "back to tab" button
> from the document picture-in-picture window.
>
> *Other signals*:
>
> Ergonomics
>
> N/A
>
>
> Activation
>
> N/A
>
>
> Security
>
> N/A
>
>
> 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?
>
> N/A, as this is not available on Android
>
>
> Debuggability
>
> N/A
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, ChromeOS, Android, and Android WebView)?No
>
> The document picture-in-picture API is not supported on Android
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?No
>
> The document picture-in-picture feature itself is fully tested on WPT, but
> this additional parameter isn't since it's a hint to the user agent and
> therefore any actual changes happen in the embedder
>
>
> Flag name on chrome://flagsNone
>
> Finch feature nameNone
>
> Non-finch justification
>
> Small change to existing API
>
>
> Requires code in //chrome?False
>
> Sample links
> https://steimelchrome.github.io/document-pip/hide-back-to-tab-button.html
>
> Estimated milestones
> Shipping on desktop 124
>
> 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).
> N/A
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/6223347936657408
>
> 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/CAE-AwAqR%2BNBOJT4h9YRkdOB9ksbPYgFCfP5JvmTKuCbFA-4-cQ%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/CAM0wra90nqW-pq0SKbbTa3iijYpHC%3D7jJ2a%3DJewyBKUU4iQAQg%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Sec-CH-UA-Form-Factor client hint

2024-03-13 Thread 'Dustin Mitchell' via blink-dev

Thanks all -- the pluralization has now landed both in the draft-spec repo
and in the Chromium source, and will be in place for M124.

Especially thanks to Domenic - that was a good observation, and consistency
in the web platform is definitely worth a little trouble to rename things.

Dustin

On Wed, Mar 6, 2024 at 11:37 AM Alex Russell 
wrote:

> LGTM3, contingent on the rename Domenic is requesting.
>
> On Wednesday, February 28, 2024 at 6:48:14 PM UTC-8 Mike Taylor wrote:
>
>> (non-owner hat on) - Thanks for flagging, Domenic. We'll re-ping the
>> thread once we decide if we should rename it, and to what.
>> On 2/28/24 9:43 PM, Domenic Denicola wrote:
>>
>> I've raised a potentially-breaking spec issue which I'd like to get a
>> conclusion on before LGTMing this:
>> https://github.com/WICG/ua-client-hints/issues/355
>>
>> On Thursday, February 29, 2024 at 2:03:07 AM UTC+9 Yoav Weiss wrote:
>>
>>> LGTM2
>>>
>>> On Wed, Feb 21, 2024 at 6:04 PM Vladimir Levin 
>>> wrote:
>>>


 On Wed, Feb 21, 2024 at 11:25 AM Dustin Mitchell 
 wrote:

> Thanks for the comments!
>
> On Tue, Feb 20, 2024 at 11:10 AM Vladimir Levin 
> wrote:
>
>>
>>
>> On Tue, Feb 20, 2024 at 7:06 AM 'Dustin Mitchell' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> Contact emails djmit...@chromium.org
>>>
>>> Explainer
>>> https://github.com/djmitche/web-explainers/blob/main/sec-ch-ua-form-factor.md
>>>
>>> Specification
>>> https://wicg.github.io/ua-client-hints/#sec-ch-ua-form-factor
>>>
>>> Design docs
>>>
>>> https://github.com/djmitche/web-explainers/blob/main/sec-ch-ua-form-factor.md
>>>
>>> Summary
>>>
>>> This hint indicates the "form-factor" of the user-agent / device, so
>>> that the site can tailor its response.
>>>
>>>
>>> Blink component Blink>Network
>>> 
>>>
>>> Search tags ua-ch ,
>>> uach , form-factor
>>> 
>>>
>>> TAG review This feature simply adds a new hint to the existing set
>>> of hints, containing data that was previously represented in the 
>>> user-agent
>>> string.
>>>
>>
>> Although this info may be available, I suspect this can be a new
>> channel of information for clients that override the user-agent string or
>> where this information isn't provided in the user-agent string. I don't
>> believe this to be a problem, but just something to consider
>>
>
> That's a good point, and likely needs to be considered for all client
> hints. Do you think it's worth adding an issue in
> https://github.com/WICG/ua-client-hints to track this?
>

 I don't feel particularly strongly about this, but raising the issue to
 invite more opinions seems worthwhile.


>
>>
>>>
>>>
>>> TAG review status Not applicable
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> If other browsers do not implement this hint, then the information
>>> will only be available in Chrome, and other browsers will implicitly 
>>> return
>>> an empty value.
>>>
>>>
>>> *Gecko*: No signal
>>>
>>> *WebKit*: No signal
>>>
>>
>> Can you please file requests for positions for both Gecko and WebKit?
>>
>
> Gecko: https://mozilla.github.io/standards-positions/#ua-client-hints
> Webkit:
> https://lists.webkit.org/pipermail/webkit-dev/2024-February/032618.html
>

 Thank you for doing this. For posterity in the future, for WebKit, it
 might be better to file an issue here:
 https://github.com/WebKit/standards-positions/issues


>
>
>>
>>
>>> *Web developers*: No signals
>>>
>>> *Other signals*:
>>>
>>> Ergonomics
>>>
>>> None - this fits with existing, similar client hints.
>>>
>>>
>>> Activation
>>>
>>> No activation risks - developers will always need to handle the
>>> situation where this hint is unavailable.
>>>
>>>
>>> Security
>>>
>>> None
>>>
>>>
>>> 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 change to existing behavior; this adds a new hint which sites
>>> must opt in to. Killswitch is available: ClientHintsFormFactor
>>>
>>>
>>> Debuggability
>>>
>>> No changes in the checklist apply.
>>>
>>>
>>> Will this feature be supported on all six Blink platforms (Windows,
>>> Mac, Linux, ChromeOS, Android, and Android WebView)? Yes

Re: [blink-dev] Intent to Ship: Adding Cross-site Ancestor Chain Bit to CHIPS Partition Key

2024-03-13 Thread 'Aaron Selya' via blink-dev

The flag is a base::features flag named
kAncestorChainBitEnabledInPartitionedCookies.

Updated the review gates on chromestatus.com

On Wed, Mar 13, 2024 at 11:25 AM Yoav Weiss (@Shopify) <
yoavwe...@chromium.org> wrote:

> Also, can you flip on the relevant review gates in chromestatus.com?
>
> On Wed, Mar 13, 2024 at 11:24 AM Yoav Weiss (@Shopify) <
> yoavwe...@chromium.org> wrote:
>
>>
>>
>> On Tue, Mar 12, 2024 at 4:46 PM 'Aaron Selya' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> The first mitigation listed here is to migrate existing
 partitioned cookies to include the new bit, and the second mitigation is to
 have a flag that can disable this feature. Would disabling the feature also
 include migrating the existing cookies back to exclude the new bit?

>>>
>>> Disabling the flag would not migrate the existing cookies back to
>>> exclude the new bit. It would make it so that the new bit value is not
>>> considered when checking equivalence. Not considering the value of the bit
>>> when is the current behavior so we anticipate no issues ignoring the bit if
>>> the flag needs to disable the feature.
>>>
>>
>> Can you clarify what kind of flag are we talking about? Is this a Finch
>> flag we expect to turn off if we encounter lots of breakage? An enterprise
>> policy flag? A flag we expect users to use? (I doubt it's the latter, but
>> clarifications would help :D)
>>
>>
>>>
>>>
 And somewhat related, but does the format of the cookie request
 developers make have to change too, or is this bit determination purely
 done within the browser?

>>>
>>> In almost all cases this is set within the browser. The only
>>> circumstance I've run into where the value could be set by a developer is
>>> with the chrome.cookies.set api for extensions.  This API allows the
>>> developer to set the site associated with the cookie partition key and with
>>> this change would allow for the bit value to be set as well.
>>>
>>> On Tue, Mar 12, 2024 at 2:53 PM Vladimir Levin 
>>> wrote:
>>>


 On Mon, Mar 11, 2024 at 1:42 PM Aaron Selya  wrote:

> Contact emails
>
> se...@chromium.org, dylancut...@chromium.org, kaustub...@chromium.org
>
>
> Explainer
>
> Keying of "CHIPS" cookies should align with other state:
> 
>
>
> Specification
>
> Add cross-site ancestor chain bit to spec:
> https://github.com/explainers-by-googlers/CHIPS-spec/pull/13
>
>
>
> Summary
>
> We are looking to align the partition key
> 
> in CHIPS (Cookies Having Independent Partitioned State, aka partitioned
> cookies) with the existing implementation of StorageKey.
>
>
> The only sites that would experience different behavior, would be when
> a top-level site “A” embeds an iframe to a cross-site document on site 
> “B”,
> and then the iframe B embeds an iframe that loads a document from site “A”
> (shorthand: A1->B->A2). Previously, partitioned cookies sent or received 
> in
> the inner iframe A2 would be the same partitioned cookies sent or received
> in the outer frame A1. This is no longer true.
>
>
> This change is privacy neutral, but will have improved security
> characteristics, because it prevents cross-site iframes from embedding
> arbitrary endpoints of the top-level site with credentials, without first
> being granted permission to do so through the Storage Access API (SAA) or
> Cross-Origin Resource Sharing (CORS).
>
>
>
> The impact of this change is expected to be small as our metrics
> indicate that only 0.2% of CHIPS (partitioned cookies) set by the first
> party are currently being used in A1->B->A2 contexts. This constitutes
> 0.032% of all page loads (calculated using the usage of
> PartitionedCookie
> ).
> For websites that do need access to the same cookies across A1 and A2 (in
> the A1->B->A2 configuration), we recommend using SameSite=None cookies
> *without* the Partitioned attribute, and invoking the Storage Access API
> (SAA) or using the Cross-Origin Resource Sharing (CORS).
>
>
>
> Blink component
>
> Internals>Network>Cookies>PartitionedCookies
> 
>
>
>
>
> TAG review
>
> Not requested, as this does not differ in any significant way from the
> ori

[blink-dev] Intent to Ship: Document picture-in-picture: add option to hide back-to-tab button

2024-03-13 Thread 'Tommy Steimel' via blink-dev

Contact emailsstei...@chromium.org, liber...@chromium.org

ExplainerNone

Specificationhttps://github.com/WICG/document-picture-in-picture/pull/114

Summary

This adds a new parameter ("allowReturnToOpener") to the document
picture-in-picture API that, when set to false, hints to the user agent
that they should not show a button in the picture-in-picture window that
allows the user to return to the opener. While having a button to return
content to the opener always makes sense in the video picture-in-picture
case (the video stream can be returned to the video element in the opener
tab), this is not always the case for document picture-in-picture
experiences. This gives developers more control over the user experience
when they determine that such a button does not make sense for their use
case.


Blink componentBlink>Media>PictureInPicture


TAG review
https://github.com/w3ctag/design-reviews/issues/798#issuecomment-1967916721

TAG review statusPending

Risks


Interoperability and Compatibility

None


*Gecko*: No signal (
https://github.com/mozilla/standards-positions/issues/670#issuecomment-1967919675)
Added comment to existing standards position issue for document
picture-in-picture. No response yet

*WebKit*: No signal (
https://github.com/WebKit/standards-positions/issues/41#issuecomment-1967918830)
Added comment to existing standards position issue for document
picture-in-picture. No response yet

*Web developers*: Positive (
https://github.com/WICG/document-picture-in-picture/issues/113) We have
received feature requests for the ability to hide the "back to tab" button
from the document picture-in-picture window.

*Other signals*:

Ergonomics

N/A


Activation

N/A


Security

N/A


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?

N/A, as this is not available on Android


Debuggability

N/A


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

The document picture-in-picture API is not supported on Android


Is this feature fully tested by web-platform-tests

?No

The document picture-in-picture feature itself is fully tested on WPT, but
this additional parameter isn't since it's a hint to the user agent and
therefore any actual changes happen in the embedder


Flag name on chrome://flagsNone

Finch feature nameNone

Non-finch justification

Small change to existing API


Requires code in //chrome?False

Sample links
https://steimelchrome.github.io/document-pip/hide-back-to-tab-button.html

Estimated milestones
Shipping on desktop 124

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).
N/A

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

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/CAE-AwAqR%2BNBOJT4h9YRkdOB9ksbPYgFCfP5JvmTKuCbFA-4-cQ%40mail.gmail.com.

[blink-dev] Intent to Ship: 'writingsuggestions' attribute

2024-03-13 Thread 'Stephanie Zhang' via blink-dev

Contact emails
sa...@microsoft.com, 
dan...@microsoft.com, 
stephanie.zh...@microsoft.com


Explainer
https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/WritingSuggestions/explainer.md


Specification
https://html.spec.whatwg.org/multipage/interaction.html#writing-suggestions


Summary
UAs are starting to provide writing suggestions to users as they type on 
various editable fields across the web. While this is generally useful for 
users, there are cases when developers may want to turn off UA-provided writing 
assistance, such as extensions or sites that wish to provide similar 
functionality on their own. To that end, developers need a solution that would 
turn on/off UA-provided writing assistance. The new attribute 
'writingsuggestions' has values 'true'/'false' that would allow developers to 
turn on/off browser-provided writing suggestions. The attribute's state for an 
element can also be inherited from ancestor elements, thereby allowing 
developers to control this functionality at a per-element or 
per-document/sub-document scale.



Blink component
Blink>Editing


TAG review
https://github.com/w3ctag/design-reviews/issues/924


TAG review status
Issues addressed


Risks



Interoperability and Compatibility
None


Gecko: No signal (https://github.com/mozilla/standards-positions/issues/855)

WebKit: In development 
(https://github.com/WebKit/standards-positions/issues/308) WebKit 
Implementation PR: https://github.com/WebKit/WebKit/pull/24051

Web developers: No signals

Other signals:


Ergonomics
None



Activation
None



Security
None



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, 
ChromeOS, Android, and Android WebView)?
Yes
Attribute is available on all platforms.



Is this feature fully tested by 
web-platform-tests?
Yes
https://wpt.fyi/results/html/editing/editing-0/writing-suggestions/writingsuggestions.html?label=master&label=experimental&aligned



Flag name on chrome://flags
None


Finch feature name
None


Non-finch justification
No finch trial needed.



Requires code in //chrome?
False


Estimated milestones
Shipping on desktop 124

Shipping on Android 124

Shipping on WebView 124





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/5153375153029120


Links to previous Intent discussions
Intent to prototype: 
https://groups.google.com/a/chromium.org/g/blink-dev/c/rHyRCx-hJhE

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/PH0PR00MB1298288BAF340FA9676EFB91EC2A2%40PH0PR00MB1298.namprd00.prod.outlook.com.

Re: [blink-dev] Intent to Ship: WebGPU: ServiceWorker and SharedWorker support

2024-03-13 Thread Mike Taylor

LGTM2

On 3/13/24 12:40 PM, Corentin Wallez wrote:
Just to clarify, the ServiceWorker cannot do anything more than what
the main thread can do for DoS. Or I guess the only additional
capability is that it can trigger it up to 30 seconds after the user
left the page.

The reason why we can't prevent DoS in all cases is that most GPUs
don't have preemption so sending an infinite loop can make some of the
processing units stuck forever. Chromium has mechanisms to try to
detect this and assign the blame to a website that won't be allowed
GPU access in the future, and some OSes can restart a stuck GPU. But
this is all best effort (unfortunately, and already the case with
WebGL, or potentially DOM with crazy filters).

On Wednesday, March 13, 2024 at 3:28:42 PM UTC+1 Corentin Wallez wrote:

I don't know the ServiceWorker mechanisms too much, but if the
Javascript dies in 30 seconds then WebGPU operations will soon
after. There isn't a lot of use in keeping WebGPU computations
running for much longer as Javascript is needed to get the result
of any computation in any useful places (canvas, ArrayBuffer,
MediaStream, etc). Technically the ServiceWorker could send a much
longer running job to the GPU (think an infinite loop) but apart
from DDoS there wouldn't be any use to this.

You might also be interested in the privacy and security section
of the WebGPU spec.
On Wednesday, March 13, 2024 at 9:55:02 AM UTC+1 Daniel Bratell wrote:

Just to ask what is probably a FAQ to get it out here...

The Service Worker timeout is 30 seconds right, so regardless
of how heavy the calculations are, a service worker and its
associated calculations will die in 30 seconds after the user
closes the associated page?

I ask because while it's been possible to run heavy
calculations in various workers in the past, this explicitly
encourages it. It would be a bad situation if a user cannot
detect or stop a runaway WebGPU operation from a possibly
hostile site.

/Daniel

On 2024-03-13 08:06, 'François Beaufort' via blink-dev wrote:

On Tue, Mar 12, 2024 at 10:14 PM Yoav Weiss (@Shopify)
wrote:

LGTM1

On Tue, Mar 12, 2024, 15:10 'François Beaufort' via
blink-dev wrote:

On Tue, Mar 12, 2024 at 6:58 PM Mike Taylor
wrote:

On 3/11/24 4:06 PM, 'François Beaufort' via
blink-dev wrote:

Contact emails

fbea...@google.com

Explainer

None

Could you write a few sentences why this is a
useful addition?

Service Workers enable offline capabilities and
background processing for WebGPU. This means
graphics-intensive web applications or Chrome
Extensions can cache resources and perform
computations even when the user isn't actively
interacting with the page.
Shared Workers allow multiple tabs or extension
contexts to coordinate and share WebGPU resources.
This leads to smoother performance and more efficient
use of the user's graphics hardware.

Specification

https://gpuweb.github.io/gpuweb/#navigator-gpu

Summary

Functionality added to the WebGPU spec after its
first shipment in a browser. ServiceWorker and
SharedWorker support is added to WebGPU,
aligning with existing WebGL capabilities.

Blink component

Blink>WebGPU

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

ServiceWorker and SharedWorker support have not
yet been implemented in any browser, but have
been approved by the GPU for the Web Community
Group, with representatives from Chrome,
Firefox, and Safari. See minutes at

https://docs.google.com/document/d/15w7nsvqWwITA5yvCrsO3SEIEuZziXzj7YsrHN4Jd2uM/edit#heading=h.jbe7pg8ebd43

/Gecko/: No signal
(https://github.com/mozilla/standards-positions/issues/971)

Not officially a positive signal, but looking
positive based

Re: [blink-dev] Intent to Ship: WebGPU: ServiceWorker and SharedWorker support

2024-03-13 Thread 'Corentin Wallez' via blink-dev

Just to clarify, the ServiceWorker cannot do anything more than what the 
main thread can do for DoS. Or I guess the only additional capability is 
that it can trigger it up to 30 seconds after the user left the page.

The reason why we can't prevent DoS in all cases is that most GPUs don't 
have preemption so sending an infinite loop can make some of the processing 
units stuck forever. Chromium has mechanisms to try to detect this and 
assign the blame to a website that won't be allowed GPU access in the 
future, and some OSes can restart a stuck GPU. But this is all best effort 
(unfortunately, and already the case with WebGL, or potentially DOM with 
crazy filters).
On Wednesday, March 13, 2024 at 3:28:42 PM UTC+1 Corentin Wallez wrote:

> I don't know the ServiceWorker mechanisms too much, but if the Javascript 
> dies in 30 seconds then WebGPU operations will soon after. There isn't a 
> lot of use in keeping WebGPU computations running for much longer as 
> Javascript is needed to get the result of any computation in any useful 
> places (canvas, ArrayBuffer, MediaStream, etc). Technically the 
> ServiceWorker could send a much longer running job to the GPU (think an 
> infinite loop) but apart from DDoS there wouldn't be any use to this.
>
> You might also be interested in the privacy and security section 
>  of the WebGPU spec.
> On Wednesday, March 13, 2024 at 9:55:02 AM UTC+1 Daniel Bratell wrote:
>
>> Just to ask what is probably a FAQ to get it out here...
>>
>> The Service Worker timeout is 30 seconds right, so regardless of how 
>> heavy the calculations are, a service worker and its associated 
>> calculations will die in 30 seconds after the user closes the associated 
>> page?
>>
>> I ask because while it's been possible to run heavy calculations in 
>> various workers in the past, this explicitly encourages it. It would be a 
>> bad situation if a user cannot detect or stop a runaway WebGPU operation 
>> from a possibly hostile site.
>>
>> /Daniel
>> On 2024-03-13 08:06, 'François Beaufort' via blink-dev wrote:
>>
>>
>>
>> On Tue, Mar 12, 2024 at 10:14 PM Yoav Weiss (@Shopify) <
>> yoav...@chromium.org> wrote:
>>
>>> LGTM1
>>>
>>> On Tue, Mar 12, 2024, 15:10 'François Beaufort' via blink-dev <
>>> blin...@chromium.org> wrote:
>>>


 On Tue, Mar 12, 2024 at 6:58 PM Mike Taylor  
 wrote:

> On 3/11/24 4:06 PM, 'François Beaufort' via blink-dev wrote:
>
> Contact emails fbea...@google.com
>
> Explainer None
>
> Could you write a few sentences why this is a useful addition?
>
  
 Service Workers enable offline capabilities and background processing 
 for WebGPU. This means graphics-intensive web applications or Chrome 
 Extensions can cache resources and perform computations even when the user 
 isn't actively interacting with the page.
 Shared Workers allow multiple tabs or extension contexts to coordinate 
 and share WebGPU resources. This leads to smoother performance and more 
 efficient use of the user's graphics hardware.

>
> Specification https://gpuweb.github.io/gpuweb/#navigator-gpu
>
> Summary 
>
> Functionality added to the WebGPU spec after its first shipment in a 
> browser. ServiceWorker and SharedWorker support is added to WebGPU, 
> aligning with existing WebGL capabilities. 
>
> Blink component Blink>WebGPU 
> 
>
> TAG review None
>
> TAG review status Not applicable
>
> Risks 
>
>
> Interoperability and Compatibility 
>
> ServiceWorker and SharedWorker support have not yet been implemented 
> in any browser, but have been approved by the GPU for the Web Community 
> Group, with representatives from Chrome, Firefox, and Safari. See minutes 
> at 
> https://docs.google.com/document/d/15w7nsvqWwITA5yvCrsO3SEIEuZziXzj7YsrHN4Jd2uM/edit#heading=h.jbe7pg8ebd43
>  
>
> *Gecko*: No signal (
> https://github.com/mozilla/standards-positions/issues/971)
>
> Not officially a positive signal, but looking positive based on the 
> comments.
>

 Indeed. 

>
> *WebKit*: No signal (
> https://github.com/WebKit/standards-positions/issues/294#issuecomment-1877411933
> )
>
> This is kind of an "N/A to positive", given it's WebGPU.
>

 Agree ;) 

>
> *Web developers*: Positive (
> https://github.com/gpuweb/gpuweb/issues/4197)
>
> *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 platform

Re: [blink-dev] Intent to Ship: Add JavaScript timer wake up alignment for unimportant cross-origin frames

One more question, is requestAnimationFrame affected at all or will that 
still work just as before?


/Daniel

On 2024-03-13 17:32, Daniel Bratell wrote:


This intent has ended up in a strange state in the chromestatus tool, 
missing various flags I would have expected. Is that because the 
intent predates some of the chromestatus updates or because it started 
as an origin trial? If so, maybe the simplest is to refile it, or can 
it be made to be a proper Intent to Ship with all the buttons and bullets?


Another few things though, and I hope I'm not repeating something 
already covered elsewhere.


First, I really like the idea of doing optimizations that have a 
measurable impact on user behaviour and probably also power usage and 
energy usage so I approve of this work. But then I have questions.


The text mentions that WebKit uses an alignment on 30 milliseconds 
intervals, but what is the intention for Chromium? Also 30 milliseconds?


If the idea is for it to be 30 milliseconds, that would be too sparse 
to allow 60 fps animations run on setTimeout. If so, is that 
intentional, and would that be acceptable?


I ask in particular, because "uninteresting iframe" is vaguely defined 
so I don't know how much content will be misclassified as "uninteresting".


In general, is the answer to my questions above covered by some 
specification we can point people to when they wonder why something 
behaves inexplicably?


/Daniel

On 2024-03-13 03:00, Domenic Denicola wrote:
Can you fill out the interoperability and compatibility risks section 
here? I don't think standards position requests are necessary, but 
saying how this behavior might break existing sites that assume 
Chromium's current behavior, and how this new behavior compares to 
WebKit and Gecko, would be helpful.


Also, can you request the 
privacy/security/enterprise/debuggability/testing gates on Chrome Status?


On Tue, Mar 12, 2024 at 10:12 PM Zheda Chen  wrote:

Okay I update the process stage in Chrome Platform Status, and
paste the newly-generated Intent above. Please take a look.

https://chromestatus.com/feature/5106220399853568

On Tuesday, March 12, 2024 at 8:57:59 PM UTC+8 Zheda Chen wrote:

*Intent to Ship: Add JavaScript timer wake up alignment for
unimportant cross-origin frames*

Contact emails
zheda...@intel.com, fdo...@chromium.org

Specification
https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html

Summary

Align wake ups of JavaScript timers for unimportant
cross-origin frames. Currently, DOM timers <32ms are all
opt-out from AlignWakeUps [1] due to performance concerns.
This is very conservative and actually some unimportant
frames are eligible to use JS timer alignment. WebKit uses
the policy to align DOM timer of non-interacted cross origin
frames to 30ms. This feature adds JavaScript timer wake up
alignment for unimportant frames on foreground pages.
Unimportant frames means they are cross origin, visible but
have non-large proportion of page’s visible area, and have no
user interaction. [1]
https://chromium-review.googlesource.com/c/chromium/src/+/4589092



Blink component
Blink>PerformanceAPIs>Timers



TAG review
None

TAG review status
Not applicable

Risks

Interoperability and Compatibility

None


/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

None



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

Is this feature fully tested by web-platform-tests

?
No

Flag name on chrome://flags
None

Finch feature name
ThrottleUnimportantFrameTimers

Requires code in //chrome?
False

Tracking bug
https://issues.chromium.org/issues/40942028

Estimated milestones

Shipping on desktop
123
DevTrial on desktop
121
Shipping on Android
123
DevTrial on Android
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)

Re: [blink-dev] Intent to Ship: Add JavaScript timer wake up alignment for unimportant cross-origin frames

This intent has ended up in a strange state in the chromestatus tool, 
missing various flags I would have expected. Is that because the intent 
predates some of the chromestatus updates or because it started as an 
origin trial? If so, maybe the simplest is to refile it, or can it be 
made to be a proper Intent to Ship with all the buttons and bullets?


Another few things though, and I hope I'm not repeating something 
already covered elsewhere.


First, I really like the idea of doing optimizations that have a 
measurable impact on user behaviour and probably also power usage and 
energy usage so I approve of this work. But then I have questions.


The text mentions that WebKit uses an alignment on 30 milliseconds 
intervals, but what is the intention for Chromium? Also 30 milliseconds?


If the idea is for it to be 30 milliseconds, that would be too sparse to 
allow 60 fps animations run on setTimeout. If so, is that intentional, 
and would that be acceptable?


I ask in particular, because "uninteresting iframe" is vaguely defined 
so I don't know how much content will be misclassified as "uninteresting".


In general, is the answer to my questions above covered by some 
specification we can point people to when they wonder why something 
behaves inexplicably?


/Daniel

On 2024-03-13 03:00, Domenic Denicola wrote:
Can you fill out the interoperability and compatibility risks section 
here? I don't think standards position requests are necessary, but 
saying how this behavior might break existing sites that assume 
Chromium's current behavior, and how this new behavior compares to 
WebKit and Gecko, would be helpful.


Also, can you request the 
privacy/security/enterprise/debuggability/testing gates on Chrome Status?


On Tue, Mar 12, 2024 at 10:12 PM Zheda Chen  wrote:

Okay I update the process stage in Chrome Platform Status, and
paste the newly-generated Intent above. Please take a look.

https://chromestatus.com/feature/5106220399853568

On Tuesday, March 12, 2024 at 8:57:59 PM UTC+8 Zheda Chen wrote:

*Intent to Ship: Add JavaScript timer wake up alignment for
unimportant cross-origin frames*

Contact emails
zheda...@intel.com, fdo...@chromium.org

Specification
https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html

Summary

Align wake ups of JavaScript timers for unimportant
cross-origin frames. Currently, DOM timers <32ms are all
opt-out from AlignWakeUps [1] due to performance concerns.
This is very conservative and actually some unimportant frames
are eligible to use JS timer alignment. WebKit uses the policy
to align DOM timer of non-interacted cross origin frames to
30ms. This feature adds JavaScript timer wake up alignment for
unimportant frames on foreground pages. Unimportant frames
means they are cross origin, visible but have non-large
proportion of page’s visible area, and have no user
interaction. [1]
https://chromium-review.googlesource.com/c/chromium/src/+/4589092



Blink component
Blink>PerformanceAPIs>Timers



TAG review
None

TAG review status
Not applicable

Risks

Interoperability and Compatibility

None


/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

None



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

Is this feature fully tested by web-platform-tests

?
No

Flag name on chrome://flags
None

Finch feature name
ThrottleUnimportantFrameTimers

Requires code in //chrome?
False

Tracking bug
https://issues.chromium.org/issues/40942028

Estimated milestones

Shipping on desktop
123
DevTrial on desktop
121
Shipping on Android
123
DevTrial on Android
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).

Re: [blink-dev] Intent to Ship: Protected Audience: Downsampled forDebugOnly & Increase number of component ads

2024-03-13 Thread Mike Taylor


LGTM2

On 3/13/24 11:45 AM, Yoav Weiss (@Shopify) wrote:

LGTM1

On Monday, March 11, 2024 at 4:21:36 PM UTC-4 Paul Jensen wrote:

On Wed, Mar 6, 2024 at 12:07 PM Yoav Weiss (@Shopify)
 wrote:



On Mon, Mar 4, 2024 at 7:00 PM Paul Jensen
 wrote:



On Wed, Feb 28, 2024 at 12:24 PM Yoav Weiss (@Shopify)
 wrote:



On Thu, Feb 22, 2024 at 6:07 PM 'Orr Bernstein' via
blink-dev  wrote:

Contact emails

pauljen...@chromium.org


Explainer

Downsampled forDebugOnly:
https://github.com/WICG/turtledove/pull/1020


Increase number of component ads:
https://github.com/WICG/turtledove/pull/1003



Specification

Downsampled forDebugOnly:
https://github.com/WICG/turtledove/pull/1023


Increase number of component ads:
https://github.com/WICG/turtledove/pull/1004



Summary

Downsampled forDebugOnly:

The forDebuggingOnly.reportAdAuctionWin() and
forDebuggingOnly.reportAdAuctionLoss() (fDO) APIs
were added to the Protected Audience (PA) API to
allow debugging from within bidding and scoring
scripts in PA auctions.  We originally intended to
remove these APIs at third-party cookie
deprecation (3PCD) time, but received feedback
that they were essential for doing root cause
analysis in escalation situations (i.e. critical
crash). Instead of removing debug reports
entirely, we now plan to heavily downsample them
at 3PCD time as follows: they will only send a
report with a 1/1000 probability. Furthermore, if
a report is sent, the browser will not send
another for 3 years (“lockout”), and if a report
is not sent (999/1000 of the time), future calls
to the fDO API from the calling origin will be
ignored for 2 weeks 90% of the time and 1 year 10%
of the time (“cooldown”).  To avoid biasing
towards new browser installs (which aren’t in
lockout or cooldown), we may place new browser
installs initially in a shorter lockout period.
For now, until 3PCD, we’ll expose whether a fDO
caller is in the “lockout” or “cooldown” periods.


Increase number of component ads:

Today, PA allows selection of ads containing 20
component ads (aka product level ads).  We plan to
increase this number from 20 to 40 as we received
feedback that ads with higher numbers of
components were critical (e.g. for ads that rotate
through 3 sets of 12 products).


Can you expand on the implications of increasing that
number? What's the tradeoff involved?


As discussed on github here
and in
person here

,
we've heard from adtechs that large portions of their ad
inventory cannot be displayed without allowing higher
numbers of component ads, so increasing this number
restores more publisher site revenue.  The downsides to
increasing this number are fairly minor:  There's a
negligible privacy impact as the component ads are not
shared with PA reporting scripts, are required to be
k-anonymous, and when displayed, each component ad can be
isolated from each other in separate Fenced Frames.


I understand the benefits of increasing the number of ads, but
are there any pointers to past discussion/analysis RE the
privacy impact? I understand it's not huge (and it's not my
role to judge the privacy risk - that's what the privacy
review is for). I'd just love to better understand this :D


WRT the privacy impact, as it's negligible, there isn't much to
dis

Re: [blink-dev] Intent to Ship: Private Aggregation debug mode for auctionReportBuyers reporting

2024-03-13 Thread Philip Jägenstedt

LGTM3

I agree with Alex that we have a bad track record of "temporary" APIs on
the web, but I'm comfortable with this given the particulars. A feature
which is only a dictionary member is detectable (through a getter) but you
have to do extra work and I don't recall ever seeing a problem from
removing a no-op dictionary member. Given this, going through OT is extra
work to reduce a risk that is already very low. In the very worst case we'd
be left with a no-op dictionary member that generates some bindings but
does nothing, so it's a small risk of a small problem.

On Mon, Mar 11, 2024 at 11:28 AM Yoav Weiss (@Shopify) <
yoavwe...@chromium.org> wrote:

>
>
> On Thu, Mar 7, 2024 at 5:03 PM Alex Turner  wrote:
>
>> Alex and Yoav,
>>
>> This particular addition is exposed only as an optional parameter on the
>> existing `AuctionAdConfig` dictionary passed to `navigator.runAdAuction()`.
>> So, I'm not aware of any web visibility from removing the new
>> `auctionReportBuyerDebugModeConfig` field (if it was already having no
>> effect). But please let me know if I'm missing something there.
>>
>> Are you referring instead to the existing
>> `privateAggregation.enableDebugMode()` function? I agree that removing that
>> would be web visible and have this risk. However, that function is already
>> fully launched (as part of the I2S here
>> )
>> and isn't affected by this change.
>>
>> As for why this shouldn't be an OT, alignment with the other way to
>> enable debug mode is a big reason. For other usages of Private Aggregation,
>> debug mode is enabled with a call to
>> `privateAggregation.enableDebugMode()`. This is tied to third-party cookie
>> eligibility in the same way (with the exception for Mode B).
>>
>
> That makes perfect sense! I think the benefits of tying this to an OT
> (better assurances that removal will be smooth) are outweighed by the
> friction it'd introduce for adoption, which is especially stark when
> considering the already shipped and much more visible enableDebugMode.
> My LGTM stands.
>
>
>> The other major reason is that we intend for this API to be available to
>> all callers in order to facilitate testing and adoption of the API, which
>> seems at odds with OTs being intended to be run only on a limited subset of
>> Chrome traffic. As this API is primarily used by third-parties on a page,
>> there is also a potential barrier in the need to edit the top-level page.
>>
>> Best,
>> Alex
>>
>> On Thu, Mar 7, 2024 at 4:26 AM Yoav Weiss (@Shopify) <
>> yoavwe...@chromium.org> wrote:
>>
>>> Alex T - can you expand on the other debug modes that are already
>>> shipped? Are they also tied to 3P cookie eligibility?
>>>
>>> If so, I agree that having all these mechanisms activated together and
>>> stop working together makes sense.
>>>
>>> On Wed, Mar 6, 2024 at 11:04 PM Alex Russell 
>>> wrote:
>>>
 Removal being guaranteed to be backwards compatible depends, at a
 minimum, on nullability. As this API would, instead, be globally exposed
 (but would not "work" when 3p cookie ineligible), addition and removal
 present the usual crop of addition and deprecation issues.

 3p cookie turndown is now into it's second or third year of delay, so
 optimism about the window for growth of use feels hard to justify.

 Why shouldn't this be an OT?

 Best,

 Alex

 On Wed, Mar 6, 2024, 1:54 PM Alex Turner  wrote:

> Hey Alex,
>
> Totally understand the concern given how difficult removing web APIs
> typically is. However, I think for this case removal should be much 
> simpler
> as the functionality (and debug mode more generally) is already tied to
> third-party cookie eligibility*. In other words, after third-party cookie
> deprecation is fully launched, this new feature will (automatically) have
> no effect. At that point, removing the new field from the IDL definitions
> should also be fully backwards compatible as it would simply be ignored.
>
> We leaned away from an OT given that other uses of Private
> Aggregation's debug mode do not require an OT token and we wanted to keep
> the workflow across debug mode consistent. Other considerations were the
> increased difficulty for usage of the API in third-party iframes and the
> large number of expected pages impacted (i.e. likely much higher than
> 0.5%). We're definitely willing to commit to formally removing this 
> feature
> shortly after third-party cookie deprecation is fully launched.
>
> I hope this addresses your concerns, but very happy to discuss further.
>
> (*I do want to acknowledge the exception for Mode B traffic softens
> this claim, but we have communicated the temporary nature of this 
> exception
> in the developer documentation
>

Re: [blink-dev] Intent to Ship: Protected Audience: Downsampled forDebugOnly & Increase number of component ads

LGTM1

On Monday, March 11, 2024 at 4:21:36 PM UTC-4 Paul Jensen wrote:

On Wed, Mar 6, 2024 at 12:07 PM Yoav Weiss (@Shopify) <
yoavwe...@chromium.org> wrote:



On Mon, Mar 4, 2024 at 7:00 PM Paul Jensen  wrote:



On Wed, Feb 28, 2024 at 12:24 PM Yoav Weiss (@Shopify) <
yoavwe...@chromium.org> wrote:



On Thu, Feb 22, 2024 at 6:07 PM 'Orr Bernstein' via blink-dev <
blink-dev@chromium.org> wrote:

Contact emails

pauljen...@chromium.org


Explainer

Downsampled forDebugOnly: https://github.com/WICG/turtledove/pull/1020

Increase number of component ads: https://github.com/WICG/
turtledove/pull/1003


Specification

Downsampled forDebugOnly: https://github.com/WICG/turtledove/pull/1023

Increase number of component ads: https://github.com/WICG/
turtledove/pull/1004


Summary

Downsampled forDebugOnly:

The forDebuggingOnly.reportAdAuctionWin() and 
forDebuggingOnly.reportAdAuctionLoss() 
(fDO) APIs were added to the Protected Audience (PA) API to allow debugging 
from within bidding and scoring scripts in PA auctions.  We originally 
intended to remove these APIs at third-party cookie deprecation (3PCD) 
time, but received feedback that they were essential for doing root cause 
analysis in escalation situations (i.e. critical crash).  Instead of 
removing debug reports entirely, we now plan to heavily downsample them at 
3PCD time as follows: they will only send a report with a 1/1000 
probability.  Furthermore, if a report is sent, the browser will not send 
another for 3 years (“lockout”), and if a report is not sent (999/1000 of 
the time), future calls to the fDO API from the calling origin will be 
ignored for 2 weeks 90% of the time and 1 year 10% of the time 
(“cooldown”).  To avoid biasing towards new browser installs (which aren’t 
in lockout or cooldown), we may place new browser installs initially in a 
shorter lockout period. For now, until 3PCD, we’ll expose whether a fDO 
caller is in the “lockout” or “cooldown” periods.

Increase number of component ads:

Today, PA allows selection of ads containing 20 component ads (aka product 
level ads).  We plan to increase this number from 20 to 40 as we received 
feedback that ads with higher numbers of components were critical (e.g. for 
ads that rotate through 3 sets of 12 products).


Can you expand on the implications of increasing that number? What's the 
tradeoff involved?


As discussed on github here  
and in person here 
,
 
we've heard from adtechs that large portions of their ad inventory cannot 
be displayed without allowing higher numbers of component ads, so 
increasing this number restores more publisher site revenue.  The downsides 
to increasing this number are fairly minor:  There's a negligible privacy 
impact as the component ads are not shared with PA reporting scripts, are 
required to be k-anonymous, and when displayed, each component ad can be 
isolated from each other in separate Fenced Frames.


I understand the benefits of increasing the number of ads, but are there 
any pointers to past discussion/analysis RE the privacy impact? I 
understand it's not huge (and it's not my role to judge the privacy risk - 
that's what the privacy review is for). I'd just love to better understand 
this :D 


WRT the privacy impact, as it's negligible, there isn't much to discuss so 
there isn't much prior discussion/analysis other than in this email thread 
and in the two links I posted before.  If there's some aspect you'd like to 
discuss further or dig into more, I'm happy to engage.


Fair enough. I'd have loved more discussion on this, but it's not a blocker.
 

 



 

 


Blink component

Blink>InterestGroups 



TAG review

The parent proposal, Protected Audience, is still pending: 
https://github.com/w3ctag/design-reviews/issues/723


TAG review status

Pending


Risks


Interoperability and Compatibility

Downsampled forDebugOnly: No expected breakage before 3PCD as the 
downsampling will not be performed until then.  For now only the status of 
whether a fDO caller is in the “lockout” or “cooldown” periods is exposed.  
After 3PCD, the downsampling will surely disrupt some potential uses of the 
reporting channel, but this is an essential privacy requirement of the 
Protected Audience API.

Increase number of component ads: This is an increase to the limit, so no 
breakage is expected.


Gecko & WebKit: No signal on parent proposal, Protected Audience.  Asked in 
the Mozilla forum here 
, and in the 
Webkit forum here 
.


Web developers:

Downsampled forDebugOnly: Di

Re: [blink-dev] Intent to ship: MP4 container support for MediaRecorder


LGTM3

(Mozilla has responded that they think this makes sense)

/Daniel

On 2024-03-06 22:02, 'Sunggook Chue' via blink-dev wrote:
Request for Mozilla: 
https://github.com/mozilla/standards-positions/issues/996.


Yes, the new feature already works on Safari.

On Wednesday, March 6, 2024 at 8:53:12 AM UTC-8 mike...@chromium.org 
wrote:


We met today and discussed this intent as OWNERS, and would like
you to still request a vendor position from Mozilla (as I
requested earlier). If this change doesn't result in interop with
Safari, can you also file a vendor position for them? My read of
the explainer is that we should be matching Safari, but confirming
would be good. Please consider shipping contingent on this request.

https://github.com/mozilla/standards-positions
https://github.com/WebKit/standards-positions

thanks,
Mike

On 3/6/24 11:48 AM, Alex Russell wrote:

LGTM3

At a higher level, it would be great for AV1/VP9 encode to end up
in something like Interop. It makes me sad to be adding a vote
here to enable a closed format when open ones are better.

On Wednesday, March 6, 2024 at 8:43:11 AM UTC-8 Philip Jägenstedt
wrote:

LGTM2

I think that

https://wpt.fyi/results/mediacapture-record?label=master&label=experimental&aligned&q=mp4


are the relevant tests. LGTM assuming all of these tests pass
with MediaRecorderEnableMp4Muxer enabled. If that's not the
case, is there some functionality that won't be supported
initially?

On Wed, Mar 6, 2024 at 7:19 AM Yoav Weiss (@Shopify)
 wrote:

LGTM1

On Tue, Mar 5, 2024 at 5:01 PM 'Michaela Merz' via
blink-dev  wrote:

Thank you for adding this. Finally we're going to be
able to do cross-browser video-recordings and
playing. Can't wait to see it in production.

M.


On Monday, March 4, 2024 at 3:50:13 PM UTC-7
sun...@microsoft.com wrote:

Mike, I've added feature detection and developer
engagement on

https://docs.google.com/document/d/1WV795DHY3Jf2p_htuAKZ9DXUefiGdQs29mCb8vRiHt8/edit?usp=sharing.


On Monday, March 4, 2024 at 2:13:11 PM UTC-8
Sunggook Chue wrote:

Yoav,

Philipp's answer is correct, please let me
know if you need any more info to unblock.

On Thursday, February 29, 2024 at 11:53:47 AM
UTC-8 philipp...@googlemail.com wrote:

Yoav,

in WebRTC land "we have a sample for
that" (thanks to the one and only WebRTC
devrel guy Sam Dutton, I think I stole
this tagline from him)!

https://webrtc.github.io/samples/src/content/getusermedia/record/
with recent changes to improve MP4 support.

Discovery currently happens
with isTypeSupported but it seems the WG
just decided to deprecate that:

https://github.com/w3c/mediacapture-record/issues/202#issuecomment-1956065141
(not sure how I feel about that, I'd
rather nuke MediaRecorder entirely in
favor of WebCodecs + IndexedDB)

Am Do., 29. Feb. 2024 um 09:13 Uhr
schrieb Yoav Weiss (@Shopify)
:



On Thu, Feb 29, 2024 at 1:46 AM
'Sunggook Chue' via blink-dev
 wrote:

Here is an explainer, summary only.


https://docs.google.com/document/d/1WV795DHY3Jf2p_htuAKZ9DXUefiGdQs29mCb8vRiHt8/edit?usp=sharing


Thanks! That's very useful! :)

What's the feature detection story?
How can developers know which formats
are supported?



On Wednesday, February 28, 2024
at 7:53:29 AM UTC-8
yoav...@chromium.org wrote:

On Tue, Feb 27, 2024 at
1:45 AM Mike Taylor
 wrote:


On 2/22/24 9:21 PM,

Re: [blink-dev] Re: Intent to Ship: Standard-compliant pseudo-element argument for getComputedStyle & KeyframeEffect

LGTM3

/Daniel

On 2024-03-13 16:19, Yoav Weiss (@Shopify) wrote:

LGTM2

On Wed, Mar 13, 2024 at 10:59 AM Noam Rosenthal
wrote:

On Wed, Mar 13, 2024 at 12:36 PM Yoav Weiss (@Shopify)
wrote:

On Monday, March 11, 2024 at 6:36:07 AM UTC-4 Noam Rosenthal
wrote:

I've run a rough HTTP archive query on it, testing all
HTTP responses last month (666 million):
getComputedStyle with an argument that doesn't begin with
"::" is called in 0.45% of pages, out of which 55% is
":before", 28% is after, and the vast majority of the rest
are invalid pseudo-element names (e.g. "height" or
"display").
There were extremely rare cases that would be affected:
getComputedStyle(element, ":placeholder") or
getComputedStyle(element, ":marker"), about 0.1% of
requests (34 out of 666 million).

Is this considering all requests? What's the %age when only
looking at HTML and CSS responses? (or on pages)

I refined the query a bit and use January dataset. So this will
potentially affect 89 pages out of 17M (226 responses of 420M). So
one in every 200,000 pages:
Total Pages 17,399,427
Total URLs 420,144,799
Potentially affected Pages 89
Potentially affected URLs 226
% Affected Pages0.0005%
% affected URLs 0.0001%

I'm still running the refinement to only use HTML/JS responses
(this is not CSS) but I'm not sure it will tell us something new.

Pages %age seems sufficiently small to give confidence here. Thanks!!
--
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/CAOmohSLTt%3DMgVzGw%2Beij8Hsga4%3DTaqDHcsDKwUH3H0khN0acSw%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/97c5bd80-6b1a-4d8a-a129-facfe36d4d26%40gmail.com.

Re: [blink-dev] Intent to Ship: Adding Cross-site Ancestor Chain Bit to CHIPS Partition Key

Also, can you flip on the relevant review gates in chromestatus.com?

On Wed, Mar 13, 2024 at 11:24 AM Yoav Weiss (@Shopify) <
yoavwe...@chromium.org> wrote:

>
>
> On Tue, Mar 12, 2024 at 4:46 PM 'Aaron Selya' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> The first mitigation listed here is to migrate existing
>>> partitioned cookies to include the new bit, and the second mitigation is to
>>> have a flag that can disable this feature. Would disabling the feature also
>>> include migrating the existing cookies back to exclude the new bit?
>>>
>>
>> Disabling the flag would not migrate the existing cookies back to exclude
>> the new bit. It would make it so that the new bit value is not considered
>> when checking equivalence. Not considering the value of the bit when is the
>> current behavior so we anticipate no issues ignoring the bit if the flag
>> needs to disable the feature.
>>
>
> Can you clarify what kind of flag are we talking about? Is this a Finch
> flag we expect to turn off if we encounter lots of breakage? An enterprise
> policy flag? A flag we expect users to use? (I doubt it's the latter, but
> clarifications would help :D)
>
>
>>
>>
>>> And somewhat related, but does the format of the cookie request
>>> developers make have to change too, or is this bit determination purely
>>> done within the browser?
>>>
>>
>> In almost all cases this is set within the browser. The only circumstance
>> I've run into where the value could be set by a developer is with the
>> chrome.cookies.set api for extensions.  This API allows the developer to
>> set the site associated with the cookie partition key and with this change
>> would allow for the bit value to be set as well.
>>
>> On Tue, Mar 12, 2024 at 2:53 PM Vladimir Levin 
>> wrote:
>>
>>>
>>>
>>> On Mon, Mar 11, 2024 at 1:42 PM Aaron Selya  wrote:
>>>
 Contact emails

 se...@chromium.org, dylancut...@chromium.org, kaustub...@chromium.org

 Explainer

 Keying of "CHIPS" cookies should align with other state:

 Specification

 Add cross-site ancestor chain bit to spec:
 https://github.com/explainers-by-googlers/CHIPS-spec/pull/13

 Summary

 We are looking to align the partition key

 in CHIPS (Cookies Having Independent Partitioned State, aka partitioned
 cookies) with the existing implementation of StorageKey.

 The only sites that would experience different behavior, would be when
 a top-level site “A” embeds an iframe to a cross-site document on site “B”,
 and then the iframe B embeds an iframe that loads a document from site “A”
 (shorthand: A1->B->A2). Previously, partitioned cookies sent or received in
 the inner iframe A2 would be the same partitioned cookies sent or received
 in the outer frame A1. This is no longer true.

 This change is privacy neutral, but will have improved security
 characteristics, because it prevents cross-site iframes from embedding
 arbitrary endpoints of the top-level site with credentials, without first
 being granted permission to do so through the Storage Access API (SAA) or
 Cross-Origin Resource Sharing (CORS).

 The impact of this change is expected to be small as our metrics
 indicate that only 0.2% of CHIPS (partitioned cookies) set by the first
 party are currently being used in A1->B->A2 contexts. This constitutes
 0.032% of all page loads (calculated using the usage of
 PartitionedCookie
 ).
 For websites that do need access to the same cookies across A1 and A2 (in
 the A1->B->A2 configuration), we recommend using SameSite=None cookies
 *without* the Partitioned attribute, and invoking the Storage Access API
 (SAA) or using the Cross-Origin Resource Sharing (CORS).

 Blink component

 Internals>Network>Cookies>PartitionedCookies

 TAG review

 Not requested, as this does not differ in any significant way from the
 original CHIPS design that was already reviewed by TAG
 .

 TAG review status

 N/A

 Risks

 Interoperability and Compatibility

 The inclusion of a new element in the partition key will mean that
 partitioned cookies (CHIPS) created after t

Re: [blink-dev] Intent to Ship: Adding Cross-site Ancestor Chain Bit to CHIPS Partition Key

On Tue, Mar 12, 2024 at 4:46 PM 'Aaron Selya' via blink-dev <
blink-dev@chromium.org> wrote:

> The first mitigation listed here is to migrate existing
>> partitioned cookies to include the new bit, and the second mitigation is to
>> have a flag that can disable this feature. Would disabling the feature also
>> include migrating the existing cookies back to exclude the new bit?
>>
>
> Disabling the flag would not migrate the existing cookies back to exclude
> the new bit. It would make it so that the new bit value is not considered
> when checking equivalence. Not considering the value of the bit when is the
> current behavior so we anticipate no issues ignoring the bit if the flag
> needs to disable the feature.
>

Can you clarify what kind of flag are we talking about? Is this a Finch
flag we expect to turn off if we encounter lots of breakage? An enterprise
policy flag? A flag we expect users to use? (I doubt it's the latter, but
clarifications would help :D)


>
>
>> And somewhat related, but does the format of the cookie request
>> developers make have to change too, or is this bit determination purely
>> done within the browser?
>>
>
> In almost all cases this is set within the browser. The only circumstance
> I've run into where the value could be set by a developer is with the
> chrome.cookies.set api for extensions.  This API allows the developer to
> set the site associated with the cookie partition key and with this change
> would allow for the bit value to be set as well.
>
> On Tue, Mar 12, 2024 at 2:53 PM Vladimir Levin 
> wrote:
>
>>
>>
>> On Mon, Mar 11, 2024 at 1:42 PM Aaron Selya  wrote:
>>
>>> Contact emails
>>>
>>> se...@chromium.org, dylancut...@chromium.org, kaustub...@chromium.org
>>>
>>>
>>> Explainer
>>>
>>> Keying of "CHIPS" cookies should align with other state:
>>> 
>>>
>>>
>>> Specification
>>>
>>> Add cross-site ancestor chain bit to spec:
>>> https://github.com/explainers-by-googlers/CHIPS-spec/pull/13
>>>
>>>
>>>
>>> Summary
>>>
>>> We are looking to align the partition key
>>> 
>>> in CHIPS (Cookies Having Independent Partitioned State, aka partitioned
>>> cookies) with the existing implementation of StorageKey.
>>>
>>>
>>> The only sites that would experience different behavior, would be when a
>>> top-level site “A” embeds an iframe to a cross-site document on site “B”,
>>> and then the iframe B embeds an iframe that loads a document from site “A”
>>> (shorthand: A1->B->A2). Previously, partitioned cookies sent or received in
>>> the inner iframe A2 would be the same partitioned cookies sent or received
>>> in the outer frame A1. This is no longer true.
>>>
>>>
>>> This change is privacy neutral, but will have improved security
>>> characteristics, because it prevents cross-site iframes from embedding
>>> arbitrary endpoints of the top-level site with credentials, without first
>>> being granted permission to do so through the Storage Access API (SAA) or
>>> Cross-Origin Resource Sharing (CORS).
>>>
>>>
>>>
>>> The impact of this change is expected to be small as our metrics
>>> indicate that only 0.2% of CHIPS (partitioned cookies) set by the first
>>> party are currently being used in A1->B->A2 contexts. This constitutes
>>> 0.032% of all page loads (calculated using the usage of
>>> PartitionedCookie
>>> ).
>>> For websites that do need access to the same cookies across A1 and A2 (in
>>> the A1->B->A2 configuration), we recommend using SameSite=None cookies
>>> *without* the Partitioned attribute, and invoking the Storage Access API
>>> (SAA) or using the Cross-Origin Resource Sharing (CORS).
>>>
>>>
>>>
>>> Blink component
>>>
>>> Internals>Network>Cookies>PartitionedCookies
>>> 
>>>
>>>
>>>
>>>
>>> TAG review
>>>
>>> Not requested, as this does not differ in any significant way from the
>>> original CHIPS design that was already reviewed by TAG
>>> .
>>>
>>>
>>> TAG review status
>>>
>>> N/A
>>>
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> The inclusion of a new element in the partition key will mean that
>>> partitioned cookies (CHIPS) created after the launch of this change will
>>> not be compatible with the partitioned cookies that already exist in users
>>> cookie jars. To address this, existing partitioned cookies will be migrated
>>> (without any need for developer action) to include the new cross-site
>>> ancestor chain bit value,

Re: [blink-dev] Re: Intent to Ship: Standard-compliant pseudo-element argument for getComputedStyle & KeyframeEffect

LGTM2

On Wed, Mar 13, 2024 at 10:59 AM Noam Rosenthal 
wrote:

>
>
> On Wed, Mar 13, 2024 at 12:36 PM Yoav Weiss (@Shopify) <
> yoavwe...@chromium.org> wrote:
>
>>
>>
>> On Monday, March 11, 2024 at 6:36:07 AM UTC-4 Noam Rosenthal wrote:
>>
>> I've run a rough HTTP archive query on it, testing all HTTP responses
>> last month (666 million):
>> getComputedStyle with an argument that doesn't begin with "::" is called
>> in 0.45% of pages, out of which 55% is ":before", 28% is after, and the
>> vast majority of the rest are invalid pseudo-element names (e.g. "height"
>> or "display").
>> There were extremely rare cases that would be affected:
>> getComputedStyle(element, ":placeholder") or getComputedStyle(element,
>> ":marker"), about 0.1% of requests (34 out of 666 million).
>>
>> Is this considering all requests? What's the %age when only looking at
>> HTML and CSS responses? (or on pages)
>>
>>
> I refined the query a bit and use January dataset. So this will
> potentially affect 89 pages out of 17M (226 responses of 420M). So one in
> every 200,000 pages:
> Total Pages 17,399,427
> Total URLs 420,144,799
> Potentially affected Pages 89
> Potentially affected URLs 226
> % Affected Pages 0.0005%
> % affected URLs 0.0001%
> I'm still running the refinement to only use HTML/JS responses (this is
> not CSS) but I'm not sure it will tell us something new.
>

Pages %age seems sufficiently small to give confidence here. Thanks!!

-- 
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/CAOmohSLTt%3DMgVzGw%2Beij8Hsga4%3DTaqDHcsDKwUH3H0khN0acSw%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: RegExp duplicate named capture groups


LGTM3

/Daniel

On 2024-03-11 17:16, Yoav Weiss (@Shopify) wrote:

LGTM2

On Mon, Mar 11, 2024 at 5:00 PM Shu-yu Guo  wrote:

On Mon, Mar 11, 2024 at 8:26 AM Mike Taylor
 wrote:

On 3/11/24 6:49 AM, Yoav Weiss (@Shopify) wrote:




On Fri, Mar 8, 2024 at 4:26 PM Mike Taylor
 wrote:

LGTM1

On 3/7/24 6:22 PM, Shu-yu Guo wrote:



Contact emails

pth...@chromium.org, s...@chromium.org


Explainer

None


Specification

https://github.com/tc39/ecma262/pull/2721



What are the implications of this on regexes that already
have duplicate named capture groups? Would their behavior
change?

Shu can confirm, but my understanding is any regexes in the
wild that have duplicate named capture groups today are just
busted (they should throw a SyntaxError - and those are pretty
hard to miss). If they do exist in the wild, they should start
working, which in theory would match author intent. The risk
seems very low IMHO, if it exists at all.


Exactly right. This is a case of going from a SyntaxError to
working, so there should be no back compat issues.


Makes sense, thanks for clarifying! :)


The concrete example from the explainer currently throws a
SyntaxError:

```
/(?[0-9]{4})-[0-9]{2}|[0-9]{2}-(?[0-9]{4})/
^^^
SyntaxError: Invalid regular expression:
/(?[0-9]{4})-[0-9]{2}|[0-9]{2}-(?[0-9]{4})/: Duplicate
capture group name
```




Summary

https://github.com/tc39/proposal-duplicate-named-capturing-groups



Blink component

Blink>JavaScript>Regexp




TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

This is a Stage 3 TC39 proposal. No known interop risk.
No known web incompatibility risk.



/Gecko/: Positive Firefox uses V8's regexp engine, so it
is not actually an independent implementation here.

/WebKit/: Shipped/Shipping
(https://bugs.webkit.org/show_bug.cgi?id=252553) Stage 3
TC39 proposal.

/Web developers/: No signals

/Other signals/:


Ergonomics

No known ergonomics risks.



Activation

This is unlikely to be polyfillable since it's adding a
new kind of RegExp syntax.



Security

No known security risks.



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

Debuggable like any other JS RegExp.



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

Yes


Is this feature fully tested by
web-platform-tests

?

Yes

Tested in test262.
https://github.com/tc39/test262/pull/3625
https://github.com/tc39/test262/pull/3706
https://github.com/tc39/test262/pull/3709



Flag name on chrome://flags

--js-regexp-duplicate-named-groups


Finch feature name

None


Non-finch justification

None


Requires code in //chrome?

False


Estimated milestones

DevTrial on desktop 123

DevTrial on Android 123



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/5149208388829184

This intent message was generated by Chrome Platform
Status

Re: [blink-dev] Re: Intent to Ship: Standard-compliant pseudo-element argument for getComputedStyle & KeyframeEffect

2024-03-13 Thread Noam Rosenthal

On Wed, Mar 13, 2024 at 12:36 PM Yoav Weiss (@Shopify) <
yoavwe...@chromium.org> wrote:

>
>
> On Monday, March 11, 2024 at 6:36:07 AM UTC-4 Noam Rosenthal wrote:
>
> I've run a rough HTTP archive query on it, testing all HTTP responses last
> month (666 million):
> getComputedStyle with an argument that doesn't begin with "::" is called
> in 0.45% of pages, out of which 55% is ":before", 28% is after, and the
> vast majority of the rest are invalid pseudo-element names (e.g. "height"
> or "display").
> There were extremely rare cases that would be affected:
> getComputedStyle(element, ":placeholder") or getComputedStyle(element,
> ":marker"), about 0.1% of requests (34 out of 666 million).
>
> Is this considering all requests? What's the %age when only looking at
> HTML and CSS responses? (or on pages)
>
>
I refined the query a bit and use January dataset. So this will potentially
affect 89 pages out of 17M (226 responses of 420M). So one in every 200,000
pages:
Total Pages 17,399,427
Total URLs 420,144,799
Potentially affected Pages 89
Potentially affected URLs 226
% Affected Pages 0.0005%
% affected URLs 0.0001%
I'm still running the refinement to only use HTML/JS responses (this is not
CSS) but I'm not sure it will tell us something new.

-- 
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/CAJn%3DMYbbQnmz3oCWEUv10DYuTC1b%2B6AOu1wABUh%3DOFsAUFKB7g%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: WebGPU: ServiceWorker and SharedWorker support

2024-03-13 Thread 'Corentin Wallez' via blink-dev

I don't know the ServiceWorker mechanisms too much, but if the Javascript 
dies in 30 seconds then WebGPU operations will soon after. There isn't a 
lot of use in keeping WebGPU computations running for much longer as 
Javascript is needed to get the result of any computation in any useful 
places (canvas, ArrayBuffer, MediaStream, etc). Technically the 
ServiceWorker could send a much longer running job to the GPU (think an 
infinite loop) but apart from DDoS there wouldn't be any use to this.

You might also be interested in the privacy and security section 
 of the WebGPU spec.
On Wednesday, March 13, 2024 at 9:55:02 AM UTC+1 Daniel Bratell wrote:

> Just to ask what is probably a FAQ to get it out here...
>
> The Service Worker timeout is 30 seconds right, so regardless of how heavy 
> the calculations are, a service worker and its associated calculations will 
> die in 30 seconds after the user closes the associated page?
>
> I ask because while it's been possible to run heavy calculations in 
> various workers in the past, this explicitly encourages it. It would be a 
> bad situation if a user cannot detect or stop a runaway WebGPU operation 
> from a possibly hostile site.
>
> /Daniel
> On 2024-03-13 08:06, 'François Beaufort' via blink-dev wrote:
>
>
>
> On Tue, Mar 12, 2024 at 10:14 PM Yoav Weiss (@Shopify) <
> yoav...@chromium.org> wrote:
>
>> LGTM1
>>
>> On Tue, Mar 12, 2024, 15:10 'François Beaufort' via blink-dev <
>> blin...@chromium.org> wrote:
>>
>>>
>>>
>>> On Tue, Mar 12, 2024 at 6:58 PM Mike Taylor  
>>> wrote:
>>>
 On 3/11/24 4:06 PM, 'François Beaufort' via blink-dev wrote:

 Contact emails fbea...@google.com

 Explainer None

 Could you write a few sentences why this is a useful addition?

>>>  
>>> Service Workers enable offline capabilities and background processing 
>>> for WebGPU. This means graphics-intensive web applications or Chrome 
>>> Extensions can cache resources and perform computations even when the user 
>>> isn't actively interacting with the page.
>>> Shared Workers allow multiple tabs or extension contexts to coordinate 
>>> and share WebGPU resources. This leads to smoother performance and more 
>>> efficient use of the user's graphics hardware.
>>>

 Specification https://gpuweb.github.io/gpuweb/#navigator-gpu

 Summary 

 Functionality added to the WebGPU spec after its first shipment in a 
 browser. ServiceWorker and SharedWorker support is added to WebGPU, 
 aligning with existing WebGL capabilities. 

 Blink component Blink>WebGPU 

 TAG review None

 TAG review status Not applicable

 Risks 

 Interoperability and Compatibility 

 ServiceWorker and SharedWorker support have not yet been implemented in 
 any browser, but have been approved by the GPU for the Web Community 
 Group, 
 with representatives from Chrome, Firefox, and Safari. See minutes at 
 https://docs.google.com/document/d/15w7nsvqWwITA5yvCrsO3SEIEuZziXzj7YsrHN4Jd2uM/edit#heading=h.jbe7pg8ebd43

 *Gecko*: No signal (
 https://github.com/mozilla/standards-positions/issues/971)

 Not officially a positive signal, but looking positive based on the 
 comments.

>>>
>>> Indeed. 
>>>

 *WebKit*: No signal (
 https://github.com/WebKit/standards-positions/issues/294#issuecomment-1877411933
 )

 This is kind of an "N/A to positive", given it's WebGPU.

>>>
>>> Agree ;) 
>>>

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

 *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, ChromeOS, Android, and Android WebView)? No
 All platforms will eventually have support. Will immediately be 
 available on Android, ChromeOS, Mac, and Windows, since those platforms 
 already support WebGPU. Linux is planned to have WebGPU support in the 
 future, so this feature will become available when WebGPU does.

 What about WebView? Do we ship support for WebGPU there?

>>>
>>> Yes. WebGPU is supported on Android WebView as well.
>>>
>>
> Note that Shared Workers are not available on Android for now. See 
> https://issues.chromium.org/issues/40290702 
>
>>
 Is this feature fully tested by web-platform-tests 

 ? Yes 

 WebGPU/WGSL have a conformance test suite (
 https://github.com/gpuweb/cts) that i

Re: [blink-dev] Intent to Ship: FedCM CORS requirement on ID assertion endpoint

2024-03-13 Thread Nicolás Peña


On Wednesday, March 13, 2024 at 7:37:29 AM UTC-4 Yoav Weiss wrote:

On Tuesday, March 12, 2024 at 3:11:24 PM UTC-4 Nicolás Peña wrote:

Regarding risk: we are going to implement this and test the IDPs we know 
are currently using FedCM, but we do not anticipate them to break since 
they are currently already relying on using third-party cookies in iframes. 
We also plan to have developer outreach/blogpost for this change so 
developers currently testing out FedCM are not caught by surprise.

Regarding vendor alignment: we have been working with Firefox and Apple to 
align on the correct behavior of the FedCM fetches: see 
https://github.com/fedidcg/FedCM/issues/320 and https://github.com/fedidcg/
FedCM/issues/428. This I2S is a result of a lot of discussions, and the 
small addition was a result of a very recent discussion occurring on our FedCM 
CORS breakout session 

.

Regarding spec, during our breakout Anne also mentioned that the small 
addition is not possible to specify properly, as it depends on the ongoing 
cookie layering work. I will add a note 
 on the spec in that fetch so 
IDPs know which cookies should be sent.

Anyways, I understand it is a bit late to add something to this I2S so if 
you prefer that we send a separate I2S/PSA for the SameSite change, we can 
do that instead.


Is the accounts endpoint the same endpoint to which this intent applies? Or 
is it different from the ID assertion endpoint?
If it's different, a separate I2S would be best. If it's the same, then I 
think we can probably fold it into this intent.


This change is to the ID assertion endpoint, which is different from the 
accounts endpoint. Then based on your comment, we will keep those two in 
separate intents. Consider the small addition I suggested above removed.
 

 



On Tuesday, March 12, 2024 at 1:34:56 PM UTC-4 Mike Taylor wrote:

On 3/12/24 11:33 AM, Nicolás Peña Moreno wrote:

Thanks for the suggestion, Yoav! It seems something fetch experts have some 
concerns about, so we do not plan to proceed with that suggestion at the 
moment.

Thanks for considering! Anne makes a good point that active defense here 
(by filtering requests based on destination) would work better against 
timing attacks than passive defense (where the responses are blocked by the 
browser). Please make sure that IDPs are aware of the destination filtering 
requirement, by having it emphasized in developer facing documentation.


Yes, we will work with devrel to continue ensuring IDP best practices are 
easily discoverable.
 


I'd like to append a small addition to this I2S (mainly to avoid having an 
additional PSA since it is very related to this one): we would also like 
approval to only send Same-Site=None cookies in the accounts endpoint, 
instead of all cookies (so not Same-Site=Lax or Same-Site=Strict). This is 
also a breaking change but we do not anticipate IDPs to break, and also 
plan to work with them to ensure that they are aware of this change and are 
not caught by surprise.

To my non-FedCM expert brain, this doesn't feel like a small addition 
(happy to be wrong!), beyond not understanding the scale of the risk, the 
normal process questions come to mind i.e., is it specced, do we have 
tests, what do other vendors think about it?


On Monday, March 11, 2024 at 6:39:14 AM UTC-4 Yoav Weiss wrote:


I left a comment 
 around 
potentially adding a CORS mode that would help IDP servers statically 
protect themselves from destination-change attacks. I don't *think* it's a 
blocker, but it's worth considering something along those lines to increase 
the solution's robustness to configuration errors, and ensure it fails 
closed. (and ask IDPs' security teams about their thoughts)

On Wed, Mar 6, 2024 at 5:51 PM Nicolás Peña  wrote:

No, Sec-Fetch-Dest 
 
is not changing. Sec-Fetch-Mode 
 
is.

On Wednesday, March 6, 2024 at 11:31:35 AM UTC-5 Chris Harrelson wrote:

On Wed, Mar 6, 2024 at 8:28 AM Nicolás Peña  wrote:



On Wednesday, March 6, 2024 at 5:11:09 AM UTC-5 Yoav Weiss wrote:

On Wed, Mar 6, 2024 at 10:21 AM Yoav Weiss (@Shopify)  
wrote:



On Mon, Mar 4, 2024 at 9:36 PM Mike Taylor  wrote:

LGTM1
On 3/4/24 1:33 PM, Nicolás Peña wrote:

Contact emails 

n...@chromium.org

Explainer 

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


A few lines summarizing this issue would be most useful when evaluating 
this and understanding what y'all want to ship.
In particular, it'd be useful to understand the request flow, what is the 
request's origin (as IIUC, we're talking about requests issued from the 
browser), and what is the request destination that we may want IDPs to 
check.

Re: [blink-dev] Re: Intent to Ship: Standard-compliant pseudo-element argument for getComputedStyle & KeyframeEffect

On Monday, March 11, 2024 at 6:36:07 AM UTC-4 Noam Rosenthal wrote:

I've run a rough HTTP archive query on it, testing all HTTP responses last
month (666 million):
getComputedStyle with an argument that doesn't begin with "::" is called in
0.45%
of pages, out of which 55% is ":before", 28% is after, and the vast
majority of the rest are invalid pseudo-element names (e.g. "height" or
"display").
There were extremely rare cases that would be affected:
getComputedStyle(element, ":placeholder") or getComputedStyle(element,
":marker"), about 0.1% of requests (34 out of 666 million).

Is this considering all requests? What's the %age when only looking at HTML
and CSS responses? (or on pages)

I'm running a more refined version of the query but I doubt I'll get
significantly different results.

So I'd perhaps classify backwards compatibility as low-risk?

On Mon, Mar 11, 2024 at 9:32 AM Noam Rosenthal
wrote:

On Mon, Mar 11, 2024 at 5:57 AM Domenic Denicola
wrote:

Thanks Dan for raising the compat concerns here. It seems like a mistake
that the original Intent says "None" for that,

Good point, I updated it.

and I think we need to get that section of the Chrome Status entry fleshed
out before considering approvals here.

What I'm hearing so far is that we think the compat risks might be small
because Gecko and WebKit are already using strict parsing. That's
something, but can we do better? For example:

- Is there any upper bound on the potential number of broken page views?
Ideally we'd have a use counter for how many times the lenient parsing is
triggered, but for an upper bound even just a use counter for how many
times these arguments are supplied to getComputedStyle()/new
KeyframeEffect() would help.
- Can we do an HTTP archive analysis of some sort?

Will do both and come back with results.

On Sun, Mar 10, 2024 at 5:55 PM Noam Rosenthal
wrote:

On Fri, Mar 8, 2024 at 11:56 PM 'Dan Clark' via blink-dev <
blink-dev@chromium.org> wrote:

Am I correct in understanding that Gecko already mostly matches the
behavior in the spec? I see that Firefox also fails most of the WPTs at
https://wpt.fyi/results/css/cssom/getComputedStyle-
pseudo-with-argument.html?label=master&label=experimental&aligned, but I
guess that's because they haven't shipped ::highlight() pseudos.

Correct, it's because of ::highlight. It passes most of the tests in
https://wpt.fyi/results/css/cssom/getComputedStyle-pseudo.html?label=master&;
label=experimental&aligned.

How are you thinking about the compatibility risk? If we're making the
parsing stricter in certain ways, presumably sites depending on that
behavior could break. Omitting the ":" seems like it could be a
particularly easy mistake to make. On the other hand the fact that WebKit
(and I guess Gecko) already did it is an encouraging signal.

Correct. Also, intending to keep current behavior for old pseudos that
support single-colon in regular CSS (before, after, first-line,
first-letter). If there are other exceptions with a lot of existing code we
can consider adding them here.

The way I'm thinking about this from a compat perspective is that if we
keep supporting single-colon/no-colon for all pseudos, there would be more
non-spec-compliant code written with those, that would seem to work in
chrome while developing and then not work in other browsers. So aligning
with the spec now is hopefully cleaner.

However, if there are reasons to keep some of the parsing more lenient here
I'm happy to hear and find the best solution for the web platform.

--
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/CAJn%3DMYbLLqWEjSNYnt6Pw%2BcV75%3DryQ%3DbsDM%
3DAXtktKW6C__kkQ%40mail.gmail.com

Re: [blink-dev] Intent to Ship: FedCM CORS requirement on ID assertion endpoint



On Tuesday, March 12, 2024 at 3:11:24 PM UTC-4 Nicolás Peña wrote:

Regarding risk: we are going to implement this and test the IDPs we know 
are currently using FedCM, but we do not anticipate them to break since 
they are currently already relying on using third-party cookies in iframes. 
We also plan to have developer outreach/blogpost for this change so 
developers currently testing out FedCM are not caught by surprise.

Regarding vendor alignment: we have been working with Firefox and Apple to 
align on the correct behavior of the FedCM fetches: see 
https://github.com/fedidcg/FedCM/issues/320 and https://github.com/fedidcg/
FedCM/issues/428. This I2S is a result of a lot of discussions, and the 
small addition was a result of a very recent discussion occurring on our FedCM 
CORS breakout session 

.

Regarding spec, during our breakout Anne also mentioned that the small 
addition is not possible to specify properly, as it depends on the ongoing 
cookie layering work. I will add a note 
 on the spec in that fetch so 
IDPs know which cookies should be sent.

Anyways, I understand it is a bit late to add something to this I2S so if 
you prefer that we send a separate I2S/PSA for the SameSite change, we can 
do that instead.


Is the accounts endpoint the same endpoint to which this intent applies? Or 
is it different from the ID assertion endpoint?
If it's different, a separate I2S would be best. If it's the same, then I 
think we can probably fold it into this intent.
 



On Tuesday, March 12, 2024 at 1:34:56 PM UTC-4 Mike Taylor wrote:

On 3/12/24 11:33 AM, Nicolás Peña Moreno wrote:

Thanks for the suggestion, Yoav! It seems something fetch experts have some 
concerns about, so we do not plan to proceed with that suggestion at the 
moment.

Thanks for considering! Anne makes a good point that active defense here 
(by filtering requests based on destination) would work better against 
timing attacks than passive defense (where the responses are blocked by the 
browser). Please make sure that IDPs are aware of the destination filtering 
requirement, by having it emphasized in developer facing documentation.


I'd like to append a small addition to this I2S (mainly to avoid having an 
additional PSA since it is very related to this one): we would also like 
approval to only send Same-Site=None cookies in the accounts endpoint, 
instead of all cookies (so not Same-Site=Lax or Same-Site=Strict). This is 
also a breaking change but we do not anticipate IDPs to break, and also 
plan to work with them to ensure that they are aware of this change and are 
not caught by surprise.

To my non-FedCM expert brain, this doesn't feel like a small addition 
(happy to be wrong!), beyond not understanding the scale of the risk, the 
normal process questions come to mind i.e., is it specced, do we have 
tests, what do other vendors think about it?


On Monday, March 11, 2024 at 6:39:14 AM UTC-4 Yoav Weiss wrote:


I left a comment 
 around 
potentially adding a CORS mode that would help IDP servers statically 
protect themselves from destination-change attacks. I don't *think* it's a 
blocker, but it's worth considering something along those lines to increase 
the solution's robustness to configuration errors, and ensure it fails 
closed. (and ask IDPs' security teams about their thoughts)

On Wed, Mar 6, 2024 at 5:51 PM Nicolás Peña  wrote:

No, Sec-Fetch-Dest 
 
is not changing. Sec-Fetch-Mode 
 
is.

On Wednesday, March 6, 2024 at 11:31:35 AM UTC-5 Chris Harrelson wrote:

On Wed, Mar 6, 2024 at 8:28 AM Nicolás Peña  wrote:



On Wednesday, March 6, 2024 at 5:11:09 AM UTC-5 Yoav Weiss wrote:

On Wed, Mar 6, 2024 at 10:21 AM Yoav Weiss (@Shopify)  
wrote:



On Mon, Mar 4, 2024 at 9:36 PM Mike Taylor  wrote:

LGTM1
On 3/4/24 1:33 PM, Nicolás Peña wrote:

Contact emails 

n...@chromium.org

Explainer 

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


A few lines summarizing this issue would be most useful when evaluating 
this and understanding what y'all want to ship.
In particular, it'd be useful to understand the request flow, what is the 
request's origin (as IIUC, we're talking about requests issued from the 
browser), and what is the request destination that we may want IDPs to 
check.

Examples of the checks IDPs would have to make would also be helpful.


Sure! From the spec 
, here is a 
sample request:

POST /fedcm_assertion_endpoint HTTP/1.1
Host: idp.example
Origin: https://rp.example/
Content-Type: application/x-www-form-urlencoded
Cookie: 0x23223
Sec-Fetch-Dest: webidentity
account_id=123&client_id=cli

Re: [blink-dev] Intent to Ship: WebGPU: ServiceWorker and SharedWorker support