[blink-dev] Intent to Ship: noopener-allow-popups COOP value

[Yoav Weiss (@Shopify)]

Contact emailsyoavwe...@chromium.org

Explainerhttps://gist.github.com/yoavweiss/c7b61e97e6f8d207be619f87ab96ead5

Specificationhttps://github.com/whatwg/html/pull/10394

The PR hasn't landed yet, but I believe it is ready to land (% potential
nits).
I'm not aware of any open issues.

Summary

Some origins can contain different applications with different levels of
security requirements. In those cases, it can be beneficial to prevent
scripts running in one application from being able to open and script pages
of another same-origin application. In such cases, it can be beneficial for
a document to ensure its opener cannot script it, even if the opener
document is a same-origin one. The `noopener-allow-popups`
Cross-Origin-Opener-Policy value will allow documents to define that.


Blink componentBlink


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

TAG review statusIssues addressed

Risks


Interoperability and Compatibility

Compatibility risk: As this feature adds a new COOP value, it doesn't run a
risk of colliding with existing values. Where we may see some risk is when
developers start using this value in ways that would surprise other teams
on their origins. (as they would no longer have scripting access to opened
documents) I don't expect that to happen often, and if it would it's
something that developers would find out at development time. So I don't
expect that to impact users. Interoperability risk: WebKit's positive
position makes me optimistic that I'd be able to land the feature there
 as well.


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

*WebKit*: Support (https://github.com/WebKit/standards-positions/issues/360)

*Web developers*: No particular signals, other than the fact that Shopify
is interested in this.

*Other signals*:

Security

No particular issues:
https://gist.github.com/yoavweiss/3cb7283f56717f6dfe6da05009a27a65


The main risk is having developers over rely on the protections this would
provide. Input from Chrome and Google security folks led to the inclusion
of a spec note

warning developers against it and indicating what else they'd need to do
for more holistic isolation of same-origin documents from others.


I'm planning to add a similar note to developer-facing docs
.

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

?Yes

https://wpt.fyi/results/html/cross-origin-opener-policy/tentative/noopener/coop-noopener-allow-popups.https.html?label=experimental&label=master&aligned


The test doesn't pass on the bots as the feature is disabled using a base
feature flag (and no runtime flag).

Flag name on chrome://flagsNone

Finch feature nameCoopNoopenerAllowPopups

Requires code in //chrome?False

Tracking bughttps://issues.chromium.org/issues/344963946

Measurementhttps://chromestatus.com/metrics/feature/timeline/popularity/5029
 https://chromestatus.com/metrics/feature/timeline/popularity/5030

Estimated milestones
Shipping on desktop 131
Shipping on Android 131
Shipping on WebView 131

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).


No open questions ATM.

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5163293877731328?gate=4905084336209920

Links to previous Intent discussionsIntent to Prototype:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSJj33d%3D0B0tNpD0qrYWzygx0i02bWdhbV3aSCgbjS3Ndw%40mail.gmail.com


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/CAOmohSJwqLtZRnw5_SgNoxvRFXdPXAJfE1Zs2iDL3jVhiMRhwA%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Dynamic safe area insets

[Yoav Weiss (@Shopify)]

LGTM2

The fact that iOS already shipped this is a compelling argument.

On Thu, Sep 12, 2024 at 3:55 PM Rick Byers  wrote:

> On Thu, Sep 12, 2024 at 9:09 AM Yoav Weiss (@Shopify) <
> yoavwe...@chromium.org> wrote:
>
>>
>> On Wed, Sep 11, 2024 at 5:05 PM Wenyu Fu  wrote:
>>
>>> Thank you for the feedback Robert!
>>>
>>> > updating the safe area while scrolling requires a main thread update
>>> for the developer drawn controls (e.g. footer) to respond
>>>
>>> I've attached a recording of the same feature's behavior on iOS
>>> <https://drive.google.com/file/d/19kaNBAr8RFQ0X9odMjx4g-t28lnCHSS_/view?usp=drive_link>.
>>> One of the initiatives for this change is to align Chrome on Android
>>> parity with iOS.
>>>
>>> > Can you attach this video so that it is available externally?
>>>
>>> Here's the link to the recording
>>> <https://drive.google.com/file/d/1IhIiYMaG5bK2n-ufahEqkQwcPTok7sFe/view?usp=drive_link>
>>>  -
>>> I've updated that in chrome status too:
>>> https://chromestatus.com/feature/5174306712322048?gate=5101473814544384
>>>
>>>
>>>
>>> On Wed, Sep 11, 2024 at 7:41 AM Robert Flack 
>>> wrote:
>>>
>>>> My only concern with the current feature is that dynamically updating
>>>> the safe area while scrolling requires a main thread update for the
>>>> developer drawn controls (e.g. footer) to respond. This is going to be
>>>> slow. Hopefully there is a path by which we can recognize this positioning
>>>> and update it frame perfectly on the compositor similar to fixed / sticky
>>>> position content.
>>>>
>>>> Otherwise, this seems in line with the established pattern for devices
>>>> which draw the viewport to an area that is not entirely guaranteed to be
>>>> visible.
>>>>
>>>> On Mon, Sep 9, 2024 at 12:54 PM Wenyu Fu  wrote:
>>>>
>>>>> Friendly ping :) This feature has an associated Chrome milstone, it'd
>>>>> be great if I can get some feedback so I can have them addressed in a
>>>>> timely manner
>>>>>
>>>>> On Fri, Sep 6, 2024 at 7:58 AM Wenyu Fu  wrote:
>>>>>
>>>>>> For Chrome on Android, we are aiming to draw the web contents edge to
>>>>>> edge, drawing part of the web contents under the bezels (i.e. navigation
>>>>>> bar). This change allows us to correctly dispatch the safe-area-inset*
>>>>>> attributes based on the shown ration of the browser controls, so if
>>>>>> websites has control elements that anchor to the bottom, they can read 
>>>>>> the
>>>>>> CSS env variable "safe-area-inset-bottom" to avoid having the controls
>>>>>> being occluded by the navigation bar. This Intent to Ship is targeting 
>>>>>> the
>>>>>> render side of the change.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Sep 6, 2024 at 3:59 AM Yoav Weiss (@Shopify) <
>>>>>> yoavwe...@chromium.org> wrote:
>>>>>>
>>>>>>> The design doc doesn't give a lot of background. Can you provide a
>>>>>>> short explanation or an inline explainer as to what this is trying to 
>>>>>>> solve
>>>>>>> and how we think developers will be using this? Thanks! :)
>>>>>>>
>>>>>>
>>>> MDN has a great explanation and examples
>>>> <https://developer.mozilla.org/en-US/docs/Web/CSS/env#examples> of how
>>>> this variable is used by developers. I suspect given this is already an
>>>> established feature and that this is changing it to be dynamic in the case
>>>> of native UI which only covers the content some of the time that this could
>>>> have been a PSA
>>>> <https://www.chromium.org/blink/launching-features/#behavior-changes>.
>>>> The only risk I can think of is if this is the first instance of a
>>>> dynamically changing inset, there may be developers who read it once from
>>>> Javascript and don't have a signal to update their UI when it changes.
>>>>
>>>
>> Makes sense! Can y'all take a look at the HTTP archive to make sure we
>> don't see evidence of this happening in the wild?
>>
>
> FWIW, given this is already shipp

Re: [blink-dev] Intent to Ship: CSS font-variant-emoji

[Yoav Weiss (@Shopify)]

LGTM1

Thanks for catching us up! :)

On Wed, Sep 11, 2024 at 5:20 PM 'Munira Tursunova' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emailsmoon...@google.com
>
> ExplainerNone
>
> Specificationhttps://www.w3.org/TR/css-fonts-4/#font-variant-emoji-prop
>
> Design docs
>
> https://docs.google.com/document/d/1NyIKm0PnWUwX6j0smDwxDAPSUoiyBHPL95oH2lvjjpc/edit?usp=sharing&resourcekey=0-ubYsGJCgRSQnT9i_guM64g
>
> Summary
>
> Font-variant-emoji CSS property provides users an easy way to control
> between colored (emoji-style) and monochromatic (text-style) emoji glyphs
> presentations. This can be also done by adding an emoji Variation Selector,
> specifically U+FE0E for text and U+FE0F for emojis, after each emoji
> codepoint. Using font-variant-emoji CSS property allows web developers to
> select between emoji style (colored) emoji presentation, text style
> (monochromatic) emoji presentation and unicode default emoji presentation
> [0]. This property only affects emojis that are part of a Unicode emoji
> presentation sequence [1]. [0]
> https://www.unicode.org/reports/tr51/tr51-25.html#Emoji_Presentation [1]
> http://www.unicode.org/emoji/charts/emoji-variants.html
>
>
> Blink componentBlink>Fonts>Emoji
> 
>
> Search tagsemoji , variation
> selectors ,
> font-variant-emoji
> , variation
> sequences 
>
> TAG reviewNone
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> None, already shipped in Firefox and Safari.
>
>
> *Gecko*: Shipped/Shipping (
> https://bugzilla.mozilla.org/show_bug.cgi?id=1461589)
>
> *WebKit*: Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=246911
> )
>
> *Web developers*: Positive
>
>- Salesforce web developer Nolan Lawson shares the struggles of
>controlling emoji presentation in the article (
>
> https://nolanlawson.com/2022/04/08/the-struggle-of-using-native-emoji-on-the-web/
>).
>- Ollie Williams expressed interest in emoji presentation control in
>the blog (https://fullystacked.net/posts/using-emoji-on-the-web/).
>- Chris Coyier, co-founder of codepen, shared the struggles with emoji
>presentations in the blog post (
>https://front-end.social/@chriscoyier/112328067179677693).
>- Alibaba developer 一丝 also shared the struggles with using emojis in
>chrome in the blog post (
>https://x.com/yisibl/status/1826841566469566779).
>- ByteDance has been interested in this feature for quite a while,
>their developer, ChangSeok Oh posted an Intent to Prototype in blink-dev
>group (
>
> https://groups.google.com/a/chromium.org/g/blink-dev/c/MaXgbE4vTbk/m/Q3QbI37IBQAJ
>).
>
>
> *Other signals*:
>
> WebView application risks
>
> Does this intent deprecate or change behavior of existing APIs, such that
> it has potentially high risk for Android WebView-based applications?
>
> None
>
>
> Debuggability
>
> No additional DevTools support is needed. Font-variant-emoji property is
> inspectable in DevTools same way as any other CSS property.
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, ChromeOS, Android, and Android WebView)?No
>
> Supported on all platforms for web fonts. Support of the feature for
> system fallback fonts depends on the fonts installed in the system, so some
> platforms may lack system fonts that cover desired emoji unicode codepoints
> with desired Variation Selectors. Since on Linux, installed fonts can
> greatly vary, it's hard to pick a unified colored and monochromatic emoji
> fallback font. Therefore the feature for fallback system fonts is only
> supported on main platforms such as Android, Windows and Mac OS.
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?Yes
>
>
> https://wpt.fyi/results/css/css-fonts?label=master&label=experimental&aligned&q=font-variant-emoji
> https://wpt.fyi/results/css/css-fonts/variation-sequences.html?label=master&label=experimental&aligned&q=variation-sequences
>
>
> Flag name on chrome://flagsFontVariantEmoji, FontVariationSequences
>
> Finch feature nameFontVariantEmoji, FontVariationSequences
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1379029
>
> Sample links
> https://developer.mozilla.org/en-US/docs/Web/CSS/font-variant-emoji
>
> Estimated milestones
> Shipping on desktop 131
> Shipping on Android 131
> Shipping on WebView 131
>
> 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

Re: [blink-dev] Intent to Ship: Dynamic safe area insets

[Yoav Weiss (@Shopify)]

On Wed, Sep 11, 2024 at 5:05 PM Wenyu Fu  wrote:

> Thank you for the feedback Robert!
>
> > updating the safe area while scrolling requires a main thread update for
> the developer drawn controls (e.g. footer) to respond
>
> I've attached a recording of the same feature's behavior on iOS
> <https://drive.google.com/file/d/19kaNBAr8RFQ0X9odMjx4g-t28lnCHSS_/view?usp=drive_link>.
> One of the initiatives for this change is to align Chrome on Android
> parity with iOS.
>
> > Can you attach this video so that it is available externally?
>
> Here's the link to the recording
> <https://drive.google.com/file/d/1IhIiYMaG5bK2n-ufahEqkQwcPTok7sFe/view?usp=drive_link>
>  -
> I've updated that in chrome status too:
> https://chromestatus.com/feature/5174306712322048?gate=5101473814544384
>
>
>
> On Wed, Sep 11, 2024 at 7:41 AM Robert Flack  wrote:
>
>> My only concern with the current feature is that dynamically updating the
>> safe area while scrolling requires a main thread update for the developer
>> drawn controls (e.g. footer) to respond. This is going to be slow.
>> Hopefully there is a path by which we can recognize this positioning and
>> update it frame perfectly on the compositor similar to fixed / sticky
>> position content.
>>
>> Otherwise, this seems in line with the established pattern for devices
>> which draw the viewport to an area that is not entirely guaranteed to be
>> visible.
>>
>> On Mon, Sep 9, 2024 at 12:54 PM Wenyu Fu  wrote:
>>
>>> Friendly ping :) This feature has an associated Chrome milstone, it'd be
>>> great if I can get some feedback so I can have them addressed in a timely
>>> manner
>>>
>>> On Fri, Sep 6, 2024 at 7:58 AM Wenyu Fu  wrote:
>>>
>>>> For Chrome on Android, we are aiming to draw the web contents edge to
>>>> edge, drawing part of the web contents under the bezels (i.e. navigation
>>>> bar). This change allows us to correctly dispatch the safe-area-inset*
>>>> attributes based on the shown ration of the browser controls, so if
>>>> websites has control elements that anchor to the bottom, they can read the
>>>> CSS env variable "safe-area-inset-bottom" to avoid having the controls
>>>> being occluded by the navigation bar. This Intent to Ship is targeting the
>>>> render side of the change.
>>>>
>>>>
>>>>
>>>> On Fri, Sep 6, 2024 at 3:59 AM Yoav Weiss (@Shopify) <
>>>> yoavwe...@chromium.org> wrote:
>>>>
>>>>> The design doc doesn't give a lot of background. Can you provide a
>>>>> short explanation or an inline explainer as to what this is trying to 
>>>>> solve
>>>>> and how we think developers will be using this? Thanks! :)
>>>>>
>>>>
>> MDN has a great explanation and examples
>> <https://developer.mozilla.org/en-US/docs/Web/CSS/env#examples> of how
>> this variable is used by developers. I suspect given this is already an
>> established feature and that this is changing it to be dynamic in the case
>> of native UI which only covers the content some of the time that this could
>> have been a PSA
>> <https://www.chromium.org/blink/launching-features/#behavior-changes>.
>> The only risk I can think of is if this is the first instance of a
>> dynamically changing inset, there may be developers who read it once from
>> Javascript and don't have a signal to update their UI when it changes.
>>
>
Makes sense! Can y'all take a look at the HTTP archive to make sure we
don't see evidence of this happening in the wild?


>
>> On Fri, Aug 30, 2024 at 7:10 PM Wenyu Fu  wrote:
>>>>>
>>>>>> > The work isn't being done by the team which owns Blink>CSS so it
>>>>>> would be good if there were experts which could triage incoming bugs, etc
>>>>>> in this area.
>>>>>>
>>>>>> Good callout! I can't seem to find an appropriate component for this
>>>>>> feature, thus I choose the closest. During development I've been closely
>>>>>> working with owners from Blink>CSS (futhark@) and I think this still
>>>>>> fits the CSS area.
>>>>>>
>>>>>> FWIW I think we could still create the Blink>CSS>SafeArea component
>>>>>>
>>>>>> > make public access to the indicated document?
>>>>>>
>>>>>

Re: [blink-dev] Intent to Ship: Capture all screens

[Yoav Weiss (@Shopify)]

LGTM3

On Wed, Sep 11, 2024 at 6:02 PM Vladimir Levin  wrote:

> LGTM2
>
> On Wed, Sep 11, 2024 at 12:00 PM Alex Russell 
> wrote:
>
>> LGTM1
>>
>> On Tuesday, September 10, 2024 at 3:36:50 PM UTC-7 Reilly Grant wrote:
>>
>>> LGTM as an IWA OWNER (3x LGTM from Blink API OWNERS are still required
>>> according to the IWA-specific API launch process
>>> ).
>>>
>>> This feature has been an interesting case study for when to restrict a
>>> capability to IWAs because the two underlying components of it, capturing a
>>> screen and enterprise policies to control a permission, exist in other
>>> features without requiring such drastic security measures. In
>>> consultation with the Security reviewers however we found that the
>>> combination of a requirement to capture all screens (which is more
>>> dangerous than normal screen capture because it doesn't allow the user to
>>> differentiate between shared and unshared content) and an administrator
>>> control (which removes user agency to decide whether their screen is
>>> displaying sensitive information) makes this feature a particularly
>>> attractive target for an attacker and necessitates the code integrity
>>> protections provided by Isolated Web Apps.
>>> Reilly Grant | Software Engineer | reil...@chromium.org | Google Chrome
>>> 
>>>
>>>
>>> On Tue, Sep 10, 2024 at 7:39 AM 'Simon Hangl' via blink-dev <
>>> blink-dev@chromium.org> wrote:
>>>
 Contact emails

 simo...@google.com, swethasiva...@google.com

 Explainer

 https://github.com/screen-share/capture-all-screens/blob/main/README.md

 Specification

 https://screen-share.github.io/capture-all-screens

 Design docs

 https://screen-share.github.io/capture-all-screens

 https://github.com/screen-share/capture-all-screens/blob/main/README.md


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

 Summary

 Capture all the screens currently connected to the device using
 getAllScreensMedia().

 Calling getDisplayMedia() multiple times requires multiple user
 gestures, with the user manually selecting the next screen each time, and
 without a guarantee to the app that all screens were selected.
 getAllScreensMedia() improves on all of these fronts.

 (As this feature has extreme privacy ramifications, it is only exposed
 behind an enterprise policy, and users are warned before recording even
 starts, that recording *could* start at some point.)


 Blink component

 Blink>Media>GetAllScreensMedia
 

 TAG review

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

 TAG review status

 TAG has expressed concerns about exposing such a powerful capability on
 the web. We mitigate their concerns by moving the API to Isolated Web Apps
 and only exposing it to apps that are explicitly allowlisted by the device
 owner.

 Chromium Trial Name

 GetAllScreensMedia

 Link to origin trial feedback summary

 https://github.com/screen-share/capture-all-screens/issues

 Origin Trial documentation link

 https://github.com/screen-share/capture-all-screens

 Risks

 Interoperability and Compatibility

 This API is only available to origins allowlisted by administrators
 through a policy. The policy itself is non-standard, limiting even
 theoretical interoperability. This API rejects requests from pages that are
 not allowlisted by an administrator. The likelihood of this API being
 adopted by a browser that does not provide administrators mechanisms to
 manage clients is low.


 Gecko: N/A - given that the API is limited to managed configurations,
 it's not clear that requesting a position is needed

 WebKit: N/A - given that the API is limited to managed configurations,
 it's not clear that requesting a position is needed

 Web developers: Positive (
 https://github.com/screen-share/capture-all-screens/issues/9)

 Other signals:

 Ergonomics

 No


 Activation

 The challenge for developers is the limitation of the API to origins
 allowlisted by an enterprise policy.


 Security

1.

Risk of malicious sites exploiting the API and gaining access to
sensitive information on users' devices. This risk is mitigated by the 
 API
only being accessible to origins allowlisted by an enterprise policy.
2.

Risk of an allowlisted site being compromised to gain access to
sensitive information on users’ devices. This risk is mitigated by the 
 API
only being accessible to I

Re: [blink-dev] Intent to Ship: Add bugfix version number to User-Agent string on Bling

[Yoav Weiss (@Shopify)]

That's LGTM1

On Wed, Sep 11, 2024 at 3:09 PM Yoav Weiss (@Shopify) <
yoavwe...@chromium.org> wrote:

> LGTM
>
> On Wed, Aug 28, 2024 at 9:53 PM Janice Liu  wrote:
>
>> Contact emails
>>
>> janice...@chromium.org, miketa...@chromium.org
>>
>> Explainer
>>
>> None. This is a minor change.
>>
>> Specification
>>
>> https://www.rfc-editor.org/rfc/rfc9110#field.user-agent
>>
>> Summary
>>
>> User Agent (UA) strings in Chromium have been moving towards reducing or
>> freezing information - but until WebKit allows us to implement UA client
>> hints,
>>
> :(
>
>
>> we propose adding the OS bugfix number to the UA, for compatibility
>> purposes.
>>
>>
>> Blink component
>>
>> Chromium>Mobile>iOSWeb
>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Chromium%3EMobile%3EiOSWeb>
>>
>> Motivation
>>
>> The Chrome for iOS User-Agent header only includes the major and minor
>> version numbers, while Safari and Firefox for iOS include the major, minor,
>> and bugfix numbers. We have received a request from external partners to
>> match this pattern, and are aware of at least one platform that relies on
>> having an accurate bugfix version number to ensure the latest security
>> updates are installed.
>>
>> UA strings in Chromium have been moving towards reducing or freezing
>> information - but until WebKit allows us to implement UA client hints, we
>> propose adding the bugfix number to the UA, for compatibility purposes.
>>
>> In practice:
>>
>> Before this change: Mozilla/5.0 (iPhone; CPU iPhone OS 17_5 like Mac OS X)
>>
>> AppleWebKit/602.1.50 (KHTML, like Gecko) CriOS/123.0.2924.75
>>
>> Mobile/14E5239e Safari/602.1
>>
>>
>> After this change (note the additional “_1” in the OS version token):
>> Mozilla/5.0 (iPhone; CPU iPhone OS 17_5_1 like Mac OS X)
>>
>> AppleWebKit/602.1.50 (KHTML, like Gecko) CriOS/123.0.2924.75
>>
>> Mobile/14E5239e Safari/602.1
>>
>>
>>
>> Initial public proposal
>>
>> None
>>
>> TAG review
>>
>> None - this is a very simple change and aligns us with what other
>> browsers are shipping.
>>
>> TAG review status
>>
>> Not applicable
>>
>> Risks
>>
>> Interoperability and Compatibility
>>
>> None
>>
>>
>> Gecko: No signal (Firefox on iOS already follows this pattern)
>>
>> WebKit: No signal (mobile Safari already follows this pattern)
>>
>> Web developers: We have received at least one external partner request
>> for this change.
>>
>>
>> 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 (this is for iOS)
>>
>>
>> Debuggability
>>
>> None
>>
>>
>> Is this feature fully tested by web-platform-tests
>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>> ?
>>
>> No
>>
>> Flag name on chrome://flags
>>
>> None
>>
>> Finch feature name
>>
>> kAddBugFixNumber
>>
>> Non-finch justification
>>
>> None
>>
>> Requires code in //chrome?
>>
>> False
>>
>> Tracking bug
>>
>> https://issues.chromium.org/u/1/issues/350426233
>>
>> Estimated milestones
>>
>> No milestones specified
>>
>>
>> Link to entry on the Chrome Platform Status
>>
>> https://chromestatus.com/feature/5084885065400320?gate=5184007944536064
>>
>> --
>> 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/01a6fedf-3b5a-4254-9bcd-2672d4cfec19n%40chromium.org
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/01a6fedf-3b5a-4254-9bcd-2672d4cfec19n%40chromium.org?utm_medium=email&utm_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSKeZ8nZp%3D310CuYm35S0xrZ%3DZS0SWteHdgGw550vN6J_w%40mail.gmail.com.

[blink-dev] Re: Intent to Experiment: Incorporating navigation initiator into the HTTP cache partition key

[Yoav Weiss (@Shopify)]

I'd love to better understand the attack scenario.

On Friday, September 6, 2024 at 5:40:55 AM UTC+2 Andrew Williams wrote:

Contact emails

miketa...@chromium.org, awil...@chromium.org

Explainer

None yet.

Specification

https://fetch.spec.whatwg.org/#http-cache-partitions

Summary

We aim to experiment with utilizing the initiator site when caching the 
responses of cross-site navigations in the HTTP cache. This experiment is 
intended to test a potential mitigation for cross-site leak attacks in 
which an attacker can initiate a top-level navigation to a given page and 
then navigate to a resource known to be loaded by the page in order to 
infer sensitive information via load timing. 


bad.com navigates the user to victim.com (at the top-level??). What happens 
then? 

The tested mitigation is also intended as a privacy improvement since it 
will make it more difficult for a malicious site to use navigations to 
infer whether a user has visited a given site previously.


But if one site navigated to another, it doesn't get any timing info about 
the "navigated to" site, right?
  


Blink component

Internals>Network>Cache 


TAG review

Not requested yet.

Risks
Interoperability and Compatibility

We do not expect compatibility impacts here, but there may be some 
performance implications. Safari and Firefox currently ship some notion of 
partitioned HTTP caches. We will seek their input once we have a better 
idea of the tradeoffs between security/privacy and performance.

Gecko: No signal requested yet.

WebKit: No signal requested yet.

Web developers: No 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?

No

Goals for experimentation

We would like to run a 1% stable experiment to understand the performance 
implications of several approaches to implementing this HTTP cache security 
improvement. We expect 6 weeks to be sufficient for analysis, beginning in 
M129, but are requesting permission to run from M129 to M131 inclusive in 
case we run into any delays.

The approaches we’d like to experiment with are:

   - 
   
   Adding a boolean value to the HTTP cache key that is set to true for 
   top-level navigations to a URL that is cross-site from the initiator site 
   of the navigation
   


   - 
   
   Adding the initiator site into the HTTP cache key for top-level 
   navigations to a URL that is cross-site from the initiator site of the 
   navigation. If the initiator has an opaque origin (for instance, if the 
   initiating page was loaded from a data: URL or is a sandboxed iframe) then 
   no caching of the navigation response will occur.
   
   - 
   
   Adding the initiator site into the HTTP cache key for all navigations 
   (including subframe navigations) in the same way as the previous approach. 
   With this scheme we’d also replace use of an existing HTTP cache key 
   component (called the “is-subframe-document-resource” boolean, set to 
   true for all subframe navigations) designed to mitigate related attacks 
   from malicious subframes. This scheme is expected to have similar 
   performance characteristics to the previous approach but would make 
   Chromium’s handling of main frame and subframe navigations consistent.
   

Incorporating the initiator into the HTTP cache key will mean that the 
responses from renderer-initiated navigations will not be re-used across 
contexts with different frame sites or top-frame sites. This could affect 
the page load times for previously visited sites in cases where loading a 
page over the network is slower than loading the page from the local disk 
cache. Renderer-initiated navigations corresponding to, for example, 
clicking links on a site, site redirects, and link prefetches that use 
“as=’document’”. Incorporating the ‘is-cross-site-top-level-navigation’ 
boolean is expected to have the least impact on performance since it allows 
the most amount of response re-use. Incorporating the full initiator site 
is expected to have the most impact since there is less re-use with these 
cache partitioning schemes, but this approach may enable future HTTP cache 
performance optimizations that are not possible today due to cross-site 
leak risks.

Debuggability

No special needs.

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

No

All except WebView, which does not currently partition its HTTP cache.

Is this feature fully tested by web-platform-tests 

?

No

Flag name on chrome://flags

None

Finch feature name

There are several feature flags, one per experiment partition key format:

   - 
   
   SplitCacheByCrossSiteMainFrameNavigationBoolean - Ena

Re: [blink-dev] Intent to Ship: Add bugfix version number to User-Agent string on Bling

[Yoav Weiss (@Shopify)]

LGTM

On Wed, Aug 28, 2024 at 9:53 PM Janice Liu  wrote:

> Contact emails
>
> janice...@chromium.org, miketa...@chromium.org
>
> Explainer
>
> None. This is a minor change.
>
> Specification
>
> https://www.rfc-editor.org/rfc/rfc9110#field.user-agent
>
> Summary
>
> User Agent (UA) strings in Chromium have been moving towards reducing or
> freezing information - but until WebKit allows us to implement UA client
> hints,
>
:(


> we propose adding the OS bugfix number to the UA, for compatibility
> purposes.
>
>
> Blink component
>
> Chromium>Mobile>iOSWeb
> 
>
> Motivation
>
> The Chrome for iOS User-Agent header only includes the major and minor
> version numbers, while Safari and Firefox for iOS include the major, minor,
> and bugfix numbers. We have received a request from external partners to
> match this pattern, and are aware of at least one platform that relies on
> having an accurate bugfix version number to ensure the latest security
> updates are installed.
>
> UA strings in Chromium have been moving towards reducing or freezing
> information - but until WebKit allows us to implement UA client hints, we
> propose adding the bugfix number to the UA, for compatibility purposes.
>
> In practice:
>
> Before this change: Mozilla/5.0 (iPhone; CPU iPhone OS 17_5 like Mac OS X)
>
> AppleWebKit/602.1.50 (KHTML, like Gecko) CriOS/123.0.2924.75
>
> Mobile/14E5239e Safari/602.1
>
>
> After this change (note the additional “_1” in the OS version token):
> Mozilla/5.0 (iPhone; CPU iPhone OS 17_5_1 like Mac OS X)
>
> AppleWebKit/602.1.50 (KHTML, like Gecko) CriOS/123.0.2924.75
>
> Mobile/14E5239e Safari/602.1
>
>
>
> Initial public proposal
>
> None
>
> TAG review
>
> None - this is a very simple change and aligns us with what other browsers
> are shipping.
>
> TAG review status
>
> Not applicable
>
> Risks
>
> Interoperability and Compatibility
>
> None
>
>
> Gecko: No signal (Firefox on iOS already follows this pattern)
>
> WebKit: No signal (mobile Safari already follows this pattern)
>
> Web developers: We have received at least one external partner request
> for this change.
>
>
> 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 (this is for iOS)
>
>
> Debuggability
>
> None
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?
>
> No
>
> Flag name on chrome://flags
>
> None
>
> Finch feature name
>
> kAddBugFixNumber
>
> Non-finch justification
>
> None
>
> Requires code in //chrome?
>
> False
>
> Tracking bug
>
> https://issues.chromium.org/u/1/issues/350426233
>
> Estimated milestones
>
> No milestones specified
>
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5084885065400320?gate=5184007944536064
>
> --
> 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/01a6fedf-3b5a-4254-9bcd-2672d4cfec19n%40chromium.org
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohS%2BbafuZ6d%2BgPKD0R1JVV4kxag8FBTP-EJTG%2BQOQ3wxq%2BA%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: @property support syntax

[Yoav Weiss (@Shopify)]

On Tuesday, September 10, 2024 at 5:08:33 PM UTC+2 Mike Taylor wrote:

LGTM1
On 9/5/24 8:40 AM, 'Munira Tursunova' via blink-dev wrote:

This is also the case for registerProperty(), right?


Right, thanks!

On Thu, Sep 5, 2024 at 2:20 PM Rune Lillesveen  wrote:

On Thu, Sep 5, 2024 at 1:44 PM Chromestatus  
wrote:

Contact emails moon...@google.com, andr...@chromium.org 

Explainer None 

Specification https://drafts.css-houdini.org/css-properties-values-api-
1/#supported-names

The link is 504ing on me. Any alternative path? 



Summary 

Support for "" syntax component name in @property.

This is also the case for registerProperty(), right?

-- 
Rune Lillesveen

-- 
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/CAAO7W_BcN%3Djo2yVEu8w93RXgTqOms%
3DQMVY63NkOdDpR70Q_RMA%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/a27cb5f0-45e2-478e-9170-f382ed1391b0n%40chromium.org.

[blink-dev] Re: Intent to Prototype & Ship: Private State Token API Permissions Policy Default Allowlist Wildcard

[Yoav Weiss (@Shopify)]

Could you flip the required review bits in the chromestatus tool?

On Monday, September 9, 2024 at 2:58:19 PM UTC+2 Ari Chivukula wrote:

> Contact emails
>
> aric...@chromium.org, kaustub...@chromium.org, sval...@chromium.org, 
> ayk...@google.com, nick...@google.com
>
> Specification
>
> https://github.com/WICG/trust-token-api/pull/306
>
> Summary
>
> Access to the Private State Token API 
>  is gated by Permissions Policy 
>  features. We proposed to 
> update the default allowlist 
> 
>  
> for both `private-state-token-issuance 
> `
>  
> and `private-state-token-redemption 
> `
>  
> features from self to * (wildcard).
>
>
> Blink component
>
> Blink>StorageAccessAPI 
> 
>
>
> Motivation
>
> The Private State Tokens API  
> has received recurring feedback from developers 
>  that the current 
> requirement to have first-party sites opt-in to allow third-parties to 
> invoke token issuance and redemption operations is not practical. This is 
> especially true for use cases where embeds don’t have first-party script 
> access to either execute the operations directly in first-party context, or 
> to enable the permission policies on the relevant frames. Current default 
> requires every site to update permission policy for iframes that embed 
> invalid traffic (IVT) detection scripts.Since scale and coverage are of 
> essence for IVT detection that rely on identifying outlier patterns; the 
> need for coordination with first-parties places a high cost for successful 
> adoption.
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/990
>
> Compatibility
>
> This will not break any existing Private State Token API usage as it only 
> increases permissiveness. As usage increases, sites may need to consider 
> the need to mitigate issuer exhaustion 
> .
>
> Competing scripts might race to call hasPrivateToken to ensure their 
> preferred issuer enters the issuerAssociations 
>  map 
>  before the issuer of others 
> given a limit of two per top-level origin 
> .
>  
> To control this process, the top-level origin 
> 
>  
> could call hasPrivateToken up to twice before any other JavaScript is 
> included to ensure their preferred issuers are available.
>
> Few enough websites 
>  are 
> using the API that we believe we can broaden the default permission set and 
> not open any concerning new avenues of attack.
>
>
> Interoperability
>
> Gecko: Position Requested 
> 
>
> WebKit: Position Requested 
> 
>
> Web developers: Positive 
> 
>
> Debuggability
>
> Storage written can be examined in devtools.
>
> Is this feature fully tested by web-platform-tests?
>
> Yes 
> 
>
> Tracking bug
>
> https://issues.chromium.org/353738486
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5205548434456576
>
>

-- 
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/27d1a149-24a0-4ca3-91ad-96f6e065466cn%40chromium.org.

Re: [blink-dev] Intent to Deprecate and Remove: Remove non-standard GPUAdapter requestAdapterInfo() method

[Yoav Weiss (@Shopify)]

OK, LGTM1 then :D

On Tue, Sep 10, 2024 at 2:01 PM François Beaufort 
wrote:

> I've checked with a Chromium build that removes the requestAdapterInfo()
> method and the websites I've tried are not broken.
> The content of the string sent for analytics is simply different but the
> POST request still happens properly.
>
> On Tue, Sep 10, 2024 at 12:32 PM Yoav Weiss (@Shopify) <
> yoavwe...@chromium.org> wrote:
>
>> Wait, I was a bit quick on that LGTM (excited about the removal in
>> WebKit, I guess).
>> You're saying that our latest data is that this API is used in 0.41% of
>> requests. What happens to that usage (which seems concentrated to a few 3P
>> scripts) when the API is removed? What does breakage in practice look like?
>>
>> On Tuesday, September 10, 2024 at 12:29:16 PM UTC+2 Yoav Weiss wrote:
>>
>>> LGTM1
>>>
>>> On Tuesday, September 10, 2024 at 8:55:36 AM UTC+2 François Beaufort
>>> wrote:
>>>
>>>> https://github.com/gpuweb/gpuweb/pull/4662#issuecomment-2338982367
>>>> indicates they have just removed it in WebKit as expected.
>>>>
>>>>
>>>> On Mon, Sep 9, 2024 at 5:48 PM François Beaufort 
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Mon, Sep 9, 2024 at 5:47 PM Mike Taylor 
>>>>> wrote:
>>>>>
>>>>>> On 9/9/24 11:45 AM, François Beaufort wrote:
>>>>>>
>>>>>> On Mon, Sep 9, 2024 at 5:39 PM Mike Taylor 
>>>>>> wrote:
>>>>>>
>>>>>>> On 9/9/24 10:38 AM, 'François Beaufort' via blink-dev wrote:
>>>>>>>
>>>>>>> Contact emails fbeauf...@google.com
>>>>>>>
>>>>>>> Explainer None
>>>>>>>
>>>>>>> Specification https://gpuweb.github.io/gpuweb/#dom-gpuadapter-info
>>>>>>>
>>>>>>> Summary
>>>>>>>
>>>>>>> The WebGPU WG decided it was impractical for requestAdapterInfo() to
>>>>>>> trigger a permission prompt so they’ve removed that option and replaced 
>>>>>>> it
>>>>>>> with the GPUAdapter info attribute so that web developers can get the 
>>>>>>> same
>>>>>>> GPUAdapterInfo value synchronously this time. See the previous intent to
>>>>>>> ship at
>>>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/eZqMmX7q_bA/m/euMLVMpxAgAJ
>>>>>>>
>>>>>>>
>>>>>>> Blink component Blink>WebGPU
>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EWebGPU>
>>>>>>>
>>>>>>> Motivation
>>>>>>>
>>>>>>> The requestAdapterInfo() asynchronous method in WebGPU is redundant
>>>>>>> because developers can already get GPUAdapterInfo synchronously using 
>>>>>>> the
>>>>>>> GPUAdapter info attribute. Hence, it should be removed.
>>>>>>>
>>>>>>> A search for the string "requestAdapterInfo" in HTTPArchive yielded
>>>>>>> no results.
>>>>>>>
>>>>>>> According to
>>>>>>> https://chromestatus.com/metrics/feature/timeline/popularity/4977,
>>>>>>> the requestAdapterInfo() method accounted for approximately 0.41% of 
>>>>>>> page
>>>>>>> loads in September 2024.
>>>>>>>
>>>>>>> Chrome UKMs helped us in identifying the most popular websites using
>>>>>>> the WebGPU requestAdapterInfo() method: - Twitch: The team has been
>>>>>>> contacted and has indicated that they will update their code. - 
>>>>>>> Dynatrace:
>>>>>>> Used by the vast majority of those websites for analytics, they have 
>>>>>>> been
>>>>>>> made aware of this deprecation.
>>>>>>>
>>>>>>>
>>>>>>> Initial public proposal None
>>>>>>>
>>>>>>> TAG review None
>>>>>>>
>>>>>>> TAG review status Not applicable
>>>>>>>
>>>>>>> Risks
>>>>>>>
>>>>>>>
>>>>>&

Re: [blink-dev] Intent to Deprecate and Remove: Remove non-standard GPUAdapter requestAdapterInfo() method

[Yoav Weiss (@Shopify)]

Wait, I was a bit quick on that LGTM (excited about the removal in WebKit, 
I guess).
You're saying that our latest data is that this API is used in 0.41% of 
requests. What happens to that usage (which seems concentrated to a few 3P 
scripts) when the API is removed? What does breakage in practice look like?

On Tuesday, September 10, 2024 at 12:29:16 PM UTC+2 Yoav Weiss wrote:

> LGTM1
>
> On Tuesday, September 10, 2024 at 8:55:36 AM UTC+2 François Beaufort wrote:
>
>> https://github.com/gpuweb/gpuweb/pull/4662#issuecomment-2338982367 
>> indicates they have just removed it in WebKit as expected.
>>
>>
>> On Mon, Sep 9, 2024 at 5:48 PM François Beaufort  
>> wrote:
>>
>>>
>>>
>>> On Mon, Sep 9, 2024 at 5:47 PM Mike Taylor  
>>> wrote:
>>>
 On 9/9/24 11:45 AM, François Beaufort wrote:

 On Mon, Sep 9, 2024 at 5:39 PM Mike Taylor  
 wrote:

> On 9/9/24 10:38 AM, 'François Beaufort' via blink-dev wrote:
>
> Contact emails fbeauf...@google.com
>
> Explainer None
>
> Specification https://gpuweb.github.io/gpuweb/#dom-gpuadapter-info
>
> Summary 
>
> The WebGPU WG decided it was impractical for requestAdapterInfo() to 
> trigger a permission prompt so they’ve removed that option and replaced 
> it 
> with the GPUAdapter info attribute so that web developers can get the 
> same 
> GPUAdapterInfo value synchronously this time. See the previous intent to 
> ship at 
> https://groups.google.com/a/chromium.org/g/blink-dev/c/eZqMmX7q_bA/m/euMLVMpxAgAJ
>  
>
>
> Blink component Blink>WebGPU 
> 
>
> Motivation 
>
> The requestAdapterInfo() asynchronous method in WebGPU is redundant 
> because developers can already get GPUAdapterInfo synchronously using the 
> GPUAdapter info attribute. Hence, it should be removed.
>
> A search for the string "requestAdapterInfo" in HTTPArchive yielded no 
> results. 
>
> According to 
> https://chromestatus.com/metrics/feature/timeline/popularity/4977, 
> the requestAdapterInfo() method accounted for approximately 0.41% of page 
> loads in September 2024. 
>
> Chrome UKMs helped us in identifying the most popular websites using 
> the WebGPU requestAdapterInfo() method: - Twitch: The team has been 
> contacted and has indicated that they will update their code. - 
> Dynatrace: 
> Used by the vast majority of those websites for analytics, they have been 
> made aware of this deprecation.
>
>
> Initial public proposal None
>
> TAG review None
>
> TAG review status Not applicable
>
> Risks 
>
>
> Interoperability and Compatibility 
>
> When WebGPU eventually launches in Safari and Firefox, websites will 
> be able to get GPUAdapterInfo values exclusively through the standardized 
> GPUAdapter info attribute. We anticipate Safari and Firefox will soon 
> support WebGPU, but won't include this non-standard method. Therefore, 
> the 
> sooner Chromium implements the Deprecate and Remove process, the less 
> likely it is that content will work in Chromium but not in other 
> browsers. 
> In Chromium-based browsers, as the requestAdapterInfo() asynchronous 
> method 
> returned a promise, websites that followed best practices were already 
> catching rejected promises. Web developers have been made aware of this 
> change in July 2024 at 
> https://developer.chrome.com/blog/new-in-webgpu-127?hl=en#gpuadapter_info_attribute.
>  
> They can use the following one-line code during the transition period: 
> const info = adapter.info || await adapter.requestAdapterInfo();
>
> I know that WebKit !== Safari, but I do see they have 
> requestAdapterInfo 
> 
>  
> today. Do we have any sense of what their plans are there (maybe a 
> standards position could clarify that)?
>

 As you can see in 
 https://github.com/gpuweb/gpuweb/pull/4662#issuecomment-2141279713, 
 they re-added temporarily requestAdapterInfo() at the time to avoid 
 breaking websites that didn't make the move yet.
 FYI, I've updated Apache TVM used by WebLLM to use adapter.info in 
 apache/tvm#17051 .

 Cool - does that mean WebKit is willing to remove it now (or shortly 
 after we do)?

>>>
>>> I believe they do but I'll let them respond to that: 
>>> https://github.com/gpuweb/gpuweb/pull/4662#issuecomment-2338474559 
>>>

>
> *Gecko*: No signal
>
> *WebKit*: No signal
>
> *Web developers*: No signals
>
> *Other signals*:
>
> WebView application risks 
>

Re: [blink-dev] Intent to Deprecate and Remove: Remove non-standard GPUAdapter requestAdapterInfo() method

[Yoav Weiss (@Shopify)]

LGTM1

On Tuesday, September 10, 2024 at 8:55:36 AM UTC+2 François Beaufort wrote:

> https://github.com/gpuweb/gpuweb/pull/4662#issuecomment-2338982367 
> indicates they have just removed it in WebKit as expected.
>
>
> On Mon, Sep 9, 2024 at 5:48 PM François Beaufort  
> wrote:
>
>>
>>
>> On Mon, Sep 9, 2024 at 5:47 PM Mike Taylor  
>> wrote:
>>
>>> On 9/9/24 11:45 AM, François Beaufort wrote:
>>>
>>> On Mon, Sep 9, 2024 at 5:39 PM Mike Taylor  
>>> wrote:
>>>
 On 9/9/24 10:38 AM, 'François Beaufort' via blink-dev wrote:

 Contact emails fbeauf...@google.com

 Explainer None

 Specification https://gpuweb.github.io/gpuweb/#dom-gpuadapter-info

 Summary 

 The WebGPU WG decided it was impractical for requestAdapterInfo() to 
 trigger a permission prompt so they’ve removed that option and replaced it 
 with the GPUAdapter info attribute so that web developers can get the same 
 GPUAdapterInfo value synchronously this time. See the previous intent to 
 ship at 
 https://groups.google.com/a/chromium.org/g/blink-dev/c/eZqMmX7q_bA/m/euMLVMpxAgAJ
  


 Blink component Blink>WebGPU 
 

 Motivation 

 The requestAdapterInfo() asynchronous method in WebGPU is redundant 
 because developers can already get GPUAdapterInfo synchronously using the 
 GPUAdapter info attribute. Hence, it should be removed.

 A search for the string "requestAdapterInfo" in HTTPArchive yielded no 
 results. 

 According to 
 https://chromestatus.com/metrics/feature/timeline/popularity/4977, the 
 requestAdapterInfo() method accounted for approximately 0.41% of page 
 loads 
 in September 2024. 

 Chrome UKMs helped us in identifying the most popular websites using 
 the WebGPU requestAdapterInfo() method: - Twitch: The team has been 
 contacted and has indicated that they will update their code. - Dynatrace: 
 Used by the vast majority of those websites for analytics, they have been 
 made aware of this deprecation.


 Initial public proposal None

 TAG review None

 TAG review status Not applicable

 Risks 


 Interoperability and Compatibility 

 When WebGPU eventually launches in Safari and Firefox, websites will be 
 able to get GPUAdapterInfo values exclusively through the standardized 
 GPUAdapter info attribute. We anticipate Safari and Firefox will soon 
 support WebGPU, but won't include this non-standard method. Therefore, the 
 sooner Chromium implements the Deprecate and Remove process, the less 
 likely it is that content will work in Chromium but not in other browsers. 
 In Chromium-based browsers, as the requestAdapterInfo() asynchronous 
 method 
 returned a promise, websites that followed best practices were already 
 catching rejected promises. Web developers have been made aware of this 
 change in July 2024 at 
 https://developer.chrome.com/blog/new-in-webgpu-127?hl=en#gpuadapter_info_attribute.
  
 They can use the following one-line code during the transition period: 
 const info = adapter.info || await adapter.requestAdapterInfo();

 I know that WebKit !== Safari, but I do see they have 
 requestAdapterInfo 
 
  
 today. Do we have any sense of what their plans are there (maybe a 
 standards position could clarify that)?

>>>
>>> As you can see in 
>>> https://github.com/gpuweb/gpuweb/pull/4662#issuecomment-2141279713, 
>>> they re-added temporarily requestAdapterInfo() at the time to avoid 
>>> breaking websites that didn't make the move yet.
>>> FYI, I've updated Apache TVM used by WebLLM to use adapter.info in 
>>> apache/tvm#17051 .
>>>
>>> Cool - does that mean WebKit is willing to remove it now (or shortly 
>>> after we do)?
>>>
>>
>> I believe they do but I'll let them respond to that: 
>> https://github.com/gpuweb/gpuweb/pull/4662#issuecomment-2338474559 
>>
>>>

 *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


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

 Flag name on chrome://flags None

 Finch feature name None

 Non-finch justification None

 Requires code in //chrome? Fal

Re: [blink-dev] Intent to Ship: Dynamic safe area insets

[Yoav Weiss (@Shopify)]

The design doc doesn't give a lot of background. Can you provide a short
explanation or an inline explainer as to what this is trying to solve and
how we think developers will be using this? Thanks! :)

On Fri, Aug 30, 2024 at 7:10 PM Wenyu Fu  wrote:

> > The work isn't being done by the team which owns Blink>CSS so it would
> be good if there were experts which could triage incoming bugs, etc in this
> area.
>
> Good callout! I can't seem to find an appropriate component for this
> feature, thus I choose the closest. During development I've been closely
> working with owners from Blink>CSS (futhark@) and I think this still fits
> the CSS area.
>
> FWIW I think we could still create the Blink>CSS>SafeArea component
>
> > make public access to the indicated document?
>
> Sorry for the inconvenience. The original doc is associated with my google
> account, and I have trouble sharing it to the public.
> I've made a public copy:
> https://docs.google.com/document/d/1VL0KNzdQwATk9Uf8kP0kcbO1-dDx86pPvB_bMQdLLHE/edit
>
> On Thu, Aug 29, 2024 at 11:53 PM uazo  wrote:
>
>> > Design docs
>>
>> could you make public access to the indicated document?
>>
>> thank you!
>>
>> On Thursday, August 29, 2024 at 9:09:17 PM UTC+2 ikilp...@chromium.org
>> wrote:
>>
>>> On Thu, Aug 29, 2024 at 12:00 PM Wenyu Fu  wrote:
>>>
 Contact emailswen...@chromium.org, wen...@google.com

 ExplainerNone

 Specificationhttps://developer.mozilla.org/en-US/docs/Web/CSS/env

 Design docs

 https://docs.google.com/document/d/1Wg8M-tkeo7_JDRYVV2vB22pAPQMYXuJ2Ik-fmqn-plg/edit?tab=t.0

 Summary

 Dynamically change the safe area inset based on the shown ration for
 the browser controls. This is used when to keep the web contents from the
 display cutout area when Chrome is drawing edge to edge. This feature is
 targeting Android only. Similar browser behavior is already available for
 Chrome on iOS and Safari Mobile. Detailed design & implementation, please
 see crbug.com/324436581


 Blink componentBlink>CSS
 


>>> Could we create a new Blink component for the env(safe-area-*)
>>> implementation? (Maybe Blink>SafeArea).
>>>
>>> The work isn't being done by the team which owns Blink>CSS so it would
>>> be good if there were experts which could triage incoming bugs, etc in this
>>> area.
>>>
>>>
 Search tagssafearea 

 TAG reviewNone

 TAG review statusNot 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?

 No specific behavior changes to API, no impact to WebView.


 Debuggability

 None


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

 Android only - feature targeting OS with a browser controls.


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

 Flag name on chrome://flagsdynamic-safe-area-insets,
 dynamic-safe-area-insets-on-scroll

 Finch feature nameDynamicSafeAreaInsets, DynamicSafeAreaInsetsOnScroll

 Requires code in //chrome?False

 Tracking bughttps://g-issues.chromium.org/issues/324436581

 Launch bughttps://launch.corp.google.com/launch/4339772

 MeasurementNo specific measurement on web platform. This success will
 be measured together with https://launch.corp.google.com/launch/4339772

 Availability expectationFeature is already available on Safari, and is
 implemented to make available on Chrome on Android.

 Adoption expectationNo change is required from web developer.

 Adoption planNo changes needed from the developer.

 Non-OSS dependencies

 Does the feature depend on any code or APIs outside the Chromium open
 source repository and its open-source dependencies to function?
 No

 Sample links

 https://screencast.googleplex.com/cast/NTMyMTc4MzcyODE0NDM4NHxmOGViYjdmMC1iZg

 Estimated milestones
 Shipping on Android 129

 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 struc

Re: [blink-dev] Intent to Ship: Full and unprefixed box-decoration-break support

[Yoav Weiss (@Shopify)]

LGTM3

On Wednesday, September 4, 2024 at 5:56:10 PM UTC+2 Daniel Bratell wrote:

> LGTM2
>
> /Daniel
> On 2024-09-04 17:53, Chris Harrelson wrote:
>
> LGTM1
>
> On Wed, Sep 4, 2024 at 2:42 AM Chromestatus <
> ad...@cr-status.appspotmail.com> wrote:
>
>> Contact emails msten...@chromium.org 
>>
>> Explainer None 
>>
>> Specification https://www.w3.org/TR/css-break-3/#break-decoration 
>>
>> Summary 
>>
>> Support box-decoration-break:clone both for inline fragmentation (line 
>> layout) and block fragmentation (pagination for printing, multicol). 
>> Traditionally in Blink, only box-decoration-break:slice (the initial value) 
>> has been supported for block fragmentation, whereas for inline 
>> fragmentation, box-decoration-break:clone was also supported, but only when 
>> using the prefixed -webkit-box-decoration-break property. See 
>> https://drafts.csswg.org/css-break/#break-decoration
>>
>>
>> Blink component Blink>Layout 
>> 
>>  
>>
>> TAG review None 
>>
>> TAG review status Not applicable 
>>
>> Risks 
>>
>>
>> Interoperability and Compatibility 
>>
>> Low.
>>
>>
>> *Gecko*: Shipped/Shipping 
>>
>> *WebKit*: No signal (
>> https://github.com/WebKit/standards-positions/issues/366) Currently 
>> WebKit and Blink only support -webkit-box-decoration-break, and only for 
>> inline fragmentation (i.e. no block fragmentation). 
>>
>> *Web developers*: No signals (https://issues.chromium.org/issues/40415661) 
>>
>>
>> *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 
>> 
>> ? Yes 
>>
>> Flag name on chrome://flags 
>>
>> Finch feature name BoxDecorationBreak 
>>
>> Requires code in //chrome? False 
>>
>> Tracking bug https://issues.chromium.org/issues/41295617 
>>
>> Estimated milestones 
>> Shipping on desktop 130 
>> DevTrial on desktop 129 
>> Shipping on Android 130 
>> DevTrial on Android 129 
>> Shipping on WebView 130 
>>
>> 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/5162398704205824?gate=6467793951391744 
>>
>> Links to previous Intent discussions Intent to Prototype: 
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKWZFm4fXc%3D%2BF68yXQ41-V8seHYj%2BjKT4VLNhCgyz7V_feZGBQ%40mail.gmail.com
>>  
>>
>>
>> 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/12c165062147fe77%40google.com
>>  
>> 
>> .
>>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to blink-dev+unsubscr...@chromium.org.
>
> To view this discussion on the web visit 
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8fFNrTKO%3DZnf_mtbEpW979Qzk22KPhVP_HTammnbdt1g%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/6e2109d7-c691-4793-a8a1-3bfe67132073n%40chromium.org.

Re: [blink-dev] Re: Intent to Ship: Protected Audience: Real Time Monitoring API

[Yoav Weiss (@Shopify)]

LGTM1

On Thursday, August 29, 2024 at 4:13:36 PM UTC+2 Paul Jensen wrote:

> Those open items are now addressed (by 
> https://github.com/WICG/turtledove/pull/1246 and 
> https://github.com/WICG/turtledove/pull/1253).
>
> On Thu, Aug 8, 2024 at 2:52 PM Chris Harrelson  
> wrote:
>
>> Hi,
>>
>> I see that there are a couple of open items on the spec (mentioned here 
>> ), 
>> should we wait for those to resolve?
>>
>> On Thu, Aug 8, 2024 at 11:32 AM Paul Jensen  
>> wrote:
>>
>>> We also extended our feature detection API to facilitate detecting this 
>>> feature:
>>> Explainer: https://github.com/WICG/turtledove/pull/1238
>>> Spec: https://github.com/WICG/turtledove/pull/1245
>>> On Wednesday, July 31, 2024 at 12:51:08 PM UTC-4 Paul Jensen wrote:
>>>
 Contact emails

 pauljen...@chromium.org


 Explainer

 https://github.com/WICG/turtledove/blob/main/PA_real_time_monitoring.md


 Specification

 https://github.com/WICG/turtledove/pull/1212


 Summary

 The goal of real-time monitoring is to get Protected Audience API 
 auction monitoring data to the buyer and seller as quickly as possible 
 (e.g. < 5 mins). The primary use-case we are trying to capture with this 
 reporting surface, the Protected Audience Real Time Monitoring (RTM) API, 
 is rapid error detection i.e. detecting quickly whether there are major 
 problems with unexpected behavior in generateBid(), scoreAd(), or loading 
 of bidding or scoring scripts or trusted signals. To offer reduced latency 
 over other reporting mechanisms like the Private Aggregation API, the RTM 
 API uses the local differentially private RAPPOR algorithm with an epsilon 
 of one.  The reduced latency is traded off for a limited number of 
 histogram buckets and significant noise.


 Blink component

 Blink>InterestGroups 
 


 TAG review

 For Protected Audience: 
 https://github.com/w3ctag/design-reviews/issues/723


 TAG review status

 Completed for Protected Audience, resolved unsatisfied.


 RisksPrivacy

 At the epsilon we are proposing (𝜖 = 1), the information leaked is 
 limited to approximately 0.18 bits per auction. This makes it very 
 difficult for a bad actor to gain any meaningful user identifying 
 information from an auction using this API.

 While the tight privacy parameters provide strong protections, there 
 are two privacy considerations of note:

- 

It reveals a small amount of information from scoreAd and 
generateBid to sellers and bidders, respectively. These contents are 
protected by the locally differentially private RAPPOR algorithm. The 
 scope 
of this risk can be measured with the privacy loss epsilon parameter. 
 This 
risk could be magnified by a bad actor running many auctions solely for 
 the 
purpose of collecting more information from a publisher page. We 
 mitigate 
this risk by bounding the number of contributions that this API will 
 send 
to an adtech from a page in a given period of time for each browser.
- 

It reveals to the ad tech the fact that it had an interest group 
present on the device. This is mitigated by the fact that the reports 
 are 
sent to a fixed path and include only heavily noised signals. We also 
considered sending reports to all eligible auction participants for 
a given auction (i.e. all those present in interestGroupBuyers, even if 
they do not have interest groups), but this will result in an 
 overwhelming 
number of reports sent.

 We plan to address both these considerations in future work 
 
 .
 Interoperability and Compatibility

 This feature represents optional new behavior that shouldn’t break 
 existing usage.


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


 Edge: Edge has announced plans to support the Ad Selection API 
  
 which shares much of its API surface with Protected Audience.


 Web developers: Interest from 5 companies on GitHub issue 
  and significant 
 interest on WICG call discussion 
 

[blink-dev] Re: Intent to Ship: Shared Storage: Allowing Cross-Origin Script in addModule & Aligning createWorklet

[Yoav Weiss (@Shopify)]

LGTM2

On Wednesday, September 4, 2024 at 5:07:54 AM UTC+2 Domenic Denicola wrote:

> LGTM1. This seems like a good change for overall web consistency, and 
> compat risks seem well-managed.
>
> On Thursday, August 29, 2024 at 4:32:20 AM UTC+9 Cammie Smith Barnes wrote:
>
>> Intent to Ship: Shared Storage: Allowing Cross-Origin Script in addModule 
>> & Aligning createWorklet
>>
>> Contact emailscam...@chromium.org, jkar...@chromium.org, 
>> yao...@chromium.org, ashame...@google.com
>> Explainerhttps://github.com/WICG/shared-storage/blob/main/README.md
>> Specificationhttps://github.com/WICG/shared-storage/pull/161
>> SummaryWe now allow sharedStorage.worklet.addModule to load cross-origin 
>> script, while still using the invoking context's origin as the data 
>> partition origin for accessing shared storage data. We also align the 
>> behavior of sharedStorage.createWorklet, so that when it loads a 
>> cross-origin script, it also uses the invoking context's origin as the data 
>> partition origin by default (instead of using the script origin as it did 
>> when initially implemented). Finally, to preserve the ability to use the 
>> script's origin as the data partition origin, we introduce a new dataOrigin 
>> option for createWorklet.
>> We have received feedback from developers stating they wanted to be able 
>> to host and run their worklet script on a separate origin from the origin 
>> that owns and writes their shared storage data. So we remove the 
>> same-origin restriction for addModule. Note that, when the worklet script 
>> is cross-origin to the invoking context, the invoking context's origin is 
>> used as the partition origin for accessing shared storage.
>> To help avoid developer confusion in the long term, we align the default 
>> behavior of createWorklet to use the invoking context's origin instead of 
>> the script origin as its data partition origin. This is a breaking change, 
>> but current usage of createWorklet is low as it was introduced in M125 and 
>> those that are using it have upgraded to a forward-compatible incantation. 
>> We also introduce a dataOrigin option that can be passed to use the 
>> previous behavior.
>>
>> Blink componentBlink>Storage>SharedStorage 
>> 
>> TAG review & statusNotification of the change is here 
>> 
>>  
>> but not expecting feedback as the entire Shared Storage feature is resolved 
>> as unsatisfied.
>>
>> Risks
>>
>> Interoperability and CompatibilityThere are no interop risks as no other 
>> browser has implemented shared storage. There is a compat risk for the 
>> recently released createWorklet API. The worklet created by createWorklet 
>> before this change had the data partition of the script’s origin. We’re 
>> changing it, to align with addModule, to use the calling context’s origin 
>> instead. We’re monitoring usage here 
>>  of 
>> the backwards-incompatible usage of the existing API and reaching out to 
>> folks using it to let them know that they should make the following 
>> forward-compatible change if they want the existing default behavior of 
>> createWorklet to continue to function after this change:
>> before: sharedStorage.createWorklet(worklet_url);after: 
>> sharedStorage.createWorklet(worklet_url, { dataOrigin: “script-origin” });
>> The dataOrigin option will be ignored on browsers previous to this 
>> change, and honored correctly after. 
>> As of today, all users have switched to the forward-compatible incantation. 
>> We are also monitoring usage of addModule with scripts that are 
>> cross-origin to the calling context here 
>> , as 
>> those will suddenly work when they did not before which could be surprising 
>> to developers. As anticipated, this usage is extremely low (.1% page 
>> loads).
>>
>> Gecko: Negative on shared storage
>> WebKit: Negative on shared storage
>> Web developers: Positive, but there is follow-up work to allow 
>> createWorklet() to serve the script from a different origin than the data 
>> origin which is what folks ultimately want. That change will be 
>> non-breaking. This work is a first step in that direction (allowing 
>> addModule to be cross-origin).
>> Other signals:
>> WebView application risksDoes this intent deprecate or change behavior 
>> of existing APIs, such that it has potentially high risk for Android 
>> WebView-based applications?None
>>
>> DebuggabilityShared Storage worklets can be debugged in devtools.
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac, 
>> Linux, ChromeOS, Android, and Android WebView)?All but webview
>> Is this feature fully tested by web-platform-tests 
>> 

Re: [blink-dev] Intent to Ship: WebAssembly JS String Builtins

[Yoav Weiss (@Shopify)]

LGTM3

On Wed, Sep 4, 2024 at 5:17 AM Domenic Denicola 
wrote:

> LGTM2.
>
> Do we have a sense of WebKit's view of the proposal, e.g. through WebKit
> participation in the Wasm CG?
>
> On Wed, Sep 4, 2024 at 11:56 AM 一丝  wrote:
>
>> Firefox has been implemented and is waiting to be shipped.
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1876148
>>
>> 在2024年9月4日星期三 UTC+8 04:53:19 写道：
>>
>>> Thanks!
>>>
>>> LGTM1
>>>
>>> On Tue, Sep 3, 2024 at 11:41 AM Adam Klein  wrote:
>>>
 On Tue, Sep 3, 2024 at 11:31 AM Chris Harrelson 
 wrote:

>
>
> On Tue, Sep 3, 2024 at 10:37 AM Adam Klein  wrote:
>
>> Contact emailsecmzi...@chromium.org, jkum...@chromium.org,
>> ad...@chromium.org
>>
>> Explainer
>> https://github.com/WebAssembly/js-string-builtins/blob/main/proposals/js-string-builtins/Overview.md
>>
>> Specificationhttps://webassembly.github.io/js-string-builtins/js-api/
>>
>> Summary
>>
>> This feature exposes common JS string operations for easy import into
>> WebAssembly and optimizations thereof. This allows creating and
>> manipulating JS strings from WebAssembly without native support within
>> WebAssembly while still allowing for a similar performance as native 
>> string
>> references. The mechanism works by exposing suitably strict versions of 
>> JS
>> string operations in the WebAssembly JS API. These can be imported by
>> modules using externref as a generic data type for storing the strings. 
>> The
>> engine can identify that these imports can be represented by native graph
>> operators without the need for calling into JS. This leads to a 
>> comparable
>> peak performance as native string operations while allowing quick
>> interoperability with JS since no copying at the boundary is required 
>> when
>> calling into arbitrary JS functions that consume strings.
>>
>>
>> Blink componentBlink>JavaScript>WebAssembly
>> 
>>
>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/940
>>
>> TAG review statusCompleted (with "Resolution: satisfied")
>>
>> Chromium Trial NameWebAssemblyJSStringBuiltins
>>
>> Link to origin trial feedback summary
>> https://docs.google.com/document/d/1zL9goDsawTQUFuuQ8ddI_pUcLY1_iFOsHaDZ374dnGw/edit?usp=sharing
>>
>> Origin Trial documentation link
>> https://github.com/WebAssembly/js-string-builtins/blob/main/proposals/js-string-builtins/Overview.md
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> This proposal is at Phase 4 in the WebAssembly spec process
>>
>>
>> *Gecko*: Positive
>>
>
> Is there a standards position issue tracking this?
>

 I don't believe so. The proposal is championed by Ryan Hunt of Mozilla,
 who works on WebAssembly in SpiderMonkey. In order to reach Phase 4, the
 proposal needed two web engine implementations, and Firefox nightly has
 support for it, alongside Chrome.


>
>
>>
>> *WebKit*: No signal (
>> https://github.com/WebKit/standards-positions/issues/343)
>>
>> *Web developers*: Positive (see OT feedback)
>>
>> *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
>> 
>> ?Yes
>>
>> Flag name on chrome://flagsNone
>>
>> Finch feature nameWebAssemblyJSStringBuiltins
>>
>> Requires code in //chrome?False
>>
>> Estimated milestones
>> Shipping on desktop 130
>> Origin trial desktop first 119
>> Origin trial desktop last 127
>> Origin trial extension 1 end milestone 130
>> Shipping on Android 130
>> Shipping on WebView 130
>>
>> 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/6695587390423040?gate=6542541230440448
>>
>> Links to previous Intent dis

Re: [blink-dev] Intent to Ship: Direct Sockets API

[Yoav Weiss (@Shopify)]

LGTM1 - the use case is clear, as well as the dangers of enabling this over
the open web. Confining this API to IWAs seems to strike a reasonable
balance.

On Mon, Aug 19, 2024 at 3:46 PM 'Randell Jesup' via blink-dev <
blink-dev@chromium.org> wrote:

> This was not closed by Mozilla with no opinion, it was closed as Harmful.
>
> Randell Jesup, Mozilla Networking Team
>
> On Tue, Aug 13, 2024, 2:59 PM Chromestatus <
> ad...@cr-status.appspotmail.com> wrote:
>
>> Contact emails greengr...@google.com
>>
>> Explainer
>> https://github.com/WICG/direct-sockets/blob/main/docs/explainer.md
>>
>> Specification https://wicg.github.io/direct-sockets
>>
>> Summary
>>
>> Allows Isolated Web Apps to establish direct transmission control
>> protocol (TCP) and user datagram protocol (UDP) communications with network
>> devices and systems as well as listen to and accept incoming connections.
>>
>>
>> Blink component Blink>Network>Direct Sockets
>> 
>>
>> Search tags networking , TCP
>> , UDP , sockets
>> 
>>
>> TAG review https://github.com/w3ctag/design-reviews/issues/548
>>
>> TAG review status Pending
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> Other browsers may choose to implement this API.
>>
>>
>> *Gecko*: Closed Without a Position (
>> https://github.com/mozilla/standards-positions/issues/431)
>>
>> *WebKit*: No signal
>>
>> *Web developers*: Positive (
>> https://discourse.wicg.io/t/filling-the-remaining-gap-between-websocket-webrtc-and-webtranspor/4366)
>> Numerous potential use cases have been suggested.
>>
>> *Other signals*:
>>
>> Security
>>
>> Various security risks and mitigations are noted in
>> https://github.com/WICG/raw-sockets/blob/master/docs/explainer.md#security-considerations
>> This is a powerful API. Users will have the opportunity to give Isolated
>> Web Apps access to local hardware, and information systems behind
>> organization firewalls. Mitigations are designed to ensure this cannot
>> happen accidentally, and only through enterprise policies or the friction
>> of installing a native app.
>>
>>
>> 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. Feature not compiled in Android.
>>
>>
>> Debuggability
>>
>> The code using this API can be debugged using the standard tools.
>> Integrating the API with the DevTools Networking tab to enable easier
>> introspection of the state of these connections as well as the data
>> transferred could be a beneficial future improvement.
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, ChromeOS, Android, and Android WebView)? No
>>
>> This feature is implemented on desktop platforms, although it will only
>> be available to the end users on platforms that support Isolated Web Apps,
>> which is currently only ChromeOS. Android is excluded for historical
>> reasons, although there are no apparent interoperability blockers here.
>>
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ? Yes
>>
>> These tests require a specific --isolated-context-origins flag to be
>> tested in WPTs, so they're run as a part of a virtual suite and are not
>> reflected on wpt.fyi.
>>
>>
>> Flag name on chrome://flags #enable-direct-sockets-web-api
>>
>> Finch feature name DirectSockets
>>
>> Requires code in //chrome? False
>>
>> Tracking bug https://bugs.chromium.org/p/chromium/issues/detail?id=909927
>>
>> Launch bug https://launch.corp.google.com/launch/4339602
>>
>> Measurement We have the following histograms for tracking network
>> failures upon creating sockets (prefixed with DirectSockets.*): -
>> TCPNetworkFailures - UDPNetworkFailures - TCPServerNetworkFailures Separate
>> programmatic counters for the .idl methods and attributes (via MeasureAs)
>> are also included to track the stats for API usage.
>>
>> Availability expectation Feature is available only in Isolated Web Apps
>> on desktop platforms. https://chromestatus.com/feature/5146307550248960
>>
>> Adoption expectation Expected to be used initially by a small number of
>> developers inside Isolated Web Apps.
>>
>> Adoption plan Working directly with developers that are planning to rely
>> on the API.
>>
>> Non-OSS dependencies
>>
>> Does the feature depend on any code or APIs outside the Chromium open
>> source repository and its open-source dependencies to function?
>> None
>>
>> Sample links
>> https://github.com/GoogleChromeLabs/telnet-client
>>
>> Estimated milestones
>> Shipping on desktop 130
>>
>> Anticipated spec changes
>>
>> Open questions about a feature may be a source of future web compat or
>

Re: [blink-dev] Intent to ship: WebGPU: Dual source blending

[Yoav Weiss (@Shopify)]

LGTM1

On Fri, Aug 23, 2024 at 2:46 PM 'François Beaufort' via blink-dev <
blink-dev@chromium.org> wrote:

> Adding +Corentin Wallez  to the thread
>
> On Fri, Aug 23, 2024 at 2:29 PM François Beaufort 
> wrote:
>
>>
>>
>> On Fri, Aug 23, 2024 at 7:01 AM Domenic Denicola 
>> wrote:
>>
>>>
>>>
>>> On Thu, Aug 22, 2024 at 9:13 PM 'François Beaufort' via blink-dev <
>>> blink-dev@chromium.org> wrote:
>>>
 Contact emails

 fbeauf...@google.com

 Explainer

 The “dual-source-blending” GPU feature adds additional blend factors
 and the WGSL @blend_src attribute to allow a fragment shader to blend two
 color outputs into a single output buffer.
 https://github.com/gpuweb/gpuweb/pull/4621

 Specification

 https://gpuweb.github.io/gpuweb/#dom-gpufeaturename-dual-source-blending

 Summary

 Functionality added to the WebGPU spec after its first shipment in a
 browser.

 Adds the optional GPU feature “dual-source-blending” that enables
 combining two fragment shader outputs into a single framebuffer. This
 technique is particularly useful for applications that require complex
 blending operations, such as those based on Porter-Duff blend modes. By
 reducing the need for frequent pipeline state object changes, dual source
 blending can enhance performance and flexibility.

 Blink component

 Blink>WebGPU
 

 TAG review

 None

 TAG review status

 Not applicable

>>>
>>> I can't figure out which exception
>>> 
>>> this would fall under. Can you help explain why TAG review is not
>>> applicable here?
>>>
>>
>> Back in October 2023, Corentin Wallez, the WebGPU Tech Lead, met with the
>> Blink API owners to address the process for releasing WebGPU features
>> following their inclusion in Chromium. It was mutually agreed that
>> requesting TAG reviews for minor features would be unnecessary. This policy
>> applied to all features added at the time. See
>> https://groups.google.com/a/chromium.org/g/blink-dev/search?q=%22tag%20review%22%20subject%3Awebgpu
>>
>
I may misremember, but I thought we discussed adding a "levels" designation
to WebGPU additions that would enable us to create such bypasses for vendor
signals and TAG reviews. Did that actually happen? If so, did we make any
progress on that?

In any case, I agree this is a small addition in which I wouldn't expect
the TAG to have meaningful feedback over the one already provided by the
domain experts at the  WebGPU group.


>>
>>
>>>
>>>

 Risks

 Interoperability and Compatibility

 This feature has not yet been implemented in any browser. It has been
 approved by the GPU for the Web Community Group, with representatives from
 Chrome, Firefox, and Safari. See minutes at
 https://github.com/gpuweb/gpuweb/wiki/GPU-Web-2024-05-29#add-optional-feature-dual_source_blending-4621

 Gecko: No signal (Mozilla members have approved
 https://github.com/gpuweb/gpuweb/pull/4621 and requested during weekly
 standardization meetings that we postpone filing standard positions until
 we reach Candidate Recommendation (CR) status in Q4.)

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

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

 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, Android WebView, 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.

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

 Yes. See https://github.com/gpuweb/cts/issues/3810

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

>>>
>>> But, it is not tested by web platform tests themselves, right?
>>> https://github.com/web-platform-tests/wpt/tree/master/webgpu seems to
>>> not contain any tests for this feature.
>>>
>>> (This does not block shipping, but rather is just 

Re: [blink-dev] Intent to Ship: scheduler.yield()

[Yoav Weiss (@Shopify)]

I was out while this thread happened, but just wanted to chime in and say
I'm super excited for this shipping!!

On Sat, Aug 24, 2024 at 12:22 AM Scott Haseley 
wrote:

> Thanks all!
>
> This will be enabled in M129. (Note: this just missed the M129 branch, so
> it wasn't in the initial Chrome Beta release --- but has since been merged
> , so
> it should be in Beta soon.)
>
> On Wed, Aug 21, 2024 at 10:20 AM Alex Russell 
> wrote:
>
>> LGTM3
>>
>> On Wednesday, August 21, 2024 at 9:06:12 AM UTC-7 Daniel Bratell wrote:
>>
>>> LGTM2
>>>
>>> /Daniel
>>> On 2024-08-16 04:44, Domenic Denicola wrote:
>>>
>>> LGTM1!
>>>
>>> Please consider updating the explainer a bit to capture where things
>>> ended up, or at least adding a warning of some sort that it's a bit out of
>>> date.
>>>
>>> I will, thanks for suggesting.
>
>> On Fri, Aug 16, 2024 at 12:33 AM Scott Haseley 
>>> wrote:
>>>
 On Wed, Aug 14, 2024 at 9:35 PM Domenic Denicola 
 wrote:

> Very exciting to see this ready to ship after what sounds like a
> successful experiment. A few small questions...
>
> On Sat, Aug 10, 2024 at 6:19 AM Scott Haseley 
> wrote:
>
>> Contact emails shase...@chromium.org
>>
>> Explainer
>> https://github.com/WICG/scheduling-apis/blob/main/explainers/yield-and-continuation.md
>>
>> https://github.com/WICG/scheduling-apis/blob/main/explainers/prioritized-task-scheduling.md#scheduleryield
>>
>> *Note*: The explainer includes parameters to yield(), but we're
>> initially shipping this with only the default behavior described in the
>> specification. It wasn't clear if the parameters were necessary, there 
>> was
>> some concern internally over the exact behavior
>> , and it
>> complicates the API. They may yet prove necessary, but it's safer to roll
>> this out --- handling the main use case --- and revisit later, if needed.
>>
>> Specification
>> https://wicg.github.io/scheduling-apis/#dom-scheduler-yield
>>
>> Summary
>>
>> Provides a method for yielding control to the browser, which can be
>> used to break up long tasks. Awaiting the promise returned by
>> scheduler.yield() causes the current task to yield, continuing in a new
>> browser task. This can be used to improve responsiveness issues caused by
>> long tasks. Continuations are prioritized to mitigate performance 
>> problems
>> of existing alternatives.
>>
>>
>> Blink component Blink>Scheduling>APIs
>> 
>>
>> TAG review https://github.com/w3ctag/design-reviews/issues/966
>>
>> TAG review status Pending
>>
>> Chromium Trial Name SchedulerYield
>>
>> Link to origin trial feedback summary
>> https://docs.google.com/document/d/1HSlhqWsamWyR9bwgtCzB2TpVW7CUm9QkyKbK0TdM0RA/edit?usp=sharing
>>
>> Origin Trial documentation link
>> https://github.com/WICG/scheduling-apis/blob/main/implementation-status.md
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> This is a new feature and will not change existing event loop task
>> scheduling, so the main risk is that other browsers might not implement 
>> the
>> feature. There is an interop challenge, however, that comes with
>> prioritization: we want to be specific enough to provide developers
>> guarantees and interoperable implementations, but provide enough 
>> scheduling
>> flexibility for UAs (like the HTML specification does with task
>> sources/task queues), which we'll keep in mind while drafting the spec 
>> (see
>> also https://github.com/WICG/scheduling-apis/issues/67).
>>
>>
>> *Gecko*: Positive (
>> https://github.com/mozilla/standards-positions/issues/1039) Note
>> that the issue opened for yield() was folded in with the original
>> Scheduling APIs proposal, as this is an enhancement to that.
>>
>> *WebKit*: No signal (
>> https://github.com/WebKit/standards-positions/issues/361)
>>
>> *Web developers*: Positive
>>
>> Several partners were able to improve site performance using the API
>> during Origin Trial (see the Origin Trial feedback link for quotes).
>>
>> Also some tweets I found with positive sentiment:
>>  - https://x.com/cramforce/status/1588912606777335808
>>  - https://x.com/mohamedmansour/status/1752909705842933943
>>  - https://x.com/sebastienlorber/status/1589939130225475584
>>
>> *Other signals*:
>>
>> Ergonomics
>>
>> The default use (inserting yield points in long tasks) should enable
>> Chrome to maintain better performance (responsiveness). There is a risk 
>> of
>> continuations starving other work, b

Re: [blink-dev] Intent to Ship: Private Aggregation API: client-side contribution merging

[Yoav Weiss (@Shopify)]

LGTM2

On Tue, Aug 27, 2024 at 6:32 PM Vladimir Levin  wrote:

> This looks like a fairly minor improvement to the API. It seems like the
> change would allow more contributions without increasing performance
> concerns. Please let me know if there are any subtleties that I may have
> missed.
>
> LGTM1
>
> Thanks,
> Vlad
>
> On Fri, Aug 16, 2024 at 5:50 PM Alex Turner  wrote:
>
>> Contact emailsale...@chromium.org
>>
>> Explainer
>> https://github.com/patcg-individual-drafts/private-aggregation-api/pull/135
>>
>> Specification
>> https://github.com/patcg-individual-drafts/private-aggregation-api/pull/136
>>
>> Summary
>>
>> Modifies the Private Aggregation API to merge histogram contributions
>> with the same bucket and filtering ID before embedding in the aggregatable
>> report's encrypted payload. Private Aggregation imposes a limit on the
>> number of contributions that can be embedded in a single aggregatable
>> report, with any additional contributions being dropped. By merging
>> together contributions where possible, we can get additional utility out of
>> the limit. Note that, ignoring the dropping of excess contributions,
>> merging these sorts of contributions should not have any impact on the
>> final outputs (i.e. summary reports).
>>
>>
>> Blink componentBlink>PrivateAggregation
>> 
>>
>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/846 (We have
>> not requested a signal for these changes specifically.)
>>
>> TAG review statusPending
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> None
>>
>>
>> *Gecko*: No signal (
>> https://github.com/mozilla/standards-positions/issues/805) We have not
>> requested a signal for this change specifically. The Gecko position on
>> Shared Storage (one of the ways Private Aggregation is exposed) is negative.
>>
>> *WebKit*: No signal (
>> https://github.com/WebKit/standards-positions/issues/189) We have not
>> requested a signal for this change specifically.
>>
>> *Web developers*: Positive (
>> https://github.com/patcg-individual-drafts/private-aggregation-api/issues/81
>> )
>>
>> *Other signals*:
>>
>> WebView application risks
>>
>> Does this intent deprecate or change behavior of existing APIs, such that
>> it has potentially high risk for Android WebView-based applications?
>>
>> None
>>
>>
>> Debuggability
>>
>> No new debug capabilities beyond the existing internals page
>> (chrome://private-aggregation-internals) and temporary debug mode. These
>> capabilities will reflect the merged contributions.
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, ChromeOS, Android, and Android WebView)?
>>
>> All but WebView
>>
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?Yes
>>
>> Flag name on chrome://flagsNone
>>
>> Finch feature namePrivateAggregationApiContributionMerging
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://crbug.com/349980058
>>
>> Launch bughttps://launch.corp.google.com/launch/4333118
>>
>> Estimated milestones
>> Shipping on desktop 129
>> Shipping on Android 129
>>
>> Anticipated spec changes
>>
>> None
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5094168719523840?gate=5075771428438016
>>
>> This intent message was generated by Chrome Platform Status
>> .
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to blink-dev+unsubscr...@chromium.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA%2BBiFk8hn%3DnCSBg8pf7naZGqHgd8-DpOv7v0q4YokycSMG7xA%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/CADsXd2PTcqDG6uQ7HZS8ofCbMxgOw%3DrdQZ7Bj3xERYQStJS%3Dsw%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/ms

Re: [blink-dev] Intent to Deprecate and Remove: Remove expectedImprovement in DelegatedInkTrailPresenter

[Yoav Weiss (@Shopify)]

LGTM2

On Monday, August 26, 2024 at 6:50:16 PM UTC+2 sahir@microsoft.com 
wrote:

> Done! Thank you.
>
> On Monday, August 26, 2024 at 9:41:45 AM UTC-7 mike...@chromium.org wrote:
>
>> Also, would you remind requesting reviews for Enteprise, Debuggability, 
>> and Testing in the chromestatus entry? Thanks!
>>
> On 8/26/24 12:40 PM, Mike Taylor wrote:
>>
> LGTM1 to remove - if there's no usage, now is the time to get that done. 
>>
>> Relevant use counter for those interested: 
>> https://chromestatus.com/metrics/feature/timeline/popularity/5017
>> On 8/26/24 12:13 PM, Chromestatus wrote:
>>
>> Contact emails sahir@microsoft.com 
>>
>>
>> Explainer None 
>>
>> Specification https://wicg.github.io/ink-enhancement 
>>
>> Summary 
>>
>> The attribute tells web developers how much improvement the 
>> DelegatedInkTrails API will provide to their current ink latency. However, 
>> this attribute is not worth increases to fingerprinting entropy.
>>
>>
>> Blink component Blink>Input 
>>  
>>
>> Motivation 
>>
>> expectedImprovement tells web developers how much improvement the 
>> DelegatedInkTrails API will provide to their current ink latency. However, 
>> this attribute is not worth increases to fingerprinting entropy. The 
>> difference in cost to the web developer between using the 
>> expectedImprovement attribute and actually delegating the "wet" ink trail 
>> to the OS/Browser is minimal, and upon additional discussion, there was no 
>> good reason found for the web developer not delegating the ink trail after 
>> receiving some value from the expectedImprovement attribute (all 
>> improvement is good improvement). The removal of this attribute should have 
>> minimal impact to web compatibility as it was never implemented in Blink in 
>> the first place. This is the intent to remove the attribute from the web 
>> exposed DelegatedInkTrailPresenter interface. There is no usage of this 
>> attribute according to blink use counters.
>>
>>
>> Initial public proposal None 
>>
>> TAG review None 
>>
>> TAG review status Not applicable 
>>
>> Risks 
>>
>>
>> Interoperability and Compatibility 
>>
>> No interoperability or compatibility risks as the feature was not 
>> implemented and is not used; even incorrectly.
>>
>>
>> *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
>>
>>
>> Is this feature fully tested by web-platform-tests 
>> 
>> ? No 
>>
>> Flag name on chrome://flags None 
>>
>> Finch feature name None 
>>
>> Non-finch justification None 
>>
>> Requires code in //chrome? False 
>>
>> Tracking bug https://bugs.chromium.org/347647410 
>>
>> Estimated milestones 
>> Shipping on desktop 130 
>>
>> Link to entry on the Chrome Platform Status 
>> https://chromestatus.com/feature/5194773674328064?gate=5169972251459584 
>>
>> This intent message was generated by Chrome Platform Status 
>> . 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "blink-dev" group.
>>
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to blink-dev+...@chromium.org.
>>
>>
>> To view this discussion on the web visit 
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6923df06209867e8%40google.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/6451fb1d-4c6c-43a1-a2ed-f87b00dbf320n%40chromium.org.

Re: [blink-dev] Intent to Experiment: Reduce Accept-Language

[Yoav Weiss (@Shopify)]

I wrote a few words about this proposal and how I think we can avoid some
of the tradeoffs it is making and end up with better user experience *and*
more privacy: https://blog.yoav.ws/posts/improving_language_negotiation/

On Wed, Aug 7, 2024, 17:41 Victor Tan  wrote:

> Email Body
>
> Contact emails
>
> victor...@chromium.org, miketa...@chromium.org
>
> Explainer
>
> https://github.com/explainers-by-googlers/reduce-accept-language
>
> TAG reviewTo be filed.
> Summary
>
> In order to reduce the amount of passively available entropy in HTTP
> requests, we want to reduce the amount of information the Accept-Language
> header exposes in HTTP requests and JS interface navigator.languages.
> Instead of sending every user's language preferences via Accept-Language,
> we only send the user’s most preferred language after language negotiation
> in the Accept-Language header. For the HTTP Accept-Language header, we will
> potentially expand a base language based on the language-region pair (e.g.,
> if the preferred language is “en-US” we will expand to “en-US, en;q=0.9”).
> The JS getter navigator.languages returns the same value as
> navigator.language.
>
> We would like to run a Finch 1% experiment from M128 to M131 inclusive.
>
> Blink component
>
> Privacy>Fingerprinting
> 
>
> Risks
>
> Interoperability and Compatibility
>
> The compatibility risk is relatively low for most users since we're
> planning to reduce the amount of information in the Accept-Language header
> and navigator.languages, rather than remove the header or change value
> format in the header. Most existing Accept-Language detection code should
> continue to work. This experiment should help us validate this assumption
> and identify corner cases.
>
> As for interoperability, for multilingual sites to rely on the
> Accept-Language, developers would need to depend on a user's full
> Accept-Language list for some browsers and a primary user's Accept-Language
> for others. Another signal is that the Chrome incognito model already
> reduced the Accept-Language header and JS interface navigator.languages to
> one language, and Safari ships this behavior for many users today.
>
> Gecko: Pending (https://github.com/mozilla/standards-positions/issues/1014
> )
>
> WebKit: Shipped (https://github.com/WebKit/standards-positions/issues/338)
> Safari already reduced the Accept-Language to a single language in most
> cases.
>
> Web developers: Some web developers are concerned about the client-side
> language negotiation implications (
> https://github.com/Tanych/accept-language/issues/10).
>
> Experiment Goals
>
> The goal of this experiment is to ensure web compatibility with our
> proposed changes. Developers can also test how reducing the Accept-Language
> request header and the JS getter navigator.languages will affect their
> systems via the  chrome://flags/#reduce-accept-language flag, especially to
> understand the impact on client side language negotiation via
> navigator.languages. We will be relying heavily on user and developer
> feedback to identify where breakage occurs,  or where use cases are not
> accounted for, especially for multilingual sites depending on the
> Accept-Language header, and navigator.languages.
>
> Experiment Risks
>
> There are some risks, as many multilingual sites have come to rely on the
> value in Accept-Language header and JS interfaces navigator.languages to
> send the right representation pages to the user.  Site breakage can take
> many forms, both obvious and non-obvious - which is the point of running
> this experiment. If we are confident the design is largely web-compatible,
> we will request a Deprecation Trial for sites to be able to have time to
> migrate or modify how their sites work.
>
> Debuggability
>
> Both of these settings and the resulting network requests are visible in
> DevTools.
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?
>
> No (All but WebView)
>
> Is this feature fully tested by web-platform-tests
> 
> ?
>
> No (We fully test in browser_tests, WPT has limits to cover all the test
> cases in the Accept-Language header).
>
> Flag name on chrome://flags
>
> #reduce-accept-language
>
> Finch Flag name
>
> kReduceAcceptLanguage
> Tracking bug
>
> https://issues.chromium.org/issues/40218547
> Launch bug
>
> https://launch.corp.google.com/launch/4317282
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5188040623390720
> 
>
> --
> 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.
>

[blink-dev] Intent to Prototype: Dynamic import maps

[Yoav Weiss (@Shopify)]

Contact emailsyoavwe...@chromium.org

Explainerhttps://github.com/whatwg/html/pull/10528#issue-2437162429

Specificationhttps://github.com/whatwg/html/pull/10528

Summary

Import maps currently have to load before any ES module and there can only
be a single import map per document. That makes them fragile and
potentially slow to use in real-life scenarios: Any module that loads
before them breaks the entire app, and in apps with many modules they
become a large blocking resource, as the entire map for all possible
modules needs to load first. This feature is to enable multiple import maps
per document, by merging them in a consistent and deterministic way.


Blink componentBlink>HTML>Modules


Motivation

Import maps in their current form provide multiple benefits to web
developers. They enable them to avoid cache invalidation cascades, and to
be able to work with more ergonomic bare module identifiers, mapping them
to URLs in a convenient way, without worrying about versions when
importing. At the same time, the current import map setup suffers from
fragility. Only a single import map can be loaded per document, and it can
only be loaded before any module script is loaded. Once a single module
script is loaded, import maps are disallowed. That creates a situation
where developers have to think twice (or more) before using module scripts
in situations that may introduce import maps further down in the document.
It also means that using import maps can carry a risk unless you’re certain
you can control all the module scripts loaded on the page. Beyond that, the
fact that import maps have to be loaded before any module means that the
map itself acts as a blocking resource to any module functionality. Large
SPAs that want to use modules, have to download the map of all potential
modules they may need during the app’s lifetime ahead of time.


Initial public proposalhttps://github.com/whatwg/html/pull/10528

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

TAG review statusPending

Risks


Interoperability and Compatibility

None


*Gecko*: No signal


*WebKit*: No signal


*Web developers*: Shopify developers would need this in order to use ES
modules proper. I haven't yet gathered a signal beyond that.

*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


Is this feature fully tested by web-platform-tests

?Not yet, but it will be

Flag name on chrome://flagsNone

Finch feature nameNone for now, but I'd add a flag before shipping.

Non-finch justificationNone

Requires code in //chrome?False

Estimated milestones

No milestones specified


Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5121916248260608?gate=5075513421594624

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/CAOmohSJrxQj19LattoOyE3Af5dn%3D50UD9ecpHZWjVZ5-GrMr9w%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Support non-special scheme URLs

[Yoav Weiss (@Shopify)]

Thanks for working on this!!

On Thu, Aug 8, 2024 at 10:09 AM Hayato Ito  wrote:

> Contact emails
>
> hay...@chromium.org
>
> Explainer
>
> http://bit.ly/url-non-special
>
> Specification
>
> https://url.spec.whatwg.org/ 
>
> Summary
>
> Support non-special scheme URLs.
>
> Previously, Chromium's URL parser didn't handle non-special scheme URLs
> properly. It treated these URLs as “opaque paths”, which didn’t align with
> the URL Standard.
>
> Now, Chromium’s URL parser correctly processes non-special URLs.
>
> Examples:
>
> Before:
>
> > const url = new URL("git://host/path");
>
> > url.host
>
> ""
>
> > url.pathname
>
> "//host/path"
>
> > url.host = "newhost";
>
> > url.host
>
> ""
>
> > const url = new URL("git://a b/path");
>
> > url.pathname
>
> "//a b/path"
>
>
> After:
>
> > const url = new URL("git://host/path");
>
> > url.host
>
> "host"
>
> > url.pathname
>
> "/path"
>
> > url.host = "newhost";
>
> > url.host
>
> "newhost"
>
> > url.href
>
> "git://newhost/path"
>
> > const url = new URL("git://a b/path");
>
> => throws Exception. // A space character is not allowed as a hostname.
>
> See http://bit.ly/url-non-special for more details.
>
>
> As part of our Interop 2024 efforts, this change delivers the following
> improvements:
>
>-
>
>Boosts WPT URL Score: 936 previously failing subtests in the WPT URL
>tests (link
>
> )
>now pass, raising the score from 87.0% to 94.7%.
>-
>
>Fixes code relying on incorrect URL behavior: 527 tests  (link
>
> )
>and related code in Chromium that depended on the previous behavior are now
>fixed or mitigated, including:
>-
>
>   Web tests that relied on non-compliant non-special URL behavior
>   (e.g. “javascript://a b” URL)
>   -
>
>   Non-special schemes used internally by Chromium code base,
>   including ChromeOS (e.g. “steam:”, “materialized-view://”, 
> “cros-apps://”)
>
>
>
> Blink component
>
> Internals>Network
> 
>
> TAG review
>
> Not applicable
>
> Risks
>
> Interoperability and Compatibility
>
> Since Safari and Firefox already support non-special scheme URLs, the
> likelihood of public websites breaking due to this change is likely low.
> See here
> 
> for a rough estimation of the non-special scheme URL usages.
>

Any particular section in that doc that talks through or estimates the
compat risk?


>
> Gecko: Shipped
>
> WebKit: Shipped
>
> Web developers:  Generally seems positive.
>
> Some signals (from interop 2024 discussions
> ) are:
>
>-
>
>> Confusion because URL parsers across Blink, Gecko, WebKit, Node, and
>Deno do not interop well. The root cause is nearly always parser bugs in
>Blink or Gecko: https://twitter.com/oleg008/status/1699087223751073883
>
>
>-
>
>> URL is very widely used - custom schemes are commonly used for links
>to native apps, or when dealing with developer tooling like databases. They
>may also become exceedingly more common with import maps.
>
>
> Other potential risks and assessments:
>
>
>-
>
>Enterprise usage: It's difficult to predict how non-special URLs are
>used in the wild, especially by enterprise customers with in-house apps.
>While adding an Enterprise Policy was considered to mitigate risks,
>technical limitations make it difficult to support URLs. See
>http://bit.ly/url-non-special for more info. We'll disable the feature
>with Finch (StandardCompliantNonSpecialSchemeURLParsing flag) in case this
>causes serious issues.
>-
>
>Impacts on well-known non-special schemes: See here
>
> 
>for the impacts on “javascript://”, “data:”, and so on.
>-
>
>Impacts on dependent components: This change affects components
>relying on URL behavior, like Origin
>. See the Security section below.
>
>
>
> Security
>
> In Chromium, GURL, KURL, and web-facing URL APIs share the common URL
> parser backends, which reside in //url. As a result, this web-facing change
> will also affect core components like url::Origin, kurl::SecurityOrigin.
>
> For detailed information on how url::Origin, kurl::SecurityOrigin, and
> web-facing url.origin are impacted, please refer to this CL’s description
> 

Re: [blink-dev] Intent to Ship: The Nested Declarations Rule

[Yoav Weiss (@Shopify)]

Can you flip the "testing" bit in the chromestatus entry? (and mark it with
"n/a" if that's the case)

On Tue, Aug 6, 2024 at 4:31 PM Chris Harrelson 
wrote:

> LGTM3
>
> On Tue, Aug 6, 2024, 6:05 AM Yoav Weiss (@Shopify) 
> wrote:
>
>> LGTM2
>>
>> On Tue, Aug 6, 2024 at 3:02 PM Philip Jägenstedt 
>> wrote:
>>
>>> LGTM1, this is important to do sooner rather than later, so that the
>>> current behavior is not locked in by site compat. Thank you for finding a
>>> solution that's acceptable to everyone!
>>>
>>> Given that this was discussed extensively in the CSSWG, I don't think we
>>> need to wait further on vendor positions.
>>>
>>> On Fri, Aug 2, 2024 at 11:06 AM Anders Hartvoll Ruud <
>>> andr...@chromium.org> wrote:
>>>
>>>> On Fri, Aug 2, 2024 at 1:54 AM Daniel Clark 
>>>> wrote:
>>>>
>>>>> The stated answer to “Will this feature be supported on all six Blink
>>>>> platforms” is “No”, but I’d expect this to be the same on all platforms –
>>>>> is that right?
>>>>>
>>>>
>>>> Yes, that was a mistake.
>>>>
>>>>
>>>>>
>>>>>
>>>>> Could you elaborate a bit on why this might not be doable behind a
>>>>> flag?
>>>>>
>>>>>
>>>>>
>>>>
>>>> This comment was ... "inherited" from the previous version of this
>>>> intent (
>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/prg4CN0eEGg?pli=1).
>>>> Looking a bit closer at CSSParserImpl now, it seems doable. We can proceed
>>>> as if this will have a flag. I'll post the flag name to this thread before
>>>> shipping.
>>>>
>>>>
>>>>> -- Dan
>>>>>
>>>>>
>>>>>
>>>>> *From:* Anders Hartvoll Ruud 
>>>>> *Sent:* Thursday, August 1, 2024 4:14 AM
>>>>> *To:* blink-dev 
>>>>> *Subject:* [blink-dev] Intent to Ship: The Nested Declarations Rule
>>>>>
>>>>>
>>>>>
>>>>> Note: See also the previous (failed) intent
>>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/prg4CN0eEGg>
>>>>> for @nest. All CSSWG disagreements around this are now resolved.
>>>>>
>>>>>
>>>>> Contact emails
>>>>>
>>>>> andr...@chromium.org
>>>>>
>>>>>
>>>>> Specification
>>>>>
>>>>> https://drafts.csswg.org/css-nesting-1/#nested-declarations-rule
>>>>>
>>>>>
>>>>> Summary
>>>>>
>>>>>
>>>>>
>>>>> CSS Nesting initially shipped with an interesting quirk that would
>>>>> cause bare declarations that come after a nested rule to “shift”, for
>>>>> example:
>>>>>
>>>>>
>>>>>
>>>>> .foo {
>>>>>
>>>>>   width: 100px;
>>>>>
>>>>>   height: 100px;
>>>>>
>>>>>   @media screen {
>>>>>
>>>>> background-color: red;
>>>>>
>>>>>   }
>>>>>
>>>>>   background-color: green;
>>>>>
>>>>> }
>>>>>
>>>>>
>>>>>
>>>>> You would think that the background-color of  would be
>>>>> green here, but no, that declaration is shifted up to the main (leading)
>>>>> block of declarations during parsing:
>>>>>
>>>>>
>>>>>
>>>>> .foo {
>>>>>
>>>>>   width: 100px;
>>>>>
>>>>>   height: 100px;
>>>>>
>>>>>   background-color: green; /* I’m here now */
>>>>>
>>>>>   @media screen {
>>>>>
>>>>> background-color: red;
>>>>>
>>>>>   }
>>>>>
>>>>> }
>>>>>
>>>>>
>>>>>
>>>>> This was at the time done intentionally for a mix of CSSOM and
>>>>> historical reasons, and all implementations of CSS Nesting currently agree
>>>>> on this behavior. However, it turns out this shifting behavio

Re: [blink-dev] Intent to Ship: Protected Audience: cross-origin trusted signals fetches

[Yoav Weiss (@Shopify)]

LGTM1 % spec nit

On Wednesday, July 31, 2024 at 6:38:43 PM UTC+2 Paul Jensen wrote:

On Friday, July 26, 2024 at 5:28:22 AM UTC-4 Yoav Weiss wrote:

On Mon, Jul 22, 2024 at 5:26 PM 'Maksim Orlovich' via blink-dev <
blink-dev@chromium.org> wrote:

Note: https://github.com/WICG/turtledove/pull/1230 is an updated link for 
the second spec clarification pull requests, and the first one of the two 
has landed.


On Fri, Jul 19, 2024 at 4:40 PM Paul Jensen  wrote:


Summary

This feature allows the Protected Audience (PA) API to fetch real-time 
bidding and scoring signals from origins other than the origin of the buyer 
and seller's scripts. This is done by enabling CORS on these requests and 
some additional checks and requirements, and changes to prevent misuse.


Can you expand on the "changes to prevent misuse" part?
What misuse are we concerned with? What have we done to avoid it?

 

Previous to this proposal, the trusted signals were required to come from 
the same origin as the bidding or scoring script that processed them, and 
the script could safely assume that the signals it received were from its 
same origin.  With this new ability to fetch them from another origin we 
wanted to avoid a couple forms of misuse:

   1. 
   
   unintentional/accidental misconfiguration where the trusted signals 
   origin (specified in the interest group or auction configuration) could now 
   be a different origin but the script processing these signals might not be 
   updated to understand this or process signals from another origin, or
   2. 
   
   intentional/malicious misconfiguration where someone might have changed 
   the origin of the trusted signals unbeknownst to the script processing 
   them.  This isn’t possible for trusted bidding signals as the interest 
   group (where the trusted bidding signals URL is specified) is only settable 
   from same-origin contexts.
   

That last part is using AsyncTask 
?
 
Is that well-defined in the PR? I'm not sure we have a strict concept of 
"context" in the platform today.
TaskAttribution 
 took 
a stab at that and AsyncContext 
 is another, but I guess 
that making that implementation-defined 
 would work as well 
for now. 


   1. 
   
 Auction configurations (where the trusted scoring signals URL is 
   specified) don’t have the same same-origin setting requirements, but this 
   is why this proposal requires the scoring script to include the 
   Ad-Auction-Allow-Trusted-Scoring-Signals-From response header which 
   lists allowed origins for the trusted scoring signals.  Misconfiguration 
   here could look like a scoring script allowing two trusted scoring signals 
   origins, and someone switching between these allowed origins unexpectedly.
   
To prevent these misconfigurations, we changed how the trusted signals are 
passed to the scripts: they are passed in a new parameter so as not to be 
confused with the previously always-same-origin signals parameter, and this 
new parameter is a map from the origin of the signals to the signals 
themselves.  This was discussed as risk #2 in my GitHub post 
.

The Ad-Auction-Allow-Trusted-Scoring-Signals-From header also prevents the 
trusted scoring signals request from being sent to unexpected origins.

-- 
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/f3759194-8de5-45d1-9c96-6c4421194337n%40chromium.org.

Re: [blink-dev] Intent to Ship: Web Authentication API: JSON serialization methods

[Yoav Weiss (@Shopify)]

LGTM2

On Wed, Aug 7, 2024 at 2:14 AM Domenic Denicola 
wrote:

> LGTM1
>
> On Wed, Aug 7, 2024 at 5:41 AM 'Martin Kreichgauer' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> The WPTs should be passing in Firefox now [1
>> <https://wpt.fyi/results/webauthn/public-key-credential-creation-options-from-json.https.window.html?q=public-key&run_id=5196133479743488>]
>> [2
>> <https://wpt.fyi/results/webauthn/public-key-credential-request-options-from-json.https.window.html?q=public-key&run_id=5196133479743488>]
>> [3
>> <https://wpt.fyi/results/webauthn/public-key-credential-to-json.https.window.html?q=public-key&run_id=5196133479743488>
>> ].
>>
>> On Fri, Jul 26, 2024 at 4:30 AM Yoav Weiss (@Shopify) <
>> yoavwe...@chromium.org> wrote:
>>
>>> Friendly reminder that this is blocked on addressing Domenic's feedback
>>> RE the WPTs :)
>>>
>>> On Wednesday, July 17, 2024 at 8:26:22 PM UTC+2 mart...@google.com
>>> wrote:
>>>
>>>> Work is underway to enable WebAuthn broadly on WebView. As far as I'm
>>>> aware, that work hasn't quite roll out yet due to some dependency on the
>>>> Android side. I'll ask the people working on that to ensure they update the
>>>> MDN compat table once we know a minimum version.
>>>>
>>>> Once WebAuthn is available in WebView, the JSON serialization parts are
>>>> included there automatically.
>>>>
>>>>
>>>> On Wed, Jul 17, 2024 at 6:31 AM Yoav Weiss (@Shopify) <
>>>> yoavwe...@chromium.org> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Sat, Jul 13, 2024 at 1:42 AM 'Martin Kreichgauer' via blink-dev <
>>>>> blink-dev@chromium.org> wrote:
>>>>>
>>>>>> Contact emailsmarti...@google.com
>>>>>>
>>>>>> Explainer
>>>>>> https://github.com/w3c/webauthn/wiki/Explainer:-JSON-Serialization-Methods
>>>>>>
>>>>>> Specificationhttps://w3c.github.io/webauthn/#publickeycredential
>>>>>>
>>>>>> Summary
>>>>>>
>>>>>> The WebAuthn PublicKeyCredential.toJSON(),
>>>>>> parseCreationOptionsFromJSON() and parseRequestOptionsFromJSON() methods
>>>>>> let developers serialize a WebAuthn response into a JSON object or
>>>>>> deserialize a WebAuthn request object from its JSON representation.
>>>>>>
>>>>>>
>>>>>> Blink componentBlink>WebAuthentication
>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EWebAuthentication>
>>>>>>
>>>>>> TAG reviewNone
>>>>>>
>>>>>> TAG review statusNot applicable
>>>>>>
>>>>>> Risks
>>>>>>
>>>>>>
>>>>>> Interoperability and Compatibility
>>>>>>
>>>>>> None
>>>>>>
>>>>>>
>>>>>> *Gecko*: Shipped/Shipping (
>>>>>> https://developer.mozilla.org/en-US/docs/Web/API/PublicKeyCredential/toJSON#browser_compatibility
>>>>>> )
>>>>>>
>>>>>> *WebKit*: No signal
>>>>>>
>>>>>> *Web developers*: Positive (https://github.com/github/webauthn-json)
>>>>>> webauthn-json is a widely used polyfill for this API maintained by 
>>>>>> Github.
>>>>>>
>>>>>> *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
>>>>>>
>>>>>> This feature is implemented in Blink renderer code and shipping on
>>>>>> all platforms.
>>>>>>
>>>>>
>>>>> https://develop

Re: [blink-dev] Intent to Ship: The Nested Declarations Rule

[Yoav Weiss (@Shopify)]

LGTM2

On Tue, Aug 6, 2024 at 3:02 PM Philip Jägenstedt 
wrote:

> LGTM1, this is important to do sooner rather than later, so that the
> current behavior is not locked in by site compat. Thank you for finding a
> solution that's acceptable to everyone!
>
> Given that this was discussed extensively in the CSSWG, I don't think we
> need to wait further on vendor positions.
>
> On Fri, Aug 2, 2024 at 11:06 AM Anders Hartvoll Ruud 
> wrote:
>
>> On Fri, Aug 2, 2024 at 1:54 AM Daniel Clark  wrote:
>>
>>> The stated answer to “Will this feature be supported on all six Blink
>>> platforms” is “No”, but I’d expect this to be the same on all platforms –
>>> is that right?
>>>
>>
>> Yes, that was a mistake.
>>
>>
>>>
>>>
>>> Could you elaborate a bit on why this might not be doable behind a flag?
>>>
>>>
>>>
>>
>> This comment was ... "inherited" from the previous version of this intent
>> (https://groups.google.com/a/chromium.org/g/blink-dev/c/prg4CN0eEGg?pli=1).
>> Looking a bit closer at CSSParserImpl now, it seems doable. We can proceed
>> as if this will have a flag. I'll post the flag name to this thread before
>> shipping.
>>
>>
>>> -- Dan
>>>
>>>
>>>
>>> *From:* Anders Hartvoll Ruud 
>>> *Sent:* Thursday, August 1, 2024 4:14 AM
>>> *To:* blink-dev 
>>> *Subject:* [blink-dev] Intent to Ship: The Nested Declarations Rule
>>>
>>>
>>>
>>> Note: See also the previous (failed) intent
>>> 
>>> for @nest. All CSSWG disagreements around this are now resolved.
>>>
>>>
>>> Contact emails
>>>
>>> andr...@chromium.org
>>>
>>>
>>> Specification
>>>
>>> https://drafts.csswg.org/css-nesting-1/#nested-declarations-rule
>>>
>>>
>>> Summary
>>>
>>>
>>>
>>> CSS Nesting initially shipped with an interesting quirk that would cause
>>> bare declarations that come after a nested rule to “shift”, for example:
>>>
>>>
>>>
>>> .foo {
>>>
>>>   width: 100px;
>>>
>>>   height: 100px;
>>>
>>>   @media screen {
>>>
>>> background-color: red;
>>>
>>>   }
>>>
>>>   background-color: green;
>>>
>>> }
>>>
>>>
>>>
>>> You would think that the background-color of  would be
>>> green here, but no, that declaration is shifted up to the main (leading)
>>> block of declarations during parsing:
>>>
>>>
>>>
>>> .foo {
>>>
>>>   width: 100px;
>>>
>>>   height: 100px;
>>>
>>>   background-color: green; /* I’m here now */
>>>
>>>   @media screen {
>>>
>>> background-color: red;
>>>
>>>   }
>>>
>>> }
>>>
>>>
>>>
>>> This was at the time done intentionally for a mix of CSSOM and
>>> historical reasons, and all implementations of CSS Nesting currently agree
>>> on this behavior. However, it turns out this shifting behavior isn’t what
>>> authors expect (WebKit blog post
>>> ),
>>> and the CSSWG now consider the decision a mistake. In October 2023, the
>>> CSSWG resolved
>>> 
>>> to not do the shifting behavior anymore, and after a long debate on how to
>>> handle the implications of this (Issue 10234
>>> ), the CSSWG finally
>>> resolved to introduce the CSSNestedDeclarations rule to solve the problem.
>>>
>>>
>>> Blink component
>>>
>>> Blink>CSS
>>> 
>>>
>>>
>>> TAG review
>>>
>>> None
>>>
>>>
>>> TAG review status
>>>
>>> Not applicable
>>>
>>>
>>> Risks
>>>
>>>
>>>
>>> This intent is a breaking change, with two main points of breakage:
>>>
>>>
>>>
>>>- Keeping the bare declarations in place can affect the winner of
>>>the cascade (the example in the introduction). This is covered by
>>>CSSBareDeclarationShift
>>>
>>>(0.00042%).
>>>- Additionally, CSSNestingDeclarations will have different
>>>specificity behavior for nested group rules, and this can also affect the
>>>winner of the cascade. This is covered by
>>>CSSNestedGroupRuleSpecificity
>>>
>>>(0.00046%).
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>>
>>>
>>> *Gecko*: No signal (
>>> https://github.com/mozilla/standards-positions/issues/1048) - “looks
>>> acceptable to me”. Note that the issue Emilio mentions in his feedback has
>>> been resolved .
>>>
>>>
>>>
>>> *WebKit*: No signal on the position itself (
>>> https://github.com/WebKit/standards-positions/issues/369) - It’s
>>> however slightly ridiculous to request a signal in this case, since this
>>> Intent carries out WebKit’s proposal
>>> 
>>> *exactly*.
>>>
>>>
>>>
>>> *Web developers*: No signals
>>>
>>>
>>>
>>> *Other signals*:
>>>
>>>
>

Re: [blink-dev] PSA: Throw exception when text encode alloc memory fail.

[Yoav Weiss (@Shopify)]

On Fri, Aug 2, 2024 at 11:40 AM Adam Rice  wrote:

> Usually specs don't cover what happens when you run out of memory, as
> implied by https://infra.spec.whatwg.org/#algorithm-limits. I think
> this is fine. I'm interested in what other browsers do, but it's hard to
> test unless you have a VM handy.
>

This section indicates that algorithms shouldn't impose specific limits,
but I don't think that implies that there shouldn't be standard behavior
when those limits are (naturally) met. An example of that is the
QuotaExceededError

exception. We expect developers to be able to deal with different quota
levels in different browsers, but the exception they get when they hit the
limit is the same everywhere.

IMO, it may make sense to define an exception that developers can expect in
those cases. (maybe depending on what other browsers are doing in that case)


> On Fri, 2 Aug 2024 at 01:17, Mike Taylor  wrote:
>
>> Hi there,
>>
>> Have we done any sort of web compatibility analysis of what this change
>> implies? A broken page might be a better choice than a crashed tab, but
>> it's hard to know without any sense of the potential impact of this change.
>> Also, is there a plan to specify this behavior? What's the interop
>> situation?
>>
>> thanks,
>> Mike
>> On 8/1/24 4:38 AM, 'xu ms' via blink-dev wrote:
>>
>> *Contact emails*: xuzha...@microsoft.com
>>
>> *Summary：*
>>
>> We are currently observing many renderer crashes occurring in text 
>> encode.Encoding
>> Standard (whatwg.org) 
>> This is because DOMArrayBuffer::Create is currently used to create a
>> buffer, and when memory allocation fails, renderer process crashes. The
>> reasons for memory allocation failure are unclear and not solely due to
>> allocating excessively large memory.
>>
>> Therefore, we want to change the logic here so that when memory
>> allocation fails, a DOMException is thrown from text encode instead of
>> crashing.
>>
>> *Blink component*: Blink>TextEncoding
>> 
>>
>> *Tracking bug*:[OOM] Is it a real OOM for blink::DOMArrayBuffer::Create?
>> [355018938] - Chromium 
>>
>>
>> --
>> 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/f4cfdc62-707f-4d21-80d5-43ed37ce52fan%40chromium.org
>> 
>> .
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to blink-dev+unsubscr...@chromium.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c6b00d44-599f-47bf-be3d-9e977681b827%40chromium.org
>> 
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAC_ixdwDfGZQgUNP7HSkU03heC8VG2Zy8fqhJJWzxDerV1i8zA%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/CAOmohS%2Bcb1M4gjXTbJ-Hyv3DDpBbxFU6-U4gyZZZnxmOffvqaA%40mail.gmail.com.

Re: [blink-dev] Intent to Experiment: FileSystemObserver interface

[Yoav Weiss (@Shopify)]

LGTM to experiment M129-M134 inclusive.



On Tue, Jul 30, 2024 at 9:39 PM Daseul Lee  wrote:

> Contact emails
>
> asu...@chromium.org, a...@chromium.org, christin...@chromium.org,
> ds...@chromium.org, memm...@chromium.org
>
> Explainer
>
> https://github.com/whatwg/fs/blob/main/proposals/FileSystemObserver.md
>
> Specification
>
> https://github.com/whatwg/fs/pull/165
>
> Design docs
>
>
> https://docs.google.com/document/d/1d6YoPvk0rdNBQaZcoFP-V5u4CBjgahvmnVsZpbn0Gmo/edit?usp=sharing
>

Thanks for the public design doc!
It's a shame that the security review is hidden behind a Google-internal doc

and
the Launch process.
While I understand how some security related discussions can't be made
public, it would have been good for me as a reviewer to get a better
understanding of e.g. the UI patterns that users will go through in order
to approve a site to watch their files/directories.
At the same time, I trust the Chrome security folks on this.


> Summary
>
> The FileSystemObserver interface notifies websites of changes to the file
> system. Sites observe changes to files and directories in the user's local
> device (as specified in WICG/file-system-access) or in the Bucket File
> System (as specified in whatwg/fs), and are notified of basic change info,
> such as the change type.
>
> Blink component
>
> Blink>Storage>FileSystem
> 
>
> TAG review
>
> Exempt per early TAG design review:
> https://github.com/w3ctag/design-reviews/issues/868
>
>
> RisksInteroperability and Compatibility
>
> Gecko: Positive (https://github.com/mozilla/standards-positions/issues/942)
> Positive on use-case
>
> WebKit: No signal (
> https://github.com/WebKit/standards-positions/issues/291)
>
> Web developers: Strongly positive (
> https://github.com/WICG/file-system-access/issues/72)
>
> 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?
>
> Not enabled in WebView
>
>
> Goals for experimentation
>
> - Obtain more web developer feedback to validate the API shape
>
> - Identify any major performance issues against real world use cases, that
> could help determining future improvements and optimizations
>
> Ongoing technical constraints
>
> None
>
> Debuggability
>
> N/A
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, ChromeOS, Android, and Android WebView)?
>
> No. Available on desktop only.
>
> Is this feature fully tested by web-platform-tests
> 
> ?
>
> Yes
>
>
> https://wpt.fyi/results/fs/FileSystemObserver.https.tentative.window.html?label=experimental&label=master&aligned
>
> Flag name on chrome://flags
>
> file-system-observer
>
> Finch feature name
>
> FileSystemObserver
>
> Requires code in //chrome?
>
> False
>
> Tracking bug
>
> https://issues.chromium.org/40105284
>
> Launch bug
>
> https://launch.corp.google.com/launch/4261040
>
> Estimated milestones
>
> Origin trial desktop first
>
> 129
>
> Origin trial desktop last
>
> 134
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/4622243656630272?gate=5110010073317376
>
> Links to previous Intent discussions
>
> Intent to prototype:
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGnvaEXNQ0OUo61DXeuhzARPyOu_E6vA6VsD6%2BBwVDGW_0BQJw%40mail.gmail.com
>
> 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/CAPhTbOjWuKV_MpRhG3bZ3Oj%3Dy5eQCvdR6iGBDrM%2BqTGpwgiWGQ%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/CAOmohSLWO3ZsMZ6VzwytSrGZ5eYAp_PVKx3kOek1kSkp_A3pEw%40mail.gmail.com.

Re: [blink-dev] Web-Facing Change PSA: Coalesced/predicted events in untrusted PointerEvents will retain original targets

[Yoav Weiss (@Shopify)]

On Mon, Jul 29, 2024 at 5:04 PM Mustaq Ahmed  wrote:

> Re WebKit support: they have started implementing
> <https://github.com/WebKit/standards-positions/issues/374#issuecomment-2253920961>
>  getCoalescedEvents(),
> as per their update 2 days ago, yayy!  Note that this PSA is about a corner
> case of that API, more below.
>
> ---
>
> Re high use-counter: I agree with Rick that the use-counter is most likely
> dominated by JS enumeration for cloning purposes, and I guess an http
> archive analysis could confirm that.
>
> But more importantly, this PSA is not about the expected/common-sense
> usage of getCoalescedEvents() to "read" the low-level trusted events that
> are skipped by browser's RAF-aligned event dispatch.  If the JS, for
> whatever reasons, dumps into an untrusted PointerEvent an arbitrary list of
> targets and offsetX/Y values ("arbitrary" in the sense that those values
> were not returned by a trusted event's getCoalescedEvents list),
> according to the spec the JS should be able to read back the values it
> wrote.  We are not aware of any real use-case that could be affected by
> this change.
>

Thanks for the explanation! I'd be slightly more comfortable with this
change if a quick HTTPArchive scan revealed that the usecounter is indeed
mostly enumeration or otherwise unaffected. But I trust your expertise on
this being very niche.


>
>
> On Fri, Jul 26, 2024 at 12:37 PM Rick Byers  wrote:
>
>>
>>
>> On Fri, Jul 26, 2024 at 12:17 PM Yoav Weiss (@Shopify) <
>> yoavwe...@chromium.org> wrote:
>>
>>>
>>>
>>> On Fri, Jul 26, 2024 at 5:04 PM Rick Byers  wrote:
>>>
>>>>
>>>>
>>>> On Fri, Jul 26, 2024 at 7:37 AM Yoav Weiss (@Shopify) <
>>>> yoavwe...@chromium.org> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, Jul 17, 2024 at 4:25 PM Mustaq Ahmed 
>>>>> wrote:
>>>>>
>>>>>> Contact emailsmus...@chromium.org
>>>>>>
>>>>>> Specification
>>>>>> https://w3c.github.io/pointerevents/#populating-and-maintaining-the-coalesced-and-predicted-events-lists
>>>>>>
>>>>>> Summary
>>>>>>
>>>>>> For untrusted (i.e. JS constructed) PointerEvents, the events
>>>>>> returned by PointerEvent.getCoalescedEvents() and
>>>>>> PointerEvent.getPredictedEvents() will maintain their original targets 
>>>>>> and
>>>>>> offsetX/Y coordinates, instead of behaving like trusted events where 
>>>>>> these
>>>>>> fields are affected by the parent (container) event.
>>>>>>
>>>>>>
>>>>>> Blink componentBlink>Input
>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EInput>
>>>>>>
>>>>>> TAG reviewNone
>>>>>>
>>>>>> TAG review statusNot applicable
>>>>>>
>>>>>> Risks
>>>>>>
>>>>>>
>>>>>> Interoperability and Compatibility
>>>>>>
>>>>>> None
>>>>>>
>>>>>
>>>>> Can you expand on that? Isn't something that developers can somehow
>>>>> rely on?
>>>>>
>>>>
>>>> Maybe in theory, but coalesced/predicted points are so niche, combined
>>>> with constructed events, it seems really unlikely to me that anyone would
>>>> notice.
>>>>
>>>
>>> I could be missing something but the usecounters for coalesced
>>> <https://chromestatus.com/metrics/feature/timeline/popularity/4859> don't
>>> seem that niche (predicted
>>> <https://chromestatus.com/metrics/feature/timeline/popularity/2971> is
>>> indeed tiny).
>>>
>>
>> Coalesced events are really useful only for art scenarios like drawing
>> fine curves (https://rbyers.github.io/paint.html#cpoints for a demo).
>> They report events at higher than the rendering frame rate, so AFAIK
>> there's only downside (wasted work) to using them for the 99% case of
>> scenarios where you want RAF-aligned events.
>>
>> When I saw this high use counter I was initially shocked but then
>> remembered the common practice of some frameworks cloning all details of an
>> input event into their own objects. We've struggled before with input event
>&

Re: [blink-dev] Web-Facing Change PSA: Coalesced/predicted events in untrusted PointerEvents will retain original targets

[Yoav Weiss (@Shopify)]

On Fri, Jul 26, 2024 at 5:04 PM Rick Byers  wrote:

>
>
> On Fri, Jul 26, 2024 at 7:37 AM Yoav Weiss (@Shopify) <
> yoavwe...@chromium.org> wrote:
>
>>
>>
>> On Wed, Jul 17, 2024 at 4:25 PM Mustaq Ahmed  wrote:
>>
>>> Contact emailsmus...@chromium.org
>>>
>>> Specification
>>> https://w3c.github.io/pointerevents/#populating-and-maintaining-the-coalesced-and-predicted-events-lists
>>>
>>> Summary
>>>
>>> For untrusted (i.e. JS constructed) PointerEvents, the events returned
>>> by PointerEvent.getCoalescedEvents() and PointerEvent.getPredictedEvents()
>>> will maintain their original targets and offsetX/Y coordinates, instead of
>>> behaving like trusted events where these fields are affected by the parent
>>> (container) event.
>>>
>>>
>>> Blink componentBlink>Input
>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EInput>
>>>
>>> TAG reviewNone
>>>
>>> TAG review statusNot applicable
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> None
>>>
>>
>> Can you expand on that? Isn't something that developers can somehow rely
>> on?
>>
>
> Maybe in theory, but coalesced/predicted points are so niche, combined
> with constructed events, it seems really unlikely to me that anyone would
> notice.
>

I could be missing something but the usecounters for coalesced
<https://chromestatus.com/metrics/feature/timeline/popularity/4859> don't
seem that niche (predicted
<https://chromestatus.com/metrics/feature/timeline/popularity/2971> is
indeed tiny).

This sounds like a tiny bug fix to me, arguably not even worthy of a PSA
> (but thanks for the extra diligence Mustaq!). Constructed events are
> supposed to just be however they were constructed. Of course we can always
> be surprised by even tiny-seeming bug-fixes...
>
>
>>>
>>> *Gecko*: Shipped/Shipping (
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1750994)
>>>
>>> *WebKit*: No signal
>>>
>>
>> Would this take us further away from WebKit interop? What's the current
>> state of their implementation?
>>
>
> getCoalescedPoints and getPredictedPoints aren't implemented by WebKit at
> all
>
>
>>
>>
>>>
>>> *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
>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>>> ?Yes
>>>
>>>
>>> https://wpt.fyi/results/pointerevents/pointerevent_constructor.https.html?label=experimental&label=master&aligned
>>>
>>>
>>> Flag name on chrome://flagsNone
>>>
>>> Finch feature nameNone
>>>
>>> Non-finch justificationNone
>>>
>>> Requires code in //chrome?False
>>>
>>> Tracking bughttps://issues.chromium.org/353538500
>>>
>>> Estimated milestones
>>> Shipping on desktop 128
>>> Shipping on Android 128
>>> Shipping on WebView 128
>>>
>>> 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/5106728480538624?gate=5128518594461696
>>>
>>> This intent message was generated by Chrome Platform Status
>>> <https://chromestatus.com/>.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "blink-dev" group.
>&g

Re: [blink-dev] Intent to Ship: Attribution Reporting Feature: Changes to source-destination-limit logic

[Yoav Weiss (@Shopify)]

LGTM3

On Fri, Jul 26, 2024 at 4:49 PM Nan Lin  wrote:

>
>
> On Fri, Jul 26, 2024 at 10:30 PM Yoav Weiss (@Shopify) <
> yoavwe...@chromium.org> wrote:
>
>> Thanks!! Do we have any stats RE how often the limits are exceeded? Is it
>> fair to assume it's a rare occasion?
>>
> The metric shows that the limits are exceeded rarely, and the change is
> based on feedbacks of a few ad-techs that exceed the limit.
>
>>
>> On Fri, Jul 26, 2024 at 3:36 PM Nan Lin  wrote:
>>
>>> Thanks Yoav. Please see the inline response.
>>>
>>> Best,
>>> Nan
>>>
>>> On Fri, Jul 26, 2024 at 5:09 PM Yoav Weiss (@Shopify) <
>>> yoavwe...@chromium.org> wrote:
>>>
>>>>
>>>> On Thu, Jul 25, 2024 at 11:24 PM Chris Harrelson 
>>>> wrote:
>>>>
>>>>> LGTM2
>>>>>
>>>>> On Mon, Jul 22, 2024 at 11:42 AM Mike Taylor 
>>>>> wrote:
>>>>>
>>>>>> > This change will not cause any site breakage or change for end
>>>>>> users of Chrome.
>>>>>>
>>>>>> LGTM1
>>>>>> On 7/11/24 3:48 PM, 'Akash Nadan' via blink-dev wrote:
>>>>>>
>>>>>> Contact emails
>>>>>>
>>>>>> akashna...@google.com, lin...@chromium.org, johni...@chromium.org
>>>>>>
>>>>>> Explainer
>>>>>>
>>>>>> Attribution Reporting with event-level reports
>>>>>> <https://github.com/WICG/attribution-reporting-api/blob/main/EVENT.md>
>>>>>>
>>>>>> Attribution Reporting API with Aggregatable Reports
>>>>>> <https://github.com/WICG/attribution-reporting-api/blob/main/AGGREGATE.md>
>>>>>>
>>>>>> Aggregation Service for the Attribution Reporting API
>>>>>> <https://github.com/WICG/attribution-reporting-api/blob/main/AGGREGATION_SERVICE_TEE.md>
>>>>>>
>>>>>> Specification
>>>>>>
>>>>>> https://wicg.github.io/attribution-reporting-api/
>>>>>>
>>>>>> Blink component
>>>>>>
>>>>>> Internals > AttributionReporting
>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3EAttributionReporting>
>>>>>>
>>>>>> TAG review
>>>>>>
>>>>>> Still under review
>>>>>> <https://github.com/w3ctag/design-reviews/issues/724> under the
>>>>>> original I2S for the Attribution Reporting API
>>>>>>
>>>>>> TAG review status
>>>>>>
>>>>>> Pending
>>>>>>
>>>>>> Summary
>>>>>>
>>>>>> We are landing the following change to the Attribution Reporting API
>>>>>> focused on:
>>>>>>
>>>>>>-
>>>>>>
>>>>>>Improving utility by changing the methodology for a rate limit
>>>>>>
>>>>>>
>>>>>> This change is based on ad-tech feedback that we have heard regarding
>>>>>> a current rate limit for the Attribution Reporting API.
>>>>>>
>>>>>> Currently the API has a limit called the source-destination-limit
>>>>>> which allows API callers to register up to 100 distinct destinations per
>>>>>> {source site, reporting site} applied to all unexpired sources per 
>>>>>> browser.
>>>>>>
>>>>>> This rate limit also uses a LIFO model (last-in-first-out) in the
>>>>>> sense that once the limit is reached, any new source registrations will 
>>>>>> be
>>>>>> rejected.
>>>>>>
>>>>>> We have heard feedback from multiple ad-techs that they are running
>>>>>> into this limit which then causes some amount of loss in terms of not 
>>>>>> being
>>>>>> able to register new sources.
>>>>>>
>>>>>> This change proposes to use a FIFO model (first-in-first-out) for
>>>>>> this rate limit. So once the limit is reached, any new source 
>>>>>> registration
>>>>>> will cause the API to delete the oldest pending source registration for 
>>>>>> the

Re: [blink-dev] Intent to Ship: Attribution Reporting Feature: Changes to source-destination-limit logic

[Yoav Weiss (@Shopify)]

Thanks!! Do we have any stats RE how often the limits are exceeded? Is it
fair to assume it's a rare occasion?

On Fri, Jul 26, 2024 at 3:36 PM Nan Lin  wrote:

> Thanks Yoav. Please see the inline response.
>
> Best,
> Nan
>
> On Fri, Jul 26, 2024 at 5:09 PM Yoav Weiss (@Shopify) <
> yoavwe...@chromium.org> wrote:
>
>>
>> On Thu, Jul 25, 2024 at 11:24 PM Chris Harrelson 
>> wrote:
>>
>>> LGTM2
>>>
>>> On Mon, Jul 22, 2024 at 11:42 AM Mike Taylor 
>>> wrote:
>>>
>>>> > This change will not cause any site breakage or change for end users
>>>> of Chrome.
>>>>
>>>> LGTM1
>>>> On 7/11/24 3:48 PM, 'Akash Nadan' via blink-dev wrote:
>>>>
>>>> Contact emails
>>>>
>>>> akashna...@google.com, lin...@chromium.org, johni...@chromium.org
>>>>
>>>> Explainer
>>>>
>>>> Attribution Reporting with event-level reports
>>>> <https://github.com/WICG/attribution-reporting-api/blob/main/EVENT.md>
>>>>
>>>> Attribution Reporting API with Aggregatable Reports
>>>> <https://github.com/WICG/attribution-reporting-api/blob/main/AGGREGATE.md>
>>>>
>>>> Aggregation Service for the Attribution Reporting API
>>>> <https://github.com/WICG/attribution-reporting-api/blob/main/AGGREGATION_SERVICE_TEE.md>
>>>>
>>>> Specification
>>>>
>>>> https://wicg.github.io/attribution-reporting-api/
>>>>
>>>> Blink component
>>>>
>>>> Internals > AttributionReporting
>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3EAttributionReporting>
>>>>
>>>> TAG review
>>>>
>>>> Still under review
>>>> <https://github.com/w3ctag/design-reviews/issues/724> under the
>>>> original I2S for the Attribution Reporting API
>>>>
>>>> TAG review status
>>>>
>>>> Pending
>>>>
>>>> Summary
>>>>
>>>> We are landing the following change to the Attribution Reporting API
>>>> focused on:
>>>>
>>>>-
>>>>
>>>>Improving utility by changing the methodology for a rate limit
>>>>
>>>>
>>>> This change is based on ad-tech feedback that we have heard regarding a
>>>> current rate limit for the Attribution Reporting API.
>>>>
>>>> Currently the API has a limit called the source-destination-limit which
>>>> allows API callers to register up to 100 distinct destinations per {source
>>>> site, reporting site} applied to all unexpired sources per browser.
>>>>
>>>> This rate limit also uses a LIFO model (last-in-first-out) in the sense
>>>> that once the limit is reached, any new source registrations will be
>>>> rejected.
>>>>
>>>> We have heard feedback from multiple ad-techs that they are running
>>>> into this limit which then causes some amount of loss in terms of not being
>>>> able to register new sources.
>>>>
>>>> This change proposes to use a FIFO model (first-in-first-out) for this
>>>> rate limit. So once the limit is reached, any new source registration will
>>>> cause the API to delete the oldest pending source registration for the same
>>>> {source site, reporting site} pair, and allow the new source registration
>>>> to be stored.
>>>>
>>>> In order to safely support this FIFO model, the following rate limit
>>>> needs to also be added to the API:
>>>>
>>>>-
>>>>
>>>>100 distinct destinations per {source site, reporting site, 24
>>>>hours}.
>>>>-
>>>>
>>>>   This new rate limit will help to prevent any attacks where an
>>>>   adversary may want to try to cycle through many different 
>>>> destinations in
>>>>   one attempt
>>>>
>>>>
>>>> In terms of the rollout plan for this feature, we would like to
>>>> directly switch this rate limit from being a LIFO model to a FIFO model.
>>>> This means the LIFO model will no longer be an option. Based on feedback we
>>>> have heard, this type of model where more recent sources are given a
>>>> stronger preference is in line with how ad-techs think ab

Re: [blink-dev] Web-Facing Change PSA: Coalesced/predicted events in untrusted PointerEvents will retain original targets

[Yoav Weiss (@Shopify)]

On Wed, Jul 17, 2024 at 4:25 PM Mustaq Ahmed  wrote:

> Contact emailsmus...@chromium.org
>
> Specification
> https://w3c.github.io/pointerevents/#populating-and-maintaining-the-coalesced-and-predicted-events-lists
>
> Summary
>
> For untrusted (i.e. JS constructed) PointerEvents, the events returned by
> PointerEvent.getCoalescedEvents() and PointerEvent.getPredictedEvents()
> will maintain their original targets and offsetX/Y coordinates, instead of
> behaving like trusted events where these fields are affected by the parent
> (container) event.
>
>
> Blink componentBlink>Input
> 
>
> TAG reviewNone
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> None
>

Can you expand on that? Isn't something that developers can somehow rely
on?


>
> *Gecko*: Shipped/Shipping (
> https://bugzilla.mozilla.org/show_bug.cgi?id=1750994)
>
> *WebKit*: No signal
>

Would this take us further away from WebKit interop? What's the current
state of their implementation?


>
> *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
> 
> ?Yes
>
>
> https://wpt.fyi/results/pointerevents/pointerevent_constructor.https.html?label=experimental&label=master&aligned
>
>
> Flag name on chrome://flagsNone
>
> Finch feature nameNone
>
> Non-finch justificationNone
>
> Requires code in //chrome?False
>
> Tracking bughttps://issues.chromium.org/353538500
>
> Estimated milestones
> Shipping on desktop 128
> Shipping on Android 128
> Shipping on WebView 128
>
> 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/5106728480538624?gate=5128518594461696
>
> 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/CAB0cuO6ogVhba4bQpZH9GE3Mh%2B04qqpvvorgXRZ_AJ-FQjwobQ%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/CAOmohSJyttfwuyqP-BtvOoUe5wEK5tkcgVRSz3%2B6RiaxBzK-sw%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Web Authentication API: JSON serialization methods

[Yoav Weiss (@Shopify)]

Friendly reminder that this is blocked on addressing Domenic's feedback RE 
the WPTs :)

On Wednesday, July 17, 2024 at 8:26:22 PM UTC+2 mart...@google.com wrote:

> Work is underway to enable WebAuthn broadly on WebView. As far as I'm 
> aware, that work hasn't quite roll out yet due to some dependency on the 
> Android side. I'll ask the people working on that to ensure they update the 
> MDN compat table once we know a minimum version.
>
> Once WebAuthn is available in WebView, the JSON serialization parts are 
> included there automatically.
>
>
> On Wed, Jul 17, 2024 at 6:31 AM Yoav Weiss (@Shopify) <
> yoavwe...@chromium.org> wrote:
>
>>
>>
>> On Sat, Jul 13, 2024 at 1:42 AM 'Martin Kreichgauer' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> Contact emailsmarti...@google.com
>>>
>>> Explainer
>>> https://github.com/w3c/webauthn/wiki/Explainer:-JSON-Serialization-Methods
>>>
>>> Specificationhttps://w3c.github.io/webauthn/#publickeycredential
>>>
>>> Summary
>>>
>>> The WebAuthn PublicKeyCredential.toJSON(), 
>>> parseCreationOptionsFromJSON() and parseRequestOptionsFromJSON() methods 
>>> let developers serialize a WebAuthn response into a JSON object or 
>>> deserialize a WebAuthn request object from its JSON representation.
>>>
>>>
>>> Blink componentBlink>WebAuthentication 
>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EWebAuthentication>
>>>
>>> TAG reviewNone
>>>
>>> TAG review statusNot applicable
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> None
>>>
>>>
>>> *Gecko*: Shipped/Shipping (
>>> https://developer.mozilla.org/en-US/docs/Web/API/PublicKeyCredential/toJSON#browser_compatibility
>>> )
>>>
>>> *WebKit*: No signal
>>>
>>> *Web developers*: Positive (https://github.com/github/webauthn-json) 
>>> webauthn-json is a widely used polyfill for this API maintained by Github.
>>>
>>> *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
>>>
>>> This feature is implemented in Blink renderer code and shipping on all 
>>> platforms.
>>>
>>
>> https://developer.mozilla.org/en-US/docs/Web/API/PublicKeyCredential 
>> says that the broader feature is not available in Android WebView.
>> Is that correct? If so, can you clarify what that means for this feature?
>>  
>>
>>>
>>>
>>> Is this feature fully tested by web-platform-tests 
>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>>> ?Yes
>>>
>>>
>>> https://wpt.fyi/results/webauthn/public-key-credential-creation-options-from-json.https.window.html
>>>  
>>> https://wpt.fyi/results/webauthn/public-key-credential-request-options-from-json.https.window.html
>>>  
>>> https://wpt.fyi/results/webauthn/public-key-credential-to-json.https.window.html
>>>
>>>
>>> DevTrial instructions
>>> https://docs.google.com/document/d/e/2PACX-1vSl4jywfU4xD3fkWrC-T5hHI79xs90oOq9tVSx4M63WkcI-wuk-nnFlPlDIAttrpTEd5BbXABJnDuxT/pub
>>>
>>> Flag name on chrome://flagsenable-experimental-web-platform-features
>>>
>>> Finch feature nameWebAuthenticationJSONSerialization
>>>
>>> Requires code in //chrome?False
>>>
>>> Tracking bug
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1401128
>>>
>>> Availability expectationFirefox has shipped an implementation already.
>>>
>>> Adoption expectationThere is a widely used polyfill (
>>> https://github.com/github/webauthn-json), which suggests there is 
>>> demand from developers for this feature.
>>>
>>> Estimated milestones
>>> Shipping on desktop 128
>>> DevTrial on desktop 128
>>> Shipping on Android 128
>>> DevTrial on Android 128
>>> Shipping on WebView 128
>

Re: [blink-dev] Intent to Ship: Deprecation of non-standard declarative shadow DOM serialization

[Yoav Weiss (@Shopify)]

LGTM1 to remove in M129, given the usecounter numbers

On Wed, Jul 10, 2024 at 11:35 PM Mason Freed  wrote:

> I'd like to check back in on this deprecation. The drop in usage from May
> continued into June and July, with current numbers hovering around 0.003%:
> https://chromestatus.com/metrics/feature/timeline/popularity/3874. I
> added deprecation messages in M127, but that's not even in stable yet. My
> guess would be that usage will continue to drop as 127 goes to stable.
>
> Given the above, I'd like to re-request permission to remove the feature
> in M129, assuming all of the trends continue to look good.
>
> Thanks,
> Mason
>
>
> On Tuesday, June 4, 2024 at 12:28:54 AM UTC-7 Daniel Bratell wrote:
>
>> LGTM3 for the deprecation in 127. I'd like to hold off on stamping the
>> removal approval until later but threatening (well, targetting) removal in
>> 129 seems ok.
>>
>> /Daniel
>> On 2024-05-31 02:44, Mason Freed wrote:
>>
>> Thanks for the LGTMs!
>>
>> On Wed, May 29, 2024 at 7:54 AM Daniel Bratell  wrote:
>>
>>> Deprecating seems fine, especially since it's a relatively new API and
>>> less likely to be used on non-maintained sites, but removal seems a bit
>>> premature even if done slowly. Would it be better to let it bake a few
>>> milestones and see if a scary deprecation message threatening removal after
>>> the summer drives the usage down?
>>>
>> I'm starting to get the feeling that this would be a good idea. The
>> Enterprise folks on the chromestatus gate also asked for something similar
>> - 3 milestones of warning period before the deprecation.
>>
>> I'm inclined to just do that - it feels safer, and I don't think there's
>> a huge rush to turn this off. Especially with usage going in the right
>> direction, instead of further up.
>>
>> So I've modified the chromestatus
>> <https://chromestatus.com/feature/5081733588582400> to show a shipping
>> milestone of M129. Does that work? And I'll add a big console error
>> starting in M127.
>>
>>
>> On Wed, May 29, 2024 at 1:22 AM Yoav Weiss (@Shopify) <
>> yoav...@chromium.org> wrote:
>>
>>> Your questions prompted me to take a closer look at the sample sites
>>>>> still hitting the use counter. I took a close look at the first 10 entries
>>>>> listed, and I think I found perhaps where the big drop came from. Of those
>>>>> ten sites, seven do not use getInnerHTML or getHTML at all. Likely not
>>>>> coincidentally, all seven are Shopify sites. My guess would be that 
>>>>> Shopify
>>>>> very recently removed its usage of getInnerHTML?
>>>>>
>>>>
>>> FWIW, internal code search brought up nothing. It's possible that this
>>> is a 3P app
>>> <https://shopify.dev/docs/apps/build/online-store/theme-app-extensions> that
>>> changed their use. (or that I'm simply failing to find the relevant change
>>> :D)
>>>
>>
>> Thanks for checking that! It's always hard to figure out what happened
>> after the fact like this.
>>
>>
>>> The plan to ramp down usage is a good one, although as we previously
>>>> discussed in a different thread, it may cause some debugging challenges for
>>>> developers. It is worthwhile to also reach out to some of the developers
>>>> whose sites you noticed would throw an exception -- just an FYI email that
>>>> this feature is being removed. Given the fairly low usage, readily
>>>> available fixes (via getHTML() or possibly innerHTML) and your commitment
>>>> to monitor for breakages, this looks good to me.
>>>>
>>>
>> I might want to tweak this plan now that we're extending by 2/3
>> milestones. Maybe now (after console warnings) it makes more sense to just
>> disable in one shot?
>>
>> I'll try to reach out to the sites I noticed.
>>
>> Thanks,
>> Mason
>>
>>
>>
>>
>>> /Daniel
>>> On 2024-05-29 10:22, Yoav Weiss (@Shopify) wrote:
>>>
>>> LGTM2
>>>
>>> On Tue, May 28, 2024 at 11:10 PM Vladimir Levin 
>>> wrote:
>>>
>>>>
>>>>
>>>> On Tue, May 28, 2024 at 12:30 PM Mason Freed 
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Mon, May 27, 2024 at 8:15 AM Vladimir Levin 
>>>>> wrote:
>>>>>
>>>>

Re: [blink-dev] Intent to Experiment: FedCM Bundle 6: Continuation API, Scope API, Scaling Well-Known, Custom account labels

[Yoav Weiss (@Shopify)]

Shifting the OT milestones (without adding more milestones through which
the OT is exposed) is fine and doesn't require further approvals. Thanks! :)

On Wed, Jul 17, 2024 at 8:28 PM Christian Biesinger 
wrote:

> Sorry, one more request, can we shift this OT to 127 until 130? It took a
> while for our partner to get ready for the trial.
>
> Christian
>
> On Tue, Jul 16, 2024 at 12:43 PM Chris Harrelson 
> wrote:
>
>>
>>
>> On Tue, Jul 16, 2024 at 9:34 AM Christian Biesinger <
>> cbiesin...@chromium.org> wrote:
>>
>>> Hi,
>>>
>>> is my understanding correct that we do not need further approvals to add
>>> Android to the origin trial in 128? (so far we only did desktop)
>>>
>>
>> That's fine by me! LGTM
>>
>>
>>>
>>> Thanks,
>>> Christian
>>>
>>> On Wed, Apr 24, 2024 at 12:20 PM Chris Harrelson 
>>> wrote:
>>>
 Great thank you. LGTM to experiment for M126-M129.

 On Wed, Apr 24, 2024 at 9:08 AM Christian Biesinger <
 cbiesin...@chromium.org> wrote:

> Sorry about that, done.
>
> On Wed, Apr 24, 2024 at 11:52 AM Chris Harrelson <
> chris...@chromium.org> wrote:
>
>> Hi,
>>
>> Please fill out the Privacy, Security and Debuggability sections for
>> this origin trial, they'll need to be started before we can approve.
>>
>> On Wed, Apr 24, 2024 at 8:39 AM Christian Biesinger <
>> cbiesin...@chromium.org> wrote:
>>
>>> Contact emails
>>>
>>> cbiesin...@chromium.org
>>>
>>> Explainer
>>>
>>> https://github.com/fedidcg/FedCM/issues/555
>>>
>>> https://github.com/fedidcg/FedCM/issues/556
>>>
>>> https://github.com/fedidcg/FedCM/issues/559
>>>
>>> https://github.com/fedidcg/FedCM/issues/552
>>>
>>> https://github.com/fedidcg/FedCM/issues/553
>>>
>>> Specification
>>>
>>> None
>>>
>>> Summary
>>>
>>> This bundles a few FedCM features that we would like to launch at
>>> the same time:
>>>
>>> Continuation API:
>>>
>>> https://github.com/fedidcg/FedCM/issues/555
>>>
>>> This lets the IDP open a popup window to finish the sign-in flow
>>> after potentially collecting additional information.
>>>
>>> Parameters API:
>>>
>>> https://github.com/fedidcg/FedCM/issues/556
>>>
>>> This lets RPs pass additional data to the ID assertion endpoint
>>>
>>> Scope API:
>>>
>>> https://github.com/fedidcg/FedCM/issues/559
>>>
>>> This lets RPs bypass the data sharing prompt in favor of the IDP
>>> prompting
>>>
>>> Scaling well-known:
>>>
>>> https://github.com/fedidcg/FedCM/issues/552
>>>
>>> This lets IDPs use different config files in different contexts
>>> without weakening FedCM privacy properties, by allowing one accounts
>>> endpoint for the eTLD+1 (instead of one config file, which is more 
>>> limiting
>>> than necessary)
>>>
>>> Account labels:
>>>
>>> https://github.com/fedidcg/FedCM/issues/553
>>>
>>> Combined with the previous proposal, this allows filtering the
>>> account list per config file without providing additional entropy to the
>>> IDP.
>>>
>>>
>>> Blink component
>>>
>>> Blink>Identity>FedCM
>>> 
>>>
>>> TAG review
>>>
>>> https://github.com/w3ctag/design-reviews/issues/945
>>>
>>> TAG review status
>>>
>>> Pending
>>>
>>> Risks
>>>
>>> Interoperability and Compatibility
>>>
>>> None
>>>
>>>
>>> Gecko: No signal
>>>
>>> WebKit: No signal (
>>> https://github.com/WebKit/standards-positions/issues/336)
>>>
>>> Web developers: Positive (
>>> https://github.com/fedidcg/FedCM/issues/488#issuecomment-1749682526)
>>> Also:
>>> https://github.com/fedidcg/FedCM/issues/496#issuecomment-1781364610
>>> https://github.com/fedidcg/FedCM/issues/533#issuecomment-1878581998
>>>
>>> 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
>>>
>>>
>>> Goals for experimentation
>>>
>>> Make sure that the API and user experience works well for identity
>>> providers, relying parties and users.
>>>
>>> Ongoing technical constraints
>>>
>>> None
>>>
>>>
>>> Debuggability
>>>
>>> No special support needed
>>>
>>>
>>> Will this feature be supported on all six Blink platforms (Windows,
>>> Mac, Linux, ChromeOS, Android, and Android WebView)?
>>>
>>> No
>>>
>>> FedCM in general is not supported in webview
>>>
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 

Re: [blink-dev] Intent to Ship: Protected Audience: cross-origin trusted signals fetches

[Yoav Weiss (@Shopify)]

On Mon, Jul 22, 2024 at 5:26 PM 'Maksim Orlovich' via blink-dev <
blink-dev@chromium.org> wrote:

> Note: https://github.com/WICG/turtledove/pull/1230 is an updated link for
> the second spec clarification pull requests, and the first one of the two
> has landed.
>
>
> On Fri, Jul 19, 2024 at 4:40 PM Paul Jensen 
> wrote:
>
>> Contact emails
>>
>> pauljen...@chromium.org
>>
>>
>> Explainer
>>
>> https://github.com/WICG/turtledove/pull/1156
>>
>
https://github.com/WICG/turtledove/blob/main/FLEDGE.md#311-cross-origin-trusted-server-signals
is an easier way of reading the same explainer text.


>
>> Specification
>>
>> https://github.com/WICG/turtledove/pull/1197
>>
>> Side note: there are two related clarification spec PRs (1
>> , 2
>> ) that are soon to land
>> but our spec mentor is fine with the spec in its current state, because the
>> new PRs are queued up, even if they don't land right away. The serious meat
>> in the main PR is in place, and any gaps in interoperability are right
>> behind.
>>
>>
>> Summary
>>
>> This feature allows the Protected Audience (PA) API to fetch real-time
>> bidding and scoring signals from origins other than the origin of the buyer
>> and seller's scripts. This is done by enabling CORS on these requests and
>> some additional checks and requirements, and changes to prevent misuse.
>>
>
Can you expand on the "changes to prevent misuse" part?
What misuse are we concerned with? What have we done to avoid it?


> We have heard that this is a critical feature request because dynamic
>> server-generated responses for the real-time bidding and scoring signals
>> are likely to not be served from the same servers as static resources like
>> the bidding and scoring scripts. Furthermore, in the future when the
>> real-time bidding and scoring signals requests will be required to be
>> served from TEEs, they’re even more likely to be served from different
>> servers.
>>
>> We’re also including some ergonomic improvements to our PA feature
>> detection API that make it easier to query PA feature support without
>> modifying on-page JavaScript.
>>
>>
>> Blink component
>>
>> Blink>InterestGroups
>> 
>>
>>
>> TAG review
>>
>> For Protected Audience:
>> https://github.com/w3ctag/design-reviews/issues/723
>>
>>
>> TAG review status
>>
>> Completed for Protected Audience, resolved unsatisfied.
>>
>>
>> RisksInteroperability and Compatibility
>>
>> Feature represents optional new behavior that shouldn’t break existing
>> usage.
>>
>>
>> Gecko & WebKit: No signal on parent proposal, Protected Audience.  Asked
>> in the Mozilla forum here
>> , and in the
>> Webkit forum here
>> .
>>
>>
>> Edge: Edge has announced plans to support the Ad Selection API
>> 
>> which shares much of its API surface with Protected Audience.
>>
>>
>> Web developers: Requested by 5+ companies (including Microsoft Ads) in
>> multiple GitHub issues: 1 ,
>> 2 , 3
>> .
>>
>>
>> Debuggability
>>
>> Protected Audience trusted signals requests show up in the DevTools
>> Network pane.
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, ChromeOS, Android, and Android WebView)?
>>
>> It will be supported on all platforms that support Protected Audience, so
>> all but WebView.
>>
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?
>>
>> Yes, in 1
>>  and 2
>> .
>>
>>
>> Flag name on chrome://flags
>>
>> None
>>
>>
>> Finch feature name
>>
>> FledgePermitCrossOriginTrustedSignals
>>
>>
>> Requires code in //chrome?
>>
>> False
>>
>>
>> Estimated milestones
>>
>> Shipping on desktop and Android in M127.
>>
>>
>> Anticipated spec changes
>>
>> None
>>
>>
>> Link to entry on the Chrome Platform Status
>>
>> https://chromestatus.com/feature/5861201518264320
>>
>>
>> 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/CABQTWrkWa-a9HmaqoSdkVhQ8YbMpY1Q-AvJtQLsyCcAfN8jBHQ%40mail.gmail.com
>> 

Re: [blink-dev] Intent to Ship:

[Yoav Weiss (@Shopify)]

I think you want to re-send this with the correct title (that includes the
feature name), to ensure this makes it into the API owner tooling

On Tue, Jul 23, 2024 at 9:05 AM Shuangshuang Zhou <
shuangshuang.z...@intel.com> wrote:

> Contact emailsshuangshuang.z...@intel.com
>
> ExplainerNone
>
> Specification
> https://w3c.github.io/selection-api/#scheduling-selectionhange-event
>
> Summary
>
> This feature is not to fire selectionchange event when there is already
> one pending. For web developers, selectionchange event listeners will be
> called less often with this feature. Before this feature, every time the
> mutation of the selection on one target(input/textarea/document) would make
> the listener to be called once.
>
> Now with this feature, before the selectionchange event listner is finally
> called, multiple mutations of the selection on one target would make the
> listener to be called only once.
>
>
> Blink componentBlink>Editing>Selection
> 
>
> TAG reviewNone
>
> TAG review statusIssues addressed
>
> Risks
>
>
> Interoperability and Compatibility
>
> Interoperability risk is low because Firefox and Safari have shipped this
> according to the specification. It has none compatibility risk since this
> is nor a removal. W3C spec for this feature:
> https://w3c.github.io/selection-api/#scheduling-selectionhange-event
>
>
> *Gecko*: Shipped/Shipping (
> https://hg.mozilla.org/integration/autoland/rev/6632631a15ec)
>
> *WebKit*: Shipped/Shipping (https://commits.webkit.org/276388@main) This
> feature is shipped in Safari Technology Preview.
>
> *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?
>
> Low WebView application risks.
>
>
> 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
> 
> ?Yes
>
> Some related WPT tests results have been updated in our commit. Commit
> url: https://chromium-review.googlesource.com/c/chromium/src/+/5494116
> Related wpt tests(all passed in the try job):
> *third_party/blink/web_tests/external/wpt/selection/onselectionchange-on-distinct-text-controls.html
> *third_party/blink/web_tests/external/wpt/selection/onselectionchange-on-document.html
> *third_party/blink/web_tests/external/wpt/selection/onselectionchange-on-document.html
> *third_party/blink/web_tests/external/wpt/selection/textcontrols/selectionchange.html
> *third_party/blink/web_tests/external/wpt/selection/textcontrols/selectionchange-on-shadow-dom.html
> *third_party/blink/web_tests/fast/events/selectionchange-iframe.html The
> feature is not enabled by default, so in wpt.fyi these tests shoule still
> be failed.
>
>
> On latest wpt.fyi reports, now chromium behaviours the same as Safari
> Preview 198 and FireFox 130, see:
>
> 1.
> https://wpt.fyi/results/selection/onselectionchange-on-document.html?label=experimental&label=master&aligned
>
> 2.
> https://wpt.fyi/results/selection/textcontrols/selectionchange.html?label=experimental&label=master&aligned
>
>
>
> Flag name on chrome://flagsNone
>
> Finch feature nameCoalesceSelectionchangeEvent
>
> Requires code in //chrome?False
>
> Estimated milestones
> Shipping on desktop
> 128
>
> 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/5227302221512704?gate=5124056542871552
>
> 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/81afa74d-0177-4608-9732-245f8999cd0an%40chromium.org
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web 

Re: [blink-dev] Intent to Ship: Attribution Reporting Feature: Changes to source-destination-limit logic

[Yoav Weiss (@Shopify)]

On Thu, Jul 25, 2024 at 11:24 PM Chris Harrelson 
wrote:

> LGTM2
>
> On Mon, Jul 22, 2024 at 11:42 AM Mike Taylor 
> wrote:
>
>> > This change will not cause any site breakage or change for end users of
>> Chrome.
>>
>> LGTM1
>> On 7/11/24 3:48 PM, 'Akash Nadan' via blink-dev wrote:
>>
>> Contact emails
>>
>> akashna...@google.com, lin...@chromium.org, johni...@chromium.org
>>
>> Explainer
>>
>> Attribution Reporting with event-level reports
>> 
>>
>> Attribution Reporting API with Aggregatable Reports
>> 
>>
>> Aggregation Service for the Attribution Reporting API
>> 
>>
>> Specification
>>
>> https://wicg.github.io/attribution-reporting-api/
>>
>> Blink component
>>
>> Internals > AttributionReporting
>> 
>>
>> TAG review
>>
>> Still under review 
>> under the original I2S for the Attribution Reporting API
>>
>> TAG review status
>>
>> Pending
>>
>> Summary
>>
>> We are landing the following change to the Attribution Reporting API
>> focused on:
>>
>>-
>>
>>Improving utility by changing the methodology for a rate limit
>>
>>
>> This change is based on ad-tech feedback that we have heard regarding a
>> current rate limit for the Attribution Reporting API.
>>
>> Currently the API has a limit called the source-destination-limit which
>> allows API callers to register up to 100 distinct destinations per {source
>> site, reporting site} applied to all unexpired sources per browser.
>>
>> This rate limit also uses a LIFO model (last-in-first-out) in the sense
>> that once the limit is reached, any new source registrations will be
>> rejected.
>>
>> We have heard feedback from multiple ad-techs that they are running into
>> this limit which then causes some amount of loss in terms of not being able
>> to register new sources.
>>
>> This change proposes to use a FIFO model (first-in-first-out) for this
>> rate limit. So once the limit is reached, any new source registration will
>> cause the API to delete the oldest pending source registration for the same
>> {source site, reporting site} pair, and allow the new source registration
>> to be stored.
>>
>> In order to safely support this FIFO model, the following rate limit
>> needs to also be added to the API:
>>
>>-
>>
>>100 distinct destinations per {source site, reporting site, 24 hours}.
>>-
>>
>>   This new rate limit will help to prevent any attacks where an
>>   adversary may want to try to cycle through many different destinations 
>> in
>>   one attempt
>>
>>
>> In terms of the rollout plan for this feature, we would like to directly
>> switch this rate limit from being a LIFO model to a FIFO model. This means
>> the LIFO model will no longer be an option. Based on feedback we have
>> heard, this type of model where more recent sources are given a stronger
>> preference is in line with how ad-techs think about measuring conversions.
>> Additionally, the API will support a priority field, so that within the
>> FIFO model ad-techs can still specify if certain destinations require a
>> higher priority than others.
>>
>> This change is not backwards compatible since the model for this rate
>> limit will be changing.
>>
>> Can you expand on that?
What would ad-tech folks need to do differently? Am I right to assume that
this would cause attribution breakage only in cases that are currently
exceeding the limit?


>
>> This change will help to reduce the registration and conversion loss
>> ad-techs may see with the current limit.
>>
>>
>> Explainer/Spec changes
>>
>>1.
>>
>>Deactivate earliest destinations if exceeding distinct destination
>>limit for unexpired sources
>>
>>
>>
>> Risks
>> Interoperability and Compatibility
>>
>> This feature is not a backwards compatible change because the behavior
>> for which sources will be rejected or deleted once the source destination
>> limit is hit will now be different. The new behavior is intuitively more in
>> line with how ad-techs measure conversions currently, however there may be
>> some scenarios where keeping older source registrations is more important
>> to an ad-tech, which may still be achieved through the use of the priority
>> field that is part of this feature.
>>
>> This change will not cause any site breakage or change for end users of
>> Chrome. Additionally, once this feature is released it will only be
>> applicable to users running on Chrome M128 and future chrome versions. This
>> change will also not delete any existing source registrations in storage
>> unless the limit is hit and there are source registrations th

Re: [blink-dev] Intent to Ship: Private Aggregation API: filtering IDs

[Yoav Weiss (@Shopify)]

LGTM2

On Friday, July 19, 2024 at 6:56:59 PM UTC+2 Mike Taylor wrote:

> LGTM1
> On 7/17/24 5:24 PM, Alex Turner wrote:
>
> On Mon, Jul 15, 2024 at 11:03 AM Mike Taylor  
> wrote:
>
>> On 7/12/24 10:44 AM, Alex Turner wrote:
>>
>> On Wed, Jul 10, 2024 at 11:25 AM Mike Taylor  
>> wrote:
>>
>>> On 7/8/24 4:05 PM, Alex Turner wrote:
>>>
>>>
>>> Interoperability and Compatibility 
>>>
>>> The Aggregation Service (used to process the aggregatable reports) 
>>> typically allows its releases to be used for up to six months. To reduce 
>>> the compatibility impact of this change, we are waiting until all current 
>>> Aggregation Service releases support the new version before rolling to 
>>> Stable.
>>>
>>> Can you say more about this? How many parties are running these 
>>> services, and do we have any way of knowing what the uptake of new versions 
>>> is, or said differently - can we tell if they're still on older versions?
>>>
>>> Also, what happens if you send the filter ID to an older version?
>>>
>> The Aggregation Service in general has a six-month support schedule 
>> ,
>>  
>> i.e. attempts to use a release more than six months after it was released 
>> will fail. Currently, there are three Aggregation Service releases that are 
>> available for use (2.3, 2.4, 2.5). All previous releases (2.2 and before) 
>> have already reached end-of-support and can no longer be used.
>>
>> I see - thanks. Just a few more questions to help me understand:
>>
>> There's mention of an image hash allowlist - presumably this is how you 
>> enforce versioning on the server side. Is that correct?
>>
> Yep, exactly.
>
>> Release 2.3 does not support the new report format, but we have announced 
>> it will reach end-of-support on August 2nd, i.e. before M128 reaches 
>> Stable. (Note that we have already enabled the feature on Canary for 
>> testing.) Attempting to process reports with the new “1.0” report version 
>> on this release will result in the aggregation job failing with a 
>> descriptive error message. In this case, however, no budget will be 
>> consumed and the aggregation can be re-attempted (either on a newer release 
>> or after excluding the “1.0” reports).
>>
>> Why doesn't this count as a breaking change, per your wiki page? Or the 
>> idea is you don't need to rev the major version number because it will be 
>> unsupported before this feature is usable in Chrome stable?
>>
>
> The Aggregation Service versioning scheme applies to server-side changes 
> only. That is, a breaking change is one that would require an active 
> migration for a partner when they update their Aggregation Service release. 
> As the processing changes on the server are backwards compatible (more 
> detail below), we haven't updated the major version.
>
> When attempting to process the new “1.0” reports, the old Aggregation 
> Service releases (2.3 and before) error out and the new releases (2.4+) 
> succeed. So, we consider that new support to be backwards compatible 
> *server-side*.
>
> OK - understood. These server errors won't affect clients sending the new 
> report version (and I realize I missed the distinction between report and 
> aggregation service version).
>
>
> And when attempting to additionally specify custom filtering_ids *on the 
> server*, Aggregation Service release 2.4 doesn’t let you (always uses the 
> default, discussed below in more detail), while release 2.5 does let you. 
> So, that change should also count as backwards compatible.
>
> Separately, there’s a question of whether the *browser-side* API change 
> (to change the report version/format) is backwards compatible. While 
> Aggregation Service release 2.3 is available, it is a breaking change. But, 
> it will be backwards compatible once all current Aggregation Service 
> releases support the report version (before M128 Stable).
>
>  
>
>> Release 2.4 supports the new report format, but it does not allow for 
>> filtering_ids to be specified for the aggregation; the default value ([0]) 
>> is always used. On this release, existing flows that do not use the new 
>> feature will be unaffected by the report version change.
>>
>> This also feels like a breakage change to me - if I'm using a supported 
>> service version, but I can't use the updated report version because I will 
>> get unexpected/inconsistent behavior with 2.5.
>>
>
> Let me clarify the behavior of Releases 2.4 and 2.5 a bit. On the web API 
> after this change, you can optionally specify a filtering ID for each 
> histogram contribution; if you don’t, the default of 0 is used. On the 
> server API, you can optionally specify which filtering IDs to keep (i.e. 
> all histogram contributions with other filtering IDs are ignored for the 
> aggregation). If you don’t specify any (either because 2.4 doesn’t let you 
> or if you us

Re: [blink-dev] Re: Intent to Ship: Attribution Reporting Feature: Flexible contributions filtering

[Yoav Weiss (@Shopify)]

LGTM3

On Wed, Jul 24, 2024 at 5:42 PM Mike Taylor  wrote:

> LGTM2
> On 7/17/24 6:22 PM, Chris Harrelson wrote:
>
> LGTM1
>
> On Fri, Jul 12, 2024 at 1:10 PM 'Akash Nadan' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Hi All,
>>
>>
>> Just adding some additional detail regarding the interoperability and
>> compatibility of this feature:
>>
>>
>> Interoperability and Compatibility
>>
>> This change is optional and will be fully backwards compatible once
>> Aggregation Service release 2.3 reaches end-of-support on August 2nd
>> (before M128 reaches Stable).
>>
>>
>> Additionally, developers that want to use this new feature will need to
>> upgrade their Aggregation Service release to version 2.5 or later. The
>> Aggregation Service is used to process the aggregatable reports that a
>> developer receives. We have notified partners of these considerations
>> through the API mailing list
>> .
>> A similar feature is being released for the Private Aggregation API,
>> with the same Aggregation Service considerations
>> 
>> .
>>
>> Thanks,
>>
>> Akash
>>
>>
>> On Thursday, July 11, 2024 at 12:54:08 PM UTC-7 Akash Nadan wrote:
>>
>>> Contact emails
>>>
>>> akash...@google.com, lin...@chromium.org, john...@chromium.org
>>>
>>> Explainer
>>>
>>> Attribution Reporting with event-level reports
>>> 
>>>
>>> Attribution Reporting API with Aggregatable Reports
>>> 
>>>
>>> Aggregation Service for the Attribution Reporting API
>>> 
>>>
>>> Specification
>>>
>>> https://wicg.github.io/attribution-reporting-api/
>>>
>>> Blink component
>>>
>>> Internals > AttributionReporting
>>> 
>>>
>>> TAG review
>>>
>>> Still under review 
>>> under the original I2S for the Attribution Reporting API
>>>
>>> TAG review status
>>>
>>> Pending
>>>
>>> Summary
>>>
>>> We are landing the following change to the Attribution Reporting API
>>> focused on:
>>>
>>>-
>>>
>>>Improving API report batching capabilities
>>>
>>>
>>> This change is based on ad-tech feedback that we heard regarding the
>>> need for additional report batching flexibility so that different report
>>> contributions can be batched at different cadences.
>>>
>>> Currently aggregatable reports generated by the API can consist of
>>> multiple separate contributions which are key:value pairs. API callers can
>>> batch together aggregatable reports and then process them in the
>>> aggregation service, which consists of decrypting the reports, aggregating
>>> the values, and adding noise, before returning a summary report to the API
>>> caller. Additionally, all contributions in an aggregatable report must
>>> currently be processed by aggregation service at the same time.
>>>
>>> With this change, the API will now allow API callers to specify
>>> filtering IDs as part of each contribution (i.e. each key:value pair) in
>>> the aggregatable report. API callers can then use these filtering IDs,
>>> which will also be part of the encrypted payload of the report, to specify
>>> which contributions they want to have processed by the aggregation service
>>> at a given time.
>>>
>>> This will allow API callers to process contributions with different
>>> filtering IDs at different cadences. Allowing this flexibility is a utility
>>> improvement, because the noise added in the aggregation service per
>>> key:value pair bucket may have a lower relative impact on values that are
>>> batched on a longer cadence.
>>>
>>> Explainer/Spec changes
>>>
>>>1.
>>>
>>>Flexible contributions filtering
>>>
>>>
>>>
>>> Risks
>>> Interoperability and Compatibility
>>>
>>> This is an optional and fully backwards compatible change. This feature
>>> provides a new filtering ID that can be set as part of the aggregatable
>>> report contributions and does not break any pre-existing API or web
>>> functionality.
>>>
>>> Gecko: No signal (Original request:
>>> https://github.com/mozilla/standards-positions/issues/791)
>>>
>>> WebKit: No signal (Original request:
>>> https://github.com/WebKit/standards-positions/issues/180)
>>>
>>> Web developers:
>>> https://github.com/patcg-individual-drafts/private-aggregation-api/issues/92
>>>
>>> *although this is a private aggregation issue link, it also applies to
>>> ARA use cases*
>>>
>>>
>>> WebView application risks
>>>
>>> Does this intent deprecate or change behavior of existing APIs, such
>>> that it has potentially high risk for Android 

Re: [blink-dev] Intent to Ship: Rename position-try-options to position-try-fallbacks

[Yoav Weiss (@Shopify)]

On Wed, Jul 17, 2024 at 10:29 PM Vladimir Levin  wrote:

>
>
> On Wed, Jul 10, 2024 at 6:34 PM Mason Freed  wrote:
>
>> {NOTE: this is a replacement of this chromestatus
>> , which has the wrong
>> feature type and cannot be changed.}
>> Contact emailsmas...@chromium.org, andr...@chromium.org
>>
>> ExplainerNone
>>
>> Specification
>> https://github.com/w3c/csswg-drafts/issues/10395#issuecomment-2192127524
>>
>> Summary
>>
>> The CSSWG resolved to rename this property, because "fallbacks" more
>> accurately describes what this property controls. The word "options" is a
>> bit deceiving, since the styles outside of `position-try` blocks will be
>> tested first, and if they result in a layout that fits within the
>> containing block, none of the "options" will get used. So "fallbacks" is a
>> better word to describe this behavior.
>> https://github.com/w3c/csswg-drafts/issues/10395#issuecomment-2192127524
>>
>>
>> Blink componentBlink>CSS
>> 
>>
>> TAG reviewNone
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> This is a name change, which will result in the old name no longer
>> functioning. So there is a risk of breakage. However, the anchor
>> positioning feature was very recently shipped, and does not have
>> implementation in other browsers. So we feel the risk is quite small
>> currently, but will grow over time. Given that, we'd like to rename this
>> property ASAP to avoid the risk getting too large. The use counter is
>> currently quite low, around 0.01% in June:
>> https://chromestatus.com/metrics/css/timeline/popularity/784 An HTTP
>> Archive search was performed, which showed that almost all usage comes from
>> one Shopify CSS file (`spec-and-compare.css`), and we intend to reach out
>> to Shopify (or hope for a response from one very special Blink API owner)
>> to make sure this will not break Shopify.
>>
>
> Have you had a chance to investigate what a breakage looks like by
> checking the sites using the feature?
>

More specifically, as discussed previously, this usage is coming from a 3P
app that merchant sites install and that Shopify has no direct control
over. Have you reached out to the app's authors? Have you tried to see if
it gets broken by this change?


>
> I think this rename is fairly safe, but I want to make sure that we're
> planning on shipping it with a flag that would be able to undo the behavior
> (a killswitch). I assume having two flags, one to add a new flag and one to
> remove the old flag is the easiest way to do that. WDYT?
>
> Thanks,
> Vlad
>
>
>
>>
>>
>> *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
>> 
>> ?Yes
>>
>> https://wpt.fyi/results/css/css-anchor-position
>>
>>
>> Flag name on chrome://flagsNone
>>
>> Finch feature nameNone
>>
>> Non-finch justificationNone
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://crbug.com/349600667
>>
>> Estimated milestones
>> Shipping on desktop 128
>> DevTrial on desktop 128
>> Shipping on Android 128
>> DevTrial on Android 128
>> Shipping on WebView 128
>>
>> 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/5090673808900096?gate=5938066895405056
>>
>> 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/CAM%3DNeDj38gT4PfU4fCXhkdAOLvdY8c_sgukkotmHnC6wTZoDhQ%40mail.gmail.com
>> 
>> .
>>
> --
> You received this message because you are subs

Re: [blink-dev] Intent to Extend Experiment: Capture all screens

[Yoav Weiss (@Shopify)]

-
>>>>
>>>>timebox the temporary solution through origin trial to make sure
>>>>this API does not remain on the drive-by web.
>>>>
>>>> The origin trial is essential to keep current developer momentum and
>>>> grant enough time for the selected developers to prepare the API
>>>> launch in context of IWA
>>>> <https://docs.google.com/document/d/1XB8rQRnY5N8G2PeEcNJpVO0q22CutvwW8GGKCZ1z_vc/edit#bookmark=kix.fusm752shry9>.
>>>> Good evidence for progress towards shipping can be seen by the multitude of
>>>> IWA related work to prepare the upcoming launch (IWA Launch
>>>> <https://chromestatus.com/feature/5146307550248960>).
>>>>
>>>> I hope to have answered your questions sufficiently. Please let me know
>>>> if you have any further concerns or follow-up questions.
>>>>
>>>> On Thursday, July 11, 2024 at 7:45:24 PM UTC+2 Reilly Grant wrote:
>>>>
>>>>> CSP and Trusted Types give you protections against XSS but only the
>>>>> bundling provided by IWAs provides the protection against server 
>>>>> compromise
>>>>> that Chrome Security is asking for for this API.
>>>>>
>>>>> Shipping this API in its final form has been blocked on IWAs being
>>>>> ready to launch (which is imminent).
>>>>> Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome
>>>>> <https://www.google.com/chrome>
>>>>>
>>>>>
>>>>> On Wed, Jul 10, 2024 at 9:58 AM Yoav Weiss (@Shopify) <
>>>>> yoav...@chromium.org> wrote:
>>>>>
>>>>>> A few things trouble me here.
>>>>>>
>>>>>>- Dependency injection
>>>>>>   - The initial intent
>>>>>>   
>>>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/6TRT0XsVOE4/m/NOm-YEQCAgAJ?utm_medium=email&utm_source=footer>
>>>>>>  indicated
>>>>>>   dependency on Enterprise Policy, rather than IWAs.
>>>>>>   - I see some reasoning for the new dependency in the design
>>>>>>   doc's security considerations
>>>>>>   
>>>>>> <https://docs.google.com/document/d/1XB8rQRnY5N8G2PeEcNJpVO0q22CutvwW8GGKCZ1z_vc/edit#heading=h.y7pqwic3b7ga>,
>>>>>>   but it seems incomplete
>>>>>>  - e.g. why couldn't you enforce CSP and TrustedTypes as a
>>>>>>  requirement for this regardless of IWA? How does bundling help 
>>>>>> when
>>>>>>  allowing one app to leak information from others? Wasn't there 
>>>>>> controls in
>>>>>>  place limiting the origins that can do that as part of the 
>>>>>> Enterprise
>>>>>>  Policy?
>>>>>>  -  I may be missing context as a lot of the links in that
>>>>>>  doc are still Google-only
>>>>>>   - Timelines
>>>>>>- The initial trial went from 118 to 124.
>>>>>>   - On this thread I see you started by asking for an extension
>>>>>>   from 124 to 130, and then switched to asking for 129 to 132.
>>>>>>   - At the same time, I don't believe the OT was put on hold
>>>>>>   when 124 was released.
>>>>>>   - *What happened between M124 and M128?*
>>>>>>- Progress towards shipping
>>>>>>   - On top of that, no evidence of substantial progress towards
>>>>>>   shipping was demonstrated. Again, the design doc still contains 
>>>>>> many
>>>>>>   Google-only links, so I may be missing context here, but this
>>>>>>   section
>>>>>>   
>>>>>> <https://docs.google.com/document/d/1XB8rQRnY5N8G2PeEcNJpVO0q22CutvwW8GGKCZ1z_vc/edit#heading=h.6yk3lvg6gurf>
>>>>>>  feels
>>>>>>   very much like a soft launch. The Origin Trial risks
>>>>>>   
>>>>>> <https://github.com/GoogleChrome/OriginTrials/blob/gh-pages/explainer.md#:~:text=And%20when%20considering,security%20is%20maintained.>
>>>>>>  we
>>>>>>   are trying to avoid don't seem to have been carefully c

Re: [blink-dev] Intent to Ship: Web Authentication API: JSON serialization methods

[Yoav Weiss (@Shopify)]

On Sat, Jul 13, 2024 at 1:42 AM 'Martin Kreichgauer' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emailsmarti...@google.com
>
> Explainer
> https://github.com/w3c/webauthn/wiki/Explainer:-JSON-Serialization-Methods
>
> Specificationhttps://w3c.github.io/webauthn/#publickeycredential
>
> Summary
>
> The WebAuthn PublicKeyCredential.toJSON(), parseCreationOptionsFromJSON()
> and parseRequestOptionsFromJSON() methods let developers serialize a
> WebAuthn response into a JSON object or deserialize a WebAuthn request
> object from its JSON representation.
>
>
> Blink componentBlink>WebAuthentication
> 
>
> TAG reviewNone
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> None
>
>
> *Gecko*: Shipped/Shipping (
> https://developer.mozilla.org/en-US/docs/Web/API/PublicKeyCredential/toJSON#browser_compatibility
> )
>
> *WebKit*: No signal
>
> *Web developers*: Positive (https://github.com/github/webauthn-json)
> webauthn-json is a widely used polyfill for this API maintained by Github.
>
> *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
>
> This feature is implemented in Blink renderer code and shipping on all
> platforms.
>

https://developer.mozilla.org/en-US/docs/Web/API/PublicKeyCredential says
that the broader feature is not available in Android WebView.
Is that correct? If so, can you clarify what that means for this feature?


>
>
> Is this feature fully tested by web-platform-tests
> 
> ?Yes
>
>
> https://wpt.fyi/results/webauthn/public-key-credential-creation-options-from-json.https.window.html
> https://wpt.fyi/results/webauthn/public-key-credential-request-options-from-json.https.window.html
> https://wpt.fyi/results/webauthn/public-key-credential-to-json.https.window.html
>
>
> DevTrial instructions
> https://docs.google.com/document/d/e/2PACX-1vSl4jywfU4xD3fkWrC-T5hHI79xs90oOq9tVSx4M63WkcI-wuk-nnFlPlDIAttrpTEd5BbXABJnDuxT/pub
>
> Flag name on chrome://flagsenable-experimental-web-platform-features
>
> Finch feature nameWebAuthenticationJSONSerialization
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1401128
>
> Availability expectationFirefox has shipped an implementation already.
>
> Adoption expectationThere is a widely used polyfill (
> https://github.com/github/webauthn-json), which suggests there is demand
> from developers for this feature.
>
> Estimated milestones
> Shipping on desktop 128
> DevTrial on desktop 128
> Shipping on Android 128
> DevTrial on Android 128
> Shipping on WebView 128
>
> 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/5141695044255744?gate=6322764007342080
>
> Links to previous Intent discussionsIntent to prototype:
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAB%3DfcEbBz4a%2BEE-KbbRDkEexDON8hCfCC-saD600J7fo9J3jZg%40mail.gmail.com
>
> 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/CAB%3DfcEYktBpGbDOw9pT40jjE%2B6T4HVCq%2Bzu-P3KMf1PQQuzaew%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/CAOmohSLdUrfbhRQ2-n-gASuHGb_c7j0NCsHc4i%2BCb_rbS6A6UQ%40mail.gmail.com.

Re: [blink-dev] Intent to Extend Experiment: WebAssembly JS String Builtins

[Yoav Weiss (@Shopify)]

LGTM to extend experimentation until M130 inclusive

On Thu, Jul 11, 2024 at 1:54 PM Emanuel Ziegler 
wrote:

> Just to clarify: the current OT already runs until M127 inclusive, we are
> asking for an extension to M130.
>

Ok, that wasn't clear from your intent, but I should have asked for
clarifications on that front. Apologies!


>
> Also, there was significant progress on the spec since the last extension.
> The proposal has moved from phase 2 to phase 3 since then including
> fulfilling all the requirements for that transition. Only the *formal*
> spec is lacking and will be completed in the upcoming months before
> reaching phase 4.
>

The Blink process cares less about phase transitions (prior to phase 4,
which we use to gauge consensus) and more about actual specifications.


>
> Thanks,
> Emanuel
>
>
> On Thu, Jul 11, 2024 at 1:06 PM Yoav Weiss (@Shopify) <
> yoavwe...@chromium.org> wrote:
>
>> LGTM to experiment until M127, inclusive.
>>
>> After some discussions amongst the API owners, I think there's no real
>> mismatch.
>> The Blink process does have more requirements for OT renewals than the
>> WASM process does for stage 3 proposals, but that not necessarily a
>> contradiction.
>> Therefore I would have expected y'all to make progress on a spec
>> regardless of the WASM process stage before asking for this renewal.
>> At the same time, given that the requirements may have not been very
>> clear, I don't want this to be a blocker here.
>> But if another extension is needed, I'd expect to see some significant
>> progress on both the spec and WPT-streaming front.
>>
>> On Wednesday, July 10, 2024 at 4:45:52 AM UTC+2 Domenic Denicola wrote:
>>
>> Thanks for clarifying the Wasm process. It sounds like there's some
>> mismatch between its more lax requirements, and the requirements of the
>> Blink process for shipping things in Chromium, and in particular the
>> requirements for extending an experiment.
>>
>> It sounds like it would be easy to make progress on the WPTs requirement,
>> but potentially not very useful for the community, if all the Wasm engines
>> are using the existing JS API tests and not paying attention to WPTs until
>> a later stage. And, it would be hard to make progress on the spec
>> requirement.
>>
>> I'm inclined to approve the extension, as it's clear you all are making a
>> good-faith effort to shape this feature in response to developer and
>> implementer feedback and using the experiment framework as intended.
>> However, since it contradicts the letter of the process, please give us a
>> day or so to discuss amongst API owners and make sure others are OK with
>> this kind of exception. And maybe, as Mike mentioned during the last
>> extension
>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/k7DQ3qYbn90/m/zVjoH0ixAQAJ>,
>> we should codify some of these exceptions into the Blink process to avoid
>> the clash in the future.
>>
>> On Wed, Jul 10, 2024 at 12:09 AM Emanuel Ziegler 
>> wrote:
>>
>> Thanks for taking a look! The progress is in alignment with the Wasm spec
>> process requirements. Please see my answers below where I provide more
>> background.
>>
>> On Mon, Jul 8, 2024 at 6:04 AM Domenic Denicola 
>> wrote:
>>
>>
>>
>> On Thu, Jul 4, 2024 at 2:50 AM Emanuel Ziegler 
>> wrote:
>>
>> Dear API owners,
>>
>> We would like to request an extension of the origin trial for Wasm JS
>> String Builtins
>> <https://developer.chrome.com/origintrials/#/view_trial/2142587522721513473>.
>> There were recent changes to the initialization of string constants
>> (implicit imports) which improved startup time and binary size on local
>> measurements.
>>
>> We would like to use the experiment to verify the viability of this
>> change in the wild (effect on load and startup times) and upcoming changes
>> to it (variable import namespace for greater flexibility). Sheets/J2Wasm
>> already implemented the first part and wants to roll it out to users in the
>> next weeks as part of the origin trial.
>>
>> The proposal is progressing well along the requested dimensions
>>
>>- Draft spec (early draft is ok, but must be spec-like and associated
>>with the appropriate standardization venue, or WICG)
>>   - The proposal continues to be actively maintained and changed
>>   with plenty of community engagement.
>>   - Recent changes mostly affected string constants and their
>>   initialization.
&g

Re: [blink-dev] Intent to Experiment: Call stacks in crash reports from unresponsive web pages

[Yoav Weiss (@Shopify)]

LGTM to experiment M127-M132 inclusive.

On Thu, Jul 11, 2024 at 8:17 AM Domenic Denicola 
wrote:

> Can you work on filing for TAG review, and asking other browsers for
> signals?
>

I agree it's a good idea to file all these at this point, but they are not
a blocker for an initial OT request. (they would be for extensions, along
with spec work)


>
> On Tue, Jul 9, 2024 at 6:16 AM 'Issack John' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Contact emails
>> issackj...@microsoft.com, seth.bren...@microsoft.com
>>
>> Explainer
>>
>> https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/CrashReporting/AddStackToCrashReports.md
>> https://github.com/WICG/crash-reporting/issues/12
>>
>> Specification
>> https://wicg.github.io/crash-reporting
>>
>> Design docs
>>
>>
>> https://docs.google.com/document/d/19DpvHIiYbmB9wgIP0BdI4vOnfVLcAZFmfIAml7SqRQA/edit?usp=sharing
>>
>> Summary
>> This feature captures the JS call stack when a web page becomes
>> unresponsive due to JavaScript code running an infinite loop or other very
>> long computation. This helps developers to identify the cause of the
>> unresponsiveness and fix it more easily. The JS call stack is included in
>> the crash reporting API when the reason is unresponsive.
>>
>>
>> Blink component
>> Chromium > Internals > Network > ReportingAndNEL
>> 
>>
>> TAG review
>> None
>>
>> TAG review status
>>
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>> "The stack trace format itself is not compatible across browsers."
>> However, "It is already exposed throughout the web platform (via the
>> `error.stack` getter), and there is already a lot of software, both client-
>> and server-side, which deals with parsing the different browsers' formats."
>>
>>
>> *Gecko*: No signal
>>
>> *WebKit*: No signal
>>
>> *Web developers*: No signals
>>
>> *Other signals*:
>>
>> Security
>> Stack frames from cross-domain scripts that were not loaded with CORS
>> must be omitted.
>>
>>
>> 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
>>
>>
>> Goals for experimentation
>> The primary goal of this experiment is to gain insights on the usage and
>> effectiveness of the call stacks in crash reports from unresponsive web
>> pages feature. We aim to understand how this feature can help developers
>> debug unresponsive renderers, and how it can be improved to better serve
>> their needs.
>>
>>  Specifically, we are looking to gain insight on the following pieces of
>> the API surface:
>>  - The frequency under which the feature is used.
>> - The usefulness of the call stacks provided by this feature in debugging
>> unresponsive renderers.
>>
>>  To validate our designs, we will be using the following metrics and
>> feedback:
>>  - Usage data: We will collect data on the number of execution contexts
>> for which this feature is enabled, and the call stack is generated.
>> - Developer feedback: We will solicit feedback from developers on the
>> usefulness of the call stacks provided by this feature, and any
>> improvements they would like to see.
>>
>> Ongoing technical constraints
>> None
>>
>>
>> Debuggability
>> Developers can launch DevTools, go to the "Application" Tab, then in the
>> "Background services" section click on "Reporting API" where they can
>> inspect reports that are queued to be sent. Application --> Reporting API
>>
>>
>> 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
>> This feature is not currently testable on WPT, since triggering it
>> requires crashing the browser.
>>
>>
>> DevTrial instructions
>>
>> https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/CrashReporting/HOWTO.md
>>
>> Flag name on chrome://flags
>>
>>
>> Finch feature name
>> DocumentPolicyIncludeJSCallStacksInCrashReports
>>
>> Requires code in //chrome?
>> False
>>
>> Tracking bug
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1445539
>>
>> Estimated milestones
>> Origin trial desktop first
>> 127
>> Origin trial desktop last
>> 132
>> DevTrial on desktop
>> 125
>> OriginTrial Android last
>> 132
>> OriginTrial Android first
>> 127
>> DevTrial on Android
>> 125
>> OriginTrial webView last
>> 132
>> OriginTrial webView first
>> 127
>>
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/4731248572628992?gate=5542684580380672
>>
>> Links to previous Intent discussions
>> Intent to prototype:
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/MW2PPF6784DDB763E2DA7BFC75AE51613ABC27B2%40MW2PPF6784DDB76.namprd00.pr

Re: [blink-dev] Intent to Extend Experiment: WebAssembly JS String Builtins

[Yoav Weiss (@Shopify)]

LGTM to experiment until M127, inclusive.

After some discussions amongst the API owners, I think there's no real 
mismatch.
The Blink process does have more requirements for OT renewals than the WASM 
process does for stage 3 proposals, but that not necessarily a 
contradiction.
Therefore I would have expected y'all to make progress on a spec regardless 
of the WASM process stage before asking for this renewal.
At the same time, given that the requirements may have not been very clear, 
I don't want this to be a blocker here.
But if another extension is needed, I'd expect to see some significant 
progress on both the spec and WPT-streaming front.

On Wednesday, July 10, 2024 at 4:45:52 AM UTC+2 Domenic Denicola wrote:

Thanks for clarifying the Wasm process. It sounds like there's some 
mismatch between its more lax requirements, and the requirements of the 
Blink process for shipping things in Chromium, and in particular the 
requirements for extending an experiment.

It sounds like it would be easy to make progress on the WPTs requirement, 
but potentially not very useful for the community, if all the Wasm engines 
are using the existing JS API tests and not paying attention to WPTs until 
a later stage. And, it would be hard to make progress on the spec 
requirement.

I'm inclined to approve the extension, as it's clear you all are making a 
good-faith effort to shape this feature in response to developer and 
implementer feedback and using the experiment framework as intended. 
However, since it contradicts the letter of the process, please give us a 
day or so to discuss amongst API owners and make sure others are OK with 
this kind of exception. And maybe, as Mike mentioned during the last 
extension 
,
 
we should codify some of these exceptions into the Blink process to avoid 
the clash in the future.

On Wed, Jul 10, 2024 at 12:09 AM Emanuel Ziegler  
wrote:

Thanks for taking a look! The progress is in alignment with the Wasm spec 
process requirements. Please see my answers below where I provide more 
background.

On Mon, Jul 8, 2024 at 6:04 AM Domenic Denicola  
wrote:



On Thu, Jul 4, 2024 at 2:50 AM Emanuel Ziegler  
wrote:

Dear API owners,

We would like to request an extension of the origin trial for Wasm JS 
String Builtins 
. 
There were recent changes to the initialization of string constants 
(implicit imports) which improved startup time and binary size on local 
measurements.

We would like to use the experiment to verify the viability of this change 
in the wild (effect on load and startup times) and upcoming changes to it 
(variable import namespace for greater flexibility). Sheets/J2Wasm already 
implemented the first part and wants to roll it out to users in the next 
weeks as part of the origin trial.

The proposal is progressing well along the requested dimensions

   - Draft spec (early draft is ok, but must be spec-like and associated 
   with the appropriate standardization venue, or WICG)
  - The proposal continues to be actively maintained and changed with 
  plenty of community engagement.
  - Recent changes mostly affected string constants and their 
  initialization.
   
To me, the proposal document does not seem very "spec-like", but instead 
like an explainer. Is there a formal specification available?


This is in accordance with common practice and in line with the Wasm 
proposal workflow. To quote from the official documentation 

 for 
phase 3:

*"Updates on the actual spec document and reference interpreter are NOT yet 
required"*


Instead they only happen during phase 3 in preparation for phase 4 (final 
stage). Until then, the overview/explainer document is the main source of 
truth to avoid double maintenance. Spec changes also often require the 
assistance of a Wasm spec expert and we want to keep the overhead for those 
low. The overhead of maintaining spec updates will hopefully improve in a 
year or two with the planned switch to SpecTec 
 which 
will make the spec more accessible to proposal champions and implementers.


   - TAG review (see exceptions 
   
   )
  - A TAG review has been requested 
   and is 
  scheduled for discussion.
   - bit.ly/blink-signals requests
  - Firefox/SpiderMonkey is actively working on their prototype and the 
  champion behind this proposal.
  - Safari/JSC expressed openness to the proposal but no official 
  confirmation yet.
   - Outreach for feedback from the spec community
  - The proposal (including string c

Re: [blink-dev] Web-Facing Change PSA: Rename inset-area to position-area

[Yoav Weiss (@Shopify)]

Given the usage, I think this should be an intent rather than a PSA. Can
you send one?

On Wed, Jul 10, 2024 at 8:15 PM Mason Freed  wrote:

> Contact emailsmas...@chromium.org
>
> Specification
> https://github.com/w3c/csswg-drafts/issues/10209#issuecomment-2221005001
>
> Summary
>
> The CSSWG resolved to rename this property from `inset-area` to
> `position-area`. See the CSSWG discussion here:
> https://github.com/w3c/csswg-drafts/issues/10209#issuecomment-2221005001
> Chrome disagrees with this change, but would like to ship an interoperable
> implementation. We will ship the new property name, `position-area`, as a
> synonym for `inset-area` first. Then after a suitable amount of time, we
> will remove `inset-area`. The latter removal will be done under a separate
> Intent.
>
>
> Blink componentBlink>CSS
> 
>
> Search tagsanchor positioning
> 
>
> TAG reviewNone
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> There is a compat risk with this rename, since the old name of
> `inset-area` is in use, with an 0.02% use counter:
> https://chromestatus.com/metrics/css/timeline/popularity/781 We will need
> to ship the new name, `position-area`, first, and issue deprecation
> warnings for the old name, `inset-area`, to give developers time to change.
> This intent to ship is about shipping `position-area` as a synonym for
> `inset-area`. We'll issue a separate I2D for removing the `inset-area`
> property.
>
>
> *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
> 
> ?Yes
>
> https://wpt.fyi/results/css/css-anchor-position
>
>
> Flag name on chrome://flagsNone
>
> Finch feature nameNone
>
> Non-finch justificationNone
>
> Requires code in //chrome?False
>
> Tracking bughttps://crbug.com/35293
>
> Estimated milestones
> Shipping on desktop 129
> DevTrial on desktop 129
> Shipping on Android 129
> DevTrial on Android 129
> Shipping on WebView 129
>
> 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/6567965055778816?gate=5360672631422976
>
> 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/CAM%3DNeDiwrPpAtU%2Byn-OAUBZoEfeYN%2Bgyjg_Vv9_RzEyMKak9Bw%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/CAOmohS%2B24jAU173F1esaAW559FY7gCD%3D6DrbxMJ1soQ9cqqozw%40mail.gmail.com.

Re: [blink-dev] Intent to Extend Experiment: Capture all screens

[Yoav Weiss (@Shopify)]

A few things trouble me here.

   - Dependency injection
  - The initial intent 
  

 indicated 
  dependency on Enterprise Policy, rather than IWAs.
  - I see some reasoning for the new dependency in the design doc's 
security 
  considerations 
  
,
 
  but it seems incomplete
 - e.g. why couldn't you enforce CSP and TrustedTypes as a 
 requirement for this regardless of IWA? How does bundling help when 
 allowing one app to leak information from others? Wasn't there 
controls in 
 place limiting the origins that can do that as part of the Enterprise 
 Policy?
 -  I may be missing context as a lot of the links in that doc are 
 still Google-only
  - Timelines
   - The initial trial went from 118 to 124.
  - On this thread I see you started by asking for an extension from 
  124 to 130, and then switched to asking for 129 to 132.
  - At the same time, I don't believe the OT was put on hold when 124 
  was released. 
  - *What happened between M124 and M128?*
   - Progress towards shipping
  - On top of that, no evidence of substantial progress towards 
  shipping was demonstrated. Again, the design doc still contains many 
  Google-only links, so I may be missing context here, but this section 
  

 feels 
  very much like a soft launch. The Origin Trial risks 
  

 we 
  are trying to avoid don't seem to have been carefully considered.
   

Putting all this together, I don't think we should renew the current trial.



On Wednesday, June 26, 2024 at 6:18:45 PM UTC+2 Simon Hangl wrote:

> Oops, upon friendly clarification from a colleague I realized that your 
> comment was probably about making the doc visible to everyone :) . I 
> updated the doc permissions now.
>
> On Wednesday, June 26, 2024 at 10:43:35 AM UTC+2 Simon Hangl wrote:
>
>> @Daniel, thanks for your questions / comments. We intend to make 
>> getAllScreensMedia available for everybody once isolated web apps launch 
>> (we are asking to extend the origin trial to already gain insights on the 
>> API before isolated web apps launch - see also the "Short term solution 
>> until IWAs are available" section in the design doc). This also brings me 
>> to the 2nd part of your question: we made significant progress towards 
>> isolated web apps (we are mostly code complete and the intent to launch 
>> will be submitted within the next 1-3 milestones).
>>
>>
>> On Tuesday, June 25, 2024 at 7:48:07 PM UTC+2 Daniel Bratell wrote:
>>
>>> Any reason to not make it available for everyone? Asking for a friend.
>>>
>>> Another thing, when extending experiments we want to see evidence of 
>>> substantial progress on the feature so that it doesn't just roll along 
>>> until it's burned in by pure inertia. Could you please tell us about the 
>>> progress since the last extension?
>>>
>>> /Daniel
>>> On 2024-06-19 16:42, 'Simon Hangl' via blink-dev wrote:
>>>
>>> Apologies for the delay. We'd like to ask for an extension of the origin 
>>> trial from M129 to M132. 
>>>
>>> @Yoav, I made the design doc available for all chromium accounts here 
>>> 
>>> .
>>>
>>> @Vladimir, we are on track with isolated web apps and an intent to ship 
>>> will be submitted in the next milestones.
>>>
>>> On Thursday, March 21, 2024 at 4:38:49 PM UTC+1 Vladimir Levin wrote:
>>>
 On Mon, Mar 18, 2024 at 11:17 AM 'Simon Hangl' via blink-dev <
 blin...@chromium.org> wrote:

> Hello blink-dev,
>
> We’d like to ask for an extension to our Origin Trial, from M124 to 
> M130. This is due to a dependency on isolated web apps, which are delayed.
>

 The intent process only allows extensions of 3 milestones at a time. It 
 also requires evidence of substantial progress on the feature. It sounds 
 like here, the original experiment did not go as planned due to a 
 dependency. Do you know if the isolated web apps feature is ready now? In 
 other words, is this dependency satisfied? 

 Contact emails
>
> sim...@google.com
> Explainer
>
> https://github.com/screen-share/capture-all-screens/blob/main/README.md
> Specification
>
> https://screen-share.github.io/capture-all-screens
> Design docs 
>
> https://screen-share.github.io/capture-all-screens
>
> https://github.com/screen-share/captur

Re: [blink-dev] Intent to Experiment: FedCM Button Mode API and Use Other Account API

[Yoav Weiss (@Shopify)]

That's fine. No re-approval is needed

On Tue, Jul 9, 2024 at 3:12 PM Yi Gu  wrote:

> Hello API owners!
>
> Quick update: we didn't start the OT on desktop until M125 and haven't
> started the OT on Android yet. Therefore we propose to update the estimated
> milestones to:
> desktop: M125 - M130 inclusive
> Android: M128 - M130 inclusive
>
> WDYT?
>
> Regards,
> Yi
>
> On Tue, Apr 9, 2024 at 12:33 AM Yoav Weiss (@Shopify) <
> yoavwe...@chromium.org> wrote:
>
>> That's indeed very useful to get a better understanding of the overall
>> flow, thanks! :)
>>
>> On Mon, Apr 8, 2024 at 5:06 PM Yi Gu  wrote:
>>
>>> Hi Yoav,
>>>
>>> Thanks for the suggestion! We have a flowchart
>>> <https://raw.githubusercontent.com/yi-gu/fedcm-images/main/button_flow/ButtonFlow.jpeg>
>>> in that thread to try to explain what a browser would do in case a user is
>>> not logged in to the IdP but maybe it's not very clear. The answer to your
>>> questions is yes. IdP controls which login page the new window would load
>>> (by reusing the required "login_url
>>> <https://developers.google.com/privacy-sandbox/3pcd/fedcm-developer-guide#login-url>"
>>> field from LoginStatus API). However they cannot choose another way to
>>> handle user logged-out in the middle of a FedCM button flow. In addition,
>>> we provided this deck
>>> <https://docs.google.com/presentation/d/1iURrPakaHgBfQ6mAefKijjxToiTTgBSPz1rtaV0od98/edit?usp=sharing>
>>>  of
>>> mocks w.r.t. how Chrome plans to implement the Button flow. We may change
>>> some of the UI affordance during OT and will publish a blog post with
>>> instruction and proposed UX soon.
>>>
>>> Please let us know if we could make it more clear for developers.
>>>
>>> Yi
>>>
>>> On Fri, Apr 5, 2024 at 9:36 AM Yoav Weiss (@Shopify) <
>>> yoavwe...@chromium.org> wrote:
>>>
>>>>
>>>>
>>>> On Tuesday, February 27, 2024 at 1:43:01 AM UTC+1 Mike Taylor wrote:
>>>>
>>>> That said, please request approvals from the various review gates in
>>>> your chromestatus entry before experimenting.
>>>> On 2/26/24 7:41 PM, Mike Taylor wrote:
>>>>
>>>> LGTM to experiment from M124 to M127 inclusive.
>>>> On 2/26/24 5:45 PM, Yi Gu wrote:
>>>>
>>>> Contact emails
>>>>
>>>>
>>>> * y...@chromium.org , cbiesin...@chromium.org
>>>> , tanzach...@chromium.org
>>>>  * Explainer
>>>>
>>>> * https://github.com/fedidcg/FedCM/issues/442
>>>> <https://github.com/fedidcg/FedCM/issues/442#issuecomment-1949323416>*
>>>>
>>>> With my API owner hat off, this is not sufficient as an explainer, and
>>>> makes it hard for me to assess the technical complexity of participating in
>>>> the OT.
>>>> I think it'd be good to elaborate on the exact flows that button mode
>>>> enables. (e.g. what happens when the user is not logged in to the IdP? Does
>>>> the browser automatically opens a separate window to handle that log in? Is
>>>> this something that the IdP should handle? If so, how?)
>>>>
>>>>
>>>> Specification
>>>>
>>>>
>>>> * https://fedidcg.github.io/FedCM <https://fedidcg.github.io/FedCM>
>>>> This will be added as an extension. * Summary
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> * We plan to experiment with two new extensions for the Federated
>>>> Credential Management (FedCM) API: - Button Mode API - The button mode lets
>>>> websites trigger FedCM directly when a user clicks a button (like a
>>>> "Sign-in with IdP" button). This means FedCM will always display a visible
>>>> user interface for login, in contrast to the widget mode where no UI is
>>>> shown if a user’s login status is logged out.  - When the FedCM API is used
>>>> in "button mode" and a user isn't logged in, they'll be taken to the IdP
>>>> login screen (in a pop-up window). Since this happens in response to a
>>>> clear user action, the UI might even be more prominent (e.g., centered and
>>>> modal) compared to the more subtle UI of widget mode. - Use Other Account
>>>> API - With this API, an Ide

Re: [blink-dev] Intent to Ship: Promise.try

[Yoav Weiss (@Shopify)]

LGTM3

On Mon, Jul 8, 2024 at 2:49 AM Domenic Denicola 
wrote:

> LGTM2!
>
> On Thu, Jul 4, 2024 at 1:00 AM Philip Jägenstedt 
> wrote:
>
>> Thank you for the explanation, Shu-yu.
>>
>> LGTM1. I've filed https://github.com/tc39/proposal-promise-try/issues/21
>> about this being stage 3 so that the repo is updated.
>>
>> On Wed, Jul 3, 2024 at 4:42 PM Shu-yu Guo  wrote:
>>
>>>
>>>
>>> On Tue, Jul 2, 2024 at 9:23 PM Domenic Denicola 
>>> wrote:
>>>
 On Wed, Jul 3, 2024 at 7:25 AM Shu-yu Guo  wrote:

> Contact emails...@chromium.org
>
> ExplainerNone
>

 I think
 https://github.com/tc39/proposal-promise-try/blob/main/README.md
 probably qualifies here.


>
> Specificationhttps://tc39.es/proposal-promise-try
>
> Summary
>
> Promise.try is a new static method. `Promise.try(f)` is shorthand for
> `new Promise(resolve => resolve(f()))`.
>
>
> Blink componentBlink>JavaScript>Language
> 
>
> TAG reviewNone
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> None. This is a new static method on the Promise constructor.
>
>
> *Gecko*: Positive This is a Stage 3 TC39 proposal.
>
> *WebKit*: Positive (https://bugs.webkit.org/show_bug.cgi?id=275359)
> This is a Stage 3 TC39 proposal.
>

 The repository currently says "stage 2.7", whereas our exceptions for
 TAG review and a lot of the usual Blink process relies on the proposal
 being in stage 3.

 From what I can tell of https://tc39.es/process-document/ the
 difference is that stage 3 has sufficient test262 tests? But below you say
 that the feature is fully tested by test262 tests, so I'm unsure what's
 holding this back from stage 3.

 In practice I suspect this isn't a real problem, but I don't want to
 LGTM right away until we get a bit more clarity here, and possibly update
 the relevant Blink process bits.

>>>
>>> I think the repo is not updated. This received Stage 3 at the June 2024
>>> meeting, but the notes are not yet public.
>>>
>>>



>
> *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
> 
> ?Yes
>
> Test262:
> https://github.com/tc39/test262/tree/main/test/built-ins/Promise/try
>
>
> Flag name on chrome://flags--js-promise-try
>
> Finch feature namekJavaScriptPromiseTry
>
> Requires code in //chrome?False
>
> Estimated milestones
> DevTrial on desktop 128
> DevTrial on Android 128
>
> 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/6315704705089536?gate=5106880681869312
>
> 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/CAN-e9e-DDG5a-Q1d0955b15kS-hSPx91vpHqrdv61yUAiCyarg%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/CAN-e9e-r2ioCiTrxf-7gjND69%2BE2XhQGye_%2BdL0Kvy5_7SnkYQ%40mail.gmail.com
>>> 

Re: [blink-dev] Intent to Experiment: Partitioning :visited links history Phase 2

[Yoav Weiss (@Shopify)]

LGTM3

One question raised 
elsewhere was around same-origin links, where links to origin B visited
from origin A should be then marked as visited when linked directly from B.
I see there's an open issue

on this. It'd be good if one of the experiment's goals would be to
determine if this is a blocker or not for initial shipping.

On Wed, Jul 3, 2024 at 10:12 PM Daniel Bratell  wrote:

> LGTM2 for a low percentage finch experiment in M128-M130 (inclusive)
>
> /Daniel
> On 2024-07-03 22:02, Chris Harrelson wrote:
>
> LGTM1
>
> (probably 3 needed because this is a non-standard experiment)
>
> On Wed, Jul 3, 2024 at 12:28 PM Kyra Seevers 
> wrote:
>
>> One point of clarification: we are intending to experiment for one
>> milestone (M128), but would like to request 3 milestones (M128 - M130) in
>> case of any delays.
>>
>> Thanks so much!
>>
>> On Wed, Jul 3, 2024 at 2:16 PM Kyra Seevers 
>> wrote:
>>
>>> Update: I wanted to update the thread that WebKit left positive
>>> indications of support for this proposal in the request for position
>>> recently: https://github.com/WebKit/standards-positions/issues/363.
>>>
>>> Daniel: Thanks for the question! We will be using a traditional Finch
>>> experiment rollout starting with Canary/Dev in M128. I will update this
>>> thread with any changes to the experiment that occur.
>>>
>>> As for why we chose our keying structure: top-level site allows us to
>>> prevent cross-site leaks and frame origin allows us to adhere to the
>>> same-origin policy and avoid cross-frame leaks. For example, if I have an
>>> iframe c.com embedded in both a.com and b.com, keying by top-level site
>>> removes the opportunity for cross-site tracking to occur between these two
>>> iframes. For a visual example of this, please see the explainer (especially
>>> Key Scenarios #2 and #3):
>>> https://github.com/kyraseevers/Partitioning-visited-links-history?tab=readme-ov-file#key-scenarios
>>> .
>>>
>>> Thanks all,
>>> Kyra
>>>
>>> On Wed, Jul 3, 2024 at 10:48 AM Daniel Bratell 
>>> wrote:
>>>
 What milestones do you plan to run the experiment in?

 (Also, why isn't it enough to key on frame origin? I'm sure there is a
 good reason but it's not obvious.)

 /Daniel
 On 2024-07-02 22:42, Kyra Seevers wrote:

 Intent to Experiment: Partitioning :visited links history Phase 2
 (User-facing partitioning for :visited links)
 Contact emails

 kyraseev...@chromium.org

 Explainer

 https://github.com/kyraseevers/Partitioning-visited-links-history

 Specification

 We plan to specify our solution before shipping. This work currently
 falls under the wording in CSS Selectors Level 4
 :  “UAs may treat all links
 as unvisited links or implement other measures to preserve the user’s
 privacy while rendering visited and unvisited links differently.”

 Summary

 To eliminate user browsing history leaks, anchor elements will be
 styled as :visited if and only if they have been clicked from this
 top-level site and frame origin before. On the browser-side, this means
 that the VisitedLinks hashtable will now be partitioned via
 "triple-keying", or by storing the following for each visited link: >>> URL, top-level site, frame origin>. By only styling links that have been
 clicked on this site and frame before, the many side-channel attacks that
 have been developed to obtain :visited links styling information are now
 obsolete, as they no longer provide sites with new information about users.

 Blink component

 Blink>History>VisitedLinks
 

 Search tags

 visited links ,
 :visited selector
 , partitioning
 history 

 TAG review

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

 TAG review status

 Issues addressed

 Risks
 Interoperability and Compatibility

 Gecko: Positive (
 https://github.com/mozilla/standards-positions/issues/1040)

 WebKit: Under Review (
 https://github.com/WebKit/standards-positions/issues/363)

 Web developers: No signals

 Other signals:

-

Positive initial signals from presentation at WebAppSec from both
Apple and Firefox

 
-

At the XS Leaks Summit, Firefox stated exploration of :visited
links partitioning in their privacy g

Re: [blink-dev] Intent to Ship: PointerEvent.deviceId for Mult-Pen Inking

[Yoav Weiss (@Shopify)]

LGTM2

Thanks for working through the PR!

On Wednesday, July 3, 2024 at 5:34:54 PM UTC+2 Daniel Bratell wrote:

> LGTM1
>
> /Daniel
> On 2024-06-26 20:16, 'Sahir Vellani' via blink-dev wrote:
>
> The PR is ready and has been *approved *by the PEWG.  
>
> The shape of the API has been reverted to an id (albeit with a slight name 
> change, persistentDeviceId) on the main PointerEvent interface. All links 
> along with request for positions have been updated. Linking the spec pr here 
> <https://github.com/w3c/pointerevents/pull/495>for convenience.
>
> On Thursday, May 23, 2024 at 7:00:38 AM UTC-7 fla...@chromium.org wrote:
>
>> There were some fresh concerns raised about the shape of the spec PR 
>> <https://github.com/w3c/pointerevents/pull/495> which are being hashed 
>> out on that review thread. I will give it approval once we reach a 
>> consensus there.
>>
>> On Wed, May 22, 2024 at 4:30 PM Yoav Weiss (@Shopify) <
>> yoav...@chromium.org> wrote:
>>
>>> OK, thanks for outlining the spec mechanics :) 
>>>
>>> Regardless of whether the PR actually lands in the spec, for the purpose 
>>> of risk-assessment, it's even more interesting to know if the PR is *ready* 
>>> to land in the spec.
>>> Can y'all clarify its review status? If it's ready to land, can a spec 
>>> editor approve it, even if it doesn't land until later?
>>>
>>> On Fri, May 17, 2024 at 10:18 AM Patrick H. Lauke <
>>> re...@splintered.co.uk> wrote:
>>>
>>>>
>>>>
>>>> On 16/05/2024 21:05, Robert Flack wrote:
>>>> > I believe the reason for waiting is that the intention is to switch 
>>>> to a 
>>>> > different publishing model after level 3 is published? @Patrick H. 
>>>> Lauke 
>>>> > <mailto:re...@splintered.co.uk> to confirm.
>>>>
>>>> Apologies for the convoluted model here ... I have to admit that I'm 
>>>> actually not sure what the expected way of working around this is, as 
>>>> Pointer Events has been such a "slow and steady" process so far, with a 
>>>> very linear way of working - it's only now that we're just hoping to 
>>>> get 
>>>> PE3 to REC and then had this extra functionality come in that we've hit 
>>>> this snag. I will check with Philippe at W3C to work out what the best 
>>>> way forward here is (have the "frozen" version that makes its way 
>>>> through the steps to REC, while being able to already have a 
>>>> "future/next" branch).
>>>>
>>>> P
>>>> -- 
>>>> Patrick H. Lauke
>>>>
>>>> * https://www.splintered.co.uk/
>>>> * https://github.com/patrickhlauke
>>>> * https://flickr.com/photos/redux/
>>>> * https://mastodon.social/@patrick_h_lauke
>>>>
>>>> -- 
> 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/98e62b43-af6b-4db6-a6b7-b76bc0864eedn%40chromium.org
>  
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/98e62b43-af6b-4db6-a6b7-b76bc0864eedn%40chromium.org?utm_medium=email&utm_source=footer>
> .
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bce38b12-556a-4a52-8316-40520857003fn%40chromium.org.

[blink-dev] Re: Intent to Ship: CSS Anchor Positioning: Unwrapped inset-area()

[Yoav Weiss (@Shopify)]

LGTM1

On Wed, Jul 3, 2024 at 1:50 PM Anders Hartvoll Ruud 
wrote:

> On Wed, Jul 3, 2024 at 11:35 AM Yoav Weiss (@Shopify) <
> yoavwe...@chromium.org> wrote:
>
>>
>>
>> On Wednesday, July 3, 2024 at 10:47:21 AM UTC+2 Anders Hartvoll Ruud
>> wrote:
>>
>> Contact emailsandr...@chromium.org
>>
>> ExplainerNone
>>
>> Specificationhttps://drafts.csswg.org/css-anchor-position-1/#position-
>> try-fallbacks
>>
>> Summary
>>
>> Replaces the inset-area() function with inset-area values directly within
>> position-try-fallbacks. This means that you now just write e.g.
>> position-try-fallbacks:top instead of position-try-fallbacks:inset-
>> area(top).
>>
>>
>> Just to clarify - this removes the inset-area function?
>>
>
> Yes, correct.
>
>
>>
>>
>>
>> The CSSWG made this change shortly after CSS Anchor Positioning shipped
>> in Blink:
>>
>> https://github.com/w3c/csswg-drafts/issues/10320#issuecomment-2137882897
>>
>>
>> Blink componentBlink>CSS
>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ECSS>
>>
>> TAG reviewNone
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>>
>> Searching for existing cases of "inset-area(" in HTTP Archive, I found
>> just a single match out of 638589186 rows:
>>
>> https://css3test.com/tests/css-anchor-position-1.js
>>
>>
>> Do you know if this was used in a production site?
>> From the name, one can assume it's a demo site..
>>
>
> It's just the input for the view to show the features supported by the
> browser e.g.: https://css3test.com/#css-anchor-position-1
>
> It doesn't count as "production use" IMO. Also, I sent a PR to update it:
> https://github.com/LeaVerou/css3test/pull/249
>

Agree!

>
>
>> Query used:
>>
>> #standardSQL
>>
>> SELECT response_bodies.url
>>
>> FROM `httparchive.response_bodies.2024_06_01_desktop` AS response_bodies
>>
>> WHERE REGEXP_CONTAINS(response_bodies.response_body, r'inset\-area\(')
>>
>> *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)?No
>>
>> Is this feature fully tested by web-platform-tests
>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>> ?Yes
>>
>> Flag name on chrome://flagsNone
>>
>> Finch feature nameCSSInsetAreaValue
>>
>> Requires code in //chrome?False
>>
>> Estimated milestonesShipping on desktop128Shipping on Android128Shipping
>> on WebView128
>>
>> 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 Statushttps://chromestatus.com/
>> feature/5116199771045888?gate=5071381116223488
>>
>> This intent message was generated by Chrome Platform Status
>> <https://chromestatus.com/>.
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohS%2Ba%2BW6mFB9LLuu5eh6HwLg%2BHu7HxzoH-p73%2B38MnGSiyg%40mail.gmail.com.

[blink-dev] Re: Intent to Ship: CSS Anchor Positioning: Unwrapped inset-area()

[Yoav Weiss (@Shopify)]

On Wednesday, July 3, 2024 at 10:47:21 AM UTC+2 Anders Hartvoll Ruud wrote:

Contact emailsandr...@chromium.org

ExplainerNone

Specificationhttps://drafts.csswg.org/css-anchor-position-1/#position-
try-fallbacks

Summary

Replaces the inset-area() function with inset-area values directly within 
position-try-fallbacks. This means that you now just write e.g. 
position-try-fallbacks:top instead of position-try-fallbacks:inset-
area(top).


Just to clarify - this removes the inset-area function?
 


The CSSWG made this change shortly after CSS Anchor Positioning shipped in 
Blink:

https://github.com/w3c/csswg-drafts/issues/10320#issuecomment-2137882897


Blink componentBlink>CSS 


TAG reviewNone

TAG review statusNot applicable

Risks


Interoperability and Compatibility


Searching for existing cases of "inset-area(" in HTTP Archive, I found just 
a single match out of 638589186 rows:

https://css3test.com/tests/css-anchor-position-1.js


Do you know if this was used in a production site?
>From the name, one can assume it's a demo site..
 


Query used: 

#standardSQL

SELECT response_bodies.url

FROM `httparchive.response_bodies.2024_06_01_desktop` AS response_bodies

WHERE REGEXP_CONTAINS(response_bodies.response_body, r'inset\-area\(')

*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)?No

Is this feature fully tested by web-platform-tests 

?Yes

Flag name on chrome://flagsNone

Finch feature nameCSSInsetAreaValue

Requires code in //chrome?False

Estimated milestonesShipping on desktop128Shipping on Android128Shipping on 
WebView128

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 Statushttps://chromestatus.com/
feature/5116199771045888?gate=5071381116223488

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/020c25ac-f034-42aa-b48e-e34a16c70643n%40chromium.org.

Re: [blink-dev] Web-Facing Change PSA: Support currentcolor in Relative Color Syntax

[Yoav Weiss (@Shopify)]

Thanks for pushing this! :)
Is there a reason this shouldn't be an intent? IIUC, we're exposing a new
value here

On Mon, Jun 24, 2024 at 8:20 PM 'Kevin Babbitt' via blink-dev <
blink-dev@chromium.org> wrote:

> *Contact emails*
>
> kbabb...@microsoft.com
>
> *Specification*
>
> https://www.w3.org/TR/css-color-5/#resolving-rcs
>
> *Design docs*
>
> https://docs.google.com/document/d/1568wVjrIRbrU9_O37gPu10cj0CDWRiAc6ZMk9t0JpXs/edit
>
> *Summary*
>
> Allow relative colors in CSS (using the 'from' keyword) to use
> 'currentcolor' as a base. This will make it easy for web developers to set
> complementary colors, based on an element's text color, for that element's
> borders, shadows, backgrounds, etc.
>
>
>
> *Blink component*
>
> Blink>CSS
> 
>
> *TAG review*
>
> https://github.com/w3ctag/design-reviews/issues/894
>
> *TAG review status*
>
> Satisfied. The link above is for Relative Color Syntax in general. Tests
> for currentcolor cases were added as part of the discussion before the TAG
> signed off on the review; I interpret that to mean that they're satisfied
> with this use case.
>
>
>
> *Risks*
>
>
>
> *Interoperability and Compatibility*
>
> Interoperability: Relative Color Syntax is a focus area for Interop 2024,
> and inclusion of currentcolor is well covered by existing WPTs, so the risk
> of other engines not converging on an interoperable implementation is low.
>
>
>
> Compatibility: The only risk here is that enabling currentcolor support
> will "light up" color declarations that are being rejected at present.
> Total usage of Relative Color Syntax on the Web (including currentcolor or
> otherwise) is ~0.09% of page loads as of May 1, 2024[1]. I haven't done an
> analysis of currentcolor in RCS, but given that no major engine supported
> it as of that date, I would expect it to be a tiny fraction of those. [1]
> https://chromestatus.com/metrics/feature/timeline/popularity/4632
>
>
>
> *Gecko*: Positive (
> https://github.com/mozilla/standards-positions/issues/841) Implementation
> bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1893966
>
> *WebKit*: Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=245970)
> Changes landed May 13.
>
> *Web developers*: Positive (
> https://github.com/web-platform-tests/interop/issues/426) This feature is
> part of Interop 2024.
>
> *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*
>
> Covered by existing DevTools support for debugging CSS properties.
>
>
>
> *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
>
>
> https://wpt.fyi/results/css/css-color?label=master&label=experimental&aligned&view=interop&q=label%3Ainterop-2024-relative-color
>
>
>
> *Flag name on chrome://flags*
>
> None
>
> *Finch feature name*
>
> CSSRelativeColorSupportsCurrentcolor
>
> *Requires code in //chrome?*
>
> False
>
> *Tracking bug*
>
> https://issues.chromium.org/issues/325309578
>
>
> *Estimated milestones*
>
> Shipping on desktop
>
> 129
>
>
>
> Shipping on Android
>
> 129
>
>
>
> Shipping on WebView
>
> 129
>
>
>
>
> *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/5307971793059840?gate=6194544847880192
>
> 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/SJ0PR00MB1144DF620BEDF481846E0E14C0D42%40SJ0PR00MB1144.namprd00.prod.outlook.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.co

Re: [blink-dev] Re: Web-Facing Change PSA: Rename position-try-options to position-try-fallbacks

[Yoav Weiss (@Shopify)]

On Wed, Jul 3, 2024 at 11:17 AM Anders Hartvoll Ruud 
wrote:

> I'll answer since Mason is now OOO.
>
> On Tue, Jul 2, 2024 at 8:48 AM Yoav Weiss (@Shopify) <
> yoavwe...@chromium.org> wrote:
>
>>
>>
>> On Tuesday, July 2, 2024 at 12:38:50 AM UTC+2 Mason Freed wrote:
>>
>> Contact emailsmas...@chromium.org, andr...@chromium.org
>>
>> Specificationhttps://github.com/w3c/csswg-drafts/issues/10395#
>> issuecomment-2192127524
>>
>> Summary
>>
>> The CSSWG resolved to rename this property, because "fallbacks" more
>> accurately describes what this property controls. The word "options" is a
>> bit deceiving, since the styles outside of `position-try` blocks will be
>> tested first, and if they result in a layout that fits within the
>> containing block, none of the "options" will get used. So "fallbacks" is a
>> better word to describe this behavior. https://github.com/w3c/csswg-
>> drafts/issues/10395#issuecomment-2192127524
>>
>>
>> Blink componentBlink>CSS
>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ECSS>
>>
>> Search tagsanchor positioning
>> <https://chromestatus.com/features#tags:anchor%20positioning>
>>
>> TAG reviewNone
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> This is a name change, which will result in the old name no longer
>> functioning. So there is a risk of breakage. However, the anchor
>> positioning feature was very recently shipped, and does not have
>> implementation in other browsers. So we feel the risk is quite small
>> currently, but will grow over time. Given that, we'd like to rename this
>> property ASAP to avoid the risk getting too large. The use counter is
>> currently quite low, around 0.01% in June: https://chromestatus.com/
>> metrics/css/timeline/popularity/784 An HTTP Archive search was
>> performed, which showed that almost all usage comes from one Shopify CSS
>> file (`spec-and-compare.css`), and we intend to reach out to Shopify (or
>> hope for a response from one very special Blink API owner) to make sure
>> this will not break Shopify.
>>
>>
>> "very special" :)
>>
>> It seems like the source of usage is this 3P app:
>> https://apps.shopify.com/spec-compare
>> I'll send you their contact email so that you can reach out to them
>> directly.
>>
>
> Note: They can preemptively handle this change today by using
> position-try:flip-inline instead.
>
>
>>
>> Can you share the HTTP Archive analysis? Manual inspection of the hosts
>> listed in the chromestatus counter didn't reveal much on my end.
>>
>
> Not sure about "analysis", but the raw dump is here:
> https://docs.google.com/document/d/1x3JKq_iGv24w-2y-rzQbS6MV78UcsTH1yWEJFeH-RdY/edit?usp=sharing
> (@chromium.org to access)
>
> It looks like the usage we see from HTA so far is flip-block/flip-inline,
> which e.g. means a tooltip won't move over to the other (better) side of a
> box when it's scrolled out of view.
>
> Beyond that, I think this would require an intent and maybe a short
>> deprecation period. Even if the only source is this single app, unless the
>> breakage is insignificant,
>>
> we'd need at least one release overlap between the new and the old values,
>> to avoid a breakage period while users are upgrading from Chromium N to N+1.
>>
>
> It's tricky, because waiting could actually cause *more* breakage, even
> with a deprecation period, and the numbers look quite good right now.
>

If the app in question could switch to `position-try:flip-inline` that
changes things, and would indeed not require a milestone overlap, assuming
they can make that change.


>
>>
>>
>>
>> *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
>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests

[blink-dev] Re: Web-Facing Change PSA: Rename position-try-options to position-try-fallbacks

[Yoav Weiss (@Shopify)]

On Tuesday, July 2, 2024 at 12:38:50 AM UTC+2 Mason Freed wrote:

Contact emailsmas...@chromium.org, andr...@chromium.org

Specificationhttps://github.com/w3c/csswg-drafts/issues/10395#
issuecomment-2192127524

Summary

The CSSWG resolved to rename this property, because "fallbacks" more 
accurately describes what this property controls. The word "options" is a 
bit deceiving, since the styles outside of `position-try` blocks will be 
tested first, and if they result in a layout that fits within the 
containing block, none of the "options" will get used. So "fallbacks" is a 
better word to describe this behavior. https://github.com/w3c/csswg-
drafts/issues/10395#issuecomment-2192127524


Blink componentBlink>CSS 


Search tagsanchor positioning 


TAG reviewNone

TAG review statusNot applicable

Risks


Interoperability and Compatibility

This is a name change, which will result in the old name no longer 
functioning. So there is a risk of breakage. However, the anchor 
positioning feature was very recently shipped, and does not have 
implementation in other browsers. So we feel the risk is quite small 
currently, but will grow over time. Given that, we'd like to rename this 
property ASAP to avoid the risk getting too large. The use counter is 
currently quite low, around 0.01% in June: https://chromestatus.com/
metrics/css/timeline/popularity/784 An HTTP Archive search was performed, 
which showed that almost all usage comes from one Shopify CSS file 
(`spec-and-compare.css`), and we intend to reach out to Shopify (or hope 
for a response from one very special Blink API owner) to make sure this 
will not break Shopify.


"very special" :)

It seems like the source of usage is this 3P 
app: https://apps.shopify.com/spec-compare
I'll send you their contact email so that you can reach out to them 
directly.

Can you share the HTTP Archive analysis? Manual inspection of the hosts 
listed in the chromestatus counter didn't reveal much on my end.

Beyond that, I think this would require an intent and maybe a short 
deprecation period. Even if the only source is this single app, unless the 
breakage is insignificant, we'd need at least one release overlap between 
the new and the old values, to avoid a breakage period while users are 
upgrading from Chromium N to N+1.



*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 

?Yes

https://wpt.fyi/results/css/css-anchor-position


Flag name on chrome://flagsNone

Finch feature nameNone

Non-finch justificationNone

Requires code in //chrome?False

Tracking bughttps://crbug.com/349600667

Estimated milestonesShipping on desktop128Shipping on Android128Shipping on 
WebView128

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 Statushttps://chromestatus.com/
feature/5167414571696128?gate=5182169462079488

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/cf8a8c9d-9efa-4bff-9dd5-590809fe2877n%40chromium.org.

Re: [blink-dev] Intent to Prototype and Ship: Compute Pressure WebDriver endpoints

[Yoav Weiss (@Shopify)]

On Wed, Jun 19, 2024 at 9:55 AM Mandy, Arnaud 
wrote:

> Contact emails
> raphael.kubo.da.co...@intel.com, juha.j.vai...@intel.com,
> kenneth.r.christian...@intel.com, arnaud.ma...@intel.com
>
> Specification
> https://github.com/w3c/compute-pressure/pull/284
>



+Mathias Bynens  +Alex Rudenko
  - I'd love to hear your thoughts on this in
general and on the PR in particular.

Arnaud - was this discussed with the WebDriver WG? Even if other vendors
are opposed to the broader feature, it'd still be good to validate the
design.


>
> Summary
> This exposes WebDriver commands for creating, removing and updating
> pressure source samples for so-called "virtual pressure sources": pressure
> sources that do not depend on underlying hardware or operating system
> support and can be used for testing.
>
> Not only does this allow ChromeDriver users to test this API more easily,
> but it was also one of the suggestions brought up during the Intent to
> Ship thread for this API
> ,
> as the existing web tests in WPT depend on MojoJS and are not interoperable.
>
> Blink component
> Blink>PerformanceAPIs>ComputePressure
> 
>
> TAG review
> None
>
> TAG review status
> Not applicable
>
> Risks
>
>
> Interoperability and Compatibility
> This feature implements WebDriver extension commands in ChromeDriver that
> are used in web-platform-tests and can also be used by ChromeDriver users.
> This feature is therefore not web-exposed, but it does intend to help
> increase adoption of the spec by making it possible for any implementation
> to run the existing web tests without having to use JS mocks that are
> heavily Mojo-based although not dependent on Mojo.
>
> *Gecko*: No signal for this feature (Not in favor of Compute Pressure API)
>
> *WebKit*: No signal for this feature (Not in favor of Compute Pressure
> API)
>

I agree that there's no point in filing for a signal if they are opposed to
the feature itself.


>
> *Web developers*: No signals
>
> *Other signals*: Compute Pressure API Intent To Ship comment
> 
> .
>
>
> Security
> n/a, this is exposed through WebDriver. There have been changes to the
> Compute Pressure code in //content and //services.
>
> WebView application risks
> None, this API is not exposed on Android.
>
> Ongoing technical constraints
> WebDriver endpoints and virtual pressure sources work in Window and
> Dedicated Worker scopes, but not shared worker ones: we store virtual
> pressure source information in WebContentsUserData, which does not
> integrate well with shared workers. Shared worker support would need to
> work with origins instead, but doing so would not play well with any
> DevTools frontend work to support the Compute Pressure API. The same
> constraint is also present in the spec, and feedback is being gathered in 
> issue
> 285 .
>
> Debuggability
> This is a debugging feature. It exposes new ChromeDriver and CDP
> endpoints, but the DevTools frontend has not been touched.
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, ChromeOS, Android, and Android WebView)?
> Windows, Mac, Linux, ChromeOS
>
> Is this feature fully tested by web-platform-tests
> 
> ?
> The feature is currently tested by WPT, but the tests depend on
> Mojo-specific JS mocks. Having these endpoints is the first step towards
> making the existing web tests interoperable.
>
> Requires code in //chrome?
> True: //chrome/test/chromedriver
>
> Tracking bug
> https://issues.chromium.org/u/1/issues/347031400
>
> Estimated milestones
> Shipping on desktop 130
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5130657352384512
>
> --
> 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/DS0PR11MB79029DDFA8D49E3C82BEAF4393CF2%40DS0PR11MB7902.namprd11.prod.outlook.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/CAOmohSKiAKXvfz0kwH5rPd1j

Re: [blink-dev] Intent to Extend Deprecation Trial: Restrict "private network requests" for subresources from public websites to secure contexts.

[Yoav Weiss (@Shopify)]

LGTM to extend the deprecation trial M127-132, but it'd be good to have
meaningful progress by then to reduce the number of folks that use it..

On Fri, Jun 14, 2024 at 8:48 PM Emily Stark  wrote:

>
>
> On Fri, Jun 14, 2024 at 10:36 AM Emily Stark  wrote:
>
>> (Apologies for the slow response, we had some OOOs)
>>
>> On Mon, Jun 3, 2024 at 7:55 PM Mike Taylor 
>> wrote:
>>
>>> Hi Emily,
>>>
>>> A few questions inline:
>>> On 6/1/24 5:05 AM, Emily Stark wrote:
>>>
>>> Contact emails est...@google.com, jdebla...@google.com,
>>> dadr...@google.com, l...@chromium.org, tito...@chromium.org,
>>> cl...@chromium.org, mk...@chromium.org, v...@chromium.org
>>>
>>> Explainer
>>> https://github.com/WICG/private-network-access/blob/master/explainer.md
>>>
>>> Specification https://wicg.github.io/private-network-access
>>>
>>> Design docs
>>>
>>> https://docs.google.com/document/d/1x1a1fQLOrcWogK3tpFBgQZQ5ZjcONTvD0IqqXkgrg5I/edit#heading=h.7nki9mck5t64
>>>
>>> Summary
>>>
>>> Requires that private network requests for subresources from public
>>> websites may only be initiated from a secure context. Examples include
>>> internet to intranet requests and internet to loopback requests. This is a
>>> first step towards fully implementing Private Network Access:
>>> https://wicg.github.io/private-network-access/
>>>
>>>
>>> Blink component Blink>SecurityFeature>CORS>PrivateNetworkAccess
>>> 
>>>
>>> TAG review https://github.com/w3ctag/design-reviews/issues/572
>>>
>>> TAG review status Issues addressed
>>>
>>> Chromium Trial Name PrivateNetworkAccessNonSecureContextsAllowed
>>>
>>> Link to origin trial feedback summary
>>> https://docs.google.com/spreadsheets/d/1z5ZdCslNCnSVR7TNlUTHjSvunMFmT_9G9NOx8-O78-I/edit?usp=sharing&resourcekey=0-DITlG8tDuFDWHiBUHnlSoQ
>>>
>>> Origin Trial documentation link
>>> https://developer.chrome.com/blog/private-network-access-update/
>>>
>>> WebFeature UseCounter name
>>> kPrivateNetworkAccessNonSecureContextsAllowedDeprecationTrial
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> No interoperability risks. Compatibility risk is small but
>>> non-negligible. UseCounters show ~0.1% of page visit making use of this
>>> feature. Direct outreach to the largest users per UKM data revealed no
>>> objections to this launch. Rolling this deprecation out to beta per the
>>> previous I2S resulted in more feedback about the compatibility risk and the
>>> need for a time extension. See the following doc for an extensive
>>> discussion:
>>> https://docs.google.com/document/d/1bpis0QwaA9ZrRFmpPW6LiaPmdwT0UhhUMNsEnU0zfLk/edit
>>>
>>> Can you speak to the number of sites in the largest users group? Is it
>>> dozens of sites? Hundreds? Presumably they're all enrolled in the DT?
>>>
>> I've requested access to the OT data so I can't say for sure yet, but in
>> the meantime, my impression is that we're roughly talking about hundreds of
>> sites. The breakage of ending the deprecation trial would be quite small in
>> terms of affected page loads, but there are legitimate use cases
>> 
>> for nonsecure subresource requests to the private network that we're trying
>> to accomodate because they don't have an alternative/workaround.
>>
>
> Update: it looks like there are ~1000 sites registered in the DT.
>
>
>> *Gecko*: Closed Without a Position (
>>> https://github.com/mozilla/standards-positions/issues/143) Tentatively
>>> positive, but no formal position yet.
>>>
>>> *WebKit*: Positive (
>>> https://lists.webkit.org/pipermail/webkit-dev/2021-May/031837.html)
>>>
>>> *Web developers*: Mixed signals (
>>> https://docs.google.com/document/d/1bpis0QwaA9ZrRFmpPW6LiaPmdwT0UhhUMNsEnU0zfLk/edit)
>>> In our recent survey, most of websites are able to migrate if our new
>>> permission prompt can be landed as a way for them to relax mixed content
>>> checks.
>>> https://docs.google.com/spreadsheets/d/1z5ZdCslNCnSVR7TNlUTHjSvunMFmT_9G9NOx8-O78-I/edit?resourcekey=0-DITlG8tDuFDWHiBUHnlSoQ#gid=309953809
>>>  
>>> Some websites, broadly falling in the category of controller webapps for
>>> IoT devices, find this change incompatible with their use cases. While many
>>> use cases can be solved with specific workarounds, some still require
>>> further engagement.
>>>
>>> *Other signals*:
>>>
>>> Activation
>>>
>>> Developers of non-secure sites that rely upon local servers will need to
>>> upgrade to HTTPS. This might cause some complications, as mixed-content
>>> checks will begin to apply. Chrome carves out HTTP access to loopback (as
>>> perhttps://w3c.github.io/webappsec-secure-contexts/#local

Re: [blink-dev] Intent to Implement and Ship: aria-rowindextext and aria-colindextext

[Yoav Weiss (@Shopify)]

LGTM2

On Mon, Jun 17, 2024 at 10:05 PM Vladimir Levin  wrote:

> LGTM1, thanks
>
> On Wed, Jun 12, 2024 at 2:35 PM 'Daniel Clark' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> *Contact emails*
>>
>> dan...@microsoft.com
>>
>>
>>
>> *Explainer*
>>
>> No formal explainer but https://github.com/w3c/aria/issues/667 discusses
>> use cases and alternatives.
>>
>>
>>
>> *Specification*
>>
>> https://w3c.github.io/aria/#aria-colindextext,
>> https://w3c.github.io/aria/#aria-rowindextext
>>
>>
>>
>> *Summary*
>>
>> The `aria-rowindextext` and `aria-colindextext` properties can be used by
>> developers to express semantics about a table or grid to assistive tech.
>> These attributes are applied in addition to `aria-rowindex` or
>> `aria-colindex` in cases where the numeric indices of rows or columns are
>> not meaningful, for example a chessboard or a spreadsheet where the columns
>> are named by letters rather than numbers.
>>
>>
>>
>> These properties are reflected in JavaScript as:
>>
>>- `Element.ariaRowIndexText`
>>- `Element.ariaColIndexText`
>>- `ElementInternals.ariaRowIndexText`
>>- `ElementInternals.ariaColIndexText`
>>
>>
>>
>> These are part of the Interop2024 Accessibility focus area:
>> https://wpt.fyi/results/wai-aria/idlharness.window.html?label=master&label=experimental&aligned&view=interop&q=label%3Ainterop-2024-accessibility
>>
>>
>>
>> *Blink component*
>>
>> Blink>Accessibility
>>
>>
>>
>> *TAG review*
>>
>> These properties were included for WAI-ARIA 1.3 which was reviewed by the
>> TAG at https://github.com/w3ctag/design-reviews/issues/927
>>
>>
>>
>> *TAG review status*
>>
>> Resolution: Satisfied
>>
>>
>>
>> *Risks*
>>
>>
>>
>>
>>
>> *Interoperability and Compatibility*
>>
>> None
>>
>>
>>
>>
>>
>> Gecko: Shipped/Shipping
>>
>>
>>
>> WebKit: No signal (https://bugs.webkit.org/show_bug.cgi?id=257142)
>>
>>
>>
>> Web developers: No direct signals, but this is part of the Interop2024
>> Accessibility focus area:
>> https://wpt.fyi/results/?label=master&label=experimental&aligned&view=interop&q=label%3Ainterop-2024-accessibility
>>
>>
>>
>> Other signals:
>>
>>
>>
>> *Ergonomics*
>>
>> None.
>>
>>
>>
>>
>>
>>
>>
>> *Activation*
>>
>> It isn't possible to polyfill the functionality of delivering the
>> semantics to AT. However the properties can be set on browsers that don't
>> support them yet without causing errors, so gradual adoption should be
>> straightforward.
>>
>>
>>
>> The property reflection behavior could be polyfilled if necessary.
>>
>>
>>
>>
>>
>>
>>
>> *Security*
>>
>> We do not anticipate any security impact from this feature.
>>
>>
>>
>>
>>
>>
>>
>> *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*
>>
>> The property values can be observed in chrome://accessibility.
>>
>>
>>
>> *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
>>
>>
>> https://wpt.fyi/results/wai-aria/idlharness.window.html?label=master&label=experimental&aligned&view=interop&q=label%3Ainterop-2024-accessibility
>>
>>
>> https://wpt.fyi/results/html/dom/aria-attribute-reflection.html?label=master&label=experimental&aligned&view=interop&q=label%3Ainterop-2024-accessibility
>>
>>
>> https://wpt.fyi/results/custom-elements/ElementInternals-accessibility.html?label=master&label=experimental&aligned&view=interop&q=%2Fcustom-elements%2F
>>
>>
>>
>>
>>
>>
>>
>> *Flag name on chrome://flags*
>>
>> None
>>
>>
>>
>> *Finch feature name*
>>
>> AriaRowColIndexText
>>
>>
>>
>> *Requires code in //chrome?*
>>
>> False
>>
>>
>>
>> *Estimated milestones*
>>
>> Shipping on desktop 128
>>
>>
>>
>> *Anticipated spec changes*
>>
>> None
>>
>>
>>
>> *Link to entry on the Chrome Platform Status*
>>
>> https://chromestatus.com/feature/5182419585204224
>>
>>
>>
>> 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/MW4PR00MB1453C3FD8F1F3CD3E8133243C5C02%40MW4PR00MB1453.namprd00.prod.outlook.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 discuss

Re: [blink-dev] Re: Intent to Ship: document.caretPositionFromPoint API

[Yoav Weiss (@Shopify)]

On Mon, Jun 17, 2024 at 6:16 PM 'Siye Liu' via blink-dev <
blink-dev@chromium.org> wrote:

> TAG suggested we put the shadow roots in a dictionary with a `shadowRoots`
> option (The API shape changed in spec
> 
> after the TAG review was filed). That's what Chromium implemented: 
> document.idl
> - Chromium Code Search
> .
> I think we are good here.
>

Awesome, 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/cb567424-b450-4965-aca9-2910ff533199n%40chromium.org
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSL8eTthTPkfsHDZSbXGaV%2B-mtV0k61heDmgSR6hz-%3DmRQ%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Ship: document.caretPositionFromPoint API

[Yoav Weiss (@Shopify)]

Note that the TAG just came back with some feedback regarding the API
shape. Please address it before shipping.

On Thu, Jun 13, 2024 at 2:34 PM Daniel Bratell  wrote:

> LGTM3
>
> /Daniel
> On 2024-06-13 10:56, Yoav Weiss (@Shopify) wrote:
>
> LGTM2
>
> On Thu, Jun 13, 2024, 10:32 Chris Harrelson  wrote:
>
>> LGTM1
>>
>> On Wed, Jun 12, 2024 at 10:26 PM 'Siye Liu' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> Yes, these tests will all pass if we enable the runtime flag
>>> `CaretPositionFromPoint`.
>>>
>>> The few Mozilla failures do represent their non-spec compliant behavior.
>>>
>>> Thanks,
>>> Siye
>>>
>>> On Wednesday, June 12, 2024 at 4:03:35 AM UTC-7 yoav...@chromium.org
>>> wrote:
>>>
>>>> On Thu, Jun 6, 2024 at 9:03 PM 'Siye Liu' via blink-dev <
>>>> blin...@chromium.org> wrote:
>>>>
>>>>> Reviews requested.
>>>>>
>>>>> Thanks,
>>>>> Siye
>>>>>
>>>>> On Thursday, June 6, 2024 at 9:47:37 AM UTC-7 Chris Harrelson wrote:
>>>>>
>>>>>> Hi, please fill out these reviews on your chromestatus entry:
>>>>>>
>>>>>> [image: image.png]
>>>>>>
>>>>>> On Wed, Jun 5, 2024 at 8:09 PM 'Siye Liu' via blink-dev <
>>>>>> blin...@chromium.org> wrote:
>>>>>>
>>>>>>> Yes, the API returns offset inside text input and textarea elements.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Siye
>>>>>>>
>>>>>>> On Wednesday, June 5, 2024 at 5:10:18 PM UTC-7 Brian Birtles wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Does this return the offset inside text input elements like Gecko's
>>>>>>>> implementation?
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>>
>>>>>>>> Brian
>>>>>>>>
>>>>>>>> 2024年6月6日木曜日 3:20:24 UTC+9 si...@microsoft.com:
>>>>>>>>
>>>>>>>>> Contact emails
>>>>>>>>> si...@microsoft.com, sa...@microsoft.com
>>>>>>>>>
>>>>>>>>> Explainer
>>>>>>>>> None
>>>>>>>>>
>>>>>>>>> Specification
>>>>>>>>>
>>>>>>>>> https://drafts.csswg.org/cssom-view/#dom-document-caretpositionfrompoint
>>>>>>>>>
>>>>>>>>> Summary
>>>>>>>>> This new API allows users to get current caret position from a
>>>>>>>>> given screen point.
>>>>>>>>> The API returns a CaretPosition object which represents the caret
>>>>>>>>> position indicating current text insertion point including the 
>>>>>>>>> containing
>>>>>>>>> DOM node, caret's character offset, and the client rectangle of caret
>>>>>>>>> range. The API also supports get CaretPosition inside Shadow DOM. To 
>>>>>>>>> get
>>>>>>>>> CaretPosition inside Shadow DOM, caller needs to provide reference to 
>>>>>>>>> all
>>>>>>>>> the shadow roots that this API can pierce into.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Blink component
>>>>>>>>> Blink>CSS
>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ECSS>
>>>>>>>>>
>>>>>>>>> TAG review
>>>>>>>>> document.caretPositionFromPoint API in shadow DOM scenario · Issue
>>>>>>>>> #949 · w3ctag/design-reviews (github.com)
>>>>>>>>> <https://github.com/w3ctag/design-reviews/issues/949>
>>>>>>>>>
>>>>>>>>> TAG review status
>>>>>>>>> Issues open
>>>>>>>>>
>>>>>>>>> Risks
>>>>>>>>>
>>>>>>>>>
>>>>>>>

Re: [blink-dev] Re: Intent to Ship: document.caretPositionFromPoint API

[Yoav Weiss (@Shopify)]

LGTM2

On Thu, Jun 13, 2024, 10:32 Chris Harrelson  wrote:

> LGTM1
>
> On Wed, Jun 12, 2024 at 10:26 PM 'Siye Liu' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Yes, these tests will all pass if we enable the runtime flag
>> `CaretPositionFromPoint`.
>>
>> The few Mozilla failures do represent their non-spec compliant behavior.
>>
>> Thanks,
>> Siye
>>
>> On Wednesday, June 12, 2024 at 4:03:35 AM UTC-7 yoav...@chromium.org
>> wrote:
>>
>>> On Thu, Jun 6, 2024 at 9:03 PM 'Siye Liu' via blink-dev <
>>> blin...@chromium.org> wrote:
>>>
 Reviews requested.

 Thanks,
 Siye

 On Thursday, June 6, 2024 at 9:47:37 AM UTC-7 Chris Harrelson wrote:

> Hi, please fill out these reviews on your chromestatus entry:
>
> [image: image.png]
>
> On Wed, Jun 5, 2024 at 8:09 PM 'Siye Liu' via blink-dev <
> blin...@chromium.org> wrote:
>
>> Yes, the API returns offset inside text input and textarea elements.
>>
>> Thanks,
>> Siye
>>
>> On Wednesday, June 5, 2024 at 5:10:18 PM UTC-7 Brian Birtles wrote:
>>
>>> Hi,
>>>
>>> Does this return the offset inside text input elements like Gecko's
>>> implementation?
>>>
>>> Best regards,
>>>
>>> Brian
>>>
>>> 2024年6月6日木曜日 3:20:24 UTC+9 si...@microsoft.com:
>>>
 Contact emails
 si...@microsoft.com, sa...@microsoft.com

 Explainer
 None

 Specification

 https://drafts.csswg.org/cssom-view/#dom-document-caretpositionfrompoint

 Summary
 This new API allows users to get current caret position from a
 given screen point.

 The API returns a CaretPosition object which represents the caret
 position indicating current text insertion point including the 
 containing
 DOM node, caret's character offset, and the client rectangle of caret
 range. The API also supports get CaretPosition inside Shadow DOM. To 
 get
 CaretPosition inside Shadow DOM, caller needs to provide reference to 
 all
 the shadow roots that this API can pierce into.


 Blink component
 Blink>CSS
 

 TAG review
 document.caretPositionFromPoint API in shadow DOM scenario · Issue
 #949 · w3ctag/design-reviews (github.com)
 

 TAG review status
 Issues open

 Risks


 Interoperability and Compatibility
 Gecko already implemented the API without the argument that
 contains shadow roots that this API can pierce into. Webkit/Blink 
 didn't
 implement it. The Gecko implementation in shadow DOM scenario is not
 spec-compliant either (Spec changed recently to cover shadow DOM 
 scenario).
 Gecko 's position is positive on this API. We expect that Gecko's 
 behavior
 will be changed to be spec-compliant in the future. There is also a 
 future
 compat risk too if we decided to deprecate the non-standard API
 `document.caretRangeFromPoint`: https://crbug.com/690599


 *Gecko*: Positive (
 https://github.com/mozilla/standards-positions/issues/1012)

 *WebKit*: Support (
 https://github.com/WebKit/standards-positions/issues/301)

 *Web developers*: Positive (
 https://bugs.chromium.org/p/chromium/issues/detail?id=388976#c34)
 Web developers are asking to have document.caretPositionFromPoint API
 implemented in Blink:
 https://bugs.chromium.org/p/chromium/issues/detail?id=388976#c28
 https://bugs.chromium.org/p/chromium/issues/detail?id=388976#c34

 *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
 
 ?
 Yes


 https://github.com/web-platform-tests/wpt/blob/master/css/cssom/caretPositionFromPoint.html
 https://github.com/web-platform-tests/wpt/blob/master/shadow-dom/Document-caretPositionFromPoint.tentative.html

>>>
>>> Looking at
>>> https://wpt.fyi/results/css/cssom/caretPositionFromPoint.html?label=e

Re: [blink-dev] Intent to Ship: Support 'color-interpolation: linearrgb' on SVG gradients

[Yoav Weiss (@Shopify)]

LGTM2

On Wed, Jun 12, 2024 at 5:50 PM Chris Harrelson 
wrote:

> LGTM1
>
> On Tue, Jun 11, 2024 at 10:23 AM Fredrik Söderquist  wrote:
>
>> On Tue, Jun 11, 2024 at 6:08 AM Yoav Weiss (@Shopify) <
>> yoavwe...@chromium.org> wrote:
>>
>>>
>>>
>>> On Mon, Jun 10, 2024 at 11:25 AM Fredrik Söderquist 
>>> wrote:
>>>
>>>> Contact email...@opera.com
>>>>
>>>> ExplainerNone
>>>>
>>>> Specification
>>>> https://svgwg.org/svg2-draft/painting.html#ColorInterpolation
>>>>
>>>> Summary
>>>>
>>>> Allows SVG gradients to interpolate in a linear-light sRGB color space.
>>>> Currently all SVG gradients interpolate in a gamma-encoded sRGB color 
>>>> space.
>>>>
>>>>
>>>> Blink componentBlink>SVG
>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ESVG>
>>>>
>>>> Search tagsSVG <https://chromestatus.com/features#tags:SVG>, CSS
>>>> <https://chromestatus.com/features#tags:CSS>, Color
>>>> <https://chromestatus.com/features#tags:Color>
>>>>
>>>> TAG reviewNone
>>>>
>>>> TAG review statusNot applicable
>>>>
>>>> Risks
>>>>
>>>>
>>>> Interoperability and Compatibility
>>>>
>>>> The risk along both axes is fairly low since the difference is in
>>>> rendering only (even if the rendering can differ quite significantly).
>>>>
>>>>
>>>> *Gecko*: Shipped/Shipping (
>>>> https://www.mozilla.org/en-US/firefox/123.0/releasenotes)
>>>>
>>>> *WebKit*: No signal
>>>>
>>>
>>> Can you file for a signal?
>>>
>>
>>  https://github.com/WebKit/standards-positions/issues/362
>>
>>
>>>
>>>> *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
>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>>>> ?Yes
>>>>
>>>>
>>>> https://wpt.fyi/results/svg/pservers/reftests/gradient-color-interpolation.svg
>>>>
>>>>
>>>> Flag name on chrome://flagsNone
>>>>
>>>> Finch feature nameSvgGradientColorInterpolationLinearRgbSupport
>>>>
>>>> Requires code in //chrome?False
>>>>
>>>> Tracking bughttps://issues.chromium.org/issues/324440102
>>>>
>>>> Estimated milestones
>>>> Shipping on desktop 127
>>>> Shipping on Android 127
>>>> Shipping on WebView 127
>>>>
>>>> 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/5131849549742080?gate=6228725141340160
>>>>
>>>> This intent message was generated by Chrome Platform Status
>>>> <https://chromestatus.com/>.
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "blink-dev" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to blink-dev+unsubscr...@chromium.org.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHediLSkF96MOwMyoU7FbrF14-fy_3TfMD-JNdjn-DqO5o1X4w%40mail.gmail.com
>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHediLSkF96MOwMyoU7FbrF14-fy_3TfMD-JNdjn-DqO5o1X4w%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>> --
>> You received this message because you are subscribed to the Google Groups
>> "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to blink-dev+unsubscr...@chromium.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHediLQJvPU6Fiu6viXSb0yQL-Yg_Qyr9wLu6dgzL3vJbdL4tg%40mail.gmail.com
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHediLQJvPU6Fiu6viXSb0yQL-Yg_Qyr9wLu6dgzL3vJbdL4tg%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohS%2Bp8_%3DPZc1DfwQg5rY9sitVv3zVpPaYOP9hDbch4scyWA%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: WebAuthn hints

[Yoav Weiss (@Shopify)]

On Mon, Jun 3, 2024 at 10:59 PM Adam Langley  wrote:

> Contact emails...@chromium.org
>
> Specificationhttps://w3c.github.io/webauthn/#enum-hints
>
> Summary
>
> The new `hints` parameter[1] in WebAuthn requests allows sites to provide
> guidance to browsers to guide their UI. The canonical use case are
> enterprises which know that their internal sites use only security keys and
> want to be able to communicate that so that browsers focus the UI on that
> case. But hints also resolve a tension where the current
> `authenticatorAttachment` parameter is strict: setting it to `platform`
> excludes all cross-platform options and vice versa. This has proven less
> than ideal in some cases. [1] https://w3c.github.io/webauthn/#enum-hints
>
>
> Blink componentBlink>WebAuthentication
> 
>
> TAG reviewNone
>
> TAG review statusNot applicable
>

>
> Risks
>
>
> Interoperability and Compatibility
>
> None: new option which only tweaks UI.
>
> *Gecko*: No signal
>
> *WebKit*: No objections when asked in person.
>

Can you ask for positions? https://bit.ly/blink-signals


>
> *Web developers*: Positive. Several sites have requested this
> functionality, which motivated the spec change. They continue to want it
> and have done so for quite a while now.
>
> 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.
>
>
> Debuggability
>
> Not really. This causes the browser UI to switch emphasis, but doesn't
> other change any site-observable behaviour.
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, ChromeOS, Android, and Android WebView)?
>
> On Android & Android WebView, support would require changes to other
> components: the android.credentials code in the framework and, for older
> Android versions, Play Services. That might come in the future, but it's
> not part of the Blink and Chrome work. (The Blink change is, of course,
> required for anything else in the system to be able to handle this
> parameter.)
>
>
> Some versions of Windows handle WebAuthn UI themselves and, while Chrome
> can change it's UI, this parameter won't immediately change the Windows UI.
> However, Microsoft is positive about this change and Chromium will be
> updated to pass this parameter on as soon as the Windows API is able to
> receive it.
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?No
>
> Hints only affect the browser UI and unknown parameters are ignored in
> WebAuthn already.
>
>
> Flag name on chrome://flagsNone
>
>
> Finch feature nameWebAuthenticationHints
>
> Requires code in //chrome?True: Chrome-specific WebAuthn UI is handled in
> //chrome and needs to respond to these hints. Other embedders would have to
> do the same to benefit from this change.
>
> Estimated milestones
> Shipping on desktop 128
>
>
> 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/5145737733341184?gate=5155815622443008
>
> --
> 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/CAL9PXLzcnJ9xLwJZzQJBL0UJdnDGb7tB5Uu7cYqB%2Bdcdb%2BCfTQ%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/CAOmohSL%3D0-Yp1NE447K6Tm4jaQYCadxSqvsc%2Bfw%3DZDERd91Fyw%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Attribution Reporting Feature: Aggregate Debug Reporting

[Yoav Weiss (@Shopify)]

LGTM1

On Wed, Jun 12, 2024 at 5:21 PM Nan Lin  wrote:

> Hi Yoav,
>
> The list of debugging signals is part of the spec:
>
> https://wicg.github.io/attribution-reporting-api/#source-debug-data-type
> https://wicg.github.io/attribution-reporting-api/#trigger-debug-data-type
>

Awesome, thanks!


>
>
> Thanks,
> Nan
>
> On Wednesday, June 12, 2024 at 4:27:41 AM UTC-4 Yoav Weiss wrote:
>
>> On Tue, Jun 11, 2024 at 7:43 PM Akash Nadan 
>> wrote:
>>
>>> Hi Yoav,
>>>
>>> The debug signals that will be reported on are documented here:
>>> https://github.com/WICG/attribution-reporting-api/blob/main/verbose_debugging_reports.md
>>>
>>
>> Thanks! Should that be part of the spec?
>>
>>
>>>
>>> These are the same debug signals that current debug reports support. We
>>> plan to support the same set of debug signals in this new feature as well.
>>>
>>
>>> These debug signals are not developer defined, however a developer can
>>> specify which of the signals they want to track and can group certain
>>> signals together (more details here
>>> <https://github.com/WICG/attribution-reporting-api/blob/main/aggregate_debug_reporting.md#opting-in-aggregate-debug-reporting>
>>> ).
>>>
>>> Thanks,
>>> Akash
>>> On Monday, June 10, 2024 at 10:02:08 PM UTC-7 Yoav Weiss (@Shopify)
>>> wrote:
>>>
>>>> On Fri, Jun 7, 2024 at 8:12 PM 'Akash Nadan' via blink-dev <
>>>> blin...@chromium.org> wrote:
>>>>
>>>>> Contact emails
>>>>>
>>>>> akash...@google.com, lin...@chromium.org, john...@chromium.org
>>>>>
>>>>> Explainer
>>>>>
>>>>> Attribution Reporting with event-level reports
>>>>> <https://github.com/WICG/attribution-reporting-api/blob/main/EVENT.md>
>>>>>
>>>>> Attribution Reporting API with Aggregatable Reports
>>>>> <https://github.com/WICG/attribution-reporting-api/blob/main/AGGREGATE.md>
>>>>>
>>>>> Aggregation Service for the Attribution Reporting API
>>>>> <https://github.com/WICG/attribution-reporting-api/blob/main/AGGREGATION_SERVICE_TEE.md>
>>>>>
>>>>> Specification
>>>>>
>>>>> https://wicg.github.io/attribution-reporting-api/
>>>>>
>>>>> Blink component
>>>>>
>>>>> Internals > AttributionReporting
>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3EAttributionReporting>
>>>>>
>>>>> TAG review
>>>>>
>>>>> Still under review
>>>>> <https://github.com/w3ctag/design-reviews/issues/724> under the
>>>>> original I2S for the Attribution Reporting API
>>>>>
>>>>> TAG review status
>>>>>
>>>>> Pending
>>>>>
>>>>> Summary
>>>>>
>>>>> We are landing the following changes to the Attribution Reporting API
>>>>> focused on:
>>>>>
>>>>>-
>>>>>
>>>>>improving debugging capabilities
>>>>>
>>>>>
>>>>> This change is based on ad-tech feedback and the need to support
>>>>> debugging capabilities after third-party cookie deprecation.
>>>>>
>>>>> Currently the API supports debug reports that are tied to third-party
>>>>> cookies. In order for an API caller to receive a debug report of any kind
>>>>> they need to make sure a specific third-party cookie (i.e. ar_debug) is
>>>>> properly set. The API will check to make sure this cookie is set before
>>>>> providing any kind of debug report. Once third-party cookies are 
>>>>> deprecated
>>>>> these debug reports will no longer be available.
>>>>>
>>>>> This change is so the API can continue to provide debugging
>>>>> information after third-party cookie deprecation when the current debug
>>>>> reports that are tied to third-party cookies are no longer available. This
>>>>> is a new report type that is not tied to third-party cookies and provides
>>>>> similar debug information. This feature allows API callers to request and
>>>>> receive debug signals in aggregate form. This feature is very similar to
>>

Re: [blink-dev] Intent to Experiment: WebGPU Subgroups experimentation

[Yoav Weiss (@Shopify)]

Please kick-off the chrome status reviews on Privacy, Security and
Debuggability before turning on the experiment.

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

> LGTM to experiment M128-131 inclusive
>
> On Wed, Jun 12, 2024 at 4:11 PM Alan Baker  wrote:
>
>> I've updated the feature. We'd like to start in milestone 128 for 4
>> milestones.
>>
>> On Wed, Jun 12, 2024 at 6:06 AM Yoav Weiss (@Shopify) <
>> yoavwe...@chromium.org> wrote:
>>
>>> What milestones do you want the experiment to run?
>>>
>>> On Tue, Jun 11, 2024 at 9:02 PM 'Alan Baker' via blink-dev <
>>> blink-dev@chromium.org> wrote:
>>>
>>>> Contact emailsalanba...@google.com
>>>>
>>>> Explainer
>>>> https://github.com/gpuweb/gpuweb/blob/main/proposals/subgroups.md
>>>>
>>>> SpecificationNone
>>>>
>>>> Summary
>>>>
>>>> Adds subgroup functionality to WebGPU. Subgroup operations perform SIMT
>>>> operations to provide efficient communication and data sharing among groups
>>>> of invocations. These operations can be used to accelerate applications by
>>>> reducing memory overheads incurred by inter-invocation communication.
>>>>
>>>>
>>>> Blink componentBlink>WebGPU
>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EWebGPU>
>>>>
>>>> TAG reviewNone
>>>>
>>>> TAG review statusPending
>>>>
>>>> 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
>>>>
>>>>
>>>> Goals for experimentation
>>>>
>>>> We wish to more broadly test portability, performance, and reach beyond
>>>> our accessible test devices. We have partners that could leverage these
>>>> features in existing products to provide feedback. For example, Mediapipe
>>>> would be able to leverage this feature easily.
>>>>
>>>> We also wish to gather feedback to help shape the API and answer the
>>>> following questions:
>>>> * Which parts are essential?
>>>> * What additions would make a meaningful impact?
>>>> * Can we mitigate non-portable behaviours for common usages?
>>>>
>>>> Ongoing technical constraints
>>>>
>>>> None
>>>>
>>>>
>>>> Debuggability
>>>>
>>>> None
>>>>
>>>>
>>>> Will this feature be supported on all six Blink platforms (Windows,
>>>> Mac, Linux, ChromeOS, Android, and Android WebView)?No
>>>>
>>>> Is this feature fully tested by web-platform-tests
>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>>>> ?No
>>>>
>>>> Flag name on chrome://flagsNone
>>>>
>>>> Finch feature nameNone
>>>>
>>>> Non-finch justificationNone
>>>>
>>>> Requires code in //chrome?False
>>>>
>>>> Estimated milestones
>>>>
>>>> No milestones specified
>>>>
>>>>
>>>> Link to entry on the Chrome Platform Status
>>>> https://chromestatus.com/feature/5126409856221184
>>>>
>>>> This intent message was generated by Chrome Platform Status
>>>> <https://chromestatus.com/>.
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "blink-dev" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to blink-dev+unsubscr...@chromium.org.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABg%2BrB7%2B-cAZNO-mckZ%2BaK8D0ZPZ4iJYi1kmU%2Bt60i%3DFzvL-gw%40mail.gmail.com
>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABg%2BrB7%2B-cAZNO-mckZ%2BaK8D0ZPZ4iJYi1kmU%2Bt60i%3DFzvL-gw%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSL16XC3f6_ATpu5D6H9T8wFwF%3DJig5Zm1B6AgGVyDg8zg%40mail.gmail.com.

Re: [blink-dev] Intent to Experiment: WebGPU Subgroups experimentation

[Yoav Weiss (@Shopify)]

LGTM to experiment M128-131 inclusive

On Wed, Jun 12, 2024 at 4:11 PM Alan Baker  wrote:

> I've updated the feature. We'd like to start in milestone 128 for 4
> milestones.
>
> On Wed, Jun 12, 2024 at 6:06 AM Yoav Weiss (@Shopify) <
> yoavwe...@chromium.org> wrote:
>
>> What milestones do you want the experiment to run?
>>
>> On Tue, Jun 11, 2024 at 9:02 PM 'Alan Baker' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> Contact emailsalanba...@google.com
>>>
>>> Explainer
>>> https://github.com/gpuweb/gpuweb/blob/main/proposals/subgroups.md
>>>
>>> SpecificationNone
>>>
>>> Summary
>>>
>>> Adds subgroup functionality to WebGPU. Subgroup operations perform SIMT
>>> operations to provide efficient communication and data sharing among groups
>>> of invocations. These operations can be used to accelerate applications by
>>> reducing memory overheads incurred by inter-invocation communication.
>>>
>>>
>>> Blink componentBlink>WebGPU
>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EWebGPU>
>>>
>>> TAG reviewNone
>>>
>>> TAG review statusPending
>>>
>>> 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
>>>
>>>
>>> Goals for experimentation
>>>
>>> We wish to more broadly test portability, performance, and reach beyond
>>> our accessible test devices. We have partners that could leverage these
>>> features in existing products to provide feedback. For example, Mediapipe
>>> would be able to leverage this feature easily.
>>>
>>> We also wish to gather feedback to help shape the API and answer the
>>> following questions:
>>> * Which parts are essential?
>>> * What additions would make a meaningful impact?
>>> * Can we mitigate non-portable behaviours for common usages?
>>>
>>> Ongoing technical constraints
>>>
>>> None
>>>
>>>
>>> Debuggability
>>>
>>> None
>>>
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>>> Linux, ChromeOS, Android, and Android WebView)?No
>>>
>>> Is this feature fully tested by web-platform-tests
>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>>> ?No
>>>
>>> Flag name on chrome://flagsNone
>>>
>>> Finch feature nameNone
>>>
>>> Non-finch justificationNone
>>>
>>> Requires code in //chrome?False
>>>
>>> Estimated milestones
>>>
>>> No milestones specified
>>>
>>>
>>> Link to entry on the Chrome Platform Status
>>> https://chromestatus.com/feature/5126409856221184
>>>
>>> This intent message was generated by Chrome Platform Status
>>> <https://chromestatus.com/>.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "blink-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to blink-dev+unsubscr...@chromium.org.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABg%2BrB7%2B-cAZNO-mckZ%2BaK8D0ZPZ4iJYi1kmU%2Bt60i%3DFzvL-gw%40mail.gmail.com
>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABg%2BrB7%2B-cAZNO-mckZ%2BaK8D0ZPZ4iJYi1kmU%2Bt60i%3DFzvL-gw%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSKqiHn9NKAqvkL-1R7VenSkF4M4HziGN8c0qku5iTFJEw%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Snap Events

[Yoav Weiss (@Shopify)]

LGTM1

This seems like a useful addition, with lots of developer demand. While
more detailed explainers would have been helpful, I don't feel it's a
blocker atm, as the demos provided helped me understand what we're shipping
and how developers will use it.

On Tue, Jun 11, 2024 at 4:46 PM Adam Argyle  wrote:

> Slightly different strategy to share a public photo
> https://photos.app.goo.gl/5vHQ4cecJqHWN7DGA, try this one?  😅
>
> On Tue, Jun 11, 2024 at 12:36 AM Yoav Weiss (@Shopify) <
> yoavwe...@chromium.org> wrote:
>
>>
>>
>> On Fri, Jun 7, 2024 at 5:47 PM 'Adam Argyle' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> Indeed, developer sentiment is full of excitement! Who wouldn't want to
>>> throw out their hyper intersection observers with a perfectly timed
>>> callback? or even better, getting insights into the concept of "changing"
>>> which is currently opaque to authors.
>>>
>>> > Philip: For the scrollsnapchange event it's easy to imagine updating
>>> some state below a carousel to match the snapped element, such as item
>>> description or store inventory. For scrollsnapchanging I don't dare hazard
>>> a guess, can someone say what the canonical use case for this is?
>>> I think you'll find that snapchanging is very prominent in mobile
>>> gesture based UI and may be used even more than snapchange. Like one of
>>> those features you can't unsee once you see it working. Consider this
>>> video I took of a game on mobile
>>> <https://photos.google.com/photo/AF1QipO6HUraOd43T9e7lPU4yXHOFX92r15vCX39DRAQ>
>>> ,
>>>
>>
>> It's 404ing for me..
>>
>>
>>> snapchanging and snapchanged are distinctly used for 2 separate moments
>>> of UI feedback. I have many examples like this! The examples are what led
>>> to the APIs. Another really common example will be revealing the caption or
>>> action buttons in a carousel. Which it's probably worth noting we're
>>> working on a CSS way to know some of this information too, we're
>>> prototyping snapped as a "state query."
>>>
>>> Here's a few demo's showing some "picker" use cases, which I feel will
>>> be the majority cases, where folks are observing the snapped or soon to be
>>> snapped item and updating ancillary UI for the user. I have a backlog of
>>> many more to make 😅 Think of these things like snap triggered animation,
>>> which can be a very healthily compliment to scroll driven animation (which
>>> currently doesn't have a "trigger" feature, only linked).
>>>
>>> I bucket the 2 events like:
>>> - the *scrollsnapchanging* event is eager to provide user feedback, can
>>> fire many more times than change
>>> - while *scrollsnapchange* is great for user feedback after they've
>>> lifted their finger or scroll has ended, timed better for confirmation or
>>> whatever. I show an example below that I use change instead of changing so
>>> the animation trigger isn't too busy.
>>>
>>> *Color picker*:
>>> https://codepen.io/argyleink/pen/zYXdgew
>>>
>>> *Date time picker (both eager and timed):*
>>> https://codepen.io/argyleink/pen/WNageoZ
>>>
>>> *Date time picker (eager):*
>>> https://codepen.io/argyleink/pen/oNOWwKq
>>>
>>> *Date time picker (timed for view transitions):*
>>> https://codepen.io/argyleink/pen/LYvzGRW
>>>
>>> > Regarding origin trials:
>>> I havent met a front-end dev who's been interested in an origin
>>> trial, but fullstack or backend devs needing a high impact business feature
>>> (like a fugu feature) do. We didn't do an origin trial for scrollend
>>> <https://developer.chrome.com/blog/scrollend-a-new-javascript-event>,
>>> and that felt like the right path forward. Feels like these 2 events are in
>>> a similar bucket as scrollend.
>>>
>>> Let me know how else I can help!
>>>
>>> On Wed, Jun 5, 2024 at 7:40 PM Alex Russell 
>>> wrote:
>>>
>>>> Thanks for the link, Phillip. Absolutely agree that this is an unmet
>>>> need and something we should have added long ago; I'd just like to see
>>>> evidence that we're matching that need with a sufficient solution and that
>>>> we've done our homework. There's almost nothing worse than getting to the
>>>

Re: [blink-dev] Intent to Ship: Protected Audience - Fix implementation and spec for renderSize

[Yoav Weiss (@Shopify)]

LGTM1

This sounds like a web-exposed bug fix, and I agree that the risk seems low.

On Tue, Jun 11, 2024 at 6:10 PM 'Xiaochen Zhou' via blink-dev <
blink-dev@chromium.org> wrote:

> I have started the requests, thank you. This item was originated from a
> previous launch:
> https://chromestatus.com/feature/5140606359175168?gate=5143092244250624.
> This feature was added to the Protected Audience explainer, but was never
> implemented or spec'd. This launch implemented this missing feature and
> added it to the spec. Please refer to the previous launch for reviews,
> thank you.
>
> On Tuesday, June 11, 2024 at 11:36:28 AM UTC-4 vmp...@chromium.org wrote:
>
>> Hi,
>>
>> Can you please start the various reviews in chromestatus?
>> [image: chipsna.png]
>>
>> Thanks,
>> Vlad
>>
>> On Fri, Jun 7, 2024 at 11:10 AM 'Xiaochen Zhou' via blink-dev <
>> blin...@chromium.org> wrote:
>>
>>> Contact emails
>>>
>>> xiaoc...@google.com, shiva...@google.com, jka...@google.com
>>>
>>> Explainer
>>>
>>> https://github.com/WICG/turtledove/pull/1145
>>>
>>> Specification
>>>
>>> https://github.com/WICG/turtledove/pull/1141
>>>
>>> Design docs
>>>
>>>
>>> https://docs.google.com/document/d/1JSUZzEnVGn6Rz6ncLbyhThModoxTGnBn-jS5xJf4Aq0/edit?usp=sharing
>>>
>>> Summary
>>>
>>> We will complete the renderSize implementation to match what the
>>> Protected Audience explainer claims
>>> .
>>> The explainer states that if the Protected Audience generateBid function
>>> returns a render URL with size specified, then the browserSignals argument
>>> to the scoreAd function will have a renderSize field reflecting that size
>>> (so that all relevant information about the bid is available for scoring).
>>> However this was missed during implementation.
>>>
>>> Setting this field is unlikely to break existing usage as this field has
>>> been a part of the explainer for 7 months and has always been optional.
>>> renderSize is only passed into scoreAd(), as part of browserSignals, if
>>> generateBid() returned a width and height. If it is specified, script can
>>> check whether the fix is enabled by executing:
>>>
>>> 'renderSize' in browserSignals
>>>
>>> See Github issue  and
>>> explainer sections for renderSize
>>> 
>>> .
>>>
>>> Blink component
>>>
>>> Blink>InterestGroups
>>> 
>>>
>>> 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
>>>
>>> Additional debugging capabilities are not necessary for these feature
>>> changes.
>>>
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>>> Linux, ChromeOS, Android, and Android WebView)?
>>>
>>> No
>>>
>>> Supported on all six Blink platforms except Android WebView.
>>>
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?
>>>
>>> Yes, it is tested by
>>> third_party/blink/web_tests/external/wpt/fledge/tentative/score-ad-browser-signals.https.window.js.
>>>
>>> Flag name on chrome://flags
>>>
>>> None
>>>
>>> Finch feature name
>>>
>>> None
>>>
>>
Please add a runtime flag with a base feature for this, just in case this
turns out riskier than expected.


>
>>> Non-finch justification
>>>
>>> None
>>>
>>> Requires code in //chrome?
>>>
>>> False
>>>
>>> Tracking bug
>>>
>>> https://issues.chromium.org/u/1/issues/333628467
>>>
>>> Launch bug
>>>
>>> https://launch.corp.google.com/launch/4319084
>>>
>>> Estimated milestones
>>>
>>> No milestones specified
>>>
>>>
>>> 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/5181817440436224
>>>
>>> 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+.

Re: [blink-dev] Re: Intent to Ship: document.caretPositionFromPoint API

[Yoav Weiss (@Shopify)]

On Thu, Jun 6, 2024 at 9:03 PM 'Siye Liu' via blink-dev <
blink-dev@chromium.org> wrote:

> Reviews requested.
>
> Thanks,
> Siye
>
> On Thursday, June 6, 2024 at 9:47:37 AM UTC-7 Chris Harrelson wrote:
>
>> Hi, please fill out these reviews on your chromestatus entry:
>>
>> [image: image.png]
>>
>> On Wed, Jun 5, 2024 at 8:09 PM 'Siye Liu' via blink-dev <
>> blin...@chromium.org> wrote:
>>
>>> Yes, the API returns offset inside text input and textarea elements.
>>>
>>> Thanks,
>>> Siye
>>>
>>> On Wednesday, June 5, 2024 at 5:10:18 PM UTC-7 Brian Birtles wrote:
>>>
 Hi,

 Does this return the offset inside text input elements like Gecko's
 implementation?

 Best regards,

 Brian

 2024年6月6日木曜日 3:20:24 UTC+9 si...@microsoft.com:

> Contact emails
> si...@microsoft.com, sa...@microsoft.com
>
> Explainer
> None
>
> Specification
>
> https://drafts.csswg.org/cssom-view/#dom-document-caretpositionfrompoint
>
> Summary
> This new API allows users to get current caret position from a given
> screen point.
>
> The API returns a CaretPosition object which represents the caret
> position indicating current text insertion point including the containing
> DOM node, caret's character offset, and the client rectangle of caret
> range. The API also supports get CaretPosition inside Shadow DOM. To get
> CaretPosition inside Shadow DOM, caller needs to provide reference to all
> the shadow roots that this API can pierce into.
>
>
> Blink component
> Blink>CSS
> 
>
> TAG review
> document.caretPositionFromPoint API in shadow DOM scenario · Issue
> #949 · w3ctag/design-reviews (github.com)
> 
>
> TAG review status
> Issues open
>
> Risks
>
>
> Interoperability and Compatibility
> Gecko already implemented the API without the argument that contains
> shadow roots that this API can pierce into. Webkit/Blink didn't implement
> it. The Gecko implementation in shadow DOM scenario is not spec-compliant
> either (Spec changed recently to cover shadow DOM scenario). Gecko 's
> position is positive on this API. We expect that Gecko's behavior will be
> changed to be spec-compliant in the future. There is also a future compat
> risk too if we decided to deprecate the non-standard API
> `document.caretRangeFromPoint`: https://crbug.com/690599
>
>
> *Gecko*: Positive (
> https://github.com/mozilla/standards-positions/issues/1012)
>
> *WebKit*: Support (
> https://github.com/WebKit/standards-positions/issues/301)
>
> *Web developers*: Positive (
> https://bugs.chromium.org/p/chromium/issues/detail?id=388976#c34) Web
> developers are asking to have document.caretPositionFromPoint API
> implemented in Blink:
> https://bugs.chromium.org/p/chromium/issues/detail?id=388976#c28
> https://bugs.chromium.org/p/chromium/issues/detail?id=388976#c34
>
> *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
> 
> ?
> Yes
>
>
> https://github.com/web-platform-tests/wpt/blob/master/css/cssom/caretPositionFromPoint.html
> https://github.com/web-platform-tests/wpt/blob/master/shadow-dom/Document-caretPositionFromPoint.tentative.html
>

Looking at
https://wpt.fyi/results/css/cssom/caretPositionFromPoint.html?label=experimental&label=master&aligned
and
https://wpt.fyi/results/shadow-dom/Document-caretPositionFromPoint.tentative.html?label=experimental&label=master&aligned,
I see that Chromium is failing all of them, due to the "test" status of the
relevant flag.

Are we passing the tests with the flag enabled? Do the few Mozilla failures
represent their deviation from the spec? Or something else?


>
> Flag name on chrome://flags
> None
>
> Finch feature name
> CaretPositionFromPoint
>
> Requires code in //chrome?
> False
>
> Tracking bug
> https://crbug.com/388976
>
> Estimated milestones
> Shipping on desktop
> 127
> DevTrial on desktop
> 127
>
>
> 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 g

Re: [blink-dev] Intent to Experiment: WebGPU Subgroups experimentation

[Yoav Weiss (@Shopify)]

What milestones do you want the experiment to run?

On Tue, Jun 11, 2024 at 9:02 PM 'Alan Baker' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emailsalanba...@google.com
>
> Explainerhttps://github.com/gpuweb/gpuweb/blob/main/proposals/subgroups.md
>
> SpecificationNone
>
> Summary
>
> Adds subgroup functionality to WebGPU. Subgroup operations perform SIMT
> operations to provide efficient communication and data sharing among groups
> of invocations. These operations can be used to accelerate applications by
> reducing memory overheads incurred by inter-invocation communication.
>
>
> Blink componentBlink>WebGPU
> 
>
> TAG reviewNone
>
> TAG review statusPending
>
> 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
>
>
> Goals for experimentation
>
> We wish to more broadly test portability, performance, and reach beyond
> our accessible test devices. We have partners that could leverage these
> features in existing products to provide feedback. For example, Mediapipe
> would be able to leverage this feature easily.
>
> We also wish to gather feedback to help shape the API and answer the
> following questions:
> * Which parts are essential?
> * What additions would make a meaningful impact?
> * Can we mitigate non-portable behaviours for common usages?
>
> Ongoing technical constraints
>
> None
>
>
> Debuggability
>
> None
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, ChromeOS, Android, and Android WebView)?No
>
> Is this feature fully tested by web-platform-tests
> 
> ?No
>
> Flag name on chrome://flagsNone
>
> Finch feature nameNone
>
> Non-finch justificationNone
>
> Requires code in //chrome?False
>
> Estimated milestones
>
> No milestones specified
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5126409856221184
>
> 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/CABg%2BrB7%2B-cAZNO-mckZ%2BaK8D0ZPZ4iJYi1kmU%2Bt60i%3DFzvL-gw%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/CAOmohS%2B3TeUPu9xwnxkeXDc3h%2BvjNse0Vyb5MQT2oMBU-s9_bQ%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Attribution Reporting Feature: Aggregate Debug Reporting

[Yoav Weiss (@Shopify)]

On Tue, Jun 11, 2024 at 7:43 PM Akash Nadan  wrote:

> Hi Yoav,
>
> The debug signals that will be reported on are documented here:
> https://github.com/WICG/attribution-reporting-api/blob/main/verbose_debugging_reports.md
>

Thanks! Should that be part of the spec?


>
> These are the same debug signals that current debug reports support. We
> plan to support the same set of debug signals in this new feature as well.
>

> These debug signals are not developer defined, however a developer can
> specify which of the signals they want to track and can group certain
> signals together (more details here
> <https://github.com/WICG/attribution-reporting-api/blob/main/aggregate_debug_reporting.md#opting-in-aggregate-debug-reporting>
> ).
>
> Thanks,
> Akash
> On Monday, June 10, 2024 at 10:02:08 PM UTC-7 Yoav Weiss (@Shopify) wrote:
>
>> On Fri, Jun 7, 2024 at 8:12 PM 'Akash Nadan' via blink-dev <
>> blin...@chromium.org> wrote:
>>
>>> Contact emails
>>>
>>> akash...@google.com, lin...@chromium.org, john...@chromium.org
>>>
>>> Explainer
>>>
>>> Attribution Reporting with event-level reports
>>> <https://github.com/WICG/attribution-reporting-api/blob/main/EVENT.md>
>>>
>>> Attribution Reporting API with Aggregatable Reports
>>> <https://github.com/WICG/attribution-reporting-api/blob/main/AGGREGATE.md>
>>>
>>> Aggregation Service for the Attribution Reporting API
>>> <https://github.com/WICG/attribution-reporting-api/blob/main/AGGREGATION_SERVICE_TEE.md>
>>>
>>> Specification
>>>
>>> https://wicg.github.io/attribution-reporting-api/
>>>
>>> Blink component
>>>
>>> Internals > AttributionReporting
>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3EAttributionReporting>
>>>
>>> TAG review
>>>
>>> Still under review <https://github.com/w3ctag/design-reviews/issues/724>
>>> under the original I2S for the Attribution Reporting API
>>>
>>> TAG review status
>>>
>>> Pending
>>>
>>> Summary
>>>
>>> We are landing the following changes to the Attribution Reporting API
>>> focused on:
>>>
>>>-
>>>
>>>improving debugging capabilities
>>>
>>>
>>> This change is based on ad-tech feedback and the need to support
>>> debugging capabilities after third-party cookie deprecation.
>>>
>>> Currently the API supports debug reports that are tied to third-party
>>> cookies. In order for an API caller to receive a debug report of any kind
>>> they need to make sure a specific third-party cookie (i.e. ar_debug) is
>>> properly set. The API will check to make sure this cookie is set before
>>> providing any kind of debug report. Once third-party cookies are deprecated
>>> these debug reports will no longer be available.
>>>
>>> This change is so the API can continue to provide debugging information
>>> after third-party cookie deprecation when the current debug reports that
>>> are tied to third-party cookies are no longer available. This is a new
>>> report type that is not tied to third-party cookies and provides similar
>>> debug information. This feature allows API callers to request and receive
>>> debug signals in aggregate form. This feature is very similar to current
>>> Aggregate Reports supported by the API, except these new reports will be
>>> specifically for debug signals.
>>>
>>
>> Can you expand on what debug signals are being aggregated? Are they
>> developer-defined somehow?
>>
>>
>>>
>>> This new feature will allow API callers to continue receiving debugging
>>> information even after third-party cookie deprecation.
>>>
>>> Explainer/Spec changes
>>>
>>>1.
>>>
>>>Explainer:
>>>
>>> https://github.com/WICG/attribution-reporting-api/blob/main/aggregate_debug_reporting.md
>>>2.
>>>
>>>Spec:
>>>1.
>>>
>>>   https://github.com/WICG/attribution-reporting-api/pull/1310
>>>   2.
>>>
>>>   https://github.com/WICG/attribution-reporting-api/pull/1292
>>>
>>>
>>> Risks
>>> Interoperability and Compatibility
>>>
>>> This is an optional and fully backwards compatible change. This feature
>>> provides a new mechanism fo

Re: [blink-dev] Re: Intent to Ship: SkipAd media session action

[Yoav Weiss (@Shopify)]

LGTM1

On Tue, Jun 11, 2024 at 12:14 AM 'Jiaming Cheng' via blink-dev <
blink-dev@chromium.org> wrote:

> Thanks François for the info!
>
> Hi Philip, please let us know if you have any other questions or concerns
> :]
>
> Best,
> Jiaming
>
> On Wed, Jun 5, 2024 at 9:46 AM François Beaufort 
> wrote:
>
>>
>>
>> On Wed, Jun 5, 2024 at 5:49 PM Philip Jägenstedt 
>> wrote:
>>
>>> Hi Jiaming,
>>>
>>> This feature has previously come across my radar as it appears in MDN to
>>> be implemented by both Firefox and Safari already:
>>>
>>> https://developer.mozilla.org/en-US/docs/Web/API/MediaSession/setActionHandler#browser_compatibility
>>>
>>> Is this accurate, is it in fact already implemented in Firefox and
>>> Safari?
>>>
>>>
>> From what I can see in https://bugs.webkit.org/show_bug.cgi?id=217797,
>> WebKit implements SkipAd.
>> Firefox also implements it according to
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1582569
>>
>
In that case we shouldn't have filed positions and a TAG review..


>
>>
>> Best regards,
>>> Philip
>>>
>>> On Tue, Jun 4, 2024 at 10:33 PM 'Jiaming Cheng' via blink-dev <
>>> blink-dev@chromium.org> wrote:
>>>
 Hey Alex,

 Thanks for your feedback! I have talked with the previous owner
 (fbeaufort@) of this feature. Please see our answers below inline.

- Are you investigating a generic action button type, the way we've
added one for Notifications

?
- If you have investigated that, would this feature be better as a
custom user/developer action?

 The skipAd media session action is not related to Notifications at all.
 It is a common media action like play, pause, next, previous, skip, etc.
 See historical PR that was approved by Media Session folks:
 https://github.com/w3c/mediasession/pull/203#issuecomment-432529816


- Have you asked the TAG about consistency w/ Notification Actions
for this design? and, most importantly...

 The TAG folks have not started talking about this yet at
 https://github.com/w3ctag/design-reviews/issues/957


- Has there been developer feedback that supports this, either from
OT or from community feedback more generally?

 Our team (ChromeOS) and the Youtube team are recently planning to
 integrate this feature in our upcoming project, so that's why we are now
 proposing to enable it.


 Let me know if you have any other questions :]


 Best,
 Jiaming

 On Wed, May 29, 2024 at 9:04 AM Alex Russell 
 wrote:

> Hey folks,
>
> A few questions from today's API OWNERS:
>
>
>- Are you investigating a generic action button type, the way
>we've added one for Notifications
>
>?
>- If you have investigated that, would this feature be better as a
>custom user/developer action?
>- Have you asked the TAG about consistency w/ Notification Actions
>for this design? and, most importantly...
>- Has there been developer feedback that supports this, either
>from OT or from community feedback more generally?
>
> Best,
>
> Alex
>
> On Thursday, May 23, 2024 at 1:28:03 PM UTC-7 Jiaming Cheng wrote:
>
>> Updated the subject of this thread.
>>
>> Key links:
>> ChromeStatus:
>> https://chromestatus.com/feature/4749278882824192?gate=4775000754618368
>> TAG: https://github.com/w3ctag/design-reviews/issues/957
>> Mozilla: https://github.com/mozilla/standards-positions/issues/1026
>> Webkit: https://github.com/WebKit/standards-positions/issues/350
>>
>> On Thu, May 23, 2024 at 1:13 PM Chris Harrelson <
>> chris...@chromium.org> wrote:
>>
>>>
>>>
>>> On Thu, May 23, 2024 at 1:10 PM Jiaming Cheng 
>>> wrote:
>>>
 Hi Chris,

 We are looking to ship this feature to Stable. We have reused an
 existing chromestatus (
 https://chromestatus.com/feature/4749278882824192?gate=4775000754618368)
 and updated almost every section, including filling all the "Prepare to
 Ship" section. This email was automatically generated by the "API 
 Owners
 Review" step in that section after each individual section was 
 approved. I
 have quoted the previous email thread in this email for additional 
 context.

>>>
>>> Ok. Please then start a new thread (or reply with a change of
>>> subject) to "Intent to ship: Skip Ad in Picture-in-Picture window"
>>>
>>>

 If you have any further questions or concerns, please let us know.

 Thanks,
 Jiaming

 On Thu, May 23, 2024 at 12:29 PM Chris Harrelson <
>

Re: [blink-dev] Intent to Ship: Snap Events

[Yoav Weiss (@Shopify)]

On Fri, Jun 7, 2024 at 5:47 PM 'Adam Argyle' via blink-dev <
blink-dev@chromium.org> wrote:

> Indeed, developer sentiment is full of excitement! Who wouldn't want to
> throw out their hyper intersection observers with a perfectly timed
> callback? or even better, getting insights into the concept of "changing"
> which is currently opaque to authors.
>
> > Philip: For the scrollsnapchange event it's easy to imagine updating
> some state below a carousel to match the snapped element, such as item
> description or store inventory. For scrollsnapchanging I don't dare hazard
> a guess, can someone say what the canonical use case for this is?
> I think you'll find that snapchanging is very prominent in mobile gesture
> based UI and may be used even more than snapchange. Like one of those
> features you can't unsee once you see it working. Consider this video I
> took of a game on mobile
> 
> ,
>

It's 404ing for me..


> snapchanging and snapchanged are distinctly used for 2 separate moments of
> UI feedback. I have many examples like this! The examples are what led to
> the APIs. Another really common example will be revealing the caption or
> action buttons in a carousel. Which it's probably worth noting we're
> working on a CSS way to know some of this information too, we're
> prototyping snapped as a "state query."
>
> Here's a few demo's showing some "picker" use cases, which I feel will be
> the majority cases, where folks are observing the snapped or soon to be
> snapped item and updating ancillary UI for the user. I have a backlog of
> many more to make 😅 Think of these things like snap triggered animation,
> which can be a very healthily compliment to scroll driven animation (which
> currently doesn't have a "trigger" feature, only linked).
>
> I bucket the 2 events like:
> - the *scrollsnapchanging* event is eager to provide user feedback, can
> fire many more times than change
> - while *scrollsnapchange* is great for user feedback after they've
> lifted their finger or scroll has ended, timed better for confirmation or
> whatever. I show an example below that I use change instead of changing so
> the animation trigger isn't too busy.
>
> *Color picker*:
> https://codepen.io/argyleink/pen/zYXdgew
>
> *Date time picker (both eager and timed):*
> https://codepen.io/argyleink/pen/WNageoZ
>
> *Date time picker (eager):*
> https://codepen.io/argyleink/pen/oNOWwKq
>
> *Date time picker (timed for view transitions):*
> https://codepen.io/argyleink/pen/LYvzGRW
>
> > Regarding origin trials:
> I havent met a front-end dev who's been interested in an origin trial, but
> fullstack or backend devs needing a high impact business feature (like a
> fugu feature) do. We didn't do an origin trial for scrollend
> , and
> that felt like the right path forward. Feels like these 2 events are in a
> similar bucket as scrollend.
>
> Let me know how else I can help!
>
> On Wed, Jun 5, 2024 at 7:40 PM Alex Russell 
> wrote:
>
>> Thanks for the link, Phillip. Absolutely agree that this is an unmet need
>> and something we should have added long ago; I'd just like to see evidence
>> that we're matching that need with a sufficient solution and that we've
>> done our homework. There's almost nothing worse than getting to the end of
>> a launch and realizing that some important use-cases isn't covered, and I
>> don't have confidence based on what we've produced that we would not end up
>> in this situation.
>>
>> An exhaustive explainer with considered alternatives and sample code
>> would unblock this from my end.
>>
>> Best,
>>
>> Alex
>>
>> On Wednesday, June 5, 2024 at 9:48:48 AM UTC-7 David Awogbemila wrote:
>>
>>>
>>> Hi Alex, thanks for yout input!
>>>
>>> (Like Tab said, we’re planning to have a review of the feature as a
>>> whole so I plan to share any feedback from that here, but since that 
>>> won’t
>>> happen for at least another week, I wanted to update this thread in the
>>> meantime.)
>>>
>>> I'm now hosting the explainer
>>> 
>>> and I've updated it to reflect the research and investigation which went
>>> into the API design (which I certainly should have done earlier). We've
>>> discussed all of the non-trivial decisions made for the API over many 
>>> CSSWG
>>> issues
>>> .
>>> The API choices reflect the minimum amount of information that meets the
>>> needs of use cases we have evidence
>>> 
>>> of interest in: the element that was selected as the snap target, and
>>> deferred adding other bits of information for which we don't

Re: [blink-dev] Intent to Ship: Attribution Reporting Feature: Aggregate Debug Reporting

[Yoav Weiss (@Shopify)]

On Fri, Jun 7, 2024 at 8:12 PM 'Akash Nadan' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emails
>
> akashna...@google.com, lin...@chromium.org, johni...@chromium.org
>
> Explainer
>
> Attribution Reporting with event-level reports
> 
>
> Attribution Reporting API with Aggregatable Reports
> 
>
> Aggregation Service for the Attribution Reporting API
> 
>
> Specification
>
> https://wicg.github.io/attribution-reporting-api/
>
> Blink component
>
> Internals > AttributionReporting
> 
>
> TAG review
>
> Still under review 
> under the original I2S for the Attribution Reporting API
>
> TAG review status
>
> Pending
>
> Summary
>
> We are landing the following changes to the Attribution Reporting API
> focused on:
>
>-
>
>improving debugging capabilities
>
>
> This change is based on ad-tech feedback and the need to support debugging
> capabilities after third-party cookie deprecation.
>
> Currently the API supports debug reports that are tied to third-party
> cookies. In order for an API caller to receive a debug report of any kind
> they need to make sure a specific third-party cookie (i.e. ar_debug) is
> properly set. The API will check to make sure this cookie is set before
> providing any kind of debug report. Once third-party cookies are deprecated
> these debug reports will no longer be available.
>
> This change is so the API can continue to provide debugging information
> after third-party cookie deprecation when the current debug reports that
> are tied to third-party cookies are no longer available. This is a new
> report type that is not tied to third-party cookies and provides similar
> debug information. This feature allows API callers to request and receive
> debug signals in aggregate form. This feature is very similar to current
> Aggregate Reports supported by the API, except these new reports will be
> specifically for debug signals.
>

Can you expand on what debug signals are being aggregated? Are they
developer-defined somehow?


>
> This new feature will allow API callers to continue receiving debugging
> information even after third-party cookie deprecation.
>
> Explainer/Spec changes
>
>1.
>
>Explainer:
>
> https://github.com/WICG/attribution-reporting-api/blob/main/aggregate_debug_reporting.md
>2.
>
>Spec:
>1.
>
>   https://github.com/WICG/attribution-reporting-api/pull/1310
>   2.
>
>   https://github.com/WICG/attribution-reporting-api/pull/1292
>
>
> Risks
> Interoperability and Compatibility
>
> This is an optional and fully backwards compatible change. This feature
> provides a new mechanism for receiving debugging information and does not
> break any pre-existing API or web functionality.
>
> Gecko: No signal (Original request:
> https://github.com/mozilla/standards-positions/issues/791)
>
> WebKit: No signal (Original request:
> https://github.com/WebKit/standards-positions/issues/180)
>
> Web developers:
> https://github.com/WICG/attribution-reporting-api/issues/705
>
>
> 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
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?
>
> The attribution reporting feature will be supported on all platforms with
> the exception of Android WebView
>
> Is this feature fully tested by web-platform-tests
> 
> ?
>
> Yes
>
> Estimated milestones
>
> This feature is anticipated to ship as part of Chrome 127
> .
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5086433709916160
>
> Links to previous Intent discussions
>
> Previous I2S:
>
> Intent to Ship: Attribution Reporting API
> 
>
> Intent to Ship: Attribution Reporting features M117
> 
>
> Intent to Ship: Attribution Reporting features M118
> 
>
> Intent to Ship: Attribution Reporting features M119
> 
>
> Intent to Ship: Attribution Reporting features M120
> 
>
> Intent to Ship: Attribution Reporting features M121
> 

Re: [blink-dev] Intent to Ship: Support 'color-interpolation: linearrgb' on SVG gradients

[Yoav Weiss (@Shopify)]

On Mon, Jun 10, 2024 at 11:25 AM Fredrik Söderquist  wrote:

> Contact email...@opera.com
>
> ExplainerNone
>
> Specificationhttps://svgwg.org/svg2-draft/painting.html#ColorInterpolation
>
> Summary
>
> Allows SVG gradients to interpolate in a linear-light sRGB color space.
> Currently all SVG gradients interpolate in a gamma-encoded sRGB color space.
>
>
> Blink componentBlink>SVG
> 
>
> Search tagsSVG , CSS
> , Color
> 
>
> TAG reviewNone
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> The risk along both axes is fairly low since the difference is in
> rendering only (even if the rendering can differ quite significantly).
>
>
> *Gecko*: Shipped/Shipping (
> https://www.mozilla.org/en-US/firefox/123.0/releasenotes)
>
> *WebKit*: No signal
>

Can you file for a 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
> 
> ?Yes
>
>
> https://wpt.fyi/results/svg/pservers/reftests/gradient-color-interpolation.svg
>
>
> Flag name on chrome://flagsNone
>
> Finch feature nameSvgGradientColorInterpolationLinearRgbSupport
>
> Requires code in //chrome?False
>
> Tracking bughttps://issues.chromium.org/issues/324440102
>
> Estimated milestones
> Shipping on desktop 127
> Shipping on Android 127
> Shipping on WebView 127
>
> 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/5131849549742080?gate=6228725141340160
>
> 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/CAHediLSkF96MOwMyoU7FbrF14-fy_3TfMD-JNdjn-DqO5o1X4w%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/CAOmohS%2B9dhgDZ66WMN2EAQtcqtG0TQNPAaQzA5fnBnpYT2yZUQ%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Protected Audience: Allow trusted bidding signals to trigger interest group updates

[Yoav Weiss (@Shopify)]

LGTM2

On Mon, Jun 10, 2024 at 8:41 PM Mike Taylor  wrote:

> On 6/4/24 1:53 PM, Caleb Raitto wrote:
>
> Response inline
>
> On Monday, June 3, 2024 at 10:16:06 PM UTC-4 Mike Taylor wrote:
>
> On 5/31/24 11:40 PM, Paul Jensen wrote:
>
> Contact emails
>
> pauljen...@chromium.org
>
>
> Explainer
>
> https://github.com/WICG/turtledove/pull/1095
>
>
> Specification
>
> https://github.com/WICG/turtledove/pull/1124
>
>
> Summary
>
> The Protected Audience API allows bidders to store information, called an
> interest group, from a single site in the browser that can only be read
> later in the context of an auction.  Today, interest groups can be updated
> by fetching new values from a server.  For all interest groups, the
> frequency of these updates is rate limited to at most once a day to
> conserve network traffic and avoid overwhelming servers.  However, we've
> heard from developers that certain ad campaigns need much more timely
> updates.  During Protected Audience auctions, the browser fetches real-time
> signals from bidders' key-value servers.  This proposal allows the response
> to these fetches to indicate a subset of interest groups they’d like
> updated more frequently than once a day.
>
>
> Blink component
>
> Blink>InterestGroups
> 
>
>
> TAG review
>
> For Protected Audience: https://github.com/w3ctag/
> design-reviews/issues/723
>
>
> TAG review status
>
> Completed for Protected Audience, resolved unsatisfied.
>
>
> Risks Interoperability and Compatibility
>
> Feature represents optional new behavior that shouldn’t break existing
> usage.
>
>
> Gecko & WebKit: No signal on parent proposal, Protected Audience.  Asked
> in the Mozilla forum here
> , and in the
> Webkit forum here
> .
>
>
> Edge: Edge has announced plans to support the Ad Selection API
> 
> which shares much of its API surface with Protected Audience.
>
>
> Web developers:
>
> Feature requested by Microsoft in GitHub issue
> .
>
> I don't see any feedback from Microsoft on this design in the issue (just
> from Criteo, which seems inconclusive). Have they given feedback elsewhere?
>
>
> The response from Microsoft (ads) is here:
> https://github.com/WICG/turtledove/issues/729#issuecomment-1822190741 --
> it's the opening paragraph that starts with "I do think having a 'please
> refresh when this auction is over' lever is a clear improvement over the
> current situation from a functionality perspective".
>
> OK - thanks. I was hoping they might have responded elsewhere to your
> request for feedback from April
> 
> or May, but I don't see a reason to block on that.
>
> LGTM1
>
>
>
>
> Debuggability
>
> Protected Audience trusted bidding signals show up in the DevTools Network
> pane. Updates show up in the Application -> Storage -> Interest Groups
> DevTools pane.
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, ChromeOS, Android, and Android WebView)?
>
> It will be supported on all platforms that support Protected Audience, so
> all but WebView.
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?
>
> Yes
> 
> .
>
>
> Flag name on chrome://flags
>
> None
>
>
> Finch feature name
>
> InterestGroupUpdateIfOlderThan
>
>
> Requires code in //chrome?
>
> False
>
>
> Estimated milestones
>
> Shipping on desktop and Android in M125.
>
>
> Anticipated spec changes
>
> None
>
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5162656775536640
>
>
> 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/CABQTWr%3DWxOenJmSZ5oW%3DVDdJ9q1nwovSJdgPw_
> 91Fp3fkV01ew%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 v

Re: [blink-dev] Intent to Deprecate and Remove: 0.0.0.0 for Private Network Access

[Yoav Weiss (@Shopify)]

LGTM2

On Wed, Jun 5, 2024 at 5:41 PM Daniel Bratell  wrote:

> LGTM1
>
> /Daniel
> On 2024-06-03 18:03, 'David Adrian' via blink-dev wrote:
>
> Contact emails l...@chromium.org
>
> Explainer None
>
> Specification https://wicg.github.io/private-network-access
>
> Summary
>
> We propose to block access to IP address 0.0.0.0 in advance of PNA
> completely rolling out. Chrome is deprecating direct access to private
> network endpoints from public websites as part of the Private Network
> Access (PNA) specification (
> https://developer.chrome.com/blog/private-network-access-preflight/).
> Services listening on the localhost (127.0.0.0/8) are considered private
> according to the specification (
> https://wicg.github.io/private-network-access/#ip-address-space-heading).
> Chrome's PNA protection (rolled out as part of
> https://chromestatus.com/feature/5436853517811712) can be bypassed using
> the IP address 0.0.0.0 to access services listening on the localhost on
> macOS and Linux. This can also be abused in DNS rebinding attacks targeting
> a web application listening on the localhost. Since 0.0.0.0 is not used in
> practice (and should not be used), but was overlooked during
> https://chromestatus.com/feature/5436853517811712, we're deprecating it
> separately from the rest of the private network requests deprecation. This
> will be a Finch (experimental) rollout, rather than a Developer Trial.
>
>
> Blink component Blink>SecurityFeature>CORS>PrivateNetworkAccess
> 
>
> Search tags security , 
> Private
> Network Access
> 
>
> TAG review None
>
> TAG review status Not applicable
>
> Chromium Trial Name PrivateNetworkAccessNullIpAddressAllowed
>
> Origin Trial documentation link https://crbug.com/1300021
>
> WebFeature UseCounter name kPrivateNetworkAccessNullIpAddress
>
> Risks
>
>
> Interoperability and Compatibility
>
> None
>
>
> *Gecko*: Closed Without a Position (
> https://github.com/mozilla/standards-positions/issues/143)
>
> *WebKit*: Support (
> https://github.com/WebKit/standards-positions/issues/163)
>
> *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
>
>
> Goals for experimentation
>
> Ongoing technical constraints
>
> Eventually, all private network access will be limited according to the
> developing Private Network Access spec.
>
>
> 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 block-null-ip-address
>
> Finch feature name PrivateNetworkAccessNullIpAddress
>
> Requires code in //chrome? False
>
> Tracking bug https://crbug.com/1300021
>
> Estimated milestones
> Shipping on desktop 133
> Origin trial desktop first 127
> Origin trial desktop last 133
> DevTrial on desktop 127
> Shipping on Android 133
> OriginTrial Android last 133
> OriginTrial Android first 127
> DevTrial on Android 127
> Shipping on WebView 133
> OriginTrial webView last 133
> OriginTrial webView first 127
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5106143060033536
>
> 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/CAGkh42L-7xt9YY-jmq-G4-nuitqELpgqgnvECkbCoPpAWWMMjw%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/683cadae-9413-4125-9209-4ecfe1b812aa%40sarasas.se
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop re

[blink-dev] Intent to Prototype: noopener-allow-popups COOP value

[Yoav Weiss (@Shopify)]

Contact emailsyoavwe...@chromium.org

Explainerhttps://gist.github.com/yoavweiss/c7b61e97e6f8d207be619f87ab96ead5

Specificationhttps://github.com/whatwg/html/pull/10394

Summary

Some origins can contain different applications with different levels of
security requirements. In those cases, it can be beneficial to prevent
scripts running in one application from being able to open and script pages
of another same-origin application. In such cases, it can be beneficial for
a document to ensure its opener cannot script it, even if the opener
document is a same-origin one. The `noopener-allow-popups`
Cross-Origin-Opener-Policy value will allow documents to define that.


Blink componentBlink


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

TAG review statusPending

Risks


Interoperability and Compatibility

Compatibility risk: As this feature adds a new COOP value, it doesn't run a
risk of colliding with existing values. Where we may see some risk is when
developers start using this value in ways that would surprise other teams
on their origins. (as they would no longer have scripting access to opened
documents) I don't expect that to happen often, and if it would it's
something that developers would find out at development time. So I don't
expect that to impact users. Interoperability risk: Too early to tell as
positions/PR was just filed.


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

*WebKit*: No signal (
https://github.com/WebKit/standards-positions/issues/360)

*Web developers*: No signals

*Other signals*:

Security

None: https://gist.github.com/yoavweiss/3cb7283f56717f6dfe6da05009a27a65


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


Goals for experimentation



Ongoing technical constraints

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

?

It will be:
https://chromium-review.googlesource.com/c/chromium/src/+/5581251/8/third_party/blink/web_tests/external/wpt/html/cross-origin-opener-policy/coop-noopener-allow-popups.https.html


Flag name on chrome://flagsNone

Finch feature nameNone

Non-finch justificationNone

Requires code in //chrome?False

Tracking bughttps://issues.chromium.org/issues/344963946

Estimated milestones

No milestones specified


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

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/CAOmohSJj33d%3D0B0tNpD0qrYWzygx0i02bWdhbV3aSCgbjS3Ndw%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Ship: Importmap integrity

[Yoav Weiss (@Shopify)]

Thanks for the extra support :)

On Tue, Jun 4, 2024, 09:30 Daniel Bratell  wrote:

> Doh, make that a bonus LGTM4. Sorry for the confusion.
>
> /Daniel
> On 2024-06-04 09:29, Daniel Bratell wrote:
>
> LGTM3
>
> /Daniel
> On 2024-05-30 19:41, Vladimir Levin wrote:
>
> LGTM2
>
> On Wed, May 29, 2024 at 11:41 AM Mike Taylor 
> wrote:
>
>> LGTM1
>> On 5/24/24 3:13 PM, Yoav Weiss (@Shopify) wrote:
>>
>>
>>
>> On Fri, May 24, 2024 at 7:12 PM Panos Astithas 
>> wrote:
>>
>>>
>>>
>>> On Wed, May 22, 2024 at 2:16 AM Yoav Weiss (@Shopify) <
>>> yoavwe...@chromium.org> wrote:
>>>
>>>>
>>>>
>>>> On Wed, May 22, 2024 at 10:29 AM Yoav Weiss (@Shopify) <
>>>> yoavwe...@chromium.org> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Tuesday, May 21, 2024 at 1:04:44 PM UTC+2 Yoav Weiss wrote:
>>>>>
>>>>> Contact emailsyoavwe...@chromium.org
>>>>>
>>>>> Explainerhttps://github.com/guybedford/import-maps-extensions#
>>>>> integrity
>>>>>
>>>>> Specificationhttps://github.com/whatwg/html/pull/10269
>>>>>
>>>>> The PR is ready to land, but we're holding off on that for 2 weeks at
>>>>> Mozilla's request. See below.
>>>>>
>>>>> Summary
>>>>>
>>>>> Imported ES modules can't currently have their integrity checked, and
>>>>> hence cannot run in environments that require Subresource Integrity or 
>>>>> with
>>>>> `require-sri-for` CSP directives. This feature adds an `integrity` section
>>>>> to import maps, enabling developers to map ES module URLs to their
>>>>> integrity metadata, and ensure they only load when they match their
>>>>> expected hashes.
>>>>>
>>>>>
>>>>> Blink componentBlink>Loader
>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ELoader>
>>>>>
>>>>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/944
>>>>>
>>>>> TAG review statusIssues addressed
>>>>>
>>>>> Risks
>>>>>
>>>>>
>>>>> Interoperability and Compatibility
>>>>>
>>>>> On the interoperability front, this got a positive position from
>>>>> WebKit, and I'm implementing the feature there
>>>>> <https://github.com/whatwg/html/pull/10269>. Mozilla didn't object to
>>>>> the feature, but asked
>>>>> <https://docs.google.com/document/d/1iaarr4Ho715CUULrvi_LD3TwshAcN2odDLBBEK0FjH0/edit#bookmark=id.li7pdpi5uloq>
>>>>>
>>>>>
>>>> I just realized that the meeting notes are not publicly viewable.
>>>> +Panos Astithas  - would you be able to open
>>>> them up to the public somehow? (e.g. as a Chromium.org doc)
>>>>
>>>
>>> They were published
>>> <https://github.com/whatwg/html/issues/10340#:~:text=Benjamin%3A%20I%27d%20like%20a%20further%20two%20weeks>
>>>  that
>>> same day, we try to post the minutes publicly in less than 24 hours.
>>>
>>
>> Oops!! My bad for using the wrong artifact!
>>
>>
>>>
>>>>
>>>>
>>>>> for a couple more weeks to evaluate it and provide a position, as they
>>>>> might be planning broader-scope work on the front of application 
>>>>> integrity,
>>>>> and want to make sure this doesn't collide with it.
>>>>>
>>>>>
>>>>> On the compatibility front, the feature is polyfilled
>>>>> <https://github.com/guybedford/es-module-shims/pull/424>, but it's turned
>>>>> off for browsers that support import maps
>>>>> <https://github.com/guybedford/es-module-shims#:~:text=The%20ES%20Module%20Shims%20polyfill%20will%20analyze%20the%20browser%20to%20see%20if%20it%20supports%20import%20maps.%20If%20it%20does%2C%20it%20doesn%27t%20do%20anything%20more>
>>>>> .
>>>>>
>>>>>
>>>>> Adding Guy Bedford, the polyfill author to this thread. Guy, can you
>>>>> confirm this is the case?
>>>>>
>>>>> *Gecko*: No signal
>>>>> <https://github.com/mozilla/standards-positions/issues/1010>
>>

Re: [blink-dev] Intent to Ship: Support Video Chapter in MediaMetadata

[Yoav Weiss (@Shopify)]

LGTM2

On Fri, May 31, 2024 at 5:52 AM 'Jiaming Cheng' via blink-dev <
blink-dev@chromium.org> wrote:

> Thanks Domenic :]
>
> On Thu, May 30, 2024 at 6:28 PM Domenic Denicola 
> wrote:
>
>> LGTM1.
>>
>> This feature and its spec fits well with the existing MediaMetadata. It
>> has received a positive position from Mozilla. The TAG review solicited a
>> good discussion of considered alternatives.
>>
>> I agree with Alex that this would have gone better with a proper
>> explainer, including considered alternatives and example code. But the
>> feature is simple enough, and thankfully we got a chance to spell out the
>> reasoning about alternatives in the TAG review, so I think we can proceed.
>>
>> On Saturday, May 18, 2024 at 1:53:09 AM UTC+9 Alex Russell wrote:
>>
>>> Sorry for the slow reply here.
>>>
>>> Glad to see this works for Audio too. This might have been a bit more
>>> obvious of there were an explainer in the usual format. I expect the TAG
>>> will ask for one of those too. Please pay particular attention to
>>> considered alternatives and example code, both for the proposed design and
>>> for discarded alternatives.
>>>
>>> https://w3ctag.org/explainers/
>>>
>>> Best,
>>>
>>> Alex
>>>
>>> On Wednesday, May 15, 2024 at 12:14:18 PM UTC-7 Jiaming Cheng wrote:
>>>
 Thanks Domenic and Mike for the reply!

 I see. It looks like we have an LGTM on the Mozilla review
 . Could we
 please add some reviewers for the TAG review as well? If not, I'm happy to
 ping this thread again in two weeks :]

 Best,
 Jiaming

 On Tue, May 14, 2024 at 10:16 PM Domenic Denicola 
 wrote:

> Hi Jiaming,
>
> Per our process
> ,
> we give the TAG and other vendors at least one month to comment on 
> changes.
> (This is why it is recommended to start these reviewers earlier, before
> sending the Intent to Ship.) So it might be a bit more time before we can
> consider this feature for shipping. Of course, if you get responses and
> engagement before that point, we can proceed earlier.
>
> -Domenic
>
> On Tuesday, May 14, 2024 at 11:06:55 AM UTC+9 Jiaming Cheng wrote:
>
>> Hi team,
>>
>> Those reviews have been posted for 10 days, there's no opposing
>> comments on any of them so far. Could you please take another look at 
>> this
>> intent?
>>
>> Let me know if you have any further questions or concerns.
>>
>> Thanks,
>> Jiaming
>>
>> On Fri, May 3, 2024 at 6:25 PM Jiaming Cheng 
>> wrote:
>>
>>> Hi Alex, Chris and Daniel,
>>>
>>> Thank you for your valuable feedback!
>>>
>>> I've addressed your comments and taken the following updates:
>>>
>>> Hey Alex, the ChapterInformation *does* apply to audio as well as
>>> video, since MediaSession is for both audio and video. I've updated the
>>> Chrome status to reflect this.
>>>
>>> Additionally, I've taken the following actions:
>>>
>>>- Added WPT test:
>>>https://chromium-review.googlesource.com/c/chromium/src/+/5516503
>>>
>>>- Filed TAG review:
>>>https://github.com/w3ctag/design-reviews/issues/952
>>>- Filed WebKit review:
>>>https://github.com/WebKit/standards-positions/issues/344
>>>- Filed Gecko review:
>>>https://github.com/mozilla/standards-positions/issues/1019
>>>
>>>
>>> I will keep you updated on the progress of these reviews and notify
>>> you once they are approved. Let me know if you have any questions :]
>>>
>>> Best,
>>> Jiaming
>>>
>>> On Wed, May 1, 2024 at 8:57 AM Alex Russell <
>>> slightly...@chromium.org> wrote:
>>>
 Hey folks,

 On reviewing this, I'm concerned that this isn't also addressing
 the same needs for Audio. This would have come up in a TAG review, and
 probably would have been fleshed out in an Explainer. Would like to see
 those before this progresses.

 Best,

 Alex

 On Tuesday, April 30, 2024 at 3:35:45 PM UTC-7 dan...@microsoft.com
 wrote:

> I was curious about WPT coverage for this and found
> https://wpt.fyi/results/mediasession/mediametadata.html
>
>
>
> Maybe that could be updated to check for the basics of the new
> attribute?
>
>
>
> -- Dan
>
>
>
> *From:* 'Jiaming Cheng' via blink-dev 
> *Sent:* Tuesday, April 30, 2024 1:50 PM
> *To:* blink-dev@chromium.org
> *Cc:* Alex Newcomer ; Megan Fu <
> megan...@google.com>; Tommy Steimel ; Andrew
> Xu 
> *Subject:* [blink-dev] Intent to Ship: Support Vid

Re: [blink-dev] Re: Intent to Ship: WebGPU: GPUAdapter info attribute

[Yoav Weiss (@Shopify)]

LGTM2

On Fri, May 31, 2024 at 7:35 AM Domenic Denicola 
wrote:

> In that case, LGTM1.
>
> On Fri, May 31, 2024 at 2:31 PM François Beaufort 
> wrote:
>
>>
>>
>> On Fri, May 31, 2024 at 3:16 AM Domenic Denicola 
>> wrote:
>>
>>>
>>>
>>> On Thursday, May 30, 2024 at 1:34:03 PM UTC+9 fbea...@google.com wrote:
>>>
>>> Contact emailsfbeauf...@google.com
>>>
>>> ExplainerNone
>>>
>>> Specificationhttps://gpuweb.github.io/gpuweb/#dom-gpuadapter-info
>>>
>>> Summary
>>>
>>> Functionality added to the WebGPU spec after its first shipment in a
>>> browser. Adds a synchronous GPUAdapter info attribute to retrieve the same
>>> information about the physical adapter as with the asynchronous GPUAdapter
>>> requestAdapterInfo() method. A separate Intent will be sent to deprecate
>>> and remove the asynchronous GPUAdapter requestAdapterInfo() method.
>>>
>>>
>>> Blink componentBlink>WebGPU
>>> 
>>>
>>> TAG reviewNone
>>>
>>> TAG review statusNot applicable
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> The GPUAdapter info attribute has not yet been implemented in any
>>> browser. It has been approved by the GPU for the Web Community Group, with
>>> representatives from Chrome, Firefox, and Safari. See minutes at
>>> https://github.com/gpuweb/gpuweb/wiki/GPU-Web-2024-05-
>>> 22#add-synchronous-gpuadapterinfo-4550
>>>
>>>
>>> *Gecko*: No signal (https://github.com/mozilla/
>>> standards-positions/issues/1033)
>>>
>>>
>>> *WebKit*: Closed Without a Position (https://github.com/WebKit/
>>> standards-positions/issues/294#issuecomment-1877411933)
>>>
>>> *Web developers*: Positive (https://github.com/gpuweb/gpuweb/issues/4536
>>> )
>>>
>>> *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, Android WebView, 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.
>>>
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?Yes
>>>
>>> See https://github.com/gpuweb/cts/pull/3679 WebGPU/WGSL have a
>>> conformance test suite (https://github.com/gpuweb/cts) that is
>>> regularly pulled into Chromium and part of the testing of Dawn/Tint in
>>> Chromium.
>>>
>>>
>>> Flag name on chrome://flagsNone
>>>
>>> Finch feature nameNone
>>>
>>>
>>> Per
>>> https://chromium.googlesource.com/chromium/src/+/main/docs/flag_guarding_guidelines.md#when-is-a-flag-required
>>> , a feature flag is required for any web platform addition.
>>>
>>
>> We'll have a blink runtime feature flag named
>> "WebGPUAdapterInfoAttribute" for this.
>> Thanks for catching Domenic!
>>
>>>
>>>
>>>
>>>
>>> Non-finch justificationNone
>>>
>>> Requires code in //chrome?False
>>>
>>> Tracking bughttps://issues.chromium.org/issues/335383516
>>>
>>> Estimated milestonesShipping on desktop127Shipping on Android127Shipping
>>> on WebView127
>>>
>>> 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 Statushttps://chromestatus.com/
>>> feature/5087914701881344?gate=5141800569536512
>>>
>>> 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/CAM0wra8zntEfiC5SBHcPeOAKV2SOfUM%3DTn9P8Wrq4L3d%3D_pXyQ%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

Re: [blink-dev] Intent to Extend Experiment: Compression Dictionary Transport

[Yoav Weiss (@Shopify)]

On Wed, May 29, 2024 at 4:31 PM Mike Taylor  wrote:

> Hi there,
>
> Would you mind commenting on progress for the following items, per OT
> renewal guidelines:
>


> Draft spec (early draft is ok, but must be spec-like and associated with
> the appropriate standardization venue, or WICG)
>
Recently published

with
above-mentioned changes.
+Patrick Meenan  can probably add precision there, but
it's making good progress in the HTTPWG.

TAG review (see exceptions)
>
https://github.com/w3ctag/design-reviews/issues/877

> bit.ly/blink-signals requests
>
Both Mozilla 
and WebKit  are
positive (with ongoing discussion about some details with Mozilla folks).

> Outreach for feedback from the spec community
>
Regular HTTPWG and WebPerfWG engagement.

> WPT tests
>
https://wpt.fyi/results/fetch/compression-dictionary?label=experimental&label=master&aligned


> thanks,
> Mike
> On 5/28/24 5:59 AM, Tsuyoshi Horo wrote:
>
> Contact emails
>
> h...@chromium.org, pmee...@chromium.org, yoavwe...@chromium.org,
> kenjibah...@chromium.org, denom...@chromium.org
>
>
> Explainer
>
> https://github.com/WICG/compression-dictionary-transport
>
>
> Specification
>
> https://datatracker.ietf.org/doc/draft-ietf-httpbis-compression-dictionary/
>
>
> Design docs
>
>
> https://docs.google.com/document/d/1IcRHLv-e9boECgPA5J4t8NDv9FPHDGgn0C12kfBgANg/edit
>
> https://github.com/WICG/compression-dictionary-transport
>
> https://datatracker.ietf.org/doc/draft-ietf-httpbis-compression-dictionary/
>
>
> Summary
>
> We are running the second round of the Origin Trial until Chrome 125. The
> design of the feature has also evolved during the origin trial and RFC
> process. We’d like to run a third round of the Origin Trial to get more
> feedback on the updated
> 
> design.
>
>
> Blink component
>
> Blink>Network
> 
>
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/877
> TAG review status
>
> Closed
> Risks Interoperability and Compatibility
>
> Interoperability and Compatibility risk are low. This feature introduces a
> new compression method for transporting resources over HTTP. Web sites can
> know the browser support for the new feature by checking
> `document.createElement('link').relList.supports('compression-dictionary')`.
> The feature is a negotiation between servers and clients that involves a
> server specifying that a resource should be used as a dictionary for future
> requests with a ‘Use-As-Dictionary’ response header. Clients that don’t
> support the feature will ignore the header and nothing further will happen.
>
> This feature is an opt-in feature. And the dictionary storage is isolated
> using the top level site and the frame origin as the key. That means, if
> there is no dictionary registered for the site, the behavior of Chrome will
> not change while browsing the site. Also this feature is only usable within
> a secure-context so this feature will not increase the risk of having
> network proxies meddle with the content’s encoding. For enterprises that
> have deployed HTTPS-intercepting proxies that do not properly handle
> unknown encodings there is an enterprise policy exposed to disable the
> feature. The feature is currently enabled only over connections using a
> well-known trust root for the secure connection which eliminates the risk
> of security devices and proxies breaking traffic. The roll-out plan for
> production has steps to remove the trust root restriction and enable
> support in enterprise environments where intercepting proxies are common.
>
>
> Gecko: Positive (https://github.com/mozilla/standards-positions/issues/771
> )
>
>
> WebKit: Positive (https://github.com/WebKit/standards-positions/issues/160
> )
>
>
> Web developers: Positive
>
>
> Other signals:
>
>
> Ergonomics
>
> To reduce memory usage in network services, dictionary metadata is stored
> in a database on disk. And to avoid performance degradation for normal
> requests that do not use a dictionary, the reading of this metadata is
> designed not to block network requests. In other words, if the reading of
> metadata from the database is not completed before the request header is
> ready to be sent to the server, the dictionary may not be used even if it
> is already registered in the database.
>
>
>
> Activation
>
> To adopt this feature, web developers need to make changes in their web
> servers or build processes for static resources. Currently there is no
> major server software which directly supports compression dictionaries.
> Some CDNs have shared interest in supporting shared dictionary comp

Re: [blink-dev] Intent to Ship: Dispatch selectionchange event per element

[Yoav Weiss (@Shopify)]

I'm sorry, but re-reading this, I realized that I don't fully understand
this change and the plan here.
Can you elaborate on:
* What is the behavior change that we want to drive here?
* Which part of that would be covered by the first CL? which by the second?
* Where do we predict compat risk here? How can we estimate it?

Thanks! :)


On Tue, May 28, 2024 at 1:54 AM Shuangshuang Zhou <
shuangshuang.z...@intel.com> wrote:

> Hi Yoav, thanks for the question! From chromium's side, currently I don't
> have any usecounters to trace how many sites would be impacted. I checked
> WebKit' status, seems they don't have any data. Maybe Olli could comment
> this from Gecko's side.
>
> Since the first CL doesn't change the original logic, we might collect
> some data in the second CL(avoid to dispatch events that are already
> scheduled but not executed).
>
> Thanks!
>
> On Monday, May 27, 2024 at 3:08:29 PM UTC+8 yoav...@chromium.org wrote:
>
>> Given Olli's comments on this change being backwards-incompatible, do we
>> have any data on how many sites would be impacted? Any usecounters to that
>> effect?
>>
>> On Mon, May 27, 2024 at 2:19 AM Shuangshuang Zhou 
>> wrote:
>>
>>> Thanks Olli for the implement in Gecko side, and also Dan's comment!
>>>
>>> Hi Mike, would you please take a look and give some suggestion? Also,
>>> seems we need 3 LGTMs, Kent or Mike, would you add another reviewer to to
>>> take a review?
>>>
>>> Thanks!
>>> On Saturday, May 25, 2024 at 1:05:59 AM UTC+8 Olli Pettay wrote:
>>>
 I am trying to land the change, so it should be in FF 128 Nightly soon,
 next week at latest. So hopefully we'll get feedback if it breaks 
 something.
 I don't think there is need for a standards-position for this
 particular small tweak.
 (But the process of making this kind of breaking spec change was rather
 unusual.)


 -Olli

 On Friday, May 24, 2024 at 7:55:44 PM UTC+3 Daniel Clark wrote:

> Thanks Shuangshuang for clarifying what’s going on with these two
> separate but related changes, and Olli for the update on
> https://bugzilla.mozilla.org/show_bug.cgi?id=1898343.
>
>
>
> Since Gecko already implements the behavior of firing selectionchange
> on input/textarea (confirmed here
> ), sounds good to me to go
> ahead with shipping this change in Chromium (I’m not an API owner though).
>
>
>
> Separately, for the behavior of not firing duplicate selectionchange,
> it might not hurt to go ahead and request an official Mozilla position on
> that since it sounds like there’s still a bit of uncertainty about landing
> that change given back compat concerns, unless Olli confirms here that the
> plan is to go ahead and ship it.
>
>
>
> -- Dan
>
>
>
> *From:* Olli Pettay 
> *Sent:* Friday, May 24, 2024 12:26 AM
> *To:* blink-dev 
> *Cc:* Shuangshuang Zhou ; tk...@chromium.org <
> tk...@chromium.org>; mike...@chromium.org ;
> Daniel Clark ; Olli Pettay 
> *Subject:* Re: [blink-dev] Intent to Ship: Dispatch selectionchange
> event per element
>
>
>
> You don't often get email from ope...@mozilla.com. Learn why this is
> important 
>
> FWIW, I'm implementing the change in
> https://bugzilla.mozilla.org/show_bug.cgi?id=1898343
>
> Need to still fix some tests, which do reveal how the spec change
> indeed isn't fully backwards compatible.
>
> Hopefully it doesn't break any real web sites.
>
>
>
>
>
>
>
> -Olli
>
>
>
>
>
> On Friday, May 24, 2024 at 10:05:47 AM UTC+3 Shuangshuang Zhou wrote:
>
> Hi Dan&Mike, I think we could submit a standard-position issue to
> Mozilla for reducing duplicated events in our second CL(mentioned in my
> last comment) for this feature. Because in the second CL, we might change
> the current logic of dispatching selectionchange event. For this time, we
> might just do it in chromium. WDYT?
>
>
>
> Thanks!
>
> On Friday, May 24, 2024 at 9:20:33 AM UTC+8 tk...@chromium.org wrote:
>
> LGTM1.
>
> Firefox and Safari statuses are strong signals, and the
> compatibility risk looks very low.
>
>
>
>
>
> On Thu, May 23, 2024 at 11:07 AM Shuangshuang Zhou <
> shuangsh...@intel.com> wrote:
>
> Hi Dan&Mike, for your concern that Firefox is still failing the WPTs
> at
> https://wpt.fyi/results/selection/onselectionchange-on-distinct-text-controls.html,
> that might be another issue. Let me make more explanation.
>
>
>
> Actually, the final goal of w3c modifys the spec of selectionchange
> event is to avoid firing duplicated selectionchange event which are not
> executed yet on the same element(as Rn

Re: [blink-dev] RE: Intent to Ship: Protected Audience: reporting timeouts & multiple-bids

[Yoav Weiss (@Shopify)]

LGTM2

On Thursday, May 23, 2024 at 1:01:53 AM UTC+2 Chris Harrelson wrote:

LGTM1

On Tue, May 21, 2024 at 3:07 PM 'Erik Anderson' via blink-dev <
blink-dev@chromium.org> wrote:

Hi,

 

Thanks for reaching out.

 

We’ve reviewed the proposal and don’t have any significant concerns. We’ll 
continue providing feedback via GitHub where appropriate.

 

Thanks,

Erik

 

*From:* Paul Jensen  
*Sent:* Friday, May 17, 2024 5:42 AM
*To:* Yoav Weiss (@Shopify) 
*Cc:* blink-dev ; Erik Anderson <
erik.ander...@microsoft.com>
*Subject:* Re: Intent to Ship: Protected Audience: reporting timeouts & 
multiple-bids

 

Actually CC Erik this time.

 

On Fri, May 17, 2024 at 8:40 AM Paul Jensen  wrote:

 

 

On Wed, May 15, 2024 at 8:36 AM Yoav Weiss (@Shopify) <
yoavwe...@chromium.org> wrote:

 

On Monday, May 6, 2024 at 10:03:16 PM UTC+2 Paul Jensen wrote:

Contact emails

pauljen...@chromium.org

 

Explainer

Protected Audience reporting timeouts: https://github.com/WICG/
turtledove/pull/1101

Protected Audience multiple-bids: https://github.com/WICG/
turtledove/pull/1048

Please fix the explainer 
<https://github.com/WICG/turtledove/pull/1048/files#r1615583702> to remove 
the "in Chrome" part from the feature detection reference. 

 

Specification

Protected Audience reporting timeouts: https://github.com/WICG/
turtledove/pull/1102

Protected Audience multiple-bids: https://github.com/WICG/
turtledove/pull/1138

 

Summary

Protected Audience (PA) reporting timeouts:

After a PA auction finishes selecting an ad and that ad is allowed to start 
rendering, the browser then runs a JavaScript function from the seller(s) 
and winning buyer to assemble reports that are sent back to their servers. 
These functions are currently given 50ms to run, after which they're 
aborted. We've heard feedback from users of the API that 50ms may not be 
sufficient to assemble the reports and may result in broken billing and 
other basic functionality, resulting in lower website revenue.  We’re 
proposing making the timeout configurable up to 5s. (This JavaScript 
generally runs in a separate process, i.e. off the main thread.)

 

I'm concerned about this timeout, tbh.

It feels very arbitrary and if set by the wrong party, it can create some 
adversarial effects.

Can you expand on why do we need a configurable timeout here, rather than 
just increasing it for everyone?

I think configurability is useful here for a few reasons:

   1. There are potentially three different variables that may determine 
   the optimal setting of this timeout:


   1. 
  1. Different devices may have different execution performance, so a 
  fixed timeout across all devices may be suboptimal.
   

   1. 
  2. Different publisher pages may have different execution 
  requirements.  Some may be sensitive to how much execution time is 
allowed 
  for these reporting scripts, so a fixed timeout across all publisher 
pages 
  may be suboptimal.
   

   1. 
  3. Different auction participants may have different execution 
  requirements.  Some may be sensitive to how much execution time is given 
  for them to complete execution of their reporting scripts.
   

   2. Making it configurable allows callers of the API to experiment and 
   tune to find the optimal timeout for particular situations.
   3. Changing the default timeout could potentially upset ongoing 
   experimentation.

 

If a configurable timeout is indeed needed, am I correct that the timeout 
would be set by the publisher, and its consequences would be felt by the 
seller?

It’s set by whoever is initiating the auction.  This could be anyone on the 
publisher page, including the publisher or a seller acting on their behalf. 

 

Also, can you expand on "This JavaScript generally runs in a separate 
process"? Where is it run?

On desktop, we use one process to run all bidding and scoring scripts for 
one origin, and that gets used for this reporting step also.  On Android, 
where system resources are more constrained, we use site-isolation’s 
heuristics to pick an appropriate process for each origin’s scripts. 

 

 

Protected Audience multiple-bids:

Presently buyers participating in PA ad selection auctions are only allowed 
to return one bid per interest group stored on a user's device. This has a 
couple downsides:

   1. When that one bid does not pass the k-anonymity threshold, the bid 
   generation logic must be invoked again which can be slow, potentially 
   doubling auction runtime.
   2. This preferences adtechs that store more interest groups on device as 
   a way to get more bids into the auction. Many interest groups on device is 
   something we publicly have stated is undesirable: 
   https://developers.google.com/privacy-sandbox/relevance/
   protected-audience-api/latency#fewer_interest_group_owners 
   
<https://developers.google.com/privacy-sandbox/r

Re: [blink-dev] Intent to Ship: The ServiceWorker static routing API not condition support

[Yoav Weiss (@Shopify)]

LGTM1

On Wednesday, May 29, 2024 at 2:39:02 AM UTC+2 Yoshisato Yanagisawa wrote:



2024年5月28日(火) 0:21 Vladimir Levin :



On Fri, May 24, 2024 at 3:43 AM Yoshisato Yanagisawa <
yyanagis...@chromium.org> wrote:

Contact emails

yyanagis...@chromium.org

Explainer

https://github.com/WICG/service-worker-static-routing-api

Specification

https://w3c.github.io/ServiceWorker/#dom-routercondition-not

Design docs

https://docs.google.com/document/d/1B2D8w_2M4j9CZC1VccBOAhfCdiRP3yPCSV5U
KKDhU70/edit#heading=h.ns1mpsv4yi7x

Summary

The ServiceWorker static routing API is an API used for routing the request 
to the network, the ServiceWorker fetch handler, or directly looking up 
from cache, and so on.  Each route consists of a condition and a source, 
and the condition is used for matching the request.

For Chromium implementations, the "or" condition is only the supported 
condition.  However, to write the condition more flexibly, supporting the 
"not" condition is expected, which matches the inverted condition inside.


Blink component

Blink>ServiceWorker 


TAG review

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

TAG review status

Issues addressed

Risks

Interoperability and Compatibility

No compatibility concerns.

This change just starts supporting the not condition.  Since existing 
routes won't have the not condition, adding the not condition support won't 
affect any existing router rules.



Gecko: Positive (https://github.com/mozilla/standards-positions/pull/894)

WebKit: Positive (https://github.com/WebKit/standards-positions/issues/206)

Web developers: No signals

Other signals:

Ergonomics

The "not" condition calculates the conditions below and inverts the result, 
such calculation may also take a time.  Also, the element does not run 
concurrently.  However, the inversion is very quick, and rules should be 
sequentially evaluated, it should not be a large performance risk.


Activation

n/a


Security

This just adds the "not" condition.  I believe the security risk is low.


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


Debuggability

n/a The debuggability should not be changed by adding the not condition.  
Note that the "not" condition also shows up in chrome://serviceworker-internals 
and devtools.


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

Yes

This is a part of the ServiceWorker static routing API.  There is no reason 
not enabling the feature in specific platforms.


Is this feature fully tested by web-platform-tests 

?

Yes

https://wpt.fyi/results/service-workers/service-worker/tentative/static-
router/static-router-main-resource.https.html?label=
experimental&label=master&aligned

* Main resource load should not match the condition with not

* Main resource load should match the condition without not

https://wpt.fyi/results/service-workers/service-worker/tentative/static-
router/static-router-subresource.https.html?label=experimental&label=master&
aligned

* Subresource load should not match with the not condition

* Subresource load should match with a file other than not


Two of the tests listed here are failing on wpt.fyi. Is that known?
 


Yes, it is intended.  Since I2S has not gotten lgtm yet, the not condition 
support is disabled via flag.
If you enable the flag, these tests pass.


For next time, a runtime enabled flag 

 
would have made it easier for developers to test this, and would have 
gotten the WPTs to pass, even if the flag is still "experimental" and not 
enabled by default.
 

 


Flag name on chrome://flags

None

Finch feature name

ServiceWorkerStaticRouterNotConditionEnabled

Requires code in //chrome?

False

Tracking bug

https://crbug.com/328565554

Availability expectation

The feature should be implemented if the ServiceWorker static routing API 
has been implemented by the other browsers.

Estimated milestones

Shipping on desktop

126

Shipping on Android

126


126 is already branched. Could you update the milestones for shipping?
 


sure.
 





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 This only adds the "not" condition. No backward compatibility issue 
should exist.

Link to entry on the Chrome Platform Status

https:/

Re: [blink-dev] Intent to Ship: Deprecation of non-standard declarative shadow DOM serialization

[Yoav Weiss (@Shopify)]

LGTM2

On Tue, May 28, 2024 at 11:10 PM Vladimir Levin  wrote:

>
>
> On Tue, May 28, 2024 at 12:30 PM Mason Freed  wrote:
>
>>
>>
>> On Mon, May 27, 2024 at 8:15 AM Vladimir Levin 
>> wrote:
>>
>>> Interoperability and Compatibility

 The use counter for getInnerHTML() (
 https://chromestatus.com/metrics/feature/timeline/popularity/3874)
 peaked at 0.05% of page loads using this function as of January 2024, and
 dropped precipitously toward 0.01% in May, 2024. This is presumably due to
 the shipment of its replacement, getHTML().

>>>
>>> It's great to see the numbers reduce significantly. If the numbers are
>>> being migrated to getHTML() though I would have expected
>>> https://chromestatus.com/metrics/feature/timeline/popularity/4781 to
>>> grow by ~0.04 percentage points, but that one is still significantly lower
>>> (although growing). Is it possible that June 1 numbers would show a better
>>> balance? Do you by any chance know when the next data point is expected to
>>> be visible on chromestatus?
>>>
>>> I'm also assume people are using a readily available replacement as
>>> opposed to just not using getInnerHTML, but it would be nice if number
>>> supported that
>>>
>>
>> Great questions. So AFAIK the use counter plot for the current month is a
>> continuous aggregation. I.e. the 0.0168% I see today (May 28) is as of the
>> 28th, and will change tomorrow (slightly). Given that we're almost to the
>> end of the month, I wouldn't expect a ton of shift. So I think you might be
>> right that this isn't actually a shift to getHTML, but just a shift away
>> from getInnerHTML. See more below.
>>
>> Your questions prompted me to take a closer look at the sample sites
>> still hitting the use counter. I took a close look at the first 10 entries
>> listed, and I think I found perhaps where the big drop came from. Of those
>> ten sites, seven do not use getInnerHTML or getHTML at all. Likely not
>> coincidentally, all seven are Shopify sites. My guess would be that Shopify
>> very recently removed its usage of getInnerHTML?
>>
>
FWIW, internal code search brought up nothing. It's possible that this is a
3P app

that changed their use. (or that I'm simply failing to find the relevant
change :D)


>> The real issue is that the remaining three sites *do* still use
>> getInnerHTML, and all three throw exceptions when the feature is disabled.
>> I can't perceive anything broken on the site, but the exception isn't a
>> good sign. A few interesting tidbits: one of the three does appear to
>> (properly) feature-detect getInnerHTML() yet an exception is still thrown
>> that might or might not be related. The other two do not feature detect,
>> and the exception is clear: "getInnerHTML is not a function". Very
>> interestingly, none of the three use getInnerHMTL for anything declarative
>> shadow dom related. They seem to just be using it as a way to get the
>> innerHTML value. All three seem to be hand-written JS, so it's possible the
>> sites were developed on Chrome in the last few years and the developer
>> didn't notice that they should have done foo=el.innerHTML instead of
>> foo=el.getInnerHTML().
>>
>> Given that the use counter is very low (0.01%), I'd still like to push
>> ahead with this deprecation. The above sites likely represent interop
>> problems, since they'll break on other browsers already today. But I'd like
>> to revise my plan: instead of going immediately to 100% removal, I'd like
>> to use a slow ramp down over time, to monitor for reported breakage.
>>
>> Thoughts?
>>
>
> The plan to ramp down usage is a good one, although as we previously
> discussed in a different thread, it may cause some debugging challenges for
> developers. It is worthwhile to also reach out to some of the developers
> whose sites you noticed would throw an exception -- just an FYI email that
> this feature is being removed. Given the fairly low usage, readily
> available fixes (via getHTML() or possibly innerHTML) and your commitment
> to monitor for breakages, this looks good to me.
>
> LGTM1
>
>
>>
>> Thanks,
>> Mason
>>
>>
>>
>>>
>>> While 0.01% still represents high usage for deprecation, the numbers
 were significantly worse for the deprecation of the old `shadowroot`
 attribute, and the removal of that feature generated zero bug reports. It
 is my strong belief that since this feature is only shipped in Chrome, the
 vast majority of usage is guarded by feature checks. So this deprecation
 should be safer than it would seem from the numbers. I'd like to remove
 this feature in M127 in code, with a killswitch (a re-enable switch really)
 in case of problems.


 *Gecko*: No signal

 *WebKit*: No signal

 *Web developers*: No signals

 *Other signals*:

 WebView application risks

 Does this intent deprecate or change behavior of existing A

Re: [blink-dev] Intent to Deprecate and Remove: Deprecate old CSS custom state syntax

[Yoav Weiss (@Shopify)]

LGTM2

Please make sure that use of the old syntax triggers some kind of
developer-facing warning, so that it won't be too hard to catch the cause
for the behavior change in the few sites that will be affected.

On Tue, May 28, 2024 at 10:33 PM Joey Arhar  wrote:

> > How should I interpret the results from your investigation? That none of
> the 8 investigated sites would be negatively affected?
>
> There is only one site which is actually affected: https://resolv.com.br/
> The buttons in the carousel there won't light up anymore, but they will
> still work. I made sure of that based on the shape of the JS portion of the
> new syntax. You can test this out in firefox nightly or safari TP.
>
> On Wed, May 22, 2024 at 9:22 AM Daniel Bratell  wrote:
>
>> To be particular about the usage number, it's about a magnitude more than
>> our informal limit. That doesn't mean it can't be shipped, but it means
>> that we want to be fairly certain that >90% of the users are unaffected by
>> the change.
>>
>> How should I interpret the results from your investigation? That none of
>> the 8 investigated sites would be negatively affected?
>>
>> /Daniel
>>
>> On 2024-05-22 18:03, Vladimir Levin wrote:
>>
>>
>>
>> On Tue, May 21, 2024 at 2:20 PM Joey Arhar  wrote:
>>
>>> > Do you know what the breakage looks like
>>>
>>> I pushed to make sure that using the old syntax with
>>> CustomStateSet.add() wouldn't throw exceptions when in the new mode in
>>> order to reduce breakage. When websites use the old syntax after it's
>>> removed, they will just have styling differences because their selectors
>>> won't parse anymore.
>>>
>>> > or whether this usage is limited to a library/a small set of large
>>> websites or something else?
>>>
>>> Based on the analysis that I linked in the previous thread
>>> ,
>>> there are some websites which all look very similar which use it, but they
>>> are all hidden behind display:none elements that I had to manually reveal.
>>> There was only one website I found which was actually using it which has a
>>> carousel which has buttons that didn't work in safari and firefox because
>>> CustomStateSet didn't exist yet.
>>>
>>> I don't think there is a popular library which is using the deprecated
>>> syntax.
>>>
>>> > Ideally, this is feature detected with some fallback syntax
>>>
>>> Websites just have to replace ":--foo" with ":state(foo)", I don't think
>>> any feature detection is necessary. If they are interested in supporting
>>> older browsers, then I don't see why they would have any interest in
>>> looking at whether the deprecated syntax works or not because the other
>>> browsers didn't have it before and neither did we until a couple years ago.
>>>
>>
>> I meant I hope that existing use is either feature-detected or it's using
>> both properties. In either case, it's very easy to fix if problems arise
>> since alternate syntax is shipped already in multiple browsers.
>>
>> LGTM1
>>
>>
>>> On Tue, May 21, 2024 at 11:09 AM Vladimir Levin 
>>> wrote:
>>>
 Hey,

 0.04% seems like a fairly sizable number. Do you know what the breakage
 looks like or whether this usage is limited to a library/a small set of
 large websites or something else?

 Ideally, this is feature detected with some fallback syntax


 On Tue, May 21, 2024 at 1:39 PM Joey Arhar  wrote:

> Contact emails jar...@chromium.org
>
> Explainer None
>
> Specification https://github.com/whatwg/html/pull/8467
>
> Summary
>
> The CSS custom state pseudo-class is being renamed from :--foo to
> :state(foo). The new syntax, :state(foo), has been enabled by default, and
> now we have to deprecate and remove the :--foo syntax. Gecko and webkit
> never implemented the old syntax and they have both shipped the new 
> syntax.
> We are currently shipping both the new syntax and the old syntax at the
> same time. There have been console errors and DevTools deprecations for 
> the
> old syntax for many milestones already. Previous thread on this topic:
> https://groups.google.com/a/chromium.org/g/blink-dev/c/JvpHoUfhJYE/m/uRtWiqoHAQAJ
> The UseCounter is currently at 0.04%
> https://chromestatus.com/metrics/feature/timeline/popularity/3796
>
>
> Blink component Blink>HTML>CustomElements
> 
>
> Motivation
>
> The syntax of this feature needs to change in order to get support
> from the other browsers and eventually have interoperable behavior.
>
>
> Initial public proposal None
>
> TAG review None
>
> TAG review status Not applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> Websites which are currently using the old syntax and don't migrate to
>>>

Re: [blink-dev] Intent to Ship: Third-party Cookie Grace Period Opt-Out

[Yoav Weiss (@Shopify)]

LGTM2

On Fri, May 24, 2024 at 5:53 PM Anton Maliev  wrote:

> I see the concern. The 3P can use document.hasStorageAccess()
>  
> to
> check for cookie support, which accounts for the grace period and opt-out.
> (It would return true if there is an active grace period on the 1P or 3P
> that affects the current frame, or false if the current client is opted
> out.) Per the linked I2S, we recommend document.hasStorageAccess() instead
> of navigator.cookieEnabled moving forward for validation relating to
> Chrome's 3PCD rollout - the latter doesn't return the correct value for
> this case.


Thanks! That makes sense.


>
> This also depends if the 3P in question is also on the grace period. If it
> is not, we would expect them to notice any breakage on other 1Ps as well.
>
> On Thursday, May 23, 2024 at 4:17:14 PM UTC-4 Yoav Weiss wrote:
>
>> On Thu, May 16, 2024 at 4:15 PM Anton Maliev 
>> wrote:
>>
>>> > Will developers have a way of knowing if the current site (where they
>>> may see breakage metrics) is opted-out of the grace period?
>>>
>>> Google is planning to build a site dashboard where developers can check
>>> on the status of their grace period and opt-out values. In the interim,
>>> Chrome DevTools shows an Issue for third-party cookies which are allowed
>>> due to the grace period - this can be used to validate whether the grace
>>> period is active for that particular client.
>>>
>>>
>> While that's potentially useful, that's not what I had in mind.
>> If a site opt-outs of the grace period, that may impact 3Ps that the site
>> embeds.
>> Those 3Ps (if they are not ready for it) are likely to notice some drop
>> in their functionality or conversion, but they'd need a way of attributing
>> that to the lack of 3P cookies.
>>
>> At the same time, while writing this, I was reminded of
>> navigator.cookieEnabled
>> .
>> Do I understand correctly that it would indicate the lack of 3P cookie
>> support in these cases?
>>
>>
>>
>>> > Do you have a rough estimate on the length of the grace period? (I'm
>>> guessing this will not be relevant after it)
>>>
>>> That's correct, a site will no longer need an opt-out file after it is
>>> removed from the grace period. Each grace period entry has its own
>>> expiration date, depending on when the site applied for the deprecation
>>> trial. We will need to assess the demand for new sites onboarding to the
>>> trial before we can give an estimate on how long we will continue to
>>> support grace periods overall.
>>>
>>> On Thursday, May 16, 2024 at 3:56:15 AM UTC-4 Yoav Weiss wrote:
>>>
 This is an odd one, but I agree that it's a web exposed feature and
 hence should go through the blink process. Thanks for sending this!


 On Tue, May 14, 2024 at 11:15 PM Anton Maliev 
 wrote:

> Contact emails
>
> amal...@chromium.org
>
> njeu...@chromium.org
>
> wanderv...@chromium.org
>
> Explainer
>
> https://github.com/explainers-by-googlers/3pcd-grace-period-opt-out
>
> Specification
>
> Well-known resource specification:
> https://github.com/explainers-by-googlers/3pcd-grace-period-opt-out/blob/main/well-known-specification.md
>
> Summary
>
> This proposal details a new mechanism for site developers to conduct a
> self-service staged opt-out of their third-party cookie phaseout grace
> period. This is intended primarily for Chrome’s active trials for
> third-party cookie deprecation - one for top-level sites
> 
> and one for embedded sites
> .
> When a site is approved for one of these trials, they are added to a
> short-term grace period which mitigates breakage until the token is
> launched.  Sites may also use this opt-out to test long term solutions.
>
> Each site on the trial will specify their desired opt-out percentage
> in a new resource in their .well-known directory
> , specified here
> .
> Google will implement server infrastructure to fetch and update these
> values on a schedule, and assign clients randomly to cohorts matching this
> percentage. These cohorts persist for a client up until clearing site
> storage or reinstalling the browser.
>


 Will developers have a way of knowing if the current site (where they
 may see breakage metrics) is opted-out of the grace period?



>
> Blink

Re: [blink-dev] Intent to Ship: Dispatch selectionchange event per element

[Yoav Weiss (@Shopify)]

Given Olli's comments on this change being backwards-incompatible, do we
have any data on how many sites would be impacted? Any usecounters to that
effect?

On Mon, May 27, 2024 at 2:19 AM Shuangshuang Zhou <
shuangshuang.z...@intel.com> wrote:

> Thanks Olli for the implement in Gecko side, and also Dan's comment!
>
> Hi Mike, would you please take a look and give some suggestion? Also,
> seems we need 3 LGTMs, Kent or Mike, would you add another reviewer to to
> take a review?
>
> Thanks!
> On Saturday, May 25, 2024 at 1:05:59 AM UTC+8 Olli Pettay wrote:
>
>> I am trying to land the change, so it should be in FF 128 Nightly soon,
>> next week at latest. So hopefully we'll get feedback if it breaks something.
>> I don't think there is need for a standards-position for this particular
>> small tweak.
>> (But the process of making this kind of breaking spec change was rather
>> unusual.)
>>
>>
>> -Olli
>>
>> On Friday, May 24, 2024 at 7:55:44 PM UTC+3 Daniel Clark wrote:
>>
>>> Thanks Shuangshuang for clarifying what’s going on with these two
>>> separate but related changes, and Olli for the update on
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1898343.
>>>
>>>
>>>
>>> Since Gecko already implements the behavior of firing selectionchange on
>>> input/textarea (confirmed here ),
>>> sounds good to me to go ahead with shipping this change in Chromium (I’m
>>> not an API owner though).
>>>
>>>
>>>
>>> Separately, for the behavior of not firing duplicate selectionchange, it
>>> might not hurt to go ahead and request an official Mozilla position on that
>>> since it sounds like there’s still a bit of uncertainty about landing that
>>> change given back compat concerns, unless Olli confirms here that the plan
>>> is to go ahead and ship it.
>>>
>>>
>>>
>>> -- Dan
>>>
>>>
>>>
>>> *From:* Olli Pettay 
>>> *Sent:* Friday, May 24, 2024 12:26 AM
>>> *To:* blink-dev 
>>> *Cc:* Shuangshuang Zhou ; tk...@chromium.org <
>>> tk...@chromium.org>; mike...@chromium.org ;
>>> Daniel Clark ; Olli Pettay 
>>> *Subject:* Re: [blink-dev] Intent to Ship: Dispatch selectionchange
>>> event per element
>>>
>>>
>>>
>>> You don't often get email from ope...@mozilla.com. Learn why this is
>>> important 
>>>
>>> FWIW, I'm implementing the change in
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1898343
>>>
>>> Need to still fix some tests, which do reveal how the spec change indeed
>>> isn't fully backwards compatible.
>>>
>>> Hopefully it doesn't break any real web sites.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> -Olli
>>>
>>>
>>>
>>>
>>>
>>> On Friday, May 24, 2024 at 10:05:47 AM UTC+3 Shuangshuang Zhou wrote:
>>>
>>> Hi Dan&Mike, I think we could submit a standard-position issue to
>>> Mozilla for reducing duplicated events in our second CL(mentioned in my
>>> last comment) for this feature. Because in the second CL, we might change
>>> the current logic of dispatching selectionchange event. For this time, we
>>> might just do it in chromium. WDYT?
>>>
>>>
>>>
>>> Thanks!
>>>
>>> On Friday, May 24, 2024 at 9:20:33 AM UTC+8 tk...@chromium.org wrote:
>>>
>>> LGTM1.
>>>
>>> Firefox and Safari statuses are strong signals, and the
>>> compatibility risk looks very low.
>>>
>>>
>>>
>>>
>>>
>>> On Thu, May 23, 2024 at 11:07 AM Shuangshuang Zhou <
>>> shuangsh...@intel.com> wrote:
>>>
>>> Hi Dan&Mike, for your concern that Firefox is still failing the WPTs at
>>> https://wpt.fyi/results/selection/onselectionchange-on-distinct-text-controls.html,
>>> that might be another issue. Let me make more explanation.
>>>
>>>
>>>
>>> Actually, the final goal of w3c modifys the spec of selectionchange
>>> event is to avoid firing duplicated selectionchange event which are not
>>> executed yet on the same element(as Rniwa commented in his comment
>>> ).
>>> Then in WebKit/WebCore, Rniwa submitted 2 CLs to achieve this ieda. The
>>> first CL in WebKit is 276238@main
>>> , and in this CL they just
>>> modified the logic to fire selectionchange event on input/textarea for the
>>> first step. Then the second CL in WebKit is 276388@main
>>> , which finally avoided to fire
>>> duplicated selectionchange events according to the latest spec on firing
>>> selectionchange event
>>> .
>>>
>>>
>>>
>>> So for this feature in Blink here , we also want to take 2 steps like
>>> WebKit does that in the first CL we change to fire on input/textarea and
>>> then sovle the duplicated events in the second CL. And those tests are
>>> already modified to what both CLs are merged. So in the above test of
>>> onselectionchange-on-distinct-text-controls.html, chrome and firefox should
>>> be failed because only Safari has landed 2 CLs to avoid duplicated
>>> selectionchange events. Or 

[blink-dev] Re: Intent to Ship: Importmap integrity

[Yoav Weiss (@Shopify)]

On Fri, May 24, 2024 at 7:12 PM Panos Astithas  wrote:

>
>
> On Wed, May 22, 2024 at 2:16 AM Yoav Weiss (@Shopify) <
> yoavwe...@chromium.org> wrote:
>
>>
>>
>> On Wed, May 22, 2024 at 10:29 AM Yoav Weiss (@Shopify) <
>> yoavwe...@chromium.org> wrote:
>>
>>>
>>>
>>> On Tuesday, May 21, 2024 at 1:04:44 PM UTC+2 Yoav Weiss wrote:
>>>
>>> Contact emailsyoavwe...@chromium.org
>>>
>>> Explainerhttps://github.com/guybedford/import-maps-extensions#integrity
>>>
>>> Specificationhttps://github.com/whatwg/html/pull/10269
>>>
>>> The PR is ready to land, but we're holding off on that for 2 weeks at
>>> Mozilla's request. See below.
>>>
>>> Summary
>>>
>>> Imported ES modules can't currently have their integrity checked, and
>>> hence cannot run in environments that require Subresource Integrity or with
>>> `require-sri-for` CSP directives. This feature adds an `integrity` section
>>> to import maps, enabling developers to map ES module URLs to their
>>> integrity metadata, and ensure they only load when they match their
>>> expected hashes.
>>>
>>>
>>> Blink componentBlink>Loader
>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ELoader>
>>>
>>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/944
>>>
>>> TAG review statusIssues addressed
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> On the interoperability front, this got a positive position from WebKit,
>>> and I'm implementing the feature there
>>> <https://github.com/whatwg/html/pull/10269>. Mozilla didn't object to
>>> the feature, but asked
>>> <https://docs.google.com/document/d/1iaarr4Ho715CUULrvi_LD3TwshAcN2odDLBBEK0FjH0/edit#bookmark=id.li7pdpi5uloq>
>>>
>>>
>> I just realized that the meeting notes are not publicly viewable.
>> +Panos Astithas  - would you be able to open them
>> up to the public somehow? (e.g. as a Chromium.org doc)
>>
>
> They were published
> <https://github.com/whatwg/html/issues/10340#:~:text=Benjamin%3A%20I%27d%20like%20a%20further%20two%20weeks>
>  that
> same day, we try to post the minutes publicly in less than 24 hours.
>

Oops!! My bad for using the wrong artifact!


>
>>
>>
>>> for a couple more weeks to evaluate it and provide a position, as they
>>> might be planning broader-scope work on the front of application integrity,
>>> and want to make sure this doesn't collide with it.
>>>
>>>
>>> On the compatibility front, the feature is polyfilled
>>> <https://github.com/guybedford/es-module-shims/pull/424>, but it's turned
>>> off for browsers that support import maps
>>> <https://github.com/guybedford/es-module-shims#:~:text=The%20ES%20Module%20Shims%20polyfill%20will%20analyze%20the%20browser%20to%20see%20if%20it%20supports%20import%20maps.%20If%20it%20does%2C%20it%20doesn%27t%20do%20anything%20more>
>>> .
>>>
>>>
>>> Adding Guy Bedford, the polyfill author to this thread. Guy, can you
>>> confirm this is the case?
>>>
>>> *Gecko*: No signal
>>> <https://github.com/mozilla/standards-positions/issues/1010>
>>>
>>> *WebKit*: Support
>>> <https://github.com/WebKit/standards-positions/issues/335>
>>>
>>>
>>> WebKit PR <https://github.com/WebKit/WebKit/pull/28253> has landed.
>>>
>>>
>>>
>>>
>>> *Web developers*: Positive
>>> <https://x.com/yoavweiss/status/1778067431417954803>
>>> This is based on a proposal from a developer (Guy Bedford).
>>> Multiple Shopify properties are interested in this, to enable using ES
>>> modules as bundler output in security sensitive environments. Asking about
>>> this on twitter and mastodon showed that some developers are interested in
>>> this, while others discount SRI in general.
>>>
>>> *Other signals*:
>>>
>>> Activation
>>>
>>> As long as support is not ubiquitous, the `integrity` part of import
>>> maps will be ignored in non-supporting browsers, resulting in scripts
>>> loading in those browsers even if they're supposed to fail their integrity
>>> checks.
>>>
>>> There's also a polyfill
>>> <https://github.com/guybedford/es-module-shims

Re: [blink-dev] Re: Intent to Ship: Importmap integrity

[Yoav Weiss (@Shopify)]

On Fri, May 24, 2024 at 5:57 PM Alex Russell 
wrote:

> I'm also not sure why we would wait.
>

Waiting a few more days won't change much, so it's perfectly fine.


> That said, if we're expanding SRI, it would be great to see media
> resources included. Won't block this intent on it, but for architectural
> consistency want to flag that we aren't "done".
>

I agree in principle, but media resources are more complex, as they can be
"executed" progressively.
SRI in its current form would mean they are inherently slower, and
expanding SRI to enable something like Merkle-Tree
<https://en.wikipedia.org/wiki/Merkle_tree#:~:text=In%20cryptography%20and%20computer%20science,labels%20of%20its%20child%20nodes.>-based
hashes seems like a significant expansion.
At the same time, maybe Mozilla's plans around application integrity would
cover that use case.


> On Wed, May 22, 2024, 6:39 PM Mike Taylor  wrote:
>
>> I'm inclined to LGTM this now - but don't see a lot of harm waiting for 1
>> additional week (per Mozilla's request in the not-public minutes). Happy to
>> do so before, so long as the HTML PR lands.
>> On 5/22/24 5:15 AM, Yoav Weiss (@Shopify) wrote:
>>
>>
>>
>> On Wed, May 22, 2024 at 10:29 AM Yoav Weiss (@Shopify) <
>> yoavwe...@chromium.org> wrote:
>>
>>>
>>>
>>> On Tuesday, May 21, 2024 at 1:04:44 PM UTC+2 Yoav Weiss wrote:
>>>
>>> Contact emailsyoavwe...@chromium.org
>>>
>>> Explainerhttps://github.com/guybedford/import-maps-extensions#integrity
>>>
>>> Specificationhttps://github.com/whatwg/html/pull/10269
>>>
>>> The PR is ready to land, but we're holding off on that for 2 weeks at
>>> Mozilla's request. See below.
>>>
>>> Summary
>>>
>>> Imported ES modules can't currently have their integrity checked, and
>>> hence cannot run in environments that require Subresource Integrity or with
>>> `require-sri-for` CSP directives. This feature adds an `integrity` section
>>> to import maps, enabling developers to map ES module URLs to their
>>> integrity metadata, and ensure they only load when they match their
>>> expected hashes.
>>>
>>>
>>> Blink componentBlink>Loader
>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ELoader>
>>>
>>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/944
>>>
>>> TAG review statusIssues addressed
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> On the interoperability front, this got a positive position from WebKit,
>>> and I'm implementing the feature there
>>> <https://github.com/whatwg/html/pull/10269>. Mozilla didn't object to
>>> the feature, but asked
>>> <https://docs.google.com/document/d/1iaarr4Ho715CUULrvi_LD3TwshAcN2odDLBBEK0FjH0/edit#bookmark=id.li7pdpi5uloq>
>>>
>>>
>> I just realized that the meeting notes are not publicly viewable.
>> +Panos Astithas  - would you be able to open them
>> up to the public somehow? (e.g. as a Chromium.org doc)
>>
>>
>>> for a couple more weeks to evaluate it and provide a position, as they
>>> might be planning broader-scope work on the front of application integrity,
>>> and want to make sure this doesn't collide with it.
>>>
>>>
>>> On the compatibility front, the feature is polyfilled
>>> <https://github.com/guybedford/es-module-shims/pull/424>, but it's turned
>>> off for browsers that support import maps
>>> <https://github.com/guybedford/es-module-shims#:~:text=The%20ES%20Module%20Shims%20polyfill%20will%20analyze%20the%20browser%20to%20see%20if%20it%20supports%20import%20maps.%20If%20it%20does%2C%20it%20doesn%27t%20do%20anything%20more>
>>> .
>>>
>>>
>>> Adding Guy Bedford, the polyfill author to this thread. Guy, can you
>>> confirm this is the case?
>>>
>>> *Gecko*: No signal
>>> <https://github.com/mozilla/standards-positions/issues/1010>
>>>
>>> *WebKit*: Support
>>> <https://github.com/WebKit/standards-positions/issues/335>
>>>
>>>
>>> WebKit PR <https://github.com/WebKit/WebKit/pull/28253> has landed.
>>>
>>>
>>>
>>>
>>> *Web developers*: Positive
>>> <https://x.com/yoavweiss/status/1778067431417954803>
>>> This is based on a proposal from 

Re: [blink-dev] Intent to Ship: Third-party Cookie Grace Period Opt-Out

[Yoav Weiss (@Shopify)]

On Thu, May 16, 2024 at 4:15 PM Anton Maliev  wrote:

> > Will developers have a way of knowing if the current site (where they
> may see breakage metrics) is opted-out of the grace period?
>
> Google is planning to build a site dashboard where developers can check on
> the status of their grace period and opt-out values. In the interim, Chrome
> DevTools shows an Issue for third-party cookies which are allowed due to
> the grace period - this can be used to validate whether the grace period is
> active for that particular client.
>
>
While that's potentially useful, that's not what I had in mind.
If a site opt-outs of the grace period, that may impact 3Ps that the site
embeds.
Those 3Ps (if they are not ready for it) are likely to notice some drop in
their functionality or conversion, but they'd need a way of attributing
that to the lack of 3P cookies.

At the same time, while writing this, I was reminded of
navigator.cookieEnabled
.
Do I understand correctly that it would indicate the lack of 3P cookie
support in these cases?



> > Do you have a rough estimate on the length of the grace period? (I'm
> guessing this will not be relevant after it)
>
> That's correct, a site will no longer need an opt-out file after it is
> removed from the grace period. Each grace period entry has its own
> expiration date, depending on when the site applied for the deprecation
> trial. We will need to assess the demand for new sites onboarding to the
> trial before we can give an estimate on how long we will continue to
> support grace periods overall.
>
> On Thursday, May 16, 2024 at 3:56:15 AM UTC-4 Yoav Weiss wrote:
>
>> This is an odd one, but I agree that it's a web exposed feature and hence
>> should go through the blink process. Thanks for sending this!
>>
>>
>> On Tue, May 14, 2024 at 11:15 PM Anton Maliev 
>> wrote:
>>
>>> Contact emails
>>>
>>> amal...@chromium.org
>>>
>>> njeu...@chromium.org
>>>
>>> wanderv...@chromium.org
>>>
>>> Explainer
>>>
>>> https://github.com/explainers-by-googlers/3pcd-grace-period-opt-out
>>>
>>> Specification
>>>
>>> Well-known resource specification:
>>> https://github.com/explainers-by-googlers/3pcd-grace-period-opt-out/blob/main/well-known-specification.md
>>>
>>> Summary
>>>
>>> This proposal details a new mechanism for site developers to conduct a
>>> self-service staged opt-out of their third-party cookie phaseout grace
>>> period. This is intended primarily for Chrome’s active trials for
>>> third-party cookie deprecation - one for top-level sites
>>> 
>>> and one for embedded sites
>>> .
>>> When a site is approved for one of these trials, they are added to a
>>> short-term grace period which mitigates breakage until the token is
>>> launched.  Sites may also use this opt-out to test long term solutions.
>>>
>>> Each site on the trial will specify their desired opt-out percentage in
>>> a new resource in their .well-known directory
>>> , specified here
>>> .
>>> Google will implement server infrastructure to fetch and update these
>>> values on a schedule, and assign clients randomly to cohorts matching this
>>> percentage. These cohorts persist for a client up until clearing site
>>> storage or reinstalling the browser.
>>>
>>
>>
>> Will developers have a way of knowing if the current site (where they may
>> see breakage metrics) is opted-out of the grace period?
>>
>>
>>
>>>
>>> Blink component
>>>
>>> Privacy 
>>>
>>> TAG review
>>>
>>> N/A
>>>
>>> TAG review status
>>>
>>> N/A
>>>
>>> Risks
>>>
>>> There aren’t inherent security implications for fetching external
>>> resources using server-side infrastructure, but there is a risk of fetching
>>> bad data, which our implementation addresses.
>>>
>>> There are also privacy implications for randomly assigning clients to
>>> cohorts, which we mitigate by clearing cohorts on site data deletion. There
>>> is also a risk that the fetching system fails or that a site loses access
>>> to its .well-known resource, both cases which we have planned mitigations
>>> for.
>>>
>>> Interoperability and Compatibility
>>>
>>> The third-party cookie deprecation trials are a Chrome feature, so these
>>> new well-known resources will only be fetched by the Chrome browser. The
>>> new resource will be distinct and will not interfere with any existing
>>> resources used by other browsers or features.
>>>
>>
>> Beyond that, I think that the fact that this is a short-lived capability
>> also significantly reduces risk.

Re: [blink-dev] Intent to Ship: PointerEvent.deviceId for Mult-Pen Inking

[Yoav Weiss (@Shopify)]

OK, thanks for outlining the spec mechanics :)

Regardless of whether the PR actually lands in the spec, for the purpose of
risk-assessment, it's even more interesting to know if the PR is *ready* to
land in the spec.
Can y'all clarify its review status? If it's ready to land, can a spec
editor approve it, even if it doesn't land until later?

On Fri, May 17, 2024 at 10:18 AM Patrick H. Lauke 
wrote:

>
>
> On 16/05/2024 21:05, Robert Flack wrote:
> > I believe the reason for waiting is that the intention is to switch to a
> > different publishing model after level 3 is published? @Patrick H. Lauke
> >  to confirm.
>
> Apologies for the convoluted model here ... I have to admit that I'm
> actually not sure what the expected way of working around this is, as
> Pointer Events has been such a "slow and steady" process so far, with a
> very linear way of working - it's only now that we're just hoping to get
> PE3 to REC and then had this extra functionality come in that we've hit
> this snag. I will check with Philippe at W3C to work out what the best
> way forward here is (have the "frozen" version that makes its way
> through the steps to REC, while being able to already have a
> "future/next" branch).
>
> P
> --
> Patrick H. Lauke
>
> * https://www.splintered.co.uk/
> * https://github.com/patrickhlauke
> * https://flickr.com/photos/redux/
> * https://mastodon.social/@patrick_h_lauke
>
>

-- 
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/CAOmohS%2B13j_wjzqsqoOEdnsnWmd9uAoWHr9HVyFUYSeUhr-0sA%40mail.gmail.com.