Re: [blink-dev] Intent to Ship: Protected Audience directFromSellerSignals via HTTP response headers

[Mike Taylor]

On 9/7/23 6:00 PM, Caleb Raitto wrote:


Hi Yoav, some responses inline:

On Wednesday, September 6, 2023 at 12:15:45 PM UTC-4 Yoav Weiss wrote:

On Tue, Sep 5, 2023 at 9:55 PM Paul Jensen
 wrote:

Contact emails*

pauljen...@chromium.org


*Explainer*

https://github.com/WICG/turtledove/pull/69
5

*


Can you clarify what this does, as the explainer is not very
explain-y?

IIUC, the current flow to get directFromSellerSignals is to
download a response A which contains a link to a WBN, then
download the WBN and that contains the signal info.
Your proposal is to change that so that
the directFromSellerSignals information would be embedded in a
response header on response A?


The original directFromSellerSignals worked by downloading a response 
A, from the seller’s origin, that is a WBN containing several 
subresources that represent signals from the seller to various auction 
participants -- no linking was involved.



You’re correct about this header-based version of 
directFromSellerSignals -- when Chrome downloads a response, from the 
seller’s origin, with fetch(..., {adAuctionHeaders: true}), the 
Ad-Auction-Signals header gets parsed as JSON to provide the signals.



If so, any more details on that header? What would be the header
name? What payload sizes should we expect for the header's value?
In what conditions will it actually be processed?


The name of the header is Ad-Auction-Signals, as mentioned here in the 
explainer: [0]. Currently, the payload size is limited to 1kb [1], but 
we’re considering increasing that to 10kb based on feedback. When 
Chrome conducts a Protected Audience auction, it processes any 
received Ad-Auction-Signals headers whose adSlot matches that of the 
auction.  The header contains JSON that dictates which signals are 
sent to which auction participants.



[0] 
https://github.com/WICG/turtledove/pull/695/files#diff-d65ba9778fe3af46de3edfce2266b5b035192f8869280ec07179963b81f4e624R465 




[1] 
https://source.chromium.org/chromium/chromium/src/+/main:content/browser/interest_group/ad_auction_url_loader_interceptor.cc;l=195;drc=dcd52bb9a48216858a950b919383c44a290273f7 



Thanks for the explanation - what's preventing 
https://github.com/WICG/turtledove/pull/695 from landing? It seems 
rather old (and references stuff that no longer exists, like 
`X-FLEDGE-Auction-Only`. (It also doesn't seem to define any 
error-handling for parsing the JSON that a server returns, which would 
be good to do.)


Thanks,

-Caleb

*
*Specification*

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


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



*Summary*

Protected Audience already supports a mechanism to ensure the
authenticity and integrity of information passed into the
auction from the seller called directFromSellerSignals.
Currently this is implemented by the seller providing
subresources in a WebBundle to the browser, which after a year
of testing has proved to not be as efficient as originally
planned. It either requires an entirely new additional fetch
of a WebBundle, or for the seller to rewrite and rework an
existing fetch to respond instead with only a WebBundle. This
feature is a rewrite of directFromSellerSignals to use an HTTP
response header, transferred via HTTPS same-origin with the
seller, instead of a WebBundle to optimize performance.


*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 as this is an optional new way of providing
directFromSellerSignals.  It cannot be used jointly
with the old mechanism, but there shouldn’t be a need
to use the old mechanism.

*

*
*

*

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

Re: [blink-dev] IP Protection feature status

[Mike Taylor]

Hi David,

I just set it to "In Development".

thanks,
Mike

On 9/8/23 8:50 PM, David Dabbs wrote:

Hello.

IP Protection feature 
 card indicates /No 
active development/.
But there are issues underway, some 
 
requesting merge into M118 as "part of the implementation of a new 
feature (IP Protection), is protected by Finch flags, and is active 
for dogfooding in Canary and Dev "


For the folks following from home, would you kindly update the 
chromestatus page?


Thank you.
--
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/CAMifzo8KRnpf%2BvCkjTONnSDsMKaKRS4a2XvXEdZE-xfE-s4n9g%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/57f9c0bb-baa1-42e3-a6d8-c4d3a6928c3f%40chromium.org.

Re: [blink-dev] Intent to Deprecate and Remove: Dangling markup in target name

[Mike Taylor]

LGTM1 to ship. Risk seems very low (and worth it, given security 
improvements), but thanks for adding a runtime enabled feature.


On 9/7/23 12:44 AM, 'Jun Kokatsu' via blink-dev wrote:



Contact emails

jkoka...@google.com


Specification

https://github.com/whatwg/html/pull/9309/files 




Summary

This change replaces the navigable target name (which is usually set 
by target attribute) to `_blank`, if it contains a dangling markup 
(i.e. `\n` and `<`). Which fixes a bypass in the dangling markup 
injection mitigation.




Blink component

Blink>SecurityFeature 




Motivation

Blink has shipped a mitigation for dangling markup injection 
attack while back. 
However, it was discovered that the mitigation can be bypassed 
through 
target name. Navigations with such target names are low 
(~0.07%). 
Therefore, this change removes the limitation discovered in the 
previous mitigation.




Initial public proposal

None


TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

None



Gecko: Positive 




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

None



Is this feature fully tested by web-platform-tests

?

Yes 


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=1421440 




Estimated milestones

119



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5073969773805568 




--
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/CAOWKMF4CR50EbS%3DMrYxMa5PcyiYPFg%2B4X2e6F5S0kzcxJLygew%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/e68e959c-0a28-45b0-90f1-d35aa2e0c17b%40chromium.org.

Re: [blink-dev] Intent to Ship: Enrollment for Privacy Sandbox

[Mike Taylor]

On 9/7/23 6:06 PM, Shivani Sharma wrote:


On Friday, September 1, 2023 at 6:20:34 PM UTC-4 Mike Taylor wrote:

Thanks. One last question here: how confident are y'all that
consumers of these APIs are well-equipped for errors in case they
don't enroll? Have you looked at any Privacy Sandbox API usage in
the wild to verify that early adopters aren't going to break?


The Impact of not enrolling has been well publicized over the past few 
months on multiple levels and through various form factors, including 
blog posts and 1:1 conversations with ad tech companies testing the APIs.
While we have been thoughtful in our design, allowing sufficient time 
between outreach and enforcement, and supporting adtechs in their 
migration journey,  adtechs would need to enroll if they plan to call 
the APIs post-enforcement successfully.
We also think it’s important to launch this process now, to provide 
time for API callers to complete enrollment and work out any issues 
that may arise, ahead of expanded API testing in early 2024.


Thanks for the answer. It sounds like there is some compat risk for 
early adopters, but y'all have mechanisms in place to communicate the 
changes and do outreach if needed.


LGTM1 to ship.

--
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/1688dcc9-8dca-4e89-bc06-4b58725c22a9%40chromium.org.

Re: [blink-dev] Re: Intent to Implement and Ship: DisplayMediaStreamOptions monitorTypeSurfaces

[Mike Taylor]

LGTM2

On 9/6/23 11:01 AM, Yoav Weiss wrote:
LGTM1 to ship, while keeping an eye out for TAG feedback, in case it'd 
be surprising and not match past feedback in the same vein.


On Wed, Sep 6, 2023 at 5:41 PM 'François Beaufort' via blink-dev 
 wrote:




On Fri, Sep 1, 2023 at 3:09 PM François Beaufort
 wrote:


Contact emails

fbeauf...@google.com 

elada...@google.com 


Explainer


https://github.com/eladalon1983/screen-share-explainers/blob/main/monitorTypeSurfaces_Explainer.md




Specification


https://w3c.github.io/mediacapture-screen-share/#dom-displaymediastreamoptions-monitortypesurfaces




Summary

When getDisplayMedia()is called, the browser offers the user a
choice of display surfaces: tabs, windows, or monitors. Using
the monitorTypeSurfacesoption, the web application may now
hint to the browser if it prefers to include display surfaces
whose type is monitor among the choices offered to the user.


Blink component

Blink>GetDisplayMedia




TAG review

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



TAG review status

Pending


FYI this feature is a simple addition of a single flag to an
existing dictionary, following an established pattern that’s also
used by a few other keys of the same dictionary
(selfBrowserSurface, systemAudio, surfaceSwitching). well-known
patterns.
We already filed a TAG review for similar options at
https://github.com/w3ctag/design-reviews/issues/744 which was
marked as satisfied.


Risks


Interoperability and Compatibility

None


Gecko: No signal
(https://github.com/mozilla/standards-positions/issues/876
)
Jan-Ivar Bruaroey from Mozilla has reviewed and approved
https://github.com/w3c/mediacapture-screen-share/pull/274
.


WebKit: No signal
(https://github.com/WebKit/standards-positions/issues/248
)
Youenn Fablet from Apple has participated in
https://www.w3.org/2023/06/27-webrtc-minutes.html#t04
and

https://github.com/w3c/mediacapture-screen-share/issues/261#issuecomment-1693090386

.


Web developers: Positive Cisco folks have expressed interest
in this feature.

https://github.com/screen-share/meetings/blob/main/minutes/2023-03-21.md?plain=1#L161




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

Supported on all platforms that support getDisplayMedia.
Namely, all desktop platforms.


Is this feature fully tested by web-platform-tests

?

Yes. See
https://wpt.fyi/results/screen-capture/getdisplaymedia.https.html


Flag name on chrome://flags

None


Finch feature name

MonitorTypeSurfaces


Requires code in //chrome?

Yes. In
chrome/browser/media/webrtc/display_media_access_handler.cc


Tracking bug

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



Estimated milestones

Shipping on desktop



119


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 

Re: [blink-dev] Intent to Ship: Sec-CH-Prefers-Reduced-Transparency User Preference Media Features Client Hints Header

[Mike Taylor]

LGTM2

On 9/6/23 10:25 AM, Yoav Weiss wrote:

LGTM1

On Sat, Sep 2, 2023 at 1:06 AM Luke  wrote:

Apologies, https://github.com/w3ctag/design-reviews/issues/632
would be the relevant link. Will update in Chromestatus too.

On Friday, 1 September 2023 at 23:10:25 UTC+1 mike...@chromium.org
wrote:

On 8/30/23 3:55 PM, Luke wrote:



Contact emails

lukewa...@gmail.com, lu...@warlow.dev


Explainer


https://github.com/wicg/user-preference-media-features-headers/blob/main/README.md


Specification


https://wicg.github.io/user-preference-media-features-headers/#sec-ch-prefers-reduced-transparency


Summary

User Preference Media Features Client Hints Header defines a
set of HTTP Client Hints headers around user preference media
features as defined by Media Queries Level 5. If used as
Critical Client Hints, these headers allow servers to make
smart choices regarding, e.g., CSS inlining.
Sec-CH-Prefers-Reduced-Transparency reflects the user's
prefers-reduced-transparency preference.



Blink component

Blink>CSS




Search tags

client hints
,
sec-ch-prefers-reduced-transparency

,
prefers-reduced-transparency



TAG review


Anything relevant to link here?



TAG review status

Pending


Risks



Interoperability and Compatibility



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

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

/Web developers/: Positive (WICG proposal Issue:
https://github.com/WICG/proposals/issues/30 with feedback
from developers working for Facebook and Magento. Twitter:
https://twitter.com/kilianvalkhof/status/1392404416335056896.
The proposal was initially discussed in
https://github.com/w3c/csswg-drafts/issues/4162 and received
positive feedback via 18 Likes)

/Other signals/:


Activation

Developers will include Sec-CH-Prefers-Reduced-Transparency
in the response headers Accept-CH and Critical-CH to let the
browser know that they’re interested in the user's
transparency preferences. If supported, the request header
Sec-CH-Prefers-Reduced-Transparency will be populated with
the appropriate value. This follows the same pattern as
existing Preference Client Hints and as such should be easy
for developers to make use of.



Security

This feature could be used for fingerprinting as it exposes a
user preference. However, this is already exposed to CSS/JS
by the `prefers-reduced-transparency` media query.



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?



Debuggability

Developers can change this client hint header value by
emulating prefers-reduced-transparency via Devtools in the
Rendering Panel.



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

Yes

The feature will be supported on all platforms, but whether
the user will be able to signal a reduced transparency
preference depends on the OS.



Is this feature fully tested by web-platform-tests

?

Yes


Flag name on chrome://flags

#enable-experimental-web-platform-features


Finch feature name

ClientHintsPrefersReducedTransparency


Requires code in //chrome?

False


Tracking bug

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


Sample links


https://sec-ch-prefers-reduced-transparency.glitch.me


Estimated milestones

Shipping on desktop 118
DevTrial on desktop 118

Shipping on Android 118
DevTrial on Android 118



Anticipated spec changes

Open questions about a feature may be a source of future web
compat or interop issues. Please list open 

Re: [blink-dev] Re: Intent to Ship: Remove Authorization header upon cross-origin redirect

[Mike Taylor]

LGTM2

On 9/3/23 8:12 PM, Yoav Weiss wrote:

LGTM1



On Mon, Sep 4, 2023 at 2:24 AM Kenichi Ishibashi  
wrote:


Hi, sorry for the long delay.

The feature page

now shows sites that use Authorization header for cross-origin
redirects. I randomly picked some of them and examined to see if
they could work when Chrome removes Authorization header up on
cross-origin redirects. As far as I can tell, none of them are
broken. We would like to ship this behind a feature flag.


Thanks for the analysis!
As you pointed out elsewhere, since our previous discussions on this 
thread, this was shipped 
 
by Firefox and Safari.
I think that changes the risk calculus (from compat to interop) and 
makes shipping this (with a base feature just in case) the right choice.



Thanks,

On Fri, Sep 1, 2023 at 1:39 AM Ioan-Cristian Linte
 wrote:

Any updates on this?
Other browser have already made the change for some time so
it's surprising that Chrome is so worried about breaking change.

The Authorization propagating in cross origin redirects is
causing a performance issue for us. Our server redirects to
AWS S3 with pre-signed url and this will return 400 error as
AWS S3 disallows specifying multiple authorizations (e.g.
signature in url and Authorization header) in a request. Also
the 400 error response includes a close connection header. To
make this work, the web client checks for the 400 error and
uses the response.url to make a new fetch request without the
Authorization header. Because the previous connection was
closed this incurs the cost of initiating a new connection.

On Wednesday, June 28, 2023 at 6:34:42 PM UTC+3 Yoav Weiss wrote:

Friendly ping! :) Any news on UKM data here?

On Wednesday, April 5, 2023 at 10:53:41 AM UTC+2 Yoav
Weiss wrote:

Sounds great, thanks!! :)

On Wed, Apr 5, 2023 at 10:44 AM Kenichi Ishibashi
 wrote:

Hi Yoav,

Sorry I haven't sent an update in this thread. (1)
sounds reasonable. I added the usercounters to UKM
a few weeks ago and I'm waiting for data. I will
report back after manual inspections are done.

Thanks,


On Wed, Apr 5, 2023 at 5:14 PM Yoav Weiss
 wrote:

Friendly ping on the above :) Does (1)
sound reasonable from your perspective?

On Wed, Mar 15, 2023 at 7:16 PM Yoav Weiss
 wrote:

The way I see this, given that the
usecounter is an order of magnitude higher
than what we can consider trivial, we have
3 options:
1) Add the usecounters to UKM

,
run an analysis on early data to extract
URLs that use this, and randomly sample
those for manual inspection.
2) Wait for the HTTPArchive crawl to run
with this usecounter, assuming that
unauthed landing pages will trigger it.
3) Run an HA query that tries to find
cross-origin redirects with Auth headers.
I'm not sure how easy (or feasible) that
would be, but Rick and Pat would know

To me, (1) seems to be the easiest, and
with the least amount of potential bias
(all pages vs. unauthed landing pages).

On Tue, Mar 14, 2023 at 9:45 PM Patrick
Meenan  wrote:

Do we expect the Authorization header
to be something that the HTTP Archive
triggers in a way that the feature
will trigger? Since they are all
unauthenticated single page loads, it
feels like it's unlikely to be
something that we hit.

On Tue, Mar 14, 2023 at 4:37 PM
Patrick Meenan 
   

Re: [blink-dev] Intent to Ship: Enrollment for Privacy Sandbox

[Mike Taylor]

On 9/1/23 2:46 PM, Shivani Sharma wrote:


Thanks Mike! Responses inline.

On Fri, Sep 1, 2023 at 1:09 PM Mike Taylor  wrote:

Hi Shivani,

In general I think this is a pretty interesting idea, just a few
minor questions below:

On 8/30/23 8:16 AM, Shivani Sharma wrote:



Contact emails

shivani...@chromium.org <mailto:shivani...@chromium.org>,
georg...@google.com <mailto:georg...@google.com>


Explainer

https://github.com/privacysandbox/attestation/blob/main/README.md
<https://github.com/privacysandbox/attestation/blob/main/README.md>


A few questions about the attestation format:

1) expiry_seconds_since_epoch implies this expires. Is there any
more info on this? Does a renewal mean incrementing
attestation_version?

2) attestation_version states "This allows the maintenance of a
historical record of attestations." Is that something you plan on
exposing to the public somewhere? Or would you expect a site to
maintain previous versions somewhere?

Also, how does unenrollment happen?

1. Yes the plan is to have attestations expire, and have adtechs step 
through re-attestation process which would increment the version.
2. The attestation file hosted on the .well-known will include all 
their historical attestations. We could also consider maintaining a 
historical record on the transparency server.
Cool - makes sense. The explainer (or blog post) could probably be 
updated to make this more clear.
Unenrollment would be either when the original attestation expires or 
the entity explicitly requests to unenroll (via the form asking to 
cancel existing enrollment). When that happens, their data will be 
removed from the enrollment records and the updated list pushed to 
Chrome will not have their site.
Thanks - it would be nice to document this in the explainer again (and 
the form, if it's not already documented).




Design document


https://docs.google.com/document/d/16PYa6wBBGBbV4YMujkFzBab8s4a7N4PcvpY0Js1qN1k/edit?usp=sharing

<https://docs.google.com/document/d/16PYa6wBBGBbV4YMujkFzBab8s4a7N4PcvpY0Js1qN1k/edit?usp=sharing>


Specification

While the enrollment process itself is not intended to be
standardized, the impacted API specifications allow for a user
agent defined gating mechanism such as enrollment and
attestation. The spec changes for the gated APIs are linked below:


Private aggregation (section with note on enrollment

<https://patcg-individual-drafts.github.io/private-aggregation-api/#scheduling-reports>)


Shared Storage (pull request
<https://github.com/WICG/shared-storage/pull/105>)

Topics (pull request
<https://github.com/patcg-individual-drafts/topics/pull/238/files>)

Attribution reporting API (pull request
<https://github.com/WICG/attribution-reporting-api/pull/968>)

Protected Audience (pull requests: 1
<https://github.com/WICG/fenced-frame/pull/114/files>, 2
<https://github.com/WICG/turtledove/pull/766/files>)


Summary and Motivation

As the Privacy Sandbox relevance and measurement APIs start
ramping up for general availability, we want to make sure these
technologies are used as intended and with transparency. The APIs
include Attribution Reporting, the Protected Audience API,
Topics, Private Aggregation and Shared Storage. As announced in a
blog post
<https://developer.chrome.com/blog/announce-enrollment-privacy-sandbox/>,
a new Developer Enrollment process for Privacy Sandbox relevance
and measurement APIs is being introduced across Chrome and
Android. This I2S refers to Chrome’s implementation of fetching
the enrolled-sites list from the enrollment server (via component
updater

<https://chromium.googlesource.com/chromium/src/+/lkgr/components/component_updater/README.md>)
and using it to gate access to the Privacy Sandbox APIs.


Blink component

Blink>PrivateAggregation

<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EPrivateAggregation>

Blink>Storage>SharedStorage

<https://bugs.chromium.org/p/chromium/issues/list?q=component%3ABlink%3EStorage%3ESharedStorage=2>

Blink>TopicsAPI

<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ETopicsAPI>

Internals > AttributionReporting

<https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3EAttributionReporting>

Blink>InterestGroups

<https://bugs.chromium.org/p/chromium/issues/list?q=component%3ABlink%3EInterestGroups=2>


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.

In the initial version, no 

Re: [blink-dev] Intent to Ship: Sec-CH-Prefers-Reduced-Transparency User Preference Media Features Client Hints Header

[Mike Taylor]

On 8/30/23 3:55 PM, Luke wrote:



Contact emails

lukewarlow...@gmail.com, l...@warlow.dev


Explainer

https://github.com/wicg/user-preference-media-features-headers/blob/main/README.md


Specification

https://wicg.github.io/user-preference-media-features-headers/#sec-ch-prefers-reduced-transparency


Summary

User Preference Media Features Client Hints Header defines a set of 
HTTP Client Hints headers around user preference media features as 
defined by Media Queries Level 5. If used as Critical Client Hints, 
these headers allow servers to make smart choices regarding, e.g., CSS 
inlining. Sec-CH-Prefers-Reduced-Transparency reflects the user's 
prefers-reduced-transparency preference.




Blink component

Blink>CSS 




Search tags

client hints , 
sec-ch-prefers-reduced-transparency 
, 
prefers-reduced-transparency 




TAG review


Anything relevant to link here?



TAG review status

Pending


Risks



Interoperability and Compatibility



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


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


/Web developers/: Positive (WICG proposal Issue: 
https://github.com/WICG/proposals/issues/30 with feedback from 
developers working for Facebook and Magento. Twitter: 
https://twitter.com/kilianvalkhof/status/1392404416335056896. The 
proposal was initially discussed in 
https://github.com/w3c/csswg-drafts/issues/4162 and received positive 
feedback via 18 Likes)


/Other signals/:


Activation

Developers will include Sec-CH-Prefers-Reduced-Transparency in the 
response headers Accept-CH and Critical-CH to let the browser know 
that they’re interested in the user's transparency preferences. If 
supported, the request header Sec-CH-Prefers-Reduced-Transparency will 
be populated with the appropriate value. This follows the same pattern 
as existing Preference Client Hints and as such should be easy for 
developers to make use of.




Security

This feature could be used for fingerprinting as it exposes a user 
preference. However, this is already exposed to CSS/JS by the 
`prefers-reduced-transparency` media query.




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?




Debuggability

Developers can change this client hint header value by emulating 
prefers-reduced-transparency via Devtools in the Rendering Panel.




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

Yes

The feature will be supported on all platforms, but whether the user 
will be able to signal a reduced transparency preference depends on 
the OS.




Is this feature fully tested by web-platform-tests

?

Yes


Flag name on chrome://flags

#enable-experimental-web-platform-features


Finch feature name

ClientHintsPrefersReducedTransparency


Requires code in //chrome?

False


Tracking bug

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


Sample links


https://sec-ch-prefers-reduced-transparency.glitch.me


Estimated milestones

Shipping on desktop 118
DevTrial on desktop 118

Shipping on Android 118
DevTrial on Android 118



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




Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6242983812268032


Links to previous Intent discussions

Intent to prototype: 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/B1ED49A6-31BF-4D28-89B3-D2973F9F12DA%40gmail.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/6B4E754E-49E5-47DE-B473-4AC40FC0C599%40gmail.com 

Re: [blink-dev] Intent to Experiment: X25519Kyber768 key encapsulation for TLS

[Mike Taylor]

Hi David,

LGTM to experiment from M117 - M118 inclusive. I think that's what 
you're asking for - please let me know if I'm reading this incorrectly. 
Good luck!


thanks,
Mike

On 8/28/23 9:18 AM, 'David Adrian' via blink-dev wrote:



Contact emails

dadr...@google.com


Explainer

https://www.ietf.org/archive/id/draft-tls-westerbaan-xyber768d00-02.html


Specification

https://www.ietf.org/archive/id/draft-tls-westerbaan-xyber768d00-02.html


Summary

Protect current Chrome TLS traffic against future quantum 
cryptanalysis by deploying the Kyber768 quantum-resistant key 
agreement algorithm. This is a hybrid X25519 + Kyber768 key agreement 
based on an IETF standard. This specification and launch is outside 
the scope of W3C. This key agreement will be launched as a TLS cipher, 
and should be transparent to users. 
https://blog.chromium.org/2023/08/protecting-chrome-traffic-with-hybrid.html




Blink component

Internals>Network>SSL 




Search tags

tls , kem 
, kyber 
, postquantum 




TAG review



TAG review status

Pending


Risks



Interoperability and Compatibility

Post-quantum secure ciphers are larger than classical ciphers. This 
may cause compatibility issues with middleboxes.



Any pointers to learn more about this possible compat problem?



/Gecko/: No signal 
(https://github.com/mozilla/standards-positions/issues/874) Firefox is 
also in the process of rolling this out.


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


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




Goals for experimentation

This is a Finch experiment, not site opt-in.

We are aiming to shake out bugs and incompatibilities with buggy TLS 
stacks that do not correctly handle large TLS ClientHellos. Announcing 
a public timeline for experimenting on stable provides the necessary 
justification for teams at companies who have buggy TLS stacks to 
prioritize fixing the bugs.



Ongoing technical constraints



Debuggability



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


Flag name on chrome://flags

enable-tls13-kyber


Finch feature name

PostQuantumKyber


Requires code in //chrome?

False


Tracking bug

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


Launch bug

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


Estimated milestones

Shipping on desktop 119
OriginTrial desktop last118
OriginTrial desktop first   117
DevTrial on desktop 115

Shipping on Android 119
OriginTrial Android last118
OriginTrial Android first   117
DevTrial on Android 115

Shipping on WebView 119



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5257822742249472


Links to previous Intent discussions

Intent to prototype: 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGkh42%2BgKeCTA6vWwzrE%3DDVR%3DTmQaCyDFQxqnXkOy9GcVyGtnA%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/CAGkh42%2B37SpGUy9t6bBkP13XQL4mrEaY%2Bu0wAzttjZyr_f2rGA%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/b18bb8c1-e6bb-4592-b6c4-c8a3dcbee74e%40chromium.org.

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

[Mike Taylor]

I also had an offline discussion with Daniel to confirm shipping as-is 
in M117, and sanitizing in 118 is acceptable from a security POV (trust 
but verify, etc).


LGTM1 to ship.

On 8/31/23 7:55 AM, 'Garrett Tanzer' via blink-dev wrote:
After some discussion offline, we're going to sanitize the macro keys 
and values with EscapeQueryParamValue 
 so 
that macro substitution always stays within the original query 
parameter field. This should prevent XSS-y substitutions while keeping 
the API surface exactly the same for regular use.


This fix will be implemented in M118, and we've decided that it need 
not block launch in M117 due to the low severity (especially because 
the existing reportEvent surface grants the buyer reporting worklet 
complete control over the destination URL, so the ad creative is 
already known to trust the buyer wrt where its reports get sent).


On Monday, August 28, 2023 at 11:55:39 AM UTC-4 Garrett Tanzer wrote:

Hi Daniel,

  * There are a few relevant call sites in the overall reporting
flow:
  o Declare allowlist of reporting destination origins
  + This happens in navigator.joinAdInterestGroup(), by an
ad auction buyer
  o Declare macros (key:value correspondences)
  + This happens in the buyer reporting worklet, by the
same ad auction buyer that declared the reporting
destination origins
  o Perform report to custom url
  + This happens under the auction's winning ad creative's
origin, which isn't necessarily the same as the ad
auction buyer, but it is chosen by the ad auction buyer
  * Here is the sequence of events:

1.
 1. The browser ingests and validates the allowlist when the
interest group is declared.
 2. The browser ingests the macro key:value mapping when the
auction happens. The key/value strings have no structure
that is validated. The browser adds "${" and "}" around
the user-provided keys in the macro mapping.
 3. In the ad that results from the auction:
 1. The ad sends a URL to the browser, including macros
like ${KEY}. The URL has to be a valid HTTPS url even
with the macros unsubstituted. (See impl:

https://source.chromium.org/chromium/chromium/src/+/main:content/browser/renderer_host/render_frame_host_impl.cc;l=8644?q=content%2Fbrowser%2Frenderer_host%2Frender_frame_host_impl.cc%20-f:out)
 2. The browser performs a simple string substitution to
replace the keys with the values. The implementation
is reused from navigator.deprecatedReplaceInURN,
another part of Protected Audience. It doesn't
substitute macros recursively, so you can't get an
infinite loop. deprecatedReplaceInURN has apparently
not been spec'd, which is was unable to quickly reuse
that spec and left it as a TODO for now.
 3. The origin of the resulting URL is checked against the
allowlist. If it doesn't match any of them, no action
is performed. If the URL is invalid, this will create
an opaque origin and therefore always fail the check.
(See impl:

https://source.chromium.org/chromium/chromium/src/+/main:content/browser/fenced_frame/fenced_frame_reporter.cc;l=454?q=fenced_frame_reporter.cc%20-f:out)
We may add an explicit URL valid/HTTPS check after
substitution for neatness/to be robust to any future
changes to the allowlist checking.
 4. If the URL does pass the check, a GET fetch will be
performed on it (the result is unused). There's no
other parsing/usage of the URL other than performing a
fetch.

So in summary, we were not very concerned about XSS because the
entity choosing the macro pairings is the one we want to protect,
and the entity providing the base URLs is semi-trusted. The less
trusted entity is the site of the destination URL, which just
receives a GET and doesn't get to control anything. Since the URL
has to be valid both before and after the macro substitution, this
limits how wacky the substitutions can get even if you don't trust
one of those entities. The weirdest stuff you could do would be
like "FOO}=value1&${BAR" -> "key=value2", so that it becomes
"${FOO}=value1&${BAR}" -> "key=value2". We can add a check to
exclude $,{,} characters in the macro key so even this isn't possible.

Hope this answers your questions,
Garrett

On Monday, August 28, 2023 at 9:35:34 AM UTC-4 Daniel 

Re: [blink-dev] Intent to Ship: Enrollment for Privacy Sandbox

[Mike Taylor]

Hi Shivani,

In general I think this is a pretty interesting idea, just a few minor 
questions below:


On 8/30/23 8:16 AM, Shivani Sharma wrote:



Contact emails

shivani...@chromium.org , 
georg...@google.com 



Explainer

https://github.com/privacysandbox/attestation/blob/main/README.md 




A few questions about the attestation format:

1) expiry_seconds_since_epoch implies this expires. Is there any more 
info on this? Does a renewal mean incrementing attestation_version?


2) attestation_version states "This allows the maintenance of a 
historical record of attestations." Is that something you plan on 
exposing to the public somewhere? Or would you expect a site to maintain 
previous versions somewhere?


Also, how does unenrollment happen?



Design document

https://docs.google.com/document/d/16PYa6wBBGBbV4YMujkFzBab8s4a7N4PcvpY0Js1qN1k/edit?usp=sharing 




Specification

While the enrollment process itself is not intended to be 
standardized, the impacted API specifications allow for a user agent 
defined gating mechanism such as enrollment and attestation. The spec 
changes for the gated APIs are linked below:



Private aggregation (section with note on enrollment 
) 



Shared Storage (pull request 
)


Topics (pull request 
)


Attribution reporting API (pull request 
)


Protected Audience (pull requests: 1 
, 2 
)



Summary and Motivation

As the Privacy Sandbox relevance and measurement APIs start ramping up 
for general availability, we want to make sure these technologies are 
used as intended and with transparency. The APIs include Attribution 
Reporting, the Protected Audience API, Topics, Private Aggregation and 
Shared Storage. As announced in a blog post 
, 
a new Developer Enrollment process for Privacy Sandbox relevance and 
measurement APIs is being introduced across Chrome and Android. This 
I2S refers to Chrome’s implementation of fetching the enrolled-sites 
list from the enrollment server (via component updater 
) 
and using it to gate access to the Privacy Sandbox APIs.



Blink component

Blink>PrivateAggregation 



Blink>Storage>SharedStorage 



Blink>TopicsAPI 



Internals > AttributionReporting 



Blink>InterestGroups 




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.

In the initial version, no gated APIs are supported on WebView , with 
the caveat that the Attribution Reporting API delegates from WebView 
to Android and would be gated as part of Android’s attestation based 
gating.



Debuggability


Console errors: The API surfaces gated on enrollment and
attestation will output relevant console error messages if a
given site is not allowed to participate/invoke those API
surfaces. (Private Aggregation API-related console messages
are output during its consumer API enrollment checks e.g.
Shared Storage, but could be made more specific in the future).


Is integration with the Reporting API also planned?


Local override: For local testing, we are providing developer 
overrides with a Chrome flag and CLI switch:


Flag: chrome://flags/#privacy-sandbox-enrollment-overrides

CLI: 
--privacy-sandbox-enrollment-overrides=https://example.com,https://example.co.uk,...



Initial public proposal

https://github.com/privacysandbox/attestation/blob/main/README.md 




TAG review

Private Aggregation (comment 
)


Shared Storage (comment 

Re: [blink-dev] Intent to Ship: Japanese Phrase Line Breaking

[Mike Taylor]

On 9/1/23 9:53 AM, Mike Taylor wrote:


On 9/1/23 12:59 AM, Koji Ishii wrote:



Contact emails

ko...@chromium.org


Explainer

None


Specification

https://drafts.csswg.org/css-text-4/#valdef-word-break-auto-phrase


Design docs


https://docs.google.com/document/d/1QyPza8XS4aaYD-yA1MHYx56Hy7DZuEm9cAH-A6lTu8c/edit?usp=sharing


Summary

Changes the line breaking rules for Japanese to keep natural phrases 
(of multiple words) together. In Japanese, this boundary is called 
"Bunsetu". Japanese doesn't use spaces to delimit words, and usually 
prefers to break at any characters, but short paragraphs such as 
headlines prefer breaking at natural phrase boundaries. In CSS, this 
feature adds a new value to the `word-break` property: `auto-phrase`. 
The implementation uses a C++ port of the BudouX 
<https://github.com/google/budoux>, the AdaBoost ML technology to 
determine the natural phrase boundaries.




Blink component

Blink>Layout>Inline 
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ELayout%3EInline>



TAG review

None


TAG review status

Not applicable

Any reason to not request a TAG review?

Ah, it's at https://github.com/w3ctag/design-reviews/issues/891. :)



Risks



Interoperability and Compatibility



/Gecko/: No signal

Can we request one?


/WebKit/: In development 
(https://bugs.webkit.org/show_bug.cgi?id=258668) 
https://github.com/w3c/csswg-drafts/issues/7193#issuecomment-1586696215


/Web developers/: Positive (https://github.com/google/budoux) The 
original JS/Python implementation has 970 stars and is already used 
by several sites <https://github.com/google/budoux> A demo tweet 
<https://twitter.com/kojiishi/status/1687688315896733696> and its 
retweets <https://twitter.com/tushuhei/status/1693544644167266403> 
has 100 likes.


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



Debuggability



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

<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?

Yes


Flag name on chrome://flags



Finch feature name



Non-finch justification

None


Requires code in //chrome?

False


Tracking bug

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


Sample links


https://github.com/google/budoux
https://google.github.io/budoux
https://twitter.com/kojiishi/status/1687688315896733696


Estimated milestones

Shipping on desktop 119

Shipping on Android 119

Shipping on WebView 119



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




Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5133892532568064


Links to previous Intent discussions

Intent to prototype: 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHe_1dJBouY10zVrouYbpGnokj65Jz4Qjuh3UMcS477u2Q9uqw%40mail.gmail.com


This intent message was generated by Chrome Platform Status 
<https://chromestatus.com/>.

--
You received this message because you are subscribed to the Google 
Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, 
send an email to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHe_1dKEQhh-Fa7WG_RWed8-ST74Oy_6KvwLnkKpwyau54fRAQ%40mail.gmail.com 
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHe_1dKEQhh-Fa7WG_RWed8-ST74Oy_6KvwLnkKpwyau54fRAQ%40mail.gmail.com?utm_medium=email_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/0370c424-2c15-4045-84fb-d7025781b446%40chromium.org.

Re: [blink-dev] Intent to Ship: Japanese Phrase Line Breaking

[Mike Taylor]

On 9/1/23 12:59 AM, Koji Ishii wrote:



Contact emails

ko...@chromium.org


Explainer

None


Specification

https://drafts.csswg.org/css-text-4/#valdef-word-break-auto-phrase


Design docs


https://docs.google.com/document/d/1QyPza8XS4aaYD-yA1MHYx56Hy7DZuEm9cAH-A6lTu8c/edit?usp=sharing


Summary

Changes the line breaking rules for Japanese to keep natural phrases 
(of multiple words) together. In Japanese, this boundary is called 
"Bunsetu". Japanese doesn't use spaces to delimit words, and usually 
prefers to break at any characters, but short paragraphs such as 
headlines prefer breaking at natural phrase boundaries. In CSS, this 
feature adds a new value to the `word-break` property: `auto-phrase`. 
The implementation uses a C++ port of the BudouX 
, the AdaBoost ML technology to 
determine the natural phrase boundaries.




Blink component

Blink>Layout>Inline 




TAG review

None


TAG review status

Not applicable

Any reason to not request a TAG review?



Risks



Interoperability and Compatibility



/Gecko/: No signal

Can we request one?


/WebKit/: In development 
(https://bugs.webkit.org/show_bug.cgi?id=258668) 
https://github.com/w3c/csswg-drafts/issues/7193#issuecomment-1586696215


/Web developers/: Positive (https://github.com/google/budoux) The 
original JS/Python implementation has 970 stars and is already used by 
several sites  A demo tweet 
 and its 
retweets  has 
100 likes.


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



Debuggability



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://flags



Finch feature name



Non-finch justification

None


Requires code in //chrome?

False


Tracking bug

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


Sample links


https://github.com/google/budoux
https://google.github.io/budoux
https://twitter.com/kojiishi/status/1687688315896733696


Estimated milestones

Shipping on desktop 119

Shipping on Android 119

Shipping on WebView 119



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




Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5133892532568064


Links to previous Intent discussions

Intent to prototype: 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHe_1dJBouY10zVrouYbpGnokj65Jz4Qjuh3UMcS477u2Q9uqw%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/CAHe_1dKEQhh-Fa7WG_RWed8-ST74Oy_6KvwLnkKpwyau54fRAQ%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/1a675bf6-81e9-4b29-be81-3eb3a2567e38%40chromium.org.

Re: [blink-dev] Intent to Experiment: Tabbed web apps

[Mike Taylor]

No issues, thanks for the update.

On 8/31/23 11:16 PM, 'Louise Brett' via blink-dev wrote:
We aren't ready to start the origin trial in M117 so we are going to 
run it from M118-123 (inclusive).


On Wednesday, July 26, 2023 at 1:19:33 PM UTC+10 Matt Giuca wrote:

@Šime: Yes, the feature as currently implemented is exposed as a
media query: "(display-mode: tabbed)" works.

We flagged additionally the need to be able to detect
whether you're in the special home tab. I'm not sure how you do
that (whether it's a media query or some other way) and it isn't
mentioned in the explainer

.
Perhaps Louise can explain (out until next week) if there is a way
to do it. However, I checked the basic detection of "am I in
tabbed mode" works with a media query.

On Mon, 24 Jul 2023 at 20:25, Thomas Steiner  wrote:

On Mon, Jul 24, 2023 at 01:04 Šime Vidas 
wrote:

Is it available in CSS media queries?

@media (display-mode: tabbed) { ... }


I have opened https://github.com/w3c/manifest/issues/952 where
the same request is made for all overrides.



On Wednesday, July 19, 2023 at 9:50:44 AM UTC+2
yoav...@chromium.org wrote:

LGTM to experiment M116-122 (inclusive)

On Wed, Jul 19, 2023 at 8:14 AM 'Louise Brett' via
blink-dev  wrote:


Contact emails

loub...@google.com, alanc...@chromium.org,
gle...@chromium.org, mgi...@chromium.org



Explainer


https://github.com/WICG/manifest-incubations/blob/gh-pages/tabbed-mode-explainer.md


Specification

None


Summary

Allow web app windows to have a tab strip. This
adds a new display mode "tabbed" and a new
manifest field to allow customizations to the tab
strip.



Blink component

Blink>AppManifest




TAG review

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


TAG review status

Pending


Risks



Interoperability and Compatibility



/Gecko/: Defer
(https://github.com/mozilla/standards-positions/issues/811)

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

/Web developers/: Positive
(https://github.com/w3c/manifest/issues/737)

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

N/A. This feature is not supported on WebView so
we will fallback to a supported display mode.



Goals for experimentation

Gather feedback on the API design.


Ongoing technical constraints



Debuggability

chrome://web-app-internals can be used for
debugging, and the new manifest field could also
be added to the DevTools Application pane.



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

No. Initially this will only be available on
ChromeOS, but will be expanded to other desktop
platforms in the future.


Is this feature fully tested by
web-platform-tests

?

No


Flag name on chrome://flags

chrome://flags/#enable-desktop-pwas-tab-strip
chrome://flags/#enable-desktop-pwas-tab-strip-customizations


Finch feature name

None


Non-finch justification

None


Requires code in //chrome?

True


Tracking bug

Re: [blink-dev] Intent to Prototype: form-sizing CSS property

[Mike Taylor]

On 8/31/23 7:52 PM, TAMURA, Kent wrote:



Contact emails

tk...@chromium.org, ikilpatr...@chromium.org


Explainer

https://github.com/tkent-google/explainers/blob/main/form-sizing.md


Specification

https://github.com/w3c/csswg-drafts/pull/9251


Design docs

N/A


Summary

By 'form-sizing' property, web authors can disable fixed default sizes 
of form controls, and make their size depend on their content. It's 
very easy to provide automatically-growing text fields.




Blink component

Blink>Layout 




Motivation

None



Initial public proposal

None


Search tags

css , forms 
, form-sizing 




TAG review

https://github.com/w3ctag/design-reviews/issues/883
https://github.com/w3ctag/design-reviews/issues/890 seems to be the 
correct link.



TAG review status

Issue open


Risks



Interoperability and Compatibility



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


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


/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

?

Yes, it should be.


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=1447058


Estimated milestones

No milestones specified



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5176596826161152

This intent message was generated by Chrome Platform Status 
.


--
TAMURA Kent
Software Engineer, Google


--
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/CAGH7WqF9x271V96TMM3YNumzawv%3DC9i30BeW2trNO_%2Bk7O4%2BAg%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/01012c98-0a82-4806-b238-2a0984dd9a3e%40chromium.org.

Re: [blink-dev] PSA: Disallowing unknown import attributes keys

[Mike Taylor]

Thanks - please do (and please follow up in this thread if things go 
sideways). Good luck!


On 8/29/23 9:34 AM, Nicolò Ribaudo wrote:


Hi,

I did not plan to implement it with a flag, but adding a killswitch 
just to be safe in case it turns out not to be web-compatible is easy 
to do.


On 28/08/23 17:23, Mike Taylor wrote:


On 8/28/23 5:33 AM, Nicolò Ribaudo wrote:


Hello,

we are implementing a breaking change to Chromium's import 
attributes implementation.


The import attributes proposal 
(https://tc39.es/proposal-import-attributes/, previously known as 
"import assertions") was recently updated to throw on unknown 
attribute keys, rather than ignoring them. Currently the only valid 
attribute is "type", defined by the HTML specification (for JSON and 
CSS imports) and by https://tc39.es/proposal-json-modules/.


The previous version of this proposal has been implemented in 
Chromium for two years, and we are now updating to the new semantics.


While this is technically a breaking change, the compatibility risk 
is very low:
- The upper bound of import attributes usage is 
https://chromestatus.com/metrics/feature/timeline/popularity/4528.
- None of the top websites listed in the link above uses unknown 
attributes.
- No tool implemented attributes other than "type" (other than 
TypeScript's "resolution-mode", which is only valid when using the 
TS-specific import type syntax), so it's unlikely that somebody is 
shipping unknown attributes thinking that they are being compiled 
away by some tool.
- A typo in type would already result in an error, since type is 
only used for CSS imports and it's mandatory.
- Of the 9.6k results on GitHub for import assertions usage 
(/import.*assert\s*\{/ 
<https://github.com/search?q=+language%3AJavaScript+%2Fimport.*assert%5Cs*%5C%7B%2F=code>), 
only 4 Node.js projects use an unknown "integrity" one (found by 
manually analyzing the results for 
/import.*assert\s*\{.*[^\s"'type].*:.*\}/ 
<https://github.com/search?q=+language%3AJavaScript+%2Fimport.*assert%5Cs*%5C%7B.*%5B%5E%5Cs%22%27type%5D.*%3A.*%5C%7D%2F=code>). 
Most of the results with unknown attributes are tests for various 
parsers or implementations.


I searched for "sha384-abc123" instead 
<https://github.com/search?q=sha384-ABC123=code=1>, and found 
10 Node projects using this integrity key with seemingly copypasta 
sha384-abc123. It seems like your search regexp doesn't account for 
keys on new lines (probably possible w/ github search?). Maybe worth 
double checking to see if nothing new pops up.


(Also, might be nice to file issues and let folks know their projects 
are going to break, especially if the number is this small.)




As such, this change is safe to ship.
Are you implementing behind a feature flag, in case it turns out to 
not be safe?


You can find the ChromeStatus entry at 
https://chromestatus.com/feature/5123137502445568.


Thanks,
Nicolò Ribaudo

--
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/192d117b-b2b9-4835-a6bd-bf5e49b64757n%40chromium.org 
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/192d117b-b2b9-4835-a6bd-bf5e49b64757n%40chromium.org?utm_medium=email_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/f24f5848-cc65-4384-afea-070506c62791%40chromium.org.

Re: [blink-dev] Re: Intent to Ship: Bounce Tracking Mitigations

[Mike Taylor]

LGTM1 to ship, as long as we fast follow with doing the work to define 
and ship webdriver extensions in order to make this testable in WPT.


(I don't think your team should be blocked on shipping because other 
browsers who already shipped the feature didn't do that work.)


On 8/21/23 3:44 PM, Christian Biesinger wrote:

On Mon, Aug 21, 2023 at 3:25 PM Ben Kelly  wrote:



On Mon, Aug 21, 2023 at 11:38 AM Mike Taylor  wrote:

On 8/21/23 11:09 AM, Ben Kelly wrote:

On Sun, Aug 20, 2023 at 11:27 PM Yoav Weiss  wrote:

Thanks for working on this important problem!

On Thu, Aug 17, 2023 at 9:28 PM Ben Kelly  wrote:

Sorry, it seems I left off the signals section of the template:

Firefox: No signal (https://github.com/mozilla/standards-positions/issues/835)


Firefox folks seem tentatively supportive, but have WPT questions. Can you 
address them?


I'm checking without our WPT folks to try to understand what mozilla is 
suggesting.  I'm not familiar with web-driver functions at all, so not quite 
sure yet how feasible this is.

My read on bvandersloot's comment is that he's asking for a less generic 
version https://github.com/web-platform-tests/wpt/issues/17489 to make this 
testable (which you've already linked below). Exposing endpoints for advancing 
time seems to have more use cases than bounce tracking-specific webdriver 
endpoints, IMHO - but that's a discussion that should probably happen in the 
relevant WG.

See https://github.com/web-platform-tests/rfcs for the process to propose 
extending the testdriver.js API to expose... but I think you'll want to get the 
relevant concepts added to the webdriver spec first (seems possible, if Mozilla 
if supportive). The other option would be to something similar to FedCM by 
adding webdriver extension commands (see spec PR here: 
https://github.com/fedidcg/FedCM/pull/465/files).

I personally wouldn't recommend blocking on this work, but it seems useful for 
someone to pursue as good first bugs for folks interested in standards and WPT 
internals. Note that additions to WebDriver now require going through the 
Intent process (great news for folks interested in learning this process, 
presumably they exist!).


Andrew Williams also helpfully pointed out a bunch of code source references to 
me for this.  I filed crbug.com/1474656 to do this work.

I think this is definitely something we will do, but it may take a milestone or 
two to get it done.  In particular, I'm unsure if there will be pushback to 
modifying the web-driver functions for a bounce tracking mitigations-specific 
feature.

Lots of specs define webdriver extensions, that should not be a problem. E.g.:
https://fedidcg.github.io/FedCM/#automation
https://w3c.github.io/secure-payment-confirmation/#sctn-automation
https://w3c.github.io/webauthn/#sctn-automation-virtual-authenticators

Note that you have to implement the commands twice, once for Chrome's
bots and once for upstream wpt.fyi and general UA automation uses.
Chrome's impl does not really use webdriver, it usually just calls a
function on internals (e.g.
https://chromium-review.googlesource.com/c/chromium/src/+/4740672/6/third_party/blink/web_tests/resources/testdriver-vendor.js)

The second impl is in Chromedriver, likely using CDP, e.g.:
https://chromium-review.googlesource.com/c/chromium/src/+/4281897
plus
https://chromium-review.googlesource.com/c/chromium/src/+/4402971

Christian


I don't think we want to take on the general purpose clock modification change 
to web-driver, though.  That seems like a much larger scope.






Webkit: No signal (https://github.com/WebKit/standards-positions/issues/214)
Web developers: No signals

On Thu, Aug 17, 2023 at 10:22 AM Ben Kelly  wrote:

Contact emails

wanderv...@chromium.org, b...@chromium.org, rtarp...@chromium.org, 
j...@chromium.org


Explainer

https://github.com/privacycg/nav-tracking-mitigations/blob/main/bounce-tracking-explainer.md


Specification

https://privacycg.github.io/nav-tracking-mitigations/#bounce-tracking-mitigations


Summary

This feature mitigates bounce tracking on the web.  It works by deleting state 
from sites that access storage during a redirect that the user has never 
directly interacted with.  See the specification for more details.


Blink component

Privacy>NavTracking


TAG review

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


TAG review status

Issues addressed


Risks


Interoperability and Compatibility

The main risk is that we will incorrectly delete state for a site that the user 
needs to continue functioning.  Our approach attempts to address this with a 
number of signals:


If a user has interacted with the site within the last 45 days, we will not 
delete its state.

We are adding successful webauthn key assertions as another "interaction" 
source in M117 to address SSO use cases that only require security taps to stay logged in.

We only delete state if the potential tracking site is not permitted as a 3P 
cookie.

Re: [blink-dev] Intent to Ship: :user-valid and :user-invalid CSS pseudo-classes

[Mike Taylor]

I see that https://drafts.csswg.org/selectors-4/#issue-df919919 states 
that this and the :invalid/:valid flavors should apply to forms and 
fieldset elements. It doesn't look like the WPTs test for that - what do 
we do for those elements, and do you know if it's interoperable?


On 8/28/23 11:54 AM, PhistucK wrote:

Thank you!

☆*PhistucK*


On Mon, Aug 28, 2023 at 4:46 PM Joey Arhar  wrote:

I filed a bug here:
https://bugs.chromium.org/p/chromium/issues/detail?id=1476503

On Sat, Aug 26, 2023 at 4:04 PM PhistucK  wrote:

Yeah, it was just a thought, maybe any new pseudo-class should
automatically be added.

☆*PhistucK*


On Sat, Aug 26, 2023 at 10:26 PM Mason Freed
 wrote:



On Saturday, August 26, 2023 at 10:31:30 AM UTC-7 PhistucK
wrote:

I guess all of them would be good. Not really why only
a few pseudo-classes are listed there...


This sounds like a great feature request for devtools in
general. I wonder if we could separate it out from
shipping this one set of 2 pseudo classes though?


☆*PhistucK*


On Sat, Aug 26, 2023 at 6:18 PM Joey Arhar
 wrote:

Sure I can try setting up the force element state
feature for it.

> along with other form-related ones

Any ones you have in mind? I could try to do them
all at once

On Sat, Aug 26, 2023 at 10:00 AM PhistucK
 wrote:

Sounds good!

> Debuggability

> These new pseudo-classes will be supported by
the DevTools styles sidebar automatically,
just like every other pseudo-class.


Can it (along with other form-related ones, I
guess) be added to the list of toggle-able
pseudo classes (shown when you click on the
":hov" button)?

image.png



☆*PhistucK*


On Sat, Aug 26, 2023 at 9:14 AM Joey Arhar
 wrote:

Contact emailsjar...@chromium.org

ExplainerNone


Specificationhttps://drafts.csswg.org/selectors-4/#user-pseudos


Summary

The :user-invalid and the :user-valid
pseudo-classes represent an element with
incorrect or correct input, respectively,
but only after the user has significantly
interacted with it. This is similar to
:valid and :invalid, but with the added
constraint that these pseudo-classes only
match after the user has interacted with
the element.



Blink componentBlink>CSS



TAG reviewNone

TAG review statusNot applicable

Risks


Interoperability and Compatibility

There is no interop/compat risks because
this is a new feature that has already
been implemented by safari and firefox and
has WPTs.



/Gecko/: Shipped/Shipping

/WebKit/: Shipped/Shipping

/Web developers/: No signals

/Other signals/:

Ergonomics

This feature will not be used in tandem
with other platform APIs. The default
usage of this API will not make it hard
for chrome to maintain good performance.



Activation

It will not be challenging for developers
to use this feature immediately. There is
already an MDN article for this feature,
so I don't think that we need additional
outreach.



Security

There are no security risks for this feature.



WebView application risks

Does this intent deprecate or change
  

Re: [blink-dev] PSA: Disallowing unknown import attributes keys

[Mike Taylor]

On 8/28/23 5:33 AM, Nicolò Ribaudo wrote:


Hello,

we are implementing a breaking change to Chromium's import attributes 
implementation.


The import attributes proposal 
(https://tc39.es/proposal-import-attributes/, previously known as 
"import assertions") was recently updated to throw on unknown 
attribute keys, rather than ignoring them. Currently the only valid 
attribute is "type", defined by the HTML specification (for JSON and 
CSS imports) and by https://tc39.es/proposal-json-modules/.


The previous version of this proposal has been implemented in Chromium 
for two years, and we are now updating to the new semantics.


While this is technically a breaking change, the compatibility risk is 
very low:
- The upper bound of import attributes usage is 
https://chromestatus.com/metrics/feature/timeline/popularity/4528.
- None of the top websites listed in the link above uses unknown 
attributes.
- No tool implemented attributes other than "type" (other than 
TypeScript's "resolution-mode", which is only valid when using the 
TS-specific import type syntax), so it's unlikely that somebody is 
shipping unknown attributes thinking that they are being compiled away 
by some tool.
- A typo in type would already result in an error, since type is only 
used for CSS imports and it's mandatory.
- Of the 9.6k results on GitHub for import assertions usage 
(/import.*assert\s*\{/ 
), 
only 4 Node.js projects use an unknown "integrity" one (found by 
manually analyzing the results for 
/import.*assert\s*\{.*[^\s"'type].*:.*\}/ 
). 
Most of the results with unknown attributes are tests for various 
parsers or implementations.


I searched for "sha384-abc123" instead 
, and found 10 
Node projects using this integrity key with seemingly copypasta 
sha384-abc123. It seems like your search regexp doesn't account for keys 
on new lines (probably possible w/ github search?). Maybe worth double 
checking to see if nothing new pops up.


(Also, might be nice to file issues and let folks know their projects 
are going to break, especially if the number is this small.)




As such, this change is safe to ship.
Are you implementing behind a feature flag, in case it turns out to not 
be safe?


You can find the ChromeStatus entry at 
https://chromestatus.com/feature/5123137502445568.


Thanks,
Nicolò Ribaudo

--
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/192d117b-b2b9-4835-a6bd-bf5e49b64757n%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/a2130ab4-28ef-4b94-b7cb-f78ef9c16b15%40chromium.org.

Re: [blink-dev] Intent to Ship: view-timeline shorthand sets view-timeline-inset

[Mike Taylor]

LGTM3

On 8/23/23 12:22 PM, Chris Harrelson wrote:

LGMT2

On Wed, Aug 23, 2023 at 9:01 AM Yoav Weiss  wrote:

LGTM1

On Wed, Aug 23, 2023 at 5:26 PM Anders Hartvoll Ruud
 wrote:



On Wed, Aug 23, 2023 at 3:23 PM Yoav Weiss
 wrote:



On Wed, Aug 23, 2023 at 2:46 PM Anders Hartvoll Ruud
 wrote:


Contact emails


*

andr...@chromium.org


*


Specification


*

https://github.com/w3c/csswg-drafts/issues/8926



*


Summary


*

The view-timelineshorthand is now a shorthand
for view-timeline-name, view-timeline-axis,
and view-timeline-inset. Previously,
view-timeline-insetwas not part of the shorthand.


This can theoretically be a problem if CSS
like this exists:


div {

  view-timeline-inset: 10px;

  view-timeline: mytimeline;

}


Currently, view-timeline(appearing later)
would not interfere with
view-timeline-insetabove, whereas with this
change the view-timelinedeclaration sets
view-timeline-insetto its initial value.


Use-counters:

 *

view-timeline: ~0.015%



 *

view-timeline-inset: ~0.019%



 *

No sample sites at the time of writing.


However, for this to be a problem, a site
needs to use bothview-timelineand
view-timeline-inset. A HTTP Archive search [1]
which looks for sites using both shows only 12
hits:


1 https://store.marketwatch.com/

2 https://www.inbank.it/

3 https://store.thetimes.ie/

4 https://www.heraldsun.com.au/

5 https://www.gameort.com/

6 https://globalstore.thetimes.co.uk/

7 https://assinaturaglobo.globo.com/

8 https://mobile.thestar.com/

9 https://readerschoice.thestar.com/

10 https://sourcingjournal.com/

11 https://ontario-doctors.thestar.com/

12 http://fashion.telegraph.co.uk/


However, I can’t find any sign that these
sites use view-timeline-[inset]from checking
manually.


If problems do appear, it can be fixed easily
by e.g. using
view-timeline-name/view-timeline-axisinstead
of view-timeline, or re-ordering the
declarations such that
view-timeline-insetcomes after.



*


Blink component


*

Blink>Animation




*


TAG review


*

None


*


TAG review status


*

Not applicable


*


Risks


*

*


Interoperability and Compatibility


*

None



Gecko: No signal


WebKit: No signal

*



Are we the first to implement this spec change?


Yes. Only Chrome has shipped view-timeline at all so far.

I think this doesn't warrant a full-fledged standards
position, but can we extract signals from the CSSWG minutes?


It was resolved without much discussion.
https://log.csswg.org/irc.w3.org/css/2023-07-21/#e1557343

Can't really extract affirmative signals from the notes,
although for this 

Re: [blink-dev] Intent to Prototype and Ship: Generic Sensor WebDriver endpoints

[Mike Taylor]

LGTM1

On 8/23/23 2:11 PM, Mathias Bynens wrote:

Thank you for the detailed explanation. Proceeding as you described SGTM.

On Wed, Aug 23, 2023 at 7:41 PM Raphael Kubo da Costa 
 wrote:


Thanks, Mathias.

Mathias Bynens  writes:
> Question 1: Are they supportive of the Generic Sensor API?

Officially, no. It has been quite a while since we last asked them
though.

See the discussion with Mozilla here:
- https://github.com/mozilla/standards-positions/issues/35
and their corresponding standards position here:
- https://mozilla.github.io/standards-positions/#generic-sensor

WebKit didn't have a standards position tracker back then, but
they did
comment on the Mozilla issue above:
-

https://github.com/mozilla/standards-positions/issues/35#issuecomment-718365969

We've been trying to address the concerns in the Devices and
Sensors WG
over the years and this will probably come up in some form at TPAC as
well.

With that said...

> Question 2: Have they provided any signals on the proposed
automation
> endpoint?

I have not asked them given the above (and Apple is not part of
the WG,
so it's also hard to ask for feedback on any specifics of the new
text).
Personally, I'd like to do a few things before discussing this API
with
WebKit and Mozilla again:
- Land these automation changes to remove the semi-dependency on Mojo
  from the web tests so that it's a lot easier for other
implementations
  to test their code.
- Sort out any permission-related issues the spec might have (although
  this is more of an implementation issue, with the Generic
Sensors and
  Device Orientation APIs in Blink not asking for permission by
default
  at the moment).
- Figure out if the Device Orientation spec (which all engines
  implement) itself needs to be more tightly coupled with the Generic
  Sensor API, at least for automation, for it to be testable in an
  interoperable way.

--
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/CADizRgYkZ%3DH3qe8DKZdcm1bLqYnGCLFpyX%3DCBGCV%3DmTWG3EJZg%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/eb91049c-9d0f-44a2-bb4c-9987b12d34b0%40chromium.org.

Re: [blink-dev] Intent to Ship: Partitioning Storage, Service Workers, and Communication APIs

[Mike Taylor]

Yes, if you sign up for a 3rd party token and inject that into the site 
embedding your iframe before your iframe is created, that will give you 
access to unpartitioned storage (until the Deprecation Trial expires).


Here's a demo that injects an 3P origin trial token then creates an iframe:

https://rogue-lace-join.glitch.me/

And the relevant source files:

https://glitch.com/edit/#!/rogue-lace-join?path=index.html%3A9%3A8
https://miketaylr.com/misc/3pspdt.js

Feel free to reach out to me off-list to discuss more or if you have any 
further questions.


On 8/22/23 11:40 PM, Yoav Weiss wrote:
Is your application running script in the top level context? Since the 
deprecation trial is implemented as a third-party origin trial, you 
may be able to sign up as a third party.


On Tue, Aug 22, 2023, 23:48 Junji Genesys  wrote:

Hello Kyra,

Thank you for communicating about the rollout plan for the storage
partitioning.

We've found that the new storage partitioning behavior has
impacted our product, which is a web client application embedded
in an iframe inside Salesforce and provides call center agents
functionality such as handling phone calls. We use browser-based
phone (WebRTC phone) that can pop out as a separate window, which
communicates with the embedded client frame via localStorage and
BroadcastChannel. The new storage partitioning restriction blocks
this communication as our application is running as an embedded
iframe with a top-level domain that differs from our browser phone
running in a popped out window. Our browser phone does not work
properly in that scenario, and as a result, users are not able to
answer their calls. Many of our customers have started reporting
this issue, and it is currently our top priority to address this
issue given its time-sensitive nature.

We've also learned about an existence of the experimental flag,
two relevant enterprise policies and the deprecation trial for
disabling this new change as a temporary measure. We're especially
interested in the deprecation trial, but that can be activated
only by the top-level domain site and there is no way for the
embedded content in an iframe to activate the deprecation trial.

I've contacted Salesforce support to see if they can sign-up and
activate the deprecation trial, but they asked me to reach out to
Chrome team to see if Chrome team can create a ticket with
Salesforce and help them with the deprecation trial for
unpartitioned third-party storage.

Would you be able to work with Salesforce for the deprecation
trial in their environment?
Also, since you might have dealt with other third-party vendors
before, what suggestions do you have on how to approach a
situation like this?
I greatly appreciate your prompt response and help on this matter.

Thank you,

Junji

On Monday, August 14, 2023 at 1:50:24 PM UTC-4 Kyra Seevers wrote:

Hi all,

Quick update: we began the rollout to 10% stable today.

The new rollout schedule is approximately:
Stable 50%: Aug 28th
Stable 100%: Sept 11th

On Wed, Aug 2, 2023 at 11:18 AM Tim Williams
 wrote:

Hey Mike,
Thanks for the update!
I totally understand your timing, and it's on us to blame
for missing this out (or at least we thought that it would
be together with the cookie update which was postponed
several times).

Anyway, I encourage you to postpone the timing until the
trial bug will be fixed to enable us, and other developers
who would like to use the trial meta tag to be able to do so.

Thanks!

On Monday, July 31, 2023 at 7:55:33 PM UTC+3 Mike Taylor
wrote:

Thanks for the bug report! We'll triage it in our
regular meeting tomorrow.

And yes, your understanding of the timing is correct
(we've been working on this project for 2+ years

<https://groups.google.com/a/chromium.org/g/blink-dev/c/WXNzM0WiQ-s/m/l10NGhaoAQAJ>,
and in dev-trial since September

<https://developer.chrome.com/en/blog/storage-partitioning-dev-trial/>
of last year). Note that advancing to a higher
percentage will depend on the stability and
web-compatibility of partitioned 3P storage.

thanks,
Mike

On 7/30/23 12:04 PM, Tim Williams wrote:

I've submitted the following bug:
https://bugs.chromium.org/p/chromium/issues/detail?id=1468811
since the trial isn't working while I did everything
right.

On Saturday, July 29, 2023 at 2:52:22 AM UTC+3 Tim
Wi

Re: [blink-dev] Intent to Ship: Storage Access API with Prompts

[Mike Taylor]

s
have different lifetimes in different
browsers, so web developers may have to
show a prompt more often than they expect:

1.

Firefox: 30 calendar days.

2.

Chrome: 30 calendar days.

3.

Safari: 30 days of browser usage.

2.

User interaction requirement. Whether a
user gesture is required by
document.requestStorageAccess() is
inconsistent across browsers:

1.

Firefox: always requires user
interaction. (This is a nonstandard
behavior, but it appears Firefox is
being updated

<https://phabricator.services.mozilla.com/D183175>to
not require user interaction in some
cases.)

2.

Chrome: requires user interaction
unless the user has already granted
access.

3.

Safari: always

<https://github.com/privacycg/storage-access/issues/172#issuecomment-1521653447>requires
user interaction. (This is a
nonstandard behavior.)


Since Firefox and Safari currently impose
stricter user interaction requirements than
what the spec dictates, this could lead to
compat issues if web developers assume that
browsers don't impose additional
browser-specific constraints.

There's one additional aspect, where web
developers may not need to call
document.requestStorageAccess() at all in
certain situations in some browsers (which
could lead to broken experiences if web
developers assume they can always omit the
explicit call):

  * Firefox: if foo.example has obtained
storage access while embedded under
bar.example, and the user loads a
bar.example page that includes a
foo.example iframe, then that iframe will
load with implicit storage access --
without having to call
document.requestStorageAccess() first.
(This is a deviation from the
specification, but this part of the spec
was changed relatively recently

<https://github.com/privacycg/storage-access/issues/113>
for security reasons; Firefox is planning

<https://bugzilla.mozilla.org/show_bug.cgi?id=1837648> to
incorporate the recent changes.)

Chris
    On Wednesday, August 2, 2023 at 5:02:35 PM
UTC-4 Mike Taylor wrote:


On 8/2/23 4:47 PM, Chris Fredrickson wrote:

Contact emails

cfred...@chromium.org,
johann...@chromium.org, shuu...@chromium.org


Explainer


https://github.com/privacycg/storage-access/blob/main/README.md

<https://github.com/privacycg/storage-access/blob/main/README.md>


https://github.com/cfredric/chrome-storage-access-api/blob/main/README.md

<https://github.com/cfredric/chrome-storage-access-api/blob/main/README.md>


Specification

https://privacycg.github.io/storage-access
<https://privacycg.github.io/storage-access>


Summary

The Storage Access API provides a means
for authenticated cross-site embeds to
check whether access to unpartitioned
cookies is blocked and request access if
it is blocked. This request may be
 

Re: [blink-dev] Intent to Ship: Opaque Response Blocking (ORB, aka CORB++) v0.2

[Mike Taylor]

LGTM3

On 8/22/23 10:37 AM, Yoav Weiss wrote:

LGTM2

On Wed, Aug 16, 2023 at 7:23 PM Chris Harrelson 
 wrote:


LGTM1 to turn it on in M118 beta and report back to this group
about use counter results/bugs reported on beta before it reaches
stable.

On Fri, Aug 11, 2023 at 2:50 AM 'Daniel Vogelheim' via blink-dev
 wrote:

On Wed, Jul 26, 2023 at 11:29 AM Yoav Weiss
 wrote:

On Tue, Jul 25, 2023 at 6:48 PM Daniel Vogelheim
 wrote:

On Tue, Jul 25, 2023 at 9:10 AM Yoav Weiss
 wrote:

On Mon, Jul 24, 2023 at 7:27 PM Daniel Vogelheim
 wrote:

On Mon, Jul 24, 2023 at 5:55 PM Yoav Weiss
 wrote:

On Mon, Jul 24, 2023 at 5:44 PM Daniel
Vogelheim  wrote:

On Mon, Jul 24, 2023 at 5:24 PM Yoav
Weiss  wrote:

On Fri, Jul 21, 2023 at 5:53 PM
'Daniel Vogelheim' via blink-dev
 wrote:


Contact emails

vogelh...@chromium.org


Specification


https://github.com/whatwg/fetch/pull/1442


Summary

Opaque Response Blocking (ORB)
is a replacement for
Cross-Origin Read Blocking
(CORB -

https://chromestatus.com/feature/5629709824032768).
CORB and ORB are both
heuristics that attempt to
prevent cross-origin
disclosure of “no-cors”
subresources. This entry
tracks "v0.2" of ORB -
Chrome's second step towards a
full ORB implementation. ORB
specifies error handling for
blocked resources differently
from CORB: ORB raises network
errors, while CORB injects an
empty response. ORB "v0.1"
still used CORB-style response
injection. This change brings
our implementation more in
line with the ORB proposal, by
changing the error handling of
all fetches (except when
initiated by a script) to be
compliant with ORB. We've made
a carve-out for
script-initiated fetches
(where we retain CORB
behaviour for now) to limit
compatibility risk.



Blink component

Internals>Sandbox>SiteIsolation




TAG review

None
(A TAG review of a particular
aspect happened

in:https://github.com/w3ctag/design-reviews/issues/618)


TAG review status

Not applicable


Risks


Interoperability and
Compatibility

This release does not modify
blocking behaviour, but only
how a blocked resource is
represented. Ideally, this
change shouldn't break any
existing code since any
resource that loads (or gets

Re: [blink-dev] Intent to Ship: HTML search element

[Mike Taylor]

LGTM2

On 8/22/23 10:29 AM, Yoav Weiss wrote:

LGTM1

Thanks for catching us up here! :)


On Thu, Aug 17, 2023 at 5:31 AM Vladimir Levin  
wrote:




On Wed, Aug 16, 2023 at 4:37 PM Joey Arhar 
wrote:


Contact emails

jar...@chromium.org


Explainer

None


Specification


https://html.spec.whatwg.org/multipage/grouping-content.html#the-search-element


Summary

The  element applies a "search" role for
accessibility. It is basically the same as .
From the HTML spec: The search element represents a part of a
document or application that contains a set of form controls
or other content related to performing a search or filtering
operation. This could be a search of the web site or
application; a way of searching or filtering search results on
the current web page; or a global or Internet-wide search
function.



Blink component

Blink>HTML




TAG review

None


TAG review status

Not applicable


FYI, there has already been a (satisfied with concerns) TAG review
for this: https://github.com/w3ctag/design-reviews/issues/714



Risks



Interoperability and Compatibility

There is minimal compat risk for this. Even if a website is
erroneously already using  tags, there likely won't be
any difference in behavior.



/Gecko/: Shipped/Shipping
(https://bugzilla.mozilla.org/show_bug.cgi?id=1824121)

/WebKit/: Shipped/Shipping
(https://github.com/WebKit/WebKit/pull/13887)

/Web developers/: No signals

/Other signals/:


Ergonomics

There are no other platform APIs this feature will be used in
tandem with. The default usage of this API will not make it
hard for chrome to maintain good performance.



Activation

It will not be challenging for developers to take advantage of
this feature immediately. I don't think that
polyfills/documentation/outreach is needed for this feature.



Security

This feature does not have any security or privacy implications.



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 has no risk for WebView.



Debuggability

The DevTools accessibility panel will show the new
accessibility role associated with search elements.



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://flags

HTMLSearchElement


Finch feature name

HTMLSearchElement


Requires code in //chrome?

False


Tracking bug

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


Availability expectation

This feature has already been implemented in firefox and
webkit, so it will be available immediately.


Adoption expectation

This feature has already been implemented in firefox and
webkit, so it will be available immediately.


Adoption plan

No actions are needed because this feature has already shipped
in firefox and safari.


Estimated milestones

Shipping on desktop 118
DevTrial on desktop 118

Shipping on Android 118
DevTrial on Android 118

Shipping on WebView 118



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

There are no open spec issues for the search element.


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5126108151808000

This intent message was generated by Chrome Platform Status
.
-- 
You received this message because you are subscribed to the

Google Groups 

Re: [blink-dev] Intent to Implement & Ship: AudioEncoderConfig.bitrateMode

[Mike Taylor]

LGTM2

On 8/22/23 10:10 AM, Yoav Weiss wrote:
LGTM1. Mirroring video codecs makes sense. Glad to see Mozilla being 
supportive.


On Thu, Aug 17, 2023 at 8:51 PM 'Thomas Guilbert' via blink-dev 
 wrote:


Contact emails

tguilb...@google.com


Explainer

None


Specification

https://w3c.github.io/webcodecs/#dom-audioencoderconfig-bitratemode




Summary


Some audio codecs support specifying the audio encoder bitrate
modes. This feature adds a "bitrateMode" flag with a default value
of “variable” to WebCodec's AudioEncoderConfig, which mirrors the
functionality already present for VideoEncoderConfig
.


This flag will allow web authors to choose between encoding audio
with a variable bitrate or a constant bitrate. Specific codec
encoder implementations might have slightly different terminology
(e.g. `CBR` vs `VBR` for Opus), but all of them should map to the
general concept of "constant" versus "variable" bitrate.


The two options have the following effects:

 *

“variable”:  allows an audio encoder to increase or lower its
bitrate according to the content of the audio it is encoding,
in order to preserve bandwidth/binary-size, while still
maintaining a target quality. For example, an encoder might
lower its bitrate when encoding silence, and revert to a full
bitrate when encoding speech.

 *

“constant” : forces an audio encoder to maintain the same
bitrate, regardless of the audio content. This can be useful
when a predictable bandwidth consumption is preferable.


As of M118, this flag will affect two codecs on Chromium: Opus and
AAC.



Blink component

Blink>Media>WebCodecs




TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

The risk is low. Firefox has not yet shipped WebCodecs, but is
currently developing it. Safari has developed video WebCodecs, but
not yet audio. The flag should be easy for other browsers to add
as they implement WebCodecs.


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


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


Web developers: Positive, as feature was originally a developper
request – https://github.com/w3c/webcodecs/issues/649



Other signals:


WebView application risks

This change does not deprecate existing APIs, and only supplements
existing APIs, with a sensible default. This should not be a
WebView risk.



Debuggability



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

?

It will be at the time it is implemented. Example test

.


Flag name on chrome://flags

N/A


Finch feature name

N/A


Non-finch justification

Simple parameter change


Requires code in //chrome?

False


Tracking bug

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




Estimated milestones

Shipping on desktop



118


Shipping on Android



118


Anticipated spec changes

None



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5084320053592064



-- 
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/CABrVPoak2%3DgxnREAhxe83D-BpSD0xF%3DnRFDbSiS8qrF0ZBQB7A%40mail.gmail.com

Re: [blink-dev] Intent to Ship: Baselines in New TextMetrics API in Canvas

[Mike Taylor]

LGTM1

On 8/21/23 1:52 PM, Yi Xu wrote:

Hi Yoav,

In first attempt link 
, 
we tried to ship all the attributes under TextMetrics API (in 2018). 
Some definitions were not clear so we was not able to do it.
In second attempt 
, 
we shipped 
actualBoundingBoxLeft, actualBoundingBoxRight, fontBoundingBoxAscent, 
fontBoundingBoxDescent, actualBoundingBoxAscent, 
actualBoundingBoxDescent, emHeightAscent and emHeightDescent.
In third attempt 
, 
we shipped fontBoundingBoxAscent, fontBoundingBoxDescent
In this attempt, we are trying to ship alphabeticBaseline, 
hangingBaseline and ideographicBaseline. Note that both Safari and 
firefox have shipped it, so we will like to catch up on this.


Thank you,

Yi Xu

On Sun, Aug 20, 2023 at 10:40 PM Yoav Weiss  
wrote:




On Fri, Aug 18, 2023 at 8:25 PM Yi Xu  wrote:


Contact emails

yi...@chromium.org, aaro...@chromium.org, fs...@chromium.org


Explainer

https://learn.microsoft.com/en-us/typography/opentype/spec/baselinetags



Specification

https://html.spec.whatwg.org/multipage/canvas.html#textmetrics
we are launching the following attributes in TextMetrics:
alphabeticBaseline, hangingBaseline and ideographicBaseline

*Tag Review*
https://github.com/w3ctag/design-reviews/issues/302


Summary

This is the 4th installment in extending the TextMetrics API
(first attempt link

,
 second
attempt
,
third attempt)

.The
current canvas TextMetrics API exposes the actualBoundingBox
and the fontBoundingBox readings. The definition of baseline
is more clear now. Both Firefox and Safari have already
shipped this *extension to TextMetrics*.


Thanks for pushing through this!! Any details on why the past
attempts weren't successful?


The original feature bug (https://crbug.com/277215
) has strong user support (23 stars).


Blink component

Blink>Canvas



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

Yes


Is this feature fully tested byweb-platform-tests

?
Link to test suite results fromwpt.fyi
.


https://wpt.fyi/results/html/canvas/element/text/2d.text.measure.baselines.html?label=experimental=master




Entry on thefeature dashboard 

https://chromestatus.com/feature/6516079022571520



Risks

Interoperability and Compatibility

Safari and Firefox have has already shipped these metrics in
the spec.

Firefox:Shipped


Safari:Shipped 

We know this is a feature requested by developers (as well as
internal Google teams like Google Docs). This API will help
developers have more control and more accurate text rendering.
As of today a different way to achieve this is by using
rendering text to the DOM and using getBoundingClientRect to
get some measurements. This process requires a relayout of the
page.

Activation

Enable the platform experiment ExtendedTextMetrics


-- 
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/CAC3hXJeKqXo9QKyreEM%2BqiNM0gi_us%3DWZ_-17AxpMg-bF%2BoLkA%40mail.gmail.com

Re: [blink-dev] Re: Intent to Ship: Bounce Tracking Mitigations

[Mike Taylor]

On 8/21/23 11:09 AM, Ben Kelly wrote:

On Sun, Aug 20, 2023 at 11:27 PM Yoav Weiss  
wrote:


Thanks for working on this important problem!

On Thu, Aug 17, 2023 at 9:28 PM Ben Kelly
 wrote:

Sorry, it seems I left off the signals section of the template:

Firefox: No signal
(https://github.com/mozilla/standards-positions/issues/835)


Firefox folks seem tentatively supportive, but have WPT questions.
Can you address them?


I'm checking without our WPT folks to try to understand what mozilla 
is suggesting.  I'm not familiar with web-driver functions at all, so 
not quite sure yet how feasible this is.


My read on bvandersloot's comment is that he's asking for a less generic 
version https://github.com/web-platform-tests/wpt/issues/17489 to make 
this testable (which you've already linked below). Exposing endpoints 
for advancing time seems to have more use cases than bounce 
tracking-specific webdriver endpoints, IMHO - but that's a discussion 
that should probably happen in the relevant WG.


See https://github.com/web-platform-tests/rfcs for the process to 
propose extending the testdriver.js API to expose... but I think you'll 
want to get the relevant concepts added to the webdriver spec first 
(seems possible, if Mozilla if supportive). The other option would be to 
something similar to FedCM 
 by 
adding webdriver extension commands (see spec PR here: 
https://github.com/fedidcg/FedCM/pull/465/files).


I personally wouldn't recommend blocking on this work, but it seems 
useful for someone to pursue as good first bugs for folks interested in 
standards and WPT internals. Note that additions to WebDriver now 
require going through the Intent process 
 
(great news for folks interested in learning this process, presumably 
they exist!).




Webkit: No signal
(https://github.com/WebKit/standards-positions/issues/214)
Web developers: No signals

On Thu, Aug 17, 2023 at 10:22 AM Ben Kelly
 wrote:

Contact emails

wanderv...@chromium.org ,
b...@chromium.org ,
rtarp...@chromium.org ,
j...@chromium.org 


Explainer


https://github.com/privacycg/nav-tracking-mitigations/blob/main/bounce-tracking-explainer.md




Specification


https://privacycg.github.io/nav-tracking-mitigations/#bounce-tracking-mitigations




Summary

This feature mitigates bounce tracking on the web.  It
works by deleting state from sites that access storage
during a redirect that the user has never directly
interacted with.  See the specification for more details.


Blink component

Privacy>NavTracking




TAG review

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



TAG review status

Issues addressed


Risks


Interoperability and Compatibility

The main risk is that we will incorrectly delete state for
a site that the user needs to continue functioning.  Our
approach attempts to address this with a number of signals:


 *

If a user has interacted with the site within the last
45 days, we will not delete its state.

 *

We are adding successful webauthn key assertions as
another "interaction" source in M117 to address SSO
use cases that only require security taps to stay
logged in.

 *

We only delete state if the potential tracking site is
not permitted as a 3P cookie.  This allows users and
enterprises to grant permission to maintain state on
these sites through existing mechanisms.


We have documented some known use cases at-risk

.


In particular, since 3P cookies are default allowed today,
this feature will only have an immediate impact on users
that have opted into 3P cookie blocking or incognito where
3P cookies are 

Re: [blink-dev] Intent to Ship: Detect UA Transitions on same-document Navigations

[Mike Taylor]

LGTM2

On 8/16/23 6:38 PM, Chris Harrelson wrote:

LGTM1 to ship once the spec PR has landed.

On Mon, Aug 14, 2023 at 7:50 AM 'Khushal Sagar' via blink-dev 
 wrote:



Contact emails

khushalsa...@google.com, liuwill...@google.com, hvanops...@google.com


Explainer

https://github.com/WICG/view-transitions/blob/main/default-ua-transitions.md


Specification

https://github.com/whatwg/html/pull/9579


Summary

Smooth visual transitions as users navigate on the web can lower
cognitive load by helping users stay in context. However, the user
experience is bad if both the site author and the UA add these
transitions: the transitions may conflict and cause confusion for
the user. This API avoids such cases to ensure only one visual
transition is executed at a time. The API adds a boolean on
`PopStateEvent` and `NavigateEvent` to indicate whether the UA has
executed a visual transition for this navigation. Authors can use
this to skip their custom transition.



Blink component

Blink>DefaultNavigationTransitions




TAG review

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


TAG review status

Issues addressed


Risks



Interoperability and Compatibility

This feature is a progressive enhancement. In the absence of the
feature, the author has to either conservatively assume there is a
UA transition (and not do a custom transition) or risk visual
glitches from double transition. As such there is no interop risk.



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

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

/Web developers/: Strongly positive Issues like this:

https://stackoverflow.com/questions/66867737/iphone-safari-detect-swipe-navigation.
This is likely to happen more as authors can now use
ViewTransitions to add custom transitions in SPAs.

/Other signals/:


Activation

None



Security

None. The API is limited to same-document navigations.



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



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. WPTs assert that the attribute is present but not the value.
By design, when this is set is left to the UA.


Flag name on chrome://flags



Finch feature name

None


Non-finch justification

None


Requires code in //chrome?

False


Estimated milestones

Shipping on desktop 118

Shipping on Android 118

Shipping on WebView 118



Anticipated spec changes

None



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5204831477694464


Links to previous Intent discussions

Intent to prototype:

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

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/CAMLuWUyhcTn1%3D%3DxfV0i5tyLS-APwqfDpetBstDie_4uMyxB1xQ%40mail.gmail.com

.

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


--
You received this message because you are subscribed to the Google Groups 
"blink-dev" 

Re: [blink-dev] Intent to Deprecate: non-standard `shadowroot` attribute for declarative shadow DOM

[Mike Taylor]

That sounds fine to me. Side question: would it be possible to treat 
shadowroot as a legacy alias of shadowrootmode, in case usage doesn't go 
down?


On 8/14/23 7:09 PM, Mason Freed wrote:
I'm checking back in on this deprecation thread. In the intervening 5 
milestones, the use counter for the deprecated attribute 
 
has unfortunately increased, rather than decreased. The old attribute 
is seen on 0.025% of page loads, just slightly more than the new 
shadowrootmode attribute 
 which 
is at 0.02%. I'm adding a UKM to look into which sites are the 
culprits, but I'd also like to start Finch-disabling the feature for a 
portion of Canary/Dev and maybe Beta users, to suss out problems and 
improve visibility of this deprecation to site owners. We're now about 
3 months out from 119 (the target removal milestone) going to stable. 
Any objections?


Thanks,
Mason


On Tuesday, February 21, 2023 at 1:36:25 PM UTC-8 Mason Freed wrote:

On Sun, Feb 19, 2023 at 11:33 PM Yoav Weiss
 wrote:

That uptick may suggest a single large entity that started
using this, and may be easy to move to the new attribute.
Have you tried turning the usecounter into a UKM


to try and see where the usage is coming from?


Agreed, that uptick is likely a single party. My hope is that it
will go back down as that entity moves to the new attribute.
Adding a UKM sounds like a reasonable idea - I'll do that if I
don't see a down-trend in the usecounter data soon.

The other alternative is that some developer documentation is
pointing at the old attribute name. Can you verify that's not
the case?


Indeed that's very likely. Our own blog post
 still describes the old
attribute. (I'm working on getting that updated.)

Otherwise, we typically prefer to have deprecation messages
with clear milestones for their removal date. It seems to me
that a year may be a lot for this. Would you be comfortable
with setting the removal date for 6 milestones ahead? Maybe
the UKM analysis can change our thinking here?


I'm reasonably comfortable with targeting 6 milestones out. That'd
be roughly M118 as the last version that supports the old
`shadowroot` attribute, and M119 as the first that doesn't. And
closer to the deadline we can re-evaluate usage and make sure it's
low enough for comfort. Does that sound reasonable? If so, I'll
update the documentation and console messages accordingly.

Thanks,
Mason


On Fri, Feb 17, 2023 at 6:38 PM Mason Freed
 wrote:


On Thu, Feb 16, 2023 at 5:19 PM Jason Robbins
 wrote:

On Wednesday, February 15, 2023 at 10:14:48 PM UTC-8
yoav...@chromium.org wrote:
+Jason Robbins - FYI, this didn't make it to the
chromestatus tool.

I have an idea about what went wrong.

"Intent to deprecate" is the subject line that is
expected for the first stage in the deprecation
process.  It was detected as such, but that stage does
not require any review.    Based on this thread and
the contents of the feature entry it looks like the
final stage was what needed to be reviewed.


Sorry - this was my fault. The stages of deprecation are
kind of different, and the two options I had for this
"deprecation" (not "removal") were "Draft Ready for Trial
email" and "Draft Intent to Ship email". I chose the
latter and renamed the subject line to "Intent to
Deprecate". I hadn't realized we had tooling look at these
emails. I guess the right thing was to choose the "Ready
for Trial" email template, and not change the subject
line. Perhaps a suggestion would be to rename those links
or add help text explaining which one is appropriate at
each stage for a deprecation/removal intent?

Thanks,
Mason

The final stage detects an intent email with the
subject line "Intent to ship" or "Intent to remove". 
The launching-features page uses "Intent to ship" for
the final stage of a deprecation, and when we generate
the email preview we use that subject line, but I'm
guessing that it sounded wrong so Mason edited it.

It would probably be better if chromestatus generated
 

Re: [blink-dev] Intent to Implement and Ship: Make URL parser to not decode percent-encoded ASCII character in URL's path

[Mike Taylor]

I'm having a hard time assessing the risk, despite the very low usage 
(it has doubled since the original email was sent - but still very low) 
and other browsers shipping it.


That said, LGTM2 % having a base::Feature we can use as a killswitch, in 
case we discover something we didn't anticipate.


On 8/9/23 8:12 PM, 'TAMURA, Kent' via blink-dev wrote:

LGTM1.  It seems to have very low risk.


On Fri, Aug 4, 2023 at 4:53 PM Hayato Ito  wrote:


Contact emails

hay...@chromium.org


Specification

https://url.spec.whatwg.org/


Summary

Make URL parser to not decode percent-encoded ASCII characters in
URL's path, such as "%41" ('A'). Before this change: > const url =
new URL("http://example.com/%41;); > url.href
"http://example.com/A"After this change: > const url = new
URL("http://example.com/%41;); > url.href "http://example.com/%41;



Blink component

Blink>Network




TAG review

None


TAG review status

Not applicable


Risks


Interoperability and Compatibility


/Gecko/: Shipped/Shipping

/WebKit/: Shipped/Shipping


There are risks. Please see the WIP CL's description for details
(https://crrev.com/c/4607744).
I'd like to collect feedback about possible risks widely through
this thread.

The usage (Canary): 0.000106% (URL.Path.UnescapeEscapedChar

).
This usage is not specific to any particular use case and can be
considered a theoretical upper bound. The actual breakage is
likely much lower than this number.


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




Tracking bug

https://crbug.com/1252531



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6389236793606144

-- 
Hayato
-- 
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/CAFpjS_2-4PAY47VbDdd%2BHS%2BchmNUc9dW3BsRtW33LDr1QOeLGw%40mail.gmail.com

.



--
TAMURA, Kent
Software Engineer, Google


--
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/CAGH7WqHcCModrUAQ%3DGJx-oiLcEmBwi%2BjU0ONCpnNWh%3Dp_THRdg%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/b674e07c-7804-41d5-b8f5-7ada6295651b%40chromium.org.

Re: [blink-dev] Re: Intent to Prototype & Ship: Cookie Expires/Max-Age attribute upper limit for prior storage

[Mike Taylor]

Perhaps we could delay this change until M119 as I understand that the 
first cookies that were set more than 400 days ago are due to expire in 
the M118 window. That should give us some time to understand the impact 
in more concrete terms and mitigate some of the impact, were it to turn 
out to that 400 days is not the right balance between utility and 
protecting users.


(I should note that I'm supportive of this change as proposed as a net 
positive for security, but am recused from voting on it.)


On 8/10/23 9:52 AM, Ari Chivukula wrote:
It's true we don't have a lot of data on the impact of this 
specifically, but part of that is due to 400 day lag between 
enforcement and anyone in prod feeling the effects. We could try to 
produce data on the amount of cookies already in the store that would 
be newly capped, but that won't really tell us what will happen if 
they expire a year from now.


Some sites may have to adapt their preferences to be re-written to the 
cookie store if they haven't already, but this change is starting 
another 400 day counter for sites to adapt the same way was done a 
year ago.


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

On Thu, Aug 3, 2023, 05:45 Daniel Bratell  wrote:

So my assumption is the pessimistic one that most sites won't
notice this policy change even if we publish posts about it. And
even if users and sites can survive lost cookies, it might still
be a disruption that was unexpected and unwanted. But I don't have
any good idea of how disruptive and how common it will be. It
might not be a real problem at all, but I am missing the knowledge
and data to understand what the size of the risk is.

My hope was that you would have some information or data that
would show to me that there is nothing to be concerned about. I
don't think I'm there yet, but if cookies are already limited to
400 days, that is a good indication it can't be too much of a
problem.

/Daniel

On 2023-08-03 14:03, Ari Chivukula wrote:

I guess I'm a little confused on the direction of the
conversation. If a user starts using chrome today no cookie can
set an expiration date more than 400 days in the future, so all
sites must already adapt to that present reality.

Some users with cookies stored before this limit was imposed
around a year ago have cookies that expire years in the future.
After this change via a DB migration, those cookies would be
capped to 400 days after the DB migration was run. No user will
lose cookies in the DB migration itself.

I don't think we know how many sites depend on cookies that are
set once and never again, but given cookie retention timelines
are not guaranteed sites should not do this. The actual
expiration time of the cookie isn't returned in the cookie header
or document.cookie, so sites should already be refreshing cookies
(by setting them again) on occasion.

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

On Thu, Aug 3, 2023, 07:44 Daniel Bratell 
wrote:

I like the idea of automatically clearing out unused cookies,
but I am unclear if that is what happens here.

In an hypothetical scenario, a user of website awesomeapp.tv
 will make some customization the first
time they are there, and the site will store that
customization in a cookie with an expire date far, far into
the future. If this hypothetical user keeps using
awesomeapp.tv  without changing any
settings, and with no cookie updates, will they still lose
their customization after 400 days?

If the hypothetical scenario could play out, do we have any
idea how common it would be?

To create some context, we have an informal "this breakage is
acceptable if needed to move the web forward of" limit of
0.003% of page loads. The numbers you list set an upper limit
on the amount of problems and the real number of possibly
problematic page loads or affected sites will be much lower,
but how low?

/Daniel

On 2023-08-02 21:57, Ari Chivukula wrote:

According to measurements in Chrome, of all cookies set,
about 20% request an Expires/Max-Age further than 400 days
in the future. Of that 20%: half target 2 years, a quarter
target 10 years or more, and the remainder are spread over
the rest of the range.

Keep in mind this is looking at the usage of sites *before*
any cap was imposed. Although the distribution of cookies
with expirations more than 400 days in the future will be
the same, the amount will be under 20% of current storage
and shrinking as any cookies added or updated will now be
forced to respect the 400 day cap.

The motivation for this change is to require, now that we're
about to 

Re: [blink-dev] Intent to Experiment: WebRTC encoded transform - Modify Metadata functions

[Mike Taylor]

LGTM to experiment from 118 to 123 inclusive.

On 8/11/23 9:07 AM, Guido Urdaneta wrote:



Contact emails

h...@chromium.org, agpa...@chromium.org, topr...@chromium.org, 
gui...@chromium.org



Explainer

https://github.com/palak8669/webrtc-encoded-transform/blob/create-encoded-explainer/create-encoded-explainer.md 




Specification

https://github.com/w3c/webrtc-encoded-transform/compare/main...palak8669:webrtc-encoded-transform:setmetadata-pr 




Design docs


https://github.com/palak8669/webrtc-encoded-transform/blob/create-encoded-explainer/create-encoded-explainer.md 




Summary

Add features to the WebRTC Encoded Transform API that allow 
manipulating audio and video frame metadata Background: A number of 
use cases have been identified that require the manipulation of WebRTC 
encoded media without decoding them first. These include: - Sending 
data that has been encoded previously - Sending data that has been 
received in encoded form - Receiving data in encoded form and 
forwarding it.


 In particular, we want to support the use case of glitch-free 
forwarding of media coming from multiple redundant peer connections 
that provide the same media payloads but with different metadata.


Issue links:

https://github.com/w3c/webrtc-nv-use-cases/issues/77 



https://github.com/w3c/webrtc-nv-use-cases/issues/122 





Blink component

Blink>WebRTC 




TAG review

The original full spec was reviewed by TAG here: 
https://github.com/w3ctag/design-reviews/issues/531 



No TAG review has been requested for this incremental change, since it 
is a small addition and its API surface might change as a result of 
feedback from the origin trial and ongoing discussions in the WebRTC 
working group.



TAG review status

Pending


Chromium Trial Name

RTCEncodedFrameSetMetadata


WebFeature UseCounter name

V8RTCEncodedVideoFrame_SetMetadata_Method


Risks



Interoperability and Compatibility

Interoperability risk: There is the risk that other browsers will not 
implement this feature. We try to mitigate this risk by providing a 
detailed specification of the new behavior and discussing it in the 
WebRTC working group, so that it becomes part of the encoded transform 
spec, which currently has consensus. Compatibility test: This is a new 
feature intended to support a new use case. It introduces no breaking 
changes, so we do not expect any compatibility issues.




Gecko: No signal


WebKit: No signal


Web developers: No signals.


Other signals:


Ergonomics

This feature is an extension to WebRTC Encoded Transform, which itself 
is an extension to WebRTC/RTCPeerConnection.




Activation

N/A



Security

No new security risks identified.



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

Our goal is to validate that the proposed API can support the intended 
use case. More specifically, we want to confirm using setMetadata() 
can help achieve glitch-free forwarding of media using redundant input 
peer connections in real-world settings.




Ongoing technical constraints

None



Debuggability

N/A



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. Currently tested using unit and web tests. WPTs will be added once 
the final API shape is confirmed.



Flag name on chrome://flags

N/A


Finch feature name

N/A


Non-finch justification

Currently guarded by a Blink RuntimeEnabledFeature: 
RTCEncodedFrameSetMetadata.



Requires code in //chrome?

No


Tracking bug

https://crbug.com/1393964 


Estimated milestones

OriginTrial desktop last



123

OriginTrial desktop first



118


OriginTrial Android last



123

OriginTrial Android first



118


OriginTrial webView last



123

OriginTrial webView first

 

Re: [blink-dev] Intent to Ship: Attribution Reporting features (lookback windows, flex-lite)

[Mike Taylor]

Thanks - the risk seems pretty low from a compat POV.

LGTM1

On 8/9/23 12:43 PM, John Delaney wrote:
> Is this based on metrics you have in front of you, or something 
else? Also, what might breakage look like in this situation?


We don't have metrics measuring the usage of this key directly, but we 
have checked with a number of known partners from the origin trial to 
see if this was being used. Breakage in this situation, similar to 
below, would not be user-visible or immediately web-visible. 
Ultimately, this will cause reports to be matched/generated 
differently than before, so a developer may see a different set of 
reports for the same set of events, or no reports at all.


> Why would a negative duration be used today? It sounds weird, but 
I've also seen "max-age=-1" w/ cookies to mean "like, now-now". Are we 
aware of any usage of negative durations?


Currently, negatives are clamped to the minimum of 1 day, and don't 
hold any special value. They would only be used if someone had 
observed they were clamped to the minimum, and decided to rely on that 
behavior rather than setting the minimum themself (or even 0). Similar 
to above, we are not aware of any usage but do not have targeted 
metrics for this.


On Friday, August 4, 2023 at 2:13:45 PM UTC-4 Mike Taylor wrote:

On 8/3/23 4:39 PM, John Delaney wrote:


Contact emails

johni...@chromium.org, csharri...@chromium.org


Explainer

https://github.com/WICG/attribution-reporting-api/blob/main/flexible_event_config.md#phase-1-lite-flexible-event-level

<https://github.com/WICG/attribution-reporting-api/blob/main/flexible_event_config.md#phase-1-lite-flexible-event-level>*
*

https://github.com/WICG/attribution-reporting-api/blob/main/EVENT.md
<https://github.com/WICG/attribution-reporting-api/blob/main/EVENT.md>


Specification

https://wicg.github.io/attribution-reporting-api/
<https://wicg.github.io/attribution-reporting-api/>


Blink component

Internals > AttributionReporting

<https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3EAttributionReporting>


Summary

We plan on landing a number of changes to the Attribution
Reporting API focused on:

 *

registration ergonomics allowing better flexibility when
controlling whether attribution should occur based on the
time between the two events

 *

support for developer controlled configurations that allow
for callers to specify the windowing scheme and number of
reports to receive for an event, in order to more efficiently
extract utility out of the privacy mechanism


Spec changes

1.

Allow expiry, event_report_window, aggregatable_report_window
fields to be integers
<https://github.com/WICG/attribution-reporting-api/pull/895>

2.

Lookback window in filters
<https://github.com/WICG/attribution-reporting-api/pull/914>

3.

Developer defined configurations for reporting windows and
maximum # of reports
<https://github.com/WICG/attribution-reporting-api/pull/856>

 *

Separate verbose debug report for start time
<https://github.com/WICG/attribution-reporting-api/pull/916>

4.

Reduce min event report window time from 1 day to 1 hour and
prohibit negative durations
<https://github.com/WICG/attribution-reporting-api/pull/876>


Risks

Interoperability and Compatibility

  Changes (1) (3) are all fully backwards compatible.
(2) (3) are optional, additive changes to the API surface which
allow for additional information to be provided by developers at
registration time.


 (2) is largely backwards compatible except in the
case a developer was previously using a key with the name
"_lookback_window", where they will now see different behavior
when matching. We expect the API breakage to be negligible.


Is this based on metrics you have in front of you, or something
else? Also, what might breakage look like in this situation?



 (4) has some marginal backwards incompatibility.
“prohibit negative durations” will result in any previous
registrations now resulting in a failure rather than being
clamped to a minimum value. In the event a registration fails,
there will be no user-visible / web-visible breakage outside of
different reports being emitted than before. That being said, we
also expect API breakage here to be negligible.


Why would a negative duration be used today? It sounds weird, but
I've also seen "max-age=-1" w/ cookies to mean "like, now-now".
Are we aware of any usage of negative durations?


Will this feature be supported on all six Blink platforms
(Win

Re: [blink-dev] Intent to Ship: Media Queries: prefers-reduced-transparency feature

[Mike Taylor]

ased on

https://github.com/WebKit/standards-positions/issues/145#issuecomment-1478736469,
it doesn't seem like there's a lot of appetite
from Apple or Mozilla.

On 7/24/23 4:13 AM, Yoav Weiss wrote:

    I'd love to hear +Mike Taylor 's thought about
this from an extra fingerprinting bit
perspective. Also, how would users signal their
preference?

On Fri, Jul 21, 2023, 23:21 Luke
 wrote:


Contact emails

lukewa...@gmail.com, lu...@warlow.dev


Explainer

None


Specification


https://drafts.csswg.org/mediaqueries-5/#prefers-reduced-transparency


Summary

Adds the `prefers-reduced-transparency`
feature, which lets authors adapt web content
to user-selected preference for reduced
transparency in the OS, such as the 'Reduce
transparency' setting on macOS. Valid options
are 'reduce' or 'no-preference'.



Blink component

Blink>CSS

<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ECSS>


Search tags

css
<https://chromestatus.com/features#tags:css>,
prefers-reduced-transparency

<https://chromestatus.com/features#tags:prefers-reduced-transparency>


TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility



/Gecko/: No signal

(https://github.com/mozilla/standards-positions/issues/851)
There is a separate umbrella issue for some
the preference media queries (contrast,
motion, color-scheme). They have a stale PR
to add an overall positive position for those
preference media queries. They also have an
implementation behind a flag. It's not been
enabled yet due to fingerprinting concerns.

/WebKit/: No signal

(https://github.com/WebKit/standards-positions/issues/145)
I have submitted an implementation of this
feature as a PR to WebKit:
https://github.com/WebKit/WebKit/pull/11560

/Web developers/: Positive

(https://blog.logrocket.com/new-media-queries-you-need-to-know)

/Other signals/:


Security

This feature can be used for fingerprinting
as it exposes a user preference.



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?



Debuggability

This can be emulated in the Dev Tools
rendering tab like other preference media
queries.



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

Yes

The feature will be supported on all
platforms, but whether the user will be able
to signal a reduced transparency preference
may depend on the OS.



Is this feature fully tested by
web-platform-tests

<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?

Yes


Flag name on chrome://flags

#enable-experimental-web-platform-features


Finch feature name

PrefersReducedTransparency


   

Re: [blink-dev] Intent to Ship: Remove quirks mode behavior for option label attribute

[Mike Taylor]

LGTM2, so long as we have a killswitch.

On 8/9/23 7:08 AM, Daniel Bratell wrote:


If I did the math correctly, that puts the likely breakage below 14% 
(95% confidence) of the population, or less than 0.002% of page loads. 
(Napkin math, don't quote me, but it's in that ballpark which is a 
good ballpark)


LGTM1

/Daniel

On 2023-08-03 03:49, Joey Arhar wrote:
I looked at the top 20 websites here: 
https://chromestatus.com/metrics/feature/timeline/popularity/4454
I looked at the option elements which were triggering the UseCounter, 
and I found that all of them seemed to have a label attribute with no 
text content at some point during page load, but then when I actually 
looked at them in DevTools after page load they all had text content.

None of those top 20 websites are affected by this change.

On Wed, Apr 26, 2023 at 9:22 AM Rick Byers  wrote:

Hey Joey,
We discussed this in the API owners meeting today. Given that
Firefox has succeeded in removing this quirk, we do think it's
valuable for us to attempt to follow. Thank you again for pushing
on it. Could you take a look at either 20 hits from HA, or 10
high-ranking hits

*
 and
see if you see any actual breakage? API owners agreed today that
if you didn't (or if you saw just 1 in 20), we'd be OK proceeding
with a killswitch we can pull if necessary.

*Note chrishtr@ is looking into making ranking-based HA analysis
easier than getting BigQuery setup.

Thanks,
   Rick

On Wed, Apr 19, 2023 at 11:06 AM Rick Byers 
wrote:

Hey Joey, sorry for the delay. Yeah 0.01% puts this into the
high risk range unfortunately. If you want to proceed, the
next step would probably be to get a random sample of
impacted URLs and evaluate the severity of breakage


and ease of adaptation

.
Maybe we'd find they are almost all pages with very subtle
layout changes which already look OK or just slightly off in
Firefox. The real risk likely comes from sites / apps
designed for blink/webkit only (enterprise, android webview,
etc.). But if you could show evidence that < 1 in 20 impacted
page loads have any meaningful breakage (i.e. <0.005% page
views impacted), then we might still be able to proceed with
appropriate webview and enterprise guards. But that obviously
has a cost, so up to you if it's better to just specify the
current quirky behavior. Maybe our efforts are better spent
trying to actively drive down quirks mode usage somehow?

Thanks for trying to clean this sort of thing up!
  Rick

On Wed, Apr 12, 2023 at 5:34 PM Joey Arhar
 wrote:

Here is the UseCounter:
https://chromestatus.com/metrics/feature/timeline/popularity/4454

It looks like it is at 0.0103%
What do yall think?

> Personally I would be happy to approve if we had a
UseCounter with less than our small but non-trivial risk
threshold of 0.001% of page loads

Looks like its higher than this threshold :(

On Wed, Apr 12, 2023 at 3:53 AM Yoav Weiss
 wrote:

Friendly ping! :)

On Wednesday, March 15, 2023 at 7:13:25 PM UTC+1 Joey
Arhar wrote:

Yes, that matches my understanding. I can see on
omahaproxy that the usecounter was merged in 112
and I can see on chromiumdash that 112 goes to
stable on april 4

On Wed, Mar 15, 2023 at 11:11 AM Yoav Weiss
 wrote:

Looked at this following the API owners
meeting and given that the usecounters

 landed
in 112, I think we can expect stable data
early April but not before.

Joey - does that match your understanding?

On Sat, Jan 28, 2023 at 1:04 AM Rick Byers
 wrote:

On Thu, Jan 26, 2023 at 5:07 PM Simon
Pieters  wrote:

Hi folks!

Thanks for working on this, Joey.
Removing quirks where possible is
always nice!

On Wed, Jan 25, 2023 at 7:18 PM Joey
 

Re: [blink-dev] Re: Intent to Ship: CSS logical flow relative values

[Mike Taylor]

LGTM1

On 8/8/23 7:11 AM, obr...@igalia.com wrote:
I got an email saying that new features will be announced in blog 
posts and enterprise release notes about 1 week before a milestone 
reaches beta.
We are close to that point and still no LGTM, so I guess it's better 
to delay this and try to target 118 instead.


El dia dimecres, 2 d’agost de 2023 a les 21:57:58 UTC+2, 
obr...@igalia.com va escriure:



Contact emails

obr...@igalia.com


Explainer


https://www.smashingmagazine.com/2018/03/understanding-logical-properties-values/


Specification

https://drafts.csswg.org/css-logical/#directional-keywords
https://drafts.csswg.org/css-ui/#resize




Design docs


https://developer.mozilla.org/docs/Web/CSS/CSS_logical_properties_and_values


Summary

Add these new values to existing CSS properties: - float:
inline-start - float: inline-end - clear: inline-start - clear:
inline-end - resize: block - resize: inline



Blink component

Blink>CSS



Search tags

css-logical 


TAG review

https://github.com/w3ctag/design-reviews/issues/286
The only issue relevant to logical values
washttps://github.com/w3c/csswg-drafts/issues/2821, which was
addressed in the spec, and Blink obeys the resolution.

It's not clear what the resolution is/was - I just see a few linked 
issues and it being closed without any comment (maybe the TAG had a 
different operating model back in 2018...).



TAG review status

Issues addressed


Risks



Interoperability and Compatibility

Gecko and WebKit already shipped. Gecko doesn't follow the spec.



/Gecko/: Shipped/Shipping
(https://bugzilla.mozilla.org/show_bug.cgi?id=1253919,
https://bugzilla.mozilla.org/show_bug.cgi?id=1464786

)
The implementation is wrong,
seehttps://bugzilla.mozilla.org/show_bug.cgi?id=1661548

/WebKit/: Shipped/Shipping
(https://bugs.webkit.org/show_bug.cgi?id=218087,
https://bugs.webkit.org/show_bug.cgi?id=218088

)

/Web developers/: Positive
(https://bugs.chromium.org/p/chromium/issues/detail?id=850004#c8)

/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

The DevTools Styles panel’s autocomplete functionality is already
aware of these new 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 byweb-platform-tests

?

Yes


Flag name on chrome://flags

None


Finch feature name

CSSLogical
(This is the feature name in runtime_enabled_features.json5, which
seemingly I'm supposed to provide here, but it's not actually
using Finch)


Requires code in //chrome?

False


Tracking bug

https://crbug.com/850004


Estimated milestones

Shipping on desktop 117
DevTrial on desktop 70

Shipping on Android 117
DevTrial on Android 70

Shipping on WebView 117



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


Links to previous Intent discussions

Intent to

prototype:https://groups.google.com/a/chromium.org/d/msg/blink-dev/48OwfwZrbvI/A1XZFGkzAwAJ

This intent message was generated byChrome 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 

Re: [blink-dev] Intent to Ship: Attribution Reporting features (lookback windows, flex-lite)

[Mike Taylor]

On 8/3/23 4:39 PM, John Delaney wrote:


Contact emails

johni...@chromium.org, csharri...@chromium.org


Explainer
https://github.com/WICG/attribution-reporting-api/blob/main/flexible_event_config.md#phase-1-lite-flexible-event-level*
*

https://github.com/WICG/attribution-reporting-api/blob/main/EVENT.md 




Specification

https://wicg.github.io/attribution-reporting-api/ 




Blink component

Internals > AttributionReporting 




Summary

We plan on landing a number of changes to the Attribution Reporting 
API focused on:


 *

registration ergonomics allowing better flexibility when
controlling whether attribution should occur based on the time
between the two events

 *

support for developer controlled configurations that allow for
callers to specify the windowing scheme and number of reports to
receive for an event, in order to more efficiently extract utility
out of the privacy mechanism


Spec changes

1.

Allow expiry, event_report_window, aggregatable_report_window
fields to be integers


2.

Lookback window in filters


3.

Developer defined configurations for reporting windows and maximum
# of reports


 *

Separate verbose debug report for start time


4.

Reduce min event report window time from 1 day to 1 hour and
prohibit negative durations



Risks

Interoperability and Compatibility

  Changes (1) (3) are all fully backwards compatible. (2) 
(3) are optional, additive changes to the API surface which allow for 
additional information to be provided by developers at registration time.



 (2) is largely backwards compatible except in the case a 
developer was previously using a key with the name "_lookback_window", 
where they will now see different behavior when matching. We expect 
the API breakage to be negligible.


Is this based on metrics you have in front of you, or something else? 
Also, what might breakage look like in this situation?


 (4) has some marginal backwards incompatibility.  
“prohibit negative durations” will result in any previous 
registrations now resulting in a failure rather than being clamped to 
a minimum value. In the event a registration fails, there will be no 
user-visible / web-visible breakage outside of different reports being 
emitted than before. That being said, we also expect API breakage here 
to be negligible.


Why would a negative duration be used today? It sounds weird, but I've 
also seen "max-age=-1" w/ cookies to mean "like, now-now". Are we aware 
of any usage of negative durations?


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


All except Android WebView


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



Yes


Estimated milestones

Chrome 117


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5089526405398528 




Links to previous Intent discussions
Previous I2S: 
https://groups.google.com/a/chromium.org/g/blink-dev/c/2Rmj5V6FSaY 


--
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/3c8f2f73-db97-4c39-9af4-c4c05539504cn%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/0ac7dd98-42a1-a566-eaaf-0084d303e9ce%40chromium.org.

Re: [blink-dev] Intent to Ship: CSS cap and rcap font units

[Mike Taylor]

LGTM1

On 8/4/23 6:41 AM, Daniil Sakhapov wrote:



Contact emails

sakha...@chromium.org


Explainer

Two font units related to the cap-height of the font. They are the 
last two to fully cover CSS Values font related units.



Specification

https://www.w3.org/TR/css-values-4/#cap


Summary

'cap' is equal to the used cap-height of the first available font. 
'rcap' is equal to the value of the cap unit on the root element.




Blink component

Blink>CSS 




TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

None



/Gecko/: Shipped/Shipping

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


/Web developers/: Asked offline at the conference.


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


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-values/cap-invalidation.html
https://wpt.fyi/css/css-contain/container-queries/font-relative-units-dynamic.html
https://wpt.fyi/css/css-values/cap-unit-001.html


Flag name on chrome://flags

CSSCapFontUnits


Requires code in //chrome?

False


Estimated milestones

Shipping on desktop 117
DevTrial on desktop 116

Shipping on Android 117
DevTrial on Android 116

Shipping on WebView 117



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

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/CAH3Z92-t_kPVjxEB5xLYFY7vaxxyVqpF8Cf7DNsfnipRFJjZ2w%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/fa72f7af-b242-28f5-aa69-1a50c3adacbd%40chromium.org.

Re: [blink-dev] Intent to Ship: Consistent minimum font size across languages

[Mike Taylor]

LGTM2

On 8/4/23 1:32 AM, Daniel Bratell wrote:


LGTM1

/Daniel

On 2023-08-04 07:13, Koji Ishii wrote:



Contact emails

ko...@chromium.org


Specification

None


Design docs


https://docs.google.com/document/d/180f-ex4Nj11lExg80ziZZ8Bc-LxQU6B9wY-WEZksLM0/edit?usp=sharing


Summary

Changes the default setting for the “Minimum font size” to be off by 
default for 7 languages (Arabic, Farsi, Japanese, Korean, Thai, 
Simplified and Traditional Chinese) to improve the interoperability 
and the accessibility. Before this change, this setting is off by 
default for all languages except the 7 languages. This change makes 
these languages consistent with other languages. Note, this is not 
about changing the “Minimum font size” feature itself. It will be 
available without any changes for the accessibility and for readability.




Blink component

Blink>Fonts 




TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

None



/Gecko/: Shipped/Shipping

/WebKit/: Shipped/Shipping

/Web developers/: Positive 
(https://bugs.chromium.org/p/chromium/issues/detail?id=1195041#c13)

https://github.com/vivliostyle/vivliostyle.js/issues/673 (Japanese)

/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

?

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/p/chromium/issues/detail?id=1469490


Estimated milestones

Shipping on desktop 118

Shipping on Android 118

Shipping on WebView 118



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

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/CAHe_1dJpyQoBMn2xmjqzoDPsQ7KGcNB4EiMma7WX8bRdei6qZw%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/8d4b48c8-cf20-b15c-2463-4bfde621d8f8%40gmail.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/d8bab081-146c-74f6-1355-bdd25619747f%40chromium.org.

Re: [blink-dev] Intent to Ship: Storage Access API with Prompts

[Mike Taylor]

On 8/2/23 4:47 PM, Chris Fredrickson wrote:

Contact emails

cfred...@chromium.org, johann...@chromium.org, shuu...@chromium.org


Explainer

https://github.com/privacycg/storage-access/blob/main/README.md 



https://github.com/cfredric/chrome-storage-access-api/blob/main/README.md 




Specification

https://privacycg.github.io/storage-access 




Summary

The Storage Access API provides a means for authenticated cross-site 
embeds to check whether access to unpartitioned cookies is blocked and 
request access if it is blocked. This request may be surfaced to the 
user as a prompt, or auto-granted/auto-denied. Chrome will support the 
Storage Access API by implementing all the behaviors listed in the 
specification, i.e. with user prompts, and additionally having its own 
user-agent-specific behaviors. Chrome’s implementation is available 
for testing 
starting 
in Chrome 117.



The Storage Access API is related to other cookie-focused projects 
like CHIPS 
and 
First-Party Sets as 
preparation for phasing out third-party cookies 
in 
Chrome.



Note that Edge previously sent an I2I 
for 
the Storage Access API feature (with their own user-agent-specific 
behavior), and Chrome has previously sent an I2S 
for 
support for the Storage Access API gated on First-Party Sets 
membership (without user prompts). This I2S is intended for support 
for the API across sites that are not within the same First-Party Set.



Blink component

Blink>StorageAccessAPI 




TAG review

https://github.com/w3ctag/design-reviews/issues/807 
(review of 
overall API, not of prompts)



TAG review status

Positive 




Risks

Interoperability and Compatibility

There is minor compatibility risk as Firefox and Safari already differ 
slightly in their user-agent-specific prompt requirements. Chrome's 
planned behavior 
is closest to 
Safari's current behavior, and we aim to standardize as much of this 
user-agent-specific behavior as possible over time.


Could you elaborate on the differences for prompt requirements, and how 
that might lead to compat issues?



Gecko: Shipping


WebKit: Shipping


Web developers: There has been great developer interest in the Storage 
Access API, given that it provides the only predictable way of working 
with cross-site cookies in many browsers. Various developers have 
chimed in onhttps://github.com/whatwg/html/issues/3338 
and filed issues 
onhttps://github.com/privacycg/storage-access 
.



Other signals: Edge has shipped Blink's previous implementations of 
this API, which differ from Chrome's plans. We have kept (and intend 
to continue keeping) Edge engineers in the loop about these changes 
and there will be feature flags to control Blink's behavior.



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

None


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


No. It will be supported on all Blink platforms except Android WebView 
initially. We may add WebView support in the future.



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



No. Browser UI is not testable by WPTs, since that is UA-specific. 
(The Storage Access API spec itself is tested by WPTs 
.)



Flag name on chrome://flags

#storage-access-api, #permission-storage-access-api


Finch feature name

StorageAccessAPI, PermissionStorageAccessAPI


Non-finch justification

None


Requires code in //chrome?

True


Estimated milestones
    Shipping on desktop: 117
    Shipping on Android: 120

Anticipated spec changes

Some minor changes are expected in order to properly take user 
settings into account: 
https://github.com/privacycg/storage-access/pull/174 
and an 

Re: [blink-dev] Re: Intent to Prototype and Ship: Clip-path geometry-box values

[Mike Taylor]

LGTM3

On 8/2/23 12:00 PM, Chris Harrelson wrote:

LGTM2

On Tue, Aug 1, 2023 at 2:19 PM Alex Russell  
wrote:


LGTM1

On Tuesday, August 1, 2023 at 1:27:31 PM UTC-7 Philip Rogers wrote:


Contact emails

p...@chromium.org


Explainer

None


Specification

https://drafts.fxtf.org/css-masking/#the-clip-path


Summary

Clip-path supports  values to control the clip's
reference box, making clip-path easier to use. These box
values can be used alongside basic shapes (for example,
clip-path: circle(50%) margin-box), or they can be used alone
to clip to the specified box (for example, clip-path:
content-box).


Blink component

Blink>Paint




Search tags

clip-path ,
clipPath ,
geometry-box
,
geometryBox 


TAG review

None


TAG review status

Not applicable


Risks


Interoperability and Compatibility

Low, as this has already shipped in both Firefox and Safari.


/Gecko/: Shipped/Shipping

/WebKit/: Shipped/Shipping

/Web developers/: Positive
(https://github.com/web-platform-tests/interop/issues/148)

/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

This is debuggable with existing basic CSS tooling.


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://flags

None


Finch feature name

ClipPathGeometryBox


Requires code in //chrome?

False


Tracking bug

https://crbug.com/694218


Measurement

Overall clip-path usage is tracked with
https://chromestatus.com/metrics/css/timeline/popularity/355.


Sample links

https://pr.gg/clip-path-geometry-box-examples.html


Estimated milestones

Shipping on desktop 118

Shipping on Android 118

Shipping on WebView 118



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

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/0afff51b-0ee7-45c2-8ec9-6ae7eeed0f97n%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/CAOMQ%2Bw-gw%2BH4i8EFfPTif3iDo3NYbQPuxg1ksTofmiFFJ9q%2Brg%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 

Re: [blink-dev] Intent to Ship: Clear BFCache during browsing data removal

[Mike Taylor]

LGTM3

On 8/2/23 11:56 AM, Chris Harrelson wrote:

LGTM2 conditioned on landing the spec.

On Wed, Aug 2, 2023 at 12:12 AM Daniel Bratell  
wrote:


Ex post facto LGTM1

Just try to get that spec updated so that developers will know
what to expect.

/Daniel


On 2023-08-02 00:32, 'Fergal Daly' via blink-dev wrote:

On Tue, 1 Aug 2023 at 23:44, Mike Taylor 
wrote:

On 8/1/23 7:54 AM, 'Mingyu Lei' via blink-dev wrote:



Contact emails

le...@chromium.org, fer...@chromium.org


Explainer

None


Specification

None

Given that WebKit is shipping this and we would like to, any
reason to not document this behavior to the Clear-Site-Data spec?


There's an issue here
<https://github.com/w3c/webappsec-clear-site-data/issues/73>.
Hopefully we can update the spec shortly,

F



Summary

When performing browsing data removal (e.g. via
chrome://settings/clearBrowserData, hard reload, or the
`Clear-Site-Data ` header), the disk and in-memory cache for
the HTTP response will be cleared. In addition to this, if
the browsing data removal's data type is "cache", then all
the BFCache entries matching the origin will be cleared as well.



Blink component

UI>Browser>Navigation>BFCache

<https://bugs.chromium.org/p/chromium/issues/list?q=component:UI%3EBrowser%3ENavigation%3EBFCache>


Search tags

bfcache <https://chromestatus.com/features#tags:bfcache>


TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

None



/Gecko/: N/A
(https://bugzilla.mozilla.org/show_bug.cgi?id=1671182)
Firefox has removed the cache type data removal for
Clear-Site-Data header.

/WebKit/: Shipped/Shipping
(https://github.com/WebKit/WebKit/pull/4617)

/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)?

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://flags

None


Finch feature name

None


Non-finch justification

The feature has already been released.



Requires code in //chrome?

False


Tracking bug

https://crbug.com/1428640


Estimated milestones

Shipping on desktop 115

Shipping on Android 115



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

https://github.com/w3c/webappsec-clear-site-data/issues/73


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5096684790480896

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/CAN_fHtn%3DJ5E7Hdcpv9Ojyhrf0AUdoL3PY%3DJxq7jByp5O5pPNgw%40mail.gmail.com

<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAN_fHtn%3DJ5E7Hdcpv9Ojyhrf0AUdoL3PY%3DJxq7jByp5O5pPNgw%40mail.gmail.com?utm_medium=email_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

Re: [blink-dev] Intent to Experiment: FedCM Sign-in Status API

[Mike Taylor]

Yep, sounds good. Thanks for the heads up!

On 8/1/23 1:24 PM, Christian Biesinger wrote:
FYI, we are extending this origin trial to Android (excluding webview) 
in Chrome 117. I understand we do not need a new LGTM for that.


Christian

On Fri, Jun 9, 2023 at 10:00 AM Mike Taylor  
wrote:


LGTM to experiment from M116 to M119 inclusive.

On 6/8/23 5:38 PM, Christian Biesinger wrote:



Contact emails

cbiesin...@chromium.org


Explainer


https://github.com/fedidcg/FedCM/blob/main/proposals/idp-sign-in-status-api.md

<https://github.com/fedidcg/FedCM/blob/main/proposals/idp-sign-in-status-api.md>


Specification

https://github.com/fedidcg/FedCM/pull/436
<https://github.com/fedidcg/FedCM/pull/436>


Summary


This origin trial is intended to cover the IdP Sign-in Status API

<https://github.com/fedidcg/FedCM/blob/main/proposals/idp-sign-in-status-api.md>,
which is our proposal to address the last remaining privacy leak
of FedCM before we feel comfortable enabling it without third
party cookies: The Timing Attack Problem (issue
<https://github.com/fedidcg/FedCM/issues/230#issue-1168333560>,
presentation

<https://github.com/fedidcg/FedCM/blob/main/meetings/2022/FedCM_%20Options%20for%20the%20Timing%20Attack%20Problem%20(8_16_2022).pdf>).


The Timing Attack Problem is an attack that a tracker can perform
by using the FedCM API in such a way that allows them to track
users invisibly. The attack works by correlating the time between
credentialed and uncredentialed requests and abusing the API to
prevent it from being observed by users.


While we explored many variations and options (presentation

<https://github.com/fedidcg/FedCM/blob/main/meetings/2022/FedCM_%20Options%20for%20the%20Timing%20Attack%20Problem%20(8_16_2022).pdf>),
in this proposal, the IdP Sign-in Status API

<https://github.com/fedidcg/FedCM/blob/main/proposals/idp-sign-in-status-api.md>allows
an Identity Provider to signal to the browser when their users
are logging in and logging out (in a top level frame).


This signal allows the FedCM API to (a) avoid making any
credential requests when the user is logged out of the IdP (and
hence, fully mitigate timing correlations) an (b) provide a
guarantee that every credentialed request it makes will have a
user-visible outcome (e.g. an account chooser or a dialog to sign
in to the IdP) given that the assumption is that the user is
logged in.


We believe this will make the Timing Attack economically
impractical (e.g. it requires the user to (a) have logged-in to
the attacker in a top level frame as well as to (b) be recognized
as an IdP in the account chooser), and in doing so enables FedCM
to operate when third party cookies are blocked.



Blink component

Blink>Identity>FedCM

<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EIdentity%3EFedCM>


TAG review


We have an open spec PR
<https://github.com/fedidcg/FedCM/pull/436>that is currently
under review, and in that process, Firefox suggested that we
reframe the API in terms of the Login Status API
<https://github.com/privacycg/is-logged-in>which
Chrome/Firefox/Safari seem to be in directional agreement
<https://github.com/privacycg/is-logged-in/issues/53>. We are
planning to kick-off our TAG review once this settles a bit more
into concrete spec terms while we are running the origin trial
but before we send our I2S.


TAG review status

Pending


Risks



Interoperability and Compatibility


Gecko: Under
consideration(https://github.com/fedidcg/FedCM/pull/436
<https://github.com/fedidcg/FedCM/pull/436>). Firefox raised
early on the Timing Attack Problem
<https://github.com/fedidcg/FedCM/issues/230#issue-1168333560>and
possible ways
<https://github.com/fedidcg/FedCM/issues/230#issuecomment-1097224792>we
can address it. The IdP Sign-in Status API is intended as a
signal that the user agent can use to mitigate the Silent

<https://github.com/fedidcg/FedCM/blob/main/meetings/2022/FedCM_%20Options%20for%20the%20Timing%20Attack%20Problem%20(8_16_2022).pdf>Timing
Attacks which are executed through correlating the time between
credentialed and uncredentialed requests without the user’s
knowledge. The API sufficiently mitigates the problem for Chrome
by showing a prompt (e.g. account chooser or dialog to sign in to
the IdP) every time it makes a credentialed request within the
FedCM API. We are working with Firefox to write the spec in such
a way that different user agents can have the flexibility to make
different trade-offs in terms of how o

Re: [blink-dev] Intent to Ship: Clear BFCache during browsing data removal

[Mike Taylor]

On 8/1/23 7:54 AM, 'Mingyu Lei' via blink-dev wrote:



Contact emails

le...@chromium.org, fer...@chromium.org


Explainer

None


Specification

None
Given that WebKit is shipping this and we would like to, any reason to 
not document this behavior to the Clear-Site-Data spec?



Summary

When performing browsing data removal (e.g. via 
chrome://settings/clearBrowserData, hard reload, or the 
`Clear-Site-Data ` header), the disk and in-memory cache for the HTTP 
response will be cleared. In addition to this, if the browsing data 
removal's data type is "cache", then all the BFCache entries matching 
the origin will be cleared as well.




Blink component

UI>Browser>Navigation>BFCache 




Search tags

bfcache 


TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

None



/Gecko/: N/A (https://bugzilla.mozilla.org/show_bug.cgi?id=1671182) 
Firefox has removed the cache type data removal for Clear-Site-Data 
header.


/WebKit/: Shipped/Shipping (https://github.com/WebKit/WebKit/pull/4617)

/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)?

No


Is this feature fully tested by web-platform-tests

?

No


Flag name on chrome://flags

None


Finch feature name

None


Non-finch justification

The feature has already been released.



Requires code in //chrome?

False


Tracking bug

https://crbug.com/1428640


Estimated milestones

Shipping on desktop 115

Shipping on Android 115



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


https://github.com/w3c/webappsec-clear-site-data/issues/73


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5096684790480896

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_fHtn%3DJ5E7Hdcpv9Ojyhrf0AUdoL3PY%3DJxq7jByp5O5pPNgw%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/2b8e555b-6aee-d611-2dff-800286bde75c%40chromium.org.

Re: [blink-dev] Re: Intent to Prototype: Web environment integrity API

[Mike Taylor]

Hi Billy Bob,

On 7/29/23 1:11 AM, Billy Bob wrote:


I have thoughtfully and respectfully written this comment. Please 
review it!


But then I'm grateful that the blink-dev community remains a place
where we can disagree respectfully and iterate openly and publicly
on difficult and emotionally charged topics, backing us away from
thinking and acting in an "us-vs-them" fashion. I also want to
point out that while open to anyone, this forum is moderated for
new posters. Moderators like myself approve any post which is
consistent with chromium's code of conduct
,
regardless of the specific point of view being taken. The
thoughtful comments here over the past few days have been
educational and overall calming for me, thank you!

I have watched the Web Integrity API unfold from Hackernews, the 
GitHub repo, and now the news. I want to be part of the discussion, 
not be informed of decisions after-the-fact.


You've found a great place to be part of the discussion and provide 
feedback (here on blink-dev, within the relevant Intent threads for a 
feature). And the folks working on the feature will take your feedback 
into account.


While you are say you are “looking for a better forum and will update 
when we have found one”, you have begun adding these changes 
to 
chromium. Again, despite wanting to treat this as an early proposal 
for new web standards, you are already prototyping it in Chromium! 
It’s a bad look, bad PR, and against your own W3C code of conduct. 
It’s not just that you’re ignoring or leaving feedback unaddressed, 
it’s that all feedback is rejected in the first place too. By the time 
it’s implemented, it may be too late. [snip]


Please take some time to familiarize yourself with the Blink process - 
which is how we prototype, experiment with, and eventually ship features 
(or decide to _not_ ship them), once approved by the Blink API Owners: 
https://www.chromium.org/blink/launching-features/. Prototyping features 
in the open (disabled, behind feature flags) is how we work.


thanks,
Mike

--
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/c1d7d39d-1871-d22f-3202-77d782437fbd%40chromium.org.

Re: [blink-dev] Intent to Ship: Partitioning Storage, Service Workers, and Communication APIs

[Mike Taylor]

Thanks for the bug report! We'll triage it in our regular meeting tomorrow.

And yes, your understanding of the timing is correct (we've been working 
on this project for 2+ years 
<https://groups.google.com/a/chromium.org/g/blink-dev/c/WXNzM0WiQ-s/m/l10NGhaoAQAJ>, 
and in dev-trial since September 
<https://developer.chrome.com/en/blog/storage-partitioning-dev-trial/> 
of last year). Note that advancing to a higher percentage will depend on 
the stability and web-compatibility of partitioned 3P storage.


thanks,
Mike

On 7/30/23 12:04 PM, Tim Williams wrote:
I've submitted the following bug: 
https://bugs.chromium.org/p/chromium/issues/detail?id=1468811 since 
the trial isn't working while I did everything right.


On Saturday, July 29, 2023 at 2:52:22 AM UTC+3 Tim Williams wrote:

Hey There,
I am truly struggling to understand the timing here.
Currently, the partitioning is under a flag.
Are you saying that the flag would be turned on to 100% of Desktop
and Android users on Sept 8th THIS YEAR??

That's a huge and extremely fast change, wow.

On Thursday, July 27, 2023 at 10:33:01 PM UTC+3 Kyra Seevers wrote:

Hi all,

M115 is now being served at 100% on Desktop and Android. We
will begin the rollout to Stable 1% shortly - the approximate
rollout schedule is now as follows:

Stable 1%: July 28th
Stable 10%: Aug 11th
Stable 50%: Aug 25th
Stable 100%: Sept 8th

On Thu, Jul 27, 2023 at 11:52 AM Mike Taylor
 wrote:

No, we don't know with certainty.

You can watch
https://chromiumdash.appspot.com/releases?platform=Windows
to see when 115 is being served to 100% for all platforms.
Today it's at 50% for Windows, for example.

On 7/26/23 5:39 PM, Jagadeesha B Y wrote:

Do we know when does M115 will hit 100%?  Exact date
would help us to communicate on the storage partition
impact to our customers.


On Wednesday, July 26, 2023 at 2:12:10 PM UTC-7
mike...@chromium.org wrote:

On 7/26/23 4:01 PM, Vi S wrote:


Hi Kyra,

Per your message here

(https://groups.google.com/a/chromium.org/g/blink-dev/c/24hK6DKJnqY/m/tu0i5OmhCAAJ)
it sounds like as of 7/26/2023, the Storage
Partitioning change has not been released yet since
M115 is not served to 100% of users. Is that
correct? My understanding of this message is that
M115 is currently served to 12.5% of users and that
once M115 is served to 100% of users (which will
happen in the next ~4 weeks), only then will the
storage partition change be rolled out in a gradual
manner. Is this understanding accurate?

That's correct.



Additionally, would you be able to provide an
updated schedule for the rollout of the storage
partitioning change (similar to the one linked here:

https://groups.google.com/a/chromium.org/g/blink-dev/c/24hK6DKJnqY/m/Tts2gjrEBwAJ)
?


Once we begin the gradual roll-out, we'll provide a
estimated rollout schedule on this thread (I hesitate
to do so now - it's hard to know when we will begin
exactly).

thanks,
Mike



Thank you

On Monday, July 24, 2023 at 10:18:26 AM UTC-4 Kyra
Seevers wrote:

Hi there,


Thank you for your email - as of today (Monday
7/24/23), the feature is not rolled-out to stable.


However, I can confirm that the rollout schedule
for this feature begins in M115 at Stable 1%
(once M115 is served to 100% of users). M115 is
currently served to 12.5% of users - you can
track the status
athttps://chromiumdash.appspot.com/releases?platform=Windows

<https://chromiumdash.appspot.com/releases?platform=Windows>.
Two weeks after that, we'll go to 10%, assuming
no large stability or compatibility regressions.
Then 50 and 100% at additional 2 week increments.


In the meantime, we have a deprecation trial

(https://developer.chrome.com/blog/storage-partitioning-deprecation-trial/#participate-in-the-deprecation-trials

<https://developer.chrome.com/blog/storage-partitioning-deprecation-trial/#participate-in-the-deprecation-trials>)
running in M115+ that allows sites who opt-in to
mainta

Re: [blink-dev] Re: Intent to Ship: HTTPS pages with Cache-control: no-store and Back/Forward Cache

[Mike Taylor]

Thanks for the additional analysis. Another question I have, if a site 
sends:


|"Cache-Control: no-cache, no-store, must-revalidate" (copypasta from 
https://stackoverflow.com/a/2068407), would it be treated differently as 
"Cache-Control: no-store"? I'm trying to think of signals that might be 
useful as heuristics for "no seriously don't ever cache this"... |


On 7/27/23 9:04 AM, Mingyu Lei wrote:

Hi Mike,

Following our previous response, we would like to share the usage data 
that we have collected from the beta channel. 18.76% of history 
navigations are not restored from BFCache because of the CCNS header 
only. The following are the breakdowns:


  * No RPC containing CCNS response header: 8.63%
  o *No cookie modification: 6.70%*
  o With non-HttpOnly cookie modifications only: 1.38%
  o With HttpOnly or non-HttpOnly cookie modifications: 0.55%
  * With RPC containing CCNS response header: 10.13%
  o No cookie modification: 1.01%
  o With non-HttpOnly cookie modifications only: 7.86%
  o With HttpOnly or non-HttpOnly cookie modifications: 1.26%

Based on these figures, we will update the proposal to evict the 
BFCache entry with any cookie modification for the current phase. This 
should give us 6.70% improvement in cache hit rate.


We could continue the HttpOnly cookie discussion in the future.

On Sat, Jul 22, 2023 at 12:46 AM Mingyu Lei  wrote:

Hi Mike,

Thanks for the comments. We have discussed the concerns you raised
before and please find the replies below.


https://github.com/fergald/explainer-bfcache-ccns/blob/main/README.md#secure-cookies
references "HTTPS-only" cookies, as well as "secure" vs
"insecure" cookies. By "HTTPS-only", do you mean a cookie that
sets the "secure" attribute (including "__Secure-" prefixes),
_and_ sets "HttpOnly"? Or something else?

Later in

https://github.com/fergald/explainer-bfcache-ccns/blob/main/README.md#allow-ccns-documents-to-be-bfcached-without-the-api,
the proposal is that CCNS pages are safe to bfcache if no
"HTTP-only" cookies have changed. Are these cookies setting
only the "HttpOnly" attribute, or is this intended to say
"HTTPS-only" as above?


The short answer is that we will only monitor HttpOnly cookies,
regardless of whether they are secure or not. The terms in the
explainer were unclear, and we will fix them.

I see that

https://github.com/w3ctag/design-reviews/issues/786#issuecomment-1515742477
references this work. Did we learn anything from
experimentation in the wild (not sure if y'all ran an experiment)?

I'm curious if y'all have looked at stats on the uptake of
secure/httponly cookies vs "non-secure" cookies being set by
pages returned from RPCs sent with an Authorization header
(though I wouldn't be surprised if we don't have UMA for
that... perhaps just globally would be useful to consider).


We are currently conducting a Finch experiment to collect the hit
rate on beta, and the data will be available next week. We will
share it with you again after we have the data.

With that data, we will be able to tell the percentage of page
loads that observe HttpOnly cookie changes, any cookie changes, or
no cookie changes. There will also be another dimension about
whether the page had sent out RPC with CCNS response. There is no
pre-existing UMA for this, but we have recorded the reasons why
BFCache is not restored.

My only concern (which may not be grounded in reality) would
be for sites not following best practices...


We expect that there will be cases where pages are restored
inappropriately where sites are not following good practice. We
don't have an idea of the size of this problem. We will have data
from the beta channel soon that will tell us what the difference
would be in terms of BFCache hit-rate between _monitoring all
cookies_ and _only monitoring HttpOnly cookies_. Our thought
process looks like this:

If _monitoring all cookies_ already gives us large hit-rate
improvement, *or* the difference between _monitoring all
cookies_ and _only monitoring HttpOnly cookies_ is small, then we
are happy to just be conservative and go with _monitoring all
cookies_. Otherwise*, we would like to discuss this further.


/* "Otherwise" means _monitoring all cookies_ will only give us
negligible cache hit-rate improvement, *and* _monitoring HttpOnly
cookies_ will give us a much larger increase./

Thanks,
Mingyu

On Wed, Jul 12, 2023 at 12:11 AM Mike Taylor
 wrote:

On 7/11/23 2:19 AM, 'Fergal Daly' via blink-dev wrote:


[BCC chrom

Re: [blink-dev] Re: Intent to Ship: Transitions on specified discrete properties

[Mike Taylor]

Thanks for the heads up.

Mind sharing some links to the compat issues?

On 7/27/23 8:57 PM, Joey Arhar wrote:
FYI: due to compat issues I encountered while launching this feature, 
we decided to create a CSS property to opt-in to the new behavior. It 
was resolved by the CSSWG here: 
https://github.com/w3c/csswg-drafts/issues/8857


On Wed, Apr 5, 2023 at 8:49 AM Rick Byers  wrote:

LGTM3

On Wed, Apr 5, 2023 at 11:40 AM Daniel Bratell
 wrote:

LGTM2

/Daniel

On 2023-04-05 17:39, Alex Russell wrote:

Thanks everyone for adding an Explainer, etc. I'm a little
worried that this is another feature that skimped on
developer engagement (Explainers) and review (TAG) until I2S.
They both came very late, and if the feature itself wasn't
seemingly landed as a closed spec PR, I'd be blocking this
for another few weeks/months until TAG had a chance to
properly discuss.

Let's not do this again?

Regardless, LGTM1.

On Wednesday, March 22, 2023 at 8:56:33 AM UTC-7 Rick Byers
wrote:

We discussed this in the API owners meeting today. Since
position requests were just filed, we'd like to give this
another week to see if anyone has any feedback. But
otherwise we're excited to see this ship.

Rick

On Wed, Mar 15, 2023 at 6:10 PM Joey Arhar
 wrote:

TAG review:
https://github.com/w3ctag/design-reviews/issues/825
WebKit standards position:
https://github.com/WebKit/standards-positions/issues/148
Mozilla standards position:
https://github.com/mozilla/standards-positions/issues/763

On Wed, Mar 15, 2023 at 1:30 PM Joey Arhar
 wrote:


Contact emails

fla...@chromium.org, jar...@chromium.org


Explainer


https://github.com/w3c/csswg-drafts/issues/4441#issuecomment-1329749962


Specification

https://github.com/w3c/csswg-drafts/pull/8520


Summary

Allows transitions of discrete properties to be
started on properties explicitly listed in the
transition-property list. These transitions run
using the same logic as an animation on those
properties performing a flip at 50% by default
but can be customized through the use of the
transitionstart event and web-animations-1 APIs
for modifying transition animations.



Blink component

Blink>Animation




TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

This is unlikely to have a big compatibility risk
since the transition-property: all keyword does
not include discrete properties. This will only
affect sites which have explicitly listed
discrete properties in transition-property.
However given this used to be unsupported, it is
unlikely to have been specified on most sites.
This will also now be doing what the developer
requested.



/Gecko/: No signal

/WebKit/: No signal

/Web developers/: No signals

/Other signals/:


Ergonomics

This will be used in tandem with the popover
attribute and CSSDisplayAnimation. This feature
will not make it hard for chrome to maintain good
performance.



Activation

This will not be hard for developers to use
immediately.



Security

This does not do anything that the developer
could not have set with their own stylesheets or
script and shouldn't have any risks.



WebView application risks

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

This is not high risk for WebView, but is
controlled by a base::Feature 

Re: [blink-dev] Intent to Extend Experiment: SoftNavigation performance Entry

[Mike Taylor]

LGTM to extend from M117-M120 inclusive, especially with the pause in 
115 and 116.


Thanks for demonstrating spec progress and sharing OT results (I'm not 
going to pretend I watched that whole 42 minute video tho - I trust that 
you did. ^__^).


On 7/27/23 12:29 PM, Yoav Weiss wrote:



Contact emails

yoavwe...@chromium.org


Explainer


https://github.com/WICG/soft-navigations#soft-navigations 




Specification


https://wicg.github.io/soft-navigations

The spec is still pretty initial and rough, but should give a general 
idea of how this can integrate with the platform.



Summary

Exposes the (experimental) soft navigation heuristics 
 to web 
developers, using both PerformanceObserver and the performance timeline.



Blink component

Blink>PerformanceAPIs 




TAG review

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


TAG review status

Extremely recent.


Risks



Interoperability and Compatibility



/Gecko/: No signal on an extremely recent position request 
https://github.com/mozilla/standards-positions/issues/854


/WebKit/: No signal on an extremely recent position request
https://github.com/WebKit/standards-positions/issues/235

/Web developers/: Strong 
 
support !


Interesting results  from 
OT participants.


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



Nope!



Goals for experimentation

I'm interested in gaining insights on the quality of the heuristic and 
how it compares to current heuristics employed by RUM providers or 
driven by framework- or app-specific knowledge. I'm also interested in 
knowing if developers find the correlation of various performance 
entries to their soft navigation ergonomic, and whether the emitted 
FP/FCP/LCP entries work well for them to evaluate the performance of 
their soft navigations.




Reason this experiment is being extended

Not enough feedback the first time around. But partners tell me they 
are now ready to measure using this.




Ongoing technical constraints

None.



Debuggability



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

SoftNavigationHeuristics


Requires code in //chrome?

False


Tracking bug

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


Estimated milestones


Origin Trial ran from M110-M114 (ending on June 30th). I asked to 
extend it on that thread, but never did.


I'm interested in running a trial on M117-M120 (inclusive), skipping 
most of M115 and M116 to ensure lack of reliance on the OT.




Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5144837209194496


Links to previous Intent discussions

Intent to prototype: 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfV3qRFx0i-eGJFSzqE8bnbX8XYJCvXAj0LfvO0icPo_jA%40mail.gmail.com
Intent to experiment: 
https://groups.google.com/a/chromium.org/g/blink-dev/c/IK-IZTBo59U/m/r8WaR2YOBQAJ

--
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/CAL5BFfULP5d3fNCAqeO2gLP56R3HCytmaNk%2B9kpYsC2dj4%3DqoQ%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/7c94d7c3-212a-62de-dfa4-76bbd25990c9%40chromium.org.

Re: [blink-dev] Re: Intent to Ship: Web Serial support for Bluetooth RFCOMM services

[Mike Taylor]

LGTM1 to ship.

(I'll leave you to figure out why the BT Serial port sometimes sent 
"2:59:NN PM" and sometimes received ":59:NN PM" :))


On 7/26/23 6:15 PM, Matt Reynolds wrote:

Here's a short demo video that shows the permission UI:

https://drive.google.com/file/d/1Y_Ito9P-EourYa7ofL_qQMOmmvBIhwpT/view

Demo source:

https://nondebug.github.io/bluetooth-serial-port-demo/

Off-screen I connected a HC-06 wireless Bluetooth serial transceiver 
<https://amzn.com/dp/B01FCQZ8VW> to a USB serial adapter 
<https://amzn.com/dp/B07BBPX8B8>. The demo uses Web Serial API to 
connect to both devices, then sends data over USB and shows that it is 
received from the HC-06 over Bluetooth.



On Wed, Jul 26, 2023 at 2:13 PM Mike Taylor  
wrote:


LGTM1 - thanks for the well-written explainer.

On 7/26/23 4:20 PM, Alex Russell wrote:

Sounds good; thanks for explaining.

On Wednesday, July 26, 2023 at 1:02:00 PM UTC-7 Reilly Grant wrote:

On Wed, Jul 26, 2023 at 10:03 AM Alex Russell
 wrote:

A screenshot would go a long way.

Exciting to hear there's a partner that want this.

Also, was there consideration of an OT? A strong reason
to avoid?


The change to the API is very small and we had strong
developer feedback during development that the API worked for
them. I also feel that this kind of feature is a poor fit for
an Origin Trial because it's not something where you can
measure the impact with or without the capability as the
capability is fundamentallyﾠnecessary for the existenceﾠof
the web app. At that point the only benefit of an OT would be
to ship an end-user application early, but it wouldn't be a
true experiment.

On Wednesday, July 26, 2023 at 9:55:25 AM UTC-7 Reilly
Grant wrote:

On Wed, Jul 26, 2023 at 9:05 AM Alex Russell
 wrote:

I'm going to have to stay recused on this vote,
but just want to lend my fullest non-voting
support to shipping ASAP. This is excellent work,
and I can see you've dotted i's and crossed t's
in anticipation of a full shakedown here. Thanks
for doing it.

It might be helpful for others evaluating the
proposal to have a demo or video to look at
regarding the permissions UI/UX that this will
sit behind; is it possible to add something like
that to your Explainer? And are there users who
can vouch for the utility of this feature for
their use-cases?


Unfortunately the hardware our partner is working on
is still confidential so I can't share a
real-worldﾠuse case. They're very excited about being
able to use a web app. We can put together a demo
video with a generic Bluetooth serial device but it
will be pretty boring because theﾠpermissions
UIﾠlooks identical toﾠselecting a wired serial port.
We only support connecting to devices that are
already paired with the system so it doesn't use the
more complex scanning UX that you see for Web
Bluetooth.ﾠﾠ

Thanks,

Alex

On Tuesday, July 25, 2023 at 1:47:30 PM UTC-7
ajayra...@google.com wrote:


Contact emails

mattreyno...@chromium.org
<mailto:mattreyno...@chromium.org>,
melhui...@chromium.org
<mailto:melhui...@chromium.org>


Explainer


https://github.com/WICG/serial/blob/main/EXPLAINER_BLUETOOTH.md

<https://github.com/WICG/serial/blob/main/EXPLAINER_BLUETOOTH.md>


Specification

https://github.com/WICG/serial/pull/189
<https://github.com/WICG/serial/pull/189>


Summary

Support Bluetooth RFCOMM services in the Web
Serial API. The Bluetooth RFCOMM (Radio
frequency communication) protocol provides
emulated RS-232 serial ports. This feature
enables applications to make connections to
RFCOMM services on paired Bluetooth Classic
devices using the Web Serial API.


Blink component

Blink>Serial

<http

Re: [blink-dev] Intent to Ship: Partitioning Storage, Service Workers, and Communication APIs

[Mike Taylor]

No, we don't know with certainty.

You can watch https://chromiumdash.appspot.com/releases?platform=Windows 
to see when 115 is being served to 100% for all platforms. Today it's at 
50% for Windows, for example.


On 7/26/23 5:39 PM, Jagadeesha B Y wrote:
Do we know when does M115 will hit 100%?  Exact date would help us to 
communicate on the storage partition impact to our customers.


On Wednesday, July 26, 2023 at 2:12:10 PM UTC-7 mike...@chromium.org 
wrote:


On 7/26/23 4:01 PM, Vi S wrote:


Hi Kyra,

Per your message here

(https://groups.google.com/a/chromium.org/g/blink-dev/c/24hK6DKJnqY/m/tu0i5OmhCAAJ)
it sounds like as of 7/26/2023, the Storage Partitioning change
has not been released yet since M115 is not served to 100% of
users. Is that correct? My understanding of this message is that
M115 is currently served to 12.5% of users and that once M115 is
served to 100% of users (which will happen in the next ~4 weeks),
only then will the storage partition change be rolled out in a
gradual manner. Is this understanding accurate?

That's correct.



Additionally, would you be able to provide an updated schedule
for the rollout of the storage partitioning change (similar to
the one linked here:

https://groups.google.com/a/chromium.org/g/blink-dev/c/24hK6DKJnqY/m/Tts2gjrEBwAJ)
?


Once we begin the gradual roll-out, we'll provide a estimated
rollout schedule on this thread (I hesitate to do so now - it's
hard to know when we will begin exactly).

thanks,
Mike



Thank you

On Monday, July 24, 2023 at 10:18:26 AM UTC-4 Kyra Seevers wrote:

Hi there,


Thank you for your email - as of today (Monday 7/24/23), the
feature is not rolled-out to stable.


However, I can confirm that the rollout schedule for this
feature begins in M115 at Stable 1% (once M115 is served to
100% of users). M115 is currently served to 12.5% of users -
you can track the status
athttps://chromiumdash.appspot.com/releases?platform=Windows
<https://chromiumdash.appspot.com/releases?platform=Windows>.
Two weeks after that, we'll go to 10%, assuming no large
stability or compatibility regressions. Then 50 and 100% at
additional 2 week increments.


In the meantime, we have a deprecation trial

(https://developer.chrome.com/blog/storage-partitioning-deprecation-trial/#participate-in-the-deprecation-trials

<https://developer.chrome.com/blog/storage-partitioning-deprecation-trial/#participate-in-the-deprecation-trials>)
running in M115+ that allows sites who opt-in to maintain
unpartitioned storage for a few milestones while they develop
a storage-partitioning-compatible solution.


Thanks,

Kyra


On Sun, Jul 23, 2023 at 7:05 PM Jagadeesha B Y
 wrote:


I see that Chrome 115 release notes -
https://chromestatus.com/feature/5723617717387264
mentioning about storage partition being enabled by
default.  Could someone confirm how gradual this rollout
is?  do we know if storage partition is rolled out fully?

Our SASS product has a heavy reliance on Shared worker
and this would break our customer use cases.  We use
shared worker to co-ordinate Web RTC signalling and
websocket management which is critical for the app.
On Wednesday, May 31, 2023 at 8:42:15 AM UTC-7
mk...@chromium.org wrote:

LGTM3 with all the caveats about careful rollout
discussed above.

-mike


On Tue, May 30, 2023 at 5:39 PM Mike Taylor
 wrote:

OK - let's consider this I2S officially revived.
Looking for a 3rd LGTM to begin shipping in M115.

We have implemented 3rd party deprecation trial
support for M115+ (see

https://developer.chrome.com/blog/storage-partitioning-deprecation-trial/#participate-in-the-deprecation-trials),
and extended the deprecation trial's expiration
date accordingly to account for the delay. And we
have the Enterprise policy ready to go.

The rollout schedule will look something like the
following, pending metrics and compatibility
stability:

July 25th: 1% of Stable population (approximately
1 week after M115 is released)
Aug 8th: 10%
Aug 22nd: 50%
Sep 5: 100%

As always, if we discover significant user-facing
breakage we'll explore pausing or rolling back to
   

Re: [blink-dev] Re: Intent to Ship: Web Serial support for Bluetooth RFCOMM services

[Mike Taylor]

LGTM1 - thanks for the well-written explainer.

On 7/26/23 4:20 PM, Alex Russell wrote:

Sounds good; thanks for explaining.

On Wednesday, July 26, 2023 at 1:02:00 PM UTC-7 Reilly Grant wrote:

On Wed, Jul 26, 2023 at 10:03 AM Alex Russell
 wrote:

A screenshot would go a long way.

Exciting to hear there's a partner that want this.

Also, was there consideration of an OT? A strong reason to avoid?


The change to the API is very small and we had strong developer
feedback during development that the API worked for them. I also
feel that this kind of feature is a poor fit for an Origin Trial
because it's not something where you can measure the impact with
or without the capability as the capability is
fundamentallyﾠnecessary for the existenceﾠof the web app. At that
point the only benefit of an OT would be to ship an end-user
application early, but it wouldn't be a true experiment.

On Wednesday, July 26, 2023 at 9:55:25 AM UTC-7 Reilly Grant
wrote:

On Wed, Jul 26, 2023 at 9:05 AM Alex Russell
 wrote:

I'm going to have to stay recused on this vote, but
just want to lend my fullest non-voting support to
shipping ASAP. This is excellent work, and I can see
you've dotted i's and crossed t's in anticipation of a
full shakedown here. Thanks for doing it.

It might be helpful for others evaluating the proposal
to have a demo or video to look at regarding the
permissions UI/UX that this will sit behind; is it
possible to add something like that to your Explainer?
And are there users who can vouch for the utility of
this feature for their use-cases?


Unfortunately the hardware our partner is working on is
still confidential so I can't share a real-worldﾠuse case.
They're very excited about being able to use a web app. We
can put together a demo video with a generic Bluetooth
serial device but it will be pretty boring because
theﾠpermissions UIﾠlooks identical toﾠselecting a wired
serial port. We only support connecting to devices that
are already paired with the system so it doesn't use the
more complex scanning UX that you see for Web Bluetooth.ﾠﾠ

Thanks,

Alex

On Tuesday, July 25, 2023 at 1:47:30 PM UTC-7
ajayra...@google.com wrote:


Contact emails

mattreyno...@chromium.org
,
melhui...@chromium.org 


Explainer


https://github.com/WICG/serial/blob/main/EXPLAINER_BLUETOOTH.md




Specification

https://github.com/WICG/serial/pull/189



Summary

Support Bluetooth RFCOMM services in the Web
Serial API. The Bluetooth RFCOMM (Radio frequency
communication) protocol provides emulated RS-232
serial ports. This feature enables applications to
make connections to RFCOMM services on paired
Bluetooth Classic devices using the Web Serial API.


Blink component

Blink>Serial




TAG review

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



TAG review status

Pending


Risks



Interoperability and Compatibility

Web Serial API is only implemented in Chromium.
Other browser vendors have expressed negative
views regarding the API and are unlikely to
implement it.


This feature will not affect compatibility in
existing apps. The feature only adds support for
connecting to new types of devices. There are no
changes for currently-supported devices.


Gecko: Negative
(https://github.com/mozilla/standards-positions/issues/687
)
Previous thread:

Re: [blink-dev] Intent to Ship: Partitioning Storage, Service Workers, and Communication APIs

[Mike Taylor]

On 7/26/23 4:01 PM, Vi S wrote:


Hi Kyra,

Per your message here 
(https://groups.google.com/a/chromium.org/g/blink-dev/c/24hK6DKJnqY/m/tu0i5OmhCAAJ) 
it sounds like as of 7/26/2023, the Storage Partitioning change has 
not been released yet since M115 is not served to 100% of users. Is 
that correct? My understanding of this message is that M115 is 
currently served to 12.5% of users and that once M115 is served to 
100% of users (which will happen in the next ~4 weeks), only then will 
the storage partition change be rolled out in a gradual manner. Is 
this understanding accurate?

That's correct.


Additionally, would you be able to provide an updated schedule for the 
rollout of the storage partitioning change (similar to the one linked 
here: 
https://groups.google.com/a/chromium.org/g/blink-dev/c/24hK6DKJnqY/m/Tts2gjrEBwAJ) 
?


Once we begin the gradual roll-out, we'll provide a estimated rollout 
schedule on this thread (I hesitate to do so now - it's hard to know 
when we will begin exactly).


thanks,
Mike



Thank you

On Monday, July 24, 2023 at 10:18:26 AM UTC-4 Kyra Seevers wrote:

Hi there,


Thank you for your email - as of today (Monday 7/24/23), the
feature is not rolled-out to stable.


However, I can confirm that the rollout schedule for this feature
begins in M115 at Stable 1% (once M115 is served to 100% of
users). M115 is currently served to 12.5% of users - you can track
the status
athttps://chromiumdash.appspot.com/releases?platform=Windows
<https://chromiumdash.appspot.com/releases?platform=Windows>. Two
weeks after that, we'll go to 10%, assuming no large stability or
compatibility regressions. Then 50 and 100% at additional 2 week
increments.


In the meantime, we have a deprecation trial

(https://developer.chrome.com/blog/storage-partitioning-deprecation-trial/#participate-in-the-deprecation-trials

<https://developer.chrome.com/blog/storage-partitioning-deprecation-trial/#participate-in-the-deprecation-trials>)
running in M115+ that allows sites who opt-in to maintain
unpartitioned storage for a few milestones while they develop a
storage-partitioning-compatible solution.


Thanks,

Kyra


On Sun, Jul 23, 2023 at 7:05 PM Jagadeesha B Y 
wrote:


I see that Chrome 115 release notes -
https://chromestatus.com/feature/5723617717387264 mentioning
about storage partition being enabled by default.  Could
someone confirm how gradual this rollout is?  do we know if
storage partition is rolled out fully?

Our SASS product has a heavy reliance on Shared worker and
this would break our customer use cases.  We use shared worker
to co-ordinate Web RTC signalling and websocket management
which is critical for the app.
On Wednesday, May 31, 2023 at 8:42:15 AM UTC-7
mk...@chromium.org wrote:

LGTM3 with all the caveats about careful rollout discussed
above.

-mike


On Tue, May 30, 2023 at 5:39 PM Mike Taylor
 wrote:

OK - let's consider this I2S officially revived.
Looking for a 3rd LGTM to begin shipping in M115.

We have implemented 3rd party deprecation trial
support for M115+ (see

https://developer.chrome.com/blog/storage-partitioning-deprecation-trial/#participate-in-the-deprecation-trials),
and extended the deprecation trial's expiration date
accordingly to account for the delay. And we have the
Enterprise policy ready to go.

The rollout schedule will look something like the
following, pending metrics and compatibility stability:

July 25th: 1% of Stable population (approximately 1
week after M115 is released)
Aug 8th: 10%
Aug 22nd: 50%
Sep 5: 100%

As always, if we discover significant user-facing
breakage we'll explore pausing or rolling back to address.

thanks,
Mike

On 5/1/23 10:43 AM, Mike Taylor wrote:


Thanks Rick and Yoav.

We learned from two partners (one internal, one
external) late last week that a 3P deprecation trial
would be needed for them to preserve widely-used
functionality while they work on a migration strategy.

We're tracking the work in crbug.com/1441411
<http://crbug.com/1441411> and hope to have that
ready by M115. Once we land the fix, I'll circle back
and look for a 3rd LGTM and have an updated rollout
schedule. :)

On 5/1/23 12:21 AM, Yoav Weiss wrote:

LGTM2

On Thu, Apr 27, 2023

Re: [blink-dev] Intent to Ship: WebAuthn PRF extension

[Mike Taylor]

This will hit stable in M116.

I don't see any movement on 
https://github.com/mozilla/standards-positions/issues/798 or 
https://github.com/WebKit/standards-positions/issues/183, but there may 
be bugs in their public trackers you can find and follow.


On 7/24/23 8:11 PM, Vivek Bhupatiraju wrote:
Amazing! When can we expect to see this in stable Chrome releases? And 
are there any updates on this feature in other browsers?


On Monday, July 24, 2023 at 4:58:32 PM UTC-7 Adam Langley wrote:

On Sat, Jul 22, 2023 at 2:15 PM Vivek Bhupatiraju
 wrote:

Are there any updates on this Intent To Ship? I would also
love this extension as it allows for an amazing UX for encryption.


Default-enabled in Chrome M116, so you should be able to
experiment with it on Beta channel ahead of the M116 release.


Cheers

AGL

--
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/f188db04-9f77-45c3-b3d4-efea6acd6793n%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/806203a0-2036-ae56-1bff-8913a2d2f31f%40chromium.org.

Re: [blink-dev] Intent to Ship: Protected Audience features: recency, rounding bids & scores

[Mike Taylor]

LGTM2

On 7/26/23 12:10 PM, Chris Harrelson wrote:

LGTM1

On Tue, Jul 25, 2023 at 5:31 PM Paul Jensen  
wrote:



Contact emails

pauljen...@chromium.org


Explainer


https://github.com/WICG/turtledove/pull/639/files?short_path=d65ba97#diff-d65ba9778fe3af46de3edfce2266b5b035192f8869280ec07179963b81f4e624




https://github.com/WICG/turtledove/pull/486/files?short_path=d65ba97#diff-d65ba9778fe3af46de3edfce2266b5b035192f8869280ec07179963b81f4e624




Specification

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


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



Summary

This I2S covers two features extending Protected Audience:


Recency:

The “recency” signal for Protected Audience interest groups
indicates how long ago the user was joined to an interest group,
which can be a useful signal when calculating an ad auction bid
(e.g. recently expressed interest likely indicates more
interest).  Previously we provided this signal in a strictly
bucketed and noised form to buyers’ win reporting function,
reportWin(). This
change additionally exposes this signal to the buyers’ bidding
function, generateBid().  It can be provided without bucketing or
noising to generateBid() like other signals available in that
function. In fact, Protected Audience already allows developers to
calculate this signal (e.g. by storing join time in the interest
group), but developers have asked (see “Web Developers” section
below) to have the browser supply it to generateBid() to ensure
it’s calculated identically to the value supplied to the reporting
function, so that models training on the reported data are
compatible with bidding.


Rounding bids and scores:

In Protected Audience, the bid price and desirability score pass
from functions that have access to cross-site data (generateBid()
and scoreAd()) to the reporting worklets that have access to first
party data (reportWin() and reportResult()), so to prevent
event-level win reports from facilitating cross-site identity
joins, we need to limit this data as much as possible.  This
change limits the information in the bid price and desirability
score by rounding them from 64-bit floating-point numbers to
16-bit floating point numbers. Previously these numbers were not
rounded.


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

Recency:This is unlikely to break existing sites as it’s only
adding a new field to an object the browser provides to Protected
Audience bidding and scoring scripts.

Rounding:This is unlikely to break existing sites as it’s only
clearing some of the less significant bits of the bid and score
values, while not changing the most significant bits or where the
values flow from and to.


Gecko : No signal on parent proposal, Protected Audience.
Asked here
and
here .


Web developers:

Recency:Adtechs asked for the recency feature here
as
part of the larger ask
.

Rounding:This has been part of Protected Audience’s plan to
accomplish our privacy goals for some time.  We haven’t heard
significant resistance.


Debuggability

These features affect values provided to Protected Audience
scripts (generateBid(), reportResult(), reportWin()) which are
debuggable via Chrome DevTools.


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

?

These are in 

Re: [blink-dev] Intent to Experiment: Compression dictionary transport with Shared Brotli

[Mike Taylor]

LGTM to experiment from 117 to 122 inclusive.

(Good luck, looks cool!)

On 7/25/23 9:52 PM, Tsuyoshi Horo wrote:



Contact emails


h...@chromium.org, pmee...@chromium.org,
yoavwe...@chromium.org, kenjibah...@chromium.org


Explainer


https://github.com/WICG/compression-dictionary-transport


Specification


https://github.com/WICG/compression-dictionary-transport


Design docs




https://docs.google.com/document/d/1IcRHLv-e9boECgPA5J4t8NDv9FPHDGgn0C12kfBgANg/edit
https://github.com/WICG/compression-dictionary-transport

https://datatracker.ietf.org/doc/draft-meenan-httpbis-compression-dictionary


Summary


This feature adds support for using designated previous
responses, as an external dictionary for Brotli-compressing
HTTP responses.



Blink component


Blink>Network




TAG review


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


TAG review status


Pending


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('dictionary')`.
Also web servers can know the browser support by checking the
`Accept-Encoding` request header and the new
`Use-As-Dictionary` request header. 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 usable only on secure-context. So this feature will
not increase the risk of non-supporting network proxies
misunderstanding the content’s encoding.



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

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

/Web developers/: No signals

/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. Currently there is no major server
softwares which supports compression dictionaries.



Security


Chrome registers the response as a dictionary only when the
response is CORS-readable from the document origin. Also we
use a registered dictionary to decompress the response only
when the response is CORS-readable from the document origin.
Additionally, the dictionary and the compressed resource are
required to be from the same origin as each other. So this
should not introduce any new attack vector of stealing
information. The dictionaries are partitioned with the storage
cache and are cleared whenever cookies or cache is cleared to
ensure that the dictionaries can not be abused as a tracking
vector.



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


We would like to collect feedback on the Compression
Dictionary Transport feature of API design. We would also like
to run some experiments using this feature to measure its
performance impact.


Ongoing technical constraints


None



Debuggability


We have introduced chrome://net-internals/#sharedDictionary.
Using it, web developers can manage the registered
dictionaries. Also web developers can check the related HTTP
request and response headers (Use-As-Dictionary,
Sec-Available-Dictionary, Accept-Encoding, Content-Encoding)
using DevTools' Network tab.



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


Yes

Re: [blink-dev] Intent to Ship: Media Queries: prefers-reduced-transparency feature

[Mike Taylor]

As to the fingerprintability, we should think about the trade-offs we're 
making between accessibility and adding more active surfaces that give 
away some bits of entropy. I'd love to hear more about requests from the 
a11y or developer community to actually have this MQ available to them. 
My own take is that if it can benefit some users, and sites will use it, 
the incremental entropy available here is probably acceptable.


I note that https://drafts.csswg.org/mediaqueries-5/#mq-prefers-security 
is effectively empty, with an inline issue saying ~"TODO: figure out if 
these are OK". That doesn't seem super great. Do we know if there is 
consensus among editors on the utility vs privacy trade offs of these 
MQs? (Maybe Tab can chime in on this topic...).


Based on 
https://github.com/WebKit/standards-positions/issues/145#issuecomment-1478736469, 
it doesn't seem like there's a lot of appetite from Apple or Mozilla.


On 7/24/23 4:13 AM, Yoav Weiss wrote:
I'd love to hear +Mike Taylor <mailto:miketa...@chromium.org> 's 
thought about this from an extra fingerprinting bit perspective. Also, 
how would users signal their preference?


On Fri, Jul 21, 2023, 23:21 Luke  wrote:


Contact emails

lukewarlow...@gmail.com, l...@warlow.dev


Explainer

None


Specification

https://drafts.csswg.org/mediaqueries-5/#prefers-reduced-transparency


Summary

Adds the `prefers-reduced-transparency` feature, which lets
authors adapt web content to user-selected preference for reduced
transparency in the OS, such as the 'Reduce transparency' setting
on macOS. Valid options are 'reduce' or 'no-preference'.



Blink component

Blink>CSS
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ECSS>


Search tags

css <https://chromestatus.com/features#tags:css>,
prefers-reduced-transparency
<https://chromestatus.com/features#tags:prefers-reduced-transparency>


TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility



/Gecko/: No signal
(https://github.com/mozilla/standards-positions/issues/851) There
is a separate umbrella issue for some the preference media queries
(contrast, motion, color-scheme). They have a stale PR to add an
overall positive position for those preference media queries. They
also have an implementation behind a flag. It's not been enabled
yet due to fingerprinting concerns.

/WebKit/: No signal
(https://github.com/WebKit/standards-positions/issues/145) I have
submitted an implementation of this feature as a PR to WebKit:
https://github.com/WebKit/WebKit/pull/11560

/Web developers/: Positive
(https://blog.logrocket.com/new-media-queries-you-need-to-know)

/Other signals/:


Security

This feature can be used for fingerprinting as it exposes a user
preference.



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?



Debuggability

This can be emulated in the Dev Tools rendering tab like other
preference media queries.



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

Yes

The feature will be supported on all platforms, but whether the
user will be able to signal a reduced transparency preference may
depend on the OS.



Is this feature fully tested by web-platform-tests

<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?

Yes


Flag name on chrome://flags

#enable-experimental-web-platform-features


Finch feature name

PrefersReducedTransparency


Requires code in //chrome?

False


Tracking bug

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


Sample links



https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-reduced-transparency#examples


Estimated milestones

Shipping on desktop 117
DevTrial on desktop 117

Shipping on Android 117
DevTrial on Android 117



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



Link to entry on the Chrome Platform Status

https://chromestatus.com/f

Re: [blink-dev] Intent to Prototype: Sec-CH-Prefers-Reduced-Transparency User Preference Media Features Client Hints Header

[Mike Taylor]

Thanks for the links - when you get to the I2S stage, it's probably a 
good idea to add a comment to each letting them know that there's a 
proposal to ship this new one.


On 7/24/23 2:47 PM, Luke wrote:
Just to follow up on the position request. A position request was 
filed as part of the original user preference client hint 
implementation and neither have had a response.


Mozilla Position request 
https://github.com/mozilla/standards-positions/issues/526


WebKit Position request 
https://github.com/WebKit/standards-positions/issues/15


On Monday, 24 July 2023 at 19:36:18 UTC+1 Luke wrote:

> Have we asked for signals?

I haven't filed position requests yet. I will do before submitting
an intent to ship however.

> If Google Search is asking for this, it seems like we have some
signal, no?

To clarify Google Search aren't asking for this client hint
specifically. But they were a use case for the color scheme
preference client hint. The Motivation section was largely a copy
from previous preference client hints as a general explanation for
the system. This feature is mainly just for completeness of the
`prefers-reduced-transparency` implementation.

Some of the other sections I hadn't filled out on the chromestatus
page apologies. I have addressed your specific questions below and
will update the status page.

> Debuggability

Developers can change this client hint header value by emulating
prefers-reduced-transparency via Devtools in the Rendering Panel.

> Web Platform Tests

This feature will be tested as much as possible in WPT tests.

> FInch Feature

My understanding of the exact feature mechanics is a bit lacking
here. But a kClientHintsPrefersReducedTransparency feature has
been added to blink/public/common/features.h I believe this is
togglable via finch? (It's disabled by default for now)

On Monday, 24 July 2023 at 19:23:06 UTC+1 mike...@chromium.org wrote:


On 7/20/23 8:19 AM, Luke wrote:

Contact emails lukewa...@gmail.com, lu...@warlow.dev

Explainer

https://github.com/wicg/user-preference-media-features-headers/blob/main/README.md

Specification

https://wicg.github.io/user-preference-media-features-headers/#sec-ch-prefers-reduced-transparency

Summary

User Preference Media Features Client Hints Header defines a
set of HTTP Client Hints headers around user preference media
features as defined by Media Queries Level 5. If used as
Critical Client Hints, these headers allow servers to make
smart choices regarding, e.g., CSS inlining.
Sec-CH-Prefers-Reduced-Transparency reflects the user's
prefers-reduced-transparency preference.



Blink component Blink>CSS



Motivation

CSS media queries, and specifically user preference media
features like `prefers-reduced-transparent` or
`prefers-reduced-motion`, have a potentially significant
impact on the amount of CSS that needs to be delivered by a
page, and on the experience the user is going to have when
the page loads. Focusing on `prefers-color-scheme`—but
highlighting that the reasoning applies to other user
preference media features as well—it is a best practice to
not load CSS for the particular non-matching color scheme in
the critical rendering path, and instead to initially only
load the currently relevant CSS. One way of doing so is via
``. However, high-traffic sites like Google
Search that wish to honor user preference media features like
`prefers-color-scheme` and that inline CSS for performance
reasons, need to know about the preferred color scheme (or
other user preference media features respectively) ideally at
request time, so that the initial HTML payload already has
the right CSS inlined.



Initial public proposal
https://github.com/w3c/csswg-drafts/issues/4162

Search tags client hints
,
sec-ch-prefers-reduced-transparency

,
prefers-reduced-transparency


TAG review

TAG review status Pending

Risks


Interoperability and Compatibility

/Gecko/: No signal

/WebKit/: No signal


Have we asked for signals?



/Web developers/: No signals

If Google Search is asking for this, it seems like we have
some signal, no?



/Other signals/:

WebView application risks

Does this intent deprecate or change behavior of existing

Re: [blink-dev] PSA: Warning on Insecurely-Delivered Downloads

[Mike Taylor]

On 7/21/23 2:22 PM, Joe DeBlasio wrote:

Hi blink-dev!

Starting shortly after HTTPS Upgrades 
 
ships, Chrome will start showing warnings when a user downloads files 
over an insecure (i.e. non-TLS) connection. This builds on top of the 
previously shipped 
 blocking 
of insecurely delivered files initiated on secure pages ("mixed 
downloads").


This user-agent intervention should cause no site breakage, but it may 
mean users see additional (bypassable) warnings if your site relies on 
insecure downloads.


Developers who wish to avoid their users seeing these warnings should 
ensure that all downloads are served securely -- warnings are 
triggered when insecure HTTP is used by the final download URL, any 
URLs that redirect to the download, or on the page on which the 
download was initiated.


While there isn't a public explainer for this change, a blog post with 
additional details is forthcoming. I'm also happy to answer any 
additional questions here.
That sounds great, please respond with a link to the blog post once it's 
published.


Joe
--
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/CAFZs0S5nA%2BBv3z%3DkQuJWZEtsxz%2B_6Q4ghHdi0dWeWnfV7vrtJQ%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/54b86625-de0a-c614-8f34-b71a03040a10%40chromium.org.

Re: [blink-dev] Intent to Implement and Ship: Per-frame quantizer in VideoEncoder

[Mike Taylor]

Thanks Eugene for the additional explainer text - and thanks to Alex for 
encouraging more work here.


On 7/20/23 10:04 AM, Chris Harrelson wrote:

LGTM3. Thank you!

On Thu, Jul 20, 2023, 5:46 AM Daniel Bratell  wrote:

LGTM2

/Daniel

On 2023-07-20 05:53, Yoav Weiss wrote:

LGTM1

Thanks for the explainer!!

On Thu, Jul 20, 2023 at 1:18 AM Eugene Zemtsov
 wrote:

Thanks for the feedback.
I put together an explainer and linked it on the ChromeStatus
feature page:

https://gist.github.com/Djuffin/3722232679b977058be787be0dff4254

On Wed, Jul 19, 2023 at 8:57 AM Alex Russell
 wrote:

I *think* I grok what this is for, and I'm still pretty
frustrated that there isn't a crisp summary along the
lines of "this parameter helps sites implement custom
bitrate vs. quality vs. CPU use tradeoffs for different
kinds of media and streams, which are important to
customers like X, Y, and Z".

Eugene, Philipp: it's important that the Blink process
show that we are shipping important features that solve
real problems, particularly when we're in the position of
shipping first. We *want* to trust the WebRTC/media
community to work with us to launch API changes quickly,
and demonstrating need is part of that. Can you respond
with an overview (perhaps in the form of an Explainer),
and/or perhaps have potential users of this API chime in?

Best,

Alex

On Wednesday, July 19, 2023 at 8:14:16 AM UTC-7 Yoav
Weiss wrote:

On Wed, Jul 19, 2023 at 2:51 PM Philipp Hancke
 wrote:

Am Mi., 19. Juli 2023 um 14:25 Uhr schrieb Yoav
Weiss :



On Thu, Jul 13, 2023 at 10:53 PM 'Eugene
Zemtsov' via blink-dev
 wrote:

Any new feedback or resolution on this one?

On Fri, Jul 7, 2023 at 5:53 AM Sangwhan
Moon  wrote:

(resending from correct email)

On 2023年07月07日 00時32分12秒 (+09:00),
    Mike Taylor wrote:

On 7/5/23 8:57 PM, 'Eugene
Zemtsov' via blink-dev wrote:


Intent to Implement and Ship:
Per-frame quantizer in VideoEncoder


Contact emails

ezemt...@google.com


Explainer

None



I think an explainer can be significantly
helpful in helping us understand how
developers will be using this feature and
what use cases it'd cover.
Could you write one or add an inline
explanation outlining that?


Explaining that is tough without going into the
details "what is quantization for video codecs. See

https://www.vcodex.com/h264avc-4x4-transform-and-quantization/
for a very detailed explanation for H264.

the tl;dr is that folks who encode video like
tuning all kinds of knobs to get the "best"
result and qp is one of those.


An explainer doesn't have to assume folks reading it
don't know what quantization means :)

Basically, clicking through the specs, it's still not
clear to me if the quantization values are provided
as a single int that quantization tables are supposed
to be divided by. a "quality" int that represents a
certain quantization table, or something else
entirely. Clarity on that would be great.



Specification


https://www.w3.org/TR/webcodecs/#video-encoder-bitrate-mode

<https://www.w3.org/TR/webcodecs/#video-encoder-bitrate-mode>


Summary

Adds "quantizer"
VideoEncoderBitrateMode for
VideoEncoder. This allows to
specify a quantizer parameter
for each frame for AV1, VP9, and
AVC video codecs. The quantizer
 

Re: [blink-dev] Intent to Prototype: Sec-CH-Prefers-Reduced-Transparency User Preference Media Features Client Hints Header

[Mike Taylor]

On 7/20/23 8:19 AM, Luke wrote:



Contact emails

lukewarlow...@gmail.com, l...@warlow.dev


Explainer

https://github.com/wicg/user-preference-media-features-headers/blob/main/README.md


Specification

https://wicg.github.io/user-preference-media-features-headers/#sec-ch-prefers-reduced-transparency


Summary

User Preference Media Features Client Hints Header defines a set of 
HTTP Client Hints headers around user preference media features as 
defined by Media Queries Level 5. If used as Critical Client Hints, 
these headers allow servers to make smart choices regarding, e.g., CSS 
inlining. Sec-CH-Prefers-Reduced-Transparency reflects the user's 
prefers-reduced-transparency preference.




Blink component

Blink>CSS 




Motivation

CSS media queries, and specifically user preference media features 
like `prefers-reduced-transparent` or `prefers-reduced-motion`, have a 
potentially significant impact on the amount of CSS that needs to be 
delivered by a page, and on the experience the user is going to have 
when the page loads. Focusing on `prefers-color-scheme`—but 
highlighting that the reasoning applies to other user preference media 
features as well—it is a best practice to not load CSS for the 
particular non-matching color scheme in the critical rendering path, 
and instead to initially only load the currently relevant CSS. One way 
of doing so is via ``. However, high-traffic sites like 
Google Search that wish to honor user preference media features like 
`prefers-color-scheme` and that inline CSS for performance reasons, 
need to know about the preferred color scheme (or other user 
preference media features respectively) ideally at request time, so 
that the initial HTML payload already has the right CSS inlined.




Initial public proposal

https://github.com/w3c/csswg-drafts/issues/4162


Search tags

client hints , 
sec-ch-prefers-reduced-transparency 
, 
prefers-reduced-transparency 




TAG review



TAG review status

Pending


Risks



Interoperability and Compatibility



/Gecko/: No signal

/WebKit/: No signal


Have we asked for signals?



/Web developers/: No signals

If Google Search is asking for this, it seems like we have some signal, no?


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




Debuggability


Anything to note here?



Is this feature fully tested by web-platform-tests

?

No

Why not?



Flag name on chrome://flags



Finch feature name


Presumably we have a base::Feature, non?



Non-finch justification

None


Requires code in //chrome?

False


Tracking bug

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


Estimated milestones

No milestones specified



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6242983812268032


Links to previous Intent discussions



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/B1ED49A6-31BF-4D28-89B3-D2973F9F12DA%40gmail.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/867747f8-d6e2-2a36-0a03-0cec081f5274%40chromium.org.

Re: [blink-dev] Intent to Experiment: Zstd Content-Encoding

[Mike Taylor]

Can you clarify the proposed experiment (presumably N% of stable?) and 
the desired milestones? Thanks!


On 7/14/23 4:57 AM, Nidhi Jaju wrote:



Contact emails

nidhij...@chromium.org


Explainer

https://docs.google.com/document/d/1aDyUw4mAzRdLyZyXpVgWvO-eLpc4ERz7I_7VDIPo9Hc/edit?usp=sharing


Specification

https://datatracker.ietf.org/doc/html/rfc8878


Design docs

https://docs.google.com/document/d/14dbzMpsYPfkefAJos124uPrlkvW7jyPJhzjujSWws2k/edit?usp=sharing


Summary

Zstandard, or “zstd”, is a data compression mechanism described in 
RFC8878. It is a fast lossless compression algorithm, targeting 
real-time compression scenarios at zlib-level and better compression 
ratios. The "zstd" token was added as an IANA-registered 
Content-Encoding token as per 
https://datatracker.ietf.org/doc/html/rfc8878#name-content-encoding. 
Adding support for "zstd" as a Content-Encoding will help load pages 
faster and use less bandwidth.



Blink component

Internals>Network 




TAG review

None


TAG review status

Not applicable


Risks


Interoperability and Compatibility

Servers that have a broken implementation of zstd might exist, but the 
risk of this is small. Additionally, middleware and middleboxes like 
virus checkers that intercept HTTPS connections might not support 
zstd, but might fail to remove it from the Accept-Encoding header in 
the request.



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


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


/Web developers/: Positive (https://crbug.com/1246971) Facebook (Yann) 
and Akamai (Nic) seem to be positive about zstd content-encoding in 
the browser. Facebook is also excited to test the feature.


/Other signals/:


Security

CRIME and BREACH mean that the resource being compressed can be 
considered readable by the document deploying them. That is bad if any 
of them contains information that the document cannot already obtain 
by other means. An attacker may provide correctly formed compressed 
frames with unreasonable memory requirements, and dictionaries may 
interact unexpectedly with a decoder, leading to possible memory or 
other resource-exhaustion attacks. It is possible to store arbitrary 
user metadata in skippable frames, so they can be used as a watermark 
to track the path of the compressed payload. It is important to note 
that these concerns apply to all compression formats, not just zstd.


To mitigate these risks, similar to Brotli, we'll be advertising 
support for "zstd" encoding only if transferred data is opaque to 
proxy, to ensure that resources don't contain private data that the 
origin cannot read otherwise.


Adding zstd to Chromium adds a large new code surface that processes 
untrusted data, which inevitably brings risks of new security holes. 
However, this is mitigated by the extensive fuzzing and security 
analysis done on zstd by Google and other community members.



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

Understand the impact of supporting zstd content-encoding in the 
browser on performance and if there's breakage.



Ongoing technical constraints



Debuggability

No special support needed. Zstd content-encoding support will be 
exposed to the devtools protocol, so developers are able to override 
it and view the headers from the inspector.



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


Flag name on chrome://flags

enable-zstd-content-encoding


Finch feature name

ZstdContentEncoding


Requires code in //chrome?

True


Tracking bug

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


Launch bug

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


Estimated milestones

Shipping on desktop 117

Shipping on Android 117

Shipping on WebView 117



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6186023867908096


Links to previous Intent discussions

Intent to prototype: 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMZNYANd_E77W1ki--h_XJM-%2B_fA3w1CriGgJmnbh1N3LwRDtw%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 

Re: [blink-dev] Intent to Ship: MathML columnspan/rowspan attributes on element

[Mike Taylor]

LGTM1 - seems like an obvious interop win.

On 7/12/23 4:31 AM, Frédéric Wang wrote:



Hello,

This is actually an intent to ship (sorry for sending email with the 
wrong title).


To summarize a bit conversations, columnspan/rowspan was something 
that was requested by web developers and is used in existing 
documents. We cannot just say "use CSS instead" as they are no 
equivalent properties.


Initially, we wanted to have this in the initial MathML implementation 
but things were postponed because we needed to decide between "make 
things more compatible with HTML" (i.e. colspan/rowspan names) or 
"make things backward compatible with MathML3" (i.e. 
columnspan/rowspan names). Given the latter is already implemented by 
Firefox/WebKit and used in existing documents and tools we decided to 
go with the latter (Mozilla also positioned negatively about changing 
the name).




-



Contact emails

fw...@chromium.org


Explainer

None


Specification

https://w3c.github.io/mathml-core/#entry-in-table-or-matrix-mtd


Summary

Implement attributes to specify the number of columns and rows that a 
MathML table cell is to span. This is similar to HTML colspan/rowspan 
attributes and does not have equivalent CSS properties.




Blink component

Blink>MathML 
MathML> 




TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility



/Gecko/: Shipped/Shipping 
(https://developer.mozilla.org/en-US/docs/Web/MathML/Element/mtd#browser_compatibility) 
Mozilla positioned negatively about renaming 
https://github.com/mozilla/standards-positions/issues/74
(Note: this should be 
https://github.com/mozilla/standards-positions/issues/743)



/WebKit/: Shipped/Shipping 
(https://developer.mozilla.org/en-US/docs/Web/MathML/Element/mtd#browser_compatibility) 



/Web developers/: Positive

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




Debuggability



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
Tests are added in 
https://chromium-review.googlesource.com/c/chromium/src/+/4061476 
However, advanced parsing such as checking the max limits 1000 and 
65534 defined in HTML is a bit tedious as MathML does not have an IDL 
for tables yet ( 
https://github.com/w3c/mathml-core/issues/166#issuecomment-1411721093 
 
) so for now they are written as internal tests.



Flag name on chrome://flags



Finch feature name



Non-finch justification

None


Requires code in //chrome?

False


Estimated milestones

Shipping on desktop 117

Shipping on Android 117

Shipping on WebView 117



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




Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5157467960377344


Links to previous Intent discussions

Intent to Experiment: 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2603ac64-2367-434f-cee3-42b3d9111639%40igalia.com 




This intent message was generated by Chrome Platform Status 
.



--
Frédéric Wang
--
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/c3ada6e8-03f7-57e6-7b63-9ccf3d9a4440%40igalia.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/8a331320-cb6b-e102-05f9-d38abcb80a7a%40chromium.org.

Re: [blink-dev] Re: Intent to Ship: Support stroke-box, content-box and border-box in the transform-box CSS property

[Mike Taylor]

LGTM2

On 7/12/23 11:19 AM, Yoav Weiss wrote:

LGTM1 - thanks for catching us up here!

On Thursday, July 6, 2023 at 1:33:39 PM UTC+2 f...@opera.com wrote:


Contact emails


f...@opera.com


Explainer


None (see summary)


Specification


https://www.w3.org/TR/css-transforms-1/#transform-box



Summary


Allows changing how the reference box for the 'transform'
property is computed. This adds additional capabilities
that will allow creating transforms/graphical effects
where - for example - the width of the border of an
element does not influence the result (e.g rotation around
a point in the content box) or the stroke of an (SVG)
element should influence the result (e.g rotating a
stroked shape around its center - including the stroke).


Blink component


Blink>SVG




TAG review


None


TAG review status


Not applicable


Risks




Interoperability and Compatibility


Low interoperability risk. The feature being part of
Interop2023 gives it a decent chance of becoming
interoperable - at least within the subset that is tested
in that scope.



/Gecko/: No signal This is small change that is in scope
of Interop2023

/WebKit/: Shipped/Shipping
(https://webkit.org/blog/10247/new-webkit-features-in-safari-13-1
)
Implemented since TP 96

/Web developers/: Positive (https://crbug.com/924472) 9+
stars in the bug tracker

/Other signals/:


WebView application risks


Minimal (adds a couple of new keywords to an existing
property)



Debuggability




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://flags




Finch feature name


CSSTransformBoxAdditionalKeywords


Requires code in //chrome?


False


Sample links


https://developer.mozilla.org/en-US/docs/Web/CSS/transform-box



Estimated milestones


Shipping on desktop 117

Shipping on Android 117

Shipping on WebView 117



Anticipated spec changes


None


Link to entry on the Chrome Platform Status


https://chromestatus.com/feature/6208828575580160



Links to previous Intent discussions


Original I2S for the transform-box property:

https://groups.google.com/a/chromium.org/g/blink-dev/c/4ZWHz8tCONI/m/XBTvQtw2BAAJ



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/2c2df193-d602-4b6e-9cf8-5658dd0ffd43n%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/dd96b694-a5d0-b477-43ee-eb6283d77676%40chromium.org.

Re: [blink-dev] Intent to Ship: Array grouping

[Mike Taylor]

LGTM1

On 7/11/23 1:33 PM, Shu-yu Guo wrote:



Contact emails

s...@chromium.org


Explainer

https://github.com/tc39/proposal-array-grouping/blob/main/README.md


Specification

https://tc39.es/proposal-array-grouping/


Summary

Adds news Object.groupBy(iterable, groupCallback) and 
Map.groupBy(iterable, groupCallback) to perform a grouping or 
bucketing operation. The Object method returns a plain object, where 
the groups are property keys. The Map method returns a Map, where the 
keys can be arbitrary values.




Blink component

Blink>JavaScript>Language 




TAG review



TAG review status

Not applicable


Risks



Interoperability and Compatibility

Minimal. These are static methods on Object and Map, which are very 
unlikely to cause incompat. The previous Array.prototype version 
caused significant compat issues and the proposal was redesigned.




/Gecko/: Shipped/Shipping 
(https://bugzilla.mozilla.org/show_bug.cgi?id=1739648)


/WebKit/: Shipped/Shipping 
(https://bugs.webkit.org/show_bug.cgi?id=234327)


/Web developers/: Strongly positive 
(https://twitter.com/rauschma/status/1470854996459769867?s=20=DDr_7gzapEKcfF2MbEVzHA 
)


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




Debuggability

This feature adds two new built-in Array.prototype methods, which are 
debuggable like all other built-in methods.




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

?

In test262:
https://github.com/tc39/test262/tree/main/test/built-ins/Object/prototype/groupBy
https://github.com/tc39/test262/tree/main/test/built-ins/Map/prototype/groupBy


Flag name on chrome://flags

--harmony-array-grouping


Finch feature name



Non-finch justification

None


Requires code in //chrome?

False


Tracking bug

https://bugs.chromium.org/p/v8/issues/detail?id=12499


Estimated milestones

DevTrial on desktop 100

DevTrial on Android 100



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




Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5714791975878656


Links to previous Intent discussions


Note that this is a new version of the proposal, redesigned
after web incompatibility prevented shipping in the previous
version and was unshipped by all the browsers. The previous
I2S is here

.




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-e9e94MKs3PgCqPG6E-7x_%2BfH8Z4AFLMC0Bva-dZrVBogKtA%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/c666418f-ca53-cba7-718d-64eed78e6016%40chromium.org.

Re: [blink-dev] Re: Intent to Ship: HTTPS pages with Cache-control: no-store and Back/Forward Cache

[Mike Taylor]

On 7/11/23 2:19 AM, 'Fergal Daly' via blink-dev wrote:


[BCC chrome-bfca...@google.com]

On Tue, 11 Jul 2023 at 15:16, Mingyu Lei  wrote:

+chrome-bfcache 

On Tue, Jul 11, 2023 at 1:08 PM Mingyu Lei  wrote:


Contact emails

kenjibah...@chromium.org, fer...@chromium.org,
denom...@chromium.org, le...@chromium.org


Specification

https://github.com/fergald/explainer-bfcache-ccns/blob/main/README.md


Design docs


https://docs.google.com/document/d/1qX1w6L6laTzpFTh78dvT7wwC1060Z3he2Azp4BAwsUE/edit?usp=sharing
https://github.com/fergald/explainer-bfcache-ccns/blob/main/README.md


This is a really well-written explainer, thank you!

One point of clarification:

https://github.com/fergald/explainer-bfcache-ccns/blob/main/README.md#secure-cookies 
references "HTTPS-only" cookies, as well as "secure" vs "insecure" 
cookies. By "HTTPS-only", do you mean a cookie that sets the "secure" 
attribute (including "__Secure-" prefixes), _and_ sets "HttpOnly"? Or 
something else?


Later in 
https://github.com/fergald/explainer-bfcache-ccns/blob/main/README.md#allow-ccns-documents-to-be-bfcached-without-the-api, 
the proposal is that CCNS pages are safe to bfcache if no "HTTP-only" 
cookies have changed. Are these cookies setting only the "HttpOnly" 
attribute, or is this intended to say "HTTPS-only" as above?




Summary

A behavior change to safely store (and restore) pages in the
Back/Forward Cache despite the presence of a "Cache-control:
no-store" HTTP header on HTTPS pages. This would allow pages
to enter BFCache and be restored as long as there are no
changes to cookies or to RPCs using the `Authorization:` header.



Blink component

UI>Browser>Navigation>BFCache




Search tags

bfcache 


TAG review

I see that 
https://github.com/w3ctag/design-reviews/issues/786#issuecomment-1515742477 
references this work. Did we learn anything from experimentation in the 
wild (not sure if y'all ran an experiment)?




TAG review status

Not applicable


Risks



Interoperability and Compatibility

I'm curious if y'all have looked at stats on the uptake of 
secure/httponly cookies vs "non-secure" cookies being set by pages 
returned from RPCs sent with an Authorization header (though I wouldn't 
be surprised if we don't have UMA for that... perhaps just globally 
would be useful to consider).


My only concern (which may not be grounded in reality) would be for 
sites not following best practices...





/Gecko/: No signal

/WebKit/: No signal


Can we request signals?



/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



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

No

BFCache is not supported on WebView, so this change has no
impact there.



Is this feature fully tested by web-platform-tests

?

No


Flag name on chrome://flags



Finch feature name

CacheControlNoStoreEnterBackForwardCache


Requires code in //chrome?

False


Tracking bug

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


Launch bug

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


Estimated milestones

DevTrial on desktop 116

DevTrial on Android 116



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


Links to previous Intent discussions



This intent message was generated by Chrome Platform Status
.

--
You received 

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

[Mike Taylor]

LGTM1

On 7/10/23 2:04 PM, Alex Turner wrote:
As a quick update, the WebDriver extension PR has now landed. (Thanks 
Mathias for the review!) So, it should be safe to include that change 
as part of this I2S.


On Mon, Jul 10, 2023 at 4:00 AM Mathias Bynens  wrote:

Thank you for including a WebDriver extension

for this; I’ve left some review feedback on the PR. Overall, I
wanted to voice my support for pursuing the Web Platform feature
(and this Intent) separately from the WebDriver extension, as long
as you’re confident in the testing strategy — no need to block on it.

On Friday, July 7, 2023 at 4:28:39 PM UTC+2 yoav...@chromium.org
wrote:

On Fri, Jul 7, 2023 at 3:48 PM Alex Turner
 wrote:



On Thu, Jul 6, 2023 at 8:42 PM Rick Byers
 wrote:

On Wed, Jun 28, 2023 at 12:34 PM Alex Turner
 wrote:


On Wed, Jun 28, 2023 at 11:53 AM Rick Byers
 wrote:

On Mon, Jun 26, 2023 at 12:32 PM Yoav Weiss
 wrote:

I wanted to comment on this intent with my
spec mentor hat on. I reviewed this
specification and provided feedback to its
authors.

My main point of feedback was around its
layering and how it relates to the other 2
specifications (Shared Storage and
Protected Audience) that use the
infrastructure that it defines. My
feedback was properly addressed, and the
specification was re-written such that
it's unaware of its users, and its users
are calling its algorithms, rather than
the other way around.
There's still work to be done to move the
user algorithms from monkeypatch sections
in this spec to their respective
specifications, but I wouldn't consider
that a blocker and I trust the team to do
that soon.
Beyond that, feedback around naming


was addressed and I believe that
ergonomics feedback


can be addressed in a backwards compatible
manner.

As is, I believe the specification is in
good shape to be implemented
interoperably. I also believe the team is
committed to improve it further on the
(non-blocking) points that are still
outstanding.


Thanks Yoav for the spec mentorship summary.

On Wed, Jun 21, 2023 at 5:33 PM Alex
Turner  wrote:



On Tue, Jun 20, 2023 at 5:39 PM Rick
Byers  wrote:


On Tue, Jun 20, 2023 at 4:51 PM
Alex Turner 
wrote:


Contact emails

ale...@chromium.org


Explainer


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


Specification


https://patcg-individual-drafts.github.io/private-aggregation-api


Summary

A generic mechanism for
measuring aggregate,
cross-site data in a privacy
preserving manner. The
potentially identifying
cross-site data is
encapsulated into
"aggregatable reports". To
prevent leakage, this data is
encrypted, ensuring it can
only 

Re: [blink-dev] Intent to Ship: Attribution Reporting API

[Mike Taylor]

LGTM3

On 7/10/23 12:15 PM, Chris Harrelson wrote:

LGTM2

On Thu, Jul 6, 2023, 7:29 PM Rick Byers  wrote:

On Wed, Jun 28, 2023 at 5:23 AM Yoav Weiss
 wrote:


On Tue, Jun 27, 2023 at 9:43 PM John Delaney
 wrote:

Thanks, Yoav and Rick for the questions/discussion. See
responses below.

Can you expand (or point to existing docs) about the
differences between this and PCM? What's the
likelihood of future convergence? What are developers
expected to do in the meantime?


Unfortunately, while we were able to converge with the PCM
authors on nomenclature
,
the Attribution Reporting API differs substantially from
PCM in quite a few ways. We don’t have a detailed write-up
of all the differences, but if it seems useful we can
draft a document in our repo outlining detailed
differences (tracking issue here
).
Here is a short summary:


 *

ARA has support for "viewed" impressions, where PCM
only supports clicks

 *

The ability for attribution to be scoped to, and
reports sent to, third parties (issue

)

 *

Registration is performed via different mechanisms,
HTTP headers for ARA, PCM uses a combination of html
attributes and .well-known request parsing (see this
issue

as
an example of divergence)

 *

Reports contain different types of information, for
example a 64-bit identifier in event-level ARA, and an
8 bit identifier PCM

 *

Different limitations on the number and timing of
reports which are sent (issue

)


There is some documentation on high-level design
dimensions within PATCG here

.


Future convergence right now is not entirely clear, but
it's something we are actively working on in the PATCG.


We expect that developers will develop for these
measurement APIs when they are providing value for their
use-cases and customers, and that this will require
multiple different implementations switched on UA
currently. It's worth noting that, at present, the API
surfaces for these two APIs do not conflict with each
other (PCM won't cause any issues in Chrome and vice versa).


 +1. I spent 30 min looking over open issues, and
while many didn't have responses yet they largely all
felt like possible future extensions. Here's a couple
which seemed to me to be worthy of at least a response
or follow-up (if not a resolution) before I'd be
comfortable approving the I2S. There may be others
though, so I'd appreciate at least a quick triage pass
by experts on the team to focus API owner attention on
the issues which may cause future compat problems or
otherwise inhibit an interoperable implementation.


We went through and added a "compat" label for issues that
we feel have compat risk. For the issues linked here, we
are following up on those individually and will provide an
update soon.


Thanks! Going through the issues

,
I see a couple that I'm not sure have real compat
implications, but 4 more that do seem like it'd be good to
settle (or at least have a mental image of future-compatible
changes) before shipping.


Reviewing the current state of those issues, it seems things are
in pretty good shape, with a few small loose ends to tie up that
don't seem too risky to. me.

LGTM1


On Mon, Jun 26, 2023 at 12:08 PM Rick Byers
 wrote:

There's clearly a lot of interop risk around all the
different proposals in this space. At the same time,
it's clear this is one of the most important aspects
to the ads industry and so the huge amount of
collaborative 

Re: [blink-dev] Intent to Ship: Inherit Base URL snapshot for about:blank and about:srcdoc, with about:blank inheriting from initiator, not parent.

[Mike Taylor]

LGTM1

On 7/10/23 11:23 AM, Dominic Farolino wrote:
The niche-ness of these changes plus the fact that they've been rolled 
out on Canary+Dev for some time /and/ that we've already smoked out 
some compat issues at that level of experimentation for the adjacent 
work the team looked into (censoring the base URL for sandboxed 
about:srcdoc Documents) makes me fairly comfortable that we have a 
good grip on the compat implications of this, IMO.


On Fri, Jul 7, 2023 at 12:01 PM W. James MacLean 
 wrote:


At present there is no mechanism I'm aware of for tracking when
baseURIs are accessed in scenarios where the behavior might be
different from what is expected. I'm not quite sure what that
would look like exactly, as at the document level we don't expect
to know if initiator = parent or not. We expect the compat risk to
be quite low, as the initiator != parent case seems likely to be
rare. But it might not be zero and we don't have any numbers on
what it might actually be.

As Dominic mentioned, we think the risk is low enough that a
careful & gradual deployment (with a killswitch available, and an
enterprise policy in place to allow disabling the new behavior at
the enterprise level) should be safe. But if there's concern that
might not be safe enough, we can look into it further. I've held
off releasing this to beta for now, though it's been active on
canary+dev for quite a while now.

On Mon, 3 Jul 2023 at 00:03, Yoav Weiss 
wrote:

A couple of questions:

  * Should we wait until the PR matures a bit and gets
reviewed? WebKit's position is encouraging, but it'd be an
even better signal to be able to land the PR.
  * How can we evaluate the compat risk here?

RE the latter, is there a way to usecount how often the
baseURI is accessed in places that will change behavior here?
That can give us an upper bound on potential breakage.

On Mon, Jul 3, 2023 at 4:00 AM Domenic Denicola
 wrote:

Let me just say, with my HTML Standard editor hat on, that
I am very excited for these changes. This area is
currently a wasteland of non-interoperable behavior,
broken specifications, and web-developer-expectations
violations. The team has done some amazing work to figure
out a model that works well, is conceptually elegant, and
has minimal compat concerns. And although I haven't done
my editor review yet, I'm excited to see that they've sent
spec PRs and a good number of web platform tests for this
area.

There may still be compat risks here, but I think the
benefits of getting a reasonable model for base URL
inheritance are worth pushing forward (with careful
deployment and a kill-switch). Thanks so much to the team
for this work.

On Sat, Jul 1, 2023 at 3:41 AM W. James MacLean
 wrote:

Intent to Ship: Inherit Base URL snapshot for
about:blank and about:srcdoc, with about:blank
inheriting from initiator, not parent.


Contact emails

wjmacl...@chromium.org 

cr...@chromium.org 

d...@chromium.org 


Explainer

None


Specification

https://github.com/whatwg/html/pull/9464
(original
proposal

)


Summary

This work aims to fix issues and improve the
compatibility of Chromium's implementation of fallback
base URL
specifically
for about:srcdoc and about:blank frames. The base URL
can be accessed directly with document.baseURI, and
indirectly when resolving relative URLs.  Chromium's
current behavior differs from Safari & Firefox in
several ways. Chromium and Safari only
partiallysnapshot the base URL for an
about:blank/srcdoc document from its creator document,
and the about:blank/srcdoc document usually does not
observe later changes to its creator document's base
URL. Still, such changes may become visible in corner
cases (e.g., if the child makes and then reverses
changes to its own element, its partial snapshot
gets updated from its creator).

We propose that the base URL 

Re: [blink-dev] Intent to Implement and Ship: Per-frame quantizer in VideoEncoder

[Mike Taylor]

On 7/5/23 8:57 PM, 'Eugene Zemtsov' via blink-dev wrote:


Intent to Implement and Ship: Per-frame quantizer in VideoEncoder


Contact emails

ezemt...@google.com


Explainer

None


Specification

https://www.w3.org/TR/webcodecs/#video-encoder-bitrate-mode 




Summary

Adds "quantizer" VideoEncoderBitrateMode for VideoEncoder. This allows 
to specify a quantizer parameter for each frame for AV1, VP9, and AVC 
video codecs. The quantizer parameter is set via codec specific 
extensions for VideoEncoderEncodeOptions.


Assuming I know very little about video codecs, what use cases does this 
enable for developers?



Blink component

Blink>Media>WebCodecs 




TAG review

None.

Previously WebCodecs API had TAG review as a whole:

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



This is a new addition since that review, but it's a trivial addition 
(IMHO) so a new review request isn't needed.



TAG review status

Not applicable


Risks



Interoperability and Compatibility



Gecko: Neutral 
(https://github.com/mozilla/standards-positions/issues/837#issuecomment-1614666364 
) 
Paul Adenot (Mozilla) expressed that minor changes to WebCodecs spec 
don't need to go through the full "Request for Mozilla Position" 
process assuming they were approved by the Media Working Group.



WebKit: Positive 
(https://www.w3.org/2023/03/07-mediawg-minutes.html#t02 
) The issue 
was discussed on 07 March 2023 by w3c Media working group. Jer Noble 
(Apple) was actively participating and provided input for spec details.


Can we request a formal position from WebKit, at least to let them know 
we're intending to ship?


Web developers: Positive (https://github.com/w3c/webcodecs/issues/56 
) People ask for this on 
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?





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


Tracking bug

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




Estimated milestones

Shipping on desktop



117


Shipping on Android



117





Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5783986600673280 








--
Thanks,
Eugene Zemtsov.
--
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/CAK8JDrF0PKfpVbaYWX-hR0wJ%2Bb9H4YtwFBUc6Y6JGSmFT7pVgQ%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/0a1d0f96-c5f0-fdf8-44b0-b49c3f180839%40chromium.org.

Re: [blink-dev] Intent to Ship: Read Chrome device attributes

[Mike Taylor]

On 7/4/23 5:35 AM, 'Sergii Bykov' via blink-dev wrote:



Contact emails

sby...@google.com


Explainer

https://github.com/Ananubis/WebApiDevice/blob/master/Explainer.md
I see that getAnnotatedAssetId(), getAnnotatedLocation(), 
getDirectoryId(), and getSerialNumber() are all defined as uniquely 
identifying a device. Forgive my ignorance, but can you expand on the 
use cases for each of these unique IDs in the explainer (and why there 
are so many of them)?



Specification

https://wicg.github.io/WebApiDevice/device_attributes


Summary

Device Attributes Web API is a subset of Managed Device Web API, that 
provides web applications the capability to query device information 
(device ID, serial number, location, etc).




Blink component

Blink 


TAG review

https://github.com/w3ctag/design-reviews/issues/606 There was no 
indication of implementation support from browsers other than Chrome. 
And reviewers were concerned by the risk of pervasive monitoring of 
employees. Privacy concerns were addressed in 'Permission control' and 
'privacy consideration' paragraphs of the spec. But TAG reviewers 
didn't endorse adding this as a general mechanism to the Web platform.



TAG review status

Issues addressed


Risks



Interoperability and Compatibility

navigator.managed object includes managed configuration and this 
device attributes API. These APIs only work in managed applications 
and return an error in other contexts. Thus navigator.managed exposure 
may be reduced in the future to managed environments only. This will 
be done as a separate chrome feature and after an investigation with 
usage counters.


Can you clarify what you intend to ship vs "exposure may be reduced in 
the future"? Mozilla had a good suggestion 
, 
but it's not clear to me if it's being incorporated or not.



/Gecko/: Neutral 
(https://github.com/mozilla/standards-positions/issues/815) Mozilla 
decided not to take a position. Also suggested to limit the exposure 
(see proposal in Interoperability and Compatibility).


/WebKit/: Neutral 
(https://github.com/WebKit/standards-positions/issues/198) Mixed 
signals from WebKit. Offering to leave it as an extension API or do 
not expose it everywhere. Exposure addressed in Interoperability and 
Compatibility


/Web developers/: Positive 
(https://github.com/WICG/proposals/issues/14) Web developers request 
this API as they migrate from deprecated ChromeApps to PWAs


/Other signals/:


Ergonomics

Frequently used with managed configuration. No performance risks.



Activation

No activation challenges for developers. API is straighforward to use. 
ChromeOS Admins will need to set up the force-installed or kiosk app 
and the allowlist policy correctly.




Security

Please see 'Permission control' and 'privacy consideration' paragraphs 
in the API spec.




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 feature does not deprecate or change behavior of existing APIs.



Debuggability

Verified that all five new methods show up in the DevTools Console 
autocomplete functionality.




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

No


Is this feature fully tested by web-platform-tests

?

No


DevTrial instructions

https://github.com/WICG/WebApiDevice/blob/main/README.md


Flag name on chrome://flags

enable-restricted-web-apis


Finch feature name



Non-finch justification

None


Requires code in //chrome?

False


Tracking bug

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


Launch bug

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


Availability expectation

Feature is available only in ChromeOS (Ash and Lacros) browsers for 
the foreseeable future.



Adoption expectation

Feature will be used by Web App developers for Kiosk and other managed 
apps on ChromeOS as a part of migration from ChromeApps to PWAs within 
12 months of launch in Chrome.



Adoption plan

A new setting in dpanel kiosk settings will allow admins of managed 
chrome to configure 'trusted' apps access to API usage via existing 
policy 'DeviceAttributesAllowedForOrigins'. This setting will be 
enabled for trusted testers end of Q2 2023.



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?


Yes. Policy 

Re: [blink-dev] Intent to Ship: CustomElementsGetName

[Mike Taylor]

LGTM3

On 7/5/23 11:42 AM, slightlyoff via Chromestatus wrote:

LGTM2
--
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/59df9b05ffbf3f9d%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/234ebe0f-d2fd-94c3-06b9-470052050e3d%40chromium.org.

Re: [blink-dev] Intent to Ship: CustomElementsGetName

[Mike Taylor]

On 7/5/23 11:42 AM, slightlyoff via Chromestatus wrote:

LGTM2
--
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/59df9b05ffbf3f9d%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/075b727f-6339-c48c-9cbf-be1c7b65b374%40chromium.org.

Re: [blink-dev] Intent to Prototype and Ship: contain-intrinsic-size: auto none support

[Mike Taylor]

LGTM3

On 7/5/23 11:40 AM, Daniel Bratell wrote:


LGTM2

/Daniel

On 2023-07-05 17:39, slightlyoff via Chromestatus wrote:

Excited to see this land; LGTM1
--
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/138e3105ffbf36a9%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/96e668ee-ced2-e88d-a534-87f3d5b32f49%40gmail.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/f719e3c1-cdb1-8d85-5bde-363a77063c0a%40chromium.org.

Re: [blink-dev] Intent to Ship (I2S): Protected Audience

[Mike Taylor]

On 7/1/23 3:09 AM, Paul Jensen wrote:



On Wed, Jun 28, 2023 at 5:33 AM Yoav Weiss  wrote:



On Tue, Jun 27, 2023 at 9:54 PM Paul Jensen
 wrote:

Yoav,


Protected Audiences has been fortunate to have a ton of design
contributions and feedback, but consequently has a lot of
issues filed.  We try to respond to all issues, as you can see
by the discussion comments on nearly all issues.  I went
through and triaged all the issues recently.  I closed many of
them, created some labels and labeled many of them. Here’s
where I think the open issues stand:

 *

65

I
labeled “Non-breaking Feature Request”, meaning they’re
requesting new functionality that is unlikely to cause
backwards compatibility issues.

 *

29 are
spec related.  As Dominic said above, most of these
changes are unlikely to break web content.

 *

8

are
seeking feedback rather than pointing to a problem.

 *

4
could
potentially break compatibility.  I think for all of these
we’ve decided to not adopt the proposed changes or we’ve
decided to adopt the proposed changes but as part of our
longer-term plans in the future.  I should note that
recently we adopted many breaking changes to our API, but
did so in a way that supports backwards compatibility, so
we can wean developers off of the old APIs without causing
immediate significant breakage.  If we chose to adopt some
of these changes, I imagine we could do so in a similar
non-breaking way.

 *

86

didn’t
fit well into a particular category:

 o

Some were questions seeking to clarify details of our
timeline or the explainer or design.

 o

Some were discussions that are mostly addressed but
left open so we don’t forget about remaining pieces.

 o

Some are open discussions or examples.

I think it’s worth noting that our usage of the issue system
differs from those of many other folks who ship features:  We
tend to use the issues as open forums as opposed to only
leaving open issues that need to have decisions made.  Many of
the issues predate the FLEDGE explainer and represent design
discussions that culminated in FLEDGE’s design.


Thanks for going over the issues!! To be clear, the number of
issues is not a concern in itself, and is indeed an indication of
the level of engagement this had.
This list of compat-related issues
 is
the only relevant bit for this intent IMO. At the same time, it'd
be good to settle these issues, or at least have a clear path
towards future-compat around them, before shipping. WDYT?


I think we’ve settled on paths to addressing each of the compat issues:

#444 and #586 
I think we’ve settled 
on not pursuing for reasons expressed in the issues.


#522 has been our long 
term plan but we've heard feedback that it blocks adoption and 
usability at this stage, especially in the long-tail of advertisers.  
Providing a solution to audience stealing is an important goal of 
Protected Audience. Our current implementation offers opt-in 
protection via our Permission-Policy, and we're going to continue to 
look for an ergonomic solution that facilitates adoption sufficiently 
to offer the protection by default.


#554 is something we 
might do, and could do in the future while offering a temporary 
backward-compatible period.  It doesn’t have significant developer 
benefits, other than making it potentially more web-like, so I’m 
reluctant to adopt it.


Thanks Paul. Could you close out 586 and leave comments on 522 and 554 
with your current thinking?


Re: 554, do you have plans to update the spec to match Chromium's 
implementation of setBid(), setPriority(), and 
setPrioritySignalsOverride()? Or do something else?





I hope the labels I added make it clearer which are future
   

Re: [blink-dev] Intent to Remove: CSS property -webkit-highlight

[Mike Taylor]

https://github.com/search?type=code=-webkit-highlight+language%3ACSS=CSS 
shows this has been used elsewhere (but I guess has just been useless in 
clank?).


That said, LGTM2.

On 7/1/23 4:33 AM, Rick Byers wrote:

Removing a prefixed API with no behavior should be trivial, thanks for 
the cleanup Stephen :-)


However, the UseCounter is surprisingly high with lots of hits in HA: 
https://chromestatus.com/metrics/css/timeline/popularity/251. Just 
confirming that you looked at a sample of those hits and found they 
were all using this 3P library?


LGTM1



On Thu, Jun 29, 2023 at 1:30 PM Stephen Chenney 
 wrote:



Contact emails

schen...@chromium.org, spectran...@igalia.com


Explainer

None


Specification

None


Summary

The CSS property -webkit-highlight is intended to highlight text,
but was never standardized. It has no visible effect in chromium
(it is parsed but never used in rendering content). The property
was removed from WebKit in 2014
(https://bugs.webkit.org/show_bug.cgi?id=128456), has been marked
as deprecated on MDN, and has been replaced recently with the CSS
Highlight Pseudo spec
(https://www.w3.org/TR/css-pseudo-4/#highlight-pseudos). The
property seems to be used in a single third-party library
(https://www.audioeye.com/) where it is always set to the value
"none".



Blink component

Blink>CSS



TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

Improving interop and compat. No other browser supports this
feature and the feature has no effect.



/Gecko/: N/A Never shipped.

/WebKit/: Removed in 2014.
(https://bugs.webkit.org/show_bug.cgi?id=128456)

/Web developers/: No signals. The property is essentially
undiscoverable.

/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



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

No


Is this feature fully tested by web-platform-tests

?

No


Flag name on chrome://flags



Finch feature name



Non-finch justification

The feature does nothing, so the behavior of web content cannot
change. There are no crash concerns with the code being removed.


Requires code in //chrome?

False


Tracking bug

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


Estimated milestones

Shipping on desktop 117

Shipping on Android 117

Shipping on WebView 117



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


Links to previous Intent discussions



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/CAGsbWzRjoatsXASAmVugMynmGDubKHaEVpD2_dQOxGn0rK71zA%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/CAFUtAY82FD8a7WxksRoC3U8zYm5U2n2G-AVMDBO_QP3wsaAw%3Dg%40mail.gmail.com 
.


--
You received this message 

Re: [blink-dev] Intent to Ship: Permissions-Policy: unload

[Mike Taylor]

LGTM3

On 6/30/23 9:10 PM, Rick Byers wrote:

LGTM2

In addition to Yoav's comments I'll also add that it makes sense to me 
if WebKit and Gecko don't want this. They each have a lot more 
flexibility in how they avoid unload handlers, and WebKit already just 
doesn't fire them when they don't want to. Chromium's enterprise 
customer base means we need to take a more careful and measured 
approach to reducing reliance on unload handlers, and given the 
positive experience we've heard from partners for this feature in OT, 
I think we must ship it despite the lack of alignment with other engines.


Ideally we succeed in deprecating unload over the next few years then 
we can delete this policy. The important thing for long-term Interop 
risk is that the engines are aligned on wanting to deprecate unload. 
We just aren't aligned on the most effective path for doing so in our 
respective environments.


On Fri, Jun 30, 2023, 3:51 a.m. Yoav Weiss  wrote:

LGTM1

On Fri, Jun 30, 2023 at 9:27 AM 'Fergal Daly' via blink-dev
 wrote:


Contact emails


fer...@chromium.org, kenjibah...@chromium.org


Explainer



https://github.com/fergald/docs/blob/master/explainers/permissions-policy-unload.md


Specification


https://github.com/whatwg/html/pull/7915


IMO, it's fine to approve this based on this PR, even if it hasn't
landed yet, given the browser positions below.




Design docs




https://github.com/fergald/docs/blob/master/explainers/permissions-policy-unload.md


Summary


This feature allows pages to disable the running of
unload event handlers. The goals are: - allow sites
that have removed all unload handlers to not regress
(i.e. accidentally adding new ones) - allow sites to
“remove” (skip) unload handlers (e.g. if updating the
code is infeasible, or if they have nondeterministic
chains of third parties and would rather not risk the
BFCache benefits over unload handlers in third party
code). Unload event handlers are problematic for
various reasons and prevent use of BFCache on Desktop
(see
https://web.dev/bfcache/#never-use-the-unload-event).
This is the first step to deprecating and removing
unload handlers.



Blink component


Blink>PermissionsAPI




TAG review


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


TAG review status


Pending


Risks




Interoperability and Compatibility


3rd-party frames that rely on unload may not work as
expected when navigating away. This is solvable by the
frame authors by use of alternatives to unload and is
unlikely to impact users. See detailed discussion.

https://github.com/fergald/docs/blob/master/explainers/permissions-policy-unload.md#concerns-about-giving-embedders-control-over-the-nonexecution-of-iframe-code



/Gecko/: Negative

(https://github.com/w3c/webappsec-permissions-policy/issues/444#issuecomment-1047829132)
FF objects to this similar to sync-xhr and
document-domain providing a way to cause cross-origin
interference with script. Explainer addresses this

(https://github.com/fergald/docs/blob/master/explainers/permissions-policy-unload.md#concerns-about-giving-embedders-control-over-the-nonexecution-of-iframe-code)
At a recent TPAC meeting with Mozilla people present,
no negative feedback was received. Request for formal
position is here
https://github.com/mozilla/standards-positions/issues/691

/WebKit/: Negative
(https://github.com/WebKit/standards-positions/issues/127)
Concerned that embedders gain a way to turn off a
code-path in the embedded frame.


I think it's important to continue those discussions with other
vendors and try to eventually bring them on board, but at the same
time, I agree with your position that we need to put users first.
Unload events are causing real performance harm today, and we
should at least give top-level site owners the ability to stop
that harm, even if created by their third-parties.

I haven't seen in the above discussions any concrete threats or
attacks enabled by this cross-origin interference. And as you say,
we already have similar policies around sync-XHR 

Re: [blink-dev] Intent to Deprecate: Deprecate unload event

[Mike Taylor]

Hi Fergal,

Nice to have lunch with you today.

On 6/28/23 5:06 PM, 'Fergal Daly' via blink-dev wrote:


Hi API-owners,


I am now asking for permission to go ahead with the following concrete 
unload deprecation plan below.



 *

Tools and outreach

 o

M115 Enable `Permission-Policy: unload` (PP:unload) with the
default being enabled. This allows sites to opt-in to unload
deprecation.

 o

Outreach to 1st/3rd parties, to migrate away from using unload
and to enforce this with PP:unload.

 *

Deprecation

 o

M117 change the default for PP:unload so that unload handlers
are skipped by default for 1% of page loads

 o

M118 increase to 5% of page loads

 o

M119 (last of 2023) increase to 10% of page loads

 o

Evaluate progress on reduction of the use of unload

 o

M120-128 increase +10% gradually to 100% of page loads


Enterprise policy would allow opt-out entirely.


Obviously, the deprecation timeline is contingent on unload usage 
coming down in response to the earlier steps.


Can you spell out a bit more what you're thinking here? I wouldn't 
expect much movement when enabled at only 1% (but maybe y'all are super 
good at outreach and will prove me wrong) - it's very likely losing 1% 
of unload handlers is hard to notice or reproduce (my hunch is that 
"breakage" here is subtle, and in the form of missing analytics/pings, 
etc.). 5% is probably a big enough dent to notice, maybe?


I would almost recommend getting to 5% faster than M119 - that's just a 
few weeks out from November holidays where many sites go into code 
freeze ahead of Black Friday™.




We expect that 10% of page loads will provide a noticeable signal to 
sites that use unload. Also, if we were to just follow the current 
spec and not run unload when we can BFCache (as happens on 
Clank/Firefox mobile and all WebKit) we expect that we would skip 
30-40% of unload handlers when the main frame navigates.



Decisions:

 *

Timeline

 *

All navigations vs main-frame navigations only


Standardising

We have some new data and have had some further discussions with 
browser vendors. There's no consensus. TL;DR WebKit are opposed to any 
Permissions-Policy but support removing unload eventually. Mozilla are 
still discussing.



Both Mozilla 
and WebKit 
were opposed 
to standardising `Permissions-Policy: unload` (defaulting to on) 
because they worried that a containing frame might selectively disable 
unload handlers in a child frame for malicious purposes (no specific 
cases were discussed).



So we flipped to the idea of having PP:unload with the default being 
disabled. We cannot suddenly do that. We need to roll it out 
gradually. WebKit folks are opposed to this and have suggested 
we 
do a reverse origin trial instead. If our plan works out, eventually 
we would ROT as the final nail but ROT starting now has downsides for 
users and sites and no upside for the implementer.



Mozilla has so far not been negative 
on the 
Permissions-Policy off-by-default approach but they are still 
discussing. They are concerned that disabling unloads when subframes 
are navigating could be a problem. We found that about 1/4 of subframe 
navigations involve an `unload` handler (most seem to involve handlers 
in cross-site and same-site site frames). We don't have examples of 
sites that rely on `unload` handlers in this way, although they 
probably do exist. Migrating to `pageshow` or using PP:unload for 
these sites should be trivial.



We have the option to say that PP:unload only applies to main frame 
navigations. This would mean these sites would be completely 
unaffected however that has some downsides. It is harder to explain 
and does not end with full removal of `unload`. We would prefer to 
have this apply to all navigations unless we find a good reason not 
to. If we were to change part-way, there would be no breakage. We hope 
that once we drive down usage in 3rd-part iframes with PP:unload that 
the number of unload handlers running in subframe navigations 
decreases significantly.



Finally there was some discussion 
about 
how Permissions-Policy off-by-default should work. Our current version 
requires every page to set the header and every parent to set the 
iframe `allow` attribute. This is maximally conservative. If at some 
point later on there is agreement to standardise on something less 
conservative, it will not break pages that have already re-enabled 
`unload`.



Overall it seems hard to standardise in advance but if we succeed in 
driving 

Re: [blink-dev] Intent to Implement and Ship: Remove Payment Request User Activation Requirement

[Mike Taylor]

LGTM3

On 6/28/23 2:06 AM, Stephen Mcgruer wrote:
Thanks Mustaq for your input (and API OWNERS for the ongoing LGTMs, 
here's hoping for #3 :)). I agree with your points on the difficulty 
of making either user activation or capability delegation work across 
navigation (though I still personally think there are reasonable 
use-cases! :D). We're definitely paying attention to potential abuse 
scenarios here, though we do agree with Rick's take that getting user 
activation is unfortunately a fairly weak protection today already.


Wrt the PR status - yes, the WG has now endorsed it, but we will 
definitely be landing the PR before trying to ship this. We've 
re-targeted the launch from M116 to M117.


On Tue, 27 Jun 2023 at 03:52, Yoav Weiss  wrote:

LGTM2 conditional on the PR landing

On Mon, Jun 26, 2023 at 5:02 PM Rick Byers 
wrote:

This makes good sense to me. Obviously there's so much risk
and potential for abuse around payments, getting the user to
click seems like a very weak mitigation anyway (eg. the
prevalence of "click to read more" buttons). +1 to waiting for
the PR to land, but it looks like the WG has now approved it,
so proactive LGTM1 for when the PR actually lands.

It's too bad Apple isn't currently a member of the WG, so
we're not likely to get their thoughts on this in time to
influence our launch decision. But I also don't think it's a
substantial interop risk - Payment Request is already very
different on Apple browsers due to the tight coupling only
with Apple Pay.

Rick

On Tue, Jun 13, 2023 at 2:54 PM Nick Burris
 wrote:


Contact emails

nbur...@chromium.org, smcgr...@chromium.org, i...@chromium.org


Specification

https://github.com/w3c/payment-request/pull/1009


Design docs


https://docs.google.com/document/d/16DHqqPWe5oM6Rucnn6Y1llhJ-DoEeLtTWFldJFg4iqA/edit#heading=h.w5782xqp7ab4


Summary

To help developers reduce friction in Payment Request
flows, we are removing the user activation requirement for
PaymentRequest.show(). Spam and clickjacking mitigations
are put in place to mitigate security and privacy risks
with this change (see design doc

).



Blink component

Blink>Payments




TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

/Gecko/: No signal

/WebKit/: No signal

/Web developers/: We've received direct feedback from web
developers that they would be able to reduce friction in
their redirect-based payment flows if
PaymentRequest.show() could be initiated without a user
activation.

/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

Existing debuggability for PaymentRequest; e.g. a specific
SecurityError is thrown when an activationless show() call
is not allowed.


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

--enable-blink-features=PaymentRequestActivationlessShow


Tracking bug

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


Estimated milestones

DevTrial on desktop 117

DevTrial on Android 117



Anticipated spec changes

https://github.com/w3c/payment-request/pull/1009


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4879115349393408


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 

Re: [blink-dev] Intent to Ship: deliveryType (Resource Timing)

[Mike Taylor]

LGTM3

On 6/27/23 12:57 AM, Yoav Weiss wrote:

LGTM2

On Mon, Jun 26, 2023 at 5:25 PM Rick Byers  wrote:

Note since the TAG and standards position requests were new on
this, API owners were waiting a bit to hear if there was any
feedback. But it's been two weeks now and this seems like a
valuable and minor extension to me and I trust the team to engage
constructively with any feedback in this area whenever it comes.
So LGTM1 to ship

On Tue, Jun 13, 2023 at 5:39 PM Jeremy Roman
 wrote:


Contact emails

jbro...@chromium.org


Explainer

https://gist.github.com/jeremyroman/43f8f290f1f404d3b7f6cb708601c7f0



Specification


https://w3c.github.io/resource-timing/#dom-performanceresourcetiming-deliverytype


Summary

Expose information about how a resource was delivered. For
example, resources which were delivered from the cache
(currently exposed through transferSize) and navigations which
were prefetched by the previous page are useful to identify.

This is currently part of an experiment bundled with other
features (because it is necessary to be able to tell whether a
page was prefetched to evaluate the utility of prefetching
technology), but I believe it's useful to ship independently,
and need not be tied to the areas that remain under
development/experimentation/discussion.


Blink component

Blink>PerformanceAPIs>ResourceTiming




TAG review

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



TAG review status

Pending


Risks



Interoperability and Compatibility



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


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


Note for others reviewing (since I was confused for a minute): the
link attached to the above URL is wrong (points to issue #54 not
#204 )

Web developers: No public signals, but web.dev
 and developer.chrome.com
 were able to successfully use
deliveryType to distinguish prefetch from non-prefetch
traffic. The major hiccup encountered was the origin trial
token not being processed before the deliveryType property was
accessed; this difficulty would not exist when the feature is
shipped.


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?



Debuggability

Some of this information is already visible to developers in
the Network panel. Developers can use the JavaScript console
to access the deliveryType API.


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

Yes


Is this feature fully tested by web-platform-tests

?

Yes


https://wpt.fyi/results/?label=master=experimental=delivery-type




Flag name

No user-visible flag; DeliveryType runtime-enabled feature.


Requires code in //chrome?

False


Tracking bug

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



Estimated milestones

OriginTrial desktop last



118

OriginTrial desktop first



110


OriginTrial Android last



118

OriginTrial Android first



110


OriginTrial webView last



118

OriginTrial webView first



110



Anticipated spec changes


Future changes may add additional delivery types, which would
be initially unrecognized by author code - most likely, real
user metrics 

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

[Mike Taylor]

LGTM3

On 6/22/23 4:13 PM, Chris Harrelson wrote:

LGTM2

On Thu, Jun 22, 2023 at 1:02 PM Rick Byers  wrote:

Similar to my comments for Topics


 there's
obviously a lot of interop risk around whether this sort of
capability will be part of the web long-term or not, but I think
shipping this in Chromium is the next logical step in moving the
debate forward. Although I sympathize with the sentiment in
Mozilla and Apple feedback about complexity, I'm personally
inspired by the effort to go down this "isolated execution
environment" path as I think it has the potential to open up a
whole new class of techniques for improving privacy - someone
should try! I appreciate the thought on mitigating future web
compat risks and agree that reduces the need for concern
significantly. I skimmed through the open spec issues and don't
see anything that seems like it needs to block launch.

Overall I don't see anything that could reasonably be done to
reduce future interop risk, so LGTM1 from me.

On Thu, Jun 22, 2023 at 11:24 AM Josh Karlin
 wrote:



On Thu, Jun 22, 2023 at 9:35 AM Yoav Weiss
 wrote:



On Wed, Jun 21, 2023 at 4:35 PM Ben Kelly
 wrote:

I was the spec mentor for shared storage and worked
with Cammie on the spec.  I'd just like to add my
thoughts to provide the requested spec maturity
summary

.


Overall I think the spec process model has reached a
high level of quality.  In particular, we paid special
attention to make sure it integrates with the storage
spec data model and resource timing's time source
model. Cammie has been very receptive to feedback and
continues to make improvements to the spec.

Of course, it is a complex spec and there has not been
a second implementation yet.  We should expect some
corner cases or nuanced issues to be reported when
that next implementation is done.  Pending that,
however, I think the spec is as high quality as we can
get at this stage.


On Tue, Jun 20, 2023 at 2:01 PM Josh Karlin
 wrote:


Contact emails

yao...@chromium.org, cam...@chromium.org,
ale...@chromium.org, jkar...@chromium.org



Explainer

https://github.com/WICG/shared-storage



Specification

https://wicg.github.io/shared-storage/



Summary

Shared Storage provides a general purpose privacy
primitive for use cases where a small amount of
cross-site data is required. It is comprised of a
storage API (writes available from anywhere, reads
only in isolated javascript environments called
worklets) and a set of output gates which
significantly limit the amount of cross-site
information that can be read externally.


Blink component

Blink>Storage>SharedStorage




TAG review

TAG review



TAG review status

Open


Risks


Interoperability and Compatibility


Gecko: Negative



WebKit:Open
, 
though concerns
have been raised.


To reduce risk in the event that we later decide
to replace this API with one that has more browser
support, the API can be effectively disabled
without breaking pages. That is, writing to shared
storage can be a noop, selectURL can simply select
the first URL, and run can be a noop.


Web developers:


We have several developers testing the API in OT

Re: [blink-dev] Re: Intent to Ship: Fenced Frames

[Mike Taylor]

LGTM3

On 6/21/23 11:53 AM, Rick Byers wrote:

LGTM2

On Wed, Jun 21, 2023 at 11:46 AM Chris Harrelson 
 wrote:


LGTM1

Thank you for thoroughly working through all the design and
specification steps for this feature. Glad to see some
positive signals from the TAG about the fundamental design in
particular.

I agree that Alex's comments are good to answer and investigate
for future work, but also they aren't blocking this intent.
(Confirmed this interpretation with Alex.)

On Wed, Jun 21, 2023 at 8:42 AM Alex Russell
 wrote:

Hey all,

I'm not going to weigh in on if this should ship right now,
but I want to express some disappointment that this design
seems to be launching without a way to load from a bundle and
a flag for removing the ability to load from the network. We
have a lot of use-cases that would benefit from a version of
 that was more capable and generic, rather than
being narrowly targeted at an ads use-case.

What's the prognosis for fixing those deficiencies in
near-future work?

Best,

Alex

On Tuesday, June 20, 2023 at 5:07:07 AM UTC-7 Shivani Sharma
wrote:

Contact emails

shivani...@chromium.org ,
d...@chromium.org ,
jkar...@chromium.org 

Explainer

https://github.com/WICG/fenced-frame/tree/master/explainer



Spec

https://wicg.github.io/fenced-frame/



Summary

In a web that has its cookies and storage partitioned by
top-frame sites, there are occasions (such as Interest
group based advertising
or Consistent A/B
experiments across sites

)
when it would be useful to display content based on inputs
from different partitions on the same page. For such use
cases, it would be ideal from a privacy perspective, if
the documents that contain data from different partitions
are isolated from each other such that they're visually
composed on the page, but unable to communicate with each
other. Iframes do not suit this purpose since they have
several communication channels with their embedding frame
(e.g., postMessage, URLs, size attribute, etc.). We
propose fenced frames, a new element to embed documents on
a page, that explicitly prevents communication between the
embedder and the frame.


At the time of this I2S, fenced frames can be created and
navigated using the `FencedFrameConfig` object returned
from the following APIs:

 *

Protected Audience API runAdAuction() (code snippet

)

 *

Shared Storage API selectUrl() (code snippet

)

(For future use cases of fenced frames, separate I2S would
be sent.)


Blink component

Blink>FencedFrames




TAG reviews and status

early design review

(status:
complete),

specification review
(status:
pending)


Link to Origin Trial feedback summary

Fenced frames are part of the unified Privacy Sandbox OT
and are an integral part of the privacy design of
“Protected Audience” and “Shared Storage” APIs. For easier
adoption, these consumer APIs don’t currently enforce the
use of fenced frames, but we have had multiple testers
testing these APIs with fenced frames. We’ve 

Re: [blink-dev] Intent to Implement & Ship: WebUSB exclusionFilters option in requestDevice()

[Mike Taylor]

LGTM1

On 6/21/23 2:32 AM, 'François Beaufort' via blink-dev wrote:



Contact emails


*

fbeauf...@google.com 

reil...@google.com 


*


Explainer


*

https://github.com/WICG/webusb/pull/233#issue-1760530134



*


Specification


*


https://wicg.github.io/webusb/#dom-usbdevicerequestoptions-exclusionfilters



https://github.com/WICG/webusb/pull/233



*


Summary


*

The "exclusionFilters" option in navigator.usb.requestDevice()
allows web developers to exclude some devices from the browser
picker. It can be used to exclude devices that match a broader
filter but are unsupported.


*


Blink component


*

Blink>USB




*


Motivation


*

Allowing web developers, through the "exclusionFilters"
option, to exclude from the browser picker some devices that
are not supported by the site will improve user experience.
Without it, web developers let users pick a device, then have
to check using a custom JavaScript helper function and alert
the user after they’ve already selected a device, resulting in
a poor user experience.


// Request access to a device from vendor ID 0xABCD.

// The device with product ID 0x1234 has been reported as
unsupported.

constdevice = awaitnavigator.usb.requestDevice({

filters: [{ vendorId: 0xABCD}],

exclusionFilters: [{ vendorId: 0xABCD, productId: 0x1234}],

});


This feature is similar to Web Bluetooth and WebHID
"exclusionFilters" options. See
https://chromestatus.com/features#exclusionFilters



*


TAG review


*

This small addition to the WebUSB API doesn’t seem to qualify
for a TAG review. FYI We have filed one for Web Bluetooth
"exclusionFilters" option recently which was marked as
satisfied at
https://github.com/w3ctag/design-reviews/issues/830



*


TAG review status


*

Not Applicable


*


Risks


*
*


Interoperability and Compatibility


*

Older browsers will ignore exclusionFilters and all devices
matching the provided filter will be displayed (the current
behavior).


Signals from other implementations (Gecko, WebKit):


Gecko: No Signal [1]

WebKit: No Signal [1]

Web / Framework developers: Positive
https://github.com/WICG/webusb/issues/232



[1] Both Gecko and WebKit are unlikely to object to this
feature specifically, but object to the overall WebUSB API as
a whole, hence it doesn't make sense to bug them with specific
questions on this.


Activation:

This feature can't be polyfilled. It should be fairly trivial
for developers to adopt this new feature.


*


Debuggability


*

No specific DevTools changes are required. This feature is
treated like any other JS method.

Note that exposing DevTools debugging support for
device-access APIs (WebUSB included) is discussed at
https://bugs.chromium.org/p/chromium/issues/detail?id=1142566#c20
.


*


Is this feature fully tested by web-platform-tests

?


*

No, because browser picker implementation is implemented
outside of Blink and so isn’t testable fully by
web-platform-tests.


*


Requires code in //chrome?


*

Yes, the browser picker implementation is part of the UI code
in //chrome.


*


Tracking bug


*

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



Estimated milestones

117


*


Link to entry on the Chrome Platform Status


https://chromestatus.com/feature/5172269315260416




--
You received this message because you are subscribed to the Google 

Re: [blink-dev] Re: Intent to Ship: WebGPU WebCodecs integration

[Mike Taylor]

LGTM3

On 6/19/23 7:09 AM, Yoav Weiss wrote:

LGTM2

On Mon, Jun 19, 2023 at 12:28 PM 'François Beaufort' via blink-dev 
 wrote:


Thank you Alex.

WebGPU can use VideoFrames in any worker so as long as they can be
produced off-main thread
 then
it shouldn't block.
VideoFrames are also possible to postMessage between workers

if needed.


On Fri, Jun 16, 2023 at 10:21 PM Alex Russell
 wrote:

LGTM1, but does this need to bounce through main thread video
decode for every frame sampled? Is it not possible to target a
WebGPU texture with the decoded buffer contents without
needing to lean on the main thread's
`requestVideoFrameCallback()`?

On Friday, June 16, 2023 at 1:20:31 AM UTC-7
fbea...@google.com wrote:


Contact emails

cwal...@google.com, kain...@google.com, bajo...@google.com


Explainer


https://developer.chrome.com/blog/new-in-webgpu-113/#use-webcodecs-videoframe-source-in-importexternaltexture



https://github.com/gpuweb/gpuweb/issues/1380


https://github.com/gpuweb/gpuweb/issues/4165


https://gpuweb.github.io/gpuweb/explainer/#image-input



Specification

https://gpuweb.github.io/gpuweb/#gpuexternaltexture



Design docs

https://github.com/gpuweb/gpuweb/issues/1380



Summary

WebGPU exposes an API to create opaque "external texture"
objects from HTMLVideoElement. These object can be used to
sample the video frames efficiently, potentially in a
zero-copy way directly from the source YUV data. However
the WebGPU specification for the first version of WebGPU
does not allow creating GPUExternalTextures from WebCodecs
VideoFrame objects. This capability is important for
advanced video processing applications that are already
using WebCodecs and would like to integrate WebGPU in the
video processing pipeline. This feature adds support for
using a VideoFrame as the source for a GPUExternalTexture
and a copyExternalImageToTexture call.


Blink component

Blink>WebGPU




TAG review

A new TAG review is not needed in this case as WebGPU had
one recently already:
https://github.com/w3ctag/design-reviews/issues/626


This small but important addition is about adding
VideoFrame support on top of HTMLVideoElement support to
GPUExternalTextures and copyExternalImageToTexture call.


TAG review status

Not applicable


Risks


Interoperability and Compatibility


Gecko: Positive

(https://github.com/gpuweb/gpuweb/wiki/Minutes-2023-04-19#investigation-import-videoframe-from-webcodec-to-webgpu-1380:~:text=KG%3A%20the%20proposal%20above%20makes%20sense

)
WebCodecs is listed as "worth prototyping" which likely
means this intergration is the same.


WebKit: In development
(https://github.com/WebKit/WebKit/pull/14055
)


Web developers: Positive


Other signals:


Ergonomics

No ergonomic risk. This API would be used at the
intersection of WebGPU and WebCodec. It is designed to
keep performance as high as possible by allowing zero-copy
sampling of YUV frame data.



Security

The lifetime management of VideoFrame was taken into
account of this feature. No other security considerations.



WebView application risks

N/A



Debuggability

No support.


Will this feature be 

Re: [blink-dev] Intent to Ship: Iterator helpers

[Mike Taylor]

LGTM1 - looks like a useful addition to the language.

On 6/15/23 5:30 PM, Rezvan Mahdavi Hezaveh wrote:



Contact emails

rez...@chromium.org, s...@chromium.org


Explainer

None


Specification

https://tc39.es/proposal-iterator-helpers


Summary

Iterator helpers are new methods on iterator prototype to allow 
general usage and consumption of iterators.




Blink component

Blink>JavaScript>Language 




TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

No known interop or web compat risk.



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


/WebKit/: Positive (https://bugs.webkit.org/show_bug.cgi?id=248650) 
This is a TC39 Stage 3 proposal.


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




Debuggability

It is debugged as any other static method in JavaScript.



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

Yes


Is this feature fully tested by web-platform-tests

?

Yes, in test262 https://github.com/tc39/test262/pull/2818 




Flag name

--harmony_iterator_helpers


Requires code in //chrome?

False


Tracking bug

https://bugs.chromium.org/p/v8/issues/detail?id=13558


Estimated milestones

DevTrial on desktop 114

DevTrial on Android 114



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




Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5102502917177344


Links to previous Intent discussions



This intent message was generated by Chrome Platform Status 
.

--
You received this message because you are subscribed to the Google 
Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACJ3t%2Bh%3DnEUZQ1sREAgeC0u58QTmXG8xLa6vZ%2BjPnC_w9JdjrA%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/1e7ad343-f421-05d1-4e57-ec0cc87007b5%40chromium.org.

Re: [blink-dev] Intent to Experiment: SoftNavigation performance entry

[Mike Taylor]

LGTM to keep going until M115.

On 6/14/23 3:13 AM, Yoav Weiss wrote:
I recently discovered that despite me asking for this to run till 
M113, the OT is running till M115.
The reason I haven't "renewed" the OT after M113 is that lined-up 
partners took a particularly long time to add support, which resulted 
in practically no-use for the OTed API (beyond a very small number of 
origins 
<https://docs.google.com/spreadsheets/d/1ZC-lHLLQrAmSyfiO21EbM6LAEUjeF4x8O0J-YdYeQrI/edit?usp=sharing> - 
Google-only link).


Now I'm interested in renewing the OT for M115, but wondered if the 
fact that the OT wasn't effectively used on M113-M114 (nor before, 
tbh) could be considered as a gap in the OT, and hence the renewal 
won't be considered as extending 
<https://www.chromium.org/blink/launching-features/#origin-trials> 
beyond the 6 milestone initial limit.  Thoughts?


On Fri, Jan 6, 2023 at 11:13 AM Yoav Weiss  wrote:

Update: We're bumping the experimentation from M109 to M110 (till
M113), to align with partner timelines (and avoid them
rediscovering bugs fixed in M109).

On Wed, Nov 30, 2022 at 3:16 PM Mike Taylor
 wrote:

LGTM to experiment from M109 to M112.

On 11/30/22 9:01 AM, Yoav Weiss wrote:



Contact emails

yoavwe...@chromium.org


Explainer


https://github.com/WICG/soft-navigations#soft-navigations
<https://bit.ly/soft-navigation>


Specification


Not yet. I want to use the OT's feedback to assess the
solution's viability.


Summary

Exposes the (experimental) soft navigation heuristics
<https://github.com/WICG/soft-navigations#soft-navigations>
to web developers, using both PerformanceObserver and the
performance timeline.


Blink component

Blink>PerformanceAPIs

<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EPerformanceAPIs>


TAG review

Not yet.


TAG review status

Not yet.


Risks



Interoperability and Compatibility



/Gecko/: No signal for now. Will file once feedback confirms
viability.

/WebKit/: No signal for now. Will file once feedback confirms
viability.

/Web developers/: Strong
<https://github.com/WICG/proposals/issues/71#issuecomment-1325856231>
support
<https://twitter.com/yoavweiss/status/1575191332775026688>!

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


Nope!



Goals for experimentation

I'm interested in gaining insights on the quality of the
heuristic and how it compares to current heuristics employed
by RUM providers or driven by framework- or app-specific
knowledge. I'm also interested in knowing if developers find
the correlation of various performance entries to their soft
navigation ergonomic, and whether the emitted FP/FCP/LCP
entries work well for them to evaluate the performance of
their soft navigations.



Reason this experiment is being extended

N/A



Ongoing technical constraints

None.



Debuggability



Will this feature be supported on all six Blink
platforms (Windows, Mac, Linux, Chrome OS, 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

<https://wpt.fyi/results/soft-navigation-heuristics?label=experimental=master=subtest>!


Flag name

SoftNavigationHeuristics


Requires code in //chrome?

False


Tracking bug

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


Estimated milestones

OriginTrial desktop last112
OriginTrial desktop first   109

OriginTrial Android last112
OriginTrial Android first   109

OriginTrial webView last112
OriginTrial webView first   109



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5144837209194496


Links to previous Intent discussions

Intent to prototype:

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfV3qRFx0i-eGJFSzqE8bnbX8XYJCvXAj0LfvO0icPo_jA%40mail.gmail.com


This intent message was ge

Re: [blink-dev] Intent to Ship: Document picture-in-picture

[Mike Taylor]

LGTM3

On 6/14/23 11:47 AM, slightlyoff via Chromestatus wrote:

LGTM2
--
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/d6062405fe18ddcb%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/83ba36f6-90bc-27a7-7847-9ba26fc5a0c8%40chromium.org.

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

[Mike Taylor]

LGTM to experiment from 115 to 118 inclusive.

On 6/13/23 1:53 PM, Scott Haseley wrote:



Contact emails

shase...@chromium.org


Explainer

https://github.com/WICG/scheduling-apis/blob/main/explainers/yield-and-continuation.md


Specification

None


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


TAG review status

Pending


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/: No signal

/WebKit/: No signal

/Web developers/: No signals

/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, but there are reasonable 
mitigations, e.g. bounding total of prioritized continuations (see 
also 
https://github.com/WICG/scheduling-apis/blob/main/explainers/yield-and-continuation.md#preventing-task-starvation-by-continuations).




Activation

The feature would benefit from a polyfill so that tasks still yield in 
the case the feature is unavailable. The behavior can be approximated 
by awaiting `scheduler.postTask()` or wrapping `setTimeout(0)` in a 
promise. The signal inheritance bit [1], however, would need 
transpilation support to propagate the current signal across async 
(Promise) boundaries. But developers can alternatively pass the 
appropriate priority/signal if necessary on browsers that don't 
support the feature.




Security

See 
https://github.com/WICG/scheduling-apis/blob/main/explainers/yield-and-continuation.md#self-review-questionnaire-security-and-privacy




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 main goal is to evaluate yielding with prioritized continuations 
on site-specific metrics. More frequent yielding is known to improve 
responsiveness (should also be measured in experiments), but there's 
often a cost (latency) to regaining control of the thread. This API 
prioritizes continuations to mitigate this, and we want to measure the 
impact on site-specific metrics to evaluate the scheduling behavior.



Ongoing technical constraints

None.



Debuggability

This has basic new-API devtools support. We plan to work with the 
devtools team to see if we can integrate continuations into the 
performance panel in some way.




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


DevTrial instructions

https://github.com/WICG/scheduling-apis/blob/main/implementation-status.md


Flag name

--enable-blink-features=SchedulerYield


Requires code in //chrome?

False


Tracking bug

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


Estimated milestones

OriginTrial desktop last118
OriginTrial desktop first   115
DevTrial on desktop 113

OriginTrial Android last118
OriginTrial Android first   115
DevTrial on Android 113

OriginTrial webView last118
OriginTrial webView first   115



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6266249336586240


Links to previous Intent discussions

Intent to prototype: 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXGoJ1SBQP-ABM3%2BsDtKzUZiPoSCWqW2mLOjMrUfFBx4TomSw%40mail.gmail.com


This intent message was generated by Chrome Platform Status 
.

--
You received this message because you 

Re: [blink-dev] Intent to Experiment: EditContext API

[Mike Taylor]

Do you all have a timeline in mind for experimentation?

On 6/12/23 7:00 PM, 'Daniel Clark' via blink-dev wrote:



Contact emails

sni...@microsoft.com , 
shih...@microsoft.com , 
bemat...@microsoft.com , 
dan...@microsoft.com 



Explainer

https://github.com/w3c/edit-context/blob/gh-pages/explainer.md 




Specification

https://w3c.github.io/edit-context 


Design docs


https://github.com/w3c/edit-context/blob/gh-pages/dev-design.md 




Summary

The EditContext API simplifies the process of integrating a web app 
with advanced text input methods such as VK shape-writing, Handwriting 
panels, speech recognition, IME Compositions etc., improves 
accessibility and performance, and unlocks new capabilities for 
web-based editors.





Blink component

Blink>Editing 




Search tags

editing , 
contenteditable 
, input 
, rawinput 
, ime 




TAG review

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




TAG review status

Pending


Risks




Interoperability and Compatibility

There are no known interop or compat risks.



/Gecko/: No signal

/WebKit/: No signal

/Web developers/: Strongly positive Positive feedback from Word 
online, Adobe and Figma, Google Docs


/Other signals/:


Activation

Developers interested in this feature will typically have their own 
polyfill for text input using hidden textarea or contenteditable 
elements. Feature detecting and using new API to avoid side effects of 
previous approaches is intended to be easily adoptable.





WebView application risks

None


Goals for experimentation

We are looking for feedback on the developer ergonomics of using the 
API and for confirmation that it meets the needs of production web 
apps for various input modes. This is a complex API, and different 
developers are expected to use it in different ways. For example, some 
partners plan to construct the view of their editable region in the 
subtree of the EditContext-associated element, while other partners 
plan to keep the EditContext-associated element off-screen while using 
the EditContext APIs to set the bounds of the editable region.


We want to ensure that our design enables all these scenarios and is 
robust given the wide field of IMEs utilized by different users, which 
may have subtly different behaviors and event timings.



Ongoing technical constraints

None




Debuggability

Existing DevTools functionality should suffice to debug EditContext.


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


Flag name

--enable-blink-features=EditContext


Requires code in //chrome?

False


Tracking bug

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




Estimated milestones

No milestones specified




Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5041440373604352 




Links to previous Intent discussions

I2I: 
https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/OHqvPx9mFww/m/1za_qdEHDwAJ


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/SN6PR00MB0448C960D827BFAFE2FD1F2CC554A%40SN6PR00MB0448.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 

Re: [blink-dev] Intent to Experiment: FedCM Sign-in Status API

[Mike Taylor]

LGTM to experiment from M116 to M119 inclusive.

On 6/8/23 5:38 PM, Christian Biesinger wrote:



Contact emails

cbiesin...@chromium.org


Explainer

https://github.com/fedidcg/FedCM/blob/main/proposals/idp-sign-in-status-api.md 




Specification

https://github.com/fedidcg/FedCM/pull/436 




Summary


This origin trial is intended to cover the IdP Sign-in Status API 
, 
which is our proposal to address the last remaining privacy leak of 
FedCM before we feel comfortable enabling it without third party 
cookies: The Timing Attack Problem (issue 
, 
presentation 
).



The Timing Attack Problem is an attack that a tracker can perform by 
using the FedCM API in such a way that allows them to track users 
invisibly. The attack works by correlating the time between 
credentialed and uncredentialed requests and abusing the API to 
prevent it from being observed by users.



While we explored many variations and options (presentation 
), 
in this proposal, the IdP Sign-in Status API 
allows 
an Identity Provider to signal to the browser when their users are 
logging in and logging out (in a top level frame).



This signal allows the FedCM API to (a) avoid making any credential 
requests when the user is logged out of the IdP (and hence, fully 
mitigate timing correlations) an (b) provide a guarantee that every 
credentialed request it makes will have a user-visible outcome (e.g. 
an account chooser or a dialog to sign in to the IdP) given that the 
assumption is that the user is logged in.



We believe this will make the Timing Attack economically impractical 
(e.g. it requires the user to (a) have logged-in to the attacker in a 
top level frame as well as to (b) be recognized as an IdP in the 
account chooser), and in doing so enables FedCM to operate when third 
party cookies are blocked.




Blink component

Blink>Identity>FedCM 




TAG review


We have an open spec PR 
that is currently under 
review, and in that process, Firefox suggested that we reframe the API 
in terms of the Login Status API 
which Chrome/Firefox/Safari 
seem to be in directional agreement 
. We are planning 
to kick-off our TAG review once this settles a bit more into concrete 
spec terms while we are running the origin trial but before we send 
our I2S.



TAG review status

Pending


Risks



Interoperability and Compatibility


Gecko: Under consideration(https://github.com/fedidcg/FedCM/pull/436 
). Firefox raised early on 
the Timing Attack Problem 
and 
possible ways 
we 
can address it. The IdP Sign-in Status API is intended as a signal 
that the user agent can use to mitigate the Silent 
Timing 
Attacks which are executed through correlating the time between 
credentialed and uncredentialed requests without the user’s knowledge. 
The API sufficiently mitigates the problem for Chrome by showing a 
prompt (e.g. account chooser or dialog to sign in to the IdP) every 
time it makes a credentialed request within the FedCM API. We are 
working with Firefox to write the spec in such a way that different 
user agents can have the flexibility to make different trade-offs in 
terms of how often to prompt users.


WebKit: No signal. Safari has so far shown overall support 
for 
FedCM, but haven't yet formed a position on this specific extension of 
FedCM. We are generally in agreement of the API shape using the Login 
Status API , but 
we haven't yet gotten signals from them on how FedCM, specifically, is 
going to be using this signal. We are planning to send a webkit 
standards position 
after we resolve this 
and 

Re: [blink-dev] Intent to Ship: Private State Tokens API

[Mike Taylor]

Side note: is there anything blocking 
https://github.com/WICG/trust-token-api/pull/257 from landing?


On 6/8/23 9:28 AM, Steven Valdez wrote:
As an update, we're currently shipping to 1% to collect metrics to 
ensure this feature does not regress core web vitals 
<https://web.dev/vitals/>, before ramping up the rollout to 100% in 
the coming weeks.


On Wed, May 17, 2023 at 2:02 PM Rick Byers  wrote:

LGTM4 FWIW. Thank you for working through these issues Steven!

Rick

On Wed, May 17, 2023 at 8:52 AM Yoav Weiss
 wrote:

LGTM3

On Tuesday, May 16, 2023 at 6:04:48 PM UTC+2 sva...@google.com
wrote:

We've filed crbug.com/1445984 <http://crbug.com/1445984>
to keep track of that and will update the developer
articles to point more explicitly to the failure
condition/requirements there.

-Steven

On Tue, May 16, 2023 at 5:30 AM Mike West
 wrote:

LGTM2, with the understanding that cleaning up the
developer-facing story around this work is important.
I think the unenrolled case probably falls into step
~8  of
https://wicg.github.io/trust-token-api/#issue-request,
in which case I think the web-facing behavior is
clearly-enough specified. I'd like y'all to make sure
that that failure mode is debuggable, which I'm happy
for you to wrap into a larger story around enrollment
in devtools if that's what you land on when working
with that team.

Thanks!

-mike


On Mon, May 15, 2023 at 5:06 PM Steven Valdez
 wrote:

Thanks, we'll work on fixing those two issues.

I'm not sure what the general flow for enrollment
in DevTools will look like, but if there's a
general flow to detect when enrollment is missing
for other APIs that check at runtime, we can try
to integrate with that when PST calls are made
with an unregistered issuer.

On Fri, May 12, 2023 at 7:05 PM Mike Taylor
 wrote:

LGTM1 % resolving the following spec issues:

https://github.com/WICG/trust-token-api/issues/232

https://github.com/WICG/trust-token-api/issues/230


On Wed, May 10, 2023 at 5:52 AM Mike West
 wrote:

Will devtools help guide developers
towards enrollment?


Also I think Mike's question on devtools
support is worth answering.



-- 


 Steven Valdez | Chrome Privacy Sandbox |
sval...@google.com | Cambridge, MA



-- 


 Steven Valdez | Chrome Privacy Sandbox |
sval...@google.com | Cambridge, MA

-- 
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/325d36cb-52a4-4c2e-8124-09036014cbcbn%40chromium.org

<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/325d36cb-52a4-4c2e-8124-09036014cbcbn%40chromium.org?utm_medium=email_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/db001cd5-8d9a-0e3c-83fa-decf3a17d592%40chromium.org.

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

[Mike Taylor]

Also, it would be good to file a TAG review sooner than later to prevent 
any delays at a possible future I2S time.


On 6/7/23 11:53 AM, Chris Harrelson wrote:

LGTM

On Tue, Jun 6, 2023 at 1:57 PM Simon Hangl  wrote:


Contact emails

simo...@google.com


Explainer

https://github.com/screen-share/capture-all-screens/blob/main/explainer.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/explainer.md



https://docs.google.com/document/d/1p8hhW8cp1PbhEClMTWzYGjfTkBxaNcD34170F60FRpg/edit?resourcekey=0-gLQD4Q6bPVJlZ3gEyZ4_mA#heading=h.qxjlhbc2utcv




Summary

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


Calling getDisplayMedia() multiple times requires multiple user
gestures, burdens the user with choosing the next screen each
time, and does not guarantee to the app that all the 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>GetDisplayMediaSet




TAG review

None


TAG review status

Pending


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 allow-listed through 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


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 users loading private information that gets recorded
and made available to apps affiliated with their device's
admin. This risk is mitigated by informing users that
recording might start at any moment before the API becomes
accessible. (In CrOS, this warning is delivered in the log-in
screen, and when users log-in despite the warning, this is
tantamount to assent.)

3.

Risk of users forgetting that their screens are being
recorded. This risk is mitigated through a persistent
notification.



WebView application risks

None



Goals for experimentation

Learn about the experience of web developers and how this API
fulfills their needs.


Ongoing technical constraints

None


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

No

This API is initially implemented on CrOS, where demand for it is
greatest, and where we have the most flexibility in offering users
early warning that their screens may be recorded if they proceed
past the log-in screen. Lessons learned from shipping this API on
CrOS will be used when deciding how to correctly implement such
warnings on other platforms.



Is this feature fully tested by web-platform-tests

?

No, as WPTs don’t support setting of managed policies. The API is
tested by a number of unit- and browser- tests (Test files

Re: [blink-dev] Intent to Remove: document.open sandbox inheritance

[Mike Taylor]

The risk seems quite low here, thanks for the explanation. LGTM2.

On 6/5/23 6:10 AM, Yoav Weiss wrote:

LGTM1 to remove

On Mon, Jun 5, 2023 at 10:15 AM Arthur Sonzogni 
 wrote:



Contact emails

arthursonzo...@chromium.org


Explainer


https://docs.google.com/document/d/1_89X4cNUab-PZE0iBDTKIftaQZsFbk7SbFmHbqY54os/edit



Specification

https://html.spec.whatwg.org/#document-open-steps


Design docs


https://docs.google.com/document/d/1_89X4cNUab-PZE0iBDTKIftaQZsFbk7SbFmHbqY54os/edit


Summary

Sandbox flags of the caller are currently applied to the callee
when document.opentargets a different window. Stop doing it.


Blink component

Blink>SecurityFeature>IFrameSandbox




Motivation

  * It makes it difficult for Chrome's implementation to stay in a
consistent state.
  * The removed behavior was not specified. Safari and Firefox do
not implement it.
  * It had no security benefits.


Initial public proposal

None


Search tags

sandbox , iframe
, document.open



TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

This should be a trivial removal. Currently, 0.02% pages are
"potentially" affected:
https://chromestatus.com/metrics/feature/timeline/popularity/4375
In most cases, a less restrictive sandbox flag is not going to
negatively impact the affected pages. So 0.02% should be seen
as an upper bound. This brings Chrome's implementation closer to
the specification, and closer to Firefox and SafarI. This has a
positive impact on interoperability.



/Gecko/: N/A This aligns Chrome with Firefox, because Firefox
never implemented this behavior.

/WebKit/: N/A This aligns Chrome with Safari, because Safari never
implemented this behavior.

/Web developers/: No signals

/Other signals/:


Security

The removed feature did not have any security benefits. A
sandboxed iframe that can call document.open on its neighbors must
have “allow-scripts”and “allow-same-origin”capabilities. This is
already a known way to escape sandbox, independently of
document.open. For instance, one can call `eval` on its parent to
escape its sandbox. Chrome and Firefox display the message: "An
iframe which has both allow-scripts and allow-same-origin for its
sandbox attribute can escape its sandboxing."Security
considerations:

https://docs.google.com/document/d/1_89X4cNUab-PZE0iBDTKIftaQZsFbk7SbFmHbqY54os/edit#bookmark=id.7lqerksbaalj



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



Is this feature fully tested by web-platform-tests

?

Yes

Before the removal: Safari/Firefox PASS. Chrome/Edge FAIL:

https://wpt.fyi/results/html/browsers/sandboxing/sandbox-document-open-mutation.window.html?label=master=stable



After the removal. Safari/Firefox/Chrome/Edge: PASS.

https://wpt.fyi/results/html/browsers/sandboxing/sandbox-document-open-mutation.window.html


Flag name

--enable-blink-features=DocumentOpenSandboxInheritanceRemoval


Requires code in //chrome?

False


Tracking bug

https://crbug.com/1186311


Estimated milestones

Shipping on desktop 116

Shipping on Android 116

Shipping on WebView 116



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5171677800955904


Links to previous Intent discussions



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

Re: [blink-dev] Intent to Ship: Add value argument to URLSearchParams's has() and delete()

[Mike Taylor]

I wasn't able to find anything obvious in the nuxt org on GitHub, but I 
did post a question in their discussion forum: 
https://github.com/nuxt/nuxt/discussions/21382


On 6/4/23 3:05 PM, Debadree Chatterjee wrote:

Hey!

So I did a more thorough testing! and it seems there is something 
common in both these two sites they are using the Nuxt Framework and 
the breakage in both of them is similar they have videos on the first 
section of their landing page with animations on top of them, due to 
the breakage it seems the video doesn't load! If you look at the call 
sites too the code looks very similar


for https://maisonyoko.com/
Screenshot 2023-06-05 at 12.24.34 AM.png

for https://crossfitdespentes.fr/
Screenshot 2023-06-05 at 12.25.09 AM.png

Both of them nuxt
Screenshot 2023-06-05 at 12.27.12 AM.png
Screenshot 2023-06-05 at 12.27.50 AM.png

I am not familiar with nuxt I will try to get to know about it, but it 
seems like there could be some problem with nuxt, If any reader here 
knows nuxt would love to reach out!


Thank You
Debadree
On Wednesday, May 31, 2023 at 9:38:18 PM UTC+5:30 Debadree Chatterjee 
wrote:


Hey Philip!

In my initial testing, I didn't see any observable change in site
behavior, but I shall confirm once again!

As for the kill switch and use counter should I update my existing
CL to include these or make a new one containing the counter to
just measure the effects?


On Wednesday, May 31, 2023 at 9:28:39 PM UTC+5:30 Philip
Jägenstedt wrote:

Hi Debadree,

Thank you so much for your hard work on this.

To confirm, these two sites were from the 20 listed earlier in
this thread, is that right? Now that we've confirmed that
these two sites will have a different behavior, can you
observe any difference on https://maisonyoko.com/ or
https://crossfitdespentes.fr/ with the changes, but without
the exception-throwing?

Generally, finding a behavior change in 10% of tested sites is
a bit concerning, but if it means that only ~10% of the cases
hit by the use counter

are problematic, it could be <0.001% of sites, and we've
successfully made breaking changes at that level in the past.

Since you now have the code for throwing an exception, would
it be straightforward to turn that into a use counter that we
can land and get a better measure of this? I think as
discussed previously in this thread, we should considering
shipping this with a killswitch and a use counter, so we can
both revert and check the usage if we get reports of breakage.

Best regards,
Philip

On Tue, May 30, 2023 at 5:16 PM Debadree Chatterjee
 wrote:

Hey Philip!

Even I was surprised, turns out I was wrong about the
delete function (so sorry), I have observed a breakage now,

The has function output example:
Screenshot 2023-05-30 at 7.36.36 PM.png


The updated delete function:

```c++
void URLSearchParams::deleteAllWithNameOrTuple(const
String& name,
                                               const
String& value, ExceptionState& exception_state) {
  std::vector indices_to_remove_with_name_val,
indices_to_remove_with_name;
  for (wtf_size_t i = 0; i < params_.size(); i++) {
    if (params_[i].first == name &&
        (value.IsNull() || params_[i].second == value)) {
      indices_to_remove_with_name_val.push_back(i);
    }
  }

  for (wtf_size_t i = 0; i < params_.size(); i++) {
    if (params_[i].first == name) {
      indices_to_remove_with_name.push_back(i);
    }
  }

  if (indices_to_remove_with_name_val.size() !=
indices_to_remove_with_name.size()) {
    DLOG(ERROR) << "indices_to_remove_with_name_val.size()
!= indices_to_remove_with_name.size()";
    exception_state.ThrowException(1, "Divergent behavior");
    return;
  }

  // match the values of indices_to_remove_with_name_val,
indices_to_remove_with_name
  for (size_t i = 0; i <
indices_to_remove_with_name_val.size(); i++) {
    if (indices_to_remove_with_name_val[i] !=
indices_to_remove_with_name[i]) {
      DLOG(ERROR) << "indices_to_remove_with_name_val[i]
!= indices_to_remove_with_name[i]";
      exception_state.ThrowException(1, "Divergent behavior");
      return;
    }
  }

  for (wtf_size_t i = 0; i < params_.size();) {
    if 

Re: [blink-dev] Intent to Experiment: COOP: restrict-properties

[Mike Taylor]

LGTM to experiment from M116 to M119 inclusive.

On 6/1/23 3:19 AM, 'Arthur Hemery' via blink-dev wrote:



Contact emails

ahem...@chromium.org


Explainer

https://github.com/hemeryar/coi-with-popups


Specification

https://github.com/whatwg/html/issues/6364


Summary

Cross-Origin-Opener-Policy is used to sever the relationship between 
popup and openers, to increase security. "restrict-properties" is a 
proposed value that restricts the relationship instead of completely 
severing it. It would enable crossOriginIsolated when paired with COEP.




Blink component

Blink>SecurityFeature>COOP 




Search tags

COOP , 
restrict-properties 






Risks



Interoperability and Compatibility

It could fail to become an interoperable part of the web platform if 
other browsers do not implement it. The OT is intended to gather user 
feedback to get support from Mozilla.




/Gecko/: No signal

/WebKit/: No signal

/Web developers/: No signals

/Other signals/: Have a few partners interested in trying this out 
like Zoom and Facebook, as well as a couple of internal partners 
(altimin@ for perfetto dashboards, vickyzhu@ for gmail, etc.).



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

The goal for this experiment is to give partners the possibility to 
try the new value at scale and to discover potential deployment 
blockers that were not anticipated (e.g. external dependency, 
same-origin communications required, etc.)



Debuggability

COOP reporting will support restricted cross-origin properties 
reporting, similar to what exists for other COOP values.



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

Yes

COOP is parsed on all platforms, but the process model implied might vary.



Is this feature fully tested by web-platform-tests

?

Yes under 
wpt/html/cross-origin-opener-policy/tentative/restrict-properties.



Flag name

--enable-features='CoopRestrictProperties'


Requires code in //chrome?

False


Tracking bug

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


Launch bug

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


Estimated milestones

OriginTrial desktop last119
OriginTrial desktop first   116

OriginTrial Android last119
OriginTrial Android first   116




Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5072630953017344


Links to previous Intent discussions

Previous Intent to experiment, dropped because implementation was 
incomplete: 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAF07A2UMOnEEY%2BG4bjE6kiPtw9insquxztWYDb%3DE9bnb-_dZow%40mail.gmail.com
Intent to 
prototype: 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAF07A2Uw-Oh0d7ktTPnV%3D8TTrr%2BNcTgfiLxzFd2P2QLD18qNsw%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/CAF07A2U6Roco9aJwOxCv9vFhXffbOyZDcxiEOKH3cEC6GJsp0w%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/ba4f730d-f23d-1d6e-81fb-2a05aa6caacd%40chromium.org.

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

[Mike Taylor]

LGTM2

On 5/31/23 10:30 AM, Rick Byers wrote:
Yes, 100%. Very good point, I was definitely over-simplifying the 
measurement challenge. Thanks David!


On Tue, May 30, 2023, 5:47 p.m. David Baron  wrote:

I was trying to avoid being too specific about what would be worth
measuring both because I haven't taken the time to think through
all the details, and because other folks on this thread have a lot
of domain expertise that can help figure out what makes sense.  I
just wanted to point out that if you are measuring stuff, it's
worth considering that it may be useful to measure something about
usage of system versus downloaded fonts in order to understand
variation between machines (which I agree is at least mostly
variation between platforms).

-David

On Tue, May 30, 2023 at 11:44 AM Dominik Röttsches
 wrote:

Hi David and Rick,

It's a shame to me to be holding back interop on the case
of fonts having the superscript or subscript glyphs out of
fear for the case where they don't. Perhaps we can treat
the case of font-variant-position being used with fonts
that lack the glyphs as a site bug that we can work to
address independently? Personally, as long as Safari and
Chrome behave the same here, I'm skeptical that the lack
of synthesis would turn into a non-trivial problem in
practice.


I think expectations as to what should the browser do vs. what
is reasonably expected of site owners in terms of font
selection and visual delivery is on a spectrum (font fallback
being a similar case).
In the case of using font-variant-position, I tend to agree
with Rick: I'd consider using font-variant-position without a
suitable font is a site bug. Safari seems to be of the same
opinion by shipping font-variant-position without synthesis.

If we were to ship without synthesis, would it be
practical to have a UseCounter which measures how often we
see font-variant-position used with a font that lacks the
glyphs? This would tell us how important the bug is. If it
remains really rare, then IMHO we've probably already
wasted more energy worrying about it than it's worth. If
it becomes more common over time then I think we have a
variety of options, chiefly implementing synthesis, but
also raising awareness with devtools features, UKM-based
site-specific outreach, and possibly even interventions of
some form (like using a fallback font?). 



It's difficult to measure the visual end result accurately:
Only at shaping time we know exactly which font binary is
used. This in HarfBuzzShaper and we can determine whether the
`sups` and `subs` OpenType features

 
are
requested (we would need extra code for determining whether
these features were requested through font-variant-position:
or font-feature-settings). Then we can determine whether the
font has such a feature in its shaping tables. The difficulty
is: We reach the shaping code lots of times for every relayout
or web font arriving. So initially, we may shape with a
fallback font before the web font arrives, which affects the
measurement result. Measuring in shaping is not synchronized
with a stable layout stage or something like a "done" state of
the page. So we could get to an approximation, but in shaping
we can't currently determine what's the last state that
"stayed" and was perceived by the user.

David wrote:

So if it makes sense to add use counters to understand the
compatibility implications here, I think it may be worth
adding what we would need to understand the breakdown of
how many sites are using this in a way that (a) is
interoperable across browsers/machines versus (b) is
broken in some browsers and working on others versus (c)
is broken on some machines and working on other machines,
even using the same browser.  I suspect this would mean
something like measuring how often we see
font-variant-position used with a system font versus a
downloadable font.  (This might also need to be recorded
along with the data on whether the font has or lacks the
superscript/subscript glyphs, because the intersection of
the two might be interesting.)


I do agree this feature is most meaningful in combination with
web fonts. Or even more specifically: Selecting
font-variant-position needs to be carefully synced 

Re: [blink-dev] Intent to Ship: Partitioning Storage, Service Workers, and Communication APIs

[Mike Taylor]

OK - let's consider this I2S officially revived. Looking for a 3rd LGTM 
to begin shipping in M115.


We have implemented 3rd party deprecation trial support for M115+ (see 
https://developer.chrome.com/blog/storage-partitioning-deprecation-trial/#participate-in-the-deprecation-trials), 
and extended the deprecation trial's expiration date accordingly to 
account for the delay. And we have the Enterprise policy ready to go.


The rollout schedule will look something like the following, pending 
metrics and compatibility stability:


July 25th: 1% of Stable population (approximately 1 week after M115 is 
released)

Aug 8th: 10%
Aug 22nd: 50%
Sep 5: 100%

As always, if we discover significant user-facing breakage we'll explore 
pausing or rolling back to address.


thanks,
Mike

On 5/1/23 10:43 AM, Mike Taylor wrote:


Thanks Rick and Yoav.

We learned from two partners (one internal, one external) late last 
week that a 3P deprecation trial would be needed for them to preserve 
widely-used functionality while they work on a migration strategy.


We're tracking the work in crbug.com/1441411 and hope to have that 
ready by M115. Once we land the fix, I'll circle back and look for a 
3rd LGTM and have an updated rollout schedule. :)


On 5/1/23 12:21 AM, Yoav Weiss wrote:

LGTM2

On Thu, Apr 27, 2023, 16:23 Rick Byers  wrote:



On Wed, Apr 26, 2023 at 2:02 PM Mike Taylor
 wrote:

On 4/26/23 9:36 AM, Mike Taylor wrote:

> On 4/25/23 12:00 PM, Rick Byers wrote:
>
>> In terms of the standards / process piece, it looks as if
the spec
>> PRs have all stalled for several months. What do you think is
>> necessary to get these unblocked and landed? As the last
engine to
>> implement this behavior, perhaps we shouldn't feel too
compelled to
>> block shipping on PRs landing?

I was gently reminded offline that I didn't answer this part
of your
question - oops.

Right now it seems to me that the costs of landing these spec
PRs is
higher than we're willing to block on, given the requested
refactoring
(and yes, it's unfortunate that 3 engines would be shipping
essentially
unspecced behavior, but that's where we're at). That said,
I'm happy to
devote my few IC hours to pushing these along as a personal
project over
the coming months.


Thanks Mike. I trust your and wanderview@'s judgement here - I
know how hard y'all have been willing to work in the past to get
the right thing done in specs. Thanks for being willing to keep
pushing in parallel. But given two other implementations have
already shipped this, it was clearly already a spec bug that the
spec didn't reflect reality. I agree that we shouldn't block
shipping a 3rd implementation on spec refactoring work.

LGTM1 to ship from my perspective. Obviously this will need a
very thoughtful and careful roll-out. But I trust Mike and his
team to engage with impacted folks to make sure it goes smoothly,
as they did with UA reduction.



--
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/bc52292b-9142-adad-d126-b93231468ed0%40chromium.org.

Re: [blink-dev] Intent to Extend Experiment: Speculation Rules - Document rules, response header, deliveryType

[Mike Taylor]

LGTM to extend to 118 inclusive.

On 5/24/23 3:30 PM, Jeremy Roman wrote:



Contact emails


jbro...@chromium.org, adith...@chromium.org,
isabo...@google.com, dome...@chromium.org,
kenjibah...@chromium.org


Explainer


https://github.com/WICG/nav-speculation/blob/main/triggers.md


https://github.com/w3c/resource-timing/issues/332



Specification


https://wicg.github.io/nav-speculation/speculation-rules.html



Summary



Three enhancements to preloading, under a combined experiment:


An extension to speculation rules syntax that lets the browser
obtain URLs for speculation from link elements in a page. They
may include criteria which restrict which of these links can
be used.


Currently developers can only specify speculation rules using
inline script tags.  The proposed feature provides an
alternative through the "Speculation-Rules" header. Its value
must be a URL to a text resource with
"application/speculationrules+json" MIME type. The resource's
rules will be added to the document's rule set.


Expose information about how a resource was delivered. For
example, resources which were delivered from the cache
(currently exposed through transferSize) and navigations which
were prefetched by the previous page are useful to identify.


An overview of this experiment remains available here:


https://github.com/jeremyroman/nav-speculation/blob/experiment-summary/chrome-2023q1-experiment-overview.md



See also the previous intent:

https://groups.google.com/a/chromium.org/g/blink-dev/c/3-0rLTZePzc/m/VNHWAdAGDQAJ


Blink component


Internals>Preload




TAG review


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



TAG review status


Complete at this time. TAG has reservations about whether the
use cases of this feature justify its complexity, as compared
to a simpler solution which would address some but not all of
the use cases.


Risks




Interoperability and Compatibility


Because authors cannot rely on speculation rules being
evaluated (or preloading generally), applications which use
them should function correctly in other browsers and should
continue to function correctly were the feature to be
deprecated. Of course, ideally other browsers do find it
compelling to implement this feature.



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


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


Web developers: We built these enhancements specifically upon
requests from partners that found the current speculation
rules too hard to integrate into their sites, and have at
least one partner lined up to participate in the origin trial.


Other signals:


Activation


Some developers might not be immediately aware of which URLs
they can preload without side effects. This risk is reduced if
they primarily use the feature for same-origin URL patterns
they are familiar with.



Security



Seehttps://wicg.github.io/nav-speculation/speculation-rules.html#security-considerations

.



WebView application risks


None that are specifically anticipated.



Justification for extension


During the experiment, we have made improvements to these
features, fixed bugs, and improved developer tools to make
them easier to debug. We have some data from use of this
showing benefits, but want to both make further improvements
to our implementation and give more time for partners to
engage (there were unforeseen delays in at least one instance).


Ongoing technical constraints


At this time the constraints are believed to be minimal.



Debuggability


Preloading and speculation rules fetches which occur are both
visible in the Network panel and the in-development Preloading