[blink-dev] Re: Intent to Ship: CSS Scrollbars: scrollbar-color, scrollbar-width

[Luke]

Yes, it will work on all Scrollbars on all platforms including overlay on
macOS. :)

On Sat, 21 Oct 2023, 03:56 Šime Vidas,  wrote:

> Will scrollbar-color work on overlay scrollbars on macOS? It does in
> Firefox.
>
> On Friday, October 20, 2023 at 10:46:36 PM UTC+2 Luke wrote:
>
>> Apologies my email client seems to have messed with the text colour. Lets
>> try that again.
>>
>> *Contact emails *lukewa...@gmail.com
>>
>> Explainerhttps://github.com/felipeerias/css-scrollbars-explainer
>>
>> Specificationhttps://www.w3.org/TR/css-scrollbars-1
>>
>> Summary
>>
>> The CSS Scrollbars spec allows authors to style scrollbars by specifying
>> their colors and thickness. This spec adds the following two properties.
>> The scrollbar-color property provides the capability of changing the color
>> scheme of scrollbars so they fit better into the particular style of a web
>> page. The scrollbar-width property allows the use of narrower scrollbars
>> that may be more suitable for some use cases, or even to hide the
>> scrollbars completely without affecting scrollability.
>>
>>
>> Blink componentBlink>Layout>Scrollbars
>> 
>>
>> Search tagscss , scrollbars
>> , scrollbar-color
>> , scrollbar-width
>> 
>>
>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/563
>>
>> TAG review statusIssues addressed
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> These are already supported inside of Firefox so shouldn't present much
>> of a risk. It's possible that if Safari doesn't support them this could
>> lead to some level of fragmentation between the legacy pseudo styles and
>> the standard properties.
>>
>>
>> *Gecko*: Shipped/Shipping (
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1460109) Firefox fully
>> supports both properties.
>>
>> *WebKit*: Positive (
>> https://github.com/WebKit/standards-positions/issues/133) A supportive
>> position has been given for both scrollbar-width and scrollbar-color. See
>> also https://github.com/WebKit/standards-positions/issues/134
>>
>> *Web developers*: Positive (https://insights.developer.mozilla.org)
>> "Inability to style browser scrollbars" included in the list of Top Pain
>> Point Categories of the MDN Browser Compatibility Report.
>>
>> *Other signals*:
>>
>> Ergonomics
>>
>> The value of scrollbar-width influences other properties such as
>> scrollbar-gutter which take the scrollbar's thickness as reference. There
>> might be conflicts between these properties and Chromium's own
>> ::-webkit-scrollbar pseudo-elements that serve a similar purpose. This is
>> partially addressed by these standard properties taking precedence inside
>> of Chromium and WebKit.
>>
>>
>> Activation
>>
>> These properties are easy for developers to take advantage of many will
>> already be using them for Firefox support.
>>
>>
>> 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?
>>
>> This should have no impact on WebView applications. It will simply allow
>> customising the colours of scrollbars if they apply the necessary styles.
>>
>>
>> Debuggability
>>
>> Both properties will show up in dev tools with auto complete support.
>> Scrollbar color will also have the color swatch show up for both values.
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)?Yes
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?No
>>
>> The existing Web Platform Tests are not exhaustive. Internal tests are
>> implemented where necessary. Results:
>> https://wpt.fyi/results/css/css-scrollbars
>>
>>
>> Flag name on chrome://flags#enable-experimental-web-platform-features
>>
>> Finch feature nameScrollbarColor and ScrollbarWidth
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=891944
>>
>> Availability expectationExpect scrollbar-width to be available across
>> all browsers within a year. scrollbar-color requires platform changes for
>> WebKit on Apple platforms so may take longer to be available.
>>
>> Adoption expectationI expect these standard properties be the default
>> way developers choose to style both colouring and sizing of scrollbars,
>> replacing the legacy webkit pseudo styles for most developers.
>>
>> Sample links
>> https://developer.mozilla.org/en-US/docs/Web/CSS/scrollbar-color
>> https://developer.mozilla.org/en-US/docs/Web/CSS/scrollbar-width
>>
>> Estimated milestones
>> Shipping on desktop
>> 121
>> DevTrial on desktop

[blink-dev] Re: Intent to Ship: CSS Scrollbars: scrollbar-color, scrollbar-width

[Luke]

Apologies my email client seems to have messed with the text colour. Lets 
try that again.

*Contact emails *lukewarlow...@gmail.com

Explainerhttps://github.com/felipeerias/css-scrollbars-explainer

Specificationhttps://www.w3.org/TR/css-scrollbars-1

Summary

The CSS Scrollbars spec allows authors to style scrollbars by specifying 
their colors and thickness. This spec adds the following two properties. 
The scrollbar-color property provides the capability of changing the color 
scheme of scrollbars so they fit better into the particular style of a web 
page. The scrollbar-width property allows the use of narrower scrollbars 
that may be more suitable for some use cases, or even to hide the 
scrollbars completely without affecting scrollability.


Blink componentBlink>Layout>Scrollbars 


Search tagscss , scrollbars 
, scrollbar-color 
, scrollbar-width 


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

TAG review statusIssues addressed

Risks


Interoperability and Compatibility

These are already supported inside of Firefox so shouldn't present much of 
a risk. It's possible that if Safari doesn't support them this could lead 
to some level of fragmentation between the legacy pseudo styles and the 
standard properties.


*Gecko*: Shipped/Shipping (
https://bugzilla.mozilla.org/show_bug.cgi?id=1460109) Firefox fully 
supports both properties.

*WebKit*: Positive (https://github.com/WebKit/standards-positions/issues/133) 
A supportive position has been given for both scrollbar-width and 
scrollbar-color. See also 
https://github.com/WebKit/standards-positions/issues/134

*Web developers*: Positive (https://insights.developer.mozilla.org) 
"Inability to style browser scrollbars" included in the list of Top Pain 
Point Categories of the MDN Browser Compatibility Report.

*Other signals*:

Ergonomics

The value of scrollbar-width influences other properties such as 
scrollbar-gutter which take the scrollbar's thickness as reference. There 
might be conflicts between these properties and Chromium's own 
::-webkit-scrollbar pseudo-elements that serve a similar purpose. This is 
partially addressed by these standard properties taking precedence inside 
of Chromium and WebKit.


Activation

These properties are easy for developers to take advantage of many will 
already be using them for Firefox support.


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?

This should have no impact on WebView applications. It will simply allow 
customising the colours of scrollbars if they apply the necessary styles.


Debuggability

Both properties will show up in dev tools with auto complete support. 
Scrollbar color will also have the color swatch show up for both values.


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

Is this feature fully tested by web-platform-tests 

?No

The existing Web Platform Tests are not exhaustive. Internal tests are 
implemented where necessary. Results: 
https://wpt.fyi/results/css/css-scrollbars


Flag name on chrome://flags#enable-experimental-web-platform-features

Finch feature nameScrollbarColor and ScrollbarWidth

Requires code in //chrome?False

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

Availability expectationExpect scrollbar-width to be available across all 
browsers within a year. scrollbar-color requires platform changes for 
WebKit on Apple platforms so may take longer to be available.

Adoption expectationI expect these standard properties be the default way 
developers choose to style both colouring and sizing of scrollbars, 
replacing the legacy webkit pseudo styles for most developers.

Sample links
https://developer.mozilla.org/en-US/docs/Web/CSS/scrollbar-color
https://developer.mozilla.org/en-US/docs/Web/CSS/scrollbar-width

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

Anticipated spec changes

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

Link to entry on the Chrome Platform Status

[blink-dev] Intent to Ship: CSS Scrollbars: scrollbar-color, scrollbar-width

[Luke]

Contact emails
 lukewarlow...@gmail.com 

Explainer
https://github.com/felipeerias/css-scrollbars-explainer

Specification
https://www.w3.org/TR/css-scrollbars-1

Summary
The CSS Scrollbars spec allows authors to style scrollbars by specifying their 
colors and thickness. This spec adds the following two properties.

The scrollbar-color property provides the capability of changing the color 
scheme of scrollbars so they fit better into the particular style of a web page.

The scrollbar-width property allows the use of narrower scrollbars that may be 
more suitable for some use cases, or even to hide the scrollbars completely 
without affecting scrollability.


Blink component
Blink>Layout>Scrollbars 


Search tags
css , scrollbars 
, scrollbar-color 
, scrollbar-width 


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

TAG review status
Issues addressed

Risks


Interoperability and Compatibility
These are already supported inside of Firefox so shouldn't present much of a 
risk. It's possible that if Safari doesn't support them this could lead to some 
level of fragmentation between the legacy pseudo styles and the standard 
properties.


Gecko: Shipped/Shipping (https://bugzilla.mozilla.org/show_bug.cgi?id=1460109) 
Firefox fully supports both properties.

WebKit: Positive (https://github.com/WebKit/standards-positions/issues/133) A 
supportive position has been given for both scrollbar-width and 
scrollbar-color. See also 
https://github.com/WebKit/standards-positions/issues/134

Web developers: Positive (https://insights.developer.mozilla.org 
) "Inability to style browser 
scrollbars" included in the list of Top Pain Point Categories of the MDN 
Browser Compatibility Report.

Other signals:

Ergonomics
The value of scrollbar-width influences other properties such as 
scrollbar-gutter which take the scrollbar's thickness as reference.

There might be conflicts between these properties and Chromium's own 
::-webkit-scrollbar pseudo-elements that serve a similar purpose. This is 
partially addressed by these standard properties taking precedence inside of 
Chromium and WebKit.


Activation
These properties are easy for developers to take advantage of many will already 
be using them for Firefox support.


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?
This should have no impact on WebView applications. It will simply allow 
customising the colours of scrollbars if they apply the necessary styles.


Debuggability
Both properties will show up in dev tools with auto complete support. Scrollbar 
color will also have the color swatch show up for both values.


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

Is this feature fully tested by web-platform-tests 
?
No
The existing Web Platform Tests are not exhaustive. Internal tests are 
implemented where necessary.

Results:
https://wpt.fyi/results/css/css-scrollbars


Flag name on chrome://flags
#enable-experimental-web-platform-features

Finch feature name
ScrollbarColor and ScrollbarWidth

Requires code in //chrome?
False

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

Availability expectation
Expect scrollbar-width to be available across all browsers within a year. 
scrollbar-color requires platform changes for WebKit on Apple platforms so may 
take longer to be available.

Adoption expectation
I expect these standard properties be the default way developers choose to 
style both colouring and sizing of scrollbars, replacing the legacy webkit 
pseudo styles for most developers.

Sample links

https://developer.mozilla.org/en-US/docs/Web/CSS/scrollbar-color
https://developer.mozilla.org/en-US/docs/Web/CSS/scrollbar-width

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


Anticipated spec changes
Open questions about a feature may be a source of future web compat or interop 
issues. Please list open issues (e.g. links to known github issues in the 
project for the feature specification) whose resolution may introduce web 
compat/interop risk (e.g., changing to naming or structure of the API in a 
non-backward-compatible way).
No anticipated spec changes, this is already shipping in Firefox for a long 
time.

Link to entry on the Chrome Platform Status

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

['Liam Brady' via blink-dev]

Contact emails

shivani...@chromium.org jkar...@chromium.org lbr...@google.com 
Explainer(s)

Send Automatic Beacons To All Registered Destinations

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

Spec(s)

Send Automatic Beacons To All Registered Destinations

(Initial version) https://github.com/WICG/fenced-frame/pull/122

(Post-security review updates) https://github.com/WICG/fenced-frame/pull/129

 
Summary

One of the capabilities of fenced frames and URN iframes loaded through 
Protected Audience or Shared Storage is being able to send reporting 
beacons automatically 

 
after a top-level navigation. We would like to modify that functionality:

Automatic beacons will now send to URLs registered via registerAdBeacon() 
on reserved.top_navigation calls, but they will not have beacon data 
attached to the request. Previously, only URLs registered via 
setReportEventDataForAutomaticBeacons received beacons, and they do have 
beacon data attached.

Note: This chromestatus entry also includes changes to Protected Audience 
ad size macros. However, it is small enough that it will be taken care of 
in a separate PSA: 
https://groups.google.com/a/chromium.org/g/blink-dev/c/3JfA8EUBEgQ

Blink component

Blink>FencedFrames 


TAG reviews and status

Fenced frames existing TAG review appended with these spec changes 
https://github.com/w3ctag/design-reviews/issues/838#issuecomment-1765061770

Link to Origin Trial feedback summary

No Origin Trial performed

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

Supported on all the above platforms except Android WebView.

Debuggability

Additional debugging capabilities are not necessary for these feature 
changes.

Risks

Compatibility

There are no compatibility risks, as described below:

The API shape as exposed to ad frames is not changing. While the 
assumptions of which sites receive the beacon after calling 
setReportEventDataForAutomaticBeacons() is changing, no code changes will 
be required to have existing code work with this new behavior.

Interoperability

There are no interoperability risks as no other browsers have decided to 
implement these features yet.

Is this feature fully tested by web-platform-tests 
?
 
Link to test suite results from wpt.fyi.

Yes

automatic-beacon-no-destination.https.html (test 
)
 
(results 

)

automatic-beacon-no-opt-in.https.html (test 
)
 
(results 

)

Anticipated spec changes

None 

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5140606359175168

Links to previous Intent discussions

Intent to prototype: 
https://groups.google.com/a/chromium.org/g/blink-dev/c/Ko9UXQYPgUE/m/URRsB-qvAAAJ
 

Intent to experiment:

https://groups.google.com/a/chromium.org/g/blink-dev/c/y6G3cvKXjlg/m/Lcpmpi_LAgAJ
 

Intent to extend origin trial:

https://groups.google.com/a/chromium.org/g/blink-dev/c/SD8Ot2gpz4g/m/A9uA-_cGAwAJ
 

https://groups.google.com/a/chromium.org/g/blink-dev/c/gpmaOi3of_w/m/SyMclFhMAAAJ
 

https://groups.google.com/a/chromium.org/g/blink-dev/c/CBrV-2DrYFI/m/RTojC6kHAgAJ
 

Intent to ship:

https://groups.google.com/a/chromium.org/g/blink-dev/c/tpw8wW0VenQ/m/mePLTiHlDQAJ

Intent to ship for functionality updates:

https://groups.google.com/a/chromium.org/g/blink-dev/c/2FKlwNZ0J4Q/m/oQmHtp1rAQAJ

-- 
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/f317f4d1-c4b7-4a19-8f13-cf6cbbde100dn%40chromium.org.

Re: [blink-dev] Re: Intent to Experiment: IP Protection Phase 0

[Mike Taylor]

Sure, the plan is to file one before any future I2S. But this isn't a 
blocking concern for this first experiment, imho.


On 10/20/23 2:22 AM, Yoav Weiss wrote:
I think it makes sense to file a TAG review as FYI in the future 
(non-blocking for this experiment) just to let the TAG know that this 
is happening, as it changes things significantly when it comes to 
fingerprinting data (by making other avenues of fingerprinting data 
more valuable than they currently are).


I wouldn't expect them to provide feedback on the IETF drafts this 
relies on though.



On Fri, Oct 20, 2023 at 7:34 AM 'Harald Alvestrand' via blink-dev 
 wrote:


standard naming rant  can we call this "IP Address Protection"?
My initial read of the title was "Intellectual Property
Protection", and I opened it with a sense of dread expecting to
find DRM-related stuff and a long argument.

There are IETF efforts related to automatic relays (MASQUE, OHAI),
but I think they are intended for a lower level of the protocol stack.
Relays in HTTP are also well defined in IETF (for some value of
"well"). I can't remember having seen this particular usage
discussed there (but I don't follow HTTP that closely).

On Fri, Oct 20, 2023 at 6:29 AM Alex Russell
 wrote:

This is going to change observable network behavior, right?
The TAG liases with IETF, and if there aren't already active
conversations in IETF about this change, I worry that it will
be received poorly.

On Thu, Oct 19, 2023, 7:15 PM Mike Taylor
 wrote:

I'm recused from voting on this feature so with my API
OWNER hat off (or maybe just back and to the side to make
me look cool...), it's possible that we submit an FYI
review in the future ahead of an I2S.

That said, this is a feature that arguably does not
materially alter web platform APIs, but instead masks the
client's IP using IETF defined CONNECT, CONNECT-UDP, and
MASQUE, etc. But if TAG would like to provide input on our
design choices, that could be useful. But it shouldn't
block an experiment.

On 10/19/23 3:22 PM, Alex Russell wrote:

Why has the TAG not been consulted?

On Thu, Oct 19, 2023, 3:09 PM 'Brianna Goldstein' via
blink-dev  wrote:

*Correction*:
The link to the entry on the Chrome Platform Status
was incorrect. Below is the corrected link

https://chromestatus.com/feature/5111460239245312



On Thu, Oct 19, 2023 at 4:52 PM Brianna Goldstein
 wrote:


Contact emails

Brianna Goldstein
, James Bradley
, David Schinazi



Explainer

IP Protection formerly known as Gnatcatcher



Specification

None


Summary

IP Protection
is
a feature that sends third-party traffic for a
set of domains through proxies for the purpose of
protecting the user by masking their IP address
from those domains.


After receiving much feedback from the ecosystem,
the design of the broader proposal is as follows:

 *

IP Protection will be opt-in initially. This
will help ensure that there is user control
over privacy decisions and that Google can
monitor behaviors at lower volumes.

 *

It will roll out in a phased manner. Like all
of our privacy proposals, we want to ensure
that we learn as we go and we recognize that
there may also be regional considerations to
evaluate.

 *

We are using a list based approach and only
domains on the list in a third-party context
will be impacted. We are conscious that these
proposals may cause undesired disruptions for
legitimate use cases and so we are just
focused on the scripts and domains that are
considered to be tracking users.



Should we expect all 3Ps 

Re: [blink-dev] Intent to Ship: Fire toggle events using microtasks

[Joey Arhar]

> Can you bump this thread when you'd like to ship it?

Sure thing. It looks like more discussion about the behavior has started in
the whatwg issue, so I'll wait for everything to be fully settled.
This feature is not a high priority for me at the moment.

On Wed, Oct 18, 2023 at 9:01 AM Philip Jägenstedt 
wrote:

> Hi again Joey,
>
> Can you bump this thread when you'd like to ship it?
>
> Best regards,
> Philip
>
> On Fri, Oct 6, 2023 at 7:38 PM Joey Arhar  wrote:
>
>> > On the level of interest, there was no reaction on
>> https://github.com/whatwg/html/issues/9046 after you asked. Is there
>> other communication that makes you relatively sure the interest is there?
>>
>> I should have filed standards positions first. I have done so now:
>> - https://github.com/WebKit/standards-positions/issues/263
>> - https://github.com/mozilla/standards-positions/issues/901
>>
>> > It sounds like the idea is to prove this web compatible by shipping it,
>> before updating the spec
>>
>> I intend to get positive signals from Gecko and WebKit first before
>> actually shipping this.
>> I already have an HTML spec PR open, so the spec could be updated at any
>> time.
>>
>> There is a risk for web compatibility, although I was convinced that this
>> should just improve the consistency of the event timing.
>> If there is significant breakage, I will disable this change via finch
>> and revert the spec changes.
>>
>> On Fri, Oct 6, 2023 at 4:12 AM Philip Jägenstedt 
>> wrote:
>>
>>> It sounds like the idea is to prove this web compatible by shipping it,
>>> before updating the spec. On the level of interest, there was no reaction
>>> on https://github.com/whatwg/html/issues/9046 after you asked. Is there
>>> other communication that makes you relatively sure the interest is there?
>>>
>>> On Fri, Oct 6, 2023 at 3:34 AM Joey Arhar  wrote:
>>>
 Contact emailsjar...@chromium.org

 Explainerhttps://github.com/whatwg/html/issues/9046

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

 Summary

 The toggle events for the popover attribute and the details element, as
 well as the close event for dialog elements, currently post a task to the
 DOM manipulation task source to fire these events asynchronously. This
 means that the event could fire before or after the next render, which
 could lead to flaky rendering for one frame. By using microtasks instead,
 the event will always fire before the next render. This was suggested in
 this HTML spec issue: https://github.com/whatwg/html/issues/9046


 Blink componentBlink>DOM
 

 TAG reviewThis is a very small change so I'm not making a TAG review.

 TAG review statusNot applicable

 Risks


 Interoperability and Compatibility

 If websites are relying on the slower event timing somehow, then we
 could run into problems.


 *Gecko*: Positive?
 https://github.com/whatwg/html/issues/9046#issuecomment-1724509340

 *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, Chrome OS, Android, and Android WebView)?Yes

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

 Flag name on chrome://flagsNone

 Finch feature nameNone

 Non-finch justification

 I am not interested in any metrics changes for this feature, it should
 just make the behavior more consistent for web developers. Should it prove
 to have issues, I can disable it with a finch killswitch.


 Requires code in //chrome?False

 Adoption expectationIf we ship this without breaking websites, then I
 think the other browsers will feel interested in implementing this as well.

 Adoption planThis change modifies several WPTs which the other
 browsers are likely watching, which will help encourage them to implement
 this as well.

 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 

[blink-dev] Intent to Ship: WebCodecs support for enabling AV1 screen content coding tools

['Philipp Hancke' via blink-dev]

Contact emails


*phan...@microsoft.com , bernard.ab...@microsoft.com
*Explainer


*None*Specification


*https://www.w3.org/TR/webcodecs-av1-codec-registration/#dom-av1encoderconfig-forcescreencontenttools
*Design
docs


*https://github.com/fippo/webrtc-explainers/blob/gh-pages/av1-screencontent/index.md
*
Summary




*Adds AV1EncoderConfig (a dictionary containing forceScreenContentTools) to
the VideoEncoderConfig along these lines: encoder.configure({ codec:
'av01.0.04M.08', av1: { forceScreenContentTools: true}, width: 1920,
height: 1080, bitrate: 2_000_000, framerate: 5, }); This allows an
application to encode “screen content”, in particular presentation slides,
in a more efficient way supported by the AV1 codec.This material is
typically static, often includes text, a limited set of colors, lots of
repetitive content (e.g. straight lines, shapes) for which the encoder can
optimize.See the explainer for a lot of visual examples. This AV1 feature
is already supported by WebRTC and enabled for screen sharing
MediaStreamTracks so this increases platform consistency.*Blink component


*Blink>Media>WebCodecs
*TAG
review


*None*TAG review status


*Not applicable*Risks

Interoperability and Compatibility






*NoneGecko: Neutral similar to this situation
https://github.com/mozilla/standards-positions/issues/837#issuecomment-1614666364
WebKit:
No signal (https://github.com/WebKit/standards-positions/issues/239
)Web developers:
No signals Presented in the screen capture community group during TPAC
2023, slides here:
https://docs.google.com/presentation/d/10i4HFYZ4CylpFUuoJcigfiI5uS7pK3uaseQpcYhugAY/edit#slide=id.g27ea3fad398_0_0
Other
signals:*WebView application risks


*Does this intent deprecate or change behavior of existing APIs, such that
it has potentially high risk for Android WebView-based applications?None*
Debuggability


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


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

?



*NoUnclear to what degree this is testable. Enabling this feature reduces
the encoded frame size which makes it tough to test, it might be possible
with a canvas source that provides predictable input similar to
https://webrtc.github.io/samples/src/content/insertable-streams/video-processing/
*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/p/chromium/issues/detail?id=1464862
*Estimated
milestones


*Shipping on desktop121*Anticipated spec changes



*None*Link to entry on the Chrome Platform Status


*https://chromestatus.com/feature/6307770441138176
*Links to previous
Intent discussionsn/a

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

[blink-dev] Re: [EXTERNAL] Re: Intent to Ship: Async Clipboard API: Read unsanitized HTML and write well-formed HTML format.

['Anupam Snigdha' via blink-dev]

We decided to split the proposal into two separate changes as read involves a 
change in the web API, but write doesn't.
So, we're going to ship the unsanitized read first, before we ship the changes 
in behavior for the write method. I'll edit the Chrome status entry to reflect 
this change. Thanks!


From: Sumeet Sharma 
Sent: Wednesday, October 18, 2023 8:06 AM
To: blink-dev 
Cc: Evan Stade ; blin...@chromium.org 
; Sanket Joshi (EDGE) ; 
jsb...@google.com ; Ana Sollano Kim 
; Anupam Snigdha 
Subject: [EXTERNAL] Re: Intent to Ship: Async Clipboard API: Read unsanitized 
HTML and write well-formed HTML format.

You don't often get email from sharmasum...@google.com. Learn why this is 
important
I think there is also a copy-side change in that writing to the clipboard 
should never sanitize text/html going forward.
On Wednesday, October 18, 2023 at 10:52:14 AM UTC-4 Evan Stade wrote:
Hi Anupam,

I think this feature is now scoped just to the read side of the equation, is 
that correct? Could you update the Chrome status 
entry 
text to remove references to writing to avoid confusion?

-- Evan Stade


On Fri, Oct 6, 2023 at 10:31 AM Anupam Snigdha  wrote:
The I2S thread was incorrectly merged into another I2S that I sent for a 
completely different feature. I'm creating a new thread and merging replies. 
Sorry for the inconvenience.

As the author of the web custom formats 
article,
 just for me to better understand: the problem is that the clipboard gets 
populated with `text/html` by random (web or native) apps. If the clipboard 
were populated from the start with `web text/html`, the contents could be read 
unsanitized, even without this new parameter. So this new parameter is the 
escape hatch that developers can use via 
`navigator.clipboard.read({unsanitized: ["text/html"]})`.
So, the problem is that, for sites like Excel Online, they aren't sure where 
the user is going to paste, so they always have to produce both 'web text/html' 
and 'text/html'. That way if an app doesn't have support for web custom format, 
then they can use the native HTML format. Same thing for native apps that 
produce a web custom format.
There are also legacy native apps (old Office versions that are used by 
Enterprises) that don't have support for the new web custom format, so the site 
has to produce the standard HTML format for those apps as well.
But you are right that if both source and target apps support web custom 
format, then it can be used to access unsanitized HTML content.

An immediate question that I ask myself is whether this mechanism could be 
expanded to other values than just `"text/html"`.
Currently we are focusing on the standard HTML format to better align with the 
DataTransfer APIs. In theory you could add support for other built-in formats 
as well, but the main intent here is to produce similar fidelity of HTML format 
so sites that use DataTransfer APIs to read HTML do not experience any 
regression when they move over to async clipboard API for copy-paste operations.

Here is a document where I described the regressions and impact on the apps 
when sanitization is performed: 
https://docs.google.com/document/d/1nLny6t3w0u9yxEzusgFJSj-D6DZmDIAzkr1DdgWcZXA/edit?usp=sharing

Some native apps that I surveyed for impact of this new proposal: 
https://docs.google.com/document/d/1O2vtCS23nB_6aJy7_xcdaWKw7TtqYm0fERzEjtLyv5M/edit?usp=sharing

FWIW, this demo was initially a bit misleading, since I expected "some text" to 
be on the clipboard, or whatever I put into the `contenteditable` box, but it's 
hardcoded. Maybe remove the box.
Oops, sorry about that. Copy-paste error  I fixed it now.

Please let me know if you have any questions!

Thanks,
Anupam

From: Thomas Steiner 
Sent: Friday, October 6, 2023 2:54 AM
To: Anupam Snigdha 
Cc: blin...@chromium.org ; Sanket Joshi (EDGE) 
; Evan Stade ; jsb...@google.com 
; Ana Sollano Kim 
Subject: [EXTERNAL] Re: [blink-dev] Re: Intent to Ship: Async Clipboard API: 
Read unsanitized HTML and write well-formed HTML format.

Adoption expectation
Excel online is ready to use this API. They are trying to move away from 
DataTransfer APIs and use Async clipboard APIs where web custom format is 
supported along with other benefits from async usage.

Adoption plan
Support for async clipboard API and web custom format is already in inner 
rings, so once this gets added to the clipboard API, Excel would be ready to 
use it right away.

As the author of the web custom formats 
article,
 just for me to better understand: the problem is that the clipboard gets 
populated with `text/html` by random (web or native) apps. If the 

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

[Alex Turner]

Contact emails

ale...@chromium.org

Explainer
https://github.com/patcg-individual-drafts/private-aggregation-api#aggregation-coordinator-choice
Specification
https://github.com/patcg-individual-drafts/private-aggregation-api/pull/106
Summary

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

Blink component

Blink>PrivateAggregation


TAG review

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

TAG review status

Pending

Risks

Interoperability and Compatibility

This feature is optional and backwards compatible.

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

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

Web developers: No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that
it has potentially high risk for Android WebView-based applications?

None


Debuggability

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


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

All but Webview


Is this feature fully tested by web-platform-tests

?

WPTs will be added when the feature is enabled.

Flag name on chrome://flags

None

Finch feature name

PrivateAggregationApiMultipleCloudProviders

Requires code in //chrome?

False

Tracking bug

https://crbug.com/1481761

Launch bug

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

Estimated milestones

We intend to ship in M120.

Anticipated spec changes

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5140711678935040

Links to previous Intent discussions

Original I2S
,
Follow-up enhancements I2S



This intent message was generated by Chrome Platform Status
.

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

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

['Yifan Luo' via blink-dev]

Contact emailscl...@chromium.org, mk...@chromium.org, v...@chromium.org,
l...@chromium.org

Explainer
https://github.com/WICG/private-network-access/blob/master/explainer.md

Specificationhttps://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 componentBlink>SecurityFeature>CORS>PrivateNetworkAccess


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

TAG review statusIssues addressed

Chromium Trial NamePrivateNetworkAccessNonSecureContextsAllowed

Link to origin trial feedback summary
https://docs.google.com/spreadsheets/d/1z5ZdCslNCnSVR7TNlUTHjSvunMFmT_9G9NOx8-O78-I/edit?usp=sharing=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 visits 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


*Gecko*: Positive (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/#localhost), which is a
release valve for folks who don't want to go through the effort of
securely-distributing certs for local servers. The initial launch in M92
was delayed due to compatibility risks surfaced during the rollout to beta.
See this doc for a lot more details:
https://docs.google.com/document/d/1bpis0QwaA9ZrRFmpPW6LiaPmdwT0UhhUMNsEnU0zfLk/edit


Security

This change should be security-positive.


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?



Goals for experimentation



Reason this experiment is being extended

We intend to extend the deprecation trial until new permission prompt
shipped, which is going to be on a origin trial from M120 to M123:
https://groups.google.com/a/chromium.org/g/blink-dev/c/sL15TKGmXqM/m/rD0SF8sQBwAJ


Ongoing technical constraints

None.


Debuggability

When a request is made that violates this restriction and the feature is
not enabled, three things happen: 1. A warning message is logged to the
DevTools console. 2. A depreciation report is filed against the initiator
website's Reporting API, if so configured. 3. An issue surfaced in the
DevTools Issues panel. Likewise, when the feature is enabled and a request
is blocked, the same happens except that the message logged to the DevTools
console is an error and its text is slightly different. The devtools
network panel shows information about the source and remote address spaces
at play.


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

Is this feature fully tested by web-platform-tests

?Yes

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

[Chris Harrelson]

On Fri, Oct 20, 2023 at 9:00 AM Joey Arhar  wrote:

> > > For the purposes of WHATWG's multi-implementer support criteria: I
> will assume we cannot check the box for "Chromium supports this feature"
> until a different browser has shipped :state() to their stable channel.
> (Let me know if that is incorrect.)
> >
> > Chromium does support the feature, and it should be marked as such in
> the WHATWG. (We've shipped it in fact, just with a slightly different name
> for the moment.)
>
> Yeah I'm worried that not merging the spec would be a confusing signal to
> Apple and then they might never implement anything. I'd like to see the
> HTML spec get merged as :state().
>

+1!


>
> On Fri, Oct 20, 2023 at 8:55 AM Chris Harrelson 
> wrote:
>
>>
>>
>> On Thu, Oct 19, 2023 at 6:48 PM Domenic Denicola 
>> wrote:
>>
>>> Thanks Chris and the API Owners for having this discussion! I am
>>> sympathetic to this being a hard problem with the strong potential to set a
>>> bad precedent.
>>>
>>> On Fri, Oct 20, 2023 at 3:00 AM Chris Harrelson 
>>> wrote:
>>>


 On Thu, Oct 19, 2023 at 10:59 AM Chris Harrelson 
 wrote:

> The API owners met yesterday and discussed this intent. Our consensus
> was that we would like to wait until another browser has implemented and 
> is
> shipping :state before we approve shipping it in Chromium. We also don't
> recommend spending more time on further bikeshet spec discussions for it 
> in
> the meantime, and leave the spec as-is.
>

 "bikeshed", that is.

>>>
>>> With my HTML spec editor hat on, I have a clarifying point and question.
>>>
>>> "Leave the spec as-is": right now there are unmerged CSS
>>>  and HTML
>>>  spec PRs, plus a WICG spec
>>> . So it's not clear
>>> exactly which spec you're referring to, but I guess the advice is for
>>> Chromium engineers to not invest effort in changing any of these three work
>>> items for bikeshed considerations. (Let me know if this is incorrect.) Of
>>> course, other community members can continue to work on the spec if they
>>> wish.
>>>
>>
>> Those PRs should be finished and landed. My/our comment was only about
>> bikeshedding.
>>
>> For the purposes of WHATWG's multi-implementer support criteria: I will
>>> assume we cannot check the box for "Chromium supports this feature" until a
>>> different browser has shipped :state() to their stable channel. (Let me
>>> know if that is incorrect.)
>>>
>>
>> Chromium does support the feature, and it should be marked as such in the
>> WHATWG. (We've shipped it in fact, just with a slightly different name for
>> the moment.)
>>
>>
>>>
>>>


>
> We think this plan is a reasonable approach to reduce work for
> web developers and Chromium implementers in the short term while still
> achieving interop in the future.
>
> On Thu, Oct 12, 2023 at 11:41 AM Alex Russell <
> slightly...@chromium.org> wrote:
>
>> Hey all,
>>
>> We've spent a LOT of time discussing this one in API OWNERS, and my
>> disinclination to allow this to move forward remains. What we're 
>> observing
>> in this Intent is an anti-pattern in which:
>>
>>- Chromium engineers follow a process that is designed to put
>>developer needs above implementer preferences
>>
>> ,
>>explore the design space earnestly, work with developers to vet a 
>> solution,
>>and work to build interest with other vendors
>>
>> 
>>.
>>- Other projects fail to implement and/or implement alternatives.
>>- The API OWNERS take a calculated risk to ship first. That is
>>premised on collateral the development team provides that the design 
>> solves
>>an important problem well, demonstrating developer support and that 
>> our
>>process for open development has given ample time for others to 
>> engage and
>>help shape the design.
>>- Time passes (often years).
>>- Without implementing themselves, other vendors demand that the
>>design change to achieve "consensus" within a standards body, but 
>> without
>>demonstrating real deficiencies in the shipped API or even feedback 
>> from
>>developers that we were wrong in some important way.
>>
>>
>> Or put another way, spec fiction is being allowed to trump real-world
>> problem solving, and that's not what our process is designed to 
>> facilitate.
>>
>> Not only does this pattern further escalate the costs 

Re: [blink-dev] Intent to Ship: Protected Audiences Negative Targeting

['Orr Bernstein' via blink-dev]

FYI, the spec (https://github.com/WICG/turtledove/pull/796) has been 
merged. Thank you all again.

All the best,
- Orr

On Wednesday, October 4, 2023 at 3:04:23 PM UTC-4 Orr Bernstein wrote:

> Thank you all so much. I'll update this thread when 
> https://github.com/WICG/turtledove/pull/796 has landed.
>
> All the best,
> - Orr
>
>
> On Wed, Oct 4, 2023 at 11:51 AM Chris Harrelson  
> wrote:
>
>> LGTM3, same.
>>
>> On Wed, Oct 4, 2023 at 8:50 AM Yoav Weiss  wrote:
>>
>>> LGTM2 with the same conditions
>>>
>>> On Monday, October 2, 2023 at 11:00:07 PM UTC+2 Mike Taylor wrote:
>>>
 LGTM1 % landing https://github.com/WICG/turtledove/pull/796. Please 
 follow up with the WPTs as well.
 On 9/27/23 11:56 AM, Chris Harrelson wrote:

 Please fill out the other chromestatus review categories (privacy, 
 security, etc); we'll re-review once those are done.

 On Wed, Sep 20, 2023 at 2:42 PM 'Orr Bernstein' via blink-dev <
 blin...@chromium.org> wrote:

> Contact emails 
>
> or...@google.com, paulj...@chromium.org
>
> Explainer 
>
> https://github.com/WICG/turtledove/pull/780
>
> Specification 
>
> https://github.com/WICG/turtledove/pull/796
>
> Summary 
>
> In online ad auctions for ad space, it’s sometimes useful to prevent 
> showing an ad to certain audiences, a concept known as negative 
> targeting. 
> For example, you might not want to show a new customer advertisement to 
> existing customers. New customer acquisition campaigns most often have 
> this 
> as a critical requirement. Protected Audience currently enables ads to 
> target users that have been joined to a given interest group through some 
> past activity on the web. This feature extends Protected Audience to 
> enable 
> negative targeting by allowing new ads to target only those users who 
> have 
> not been joined to a given interest group. In this way, we're enabling 
> advertisers to target new groups of users using the existing 
> privacy-preserving concepts of the Protected Audience API.
>
>
> Blink component 
>
> Blink>InterestGroups 
> 
>
> TAG review 
>
> The parent proposal, Protected Audience, is still pending: 
> https://github.com/w3ctag/design-reviews/issues/723
>
> TAG review status 
>
> Pending
>
> Risks
>
> Interoperability and Compatibility 
>
> None. This is an optional new feature of the Protected Audience API. 
> Ad techs can use this new feature by specifying values for new fields in 
> the auction config. Without explicit values for those new fields, there's 
> no functional behavioral change as a result of this feature.
>
> Gecko & WebKit: No signal on parent proposal, Protected Audience.  
> Asked in the Mozilla forum here 
> , and in 
> the Webkit forum here 
> .
>
> Web developers: Adtech asked for this via Protected Audience Github 
> issue #319 .
>
>
> Debuggability 
>
> Additional bids sent into the auction are visible in their response 
> headers via DevTools. You can determine if the additional bid was sent 
> for 
> scoring by adding a breakpoint in the scoring script in DevTools. Error 
> scenarios, e.g. signature verification errors and joining origin mismatch 
> on negative interest groups - are written to the console. We're 
> considering 
> additional DevTools enhancements to aid additional bids debugging.
>
> Will this feature be supported on all six Blink platforms (Windows, 
> Mac, Linux, Chrome OS, 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 
> 
> ? 
>
> We plan to add WPTs to cover this API in the next month.
>
> Flag name on chrome://flags 
>
> None
>
> Finch feature name 
>
> FledgeNegativeTargeting
>
> Requires code in //chrome? 
>
> False
>
> Estimated milestones 
>
> Shipping on desktop and Android in M118.
>
> Anticipated spec changes 
>
> None related to this feature.
>
> Link to entry on the Chrome Platform Status 
>
> https://chromestatus.com/feature/5021508157571072
>
> This intent message was generated by Chrome Platform Status 
> .
> -- 
> You received this message because you are subscribed to the 

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

[Joey Arhar]

> > For the purposes of WHATWG's multi-implementer support criteria: I will
assume we cannot check the box for "Chromium supports this feature" until a
different browser has shipped :state() to their stable channel. (Let me
know if that is incorrect.)
>
> Chromium does support the feature, and it should be marked as such in the
WHATWG. (We've shipped it in fact, just with a slightly different name for
the moment.)

Yeah I'm worried that not merging the spec would be a confusing signal to
Apple and then they might never implement anything. I'd like to see the
HTML spec get merged as :state().

On Fri, Oct 20, 2023 at 8:55 AM Chris Harrelson 
wrote:

>
>
> On Thu, Oct 19, 2023 at 6:48 PM Domenic Denicola 
> wrote:
>
>> Thanks Chris and the API Owners for having this discussion! I am
>> sympathetic to this being a hard problem with the strong potential to set a
>> bad precedent.
>>
>> On Fri, Oct 20, 2023 at 3:00 AM Chris Harrelson 
>> wrote:
>>
>>>
>>>
>>> On Thu, Oct 19, 2023 at 10:59 AM Chris Harrelson 
>>> wrote:
>>>
 The API owners met yesterday and discussed this intent. Our consensus
 was that we would like to wait until another browser has implemented and is
 shipping :state before we approve shipping it in Chromium. We also don't
 recommend spending more time on further bikeshet spec discussions for it in
 the meantime, and leave the spec as-is.

>>>
>>> "bikeshed", that is.
>>>
>>
>> With my HTML spec editor hat on, I have a clarifying point and question.
>>
>> "Leave the spec as-is": right now there are unmerged CSS
>>  and HTML
>>  spec PRs, plus a WICG spec
>> . So it's not clear
>> exactly which spec you're referring to, but I guess the advice is for
>> Chromium engineers to not invest effort in changing any of these three work
>> items for bikeshed considerations. (Let me know if this is incorrect.) Of
>> course, other community members can continue to work on the spec if they
>> wish.
>>
>
> Those PRs should be finished and landed. My/our comment was only about
> bikeshedding.
>
> For the purposes of WHATWG's multi-implementer support criteria: I will
>> assume we cannot check the box for "Chromium supports this feature" until a
>> different browser has shipped :state() to their stable channel. (Let me
>> know if that is incorrect.)
>>
>
> Chromium does support the feature, and it should be marked as such in the
> WHATWG. (We've shipped it in fact, just with a slightly different name for
> the moment.)
>
>
>>
>>
>>>
>>>

 We think this plan is a reasonable approach to reduce work for
 web developers and Chromium implementers in the short term while still
 achieving interop in the future.

 On Thu, Oct 12, 2023 at 11:41 AM Alex Russell 
 wrote:

> Hey all,
>
> We've spent a LOT of time discussing this one in API OWNERS, and my
> disinclination to allow this to move forward remains. What we're observing
> in this Intent is an anti-pattern in which:
>
>- Chromium engineers follow a process that is designed to put
>developer needs above implementer preferences
>
> ,
>explore the design space earnestly, work with developers to vet a 
> solution,
>and work to build interest with other vendors
>
> 
>.
>- Other projects fail to implement and/or implement alternatives.
>- The API OWNERS take a calculated risk to ship first. That is
>premised on collateral the development team provides that the design 
> solves
>an important problem well, demonstrating developer support and that our
>process for open development has given ample time for others to engage 
> and
>help shape the design.
>- Time passes (often years).
>- Without implementing themselves, other vendors demand that the
>design change to achieve "consensus" within a standards body, but 
> without
>demonstrating real deficiencies in the shipped API or even feedback 
> from
>developers that we were wrong in some important way.
>
>
> Or put another way, spec fiction is being allowed to trump real-world
> problem solving, and that's not what our process is designed to 
> facilitate.
>
> Not only does this pattern further escalate the costs involved in the
> process to deliver a feature where we have already paid treble to
> ice-break, it potentially breaks applications -- remember that we suffer
> from enterprise blindness in our use counters, so it's probable that we
> will 

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

[Chris Harrelson]

On Thu, Oct 19, 2023 at 6:48 PM Domenic Denicola 
wrote:

> Thanks Chris and the API Owners for having this discussion! I am
> sympathetic to this being a hard problem with the strong potential to set a
> bad precedent.
>
> On Fri, Oct 20, 2023 at 3:00 AM Chris Harrelson 
> wrote:
>
>>
>>
>> On Thu, Oct 19, 2023 at 10:59 AM Chris Harrelson 
>> wrote:
>>
>>> The API owners met yesterday and discussed this intent. Our consensus
>>> was that we would like to wait until another browser has implemented and is
>>> shipping :state before we approve shipping it in Chromium. We also don't
>>> recommend spending more time on further bikeshet spec discussions for it in
>>> the meantime, and leave the spec as-is.
>>>
>>
>> "bikeshed", that is.
>>
>
> With my HTML spec editor hat on, I have a clarifying point and question.
>
> "Leave the spec as-is": right now there are unmerged CSS
>  and HTML
>  spec PRs, plus a WICG spec
> . So it's not clear
> exactly which spec you're referring to, but I guess the advice is for
> Chromium engineers to not invest effort in changing any of these three work
> items for bikeshed considerations. (Let me know if this is incorrect.) Of
> course, other community members can continue to work on the spec if they
> wish.
>

Those PRs should be finished and landed. My/our comment was only about
bikeshedding.

For the purposes of WHATWG's multi-implementer support criteria: I will
> assume we cannot check the box for "Chromium supports this feature" until a
> different browser has shipped :state() to their stable channel. (Let me
> know if that is incorrect.)
>

Chromium does support the feature, and it should be marked as such in the
WHATWG. (We've shipped it in fact, just with a slightly different name for
the moment.)


>
>
>>
>>
>>>
>>> We think this plan is a reasonable approach to reduce work for
>>> web developers and Chromium implementers in the short term while still
>>> achieving interop in the future.
>>>
>>> On Thu, Oct 12, 2023 at 11:41 AM Alex Russell 
>>> wrote:
>>>
 Hey all,

 We've spent a LOT of time discussing this one in API OWNERS, and my
 disinclination to allow this to move forward remains. What we're observing
 in this Intent is an anti-pattern in which:

- Chromium engineers follow a process that is designed to put
developer needs above implementer preferences

 ,
explore the design space earnestly, work with developers to vet a 
 solution,
and work to build interest with other vendors

 
.
- Other projects fail to implement and/or implement alternatives.
- The API OWNERS take a calculated risk to ship first. That is
premised on collateral the development team provides that the design 
 solves
an important problem well, demonstrating developer support and that our
process for open development has given ample time for others to engage 
 and
help shape the design.
- Time passes (often years).
- Without implementing themselves, other vendors demand that the
design change to achieve "consensus" within a standards body, but 
 without
demonstrating real deficiencies in the shipped API or even feedback from
developers that we were wrong in some important way.


 Or put another way, spec fiction is being allowed to trump real-world
 problem solving, and that's not what our process is designed to facilitate.

 Not only does this pattern further escalate the costs involved in the
 process to deliver a feature where we have already paid treble to
 ice-break, it potentially breaks applications -- remember that we suffer
 from enterprise blindness in our use counters, so it's probable that we
 will also need to reach out to, e.g., Salesforce and ask them to help
 collect data. This pattern also drags us away from other work that would
 expand the platform for users and developers in productive ways.

 These costs may seems small on an individual feature basis, but they
 add up fast and set terrible precedent. I'm *extremely* unhappy that
 we seem to be engaging in more of it over the past year, particularly
 without strong arguments for why the new design is superior. Even the
 recent debate over this feature is largely about non-committal mild
 preferences:

 https://github.com/w3c/csswg-drafts/issues/4805#issuecomment-1663111980

 At this point I've read substantially all of the minutes related to
 these design 

[blink-dev] Intent to Experiment: Private Network Access permission to relax mixed content

['Yifan Luo' via blink-dev]

Contact emails...@chromium.org, cl...@chromium.org

Explainer
https://github.com/iVanlIsh/private-network-access/blob/main/explainer.md

Specificationhttps://wicg.github.io/private-network-access

Design docs
https://docs.google.com/document/d/1Q18g4fZoDIYQ9IuxlZTaItgkzfiz_tCqaEAI8J3Y1WY/edit

Summary

In order to establish connections to devices on a local network that do not
have globally unique names, and therefore cannot obtain TLS certificates,
this feature introduces a new option to `fetch()` to declare a developers'
intent to talk to such a device, a new policy-controlled feature to gate
each sites' access to this capability, and new headers for the server's
preflight response to provide additional metadata.


Blink componentBlink>SecurityFeature>CORS>PrivateNetworkAccess


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

TAG review statusIssues addressed

Risks


Interoperability and Compatibility



*Gecko*: No signal

*WebKit*: No signal

*Web developers*: Positive (
https://github.com/WICG/private-network-access/issues/23)

*Other signals*:

Ergonomics

This new feature requires users to click on the new permission. This may
lead users to spamming on some websites. However, this is an intentional
move to encourage the websites to provide security context. The origin
trial also aimed to measure the frequency of users getting the permissions.


Activation

No. This feature attempt to bring developers an easier way to restrict
Private Network Access with secure context.


Security

This is a security positive 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


Goals for experimentation



Ongoing technical constraints

None.


Debuggability

Relevant information (client and resource IP address space) is already
piped into the DevTools network panel. We’ll likely also represent the
permission state in the settings pages.


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

Mac, Windows, Linux, Chrome OS, Fuchsia, Android, WebLayer. Not Android
WebView because of the absence of deprecation trial integration (though
that may be changing soon, see https://crbug.com/1308425). Not iOS because
this requires changes in Blink and the network service, neither of which
are used on iOS.


Is this feature fully tested by web-platform-tests

?No

https://wpt.fyi/results/fetch/private-network-access/mixed-content-fetch.tentative.https.window.html?label=master=experimental=private-network-access


Flag name on chrome://flags

Finch feature nameNone

Non-finch justificationNone

Requires code in //chrome?True

Tracking bughttps://crbug.com/1338439

Estimated milestones
OriginTrial desktop last 123
OriginTrial desktop first 120

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

Links to previous Intent discussionsIntent to prototype:
https://groups.google.com/a/chromium.org/g/blink-dev/c/6MczoSFGiHo/m/IigYuhu7AwAJ

This intent message was generated by Chrome Platform Status
.

-- 
Yifan

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

[blink-dev] Intent to Ship: CSS and Syntax for registered Custom Properties

[Rune Lillesveen]

Contact emailsfuth...@chromium.org, andr...@chromium.org

ExplainerNone

Specification
https://drafts.css-houdini.org/css-properties-values-api-1/#syntax-strings

Summary

Supports using the  and  syntaxes for
custom properties registered with @property or registerProperty(). The
syntax can be used to restrict values of the custom property to represent
transforms. This also makes it possible to use transitions and animations
directly on these registered custom properties.


 and  can have computed values that
contain both pixel and percentage values. They are interpolated as pixels
and percentages respectively. However, if transforms cannot be interpolated
on a function by function basis because the function types do not match,
they need to be interpolated by matrices which cannot represent percentage
values. For instance when interpolating between a translate and a rotate
with a percentage component in the translate function.

For those cases a mix() function is necessary to represent intermediate
values. Chrome does not yet implement a mix() function. Instead we fall
back to discrete interpolations to avoid non-representable computed values.
This is only a problem for the standard 'transform' property in the typed
om interfaces since getComputedStyle() returns the resolved value for the
'transform' property.

Blink componentBlink>CSS


TAG reviewNone

TAG review statusNot applicable

Risks


Interoperability and Compatibility

None


*Gecko*: Positive Implementation behind a flag.

*WebKit*: Shipped/Shipping

*Web developers*: No signals

*Other signals*:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that
it has potentially high risk for Android WebView-based applications?

None


Debuggability

No additional devtools support necessary compared to existing syntaxes.


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

Is this feature fully tested by web-platform-tests

?Yes

https://wpt.fyi/css/css-properties-values-api/animation/custom-property-animation-list-type-mismatch.html
https://wpt.fyi/css/css-properties-values-api/animation/custom-property-animation-transform-function.html
https://wpt.fyi/css/css-properties-values-api/animation/custom-property-animation-transform-list-multiple-values.html
https://wpt.fyi/css/css-properties-values-api/animation/custom-property-animation-transform-list-single-values.html
https://wpt.fyi/css/css-properties-values-api/animation/custom-property-transition-transform-function.html
https://wpt.fyi/css/css-properties-values-api/animation/custom-property-transition-transform-list.html
https://wpt.fyi/css/css-properties-values-api/at-property.html
https://wpt.fyi/css/css-properties-values-api/registered-property-computation.html
https://wpt.fyi/css/css-properties-values-api/registered-property-initial.html
https://wpt.fyi/css/css-properties-values-api/register-property-syntax-parsing.html
https://wpt.fyi/css/css-properties-values-api/typedom.html


Flag name on chrome://flags#enable-experimental-web-platform-features

Finch feature nameCSSVariables2TransformValues

Requires code in //chrome?False

Tracking bughttps://crbug.com/911156

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

Anticipated spec changes

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

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

This intent message was generated by Chrome Platform Status
.


-- 
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/CACuPfeRL2cdKk0ES9dJS-CrA7oH-NcnUeJhAZ%2BLnWHkt7dq8yA%40mail.gmail.com.

Re: [blink-dev] Android shared workers

[Kenji Baheux]

On Thu, Oct 19, 2023 at 10:56 PM Ben Kelly  wrote:

> On Thu, Oct 19, 2023 at 5:20 AM Kenji Baheux 
> wrote:
>
>> Compelling use cases (e.g. actual & reasonably popular products that work
>> better or only work when sharedworker are available *on mobile*) would
>> help boost the priority over other interop requests.
>>
>
> There were enough use cases for Apple to reintroduce shared worker after
> removing it.  Classic one is any kind of site where a user may plausibly
> have multiple tabs open and need them to remain in sync with the server.
> You treat the SharedWorker as the source of truth in terms of talking to
> the server, data updates, etc.  So email clients, shared document editors,
> etc fit this bill.
>
  Yes, you can accomplish the same thing more awkwardly other ways with
> leader-election algorithms using BroadcastChannel or force ServiceWorker
> into a SharedWorker model by forcing it to stay alive.  But forcing
> sub-optimal solutions is a tax on the web ecosystem for these use cases and
> pushes people to build native apps for mobile instead of the web.
>
> I'll also just say I find the framing of "mobile web" as a separate
> platform from the web in general or desktop web somewhat surprising and
> disappointing.  We should not be bifurcating the web ecosystem without a
> good reason.
>

At the time there was a reasonable reason (complexity and implementation
costs vs. lack of strong use cases / partners).

Things are a bit different these days. That said, there are other interop
requests that compete for the team's bandwidth, beside their main projects.
The other requests have clearer signals of impact *at the moment*.


>  What is the reason SharedWorker should be desktop-only when every other
> browser is able to ship it on mobile?
>

To be clear, no one said that SharedWorker should be desktop-only.
This is not an if, it's a when.


>
>
>
>
>>
>> On Wed, Oct 18, 2023 at 11:04 PM Ben Kelly 
>> wrote:
>>
>>> FWIW, chrome on android is the last holdout on shared workers.  Safari
>>> on ios supports it.  It would be nice if this could be prioritized.
>>>
>>> On Wed, Oct 18, 2023 at 9:44 AM Rik Cabanier  wrote:
>>>
 One of our users reported that sharedworkers weren't working in the
 browser.
 After investigating it looks like they were never supported on Android
 but it seems that they are supported everywhere else, including mobile
 Safari.
 Reading
 https://monorail-prod.appspot.com/p/chromium/issues/detail?id=154571,
 it seems there was a concern that too many sharedworkers would exhaust
 system resources. Is that still a concern 10 years later?

 --
 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/34528104-dca4-4a21-b376-013bd393dfc1n%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/CAK7rkMjH%2BV42hygYZTH6f9CBj4nfkk4W4rQuaXY84d-r%2BX%3DOmg%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/CADWWn7VmRBhi3bbSOGhJdyp2%3D8wsW7tknvAXiiZoaAVCQ3HbXg%40mail.gmail.com.

Re: [blink-dev] Intent to Experiment: IP Protection Phase 0

['Thomas Steiner' via blink-dev]

In the attached document
,
there are (at first sight) three domains of long-dead Google services:

inbox.google.com
wave.google.com
orkut.com

Is this on purpose?

On Thu, Oct 19, 2023 at 10:52 PM 'Brianna Goldstein' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emails
>
> Brianna Goldstein , James Bradley
> , David Schinazi 
>
> Explainer
>
> IP Protection formerly known as Gnatcatcher
> 
>
> Specification
>
> None
>
> Summary
>
> IP Protection  is a
> feature that sends third-party traffic for a set of domains through proxies
> for the purpose of protecting the user by masking their IP address from
> those domains.
>
> After receiving much feedback from the ecosystem, the design of the
> broader proposal is as follows:
>
>-
>
>IP Protection will be opt-in initially. This will help ensure that
>there is user control over privacy decisions and that Google can monitor
>behaviors at lower volumes.
>-
>
>It will roll out in a phased manner. Like all of our privacy
>proposals, we want to ensure that we learn as we go and we recognize that
>there may also be regional considerations to evaluate.
>-
>
>We are using a list based approach and only domains on the list in a
>third-party context will be impacted. We are conscious that these
>proposals may cause undesired disruptions for legitimate use cases and so
>we are just focused on the scripts and domains that are considered to be
>tracking users.
>
>
> We plan to test and roll out the feature in multiple phases. To start,
> Phase 0 will use a single Google-owned proxy and will only proxy requests
> to domains owned by Google. This first phase will allow us to test our
> infrastructure while preventing impact to other companies and gives us more
> time to refine the list of domains that will be proxied. For simplicity,
> only clients with US-based IP addresses will be granted access to the
> proxies for phase 0.
>
> A small percentage of clients will be automatically enrolled in this
> initial test, though the architecture and design will evolve between this
> test and future launches. To access the proxy, a user must be logged in to
> Chrome. To prevent abuse, a Google-run authentication server will grant
> access tokens to the Google run proxy based on a per-user quota.
>
> In future phases we plan to use a 2-hop proxy, as had previously been
> indicated in the IP Protection explainer.
>
> Blink component
>
> Privacy>Fingerprinting>IPProtection
> 
>
> TAG review
>
> None
>
> TAG review status
>
> N/A
>
> RisksInteroperability and Compatibility
>
> IP Protection changes how stable a client's IP address is but does not
> otherwise cause a breaking change for existing sites. In this experiment
> the only sites impacted are Google owned domains which include the some
> domains
> 
> when they are loaded in a third party context.
>
> For those requests, a stable IP address for a client can no longer be
> expected. There is no impact to other domains at this time.
>
> Gecko: No signal
>
> WebKit: Shipped a similar feature in Intelligent Tracking Protection.
> This experiment is only a single proxy, however we plan in a later phase to
> move to the double hop proxy model that Safari has also shipped.
>
> 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?
>
> This experiment does not include Webview.
>
>
> Goals for experimentation
>
> We will enable this experiment in the pre-stable Chrome channels at most
> to 33% of clients. For this initial experiment we want to test our
> infrastructure and the integrations between various components for bugs,
> stability and reliability. We want to measure the latency of requests using
> the full flow to get an early picture of where we can improve performance
> as we ramp up traffic.
>
> Ongoing technical constraints
>
> None
>
> Debuggability
>
> How to test IP Protection if the feature is enabled on your client
>
>1.
>
>Navigate your configured browser to chrome://net-export.
>2.
>
>Click “Start Logging To Disk” and save the log as something you can
>remember
>3.
>
>Open another tab and navigate to a sites that loads 3p Google ads
>4.
>
>Go back to your net-export tab and click “Stop Logging”. This will
>download a JSON log file.
>5.
>
>Navigate to https://netlog-viewer.appspot.com/#import and import your
>file
>6.
>
>Using the left navigation bar, navigate 

Re: [blink-dev] Re: Intent to Experiment: IP Protection Phase 0

[Martin Thomson]

As Harald mentioned, this is based on ongoing IETF work, but I think that
Mike's assessment is the relevant one: this is a choice that Chrome can
make without necessarily getting approval from anyone.  Apple's iCloud
Private Relay is a very similar system that is well-known and favourably
viewed.

The hazards here are less obvious, but they are all things that Chromium
people need to consider carefully.  I believe some, like Mike, already have
performed this analysis, even if Brianna's short note doesn't cover these
details.

Sites today rely heavily on IP reputation for denial of service and abuse
mitigation purposes.  Hiding IP at scale is going to force sites to alter
how they think about and react to abuse and attacks.  I understand that
this is why Apple shipped Private Access Tokens and Google are working on
Private State Tokens.  That is, Privacy Pass.  (Mozilla will have something
to share about Privacy Pass in the next week or so.)  A slow roll-out that
initially limits proxying to embedded content should help here.

Routing traffic through a limited number of entities creates a traffic
bottleneck.  That gives those entities considerable power over a vast
amount of traffic.  The privacy risk here is tiny, as I don't believe that
traffic analysis is currently very good at this scale, but it is worth
noting.  More concerning is that these entities have the ability to block
or slow traffic at scale.  The two-proxy setup does help a lot with that as
it makes targeting flows for analysis harder.


On Fri, Oct 20, 2023 at 3:29 PM Alex Russell 
wrote:

> This is going to change observable network behavior, right? The TAG liases
> with IETF, and if there aren't already active conversations in IETF about
> this change, I worry that it will be received poorly.
>
> On Thu, Oct 19, 2023, 7:15 PM Mike Taylor  wrote:
>
>> I'm recused from voting on this feature so with my API OWNER hat off (or
>> maybe just back and to the side to make me look cool...), it's possible
>> that we submit an FYI review in the future ahead of an I2S.
>>
>> That said, this is a feature that arguably does not materially alter web
>> platform APIs, but instead masks the client's IP using IETF defined
>> CONNECT, CONNECT-UDP, and MASQUE, etc. But if TAG would like to provide
>> input on our design choices, that could be useful. But it shouldn't block
>> an experiment.
>> On 10/19/23 3:22 PM, Alex Russell wrote:
>>
>> Why has the TAG not been consulted?
>>
>> On Thu, Oct 19, 2023, 3:09 PM 'Brianna Goldstein' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> *Correction*:
>>> The link to the entry on the Chrome Platform Status was incorrect. Below
>>> is the corrected link
>>>
>>> https://chromestatus.com/feature/5111460239245312
>>>
>>> On Thu, Oct 19, 2023 at 4:52 PM Brianna Goldstein <
>>> brgoldst...@google.com> wrote:
>>>
 Contact emails

 Brianna Goldstein , James Bradley
 , David Schinazi 

 Explainer

 IP Protection formerly known as Gnatcatcher
 

 Specification

 None

 Summary

 IP Protection  is a
 feature that sends third-party traffic for a set of domains through proxies
 for the purpose of protecting the user by masking their IP address from
 those domains.

 After receiving much feedback from the ecosystem, the design of the
 broader proposal is as follows:

-

IP Protection will be opt-in initially. This will help ensure that
there is user control over privacy decisions and that Google can monitor
behaviors at lower volumes.
-

It will roll out in a phased manner. Like all of our privacy
proposals, we want to ensure that we learn as we go and we recognize 
 that
there may also be regional considerations to evaluate.
-

We are using a list based approach and only domains on the list in
a third-party context will be impacted. We are conscious that these
proposals may cause undesired disruptions for legitimate use cases and 
 so
we are just focused on the scripts and domains that are considered to be
tracking users.


 We plan to test and roll out the feature in multiple phases. To start,
 Phase 0 will use a single Google-owned proxy and will only proxy requests
 to domains owned by Google. This first phase will allow us to test our
 infrastructure while preventing impact to other companies and gives us more
 time to refine the list of domains that will be proxied. For simplicity,
 only clients with US-based IP addresses will be granted access to the
 proxies for phase 0.

 A small percentage of clients will be automatically enrolled in this
 initial test, though the architecture and design will evolve between this
 test and future launches. To 

Re: [blink-dev] Re: Intent to Experiment: IP Protection Phase 0

[Yoav Weiss]

I think it makes sense to file a TAG review as FYI in the future
(non-blocking for this experiment) just to let the TAG know that this is
happening, as it changes things significantly when it comes to
fingerprinting data (by making other avenues of fingerprinting data more
valuable than they currently are).

I wouldn't expect them to provide feedback on the IETF drafts this relies
on though.


On Fri, Oct 20, 2023 at 7:34 AM 'Harald Alvestrand' via blink-dev <
blink-dev@chromium.org> wrote:

> standard naming rant  can we call this "IP Address Protection"?
> My initial read of the title was "Intellectual Property Protection", and I
> opened it with a sense of dread expecting to find DRM-related stuff and a
> long argument.
>
> There are IETF efforts related to automatic relays (MASQUE, OHAI), but I
> think they are intended for a lower level of the protocol stack.
> Relays in HTTP are also well defined in IETF (for some value of "well"). I
> can't remember having seen this particular usage discussed there (but I
> don't follow HTTP that closely).
>
> On Fri, Oct 20, 2023 at 6:29 AM Alex Russell 
> wrote:
>
>> This is going to change observable network behavior, right? The TAG
>> liases with IETF, and if there aren't already active conversations in IETF
>> about this change, I worry that it will be received poorly.
>>
>> On Thu, Oct 19, 2023, 7:15 PM Mike Taylor  wrote:
>>
>>> I'm recused from voting on this feature so with my API OWNER hat off (or
>>> maybe just back and to the side to make me look cool...), it's possible
>>> that we submit an FYI review in the future ahead of an I2S.
>>>
>>> That said, this is a feature that arguably does not materially alter web
>>> platform APIs, but instead masks the client's IP using IETF defined
>>> CONNECT, CONNECT-UDP, and MASQUE, etc. But if TAG would like to provide
>>> input on our design choices, that could be useful. But it shouldn't block
>>> an experiment.
>>> On 10/19/23 3:22 PM, Alex Russell wrote:
>>>
>>> Why has the TAG not been consulted?
>>>
>>> On Thu, Oct 19, 2023, 3:09 PM 'Brianna Goldstein' via blink-dev <
>>> blink-dev@chromium.org> wrote:
>>>
 *Correction*:
 The link to the entry on the Chrome Platform Status was incorrect.
 Below is the corrected link

 https://chromestatus.com/feature/5111460239245312

 On Thu, Oct 19, 2023 at 4:52 PM Brianna Goldstein <
 brgoldst...@google.com> wrote:

> Contact emails
>
> Brianna Goldstein , James Bradley
> , David Schinazi 
>
> Explainer
>
> IP Protection formerly known as Gnatcatcher
> 
>
> Specification
>
> None
>
> Summary
>
> IP Protection  is a
> feature that sends third-party traffic for a set of domains through 
> proxies
> for the purpose of protecting the user by masking their IP address from
> those domains.
>
> After receiving much feedback from the ecosystem, the design of the
> broader proposal is as follows:
>
>-
>
>IP Protection will be opt-in initially. This will help ensure that
>there is user control over privacy decisions and that Google can 
> monitor
>behaviors at lower volumes.
>-
>
>It will roll out in a phased manner. Like all of our privacy
>proposals, we want to ensure that we learn as we go and we recognize 
> that
>there may also be regional considerations to evaluate.
>-
>
>We are using a list based approach and only domains on the list in
>a third-party context will be impacted. We are conscious that
>these proposals may cause undesired disruptions for legitimate use 
> cases
>and so we are just focused on the scripts and domains that are 
> considered
>to be tracking users.
>
>
Should we expect all 3Ps impacted to get the same client IP? Are we
concerned with them "comparing notes"?
Also, since the first party gets the real IP, are we concerned with it
starting to reflect that info in the DOM for 3Ps to pick it up?

>
>
>
> We plan to test and roll out the feature in multiple phases. To start,
> Phase 0 will use a single Google-owned proxy and will only proxy requests
> to domains owned by Google. This first phase will allow us to test our
> infrastructure while preventing impact to other companies and gives us 
> more
> time to refine the list of domains that will be proxied. For simplicity,
> only clients with US-based IP addresses will be granted access to the
> proxies for phase 0.
>
> A small percentage of clients will be automatically enrolled in this
> initial test, though the architecture and design will evolve between this
> test and future launches. To access the proxy, a user must be logged in to
> Chrome. To prevent abuse, a