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

[Mike Taylor]

Hi there,

Have we done any sort of web compatibility analysis of what this change 
implies? A broken page might be a better choice than a crashed tab, but 
it's hard to know without any sense of the potential impact of this 
change. Also, is there a plan to specify this behavior? What's the 
interop situation?


thanks,
Mike

On 8/1/24 4:38 AM, 'xu ms' via blink-dev wrote:

*Contact emails*: xuzha...@microsoft.com

*Summary：*

We are currently observing many renderer crashes occurring in text 
encode.Encoding Standard (whatwg.org) 


This is because DOMArrayBuffer::Create is currently used to create a 
buffer, and when memory allocation fails, renderer process crashes. 
The reasons for memory allocation failure are unclear and not solely 
due to allocating excessively large memory.


Therefore, we want to change the logic here so that when memory 
allocation fails, a DOMException is thrown from text encode instead of 
crashing.


*Blink component*: Blink>TextEncoding 



*Tracking bug*:[OOM] Is it a real OOM for 
blink::DOMArrayBuffer::Create? [355018938] - Chromium 




--
You received this message because you are subscribed to the Google 
Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f4cfdc62-707f-4d21-80d5-43ed37ce52fan%40chromium.org 
.


--
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c6b00d44-599f-47bf-be3d-9e977681b827%40chromium.org.

Re: [blink-dev] Intent to Ship: Isolated Web Apps

[Mike Taylor]

or LGTM2 - sorry, race condition.

On 7/31/24 11:46 AM, Mike Taylor wrote:


Thanks for the v2 updates.

LGTM1

On 7/30/24 2:09 PM, Reilly Grant wrote:
On Tue, Jul 16, 2024 at 1:20 PM Robbie McElrath 
 wrote:


Thanks - before I jump too deeply into the review, would you
mind requesting the various review gate bits in your
chromestatus entry?

Done. We've been using launch/ for the approvals so far. I added
a link to the corresponding launch/ approval in chromestatus when
applicable.


No, the IWA security rules are enforced with existing web
primitives (CSP/TT, permissions policy, COI) that already
have DevTools support. There is some non-DevTools tooling
needed to build and sign the bundle, but I don't think
there's a use case for adding bundle-related functionality
into DevTools.

Makes sense. Are there plans to build said tooling and make
it available to ease adoption?


Yeah, we already have JS tooling available to create bundles
<https://github.com/WICG/webpackage/tree/main/js/bundle>, sign
bundles <https://github.com/WICG/webpackage/tree/main/js/sign>
(the new integrity block format is already supported), and a
webpack

<https://github.com/GoogleChromeLabs/webbundle-plugins/blob/main/packages/webbundle-webpack-plugin/README.md>
and rollup

<https://github.com/GoogleChromeLabs/webbundle-plugins/tree/main/packages/rollup-plugin-webbundle>
plugin. These make it easy to integrate with existing npm-based
flows, see the telnet demo app

<https://github.com/GoogleChromeLabs/telnet-client/blob/main/webpack.wbn.js#L36>
for an example. There's also a go tool
<https://github.com/WICG/webpackage/tree/main/go/bundle> that can
build and sign bundles, but it doesn't support integrity block v2
yet. Updating the go version has been lower priority as we don't
know of anyone that actually used it.


Integrity block v2 was recently proposed to address key
rotation related issues with v1. The internal design doc is
here: go/iwa-key-rotation
<https://goto.google.com/iwa-key-rotation>. Yes, we will be
speccing this.

Great - any idea of when you might have some version of a
spec draft ready?


The engineer working on this estimates it being done in the next
few weeks.


An update to the Integrity Block explainer with the version 2 format 
landed in https://github.com/WICG/webpackage/pull/892.



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5146307550248960
<https://chromestatus.com/feature/5146307550248960>


Links to previous Intent discussions

Intent to prototype:

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEmk%3DMayyUjocrvyQKgu-bZy_4z5VJ0ijHCAijBTZY2xLwJpJQ%40mail.gmail.com

<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEmk%3DMayyUjocrvyQKgu-bZy_4z5VJ0ijHCAijBTZY2xLwJpJQ%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
<mailto:blink-dev+unsubscr...@chromium.org>.
To view this discussion on the web visit

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANtkjcS1A2rO%2BvHnnPXqc6sxhjenearhCGx9vxt%2BcKqM5otDfA%40mail.gmail.com

<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANtkjcS1A2rO%2BvHnnPXqc6sxhjenearhCGx9vxt%2BcKqM5otDfA%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/02549cbf-4750-4edd-8604-fccabecd52bc%40chromium.org.

Re: [blink-dev] Intent to Ship: Isolated Web Apps

[Mike Taylor]

Thanks for the v2 updates.

LGTM1

On 7/30/24 2:09 PM, Reilly Grant wrote:
On Tue, Jul 16, 2024 at 1:20 PM Robbie McElrath 
 wrote:


Thanks - before I jump too deeply into the review, would you
mind requesting the various review gate bits in your
chromestatus entry?

Done. We've been using launch/ for the approvals so far. I added a
link to the corresponding launch/ approval in chromestatus when
applicable.


No, the IWA security rules are enforced with existing web
primitives (CSP/TT, permissions policy, COI) that already
have DevTools support. There is some non-DevTools tooling
needed to build and sign the bundle, but I don't think
there's a use case for adding bundle-related functionality
into DevTools.

Makes sense. Are there plans to build said tooling and make it
available to ease adoption?


Yeah, we already have JS tooling available to create bundles
, sign
bundles 
(the new integrity block format is already supported), and a
webpack


and rollup


plugin. These make it easy to integrate with existing npm-based
flows, see the telnet demo app


for an example. There's also a go tool
 that can
build and sign bundles, but it doesn't support integrity block v2
yet. Updating the go version has been lower priority as we don't
know of anyone that actually used it.


Integrity block v2 was recently proposed to address key
rotation related issues with v1. The internal design doc is
here: go/iwa-key-rotation
. Yes, we will be
speccing this.

Great - any idea of when you might have some version of a spec
draft ready?


The engineer working on this estimates it being done in the next
few weeks.


An update to the Integrity Block explainer with the version 2 format 
landed in https://github.com/WICG/webpackage/pull/892.



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5146307550248960



Links to previous Intent discussions

Intent to prototype:

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEmk%3DMayyUjocrvyQKgu-bZy_4z5VJ0ijHCAijBTZY2xLwJpJQ%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/CANtkjcS1A2rO%2BvHnnPXqc6sxhjenearhCGx9vxt%2BcKqM5otDfA%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/a690a9e6-bed6-411a-8ae5-291958125e20%40chromium.org.

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

[Mike Taylor]

LGTM3

On 7/25/24 4:35 PM, Chris Harrelson wrote:

LGTM2

On Thu, Jul 25, 2024 at 1:24 AM Daniel Bratell  
wrote:


LGTM1

/Daniel

On 2024-07-25 00:22, Mason Freed wrote:



On Wed, Jul 17, 2024 at 11:51 PM Yoav Weiss (@Shopify)
 wrote:


Have you had a chance to investigate what a breakage
looks like by checking the sites using the feature?


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


So I've been successful in getting in touch with this 3P app
author, and they've already disabled their usage of anchor
positioning generally. So that specific case should be handled.
Generally, the behavior that will be broken by the rename is that
fallback positions will not be attempted, meaning only the
primary anchor position will be used.

I think this rename is fairly safe, but I want to make
sure that we're planning on shipping it with a flag that
would be able to undo the behavior (a killswitch). I
assume having two flags, one to add a new flag and one to
remove the old flag is the easiest way to do that. WDYT?


Thanks, I'm glad you agree that this should be relatively safe,
if done *soon* before usage increases. And to confirm, we do have
two flags (CSSPositionTryFallbacks and CSSPositionTryOptions)
which work exactly as you suggest. We will flip flop their
states, but retain the ability to swap that back via Finch in
case of emergency.

Thanks,
Mason

Thanks,
Vlad



/Gecko/: No signal

/WebKit/: No signal

/Web developers/: No signals

/Other signals/:


WebView application risks

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

None



Debuggability

None



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

Yes


Is this feature fully tested by
web-platform-tests

?

Yes

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



Flag name on chrome://flags

None


Finch feature name

None


Non-finch justification

None


Requires code in //chrome?

False


Tracking bug

https://crbug.com/349600667


Estimated milestones

Shipping on desktop 128
DevTrial on desktop 128

Shipping on Android 128
DevTrial on Android 128

Shipping on WebView 128



Anticipated spec changes

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

None


Link to entry on the Chrome Platform Status


https://chromestatus.com/feature/5090673808900096?gate=5938066895405056

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

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

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDj38gT4PfU4fCXhkdAOLvdY8c_sgukkotmHnC6wTZoDhQ%40mail.gmail.com

.

-- 

Re: [blink-dev] Intent to Experiment: FedCM as a trust signal for the Storage Access API

[Mike Taylor]

On 7/24/24 8:06 PM, Chris Fredrickson wrote:

My apologies, I misunderstood the process here. I hereby formally 
request an extension for this OT, through M129 :)

Thanks, I formally LGTM the request to M129 inclusive. :)
Re: the OT dashboard, I've already requested an OT extension through 
the chromestatus entry; I believe the OT dashboard will be updated to 
reflect that once the OT team approves that request.
Great - I think the OT team typically chases down LGTMs - so you should 
be set now.


Chris

On Wednesday, July 24, 2024 at 1:52:53 PM UTC-4 Mike Taylor wrote:

Hey Chris,

Per the process, you'll need to formally request an extension,
rather than treat this as an FYI.

(Also, I just double checked and

https://developer.chrome.com/origintrials/#/register_trial/4008766618313162753

<https://developer.chrome.com/origintrials/#/register_trial/4008766618313162753>
is only available until M127. Note there's a 2 month "grace
period" where it will continue to work for users on 126 or 127
that haven't upgraded to M128 or higher - but it should not work
in 128 or 129.)

thanks,
Mike

On 7/24/24 4:03 PM, Chris Fredrickson wrote:

FYI, we're going to extend this OT another 2 milestones, to 129
inclusive. (Existing OT tokens will still work, they won't expire
IIUC.)

On Tuesday, May 7, 2024 at 11:02:03 AM UTC-4 Mike Taylor wrote:

LGTM to experiment from 126 to 127 inclusive.

On 5/7/24 10:52 AM, Chris Fredrickson wrote:


Contact emails

joha...@chromium.org, cfre...@chromium.org, yi...@chromium.org


Explainer

https://github.com/explainers-by-googlers/storage-access-for-fedcm
<https://github.com/explainers-by-googlers/storage-access-for-fedcm>


Specification

None (TBD)


Summary

Reconciles the FedCM and Storage Access APIs by making a
prior FedCM grant a valid reason to automatically approve a
storage access request.


When a user grants permission for using their identity with
a 3rd party Identity Provider (IdP) on a Relying Party (RP),
many IdPs require third-party cookies to function correctly
and securely. This proposal aims to satisfy that requirement
in a private and secure manner by updating the Storage
Access API (SAA) permission checks to not only accept the
permission grant that is given by a storage access prompt,
but also the permission grant that is given by a FedCM prompt.


A key property of this mechanism is limiting the grant to
cases explicitly allowed by the RP via the FedCM permissions
policy, enforcing a per-frame control for the RP and
preventing passive surveillance by the IdP beyond the
capabilities that FedCM already grants, as outlined in the
Privacy Considerations

<https://github.com/explainers-by-googlers/storage-access-for-fedcm?tab=readme-ov-file#privacy-considerations>.



Blink component

Blink>StorageAccessAPI


TAG review

None


TAG review status

N/A


Risks



Interoperability and Compatibility

None




Gecko: No public signals, positive initial signals

<https://docs.google.com/document/d/1jxqW4kvGdclIWsOlWMXWLGpwu1wOorST2Ol6vJKAjDE/edit#heading=h.y0ecc5cfr86n>.
We will request a formal position.


WebKit: No signal. We will request a formal position.


Web developers: Positive
<https://github.com/fedidcg/FedCM/issues/467>


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


Goals for experimentation

Evaluate the implementation, and the usability of the
feature to ensure it adequately solves the problem.


Ongoing technical constraints

None


Debuggability

None


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

No. It will not be supported in Android WebView.


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

No. The implementation is primarily in permissions code in
//chrome, which cannot be tested in WPTs since WPTs use a
fake permission manager

<https://crsrc.org/c/content/web_test/browser/web_test_permission_manager.h;drc=33b441e83b1f70381158fcafb0ecde9168b79524;l=28>in
Chromium.


Flag name on chrome://flags

#fedcm-with-storage-access-api


Finch feature name

FedCmWithStorageAccessAPI


Non-finch justification

None

Re: [blink-dev] Intent to Experiment: FedCM as a trust signal for the Storage Access API

[Mike Taylor]

Hey Chris,

Per the process, you'll need to formally request an extension, rather 
than treat this as an FYI.


(Also, I just double checked and 
https://developer.chrome.com/origintrials/#/register_trial/4008766618313162753 
is only available until M127. Note there's a 2 month "grace period" 
where it will continue to work for users on 126 or 127 that haven't 
upgraded to M128 or higher - but it should not work in 128 or 129.)


thanks,
Mike

On 7/24/24 4:03 PM, Chris Fredrickson wrote:
FYI, we're going to extend this OT another 2 milestones, to 129 
inclusive. (Existing OT tokens will still work, they won't expire IIUC.)


On Tuesday, May 7, 2024 at 11:02:03 AM UTC-4 Mike Taylor wrote:

LGTM to experiment from 126 to 127 inclusive.

On 5/7/24 10:52 AM, Chris Fredrickson wrote:


Contact emails

joha...@chromium.org, cfre...@chromium.org, yi...@chromium.org


Explainer

https://github.com/explainers-by-googlers/storage-access-for-fedcm
<https://github.com/explainers-by-googlers/storage-access-for-fedcm>


Specification

None (TBD)


Summary

Reconciles the FedCM and Storage Access APIs by making a prior
FedCM grant a valid reason to automatically approve a storage
access request.


When a user grants permission for using their identity with a 3rd
party Identity Provider (IdP) on a Relying Party (RP), many IdPs
require third-party cookies to function correctly and securely.
This proposal aims to satisfy that requirement in a private and
secure manner by updating the Storage Access API (SAA) permission
checks to not only accept the permission grant that is given by a
storage access prompt, but also the permission grant that is
given by a FedCM prompt.


A key property of this mechanism is limiting the grant to cases
explicitly allowed by the RP via the FedCM permissions policy,
enforcing a per-frame control for the RP and preventing passive
surveillance by the IdP beyond the capabilities that FedCM
already grants, as outlined in the Privacy Considerations

<https://github.com/explainers-by-googlers/storage-access-for-fedcm?tab=readme-ov-file#privacy-considerations>.



Blink component

Blink>StorageAccessAPI


TAG review

None


TAG review status

N/A


Risks



Interoperability and Compatibility

None




Gecko: No public signals, positive initial signals

<https://docs.google.com/document/d/1jxqW4kvGdclIWsOlWMXWLGpwu1wOorST2Ol6vJKAjDE/edit#heading=h.y0ecc5cfr86n>.
We will request a formal position.


WebKit: No signal. We will request a formal position.


Web developers: Positive
<https://github.com/fedidcg/FedCM/issues/467>


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


Goals for experimentation

Evaluate the implementation, and the usability of the feature to
ensure it adequately solves the problem.


Ongoing technical constraints

None


Debuggability

None


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

No. It will not be supported in Android WebView.


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

No. The implementation is primarily in permissions code in
//chrome, which cannot be tested in WPTs since WPTs use a fake
permission manager

<https://crsrc.org/c/content/web_test/browser/web_test_permission_manager.h;drc=33b441e83b1f70381158fcafb0ecde9168b79524;l=28>in
Chromium.


Flag name on chrome://flags

#fedcm-with-storage-access-api


Finch feature name

FedCmWithStorageAccessAPI


Non-finch justification

None


Requires code in //chrome?

True


Estimated milestones

M126 through M127 (inclusive).



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5116478702747648
<https://chromestatus.com/feature/5116478702747648>


Links to previous Intent discussions

Intent to prototype:

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAD_OO4iogs7O60r0YcVnDB5aCvs9WUYjWFcuHqcFi5bXLRBOig%40mail.gmail.com

<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAD_OO4iogs7O60r0YcVnDB5aCvs9WUYjWFcuHqcFi5bXLRBOig%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+...@chromium.org.
To view this discussion on the web visit

https://groups.google.com/a/chromium.org/d/msg

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

[Mike Taylor]

LGTM2

On 7/17/24 6:22 PM, Chris Harrelson wrote:

LGTM1

On Fri, Jul 12, 2024 at 1:10 PM 'Akash Nadan' via blink-dev 
 wrote:


Hi All,

*
*

Just adding some additional detail regarding the interoperability
and compatibility of this feature:

*
*

Interoperability and Compatibility

This change is optional and will be fully backwards compatible
once Aggregation Service release 2.3 reaches end-of-support on
August 2nd (before M128 reaches Stable).

*
*

Additionally, developers that want to use this new feature will
need to upgrade their Aggregation Service release to version 2.5
or later. The Aggregation Service is used to process the
aggregatable reports that a developer receives. We have notified
partners of these considerations through the API mailing list

.
A similar feature is being released for thePrivate Aggregation
API, with the same Aggregation Service considerations

.

Thanks,

Akash


On Thursday, July 11, 2024 at 12:54:08 PM UTC-7 Akash Nadan wrote:

Contact emails

akash...@google.com, lin...@chromium.org, john...@chromium.org


Explainer

Attribution Reporting with event-level reports


Attribution Reporting API with Aggregatable Reports



Aggregation Service for the Attribution Reporting API




Specification

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



Blink component

Internals > AttributionReporting




TAG review

Still under review
under the
original I2S for the Attribution Reporting API


TAG review status

Pending


Summary

We are landing the following change to the Attribution
Reporting API focused on:

 *

Improving API report batching capabilities


This change is based on ad-tech feedback that we heard
regarding the need for additional report batching flexibility
so that different report contributions can be batched at
different cadences.


Currently aggregatable reports generated by the API can
consist of multiple separate contributions which are key:value
pairs. API callers can batch together aggregatable reports and
then process them in the aggregation service, which consists
of decrypting the reports, aggregating the values, and adding
noise, before returning a summary report to the API caller.
Additionally, all contributions in an aggregatable report must
currently be processed by aggregation service at the same time.


With this change, the API will now allow API callers to
specify filtering IDs as part of each contribution (i.e. each
key:value pair) in the aggregatable report. API callers can
then use these filtering IDs, which will also be part of the
encrypted payload of the report, to specify which
contributions they want to have processed by the aggregation
service at a given time.


This will allow API callers to process contributions with
different filtering IDs at different cadences. Allowing this
flexibility is a utility improvement, because the noise added
in the aggregation service per key:value pair bucket may have
a lower relative impact on values that are batched on a longer
cadence.


Explainer/Spec changes

1.

Flexible contributions filtering



Risks
Interoperability and Compatibility

This is an optional and fully backwards compatible change.
This feature provides a new filtering ID that can be set as
part of the aggregatable report contributions and does not
break any pre-existing API or web functionality.


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


WebKit: No signal (Original request:
https://github.com/WebKit/standards-positions/issues/180
)


Web developers:

Re: [blink-dev] Intent to Extend Experiment: Explicit Compile Hints with Magic Comments

[Mike Taylor]

Thanks for the clarification. LGTM to (re-)run 129 to 131 inclusive.

On 7/24/24 4:37 AM, Marja Hölttä wrote:
Yes, the OT expired and I'd like to run a new one. There was no way to 
input the "beginning milestone number" for the extension in Chromestatus.



On Mon, Jul 22, 2024 at 5:56 PM Mike Taylor  
wrote:


Just to clarify: this ran as an OT from 115 to 117, and has been
disabled since then?

And you're requesting to run another OT (vs extending a currently
active one) from 129 to 131.

Do I have that correct?

On 7/22/24 5:56 AM, 'Marja Hölttä' via blink-dev wrote:



Contact emails

ma...@google.com, lesz...@google.com


Explainer


https://github.com/explainers-by-googlers/explicit-javascript-compile-hints-file-based/blob/main/README.md


Specification

None


Summary

Allow attaching information about which functions should be eager
parsed & compiled in JavaScript files. The information will be
encoded as magic comments. We'll first target launching the
file-based explicit compile hints, and as a follow up,
investigate selecting individual functions for eager compilation.



Blink component

Blink>JavaScript

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


TAG review



TAG review status

Pending


Chromium Trial Name

JavaScriptCompileHintsMagic


Link to origin trial feedback summary

https://google.qualtrics.com/jfe/form/SV_9SLyOGnTj2cwo0C


Origin Trial documentation link


https://docs.google.com/document/d/19xTAM4A75tz0xUq_velMzGA4JHEgXpyflUxXTcuNiyE/edit?usp=sharing


Risks



Interoperability and Compatibility

No interoperability / compatibility risks. Other browsers are
likely to ignore the hints if they perceive they cannot benefit
from them. Ignoring the hint is allowed behavior. We plan to make
the hints generic though, so that other browsers can later start
to support them too, e.g., if they implement background parsing /
compilation.



/Gecko/: N/A
(https://github.com/mozilla/standards-positions/issues/780)

/WebKit/: N/A
(https://github.com/WebKit/standards-positions/issues/172)

/Web developers/: Positive Positive signals from partners who
want to use compile hints to eager-compile core JS files.

/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

We'd like to measure the performance of the improved feature
implementation in userland partner metrics.


Reason this experiment is being extended

The origin trial configuration for this feature was broken in
M115-M116, and the users weren't able to run the experiments.



Reason this experiment is being extended

We did an origin trial in versions 115-117. We modified the
feature based on the results (performance measurements by Google
Workspace) and we'd now like to do another origin trial with the
modified feature, in versions 129-131.



Ongoing technical constraints



Debuggability



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

Yes


Is this feature fully tested by web-platform-tests

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

No

The feature doesn't trigger any functional changes and cannot be
tested by WPT.



Flag name on chrome://flags



Finch feature name

None


Non-finch justification

None


Requires code in //chrome?

False


Tracking bug

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


Estimated milestones

Origin trial desktop first  115
Origin trial desktop last   117
Origin trial extension 1 end milestone  120
Origin trial extension 2 end milestone  131



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5100466238652416?gate=5198754872819712


Links to previous Intent discussions

Intent to Experiment:

https://groups.google.com/a/chromium.org/g/blink-dev/c/BmN1Wus8V1s/m/3L2uU-wGAgAJ
Intent to Extend Experiment 1:

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



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

-- 


Google Germany GmbH

Erika-Mann-Straße 33

80636 München

*
*

Geschäftsfü

Re: [blink-dev] Re: Intent to Ship: Web Permissions API on WebView

[Mike Taylor]

Yep - thanks Peter. The review gates are still part of the process, even 
for cases such as this.


On 7/23/24 4:42 AM, Peter Birk Pakkenberg wrote:
I have requested the review gates as mentioned by Domenic, but I do 
want to point out that this feature has been in production since 2015 
in Chrome, and that we're just closing the loop in bringing it to 
WebView.



Sincerely,
Google Logo 
Peter Birk Pakkenberg
Software Engineer
pb...@chromium.org



On Tue, 23 Jul 2024 at 01:14, Domenic Denicola  
wrote:


LGTM2

On Tue, Jul 23, 2024 at 3:49 AM Mike Taylor
 wrote:

LGTM1

On 7/18/24 10:34 PM, Domenic Denicola wrote:

Always exciting to get full cross-platform support!

Can you request the privacy / security / enterprise /
debuggability / testing review gates on ChromeStatus? After
those are in progress I'll be happen to LGTM.

On Thursday, July 18, 2024 at 9:00:41 PM UTC+9 Peter
Pakkenberg wrote:


Specification

https://w3c.github.io/permissions/


Summary


This Intent to Ship covers the launch of the Web
Permission API in WebView, an API that has already
launched in other browsers and embedders.


WebView has a more limited permission model than other
embedders, namely, it doesn’t support separating
“checking permission state” from “requesting
permissions”, and the Permission API implementation we
ship will reflect this. In particular, the API will
respond with “denied” for APIs that are not supported by
WebView, “granted” for permissions that WebView
automatically grants (midi, sensors) and “prompt” for
APIs where permission is handled by sending a callback to
the WebView-embedding app

<https://developer.android.com/reference/android/webkit/WebChromeClient#onPermissionRequest(android.webkit.PermissionRequest)>(camera,
microphone, midi-sysex). WebView does offer support for
persistent permissions for the Geolocation API, so in
apps that use that feature, WebView will respond with
“granted” or “prompt” depending on the choices made by
the embedding app.


Blink component

Blink>PermissionsAPI

<https://g-issues.chromium.org/issues?q=status:open%20componentid:1456441=created_time:desc>

Mobile>WebView

<https://g-issues.chromium.org/issues?q=status:open%20componentid:1456456=created_time:desc>


TAG review

None


TAG review status

Not applicable


Risks


Interoperability and Compatibility


The API is already implemented in all major browsers
<https://caniuse.com/permissions-api>. This Intent to
Ship covers the launch in WebView.


WebView application risks

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


This launch does not change any existing behaviour in
WebView. However, websites should be aware that they will
now be able to use the permissions.query API, which was
previously not exposed, and for some APIs (microphone,
camera, and MIDI SysEx), they will always get a response
of “prompt”. This reflects the fact that these
permissions are always forwarded to the embedding app

<https://developer.android.com/reference/android/webkit/WebChromeClient#onPermissionRequest(android.webkit.PermissionRequest)>.


Debuggability

None



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

Yes


Is this feature fully tested by
web-platform-tests

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

Yes
<https://github.com/web-platform-tests/wpt/tree/master/permissions>,
where results will be published to wpt.fyi

<https://wpt.fyi/results/permissions?label=master=experimental=chrome=firefox=safari=android_webview>


Flag name on chrome://flags

None


Finch feature name

WebPermissionsApi


Requires code in //chrome?

False


Tracking bug

https://issues.chromium.org/issues/348635849
   

Re: [blink-dev] Intent to Ship: Remove PointerEvent.getCoalescedEvents() from insecure contexts

[Mike Taylor]

Could you also request the Enterprise bit?

In the meantime - I'd love to know more about `[SecureContext=flag]` not 
working - that capability was introduced to make these types of roll 
outs safer, IIRC. In the past I've had to write postmortems because I 
thought usage was low enough, but the breakage was in enterprise 
environments that disable telemetry... and didn't have a finch flag to 
quickly revert. :(


(I'm also not trying to send you on an impossible side-quest, but won't 
be sad if someone is nerd sniped into fixing what feels like a regression).


On 7/18/24 10:31 PM, Domenic Denicola wrote:
LGTM1. It's a bit scary doing this without a Finch flag, but the usage 
is very low and such pages are already broken in Firefox.


On Fri, Jul 19, 2024 at 1:00 AM Mustaq Ahmed  wrote:



On Wed, Jul 17, 2024 at 2:20 PM Mike Taylor
 wrote:

On 7/17/24 10:18 AM, Mustaq Ahmed wrote:


> Can you ask for WebKit's position? Or maye there's at least
a pointer to working group discussions they participated in?

- Safari doesn't yet support
PointerEvent.getCoalescedEvents(), so we can't ask for their
position on secure/non-secure context differences:

https://developer.mozilla.org/en-US/docs/Web/API/PointerEvent/getCoalescedEvents#browser_compatibility

That's OK - we ask for positions from them all the time for
things they don't support.


Done: https://github.com/WebKit/standards-positions/issues/374


- Here is a PEWG discussion started by @gsnedders from WebKit
(I couldn't find any other related discussion
Safari participated in):
https://github.com/w3c/pointerevents/issues/215

To my knowledge, that was posted a few years before Sam
started working at Apple.


I missed this, sorry.  My corrected answer is: "I couldn't find
any PEWG discussion on Coalesced Events where Safari participated".


> Our process requires a Finch feature in general. And this
sort of potentially-risky removal seems like the kind of
thing that benefits from a Finch feature, so that it can be
remotely reverted if it causes terrible regressions.

Unfortunately we can't put this change behind a flag because
Blink does not allow making [SecureContext] conditional.  I
think it was supported in the past because "Blink IDL
Extended Attributes" documentation still mentions
[SecureContext=flag] as non-standard, but it doesn't even
compile!

https://chromium.googlesource.com/chromium/src/+/HEAD/third_party/blink/renderer/bindings/IDLExtendedAttributes.md#securecontext


On Tue, Jul 16, 2024 at 9:30 PM Domenic Denicola
 wrote:



On Wed, Jul 17, 2024 at 6:52 AM Mustaq Ahmed
 wrote:


Contact emails

mus...@chromium.org


Explainer

None


Specification

https://w3c.github.io/pointerevents/#pointerevent-interface


Summary

The Pointer Events Working Group made
PointerEvent.getCoalescedEvents() restricted to
secure contexts 4+ years ago, which removed the API
from insecure contexts. Chrome originally shipped the
old behavior and didn't follow the spec change
immediately because of compat concerns. We are now
removing it from insecure contexts because Chrome
usage in insecure contexts turned out to be very low.



Blink component

Blink>Input

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


TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

Interop: This will improves Interop, making Chrome
fully match Firefox (and the spec). Compat: There is
a bit of risk because the usage is non-zero (~0.0004%
as of 2024-07-16). This usage stat is expected to
include non-breaking JS enumerations.

https://chromestatus.com/metrics/feature/timeline/popularity/4598



/Gecko/: Shipped/Shipping

/WebKit/: No signal


Can you ask for WebKit's position? Or maye there's at
least a pointer to working group discussions they
participated in?


/Web developers/: No signals

/Other signals/:


WebView application risks

Does this intent deprecate or change behavior of
existing APIs, suc

Re: [blink-dev] Re: Intent to Ship: Web Permissions API on WebView

[Mike Taylor]

LGTM1

On 7/18/24 10:34 PM, Domenic Denicola wrote:

Always exciting to get full cross-platform support!

Can you request the privacy / security / enterprise / debuggability / 
testing review gates on ChromeStatus? After those are in progress I'll 
be happen to LGTM.


On Thursday, July 18, 2024 at 9:00:41 PM UTC+9 Peter Pakkenberg wrote:


Specification

https://w3c.github.io/permissions/



Summary


This Intent to Ship covers the launch of the Web Permission API in
WebView, an API that has already launched in other browsers and
embedders.


WebView has a more limited permission model than other embedders,
namely, it doesn’t support separating “checking permission state”
from “requesting permissions”, and the Permission API
implementation we ship will reflect this. In particular, the API
will respond with “denied” for APIs that are not supported by
WebView, “granted” for permissions that WebView automatically
grants (midi, sensors) and “prompt” for APIs where permission is
handled by sending a callback to the WebView-embedding app

(camera,
microphone, midi-sysex). WebView does offer support for persistent
permissions for the Geolocation API, so in apps that use that
feature, WebView will respond with “granted” or “prompt” depending
on the choices made by the embedding app.


Blink component

Blink>PermissionsAPI



Mobile>WebView




TAG review

None


TAG review status

Not applicable


Risks


Interoperability and Compatibility


The API is already implemented in all major browsers
. This Intent to Ship covers
the launch in WebView.


WebView application risks

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


This launch does not change any existing behaviour in WebView.
However, websites should be aware that they will now be able to
use the permissions.query API, which was previously not exposed,
and for some APIs (microphone, camera, and MIDI SysEx), they will
always get a response of “prompt”. This reflects the fact that
these permissions are always forwarded to the embedding app

.


Debuggability

None



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

Yes


Is this feature fully tested by web-platform-tests

?

Yes
,
where results will be published to wpt.fyi




Flag name on chrome://flags

None


Finch feature name

WebPermissionsApi


Requires code in //chrome?

False


Tracking bug

https://issues.chromium.org/issues/348635849



Measurement

Reuse existing use counter for permissions.query.


Availability expectation

Available in all major browsers. This also adds the API to WebView


Adoption expectation

Already widely adopted.


Adoption plan

Already widely adopted.


Non-OSS dependencies

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

No.


Estimated milestones

Shipping on WebView



128






Anticipated spec changes

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

None


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6376494003650560



--
You received this message because you are subscribed to the 

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

[Mike Taylor]

> This change will not cause any site breakage or change for end users 
of Chrome.


LGTM1

On 7/11/24 3:48 PM, 'Akash Nadan' via blink-dev wrote:

Contact emails

akashna...@google.com , 
lin...@chromium.org , 
johni...@chromium.org 



Explainer

Attribution Reporting with event-level reports 



Attribution Reporting API with Aggregatable Reports 



Aggregation Service for the Attribution Reporting API 




Specification

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




Blink component

Internals > AttributionReporting 




TAG review

Still under review 
under the 
original I2S for the Attribution Reporting API



TAG review status

Pending


Summary

We are landing the following change to the Attribution Reporting API 
focused on:


 *

Improving utility by changing the methodology for a rate limit


This change is based on ad-tech feedback that we have heard regarding 
a current rate limit for the Attribution Reporting API.



Currently the API has a limit called the source-destination-limit 
which allows API callers to register up to 100 distinct destinations 
per {source site, reporting site} applied to all unexpired sources per 
browser.



This rate limit also uses a LIFO model (last-in-first-out) in the 
sense that once the limit is reached, any new source registrations 
will be rejected.



We have heard feedback from multiple ad-techs that they are running 
into this limit which then causes some amount of loss in terms of not 
being able to register new sources.



This change proposes to use a FIFO model (first-in-first-out) for this 
rate limit. So once the limit is reached, any new source registration 
will cause the API to delete the oldest pending source registration 
for the same {source site, reporting site} pair, and allow the new 
source registration to be stored.



In order to safely support this FIFO model, the following rate limit 
needs to also be added to the API:


 *

100 distinct destinations per {source site, reporting site, 24 hours}.

 o

This new rate limit will help to prevent any attacks where an
adversary may want to try to cycle through many different
destinations in one attempt


In terms of the rollout plan for this feature, we would like to 
directly switch this rate limit from being a LIFO model to a FIFO 
model. This means the LIFO model will no longer be an option. Based on 
feedback we have heard, this type of model where more recent sources 
are given a stronger preference is in line with how ad-techs think 
about measuring conversions. Additionally, the API will support a 
priority field, so that within the FIFO model ad-techs can still 
specify if certain destinations require a higher priority than others.



This change is not backwards compatible since the model for this rate 
limit will be changing.



This change will help to reduce the registration and conversion loss 
ad-techs may see with the current limit.




Explainer/Spec changes

1.

Deactivate earliest destinations if exceeding distinct destination
limit for unexpired sources



Risks
Interoperability and Compatibility

This feature is not a backwards compatible change because the behavior 
for which sources will be rejected or deleted once the source 
destination limit is hit will now be different. The new behavior is 
intuitively more in line with how ad-techs measure conversions 
currently, however there may be some scenarios where keeping older 
source registrations is more important to an ad-tech, which may still 
be achieved through the use of the priority field that is part of this 
feature.



This change will not cause any site breakage or change for end users 
of Chrome. Additionally, once this feature is released it will only be 
applicable to users running on Chrome M128 and future chrome versions. 
This change will also not delete any existing source registrations in 
storage unless the limit is hit and there are source registrations 
that exceed the limit.



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



WebKit: No signal (Original request: 
https://github.com/WebKit/standards-positions/issues/180 
)



Web developers: 
https://github.com/WICG/attribution-reporting-api/issues/1228 

Re: [blink-dev] Intent to Ship: CSS interpolate-size property and calc-size() function

[Mike Taylor]

Got it - thanks.

LGTM2

On 7/16/24 4:11 PM, David Baron wrote:
I suppose mostly the test naming as "tentative" just needs to be 
updated, but I was planning to do it along with landing the one line 
changes to the property value definitions (which I mentioned in the 
"Anticipated spec changes" section of the intent), since technically 
it's testing stuff that isn't formally required without that.


-David

On Tue, Jul 16, 2024 at 2:40 PM Mike Taylor  
wrote:


On 7/16/24 2:27 PM, Chris Harrelson wrote:


LGTM1!


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/css/css-values/calc-size


I see that most of these tests are marked as tentative - is that
intentional, or just needs to be updated?



--
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/eeb1fe63-5156-476c-9685-15ce57c277dd%40chromium.org.

Re: [blink-dev] Intent to Extend Experiment: Explicit Compile Hints with Magic Comments

[Mike Taylor]

Just to clarify: this ran as an OT from 115 to 117, and has been 
disabled since then?


And you're requesting to run another OT (vs extending a currently active 
one) from 129 to 131.


Do I have that correct?

On 7/22/24 5:56 AM, 'Marja Hölttä' via blink-dev wrote:



Contact emails

ma...@google.com, lesz...@google.com


Explainer

https://github.com/explainers-by-googlers/explicit-javascript-compile-hints-file-based/blob/main/README.md


Specification

None


Summary

Allow attaching information about which functions should be eager 
parsed & compiled in JavaScript files. The information will be encoded 
as magic comments. We'll first target launching the file-based 
explicit compile hints, and as a follow up, investigate selecting 
individual functions for eager compilation.




Blink component

Blink>JavaScript 




TAG review



TAG review status

Pending


Chromium Trial Name

JavaScriptCompileHintsMagic


Link to origin trial feedback summary

https://google.qualtrics.com/jfe/form/SV_9SLyOGnTj2cwo0C


Origin Trial documentation link

https://docs.google.com/document/d/19xTAM4A75tz0xUq_velMzGA4JHEgXpyflUxXTcuNiyE/edit?usp=sharing


Risks



Interoperability and Compatibility

No interoperability / compatibility risks. Other browsers are likely 
to ignore the hints if they perceive they cannot benefit from them. 
Ignoring the hint is allowed behavior. We plan to make the hints 
generic though, so that other browsers can later start to support them 
too, e.g., if they implement background parsing / compilation.




/Gecko/: N/A (https://github.com/mozilla/standards-positions/issues/780)

/WebKit/: N/A (https://github.com/WebKit/standards-positions/issues/172)

/Web developers/: Positive Positive signals from partners who want to 
use compile hints to eager-compile core JS files.


/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

We'd like to measure the performance of the improved feature 
implementation in userland partner metrics.



Reason this experiment is being extended

The origin trial configuration for this feature was broken in 
M115-M116, and the users weren't able to run the experiments.




Reason this experiment is being extended

We did an origin trial in versions 115-117. We modified the feature 
based on the results (performance measurements by Google Workspace) 
and we'd now like to do another origin trial with the modified 
feature, in versions 129-131.




Ongoing technical constraints



Debuggability



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

Yes


Is this feature fully tested by web-platform-tests

?

No

The feature doesn't trigger any functional changes and cannot be 
tested by WPT.




Flag name on chrome://flags



Finch feature name

None


Non-finch justification

None


Requires code in //chrome?

False


Tracking bug

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


Estimated milestones

Origin trial desktop first  115
Origin trial desktop last   117
Origin trial extension 1 end milestone  120
Origin trial extension 2 end milestone  131



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5100466238652416?gate=5198754872819712


Links to previous Intent discussions

Intent to Experiment: 
https://groups.google.com/a/chromium.org/g/blink-dev/c/BmN1Wus8V1s/m/3L2uU-wGAgAJ
Intent to Extend Experiment 1: 
https://groups.google.com/a/chromium.org/g/blink-dev/c/BmN1Wus8V1s/m/rhtpXTyPCgAJ




This intent message was generated by Chrome Platform Status 
.


--

Google Germany GmbH

Erika-Mann-Straße 33

80636 München

*
*

Geschäftsführer: Paul Manicle, Liana Sebastian.

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

*
*

Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise 
erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes 
weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich 
bitte wissen, dass die E-Mail an die falsche Person gesendet wurde.


This e-mail is confidential. If you received this communication by 
mistake, please don't forward it to anyone else, please erase all 
copies and attachments, and please let me know that it has gone to the 
wrong person.


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

Re: [blink-dev] Intent to Extend Experiment: Cookie Deprecation Label Throughout 3PC Phaseout

[Mike Taylor]

LGTM to extend from 127 to 129 inclusive.

On 7/15/24 11:56 AM, John Delaney wrote:

*Contact emails*
johni...@chromium.org, wanderv...@chromium.org, lin...@chromium.org

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

*Summary*
With the end of Chrome-facilitated testing period, we will continue to 
expose cookie deprecation labels within Chrome to facilitate 
evaluation of the Privacy Sandbox Relevance and Measurement APIs by 
ad-techs until sometime during the third-party cookie phase-out 
process in 2025. Third-party cookie phase-out is subject to addressing 
any remaining concerns of the UK Competition and Markets Authority (CMA).


We will be extending the current set of labels, documented on the 
developer blog 
(https://developers.google.com/privacy-sandbox/relevance/setup/web/chrome-facilitated-testing). 
We are still evaluating possible changes to the labeling configuration 
in this period between facilitated testing and third-party cookie 
phase-out. Further guidance will be provided in the coming milestones 
on any changes to labels.


We expect to support labeled browser groups until we begin phasing out 
third-party cookies in early 2025, and for some time during the 
phase-out process.


*Link to “Intent to Experiment” blink-dev discussion*
https://groups.google.com/a/chromium.org/g/blink-dev/c/3escBQGtIpM/m/ntcytva5BgAJ
https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/v3PiIzm1M-Y

*Goals for experimentation*
While the Chrome-facilitated testing period concluded at the end of 
H1, we expect ad-techs to continue to use the labels to evaluate and 
optimize deployments of the Privacy Sandbox Ads APIs.


*Experimental timeline*
This feature was previously approved to run from Chrome 119 -> 126. We 
expect to extend this experiment every 3 milestones (per standard 
process) until some point during third-party cookie phaseout.


We would like to start with extending this for Chrome 127 through 129.

*Any risks when the experiment finishes?*
Minimal, the cookie deprecation labels are only available for a subset 
of users and must be requested.


We expect to support labeled browser groups for some time during the 
third-party cookie phase-out process. In this case, the fraction of 
labeled browsers would increase, which was not the case in the 
original Intent to Experiment. We will seek approval for this in 
subsequent Intent to Extend Experiments, and plan to maintain a 
holdback group at those times.


Any changes in usage/availability will be communicated beforehand to 
blink-dev.


*Reason this experiment is being extended*
We have received feedback that these labels are useful for ad tech 
companies to evaluate the APIs with limited browser groups beyond the 
Chrome-facilitated testing period.


*Ongoing technical constraints*
None

*Will this feature be supported on all five Blink platforms supported 
by Origin Trials (Windows, Mac, Linux, Chrome OS, and Android)?*

No, not supported on webview.

*Link to entry on the feature dashboard*
https://chromestatus.com/feature/5189079788683264
--
You received this message because you are subscribed to the Google 
Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1a03b87a-5a5d-40d0-ad44-fb66ae159f49n%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/df0cf2b2-0e0b-4a18-9996-6a93a4833d5a%40chromium.org.

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

[Mike Taylor]

LGTM1

On 7/17/24 5:24 PM, Alex Turner wrote:
On Mon, Jul 15, 2024 at 11:03 AM Mike Taylor  
wrote:


On 7/12/24 10:44 AM, Alex Turner wrote:


On Wed, Jul 10, 2024 at 11:25 AM Mike Taylor
 wrote:

On 7/8/24 4:05 PM, Alex Turner wrote:



Interoperability and Compatibility

The Aggregation Service (used to process the aggregatable
reports) typically allows its releases to be used for up to
six months. To reduce the compatibility impact of this
change, we are waiting until all current Aggregation Service
releases support the new version before rolling to Stable.


Can you say more about this? How many parties are running
these services, and do we have any way of knowing what the
uptake of new versions is, or said differently - can we tell
if they're still on older versions?

Also, what happens if you send the filter ID to an older version?

The Aggregation Service in general has a six-month support
schedule

<https://github.com/privacysandbox/aggregation-service/wiki/Aggregation-Service-release-and-end%E2%80%90of%E2%80%90support-plan#release-and-end-of-support-schedules>,
i.e. attempts to use a release more than six months after it was
released will fail. Currently, there are three Aggregation
Service releases that are available for use (2.3, 2.4, 2.5). All
previous releases (2.2 and before) have already reached
end-of-support and can no longer be used.


I see - thanks. Just a few more questions to help me understand:

There's mention of an image hash allowlist - presumably this is
how you enforce versioning on the server side. Is that correct?

Yep, exactly.


Release 2.3 does not support the new report format, but we have
announced it will reach end-of-support on August 2nd, i.e. before
M128 reaches Stable. (Note that we have already enabled the
feature on Canary for testing.) Attempting to process reports
with the new “1.0” report version on this release will result in
the aggregation job failing with a descriptive error message. In
this case, however, no budget will be consumed and the
aggregation can be re-attempted (either on a newer release or
after excluding the “1.0” reports).

Why doesn't this count as a breaking change, per your wiki page?
Or the idea is you don't need to rev the major version number
because it will be unsupported before this feature is usable in
Chrome stable?


The Aggregation Service versioning scheme applies to server-side 
changes only. That is, a breaking change is one that would require an 
active migration for a partner when they update their Aggregation 
Service release. As the processing changes on the server are backwards 
compatible (more detail below), we haven't updated the major version.


When attempting to process the new “1.0” reports, the old Aggregation 
Service releases (2.3 and before) error out and the new releases 
(2.4+) succeed. So, we consider that new support to be backwards 
compatible /server-side/.
OK - understood. These server errors won't affect clients sending the 
new report version (and I realize I missed the distinction between 
report and aggregation service version).


And when attempting to additionally specify custom filtering_ids /on 
the server/, Aggregation Service release 2.4 doesn’t let you (always 
uses the default, discussed below in more detail), while release 2.5 
does let you. So, that change should also count as backwards compatible.


Separately, there’s a question of whether the /browser-side/ API 
change (to change the report version/format) is backwards compatible. 
While Aggregation Service release 2.3 is available, it is a breaking 
change. But, it will be backwards compatible once all current 
Aggregation Service releases support the report version (before M128 
Stable).



Release 2.4 supports the new report format, but it does not allow
for filtering_ids to be specified for the aggregation; the
default value ([0]) is always used. On this release, existing
flows that do not use the new feature will be unaffected by the
report version change.

This also feels like a breakage change to me - if I'm using a
supported service version, but I can't use the updated report
version because I will get unexpected/inconsistent behavior with 2.5.


Let me clarify the behavior of Releases 2.4 and 2.5 a bit. On the web 
API after this change, you can optionally specify a filtering ID for 
each histogram contribution; if you don’t, the default of 0 is used. 
On the server API, you can optionally specify which filtering IDs to 
keep (i.e. all histogram contributions with other filtering IDs are 
ignored for the aggregation). If you don’t specify any (either because 
2.4 doesn’t let you or if you use the default in 2.5), the default of 
keeping just filtering ID 0 is used.


So, any existing

Re: [blink-dev] Fwd: Intent to Extend Experiment: Protected Audience Bidding & Auction Services

[Mike Taylor]

Apologies - I mean to approve from M127 to M129 inclusive (math is hard).

On 7/19/24 12:03 PM, Mike Taylor wrote:


OK - thanks. It sounds like the majority of the API is specced, with 
some options to go (I hope I'm interpreting that correctly).


LGTM to extend from M127 to M130 inclusive.

If there's a further extension request, I would expect all the spec 
work to be finished and merged, and significantly more WPT coverage. 
If WPT needs support for PA to be more testable, I would strongly 
recommend you start thinking about webdriver/testdriver.js extensions 
to make that possible.


On 7/17/24 5:38 PM, Russ Hamilton wrote:
The draft PR describes the basic API. There are some options we've 
recently added to navigator.getInterestGroupAdAuctionData()` to 
provide more control over what gets put in the encrypted request (see 
the explainer pull request here: 
https://github.com/WICG/turtledove/pull/1183) which are not yet 
included in the draft spec.


On Monday, July 1, 2024 at 10:37:56 AM UTC-4 mike...@chromium.org wrote:

I see - thanks for the info Paul. It seems like an unintentional
mixup.

When I approved the previous extension I wrote: "I would like to
see draft specifications and progress on making this testable via
WPTs"

Russ thanks for linking to
https://pr-preview.s3.amazonaws.com/brusshamilton/turtledove/pull/1200.html
- based on this draft PR
<https://github.com/WICG/turtledove/pull/1200/files>. You wrote
that it describes _some_ of the changes, can you speak to what is
missing (that you will presumably spec ahead of an I2S)?

And thanks for beginning to land WPTs
<https://chromium-review.googlesource.com/c/chromium/src/+/5622101>.

On 6/28/24 1:59 PM, Paul Jensen wrote:

Mike,

It looks like we did continue the OT during M122-124 before
sending the first I2EE, despite initially only asking for
approval for M119-121.  I wonder if someone went off of the
current OT policy of "An initial origin trial or experiment for
a feature may only run for 6 milestones"

<https://www.chromium.org/blink/launching-features/#widen-review:~:text=An%20initial%20origin%20trial%20or%20experiment%20for%20a%20feature%20may%20only%20run%20for%206%20milestones>
without knowing my initial ask was for just 3 milestones.  I
apologize for that and am going to seek updating internal
processes to add a check to prevent this oversight from
happening again, even if the initial I2EE is "fairly mechanical"
as you said originally.

On Wednesday, June 26, 2024 at 1:53:56 PM UTC-4 Mike Taylor wrote:

Hi Russ,

I'm trying to refresh my memory on the history of this
experiment.

Experiment first approved on 10/19/23 for M119 to M121,

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


Request on 4/4/24 to renew from M124 to M127,

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


Approved 4/12/24 (“for another 3 milestones”),

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


Requesting M127 to M130 on 6/20/24,

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


Question: what happened between M122 and M124? Was the
experiment not running?


On 6/20/24 2:52 PM, 'Russ Hamilton' via blink-dev wrote:

(Now *To* blink-dev instead of just CC)


Contact emails

paulj...@chromium.org, beham...@google.com


Explainer

Chrome:

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

<https://github.com/WICG/turtledove/blob/main/FLEDGE_browser_bidding_and_auction_API.md>

Services:

https://github.com/privacysandbox/fledge-docs/blob/main/bidding_auction_services_api.md

<https://github.com/privacysandbox/fledge-docs/blob/main/bidding_auction_services_api.md>

Note that this explainer has a helpful onboarding section

<https://github.com/privacysandbox/fledge-docs/blob/main/bidding_auction_services_api.md#onboarding-and-alpha-testing-guide>for
setting up the services.


Specification

A work-in-progress pull request

<https://pr-preview.s3.amazonaws.com/brusshamilton/turtledove/pull/1200.html>on
the Protected Audience spec
<https://wicg.github.io/turtledove/>describes some of the
changes to the W3C spec. We are reaching out to the IETF
ART Area Directors for assistance beginning the
standardization process for some of the server-side aspects
of this API.


Summary

We propose extending the Bidding and Auction Services
origin trial currently oper

Re: [blink-dev] Fwd: Intent to Extend Experiment: Protected Audience Bidding & Auction Services

[Mike Taylor]

OK - thanks. It sounds like the majority of the API is specced, with 
some options to go (I hope I'm interpreting that correctly).


LGTM to extend from M127 to M130 inclusive.

If there's a further extension request, I would expect all the spec work 
to be finished and merged, and significantly more WPT coverage. If WPT 
needs support for PA to be more testable, I would strongly recommend you 
start thinking about webdriver/testdriver.js extensions to make that 
possible.


On 7/17/24 5:38 PM, Russ Hamilton wrote:
The draft PR describes the basic API. There are some options we've 
recently added to navigator.getInterestGroupAdAuctionData()` to 
provide more control over what gets put in the encrypted request (see 
the explainer pull request here: 
https://github.com/WICG/turtledove/pull/1183) which are not yet 
included in the draft spec.


On Monday, July 1, 2024 at 10:37:56 AM UTC-4 mike...@chromium.org wrote:

I see - thanks for the info Paul. It seems like an unintentional
mixup.

When I approved the previous extension I wrote: "I would like to
see draft specifications and progress on making this testable via
WPTs"

Russ thanks for linking to
https://pr-preview.s3.amazonaws.com/brusshamilton/turtledove/pull/1200.html
- based on this draft PR
<https://github.com/WICG/turtledove/pull/1200/files>. You wrote
that it describes _some_ of the changes, can you speak to what is
missing (that you will presumably spec ahead of an I2S)?

And thanks for beginning to land WPTs
<https://chromium-review.googlesource.com/c/chromium/src/+/5622101>.

On 6/28/24 1:59 PM, Paul Jensen wrote:

Mike,

It looks like we did continue the OT during M122-124 before
sending the first I2EE, despite initially only asking for
approval for M119-121.  I wonder if someone went off of the
current OT policy of "An initial origin trial or experiment for a
feature may only run for 6 milestones"

<https://www.chromium.org/blink/launching-features/#widen-review:~:text=An%20initial%20origin%20trial%20or%20experiment%20for%20a%20feature%20may%20only%20run%20for%206%20milestones>
without knowing my initial ask was for just 3 milestones.  I
apologize for that and am going to seek updating internal
processes to add a check to prevent this oversight from happening
again, even if the initial I2EE is "fairly mechanical" as you
said originally.

On Wednesday, June 26, 2024 at 1:53:56 PM UTC-4 Mike Taylor wrote:

Hi Russ,

I'm trying to refresh my memory on the history of this
experiment.

Experiment first approved on 10/19/23 for M119 to M121,

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


Request on 4/4/24 to renew from M124 to M127,

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


Approved 4/12/24 (“for another 3 milestones”),

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


Requesting M127 to M130 on 6/20/24,

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


Question: what happened between M122 and M124? Was the
experiment not running?


On 6/20/24 2:52 PM, 'Russ Hamilton' via blink-dev wrote:

(Now *To* blink-dev instead of just CC)


Contact emails

paulj...@chromium.org, beham...@google.com


Explainer

Chrome:

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

<https://github.com/WICG/turtledove/blob/main/FLEDGE_browser_bidding_and_auction_API.md>

Services:

https://github.com/privacysandbox/fledge-docs/blob/main/bidding_auction_services_api.md

<https://github.com/privacysandbox/fledge-docs/blob/main/bidding_auction_services_api.md>

Note that this explainer has a helpful onboarding section

<https://github.com/privacysandbox/fledge-docs/blob/main/bidding_auction_services_api.md#onboarding-and-alpha-testing-guide>for
setting up the services.


Specification

A work-in-progress pull request

<https://pr-preview.s3.amazonaws.com/brusshamilton/turtledove/pull/1200.html>on
the Protected Audience spec
<https://wicg.github.io/turtledove/>describes some of the
changes to the W3C spec. We are reaching out to the IETF ART
Area Directors for assistance beginning the standardization
process for some of the server-side aspects of this API.


Summary

We propose extending the Bidding and Auction Services origin
trial currently operating on 1% stable.

Recent changes:

 *

Prompted by developer concerns about scalability, we
   

Re: [blink-dev] Intent to Deprecate and Relaunch: CHIPS on WebView

[Mike Taylor]

LGTM3

On 7/18/24 11:24 AM, Chris Harrelson wrote:

LGTM2

On Thu, Jul 18, 2024 at 6:49 AM Vladimir Levin  
wrote:




On Wed, Jul 17, 2024 at 3:13 PM 'Dylan Cutler' via blink-dev
 wrote:

Hey Vlad,

I agree that deleting the affected cookies seems to be the
least risky behavior here. Is this plan to roll out via
Finch and monitor for bad breakages?

Unfortunately it is not possible to roll out network feature
changes via Finch to WebView, since WebView may sometimes use
the cookie store before the feature list has been fully
initialized. We have implemented this change as a command line
switch for the process running the network service.


That makes sense. It does increase the risk of this removal, but I
can't think of any other approach. As someone pointed out: "having
no cookies is better than having corrupted cookies", and
apps/sites should be able to deal gracefully with cookies being
deleted.

LGTM1


Also, could you start the various reviews on the
chromestatus entry?

Done!

Dylan

On Wed, Jul 17, 2024 at 2:03 PM Vladimir Levin
 wrote:

Thank you for all of the context.

I agree that deleting the affected cookies seems to be the
least risky behavior here. Is this plan to roll out via
Finch and monitor for bad breakages?

Also, could you start the various reviews on the
chromestatus entry?
chipsna.png

Thanks,
Vlad

On Thu, Jul 11, 2024 at 1:17 PM Torne (Richard Coles)
 wrote:



On Tue, 9 Jul 2024 at 10:20, Vladimir Levin
 wrote:



On Fri, Jun 28, 2024, 16:28 'Dylan Cutler' via
blink-dev  wrote:

Hey Vlad,

Thanks for your response. I have completed the
analysis and have some results to report. I
also have created the Chromestatus

entry as requested.

Here are some stats that give a picture of
CHIPS usage on WebView

  * Global percentage of requests from WebView
clients that contain partitioned cookies:  33%
  * Global percentage of requests from WebView
that contain a single partitioned cookie: 29%


  * Average percentage of requests from a
single WebView app that contain
partitioned cookies: 10%
  * Average percentage of requests from a
single WebView app that contain a single
partitioned cookie: 7%


  * Global percentage of CHIPS we estimate to
be the receive-cookie-deprecation


opt-in cookie: 54%
  * Average percentage of CHIPS that each app
has stored that we estimate to be the
receive-cookie-deprecation opt-in cookie: 55%


  * The percentage of apps using CHIPS: 73%
  * The percentage of apps using the
receive-cookie-deprecation opt in cookie: 66%

The majority of usage of CHIPS is for the 3PCD
facilitated testing opt-in cookie, which will
not be impacted by this change since this
cookie merely serves to opt into browser
behavior that is not available on WebView
regardless.

That being said, we do see usage of CHIPS is
significant on WebView, so we have to weigh
our options. Is it more disruptive to delete
the cookies, silently change their behavior to
unpartitioned, or to do nothing until
shouldInterceptRequest supports the Cookie
header. I am also curious to hear your take.


Thank you for the analysis. Can you help me
understand what percentage of webview apps do you
expect would experience a breakage if delete the
cookies? My understanding is that it's around 33%
assuming that global requests are distributed
evenly across apps? Although 

Re: [blink-dev] Intent to Ship: WebGPU extended range (HDR) support

[Mike Taylor]

LGTM3

On 7/18/24 9:44 AM, Vladimir Levin wrote:

LGTM2

On Wed, Jul 17, 2024 at 10:09 PM Domenic Denicola 
 wrote:




On Wednesday, July 17, 2024 at 10:41:26 AM UTC+9 Domenic Denicola
wrote:

This looks like a nice straightforward feature. Just one
potential spec issue...

On Tue, Jul 16, 2024 at 11:19 PM 'Christopher Cameron' via
blink-dev  wrote:

Hello blink-dev! This is the first feature from HDR canvas
work that is ready to ship. It has been split off and
reduced in scope from this wider feature
.
Contact emailsccame...@chromium.org

ExplainerNone

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



I found the spec for the toneMapping member a bit confusing. I
filed https://github.com/gpuweb/gpuweb/issues/4756
 to ask
questions about potentially getting it clarified.


Upon further discussion in the issue, it became clear that I was
confused because of my lack of familiarity with graphics / WebGPU
APIs, and not because of anything inherently contradictory in the
spec. (There's also a minor wordsmithing issue being discussed,
but that's not blocking.)

So, LGTM1.



Design docs

https://github.com/ccameron-chromium/webgpu-hdr/blob/main/EXPLAINER.md



Summary

Adds tone mapping parameters to the WebGPU canvas
configuration, and adds options of "standard" (the current
behavior of restricting content to the SDR range of the
display) as the default, and "extended" (not imposing this
restriction) as a new behavior. This allows WebGPU content
to use the full range of a display.



Blink componentBlink>WebGPU



Search tagsWebGPU
, HDR
, Canvas


TAG reviewNone

TAG review statusNot applicable

Risks


Interoperability and Compatibility

None. This feature has been developed with and reviewed by
representatives of Mozilla and WebKit, and maps to mature
APIs present on all platforms (except ChromeOS, where
support is coming soon).



/Gecko/: Positive
(https://github.com/gpuweb/gpuweb/pull/4500
) Approval
does not automatically imply positive signal for Mozilla,
but approver communicated that it does here (can file for
signal if requested).

/WebKit/: Positive
(https://github.com/gpuweb/gpuweb/pull/4500
) Approval
implies positive signal for Safari, in WebGPU WG.

/Web developers/: Positive

(https://github.com/gpuweb/gpuweb/issues/4239#issuecomment-1935112593

)
Several requests have been made for this feature.

/Other signals/: PR
(https://github.com/gpuweb/gpuweb/pull/4500
) reviewed by
kdashg at Mozilla and mwyrzykowski at WebKit

Ergonomics

This maps directly to the platform APIs that are used for
HDR video and image rendering, and should require almost
no additional work to support. On some platforms, this
maps directly to the exact underlying API, while on other
platforms some conversion is required.



Activation

This can be used immediately by developers.



Security

This introduces no new security or privacy issues.



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. WebView does not current support this (because it
does not support HDR images), but the support for both
features will come simultaneously.



Debuggability

None



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

ChromeOS 

Re: [blink-dev] Intent to Ship: Remove PointerEvent.getCoalescedEvents() from insecure contexts

[Mike Taylor]

On 7/17/24 10:18 AM, Mustaq Ahmed wrote:

> Can you ask for WebKit's position? Or maye there's at least a 
pointer to working group discussions they participated in?


- Safari doesn't yet support PointerEvent.getCoalescedEvents(), so we 
can't ask for their position on secure/non-secure context differences:

https://developer.mozilla.org/en-US/docs/Web/API/PointerEvent/getCoalescedEvents#browser_compatibility
That's OK - we ask for positions from them all the time for things they 
don't support.
- Here is a PEWG discussion started by @gsnedders from WebKit (I 
couldn't find any other related discussion Safari participated in):

https://github.com/w3c/pointerevents/issues/215
To my knowledge, that was posted a few years before Sam started working 
at Apple.
> Our process requires a Finch feature in general. And this sort of 
potentially-risky removal seems like the kind of thing that benefits 
from a Finch feature, so that it can be remotely reverted if it causes 
terrible regressions.


Unfortunately we can't put this change behind a flag because Blink 
does not allow making [SecureContext] conditional.  I think it was 
supported in the past because "Blink IDL Extended 
Attributes" documentation still mentions [SecureContext=flag] as 
non-standard, but it doesn't even compile!

https://chromium.googlesource.com/chromium/src/+/HEAD/third_party/blink/renderer/bindings/IDLExtendedAttributes.md#securecontext


On Tue, Jul 16, 2024 at 9:30 PM Domenic Denicola 
 wrote:




On Wed, Jul 17, 2024 at 6:52 AM Mustaq Ahmed 
wrote:


Contact emails

mus...@chromium.org


Explainer

None


Specification

https://w3c.github.io/pointerevents/#pointerevent-interface


Summary

The Pointer Events Working Group made
PointerEvent.getCoalescedEvents() restricted to secure
contexts 4+ years ago, which removed the API from insecure
contexts. Chrome originally shipped the old behavior and
didn't follow the spec change immediately because of compat
concerns. We are now removing it from insecure contexts
because Chrome usage in insecure contexts turned out to be
very low.



Blink component

Blink>Input




TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

Interop: This will improves Interop, making Chrome fully match
Firefox (and the spec). Compat: There is a bit of risk because
the usage is non-zero (~0.0004% as of 2024-07-16). This usage
stat is expected to include non-breaking JS enumerations.
https://chromestatus.com/metrics/feature/timeline/popularity/4598



/Gecko/: Shipped/Shipping

/WebKit/: No signal


Can you ask for WebKit's position? Or maye there's at least a
pointer to working group discussions they participated in?


/Web developers/: No signals

/Other signals/:


WebView application risks

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

None



Debuggability

None



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

Yes


Is this feature fully tested by web-platform-tests

?

Yes


https://wpt.fyi/results/pointerevents?label=master=experimental=pointerevents%2Fpointerevent_constructor





Flag name on chrome://flags

None


Finch feature name

None


Non-finch justification

None


Our process requires a Finch feature in general. And this sort of
potentially-risky removal seems like the kind of thing that
benefits from a Finch feature, so that it can be remotely reverted
if it causes terrible regressions.



Requires code in //chrome?

False


Tracking bug

https://issues.chromium.org/40928769


Estimated milestones

Shipping on desktop 129

Shipping on Android 129

Shipping on WebView 129



Anticipated spec changes

Open questions about a feature may be a source of future web
compat or interop issues. Please list open issues (e.g. links
to known github issues in the project for 

Re: [blink-dev] Intent to Ship: CSS interpolate-size property and calc-size() function

[Mike Taylor]

On 7/16/24 2:27 PM, Chris Harrelson wrote:


LGTM1!


Is this feature fully tested by web-platform-tests

?

Yes

https://wpt.fyi/results/css/css-values/calc-size

I see that most of these tests are marked as tentative - is that 
intentional, or just needs to be updated?


--
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/14c7df54-3c44-4adc-9d13-3ec3c8957297%40chromium.org.

Re: [blink-dev] Intent to Ship: Isolated Web Apps

[Mike Taylor]

Thanks - before I jump too deeply into the review, would you mind 
requesting the various review gate bits in your chromestatus entry?


On 7/15/24 2:44 PM, Robbie McElrath wrote:

Thanks for taking a look Mike!

Are there any things that an IWA needs that DevTools can't
currently do?


No, the IWA security rules are enforced with existing web primitives 
(CSP/TT, permissions policy, COI) that already have DevTools support. 
There is some non-DevTools tooling needed to build and sign the 
bundle, but I don't think there's a use case for adding bundle-related 
functionality into DevTools.
Makes sense. Are there plans to build said tooling and make it available 
to ease adoption?


Can you say more about this please? Or is there an issue or
explainer to read for more context? Is there a plan to do the spec
work?


Integrity block v2 was recently proposed to address key rotation 
related issues with v1. The internal design doc is 
here: go/iwa-key-rotation. Yes, we will be speccing this.

Great - any idea of when you might have some version of a spec draft ready?




Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5146307550248960



Links to previous Intent discussions

Intent to prototype:

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEmk%3DMayyUjocrvyQKgu-bZy_4z5VJ0ijHCAijBTZY2xLwJpJQ%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/CANtkjcS1A2rO%2BvHnnPXqc6sxhjenearhCGx9vxt%2BcKqM5otDfA%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/956141e3-e92b-49ef-afae-0ba64fa6c073%40chromium.org.

Re: [blink-dev] Re: Intent to Ship: AudioContext.onerror

[Mike Taylor]

LGTM2

On 7/15/24 10:55 PM, Domenic Denicola wrote:

LGTM1, thanks for the prompt action!

On Mon, Jul 15, 2024 at 11:22 PM Hongchan Choi  
wrote:


Hi Domenic,

Thanks for your input! I've addressed the issue you opened with 2 PRs:
- https://github.com/WebAudio/web-audio-api/pull/2593
- https://github.com/WebAudio/web-audio-api/pull/2592

Regarding the test updates, what would you like to see other than
basic IDL tests? This event can be dispatched only with device
failure, which is impossible to emulate on WPT.


You're right. I forgot that aspect of the problem, and agree that 
makes the event type not realistically testable.



Or do we want a more involved "device mocking" for testing?


It would be ideal to have such device mocking, with WebDriver or 
similar technologies. However, it's not a blocker for shipping. And 
realistically, of all the currently-untestable things that it would be 
nice to add WebDriver support for 
, 
this particular error case doesn't seem too high on the list to me.


(Although maybe it is, e.g. if you're working with a partner who would 
really appreciate being able to write automated tests for their 
website's behavior in such error cases?)


So, my recommendation would be to file a bug on web-platform-tests/wpt 
with "type:untestable" documenting this gap. But unless you hear great 
demand from web developers for writing such automated tests, that bug 
will probably just stay open with low priority. And again, none of 
this blocks shipping.



Best,
Hongchan


On Wed, Jul 10, 2024 at 11:22 PM Domenic Denicola
 wrote:

I've filed a spec issue that I believe should be addressed
before shipping (with appropriate test updates, etc.)
https://github.com/WebAudio/web-audio-api/issues/2590

On Thursday, July 11, 2024 at 2:06:53 PM UTC+9
ajayra...@google.com wrote:


Contact emails

hongc...@chromium.org ,
mjwil...@chromium.org


Explainer

None; the specification (W3C Proposed Recommendation) is
already published.


Specification

https://webaudio.github.io/web-audio-api/#dom-audiocontext-onerror


Summary

Introduces an event listener on AudioContext to notify
developers of audio device or rendering system failures.


Blink component

Blink>WebAudio




Motivation

Currently, developers lack visibility into the success or
failure of their AudioContext, whether during its creation
or while actively rendering audio. In the event of
failure, web applications misleadingly continue to
function as if audio playback is proceeding normally. The
AudioContext.onerror event listener allows web
applications to proactively respond to and manage device
or rendering failures.


Initial public proposal

https://github.com/WebAudio/web-audio-api/issues/2567



TAG review

http://github.com/w3ctag/design-reviews/issues/950



TAG review status

Resolved


Risks


Interoperability and Compatibility


Gecko: Positive 
(http://github.com/mozilla/standards-positions/issues/1016)


WebKit: Defer to Audio WG
(https://github.com/WebKit/standards-positions/issues/340)


Web developers: Positive (2020 Developer Survey

)


WebView application risks

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

None


Debuggability

None


Is this feature fully tested by web-platform-tests

?

No, AudioContext failure scenarios cannot be tested in
WPTs. Chromium-internal tests will fully exercise this
scenario.


Flag name on chrome://flags

None


Finch feature name

AudioContextOnError


Non-finch justification

  

Re: [blink-dev] Intent to Ship: Isolated Web Apps

[Mike Taylor]

On 7/11/24 8:41 PM, Robbie McElrath wrote:



Contact emails

rmcelr...@chromium.org, reil...@chromium.org


Explainer

https://github.com/WICG/isolated-web-apps/blob/main/README.md 




Specification

https://wicg.github.io/isolated-web-apps/isolated-contexts 




Summary

Isolated Web Apps (IWAs) are an extension of existing work on PWA 
installation and Web Packaging that provide stronger protections 
against server compromise and other tampering that is necessary for 
developers of security-sensitive applications.



Rather than being hosted on live web servers and fetched over HTTPS, 
these applications are packaged into Web Bundles and signed by their 
developer. For this initial launch, installation can only be triggered 
by enterprise policy on managed devices.



Blink component

Blink 


TAG review

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




TAG review status

Pending


Risks


Interoperability and Compatibility


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



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



Web developers: Several companies have reached out asking about IWA 
availability (can’t name them publicly), the iwa-...@chromium.org 
list is 
active, and there’s been some interest 
in the WICG repo.



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. Feature not compiled in Android.



Debuggability


Are there any things that an IWA needs that DevTools can't currently do?



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

No, the initial launch is scoped to ChromeOS only.


Is this feature fully tested by web-platform-tests

?

No, IWAs are built on top of PWA infrastructure, which isn’t currently 
supported by WPT.



Flag name on chrome://flags

#enable-isolated-web-apps


Finch feature name

IsolatedWebApps


Requires code in //chrome?

True


Launch bug

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




Measurement

We have histograms measuring the following (see WebApp.Isolated.*):

 *

Installation result

 *

Update result

 *

Orphaned bundle cleanup job result

 *

Bundle verification (signature and file format) result

 *

Bundle resource read result


Availability expectation

Initially only available on ChromeOS, with other platforms following 
at a later date.



Adoption expectation

Expected to be used initially by a small number (<10) number of 
partners, but any enterprise admin could develop and deploy an IWA if 
they choose.



Adoption plan

Working directly with partners for whom IWAs are an appropriate solution.


Non-OSS dependencies

Key rotations are handled by the Component Updater, which receives 
Google-managed configuration data.



Sample links


https://github.com/GoogleChromeLabs/telnet-client 



https://github.com/WICG/controlled-frame/tree/main/test_app 




Estimated milestones

Shipping on desktop



128


Anticipated spec changes

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



We recently added support for Integrity Block v2 to Signed Web 
Bundles, which hasn’t been spec’d yet. We’re supporting both Integrity 
Block formats for a few releases while partners migrate before 
dropping support for v1.


Can you say more about this please? Or is there an issue or explainer to 
read for more context? Is there a plan to do the spec work?



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5146307550248960 




Links to previous 

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

[Mike Taylor]

On 7/12/24 10:44 AM, Alex Turner wrote:

On Wed, Jul 10, 2024 at 11:25 AM Mike Taylor  
wrote:


On 7/8/24 4:05 PM, Alex Turner wrote:



Interoperability and Compatibility

The Aggregation Service (used to process the aggregatable
reports) typically allows its releases to be used for up to six
months. To reduce the compatibility impact of this change, we are
waiting until all current Aggregation Service releases support
the new version before rolling to Stable.


Can you say more about this? How many parties are running these
services, and do we have any way of knowing what the uptake of new
versions is, or said differently - can we tell if they're still on
older versions?

Also, what happens if you send the filter ID to an older version?

The Aggregation Service in general has a six-month support schedule 
<https://github.com/privacysandbox/aggregation-service/wiki/Aggregation-Service-release-and-end%E2%80%90of%E2%80%90support-plan#release-and-end-of-support-schedules>, 
i.e. attempts to use a release more than six months after it was 
released will fail. Currently, there are three Aggregation Service 
releases that are available for use (2.3, 2.4, 2.5). All previous 
releases (2.2 and before) have already reached end-of-support and can 
no longer be used.


I see - thanks. Just a few more questions to help me understand:

There's mention of an image hash allowlist - presumably this is how you 
enforce versioning on the server side. Is that correct?


Release 2.3 does not support the new report format, but we have 
announced it will reach end-of-support on August 2nd, i.e. before M128 
reaches Stable. (Note that we have already enabled the feature on 
Canary for testing.) Attempting to process reports with the new “1.0” 
report version on this release will result in the aggregation job 
failing with a descriptive error message. In this case, however, no 
budget will be consumed and the aggregation can be re-attempted 
(either on a newer release or after excluding the “1.0” reports).
Why doesn't this count as a breaking change, per your wiki page? Or the 
idea is you don't need to rev the major version number because it will 
be unsupported before this feature is usable in Chrome stable?
Release 2.4 supports the new report format, but it does not allow for 
filtering_ids to be specified for the aggregation; the default value 
([0]) is always used. On this release, existing flows that do not use 
the new feature will be unaffected by the report version change.
This also feels like a breakage change to me - if I'm using a supported 
service version, but I can't use the updated report version because I 
will get unexpected/inconsistent behavior with 2.5.


Release 2.5 supports the new report format and allows filtering_ids to 
be specified for the aggregation. Developers who want to use the new 
feature should upgrade to this release.


We don't currently have metrics on usage of each Aggregation Service 
release, but plan to add those. Still, we have notified partners of 
these considerations through the API mailing lists 
<https://groups.google.com/a/chromium.org/g/shared-storage-api-announcements/c/qlL4kpdgvP0>. 
We'll also remind partners of the upcoming end-of-support.


Thanks for the public comms - having some form of telemetry for 
aggregation service versions in the wild does seem useful.


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/40956f3a-474f-4878-81f2-f353f400f049%40chromium.org.

Re: [blink-dev] Intent to Ship: Rename inset-area to position-area

[Mike Taylor]

LGTM3

On 7/11/24 2:18 PM, Chris Harrelson wrote:

LGTM2

On Thu, Jul 11, 2024 at 11:06 AM Vladimir Levin  
wrote:


LGTM1 to add `position-area`, since it is an alias for
`inset-area` that is shipped and is being deprecated.

On Thu, Jul 11, 2024 at 12:22 PM Mason Freed 
wrote:


On Thu, Jul 11, 2024 at 9:17 AM Vladimir Levin
 wrote:

Just to clarify: this intent is to add `position-area`
which is a drop in replacement/alias for `inset-area`. The
latter is being deprecated via another intent. Is this
correct?


That's exactly right, yes. The intent to deprecate the old
name (inset-area) is this one

.

Thanks,
Mason

Thanks,
Vlad

On Wed, Jul 10, 2024 at 6:23 PM Mason Freed
 wrote:


{NOTE: this is a replacement of this
chromestatus
,
which has the wrong feature type and cannot be
changed.}



Contact emails

mas...@chromium.org


Explainer

None


Specification


https://github.com/w3c/csswg-drafts/issues/10209#issuecomment-2221005001


Summary

The CSSWG resolved to rename this property from
`inset-area` to `position-area`. See the CSSWG
discussion here:

https://github.com/w3c/csswg-drafts/issues/10209#issuecomment-2221005001
Chrome disagrees with this change, but would like to
ship an interoperable implementation. We will ship the
new property name, `position-area`, as a synonym for
`inset-area` first. Then after a suitable amount of
time, we will remove `inset-area`. The latter removal
will be done under a separate Intent.



Blink component

Blink>CSS




TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

There is a compat risk with this rename, since the old
name of `inset-area` is in use, with an 0.02% use
counter:
https://chromestatus.com/metrics/css/timeline/popularity/781
We will need to ship the new name, `position-area`,
first, and issue deprecation warnings for the old
name, `inset-area`, to give developers time to change.
This intent to ship is about shipping `position-area`
as a synonym for `inset-area`. We'll issue a separate
I2D for removing the `inset-area` property.



/Gecko/: No signal

/WebKit/: No signal

/Web developers/: No signals

/Other signals/:


WebView application risks

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

None



Debuggability

None



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

Yes


Is this feature fully tested by
web-platform-tests

?

Yes

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



Flag name on chrome://flags

None


Finch feature name

None


Non-finch justification

None


Requires code in //chrome?

False


Estimated milestones

Shipping on desktop 129
DevTrial on desktop 129

Shipping on Android 129
DevTrial on Android 129

Shipping on WebView 129



Anticipated spec changes

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

Re: [blink-dev] Intent to Deprecate and Remove: Deprecation of CSS Anchor Positioning property `inset-area`

[Mike Taylor]

LGTM3

On 7/11/24 12:13 PM, Chris Harrelson wrote:

LGTM2

On Thu, Jul 11, 2024 at 9:12 AM Vladimir Levin  
wrote:




On Thu, Jul 11, 2024 at 11:52 AM Mason Freed 
wrote:



On Thu, Jul 11, 2024 at 8:31 AM Vladimir Levin
 wrote:

From the other emails, there is a 0.02% usage of this
property right now, so it may be worthwhile to document
the planned timeline for the rename process.

This lists M131 as the shipping milestone, but I assume we
want to do this before then, right?


So the idea is to add `position-area` in M129, and deprecate
(but not yet remove) `inset-area` also in M129. And then
ideally remove `inset-area` in M131. Two milestones seems like
enough time for developers to migrate, but not enough time for
usage of `inset-area` to really pick up.


That sounds like a good plan. I also assume that you would reach
out to any properties that you know are using insert-area to let
them know of this change, especially if you don't see usage
dropping by M131.

LGTM1 for deprecating `insert-area` in M129 and removing in M131

Thanks,
Vlad


Thanks,
Mason


Thanks,
Vlad



/Gecko/: No signal

/WebKit/: No signal

/Web developers/: No signals

/Other signals/:


WebView application risks

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

None



Debuggability

None



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://crbug.com/352360007


Estimated milestones

Shipping on desktop 131
DevTrial on desktop 129

Shipping on Android 131
DevTrial on Android 129

Shipping on WebView 131



Link to entry on the Chrome Platform Status


https://chromestatus.com/feature/5944933945704448?gate=6046273227718656

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/CAHB%2BDAhbysWX2rT2QGMiv%3D2XvxYD9pzKTy894OFP81RNoPHKMg%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/CADsXd2NMK74T5pOH4V5H-R%2BmfRYs5NnNemYah%3Dbp%3DrcGNrKkFQ%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_AQmqASTso%3D4Osv%2B5ee41%2BxTCq_Scmc_BKdOy7EQLg3A%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] Ready for Developer Testing: Web Authentication API: JSON serialization methods

[Mike Taylor]

Hi Martin,

Is this intended to be an Intent to Ship, or dev trial?

thanks,
Mike

On 6/26/24 2:28 PM, 'Martin Kreichgauer' via blink-dev wrote:



Contact emails

marti...@google.com


Explainer

https://github.com/w3c/webauthn/wiki/Explainer:-JSON-Serialization-Methods


Specification

https://w3c.github.io/webauthn/#publickeycredential


Summary

The WebAuthn PublicKeyCredential.toJSON(), 
parseCreationOptionsFromJSON() and parseRequestOptionsFromJSON() 
methods let developers serialize a WebAuthn response into a JSON 
object or deserialize a WebAuthn request object from its JSON 
representation.




Blink component

Blink>WebAuthentication 




TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

None



/Gecko/: Shipped/Shipping 
(https://developer.mozilla.org/en-US/docs/Web/API/PublicKeyCredential/toJSON#browser_compatibility)


/WebKit/: No signal

/Web developers/: Positive (https://github.com/github/webauthn-json) 
webauthn-json is a widely used polyfill for this API maintained by Github.


/Other signals/:


WebView application risks

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


None



Goals for experimentation



Ongoing technical constraints

None



Debuggability

None



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

Yes

This feature is implemented in Blink renderer code and shipping on all 
platforms.




Is this feature fully tested by web-platform-tests

?

Yes

https://wpt.fyi/results/webauthn/public-key-credential-creation-options-from-json.https.window.html 
https://wpt.fyi/results/webauthn/public-key-credential-request-options-from-json.https.window.html 
https://wpt.fyi/results/webauthn/public-key-credential-to-json.https.window.html




DevTrial instructions

https://docs.google.com/document/d/e/2PACX-1vSl4jywfU4xD3fkWrC-T5hHI79xs90oOq9tVSx4M63WkcI-wuk-nnFlPlDIAttrpTEd5BbXABJnDuxT/pub


Flag name on chrome://flags

enable-experimental-web-platform-features


Finch feature name

WebAuthenticationJSONSerialization


Requires code in //chrome?

False


Tracking bug

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


Estimated milestones

DevTrial on desktop 128

DevTrial on Android 128



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5141695044255744


Links to previous Intent discussions

Intent to prototype: 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAB%3DfcEbBz4a%2BEE-KbbRDkEexDON8hCfCC-saD600J7fo9J3jZg%40mail.gmail.com


This intent message was generated by Chrome Platform Status 
.

--
You received this message because you are subscribed to the Google 
Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAB%3DfcEZFNdKypxjgMis0WGNVHs7hA6hw3UAXynKDs7ig0bPcgg%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/74eaa160-e5cb-46ab-b290-42b8bc8c0b1d%40chromium.org.

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

[Mike Taylor]

On 7/8/24 4:05 PM, Alex Turner wrote:



Contact emails

ale...@chromium.org


Explainer

https://github.com/patcg-individual-drafts/private-aggregation-api/blob/main/flexible_filtering.md


Specification

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


Summary

Modifies the Private Aggregation API to add a 'filtering ID' to the 
aggregatable reports' encrypted payloads. This ID allows histogram 
contributions with different filtering IDs to be processed separately 
on the aggregation service. A list of filtering IDs could be provided 
in an aggregation query and any contributions not matching a listed ID 
will be filtered out, not contributing to the result. To support the 
new feature, we update the report version to "1.0" (from "0.1"). By 
the time this is launched to Stable, all valid aggregation service 
releases will support the new report version, avoiding backwards 
compatibility concerns. (Old releases are deprecated on a regular 
schedule.)




Blink component

Blink>PrivateAggregation 




TAG review

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



TAG review status

Pending


Risks



Interoperability and Compatibility

The Aggregation Service (used to process the aggregatable reports) 
typically allows its releases to be used for up to six months. To 
reduce the compatibility impact of this change, we are waiting until 
all current Aggregation Service releases support the new version 
before rolling to Stable.


Can you say more about this? How many parties are running these 
services, and do we have any way of knowing what the uptake of new 
versions is, or said differently - can we tell if they're still on older 
versions?


Also, what happens if you send the filter ID to an older version?




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


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


/Web developers/: Positive signals for broad 
feature (https://github.com/patcg-individual-drafts/private-aggregation-api/issues/92) 



/Other signals/:


WebView application risks

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


None



Debuggability

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




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

All but Webview



Is this feature fully tested by web-platform-tests

?

Yes


Flag name on chrome://flags

None


Finch feature name

PrivateAggregationApiFilteringIds


Requires code in //chrome?

False


Tracking bug

https://crbug.com/330744610


Launch bug

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


Estimated milestones

Shipping on desktop 128

Shipping on Android 128



Anticipated spec changes

None


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4793172803977216?gate=5039125582577664

This intent message was generated by Chrome Platform Status 
.

--
You received this message because you are subscribed to the Google 
Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA%2BBiFk3Nz9owQQnA9XzYa43cLAoh53dXGQTEstn%2BStUuud--Q%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/e436def7-548c-463b-8ece-c394aefe9ea9%40chromium.org.

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

[Mike Taylor]

Hi Brett,

We don't yet have an expiration date set for 
https://chromeenterprise.google/policies/#DefaultThirdPartyStoragePartitioningSetting, 
or any concrete plans to add one. If and when we do decide to deprecate 
it, we'll give a 6 months deprecation notice through the normal 
enterprise policy channels. FWIW, I would like to remove it eventually - 
but I don't expect it to happen this year.


thanks,
Mike

On 7/5/24 12:37 PM, Brett McStotts wrote:


Can we confirm the above 
is 
true that the DisableStoragePartitioning Enterprise Policy will also 
expire on September 3rd, 2024?


We've uncovered an upcoming issue for us with Storage Partitioning and 
Partitioned cookies. We have Site A that embeds Site B in an iframe. 
Site B uses a Shared Worker that refreshes an access cookie. Disabling 
Storage Partitioning makes the Shared Worker a top-level context. So 
if the SharedWorker for the iframed sets a Partitioned cookie, the 
cookie will have a partition key of Site B. Therefore, it won't be 
accessible in the iframe embedded under Site A.


We're setting both a partitioned and unpartitioned cookie right now so 
it's fine. But after 3PCD the unpartitioned cookie won't be available. 
We'll have to tell customers embedding our site who are using the 
DisableStoragePartitioning Enterprise Policy to also use the 
CookiesAllowedForUrls Enterprise policy. Or make architecture changes.


However, if the Enterprise Policy is expiring then this is a non-issue.
On Monday, December 4, 2023 at 10:54:40 AM UTC-5 ari...@chromium.org 
wrote:


Heads up that there's an Origin Trial which allows unpartitioned
access to some storage and communication mechanisms via SAA (the
same mechanism that grants unpartitioned cookie access):
https://developer.chrome.com/blog/saa-non-cookie-storage/

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


On Mon, Apr 10, 2023 at 6:07 PM 'Elijah Grey' via blink-dev
 wrote:

Hi Chris,

I appreciate your response. Here are my responses to your points:

1. Yes, we plan to use FPS to put our consent management tool
in the same FPS (using .sync.transcend.io
 as a service domain per customer,
alternatively CNAME-backed by the customer). We will still be
forced to reduce customers' users' privacy by sharing user
consent data through cookies (and completely lose our ability
to sync quarantine data cross-site as it cannot safely be
included in network requests through cookies).
2. Thanks, I'll make sure to leave a comment about our use case.
3. Same as above. I'll expound on my use case in that issue too.

Again, I posit that the non-ideal alignment of these
unpartitioned storage deprecation timelines will push site
owners to use cookies to share state where they previously did
not have to use cookies. A non-cookie solution should be
available prior to the deprecation point to prevent adverse
incentives from affecting the web as a whole.

I understand that the actual harms are likely minor, but they
are measurable. We attempt to limit total entropy of consent
data propagated by our sync system, but even with our best
efforts it is not unreasonable to assume that bad actors would
use the uniqueness of consent cookies (e.g. by looking at
timestamps etc.) to uniquely track users. Our current system
does not attempt to uniquely track users and serves as an
enforcement point to prevent other tools from uniquely
tracking users for certain purposes without consent (depending
on user-applicable legal regimes).

Regards,
Eli
On Monday, April 10, 2023 at 10:45:09 AM UTC-7 Chris
Fredrickson wrote:

Hi Eli,

If I can chime in on a few points from the First-Party
Sets perspective:

 1. Do you plan to use First-Party Sets to put your
consent management site in the same FPS as your
customers' sites? (Note that you would have to work
around the FPS disjointness requirement

,
e.g. using CNAMEs.) That would allow your product to
continue to do limited cross-site data sharing,
although it would have to use cookies to do so.
 2. FYI, both the Storage Access API and Chromium's
proposed extension (requestStorageAccessFor) only
unblock access to unpartitioned cookies; they do not
unblock access to unpartitioned storage. (You may
already know this, since you linked to the relevant
Storage Access API issue

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

[Mike Taylor]

LGTM3

On 7/3/24 11:35 AM, Yoav Weiss (@Shopify) wrote:

LGTM2

Thanks for working through the PR!

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

LGTM1

/Daniel

On 2024-06-26 20:16, 'Sahir Vellani' via blink-dev wrote:

The PR is ready and has been *approved *by the PEWG.

The shape of the API has been reverted to an id (albeit with a
slight name change, persistentDeviceId) on the main PointerEvent
interface. All links along with request for positions have been
updated. Linking the spec pr here
for convenience.

On Thursday, May 23, 2024 at 7:00:38 AM UTC-7 fla...@chromium.org
wrote:

There were some fresh concerns raised about the shape of the
spec PR  which
are being hashed out on that review thread. I will give it
approval once we reach a consensus there.

On Wed, May 22, 2024 at 4:30 PM Yoav Weiss (@Shopify)
 wrote:

OK, thanks for outlining the spec mechanics :)

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

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



On 16/05/2024 21:05, Robert Flack wrote:
> I believe the reason for waiting is that the
intention is to switch to a
> different publishing model after level 3 is
published? @Patrick H. Lauke
>  to confirm.

Apologies for the convoluted model here ... I have to
admit that I'm
actually not sure what the expected way of working
around this is, as
Pointer Events has been such a "slow and steady"
process so far, with a
very linear way of working - it's only now that we're
just hoping to get
PE3 to REC and then had this extra functionality come
in that we've hit
this snag. I will check with Philippe at W3C to work
out what the best
way forward here is (have the "frozen" version that
makes its way
through the steps to REC, while being able to already
have a
"future/next" branch).

P
-- 
Patrick H. Lauke


* https://www.splintered.co.uk/
* https://github.com/patrickhlauke

* https://flickr.com/photos/redux/

* https://mastodon.social/@patrick_h_lauke


-- 
You received this message because you are subscribed to the

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

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/98e62b43-af6b-4db6-a6b7-b76bc0864eedn%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/bce38b12-556a-4a52-8316-40520857003fn%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/a02ac8dd-0b7c-418c-b2ea-993b96ee4654%40chromium.org.

Re: [blink-dev] Fwd: Intent to Extend Experiment: Protected Audience Bidding & Auction Services

[Mike Taylor]

I see - thanks for the info Paul. It seems like an unintentional mixup.

When I approved the previous extension I wrote: "I would like to see 
draft specifications and progress on making this testable via WPTs"


Russ thanks for linking to 
https://pr-preview.s3.amazonaws.com/brusshamilton/turtledove/pull/1200.html 
- based on this draft PR 
<https://github.com/WICG/turtledove/pull/1200/files>. You wrote that it 
describes _some_ of the changes, can you speak to what is missing (that 
you will presumably spec ahead of an I2S)?


And thanks for beginning to land WPTs 
<https://chromium-review.googlesource.com/c/chromium/src/+/5622101>.


On 6/28/24 1:59 PM, Paul Jensen wrote:

Mike,

It looks like we did continue the OT during M122-124 before sending 
the first I2EE, despite initially only asking for approval for 
M119-121.  I wonder if someone went off of the current OT policy of 
"An initial origin trial or experiment for a feature may only run for 
6 milestones" 
<https://www.chromium.org/blink/launching-features/#widen-review:~:text=An%20initial%20origin%20trial%20or%20experiment%20for%20a%20feature%20may%20only%20run%20for%206%20milestones> 
without knowing my initial ask was for just 3 milestones.  I apologize 
for that and am going to seek updating internal processes to add a 
check to prevent this oversight from happening again, even if the 
initial I2EE is "fairly mechanical" as you said originally.


On Wednesday, June 26, 2024 at 1:53:56 PM UTC-4 Mike Taylor wrote:

Hi Russ,

I'm trying to refresh my memory on the history of this experiment.

Experiment first approved on 10/19/23 for M119 to M121,

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

<https://groups.google.com/a/chromium.org/g/blink-dev/c/2bwMHd3Yz7I/m/BzI3_qoCAwAJ>


Request on 4/4/24 to renew from M124 to M127,

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

<https://groups.google.com/a/chromium.org/g/blink-dev/c/2bwMHd3Yz7I/m/xaJHFJ_uAAAJ>


Approved 4/12/24 (“for another 3 milestones”),

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

<https://groups.google.com/a/chromium.org/g/blink-dev/c/2bwMHd3Yz7I/m/Pm842qm_AAAJ>


Requesting M127 to M130 on 6/20/24,

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

<https://groups.google.com/a/chromium.org/g/blink-dev/c/2bwMHd3Yz7I/m/RigQFZilAgAJ>


Question: what happened between M122 and M124? Was the experiment
not running?


On 6/20/24 2:52 PM, 'Russ Hamilton' via blink-dev wrote:

(Now *To* blink-dev instead of just CC)


Contact emails

pauljen...@chromium.org, behamil...@google.com


Explainer

Chrome:

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

<https://github.com/WICG/turtledove/blob/main/FLEDGE_browser_bidding_and_auction_API.md>

Services:

https://github.com/privacysandbox/fledge-docs/blob/main/bidding_auction_services_api.md

<https://github.com/privacysandbox/fledge-docs/blob/main/bidding_auction_services_api.md>

Note that this explainer has a helpful onboarding section

<https://github.com/privacysandbox/fledge-docs/blob/main/bidding_auction_services_api.md#onboarding-and-alpha-testing-guide>for
setting up the services.


Specification

A work-in-progress pull request

<https://pr-preview.s3.amazonaws.com/brusshamilton/turtledove/pull/1200.html>on
the Protected Audience spec
<https://wicg.github.io/turtledove/>describes some of the changes
to the W3C spec. We are reaching out to the IETF ART Area
Directors for assistance beginning the standardization process
for some of the server-side aspects of this API.


Summary

We propose extending the Bidding and Auction Services origin
trial currently operating on 1% stable.

Recent changes:

 *

Prompted by developer concerns about scalability, we have
recently added support in M127 for limiting the size of the
Bidding and Auction request payload

 *

We also added controls to enable sellers to select which
buyers are included in the payload when it doesn’t affect the
outwardly visible size of the encrypted data.

 *

Additionally the Bidding and Auction server has recently
added support for features such as buyerReportingId and bid
currency.

We have decided to extend the experiment to give developers time
to experiment with the new features. We would like to request
extending the end milestone from M127 to M130.


Blink component

Blink>InterestGroups

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

Re: [blink-dev] Fwd: Intent to Extend Experiment: Protected Audience Bidding & Auction Services

[Mike Taylor]

Hi Russ,

I'm trying to refresh my memory on the history of this experiment.

Experiment first approved on 10/19/23 for M119 to M121, 
https://groups.google.com/a/chromium.org/g/blink-dev/c/2bwMHd3Yz7I/m/BzI3_qoCAwAJ 



Request on 4/4/24 to renew from M124 to M127, 
https://groups.google.com/a/chromium.org/g/blink-dev/c/2bwMHd3Yz7I/m/xaJHFJ_uAAAJ 



Approved 4/12/24 (“for another 3 milestones”), 
https://groups.google.com/a/chromium.org/g/blink-dev/c/2bwMHd3Yz7I/m/Pm842qm_AAAJ 



Requesting M127 to M130 on 6/20/24, 
https://groups.google.com/a/chromium.org/g/blink-dev/c/2bwMHd3Yz7I/m/RigQFZilAgAJ 



Question: what happened between M122 and M124? Was the experiment not 
running?



On 6/20/24 2:52 PM, 'Russ Hamilton' via blink-dev wrote:

(Now *To* blink-dev instead of just CC)


Contact emails

pauljen...@chromium.org, behamil...@google.com


Explainer

Chrome: 
https://github.com/WICG/turtledove/blob/main/FLEDGE_browser_bidding_and_auction_API.md 



Services: 
https://github.com/privacysandbox/fledge-docs/blob/main/bidding_auction_services_api.md 



Note that this explainer has a helpful onboarding section 
for 
setting up the services.



Specification

A work-in-progress pull request 
on 
the Protected Audience spec 
describes some of the changes to 
the W3C spec. We are reaching out to the IETF ART Area Directors for 
assistance beginning the standardization process for some of the 
server-side aspects of this API.



Summary

We propose extending the Bidding and Auction Services origin trial 
currently operating on 1% stable.


Recent changes:

 *

Prompted by developer concerns about scalability, we have recently
added support in M127 for limiting the size of the Bidding and
Auction request payload

 *

We also added controls to enable sellers to select which buyers
are included in the payload when it doesn’t affect the outwardly
visible size of the encrypted data.

 *

Additionally the Bidding and Auction server has recently added
support for features such as buyerReportingId and bid currency.

We have decided to extend the experiment to give developers time to 
experiment with the new features. We would like to request extending 
the end milestone from M127 to M130.



Blink component

Blink>InterestGroups 




TAG review

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




TAG review status

Completed for Protected Audience, resolved unsatisfied.


Interoperability and Compatibility


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


Edge: Microsoft has proposed their Ad Selection API
(https://github.com/WICG/privacy-preserving-ads/
) as
a similar TEE on-server auction API. That API looks like it
would have an identical Web Platform API as the Bidding and
Auction Services API. We have biweekly meetings with
Microsoft, and are open to collaborating on specifying the API.

WPT Tests

We have started to implement some tests 
, 
but work is still ongoing.



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4649601971257344 




Links to previous Intent discussions

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




Intent to Experiment:

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




Intent to Extend Experiment:

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




Thanks,


–Benjamin “Russ” Hamilton

--
You received this message because you are subscribed to the 

Re: [blink-dev] Intent to Experiment: Reverse origin trial for Standardized CSS zoom

[Mike Taylor]

Oh - also, can you request the Privacy, Security, Debuggability bits in 
chromestatus? thx


On 6/26/24 11:04 AM, Mike Taylor wrote:


On 6/25/24 5:31 PM, Stefan Zager wrote:

On Tue, Jun 25, 2024 at 1:54 PM Mike Taylor  
wrote:


On 6/25/24 4:23 PM, Stefan Zager wrote:


On Tue, Jun 25, 2024 at 7:24 AM Mike Taylor
 wrote:

Thanks for creating this - can you clarify how long you
would like this deprecation trial to last?

That will depend on the response from site owners and the level
of uptake, but the initial period will be one year.


Typically it is feature teams that determine the length of a
deprecation trial, rather than site owners - based on webcompat
analysis, which may include outreach to known affected sites. Per
https://www.chromium.org/blink/launching-features/#deprecation-trial
- deprecation trials normally only last 6 milestones, and are
renewed in 6 milestone increments. However, exceptions are
possible with 3 LGTMs.

If you think 1 year is the correct length for the ecosystem, can
you please provide justification for an exception here?

I mistakenly thought that one year was the standard period for a 
deprecation trial; in light of that documentation, I think six months 
is appropriate.


No worries - we can revisit in 6 months if needed.

LGTM




On 6/24/24 7:52 PM, Stefan Zager wrote:



Contact emails

sza...@chromium.org


Explainer

None


Specification

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


Design docs



https://docs.google.com/document/d/1AcnDShjT-kEuRaMchZPm5uaIgNZ4OiYtM4JI9qiV8Po/edit


Summary

Create a reverse origin trial to allow sites to opt out of
the "Standardized CSS Zoom" feature
<https://chromestatus.com/feature/5198254868529152>.
Existing sites may rely on chromium's legacy
non-spec-compliant behavior of the CSS zoom property. This
origin trial will allow individual sites to opt out of the
new spec-compliant behavior, to allow them time to migrate
to the newly-specified behavior.


Blink component

Blink>Paint

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


TAG review

None


TAG review status

Pending


Risks



Interoperability and Compatibility

This is meant to mitigate the compatibility risks of the
Standardized CSS Zoom feature. The origin trial will have a
limited duration, so sites that participate in the origin
trial but are not updated to support the new behavior will
still break when the origin trial ends.


WebView application risks

See Interoperability and Compatibility risks



Goals for experimentation

To provide a reprieve for sites that are broken by the new
zoom behavior.


Ongoing technical constraints

None



Debuggability

None



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

Yes


Is this feature fully tested by web-platform-tests

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

The legacy chromium-specific behavior is tested by
chromium-internal tests, but not WPT.


Flag name on chrome://flags

StandardizedBrowserZoom


Finch feature name

StandardizedBrowserZoom


Requires code in //chrome?

False


Estimated milestones

M128



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5198254868529152


Links to previous Intent discussions



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

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/CAHOQ7J-gUQpe%3DaFNm%2BcH8uWPx8rQrkbA4-BEX0vGivHsdfeZ-w%40mail.gmail.com

<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHOQ7J-gUQpe%3DaFNm%2BcH8uWPx8rQrkbA4-BEX0vGivHsdfeZ-w%40mail.gmail.com?utm_medium=email_source=footer>.




--
You received 

Re: [blink-dev] Intent to Experiment: Reverse origin trial for Standardized CSS zoom

[Mike Taylor]

On 6/25/24 5:31 PM, Stefan Zager wrote:

On Tue, Jun 25, 2024 at 1:54 PM Mike Taylor  
wrote:


On 6/25/24 4:23 PM, Stefan Zager wrote:


On Tue, Jun 25, 2024 at 7:24 AM Mike Taylor
 wrote:

Thanks for creating this - can you clarify how long you would
like this deprecation trial to last?

That will depend on the response from site owners and the level
of uptake, but the initial period will be one year.


Typically it is feature teams that determine the length of a
deprecation trial, rather than site owners - based on webcompat
analysis, which may include outreach to known affected sites. Per
https://www.chromium.org/blink/launching-features/#deprecation-trial
- deprecation trials normally only last 6 milestones, and are
renewed in 6 milestone increments. However, exceptions are
possible with 3 LGTMs.

If you think 1 year is the correct length for the ecosystem, can
you please provide justification for an exception here?

I mistakenly thought that one year was the standard period for a 
deprecation trial; in light of that documentation, I think six months 
is appropriate.


No worries - we can revisit in 6 months if needed.

LGTM




On 6/24/24 7:52 PM, Stefan Zager wrote:



Contact emails

sza...@chromium.org


Explainer

None


Specification

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


Design docs



https://docs.google.com/document/d/1AcnDShjT-kEuRaMchZPm5uaIgNZ4OiYtM4JI9qiV8Po/edit


Summary

Create a reverse origin trial to allow sites to opt out of
the "Standardized CSS Zoom" feature
<https://chromestatus.com/feature/5198254868529152>.
Existing sites may rely on chromium's legacy
non-spec-compliant behavior of the CSS zoom property. This
origin trial will allow individual sites to opt out of the
new spec-compliant behavior, to allow them time to migrate
to the newly-specified behavior.


Blink component

Blink>Paint

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


TAG review

None


TAG review status

Pending


Risks



Interoperability and Compatibility

This is meant to mitigate the compatibility risks of the
Standardized CSS Zoom feature. The origin trial will have a
limited duration, so sites that participate in the origin
trial but are not updated to support the new behavior will
still break when the origin trial ends.


WebView application risks

See Interoperability and Compatibility risks



Goals for experimentation

To provide a reprieve for sites that are broken by the new
zoom behavior.


Ongoing technical constraints

None



Debuggability

None



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

Yes


Is this feature fully tested by web-platform-tests

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

The legacy chromium-specific behavior is tested by
chromium-internal tests, but not WPT.


Flag name on chrome://flags

StandardizedBrowserZoom


Finch feature name

StandardizedBrowserZoom


Requires code in //chrome?

False


Estimated milestones

M128



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5198254868529152


Links to previous Intent discussions



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

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/CAHOQ7J-gUQpe%3DaFNm%2BcH8uWPx8rQrkbA4-BEX0vGivHsdfeZ-w%40mail.gmail.com

<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHOQ7J-gUQpe%3DaFNm%2BcH8uWPx8rQrkbA4-BEX0vGivHsdfeZ-w%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

Re: [blink-dev] Intent to Experiment: Reverse origin trial for Standardized CSS zoom

[Mike Taylor]

On 6/25/24 4:23 PM, Stefan Zager wrote:

On Tue, Jun 25, 2024 at 7:24 AM Mike Taylor  
wrote:


Thanks for creating this - can you clarify how long you would like
this deprecation trial to last?

That will depend on the response from site owners and the level of 
uptake, but the initial period will be one year.


Typically it is feature teams that determine the length of a deprecation 
trial, rather than site owners - based on webcompat analysis, which may 
include outreach to known affected sites. Per 
https://www.chromium.org/blink/launching-features/#deprecation-trial - 
deprecation trials normally only last 6 milestones, and are renewed in 6 
milestone increments. However, exceptions are possible with 3 LGTMs.


If you think 1 year is the correct length for the ecosystem, can you 
please provide justification for an exception here?



On 6/24/24 7:52 PM, Stefan Zager wrote:



Contact emails

sza...@chromium.org


Explainer

None


Specification

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


Design docs



https://docs.google.com/document/d/1AcnDShjT-kEuRaMchZPm5uaIgNZ4OiYtM4JI9qiV8Po/edit


Summary

Create a reverse origin trial to allow sites to opt out of the
"Standardized CSS Zoom" feature
<https://chromestatus.com/feature/5198254868529152>. Existing
sites may rely on chromium's legacy non-spec-compliant behavior
of the CSS zoom property. This origin trial will allow individual
sites to opt out of the new spec-compliant behavior, to allow
them time to migrate to the newly-specified behavior.


Blink component

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


TAG review

None


TAG review status

Pending


Risks



Interoperability and Compatibility

This is meant to mitigate the compatibility risks of the
Standardized CSS Zoom feature. The origin trial will have a
limited duration, so sites that participate in the origin trial
but are not updated to support the new behavior will still break
when the origin trial ends.


WebView application risks

See Interoperability and Compatibility risks



Goals for experimentation

To provide a reprieve for sites that are broken by the new zoom
behavior.


Ongoing technical constraints

None



Debuggability

None



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

Yes


Is this feature fully tested by web-platform-tests

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

The legacy chromium-specific behavior is tested by
chromium-internal tests, but not WPT.


Flag name on chrome://flags

StandardizedBrowserZoom


Finch feature name

StandardizedBrowserZoom


Requires code in //chrome?

False


Estimated milestones

M128



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5198254868529152


Links to previous Intent discussions



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

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/CAHOQ7J-gUQpe%3DaFNm%2BcH8uWPx8rQrkbA4-BEX0vGivHsdfeZ-w%40mail.gmail.com

<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHOQ7J-gUQpe%3DaFNm%2BcH8uWPx8rQrkbA4-BEX0vGivHsdfeZ-w%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/1e27a6a0-2d6b-4a99-a50f-374b28568971%40chromium.org.

Re: [blink-dev] Intent to Experiment: Reverse origin trial for Standardized CSS zoom

[Mike Taylor]

Thanks for creating this - can you clarify how long you would like this 
deprecation trial to last?


On 6/24/24 7:52 PM, Stefan Zager wrote:



Contact emails

sza...@chromium.org


Explainer

None


Specification

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


Design docs


https://docs.google.com/document/d/1AcnDShjT-kEuRaMchZPm5uaIgNZ4OiYtM4JI9qiV8Po/edit


Summary

Create a reverse origin trial to allow sites to opt out of the 
"Standardized CSS Zoom" feature 
. Existing sites 
may rely on chromium's legacy non-spec-compliant behavior of the CSS 
zoom property. This origin trial will allow individual sites to opt 
out of the new spec-compliant behavior, to allow them time to migrate 
to the newly-specified behavior.



Blink component

Blink>Paint 




TAG review

None


TAG review status

Pending


Risks



Interoperability and Compatibility

This is meant to mitigate the compatibility risks of the Standardized 
CSS Zoom feature. The origin trial will have a limited duration, so 
sites that participate in the origin trial but are not updated to 
support the new behavior will still break when the origin trial ends.



WebView application risks

See Interoperability and Compatibility risks



Goals for experimentation

To provide a reprieve for sites that are broken by the new zoom behavior.


Ongoing technical constraints

None



Debuggability

None



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

Yes


Is this feature fully tested by web-platform-tests

?

The legacy chromium-specific behavior is tested by chromium-internal 
tests, but not WPT.



Flag name on chrome://flags

StandardizedBrowserZoom


Finch feature name

StandardizedBrowserZoom


Requires code in //chrome?

False


Estimated milestones

M128



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5198254868529152


Links to previous Intent discussions


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

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/CAHOQ7J-gUQpe%3DaFNm%2BcH8uWPx8rQrkbA4-BEX0vGivHsdfeZ-w%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/5d3f59e6-1155-4650-bf31-6806cc0939c7%40chromium.org.

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

[Mike Taylor]

Thanks - LGTM1

On 6/24/24 11:02 AM, Raphael Kubo da Costa wrote:

Done!

Mike Taylor  writes:

Could you please request reviews for the various review gate bits in
your chromestatus entry?


(privacy, security, enterprise... etc)


On 6/19/24 3:54 AM, Mandy, Arnaud wrote:

Contact emails
raphael.kubo.da.co...@intel.com
<mailto:raphael.kubo.da.co...@intel.com>, juha.j.vai...@intel.com
<mailto:juha.j.vai...@intel.com>, kenneth.r.christian...@intel.com
<mailto:kenneth.r.christian...@intel.com>, arnaud.ma...@intel.com
<mailto:arnaud.ma...@intel.com>

Specification
https://github.com/w3c/compute-pressure/pull/284
<https://github.com/w3c/compute-pressure/pull/284>

Summary
This exposes WebDriver commands for creating, removing and updating
pressure source samples for so-called "virtual pressure sources":
pressure sources that do not depend on underlying hardware or
operating system support and can be used for testing.

Not only does this allow ChromeDriver users to test this API more
easily, but it was also one of the suggestions brought up during the
Intent to Ship thread for this API
<https://groups.google.com/a/chromium.org/g/blink-dev/c/7leKysvPZWk/m/MEtDE7zyAQAJ>,
as the existing web tests in WPT depend on MojoJS and are not
interoperable.

Blink component
Blink>PerformanceAPIs>ComputePressure
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EPerformanceAPIs%3EComputePressure>

TAG review
None

TAG review status
Not applicable

Risks


Interoperability and Compatibility
This feature implements WebDriver extension commands in ChromeDriver
that are used in web-platform-tests and can also be used by
ChromeDriver users. This feature is therefore not web-exposed, but
it does intend to help increase adoption of the spec by making it
possible for any implementation to run the existing web tests
without having to use JS mocks that are heavily Mojo-based although
not dependent on Mojo.

/Gecko/: No signal for this feature (Not in favor of Compute Pressure API)

/WebKit/: No signal for this feature (Not in favor of Compute
Pressure API)

/Web developers/: No signals

/Other signals/: Compute Pressure API Intent To Ship comment
<https://groups.google.com/a/chromium.org/g/blink-dev/c/7leKysvPZWk/m/MEtDE7zyAQAJ>.


Security
n/a, this is exposed through WebDriver. There have been changes to
the Compute Pressure code in //content and //services.

WebView application risks
None, this API is not exposed on Android.

Ongoing technical constraints
WebDriver endpoints and virtual pressure sources work in Window and
Dedicated Worker scopes, but not shared worker ones: we store
virtual pressure source information in WebContentsUserData, which
does not integrate well with shared workers. Shared worker support
would need to work with origins instead, but doing so would not play
well with any DevTools frontend work to support the Compute Pressure
API. The same constraint is also present in the spec, and feedback
is being gathered in issue 285
<https://github.com/w3c/compute-pressure/issues/285>.

Debuggability
This is a debugging feature. It exposes new ChromeDriver and CDP
endpoints, but the DevTools frontend has not been touched.

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

Is this feature fully tested by web-platform-tests
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?
The feature is currently tested by WPT, but the tests depend on
Mojo-specific JS mocks. Having these endpoints is the first step
towards making the existing web tests interoperable.

Requires code in //chrome?
True: //chrome/test/chromedriver

Tracking bug
https://issues.chromium.org/u/1/issues/347031400
<https://issues.chromium.org/u/1/issues/347031400>

Estimated milestones
Shipping on desktop 130


Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5130657352384512
<https://chromestatus.com/feature/5130657352384512>

-- You received this message because you are subscribed to the
Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/DS0PR11MB79029DDFA8D49E3C82BEAF4393CF2%40DS0PR11MB7902.namprd11.prod.outlook.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/DS0PR11MB79029DDFA8D49E3C82BEAF4393CF2%40DS0PR11MB7902.namprd11.prod.outlook.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/97a48e59-eefb-49bc-897c-06805d522990%40chromium.org.

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

[Mike Taylor]

Could you please request reviews for the various review gate bits in 
your chromestatus entry?



(privacy, security, enterprise... etc)


On 6/19/24 3:54 AM, Mandy, Arnaud wrote:

Contact emails
raphael.kubo.da.co...@intel.com 
, juha.j.vai...@intel.com 
, kenneth.r.christian...@intel.com 
, arnaud.ma...@intel.com 



Specification
https://github.com/w3c/compute-pressure/pull/284 



Summary
This exposes WebDriver commands for creating, removing and updating 
pressure source samples for so-called "virtual pressure sources": 
pressure sources that do not depend on underlying hardware or 
operating system support and can be used for testing.


Not only does this allow ChromeDriver users to test this API more 
easily, but it was also one of the suggestions brought up during the 
Intent to Ship thread for this API 
, 
as the existing web tests in WPT depend on MojoJS and are not 
interoperable.


Blink component
Blink>PerformanceAPIs>ComputePressure 



TAG review
None

TAG review status
Not applicable

Risks


Interoperability and Compatibility
This feature implements WebDriver extension commands in ChromeDriver 
that are used in web-platform-tests and can also be used by 
ChromeDriver users. This feature is therefore not web-exposed, but it 
does intend to help increase adoption of the spec by making it 
possible for any implementation to run the existing web tests without 
having to use JS mocks that are heavily Mojo-based although not 
dependent on Mojo.


/Gecko/: No signal for this feature (Not in favor of Compute Pressure API)

/WebKit/: No signal for this feature (Not in favor of Compute Pressure 
API)


/Web developers/: No signals

/Other signals/: Compute Pressure API Intent To Ship comment 
.



Security
n/a, this is exposed through WebDriver. There have been changes to the 
Compute Pressure code in //content and //services.


WebView application risks
None, this API is not exposed on Android.

Ongoing technical constraints
WebDriver endpoints and virtual pressure sources work in Window and 
Dedicated Worker scopes, but not shared worker ones: we store virtual 
pressure source information in WebContentsUserData, which does not 
integrate well with shared workers. Shared worker support would need 
to work with origins instead, but doing so would not play well with 
any DevTools frontend work to support the Compute Pressure API. The 
same constraint is also present in the spec, and feedback is being 
gathered in issue 285 
.


Debuggability
This is a debugging feature. It exposes new ChromeDriver and CDP 
endpoints, but the DevTools frontend has not been touched.


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

Windows, Mac, Linux, ChromeOS

Is this feature fully tested by web-platform-tests 
?
The feature is currently tested by WPT, but the tests depend on 
Mojo-specific JS mocks. Having these endpoints is the first step 
towards making the existing web tests interoperable.


Requires code in //chrome?
True: //chrome/test/chromedriver

Tracking bug
https://issues.chromium.org/u/1/issues/347031400 



Estimated milestones
Shipping on desktop 130


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



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


--
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0db8068e-5ca0-47f9-a5b5-fa27f9acc02f%40chromium.org.

Re: [blink-dev] Intent to Experiment: Digital Credential API

[Mike Taylor]

LGTM to experiment for 6 milestones from M128 to M133 inclusive.

On 6/22/24 1:44 PM, Rick Byers wrote:



Hello blink-dev,

I'd like to request permission to start an OT for this API. There's 
still a lot to figure out in the larger space of digital credentials 
on the web 
, 
but with eIDAS 
 
regulation passing in the EU which requires large platforms like 
Google to accept such credentials before 2026, we believe it's urgent 
to start testing out better solutions in the wild and try to rapidly 
iterate on designs.


Thanks,
   Rick


Contact emails

rby...@chromium.org, g...@chromium.org


Explainer

https://github.com/WICG/digital-credentials/blob/main/explainer.md


Specification

https://wicg.github.io/digital-credentials


Summary

Websites can and do get credentials from mobile wallet apps through a 
variety of mechanisms today (custom URL handlers, QR code scanning, 
etc.). This Web Platform feature would allow sites to request identity 
information from wallets via Android's IdentityCredential CredMan 
system. It is extensible to support multiple credential formats (eg. 
ISO mDoc and W3C verifiable credential) and allows multiple wallet 
apps to be used. Mechanisms 
 
are being added to help reduce the risks 
 of 
ecosystem-scale abuse of real-world identity.



Blink component

Blink>Identity>DigitalCredentials 




TAG review

Mozilla feedback 
 from 
Martin (also on the TAG) suggests we need to invest more in the threat 
model for the larger space and clarify specific privacy mitigations 
before requesting TAG review. We are involved in ongoing work 
 in the PING to 
analyze and provide guidelines for the larger space of digital 
credentials on the web.



TAG review status

Not started


Risks


Interoperability and Compatibility

There are multiple standards efforts involved here. We have been 
working with WebKit and Mozilla in the WICG on defining this specific 
API. But the greater interoperability risk will come from the data 
that is sent and returned via this API. Details of that are still in 
discussions but mostly driven outside the web browser community in the 
OpenID Foundation (eg. OpenID4VP: 
https://openid.net/specs/openid-4-verifiable-presentations-1_0.html) 
and ISO (18013-7 "mdoc": https://www.iso.org/standard/82772.html)




/Gecko/: Negative 
(https://github.com/mozilla/standards-positions/issues/1003) We share 
most of Mozilla's concerns and continue to work with them (and the 
broader community) on mitigations. I believe we feel greater risk for 
the established practice of custom schemes becoming prevalent than 
Mozilla does (eg. due to Google being mandated by eIDAS regulation to 
accept EUDI credentials by 2026).


/WebKit/: In development 
(https://github.com/WebKit/standards-positions/issues/332) WebKit 
implementation progress: https://bugs.webkit.org/show_bug.cgi?id=268516


/Web developers/: No signals

/Other signals/: This work in the W3C PING is relevant: 
https://github.com/w3cping/credential-considerations/



Ergonomics

There's a possibility that these credentials will be used alongside 
other types of credentials in the future - such as optionally minting 
a passkey when a digital credential is used to sign up for a site, or 
by allowing sign-up with either a digital credential or a federated 
credential via FedCM. As such we argued it was best to put this work 
in the context of the Credential Management API. However there's also 
a compelling argument that identity claims are much more than 
"credentials" and should evoke different developer expectations. The 
agreed upon compromise was to add a new credential container at 
'navigator.identity'.




Activation

The primary activation concern is enabling existing deployments using 
technology like OpenID4VP to be able to also support this API. As such 
we have left the request protocol unspecified at this layer, to be 
specified along with existing request protocols to maximize activation 
opportunity.




Security

See 
https://github.com/WICG/digital-credentials/blob/main/horizontal-reviews/security-privacy.md 
and https://github.com/WICG/digital-credentials/issues/115




WebView application risks

No


Goals for experimentation

We want to gather initial feedback from production 

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

[Mike Taylor]

LGTM2

On 6/12/24 11:25 AM, Yoav Weiss (@Shopify) wrote:

LGTM1

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

Hi Yoav,

The list of debugging signals is part of the spec:

https://wicg.github.io/attribution-reporting-api/#source-debug-data-type
https://wicg.github.io/attribution-reporting-api/#trigger-debug-data-type


Awesome, thanks!



Thanks,
Nan

On Wednesday, June 12, 2024 at 4:27:41 AM UTC-4 Yoav Weiss wrote:

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

Hi Yoav,

The debug signals that will be reported on are documented
here:

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


Thanks! Should that be part of the spec?


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


These debug signals are not developer defined, however a
developer can specify which of the signals they want to
track and can group certain signals together (more details
here

).

Thanks,
Akash
On Monday, June 10, 2024 at 10:02:08 PM UTC-7 Yoav Weiss
(@Shopify) wrote:

On Fri, Jun 7, 2024 at 8:12 PM 'Akash Nadan' via
blink-dev  wrote:

Contact emails

akash...@google.com, lin...@chromium.org,
john...@chromium.org


Explainer

Attribution Reporting with event-level reports



Attribution Reporting API with Aggregatable
Reports



Aggregation Service for the Attribution Reporting
API




Specification

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



Blink component

Internals > AttributionReporting




TAG review

Still under review
under
the original I2S for the Attribution Reporting API


TAG review status

Pending


Summary

We are landing the following changes to the
Attribution Reporting API focused on:

 *

improving debugging capabilities


This change is based on ad-tech feedback and the
need to support debugging capabilities after
third-party cookie deprecation.


Currently the API supports debug reports that are
tied to third-party cookies. In order for an API
caller to receive a debug report of any kind they
need to make sure a specific third-party cookie
(i.e. ar_debug) is properly set. The API will
check to make sure this cookie is set before
providing any kind of debug report. Once
third-party cookies are deprecated these debug
reports will no longer be available.


This change is so the API can continue to provide
debugging information after third-party cookie
deprecation when the current debug reports that
are tied to third-party cookies are no longer
available. This is a new report type that is not
tied to third-party cookies and provides similar
debug information. This feature allows API callers
to request and receive debug signals in aggregate
form. This feature is very similar to current
Aggregate Reports supported by the API, except
these new reports will be specifically for debug
signals.


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


This new feature will allow API callers to

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

[Mike Taylor]

On 6/4/24 1:53 PM, Caleb Raitto wrote:


Response inline

On Monday, June 3, 2024 at 10:16:06 PM UTC-4 Mike Taylor wrote:

On 5/31/24 11:40 PM, Paul Jensen wrote:


Contact emails

pauljen...@chromium.org


Explainer

https://github.com/WICG/turtledove/pull/1095
<https://github.com/WICG/turtledove/pull/1095>


Specification

https://github.com/WICG/turtledove/pull/1124
<https://github.com/WICG/turtledove/pull/1124>


Summary

The Protected Audience API allows bidders to store information,
called an interest group, from a single site in the browser that
can only be read later in the context of an auction.  Today,
interest groups can be updated by fetching new values from a
server.  For all interest groups, the frequency of these updates
is rate limited to at most once a day to conserve network traffic
and avoid overwhelming servers.  However, we've heard from
developers that certain ad campaigns need much more timely
updates.  During Protected Audience auctions, the browser fetches
real-time signals from bidders' key-value servers.  This proposal
allows the response to these fetches to indicate a subset of
interest groups they’d like updated more frequently than once a day.


Blink component

Blink>InterestGroups

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


TAG review

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


TAG review status

Completed for Protected Audience, resolved unsatisfied.


Risks Interoperability and Compatibility

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


Gecko & WebKit: No signal on parent proposal, Protected Audience.
Asked in the Mozilla forumhere
<https://github.com/mozilla/standards-positions/issues/770>, and
in the Webkit forum here
<https://github.com/WebKit/standards-positions/issues/158>.


Edge: Edge has announced plans to support the Ad Selection API
<https://github.com/WICG/privacy-preserving-ads/blob/main/README.md>which
shares much of its API surface with Protected Audience.


Web developers:

Feature requested by Microsoft in GitHub issue
<https://github.com/WICG/turtledove/issues/729>.


I don't see any feedback from Microsoft on this design in the
issue (just from Criteo, which seems inconclusive). Have they
given feedback elsewhere?


The response from Microsoft (ads) is here: 
https://github.com/WICG/turtledove/issues/729#issuecomment-1822190741 
-- it's the opening paragraph that starts with "I do think having a 
'please refresh when this auction is over' lever is a clear 
improvement over the current situation from a functionality perspective".


OK - thanks. I was hoping they might have responded elsewhere to your 
request for feedback from April 
<https://github.com/WICG/turtledove/issues/729#issuecomment-2077517709> 
or May, but I don't see a reason to block on that.


LGTM1



Debuggability

Protected Audience trusted bidding signals show up in the
DevTools Network pane. Updates show up in the Application ->
Storage -> Interest Groups DevTools pane.


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

It will be supported on all platforms that support Protected
Audience, so all but WebView.


Is this feature fully tested by web-platform-tests

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


Yes

<https://github.com/web-platform-tests/wpt/blob/f118165cd650448765d2e0efd3d7ee71f1e15e4f/fledge/tentative/trusted-bidding-signals.https.window.js#L973>.


Flag name on chrome://flags

None


Finch feature name

InterestGroupUpdateIfOlderThan


Requires code in //chrome?

False


Estimated milestones

Shipping on desktop and Android in M125.


Anticipated spec changes

None


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5162656775536640
<https://chromestatus.com/feature/5162656775536640>


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
<mailto:blink-dev+unsubscr...@chromium.org>.
To view this discussion on the web visit

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABQTWr%3DWxOenJmSZ5oW%3DVDdJ9q1nwovSJdgPw_91Fp3fkV01ew%40mail.gmail.com
   

Re: [blink-dev] Intent to Ship: CSS ruby-align property

[Mike Taylor]

LGTM2

On 6/7/24 1:39 AM, Chris Harrelson wrote:

Sorry, make that "LGTM1"

On Thu, Jun 6, 2024 at 9:39 AM chrishtr via Chromestatus 
> wrote:


LGTM
-- 
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/eba2d9061a3b5258%40google.com

.

--
You received this message because you are subscribed to the Google 
Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw9Vr%3DAEvoS3ZyZcjxLh%2BcBvJ-88NqEhDfOmCV8qBJ28_Q%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/5045d36d-6dfc-47ef-98e3-2e3a25eb34ea%40chromium.org.

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

[Mike Taylor]

I will claim that it doesn't, since it's just for 1 more milestone.

(if other API OWNERS disagree, now is a great time to chime in!)

On 6/6/24 2:30 PM, John Delaney wrote:
Thanks Mike. I should have included this in the original email, but 
the initial I2E for this feature needed 3 LGTMs as it was a 
non-standard experiment. Does this extension also require 3?


Thanks again!

On Thu, Jun 6, 2024 at 1:00 AM Mike Taylor  wrote:

LGTM to extend one more milestone (M126).

On 6/5/24 11:57 PM, John Delaney wrote:


We would like to extend the Cookie Deprecation Label experimental
feature being used for Chrome Facilitated Testing.  This feature
previously received approval to run through the end of M125
(ending roughly June 10, 2024).  The Facilitated Testing period,
however, is scheduled to run through June 30, 2024.


Therefore, we would like to extend Cookie Deprecation Labels for
another milestone through M126.


Contact emails

johni...@chromium.org <mailto:johni...@chromium.org>,
wanderv...@chromium.org <mailto:wanderv...@chromium.org>,
lin...@chromium.org <mailto:lin...@chromium.org>


Explainer


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

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

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


Summary

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


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


We are exploring ways to address ecosystem feedback that we
should continue supporting labels after 30 June. We expect to
provide more information soon.

Link to “Intent to Experiment” blink-dev discussion


https://groups.google.com/a/chromium.org/g/blink-dev/c/3escBQGtIpM/m/ntcytva5BgAJ

<https://groups.google.com/a/chromium.org/g/blink-dev/c/3escBQGtIpM/m/ntcytva5BgAJ>

Goals for experimentation

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


Experimental timeline

Previously the feature was approved until M125.  We'd like to
extend the experiment by one milestone to M126 so that we can
continue to support the Chrome Facilitated Testing period until
June 30, 2024. Any experimentation after June 30 will be covered
by another Intent.


Any risks when the experiment finishes?

Minimal. The feature is designed in a way that websites must
feature detect for the web API. This feature is also only
available for a subset of users.


Reason this experiment is being extended

This feature is necessary to support the ongoing Chrome
Facilitated Testing effort

<https://developers.google.com/privacy-sandbox/relevance/setup/web/chrome-facilitated-testing>.
The Facilitated Testing period is scheduled to complete on June
30, 2024 which is slightly beyond our previous approval for the
feature.  Therefore we are requesting to extend the experimental
feature access to M126.


Ongoing technical constraints

None


Will this feature be supported on all five Blink platforms
supported by Origin Trials (Windows, Mac, Linux, Chrome OS, and
Android)?

No, not supported on webview.


Link to entry on the feature dashboard

https://chromestatus.com/feature/5189079788683264
<https://chromestatus.com/feature/5189079788683264>


-- 
You received this message because you are subscribed to the

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

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/cc8339ee-9996-43cf-b3ec-451f01f9e64cn%40chromium.org

<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/cc8339ee-9996-43cf-b3ec-451f01f9e64cn%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/5fdea5ce-fabf-48b2-9c33-2e62d392%40chromium.org.

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

[Mike Taylor]

LGTM to extend one more milestone (M126).

On 6/5/24 11:57 PM, John Delaney wrote:


We would like to extend the Cookie Deprecation Label experimental 
feature being used for Chrome Facilitated Testing.  This feature 
previously received approval to run through the end of M125 (ending 
roughly June 10, 2024).  The Facilitated Testing period, however, is 
scheduled to run through June 30, 2024.



Therefore, we would like to extend Cookie Deprecation Labels for 
another milestone through M126.



Contact emails

johni...@chromium.org , 
wanderv...@chromium.org , 
lin...@chromium.org 



Explainer

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



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




Summary

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



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



We are exploring ways to address ecosystem feedback that we should 
continue supporting labels after 30 June.  We expect to provide more 
information soon.


Link to “Intent to Experiment” blink-dev discussion

https://groups.google.com/a/chromium.org/g/blink-dev/c/3escBQGtIpM/m/ntcytva5BgAJ 



Goals for experimentation

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



Experimental timeline

Previously the feature was approved until M125.  We'd like to extend 
the experiment by one milestone to M126 so that we can continue to 
support the Chrome Facilitated Testing period until June 30, 2024. Any 
experimentation after June 30 will be covered by another Intent.



Any risks when the experiment finishes?

Minimal. The feature is designed in a way that websites must feature 
detect for the web API. This feature is also only available for a 
subset of users.



Reason this experiment is being extended

This feature is necessary to support the ongoing Chrome Facilitated 
Testing effort 
. 
The Facilitated Testing period is scheduled to complete on June 30, 
2024 which is slightly beyond our previous approval for the feature.  
Therefore we are requesting to extend the experimental feature access 
to M126.



Ongoing technical constraints

None


Will this feature be supported on all five Blink platforms supported 
by Origin Trials (Windows, Mac, Linux, Chrome OS, and Android)?


No, not supported on webview.


Link to entry on the feature dashboard

https://chromestatus.com/feature/5189079788683264 




--
You received this message because you are subscribed to the Google 
Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/cc8339ee-9996-43cf-b3ec-451f01f9e64cn%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/7650877c-a675-4ce0-a4cc-28e8a70521f6%40chromium.org.

Re: [blink-dev] Intent to Ship: No-Vary-Search Hint for Prerender Speculation Rules

[Mike Taylor]

LGTM1

On 6/5/24 11:21 PM, Liviu Tinta wrote:



Contact emails

dome...@chromium.org, jbro...@chromium.org, liviuti...@chromium.org


Explainer

https://github.com/WICG/nav-speculation/blob/main/triggers.md#no-vary-search-hint 




Specification

https://wicg.github.io/nav-speculation/prerendering.html 




Summary

Adds a hint to speculation rules that informs the navigation prerender 
cache that the URL to be prerendered expects to receive the same 
No-Vary-Search header in the response.


The hint is useful because prerenders that depend on No-Vary-Search to 
match to navigations do not benefit the user if the navigation happens 
before prerender headers return from the server.  Using the hint, the 
web browser will expect, but verify, that the No-Vary-Search hint 
matches with the No-Vary-Search header. If the No-Vary-Search hint 
does not match the No-Vary-Search header received then the web browser 
will send a new request.



We would like to ship "No-Vary-Search Hint for Prerender Speculation 
Rules" together with "No-Vary-Search support for prerender 
".



Blink component

Internals>Preload>Prerender 




TAG review

Not applicable. The TAG has already given a negative opinion on the 
overall complexity of speculation rules ( 
https://github.com/w3ctag/design-reviews/issues/721 
), so we 
anticipate it would not be a good use of their time to review 
additions to the syntax. The addition itself is small and any 
architectural questions about it would be covered under the general 
closed speculation rules review.



TAG review status

Not applicable


Risks



Interoperability and Compatibility

None



Gecko: No signal 
(https://github.com/mozilla/standards-positions/issues/620#issuecomment-1608195274 
)



WebKit: No signal 
(https://github.com/WebKit/standards-positions/issues/54#issuecomment-1608197504 
)



Web developers: Below is the text from the I2S of the No-Vary-Search 
on navigational prefetch, and we believe the same applies to 
Prerendering. Google Search has been experimenting with No-Vary-Search 
header / Speculation Rules "expects_no_vary_search". This 
functionality helps Google Search to match prefetched content to the 
next user navigation. Developers can use parameters in the prefetched 
URL that are not needed when navigating to the actual link (e.g. the 
source of the link click). The server can customize behavior using 
these parameters without causing a cache miss in the browser. 
"expects_no_vary_search" addition to Speculation Rules allows the 
browser to completely handle the case where the user navigates to a 
URL that is currently prefetched by waiting for the ongoing prefetch 
instead of directly requesting the page from the server. Google Search 
conducted experiments prefetching Search results pages from the search 
box and other links that lead to another Search results page. There 
was significant latency improvement for navigating to Search result 
pages prefetched using No-Vary-Search header and "expects_no_vary_search".



Other signals: No-Vary-Search header has been discussed, together with 
No-Vary-Search Hint for Prefetch Speculation Rules at Web Perf WG 
meeting at TPAC 2023. 
https://docs.google.com/presentation/u/1/d/1GK92nCORW5vKd7LgGtTsgy35eqTV7P71l05pHsni8ok/edit#slide=id.g240fd6541f7_0_31 




Ergonomics

(Text taken from Prefetch NVS I2S)


No-Vary-Search will be used in tandem with Speculation Rules 
(https://wicg.github.io/nav-speculation/speculation-rules.html 
). The 
default usage of No-Vary-Search will not make it hard for Chrome to 
maintain good performance.




Security

See:https://github.com/WICG/nav-speculation/blob/main/no-vary-search-security-privacy-questionnaire.md 





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?


We are closely working with Android WebView team, and the broader 
prerender feature is gated through new AwSettings API (currently 
@RequiresOptIn) so there's zero risk that it will break existing 
WebView apps.

Re: [blink-dev] Re: Intent to Ship: No-Vary-Search support for prerender

[Mike Taylor]

LGTM1 - I'm very happy to see this ship.

On 6/6/24 11:42 AM, Domenic Denicola wrote:
I will abstain from approving this feature as an API Owner, as one of 
the people responsible for it. But I will urge other API owners to 
approve it, and give a bit of reasoning.


In my opinion, this is a straightforward extension from prefetch to 
prerender which makes the web platform more uniform. It is good that 
it is being done as a separate intent, since it is shipping at a 
different time, and thus need to appear separately in e.g. beta blog 
posts and other developer-facing documentation. But I think the same 
considerations that helped the prefetch version get a prompt approval 
should apply here.


BTW, looking back on that previous thread 
, 
some of the non-blocking discussion raised there was about engaging 
the HTTPWG. I'm happy to report that we've started this process, 
producing a draft RFC 
 and 
getting some discussion 
 
started on the relevant mailing list, which seem relatively positive 
to me. There was also some concern about ensuring that compression 
dictionaries and this header aligned on the same naming; as far as I 
can tell that issue no longer exists as the latest compression 
dictionaries draft 
 only 
has "match", and no longer "match-query".


On Wednesday, June 5, 2024 at 11:04:10 PM UTC+9 Liviu Tinta wrote:

Contact emails

dome...@chromium.org, jbro...@chromium.org, liviuti...@chromium.org


Explainer


https://github.com/WICG/nav-speculation/blob/main/no-vary-search.md#prerendering-activation




Specification

https://wicg.github.io/nav-speculation/no-vary-search.html



Summary

Enables a prerender entry to match even if URL query parameters
change. The No-Vary-Search HTTP response header declares that some
or all parts of a URL's query can be ignored for cache matching
purposes. It can declare that the order of query parameter keys
should not cause cache misses, that specific query parameters
should not cause cache misses or that only certain known query
parameters should cause cache misses. It could apply to multiple
caches, but this entry refers to support for prerender.



Blink component

Internals>Preload>Prerender




TAG review

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



TAG review status

Pending


Risks

Interoperability and Compatibility

None



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


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


Web developers: No signals Below is the text from the I2S of the
No-Vary-Search on navigational prefetch, and we believe the same
applies to Prerendering. Google Search has been experimenting with
No-Vary-Search header / Speculation Rules
"expects_no_vary_search". This functionality helps Google Search
to match prefetched content to the next user navigation.
Developers can use parameters in the prefetched URL that are not
needed when navigating to the actual link (e.g. the source of the
link click). The server can customize behavior using these
parameters without causing a cache miss in the browser.
"expects_no_vary_search" addition to Speculation Rules allows the
browser to completely handle the case where the user navigates to
a URL that is currently prefetched by waiting for the ongoing
prefetch instead of directly requesting the page from the server.
Google Search conducted experiments prefetching Search results
pages from the search box and other links that lead to another
Search results page. There was significant latency improvement for
navigating to Search result pages prefetched using No-Vary-Search
header and "expects_no_vary_search".


Other signals: No-Vary-Search header has been discussed, together
with No-Vary-Search Hint for Prefetch Speculation Rules at Web
Perf WG meeting at TPAC 2023.

https://docs.google.com/presentation/u/1/d/1GK92nCORW5vKd7LgGtTsgy35eqTV7P71l05pHsni8ok/edit#slide=id.g240fd6541f7_0_31

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

[Mike Taylor]

On 6/4/24 9:50 PM, Adam Langley wrote:


On Mon, Jun 3, 2024 at 7:36 PM Mike Taylor  wrote:

(oops, accidentally removed agl@ from To, fixing)

On 6/4/24 11:35 AM, Mike Taylor wrote:


Hi Adam,

Could you please request reviews (or N/A, if you have internal
approvals) for Privacy, Security, and Enterprise bits in your
chromestatus entry?


Reviews have been requested for some time now.
Sorry - unsure if this is a chromestatus bug or I am missing something - 
I see that Privacy, Security, and Enterprise were requested 9 hours ago. 
Either way - thanks. :)



thx,
Mike

On 6/4/24 5:59 AM, Adam Langley wrote:



Contact emails

a...@chromium.org


Specification

https://w3c.github.io/webauthn/#enum-hints


Summary

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



Blink component

Blink>WebAuthentication

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


TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

None: new option which only tweaks UI.


/Gecko/: No signal

/WebKit/: No objections when asked in person.

/Web developers/: Positive. Several sites have requested this
functionality, which motivated the spec change. They continue to
want it and have done so for quite a while now.


WebView application risks

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

No.



Debuggability

Not really. This causes the browser UI to switch emphasis, but
doesn't other change any site-observable behaviour.


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


On Android & Android WebView, support would require changes to
other components: the android.credentials code in the framework
and, for older Android versions, Play Services. That might come
in the future, but it's not part of the Blink and Chrome work.
(The Blink change is, of course, required for anything else in
the system to be able to handle this parameter.)


Some versions of Windows handle WebAuthn UI themselves and,
while Chrome can change it's UI, this parameter won't
immediately change the Windows UI. However, Microsoft is
positive about this change and Chromium will be updated to pass
this parameter on as soon as the Windows API is able to receive it.



Is this feature fully tested by web-platform-tests

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

No

Hints only affect the browser UI and unknown parameters are
ignored in WebAuthn already.



Flag name on chrome://flags

None


Finch feature name

WebAuthenticationHints


Requires code in //chrome?

True: Chrome-specific WebAuthn UI is handled in //chrome and
needs to respond to these hints. Other embedders would have to
do the same to benefit from this change.


Estimated milestones

Shipping on desktop 128




Anticipated spec changes

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

None


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5145737733341184?gate=5155815622443008
-- 
You received this message because you are subscribed to the

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

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL9PXLzcnJ9xLwJZzQJBL0UJdnDGb7tB5Uu7cYqB%2Bdcdb%2BCfTQ%40mail.gmail.com

<https://groups.google.com/

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

[Mike Taylor]

Hi Emily,

A few questions inline:

On 6/1/24 5:05 AM, Emily Stark wrote:



Contact emails

est...@google.com, jdebla...@google.com, dadr...@google.com, 
l...@chromium.org, tito...@chromium.org, cl...@chromium.org, 
mk...@chromium.org, v...@chromium.org



Explainer

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


Specification

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


Design docs


https://docs.google.com/document/d/1x1a1fQLOrcWogK3tpFBgQZQ5ZjcONTvD0IqqXkgrg5I/edit#heading=h.7nki9mck5t64


Summary

Requires that private network requests for subresources from public 
websites may only be initiated from a secure context. Examples include 
internet to intranet requests and internet to loopback requests. This 
is a first step towards fully implementing Private Network Access: 
https://wicg.github.io/private-network-access/




Blink component

Blink>SecurityFeature>CORS>PrivateNetworkAccess 




TAG review

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


TAG review status

Issues addressed


Chromium Trial Name

PrivateNetworkAccessNonSecureContextsAllowed


Link to origin trial feedback summary

https://docs.google.com/spreadsheets/d/1z5ZdCslNCnSVR7TNlUTHjSvunMFmT_9G9NOx8-O78-I/edit?usp=sharing=0-DITlG8tDuFDWHiBUHnlSoQ 




Origin Trial documentation link

https://developer.chrome.com/blog/private-network-access-update/


WebFeature UseCounter name

kPrivateNetworkAccessNonSecureContextsAllowedDeprecationTrial


Risks



Interoperability and Compatibility

No interoperability risks. Compatibility risk is small but 
non-negligible. UseCounters show ~0.1% of page visit making use of 
this feature. Direct outreach to the largest users per UKM data 
revealed no objections to this launch. Rolling this deprecation out to 
beta per the previous I2S resulted in more feedback about the 
compatibility risk and the need for a time extension. See the 
following doc for an extensive discussion: 
https://docs.google.com/document/d/1bpis0QwaA9ZrRFmpPW6LiaPmdwT0UhhUMNsEnU0zfLk/edit


Can you speak to the number of sites in the largest users group? Is it 
dozens of sites? Hundreds? Presumably they're all enrolled in the DT?


/Gecko/: Closed Without a Position 
(https://github.com/mozilla/standards-positions/issues/143) 
Tentatively positive, but no formal position yet.


/WebKit/: Positive 
(https://lists.webkit.org/pipermail/webkit-dev/2021-May/031837.html)


/Web developers/: Mixed signals 
(https://docs.google.com/document/d/1bpis0QwaA9ZrRFmpPW6LiaPmdwT0UhhUMNsEnU0zfLk/edit) 
In our recent survey, most of websites are able to migrate if our new 
permission prompt can be landed as a way for them to relax mixed 
content checks. 
https://docs.google.com/spreadsheets/d/1z5ZdCslNCnSVR7TNlUTHjSvunMFmT_9G9NOx8-O78-I/edit?resourcekey=0-DITlG8tDuFDWHiBUHnlSoQ#gid=309953809  
Some websites, broadly falling in the category of controller webapps 
for IoT devices, find this change incompatible with their use cases. 
While many use cases can be solved with specific workarounds, some 
still require further engagement.


/Other signals/:


Activation

Developers of non-secure sites that rely upon local servers will need 
to upgrade to HTTPS. This might cause some complications, as 
mixed-content checks will begin to apply. Chrome carves out HTTP 
access to loopback (as 
perhttps://w3c.github.io/webappsec-secure-contexts/#localhost 
), which is 
a release valve for folks who don't want to go through the effort of 
securely-distributing certs for local servers. The initial launch in 
M92 was delayed due to compatibility risks surfaced during the rollout 
to beta. See this doc for a lot more details: 
https://docs.google.com/document/d/1bpis0QwaA9ZrRFmpPW6LiaPmdwT0UhhUMNsEnU0zfLk/edit




Security

This change should be security-positive.



WebView application risks

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




Goals for experimentation



Reason this experiment is being extended

The blocker to shipping this feature is that some websites can't 
create HTTPS connections to subresources on the private network due to 
various constraints (e.g., unable to obtain a publicly trusted HTTPS 
certificate). A permission prompt is in development 
(https://groups.google.com/a/chromium.org/g/blink-dev/c/sL15TKGmXqM/m/rD0SF8sQBwAJ) 
to allow such subresources to be loaded over HTTP (whereas they would 
usually be blocked by mixed content rules). 

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

[Mike Taylor]

(oops, accidentally removed agl@ from To, fixing)

On 6/4/24 11:35 AM, Mike Taylor wrote:


Hi Adam,

Could you please request reviews (or N/A, if you have internal 
approvals) for Privacy, Security, and Enterprise bits in your 
chromestatus entry?


thx,
Mike

On 6/4/24 5:59 AM, Adam Langley wrote:



Contact emails

a...@chromium.org


Specification

https://w3c.github.io/webauthn/#enum-hints


Summary

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




Blink component

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



TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

None: new option which only tweaks UI.


/Gecko/: No signal

/WebKit/: No objections when asked in person.

/Web developers/: Positive. Several sites have requested this 
functionality, which motivated the spec change. They continue to want 
it and have done so for quite a while now.



WebView application risks

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


No.



Debuggability

Not really. This causes the browser UI to switch emphasis, but 
doesn't other change any site-observable behaviour.



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


On Android & Android WebView, support would require changes to other 
components: the android.credentials code in the framework and, for 
older Android versions, Play Services. That might come in the future, 
but it's not part of the Blink and Chrome work. (The Blink change is, 
of course, required for anything else in the system to be able to 
handle this parameter.)



Some versions of Windows handle WebAuthn UI themselves and, while 
Chrome can change it's UI, this parameter won't immediately change 
the Windows UI. However, Microsoft is positive about this change and 
Chromium will be updated to pass this parameter on as soon as the 
Windows API is able to receive it.




Is this feature fully tested by web-platform-tests

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

No

Hints only affect the browser UI and unknown parameters are ignored 
in WebAuthn already.




Flag name on chrome://flags

None


Finch feature name

WebAuthenticationHints


Requires code in //chrome?

True: Chrome-specific WebAuthn UI is handled in //chrome and needs to 
respond to these hints. Other embedders would have to do the same to 
benefit from this change.



Estimated milestones

Shipping on desktop 128




Anticipated spec changes

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


None


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5145737733341184?gate=5155815622443008
--
You received this message because you are subscribed to the Google 
Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, 
send an email to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL9PXLzcnJ9xLwJZzQJBL0UJdnDGb7tB5Uu7cYqB%2Bdcdb%2BCfTQ%40mail.gmail.com 
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL9PXLzcnJ9xLwJZzQJBL0UJdnDGb7tB5Uu7cYqB%2Bdcdb%2BCfTQ%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/24d1ed57-7ed0-429e-be56-e85ddd70e2ce%40chromium.org.

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

[Mike Taylor]

Hi Adam,

Could you please request reviews (or N/A, if you have internal 
approvals) for Privacy, Security, and Enterprise bits in your 
chromestatus entry?


thx,
Mike

On 6/4/24 5:59 AM, Adam Langley wrote:



Contact emails

a...@chromium.org


Specification

https://w3c.github.io/webauthn/#enum-hints


Summary

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




Blink component

Blink>WebAuthentication 




TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

None: new option which only tweaks UI.


/Gecko/: No signal

/WebKit/: No objections when asked in person.

/Web developers/: Positive. Several sites have requested this 
functionality, which motivated the spec change. They continue to want 
it and have done so for quite a while now.



WebView application risks

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


No.



Debuggability

Not really. This causes the browser UI to switch emphasis, but doesn't 
other change any site-observable behaviour.



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


On Android & Android WebView, support would require changes to other 
components: the android.credentials code in the framework and, for 
older Android versions, Play Services. That might come in the future, 
but it's not part of the Blink and Chrome work. (The Blink change is, 
of course, required for anything else in the system to be able to 
handle this parameter.)



Some versions of Windows handle WebAuthn UI themselves and, while 
Chrome can change it's UI, this parameter won't immediately change the 
Windows UI. However, Microsoft is positive about this change and 
Chromium will be updated to pass this parameter on as soon as the 
Windows API is able to receive it.




Is this feature fully tested by web-platform-tests

?

No

Hints only affect the browser UI and unknown parameters are ignored in 
WebAuthn already.




Flag name on chrome://flags

None


Finch feature name

WebAuthenticationHints


Requires code in //chrome?

True: Chrome-specific WebAuthn UI is handled in //chrome and needs to 
respond to these hints. Other embedders would have to do the same to 
benefit from this change.



Estimated milestones

Shipping on desktop 128




Anticipated spec changes

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


None


Link to entry on the Chrome Platform Status

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


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

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

[Mike Taylor]

On 5/31/24 11:40 PM, Paul Jensen wrote:



Contact emails

pauljen...@chromium.org


Explainer

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




Specification

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




Summary

The Protected Audience API allows bidders to store information, called 
an interest group, from a single site in the browser that can only be 
read later in the context of an auction.  Today, interest groups can 
be updated by fetching new values from a server.  For all interest 
groups, the frequency of these updates is rate limited to at most once 
a day to conserve network traffic and avoid overwhelming servers.  
However, we've heard from developers that certain ad campaigns need 
much more timely updates.  During Protected Audience auctions, the 
browser fetches real-time signals from bidders' key-value servers.  
This proposal allows the response to these fetches to indicate a 
subset of interest groups they’d like updated more frequently than 
once a day.



Blink component

Blink>InterestGroups 




TAG review

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




TAG review status

Completed for Protected Audience, resolved unsatisfied.


Risks


Interoperability and Compatibility

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



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



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



Web developers:

Feature requested by Microsoft in GitHub issue 
.


I don't see any feedback from Microsoft on this design in the issue 
(just from Criteo, which seems inconclusive). Have they given feedback 
elsewhere?




Debuggability

Protected Audience trusted bidding signals show up in the DevTools 
Network pane. Updates show up in the Application -> Storage -> 
Interest Groups DevTools pane.



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

It will be supported on all platforms that support Protected Audience, 
so all but WebView.



Is this feature fully tested by web-platform-tests

?

Yes 
.



Flag name on chrome://flags

None


Finch feature name

InterestGroupUpdateIfOlderThan


Requires code in //chrome?

False


Estimated milestones

Shipping on desktop and Android in M125.


Anticipated spec changes

None


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5162656775536640 




This intent message was generated by Chrome Platform Status 
.


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


--
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/256a1685-16cb-4bda-beb3-8492e863cb29%40chromium.org.

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

[Mike Taylor]

On 6/4/24 6:26 AM, 'Kagami Rosylight' via blink-dev wrote:

> /Gecko/: Closed Without a Position 
(https://github.com/mozilla/standards-positions/issues/143)


It looks like it's closed with position: "worth prototyping", though? 
Or is there another issue that is closed without position?


I can see why that's confusing - it's labelled as "proposal appears 
stale", but if you follow the linked PR 
https://github.com/mozilla/standards-positions/pull/480 you can get to 
the actual resolution.




On Monday, June 3, 2024 at 6:04:03 PM UTC+2 dad...@google.com wrote:


Contact emails

l...@chromium.org


Explainer

None


Specification

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


Summary

We propose to block access to IP address 0.0.0.0 in advance of PNA
completely rolling out. Chrome is deprecating direct access to
private network endpoints from public websites as part of the
Private Network Access (PNA) specification
(https://developer.chrome.com/blog/private-network-access-preflight/).
Services listening on the localhost (127.0.0.0/8
) are considered private according to the
specification
(https://wicg.github.io/private-network-access/#ip-address-space-heading).
Chrome's PNA protection (rolled out as part of
https://chromestatus.com/feature/5436853517811712) can be bypassed
using the IP address 0.0.0.0 to access services listening on the
localhost on macOS and Linux. This can also be abused in DNS
rebinding attacks targeting a web application listening on the
localhost. Since 0.0.0.0 is not used in practice (and should not
be used), but was overlooked during
https://chromestatus.com/feature/5436853517811712, we're
deprecating it separately from the rest of the private network
requests deprecation. This will be a Finch (experimental) rollout,
rather than a Developer Trial.



Blink component

Blink>SecurityFeature>CORS>PrivateNetworkAccess




Search tags

security ,
Private Network Access



TAG review

None


TAG review status

Not applicable


Chromium Trial Name

PrivateNetworkAccessNullIpAddressAllowed


Origin Trial documentation link

https://crbug.com/1300021


WebFeature UseCounter name

kPrivateNetworkAccessNullIpAddress


Risks



Interoperability and Compatibility

None



/Gecko/: Closed Without a Position
(https://github.com/mozilla/standards-positions/issues/143)

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

/Web developers/: No signals

/Other signals/:


WebView application risks

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

None



Goals for experimentation



Ongoing technical constraints

Eventually, all private network access will be limited according
to the developing Private Network Access spec.



Debuggability

None



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

Yes


Is this feature fully tested by web-platform-tests

?

No


Flag name on chrome://flags

block-null-ip-address


Finch feature name

PrivateNetworkAccessNullIpAddress


Requires code in //chrome?

False


Tracking bug

https://crbug.com/1300021


Estimated milestones

Shipping on desktop 133
Origin trial desktop first  127
Origin trial desktop last   133
DevTrial on desktop 127

Shipping on Android 133
OriginTrial Android last133
OriginTrial Android first   127
DevTrial on Android 127

Shipping on WebView 133
OriginTrial webView last133
OriginTrial webView first   127



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5106143060033536

This intent message was generated by Chrome Platform Status
.

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

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

[Mike Taylor]

LGTM3

On 5/31/24 4:08 AM, Yoav Weiss (@Shopify) wrote:

LGTM2

On Fri, May 31, 2024 at 5:52 AM 'Jiaming Cheng' via blink-dev 
 wrote:


Thanks Domenic :]

On Thu, May 30, 2024 at 6:28 PM Domenic Denicola
 wrote:

LGTM1.

This feature and its spec fits well with the existing
MediaMetadata. It has received a positive position from
Mozilla. The TAG review solicited a good discussion of
considered alternatives.

I agree with Alex that this would have gone better with a
proper explainer, including considered alternatives and
example code. But the feature is simple enough, and thankfully
we got a chance to spell out the reasoning about alternatives
in the TAG review, so I think we can proceed.

On Saturday, May 18, 2024 at 1:53:09 AM UTC+9 Alex Russell wrote:

Sorry for the slow reply here.

Glad to see this works for Audio too. This might have been
a bit more obvious of there were an explainer in the usual
format. I expect the TAG will ask for one of those too.
Please pay particular attention to considered alternatives
and example code, both for the proposed design and for
discarded alternatives.

https://w3ctag.org/explainers/

Best,

Alex

On Wednesday, May 15, 2024 at 12:14:18 PM UTC-7 Jiaming
Cheng wrote:

Thanks Domenic and Mike for the reply!

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

Best,
Jiaming

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

Hi Jiaming,

Per our process

,
we give the TAG and other vendors at least one
month to comment on changes. (This is why it is
recommended to start these reviewers earlier,
before sending the Intent to Ship.) So it might be
a bit more time before we can consider this
feature for shipping. Of course, if you get
responses and engagement before that point, we can
proceed earlier.

-Domenic

On Tuesday, May 14, 2024 at 11:06:55 AM UTC+9
Jiaming Cheng wrote:

Hi team,

Those reviews have been posted for 10 days,
there's no opposing comments on any of them so
far. Could you please take another look at
this intent?

Let me know if you have any further questions
or concerns.

Thanks,
Jiaming

On Fri, May 3, 2024 at 6:25 PM Jiaming Cheng
 wrote:

Hi Alex, Chris and Daniel,

Thank you for your valuable feedback!

I've addressed your comments and taken the
following updates:

Hey Alex, the ChapterInformation *does*
apply to audio as well as video, since
MediaSession is for both audio and video.
I've updated the Chrome status to reflect
this.

Additionally, I've taken the following
actions:

  * Added WPT test:

https://chromium-review.googlesource.com/c/chromium/src/+/5516503

  * Filed TAG review:

https://github.com/w3ctag/design-reviews/issues/952
  * Filed WebKit review:

https://github.com/WebKit/standards-positions/issues/344
  * Filed Gecko review:

https://github.com/mozilla/standards-positions/issues/1019



I will keep you updated on the progress of
these reviews and notify you once they are
approved. Let me know if you have any
questions :]

Best,
Jiaming

On Wed, May 1, 2024 at 8:57 AM Alex
  

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

[Mike Taylor]

LGTM3

On 5/31/24 4:07 AM, Yoav Weiss (@Shopify) wrote:

LGTM2

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


In that case, LGTM1.

On Fri, May 31, 2024 at 2:31 PM François Beaufort
 wrote:



On Fri, May 31, 2024 at 3:16 AM Domenic Denicola
 wrote:



On Thursday, May 30, 2024 at 1:34:03 PM UTC+9
fbea...@google.com wrote:

Contact emailsfbeauf...@google.com

ExplainerNone


Specificationhttps://gpuweb.github.io/gpuweb/#dom-gpuadapter-info


Summary

Functionality added to the WebGPU spec after its first
shipment in a browser. Adds a synchronous GPUAdapter
info attribute to retrieve the same information about
the physical adapter as with the asynchronous
GPUAdapter requestAdapterInfo() method. A separate
Intent will be sent to deprecate and remove the
asynchronous GPUAdapter requestAdapterInfo() method.



Blink componentBlink>WebGPU



TAG reviewNone

TAG review statusNot applicable

Risks


Interoperability and Compatibility

The GPUAdapter info attribute has not yet been
implemented in any browser. It has been approved by
the GPU for the Web Community Group, with
representatives from Chrome, Firefox, and Safari. See
minutes at

https://github.com/gpuweb/gpuweb/wiki/GPU-Web-2024-05-22#add-synchronous-gpuadapterinfo-4550






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


/WebKit/: Closed Without a Position

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

)

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

/Other signals/:

WebView application risks

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

None



Debuggability

None



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

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



Is this feature fully tested by web-platform-tests

?Yes


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



Flag name on chrome://flagsNone

Finch feature nameNone


Per

https://chromium.googlesource.com/chromium/src/+/main/docs/flag_guarding_guidelines.md#when-is-a-flag-required
, a feature flag is required for any web platform addition.


We'll have a blink runtime feature flag named
"WebGPUAdapterInfoAttribute" for this.
Thanks for catching Domenic!



Non-finch justificationNone

Requires code in //chrome?False

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


Estimated milestonesShipping on desktop127Shipping on
Android127Shipping on WebView127

Anticipated spec changes

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

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

[Mike Taylor]

Thanks Domenic - I agree.

On 5/30/24 9:31 PM, Domenic Denicola wrote:

LGTM for a new OT from 127 to 129.

(Speaking generally, I think starting new OTs is better than extending 
existing ones, so I am glad the team has taken this route. From an 
ecosystem perspective, new OTs make it easier for the team to make 
breaking changes, and encourages OT participants to continually 
re-engage with the process.)


On Friday, May 31, 2024 at 10:07:00 AM UTC+9 jrob...@google.com wrote:

Mike or other API Owners, still approved given that this is
actually requesting a new OT?

Thanks,
jason!

On Wednesday, May 29, 2024 at 5:10:54 PM UTC-7 Tsuyoshi Horo wrote:

Ah, sorry for the confusion.

This request is for the V3 Origin Trial.

V1 OT was from 117 to 122.
V2 OT was from 122 to 125.
And this V3 OT is from 127 to 129.


On Thu, May 30, 2024 at 8:32 AM Patrick Meenan
 wrote:

Sorry, probably some confusion with the process.

This is for the 3rd round of OT on the platform status
entry (CompressionDictionaryTransportV3) so "extend" may
not be the right terminology.  V1 really ended at 122 and
we had the same confusion the last time around and the V2
trial was created that went from 123-125 (and is the
current active trial).

I'll leave it to Tsuyoshi so I don't accidentally break
anything, but I assume we need to mark the v3 trial as the
active stage.

On Wed, May 29, 2024 at 7:16 PM Panos Astithas
 wrote:

Hi Tsuyoshi,

Is this a request to extend the V1 OT as it appears in
Chromestatus and in the title of this thread or are
you trying to create a new V3 trial as it seems to be
the intent based on the content of your intent? Note
that V1 ended at M125, so teh extension would be for 4
milestones.

On Wed, May 29, 2024 at 10:22 AM Mike Taylor
 wrote:

Thanks all. LGTM to extend from 127 to 129 inclusive.

On 5/29/24 10:51 AM, Patrick Meenan wrote:


On the spec side of things, there is one more
issue outstanding in the IETF discussion but it's
not API-impacting and we expect that this latest
draft

<https://datatracker.ietf.org/doc/draft-ietf-httpbis-compression-dictionary/04/>,
which this OT implements, has the final API
shape. There will be some tweaks around the edges
as we go through the final steps of the RFC
process but the V3 OT will give sites something
to test against that matches what we expect to ship.

There are some fairly substantial changes from
the previous OT that it would be useful to get
feedback on. In particular, the change to the
file format that embeds the dictionary hash into
the file itself instead of being a separate
response header.

On Wed, May 29, 2024 at 10:37 AM Yoav Weiss
(@Shopify)  wrote:



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

Hi there,

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



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

Recently published

<https://datatracker.ietf.org/doc/draft-ietf-httpbis-compression-dictionary/> 
with
above-mentioned changes.
+Patrick Meenan can probably add precision
there, but it's making good progress in the
HTTPWG.

TAG review (see exceptions)

https://github.com/w3ctag/design-reviews/issues/877
<https://github.com/w3ctag/design-reviews/issues/877>


bit.ly/blink-signals
<http://bit.ly/blink-signals> requests

Both Mozilla

<https://github.com/mozilla/standards-positions/issues/771>
and WebKit

<https://github.com/WebKit/standards-positions/issues/160>
 

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

[Mike Taylor]

Thanks all. LGTM to extend from 127 to 129 inclusive.

On 5/29/24 10:51 AM, Patrick Meenan wrote:
On the spec side of things, there is one more issue outstanding in the 
IETF discussion but it's not API-impacting and we expect that this 
latest draft 
<https://datatracker.ietf.org/doc/draft-ietf-httpbis-compression-dictionary/04/>, 
which this OT implements, has the final API shape. There will be some 
tweaks around the edges as we go through the final steps of the RFC 
process but the V3 OT will give sites something to test against that 
matches what we expect to ship.


There are some fairly substantial changes from the previous OT that it 
would be useful to get feedback on. In particular, the change to the 
file format that embeds the dictionary hash into the file itself 
instead of being a separate response header.


On Wed, May 29, 2024 at 10:37 AM Yoav Weiss (@Shopify) 
 wrote:




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

Hi there,

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



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

Recently published

<https://datatracker.ietf.org/doc/draft-ietf-httpbis-compression-dictionary/> 
with
above-mentioned changes.
+Patrick Meenan <mailto:pmee...@google.com> can probably add
precision there, but it's making good progress in the HTTPWG.

TAG review (see exceptions)

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

bit.ly/blink-signals <http://bit.ly/blink-signals> requests

Both Mozilla
<https://github.com/mozilla/standards-positions/issues/771> and
WebKit <https://github.com/WebKit/standards-positions/issues/160>
are positive (with ongoing discussion about some details with
Mozilla folks).

Outreach for feedback from the spec community

Regular HTTPWG and WebPerfWG engagement.

WPT tests


https://wpt.fyi/results/fetch/compression-dictionary?label=experimental=master

<https://wpt.fyi/results/fetch/compression-dictionary?label=experimental=master>


thanks,
Mike

On 5/28/24 5:59 AM, Tsuyoshi Horo wrote:


Contact emails

h...@chromium.org, pmee...@chromium.org,
yoavwe...@chromium.org, kenjibah...@chromium.org,
denom...@chromium.org

*
*


Explainer

https://github.com/WICG/compression-dictionary-transport
<https://github.com/WICG/compression-dictionary-transport>

*
*


Specification


https://datatracker.ietf.org/doc/draft-ietf-httpbis-compression-dictionary/

<https://datatracker.ietf.org/doc/draft-ietf-httpbis-compression-dictionary/>

*
*


Design docs


https://docs.google.com/document/d/1IcRHLv-e9boECgPA5J4t8NDv9FPHDGgn0C12kfBgANg/edit

<https://docs.google.com/document/d/1IcRHLv-e9boECgPA5J4t8NDv9FPHDGgn0C12kfBgANg/edit>

https://github.com/WICG/compression-dictionary-transport
<https://github.com/WICG/compression-dictionary-transport>


https://datatracker.ietf.org/doc/draft-ietf-httpbis-compression-dictionary/

<https://datatracker.ietf.org/doc/draft-ietf-httpbis-compression-dictionary/>

*
*

Summary

We are running the second round of the Origin Trial until
Chrome 125. The design of the feature has also evolved during
the origin trial and RFC process. We’d like to run a third
round of the Origin Trial to get more feedback on the updated

<https://chromium.googlesource.com/chromium/src/+/d934bf37456735d9bc03107c577804f439f8a986/docs/experiments/compression-dictionary-transport.md#changes-in-m127>design.

*
*


Blink component

Blink>Network

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

*
*


TAG review

https://github.com/w3ctag/design-reviews/issues/877
<https://github.com/w3ctag/design-reviews/issues/877>


TAG review status

Closed


Risks


Interoperability and Compatibility

Interoperability and Compatibility risk are low. This feature
introduces a new compression method for transporting
resources over HTTP. Web sites can know the browser support
for the new feature by checking

`document.createElement('link').relList.supports('compression-dictionary')`. 
The feature is a negotiation between servers and clients that
involves a server specifying that a resource should be used
as a dictionary for future requests with a
‘Use-As-Dicti

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

[Mike Taylor]

LGTM1

On 5/24/24 3:13 PM, Yoav Weiss (@Shopify) wrote:



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




On Wed, May 22, 2024 at 2:16 AM Yoav Weiss (@Shopify)
 wrote:



On Wed, May 22, 2024 at 10:29 AM Yoav Weiss (@Shopify)
 wrote:



On Tuesday, May 21, 2024 at 1:04:44 PM UTC+2 Yoav Weiss wrote:

Contact emailsyoavwe...@chromium.org


Explainerhttps://github.com/guybedford/import-maps-extensions#integrity


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


The PR is ready to land, but we're holding off on that
for 2 weeks at Mozilla's request. See below.

Summary

Imported ES modules can't currently have their
integrity checked, and hence cannot run in
environments that require Subresource Integrity or
with `require-sri-for` CSP directives. This feature
adds an `integrity` section to import maps, enabling
developers to map ES module URLs to their integrity
metadata, and ensure they only load when they match
their expected hashes.



Blink componentBlink>Loader



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


TAG review statusIssues addressed

Risks


Interoperability and Compatibility

On the interoperability front, this got a positive
position from WebKit, and I'm implementing the feature
there .
Mozilla didn't object to the feature, but asked





I just realized that the meeting notes are not publicly viewable.
+Panos Astithas  - would you be
able to open them up to the public somehow? (e.g. as a
Chromium.org doc)


They were published


 that
same day, we try to post the minutes publicly in less than 24 hours.


Oops!! My bad for using the wrong artifact!

for a couple more weeks to evaluate it and provide a
position, as they might be planning broader-scope work
on the front of application integrity, and want to
make sure this doesn't collide with it.


On the compatibility front, the feature is polyfilled
,
but it's turned off for browsers that support import
maps

.


Adding Guy Bedford, the polyfill author to this
thread. Guy, can you confirm this is the case?


/Gecko/: No signal


/WebKit/: Support


WebKit PR 
has landed.



/Web developers/: Positive

This is based on a proposal from a developer (Guy
Bedford).
Multiple Shopify properties are interested in this, to
enable using ES modules as bundler output in security
sensitive environments. Asking about this on twitter
and mastodon showed that some developers are
interested in this, while others discount SRI in general.

/Other signals/:

Activation

As long as support is not ubiquitous, the `integrity`
part of import maps will be ignored in non-supporting
browsers, resulting in scripts loading in those
browsers even if they're supposed to fail their
integrity checks.

There's also a polyfill

that would enable sites to get integrity support for

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

[Mike Taylor]

Hi there,

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


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

TAG review (see exceptions)
bit.ly/blink-signals requests
Outreach for feedback from the spec community
WPT tests

thanks,
Mike

On 5/28/24 5:59 AM, Tsuyoshi Horo wrote:


Contact emails

h...@chromium.org, pmee...@chromium.org, yoavwe...@chromium.org, 
kenjibah...@chromium.org, denom...@chromium.org


*
*


Explainer

https://github.com/WICG/compression-dictionary-transport 



*
*


Specification

https://datatracker.ietf.org/doc/draft-ietf-httpbis-compression-dictionary/ 



*
*


Design docs

https://docs.google.com/document/d/1IcRHLv-e9boECgPA5J4t8NDv9FPHDGgn0C12kfBgANg/edit 



https://github.com/WICG/compression-dictionary-transport 



https://datatracker.ietf.org/doc/draft-ietf-httpbis-compression-dictionary/ 



*
*

Summary

We are running the second round of the Origin Trial until Chrome 125. 
The design of the feature has also evolved during the origin trial and 
RFC process. We’d like to run a third round of the Origin Trial to get 
more feedback on the updated 
design.


*
*


Blink component

Blink>Network 



*
*


TAG review

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




TAG review status

Closed


Risks


Interoperability and Compatibility

Interoperability and Compatibility risk are low. This feature 
introduces a new compression method for transporting resources over 
HTTP. Web sites can know the browser support for the new feature by 
checking 
`document.createElement('link').relList.supports('compression-dictionary')`.  
The feature is a negotiation between servers and clients that involves 
a server specifying that a resource should be used as a dictionary for 
future requests with a ‘Use-As-Dictionary’ response header. Clients 
that don’t support the feature will ignore the header and nothing 
further will happen.


This feature is an opt-in feature. And the dictionary storage is 
isolated using the top level site and the frame origin as the key. 
That means, if there is no dictionary registered for the site, the 
behavior of Chrome will not change while browsing the site. Also this 
feature is only usable within a secure-context so this feature will 
not increase the risk of having network proxies meddle with the 
content’s encoding. For enterprises that have deployed 
HTTPS-intercepting proxies that do not properly handle unknown 
encodings there is an enterprise policy exposed to disable the 
feature. The feature is currently enabled only over connections using 
a well-known trust root for the secure connection which eliminates the 
risk of security devices and proxies breaking traffic. The roll-out 
plan for production has steps to remove the trust root restriction and 
enable support in enterprise environments where intercepting proxies 
are common.


*
*

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


*
*

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


*
*

Web developers: Positive

*
*

Other signals:

*
*


Ergonomics

To reduce memory usage in network services, dictionary metadata is 
stored in a database on disk. And to avoid performance degradation for 
normal requests that do not use a dictionary, the reading of this 
metadata is designed not to block network requests. In other words, if 
the reading of metadata from the database is not completed before the 
request header is ready to be sent to the server, the dictionary may 
not be used even if it is already registered in the database.


*

*


Activation

To adopt this feature, web developers need to make changes in their 
web servers or build processes for static resources. Currently there 
is no major server software which directly supports compression 
dictionaries. Some CDNs have shared interest in supporting shared 
dictionary compression (e.g. publicly mentioned 

Re: [blink-dev] Intent to Ship: Unrestricted WebUSB (available only to Isolated Web Apps)

[Mike Taylor]

LGTM1 to ship this for IWAs only.

On 5/22/24 2:11 PM, Reilly Grant wrote:
LGTM as an IWA OWNER (3x LGTM from Blink API OWNERS are still required 
according to the IWA-specific API launch process 
).


This is a good example of IWA-specific behavior minimally extending an 
existing API and I think this approach strikes a good balance between 
capability and security.
Reilly Grant | Software Engineer |reil...@chromium.org |Google Chrome 




On Wed, May 22, 2024 at 10:08 AM 'Ajay Rahatekar' via blink-dev 
 wrote:



Contact emails

mattreyno...@chromium.org


Specification

https://wicg.github.io/webusb/#permissions-policy



Summary

Enables trusted applications to bypass security restrictions in
the WebUSB API.


The WebUSB specification defines a blocklist of vulnerable devices
and a table of protected interfaces classes that are blocked from
access through WebUSB. With this feature, Isolated Web Apps
(https://github.com/WICG/isolated-web-apps) with permission to
access the "usb-unrestricted" Permission Policy feature will be
allowed to access blocklisted devices and protected interface classes.



Blink component

Blink>USB



Search tags

usb , webusb
, unrestricted



TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

WebUSB is only implemented in Chromium-based browsers.



Gecko: No signal


WebKit: No signal


Web developers: No signals


Other signals:


WebView application risks

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

None



Debuggability

None



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

No

This feature is not available on Android because Isolated Web Apps
are not supported in Chrome for Android.



Is this feature fully tested by web-platform-tests

?

No, this feature is only available in Isolated Web Apps which are
not yet supported for web platform tests.


Flag name on chrome://flags

chrome://flags/#enable-unrestricted-usb


Finch feature name

UnrestrictedUsb


Requires code in //chrome?

False


Tracking bug

https://crbug.com/40783010 


Launch bug

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



Estimated milestones

Shipping on desktop



127


Anticipated spec changes

Open questions about a feature may be a source of future web
compat or interop issues. Please list open issues (e.g. links to
known 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/5106506475503616?gate=6251287998103552



Links to previous Intent discussions

Intent to prototype:

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHB%2BDAgOvR6ggk64OaEGkfJE%2BOsMh0jKjORBZ_LyN2Pdad%3Dg3w%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/CAHB%2BDAigp8dfbrCYbzs7A9W03%2BpCzZmu58p90tptrTtXh7bRrg%40mail.gmail.com

.

--
You received this message 

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

[Mike Taylor]

LGTM3, and +1 to Yoav's suggestion.

On 5/29/24 1:00 AM, Yoav Weiss (@Shopify) wrote:

LGTM2

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


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

> How should I interpret the results from your investigation? That
none of the 8 investigated sites would be negatively affected?

There is only one site which is actually affected:
https://resolv.com.br/
The buttons in the carousel there won't light up anymore, but they
will still work. I made sure of that based on the shape of the JS
portion of the new syntax. You can test this out in firefox
nightly or safari TP.

On Wed, May 22, 2024 at 9:22 AM Daniel Bratell
 wrote:

To be particular about the usage number, it's about a
magnitude more than our informal limit. That doesn't mean it
can't be shipped, but it means that we want to be fairly
certain that >90% of the users are unaffected by the change.

How should I interpret the results from your investigation?
That none of the 8 investigated sites would be negatively
affected?

/Daniel

On 2024-05-22 18:03, Vladimir Levin wrote:



On Tue, May 21, 2024 at 2:20 PM Joey Arhar
 wrote:

> Do you know what the breakage looks like

I pushed to make sure that using the old syntax with
CustomStateSet.add() wouldn't throw exceptions when in
the new mode in order to reduce breakage. When websites
use the old syntax after it's removed, they will just
have styling differences because their selectors won't
parse anymore.

> or whether this usage is limited to a library/a small
set of large websites or something else?

Based on the analysis that I linked in the previous
thread

,
there are some websites which all look very similar which
use it, but they are all hidden behind display:none
elements that I had to manually reveal. There was only
one website I found which was actually using it which has
a carousel which has buttons that didn't work in safari
and firefox because CustomStateSet didn't exist yet.

I don't think there is a popular library which is using
the deprecated syntax.

> Ideally, this is feature detected with some fallback syntax

Websites just have to replace ":--foo" with
":state(foo)", I don't think any feature detection is
necessary. If they are interested in supporting older
browsers, then I don't see why they would have any
interest in looking at whether the deprecated syntax
works or not because the other browsers didn't have it
before and neither did we until a couple years ago.


I meant I hope that existing use is either feature-detected
or it's using both properties. In either case, it's very easy
to fix if problems arise since alternate syntax is shipped
already in multiple browsers.

LGTM1


On Tue, May 21, 2024 at 11:09 AM Vladimir Levin
 wrote:

Hey,

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

Ideally, this is feature detected with some fallback
syntax


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


Contact emails


jar...@chromium.org


Explainer


None


Specification


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


Summary


The CSS custom state pseudo-class is
being renamed from :--foo to :state(foo).
The new syntax, :state(foo), has been
enabled by default, and now we have to
deprecate and remove the :--foo syntax.
Gecko and webkit never implemented the
old syntax and they have both shipped the
new syntax. We are currently shipping
both the new syntax and the old syntax at
the same time. There have been console

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

[Mike Taylor]

LGTM3

On 5/29/24 4:34 AM, Yoav Weiss (@Shopify) wrote:

LGTM2

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

LGTM1

On Tue, May 21, 2024 at 3:07 PM 'Erik Anderson' via blink-dev
 wrote:

Hi,

Thanks for reaching out.

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

Thanks,

Erik

*From:*Paul Jensen 
*Sent:* Friday, May 17, 2024 5:42 AM
*To:* Yoav Weiss (@Shopify) 
*Cc:* blink-dev ; Erik Anderson

*Subject:* Re: Intent to Ship: Protected Audience: reporting
timeouts & multiple-bids

Actually CC Erik this time.

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

On Wed, May 15, 2024 at 8:36 AM Yoav Weiss (@Shopify)
 wrote:

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

Contact emails

pauljen...@chromium.org

Explainer

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


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


Please fix the explainer 
 to 
remove the "in Chrome" part from the feature detection reference.


Specification

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


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


Summary

Protected Audience (PA) reporting timeouts:

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

I'm concerned about this timeout, tbh.

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

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

I think configurability is useful here for a few reasons:

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

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

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

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

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

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

It’s set by whoever is 

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

[Mike Taylor]

Thanks all - the renewed deprecation trial is live now. We renamed it to 
DisableThirdPartyStoragePartitioning2 to work around some internal 
limitations (and to show off our creative re-naming abilities).


Qualified origins can apply for registration here:
https://developer.chrome.com/origintrials/#/view_trial/568016503002103809

blog post:
https://developers.google.com/privacy-sandbox/blog/storage-partitioning-deprecation-trial-renewal 



Note that there are still a few weeks left to register for the original 
DT, which would qualify an origin for the extension.


On 5/22/24 11:58 AM, Yoav Weiss (@Shopify) wrote:

LGTM to extend the deprecation trial M127-M132 inclusive

On Wed, May 22, 2024 at 4:44 PM Mike Taylor  
wrote:


On 5/22/24 8:11 AM, Yoav Weiss (@Shopify) wrote:




On Tue, May 21, 2024 at 8:55 PM Mike Taylor
 wrote:

**


*Contact emails*

*

miketa...@chromium.org


Explainer


https://github.com/wanderview/quota-storage-partitioning/blob/main/explainer.md

<https://github.com/wanderview/quota-storage-partitioning/blob/main/explainer.md>


Specification

None


Summary

We shipped “storage partitioning” in Chrome 115, and a
Deprecation Trail

<https://developer.chrome.com/origintrials/#/view_trial/-8517432795264450559>(DT)
beginning in M113 that is set to expire in M126. There are
also enterprise policies available:


https://chromeenterprise.google/policies/#DefaultThirdPartyStoragePartitioningSetting

<https://chromeenterprise.google/policies/#DefaultThirdPartyStoragePartitioningSetting>


https://chromeenterprise.google/policies/#ThirdPartyStoragePartitioningBlockedForOrigins

<https://chromeenterprise.google/policies/#ThirdPartyStoragePartitioningBlockedForOrigins>


We are requesting a renewal for 6 milestones (M127 - M132
inclusive) for the DisableThirdPartyStoragePartitioning

<https://developer.chrome.com/origintrials/#/view_trial/-8517432795264450559>DT
(but notthe
DisableThirdPartySessionStoragePartitioningAfterGeneralPartitioning

<https://developer.chrome.com/origintrials/#/view_trial/3444127815031586817>DT).


Since we shipped the first Deprecation Trial, we have also
shipped the non-cookie storage extension to SAA

<https://groups.google.com/a/chromium.org/g/blink-dev/c/F5EV8I-j7Eg/m/OAi7lcykAAAJ>(M125+)
to address sites impacted by storage partitioning. We are
confident this API extension will address the majority of
“unpartitioned” storage use cases, however, we are aware of a
few partners with slightly different use cases that we are
currently exploring API solutions for.


Our near-term goal is to have this Deprecation Trial expire
and migrate the platform to partitioned-by-default 3rd party
storage, communications APIs, and service workers, especially
ahead of 3rd party cookie deprecation. Given that, we propose
to only allow an extension for sites that have already
enrolled in the current non-expired Deprecation Trial, taking
advantage of the new OT registration approval workflow.

*


That's exciting! Are there numbers you can share regarding the
current participants? Is it realistic to expect the 6 milestone
renewal to be the last one?


Sure thing - we have on the order of 600 registrants, but if you
de-dupe the list that takes you down to about 400. Further
removing localhost, or staging or obvious test domains (stuff like
"https://testing-this-ot.vercel.app;
<https://testing-this-ot.vercel.app>, we're down to ~300. My
hand-wavey guess is the majority of these will be served by the
non-cookie SAA stuff we shipped, or have already resolved their
need to use the OT.

Will this be the last renewal? Hard to predict the future, but if
we do find ourselves in that bucket I would like to craft it in
such a way to continue to narrow the funnel further than we are
right now, especially to avoid timeline contention and
side-channels with 3PCD.



*

We will respond to this intent with a link to a blog post
once the renewal process is in place.


Blink component

Blink>Storage

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


TAG review

Early Design Review
https://github.com/w3ctag/design-reviews/issues/629
<https://github.com/w3ctag/design-reviews/issues/629>


TAG review status

Resolution Satisfied


Chromium Trial Name

DisableThirdPartyStoragePartitioning


Origin Trial documentation l

Re: [blink-dev] Intent to Ship: CSS font-size-adjust with the two-value syntax

[Mike Taylor]

LGTM2

On 5/23/24 12:06 PM, Philip Jägenstedt wrote:

Thank you for looking into the test failures, ChangSeok!

LGTM1 to align with Firefox and Safari on the remaining failures 
(except the reftests with minor pixel differences) and shipping!


On Wed, May 22, 2024 at 10:05 PM ChangSeok Oh  
wrote:


Hi Dominik,

Thanks for your add-up! And Yes, we can align with other browsers
for the time being.

--
ChangSeok

> On May 21, 2024, at 6:13 AM, Dominik Röttsches
 wrote:
>
> Big thanks ChangSeok for implementing this and pushing for this
feature.
>
> I can say a few things about the open issues
>  - https://github.com/w3c/csswg-drafts/issues/6384
>
> font-size-adjust relies on a font metric reference point, for
example, the x-height, cap-height, etc. in order to scale font
sizes to match on a scaled metric.
> Strictly speaking in the OpenType font spec, some metrics that
are spec'ed for font-size-adjust are optional in the font file.
They might not exist in the font file.
> The discussion in this issue revolves around what to do when the
metric does not exist: There are mainly two alternatives:
> a) don't adjust anything, b) adjust to a heuristic that tries to
approximate the missing value.
>
> From an interop point of view: a) is interoperable, b) is not
interoperable without spec changes in the CSS values spec to
tighten the heuristics.
> For Interop 2024, I think we can and should only test and
consider the happy path, in which the font has the metrics.
>
> The missing metrics situation can be considered a somewhat rare
edge case.
>
> - https://github.com/w3c/csswg-drafts/issues/10292
>
> This discussion is about the computed style of font-size-adjust
and whether that should "leak" actual values that come from the
font files. If I am not mistaken, FF and Safari are currently
aligned on doing that and making the computed style show values
from the font files, in order to inherit a meaningful numerical
value in the cascade. There are arguments for why this is the
right approach from a functionality point of view. Whether it's
the right approach from a CSS inheritance / logical point of view
is perhaps the question. I am not sure about WPT test coverage at
the moment (it's likely small), but for the time being I believe
we can align with Safari and FF. ChangSeok, do you agree?
>
> Dominik
>
>
> On Tue, May 21, 2024 at 3:43 PM Philip Jägenstedt
 wrote:
> Hi ChangSeok,
>
> Thank you for working on this, it's great to see both more
powerful typography control, and progress on Interop 2024.
>
> Can you say something about the remaining failures in WPT?
font-size-adjust-012.html font-size-adjust-013.html both look like
minor differences, but it seems like it only happens on Linux
(Chrome) and not Windows (Edge)?
>
> There are also 3 failing subtests in
font-size-adjust-computed.html, does that depend on resolving one
of the spec issues? Or can we match what Firefox and Safari do and
pass the tests without waiting for spec changes?
>
> Best regards,
> Philip
>
> On Thu, May 16, 2024 at 5:01 PM Vladimir Levin
 wrote:
>
>
> On Thu, May 16, 2024 at 10:02 AM ChangSeok Oh
 wrote:
> Contact emails
> changseok...@bytedance.com, changs...@chromium.org
>
> Explainer
> None
>
> Specification
> https://www.w3.org/TR/css-fonts-5/#font-size-adjust-prop
>
> Summary
> The font-size-adjust CSS property enhances readability
consistency by adjusting font size based on lowercase letter
height rather than uppercase. Additionally, the newly introduced
two-value syntax for font-size-adjust in the font module level 5
enables web designers to specify a font metric for size
adjustment. This feature is one of focus areas for Interop 2024.
>
> Blink component
> Blink>CSS, Blink>Fonts
>
> TAG review
> None
>
> TAG review status
> Not applicable
>
> Risks
> Interoperability and Compatibility
> Gecko and WebKit have shipped this feature, and there is no
major interoperability risk. However, certain aspects are still
being discussed regarding interoperability concerns. [1, 2].
> [1] https://github.com/w3c/csswg-drafts/issues/6384 [2]
https://github.com/w3c/csswg-drafts/issues/10292
>
> Gecko: Shipped/Shipping
(https://bugzilla.mozilla.org/show_bug.cgi?id=1711479)
>
> WebKit: Shipped/Shipping
(https://bugs.webkit.org/show_bug.cgi?id=254191)
>
> 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

Re: [blink-dev] Intent to Experiment: Keyboard-focusable scroll containers Opt Out

[Mike Taylor]

Thanks Di - this is a useful clarification.

You can request up to 6 milestones for a Deprecation Trial, and only 
need a single LGTM. Renewals are possible, with sufficient justification.


That said, if you do think that 9 milestones is sufficient for your 
needs - that is also possible, but will require 3 LGTMs. If that is the 
route you would like to propose, can your let us know why you think 9 
milestones is sufficient, and wouldn't require a renewal? What outreach 
or comms plans do you have in place to ensure that the previously broken 
sites will be ready for this change in ~9 months?


Either way, please let us know how many (and which) milestonesyou are 
requesting for the deprecation trial.


thanks!
Mike

On 5/13/24 2:27 PM, Di Zhang wrote:


Sorry for missing information! I haven’t created a request for a 
Deprecation Trial before, which is what I intended this to be, and I 
missed some parts of the process. The chromestatus is located here, 
which is for the overall KeyboardFocusableScrollers feature: 
https://chromestatus.com/feature/5231964663578624 
<https://chromestatus.com/feature/5231964663578624>. The origin trial 
section details why we are requesting a Deprecation trial for this 
feature, which I’ve copied below. I believe this answers the questions 
I’ve received here, but please let me know if anything else is missing!


Summary

The feature KeyboardFocusableScrollers changes the focusability of a 
scroll container. This feature includes the following changes:


 *

Scrollers are click-focusable and programmatically-focusable by
default.

 *

Scrollers without focusable children are keyboard-focusable by
default.

This is an important improvement to help make scrollers and contents 
within scrollers more accessible to all users.



We attempted to ship the above changes, and found that a limited 
number of sites had broken expectations around some of their 
components. As a result, we had to unship the feature to avoid this 
breakage. However, given the benefits mentioned above, we’d like to 
ship this feature again.


To allow more time for the affected sites to migrate their components, 
we are requesting a Deprecation Trial. This trial (called 
“KeyboardFocusableScrollersOptOut”), when enabled, will disablethe 
KeyboardFocusableScrollers feature. To give adequate time, we’d like 
to let this deprecation trial run for 9 months. It might be ok to 
limit this to 6-months, but would like the option to extend the 
depreciation period if needed.


On Friday, May 10, 2024 at 12:38:47 PM UTC-7 Vladimir Levin wrote:

On Fri, May 10, 2024 at 2:18 PM Mike Taylor
 wrote:

Is there a chromestatus entry associated with this intent?
There's a lot of information missing from this Intent (see

https://groups.google.com/a/chromium.org/g/blink-dev/c/LwgSKPBivuM/m/0dRsXWhBAgAJ

<https://groups.google.com/a/chromium.org/g/blink-dev/c/LwgSKPBivuM/m/0dRsXWhBAgAJ>
as what is typical) - could you reply with the missing info?

(Did you use ChromeStatus to generate the email?)

Also note that origin trials can only run for 6 milestones
initially (see
https://www.chromium.org/blink/launching-features/#origin-trials
<https://www.chromium.org/blink/launching-features/#origin-trials>)
- or are you requesting a deprecation trial?

FWIW, according to
https://www.chromium.org/blink/launching-features/#deprecation-trial
<https://www.chromium.org/blink/launching-features/#deprecation-trial>,
deprecation trials also only run for up to 6 milestones before
extensions

On 5/10/24 12:36 PM, Di Zhang wrote:

Contact emails

dizha...@chromium.org

dom-...@google.com


*Experiment Goals*The feature KeyboardFocusableScrollers
changes the focusability of a a scroll container. This is an
important improvement to help make scrollers and contents
within scrollers more accessible to all users. The goal of
this experiment is to collect feedback on this change from
users who might depend on the previous behavior (when a
scroller is not focusable by default) and help them adapt to
the new behavior which will ship in M126. Sites can use this
Origin Trial to opt out of the KeyboardFocusableScrollers
feature.
*Experiment Risks*This experiment is to allow users to
opt-out of the feature KeyboardFocusableScrollers. There is
no risk to loss access to any important API or other
functionality.
*Ongoing Constraints*None


OT desktop start126OT desktop end135OT Android start126OT
Android end135OT WebView startN/AOT WebView endN/A


*Note: *The Intent to Ship for Keyboard Focusable Scrollers:

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

<https://groups.

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

[Mike Taylor]

I'm inclined to LGTM this now - but don't see a lot of harm waiting for 
1 additional week (per Mozilla's request in the not-public minutes). 
Happy to do so before, so long as the HTML PR lands.


On 5/22/24 5:15 AM, Yoav Weiss (@Shopify) wrote:



On Wed, May 22, 2024 at 10:29 AM Yoav Weiss (@Shopify) 
 wrote:




On Tuesday, May 21, 2024 at 1:04:44 PM UTC+2 Yoav Weiss wrote:

Contact emailsyoavwe...@chromium.org

Explainerhttps://github.com/guybedford/import-maps-extensions#integrity


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


The PR is ready to land, but we're holding off on that for 2
weeks at Mozilla's request. See below.

Summary

Imported ES modules can't currently have their integrity
checked, and hence cannot run in environments that require
Subresource Integrity or with `require-sri-for` CSP
directives. This feature adds an `integrity` section to import
maps, enabling developers to map ES module URLs to their
integrity metadata, and ensure they only load when they match
their expected hashes.



Blink componentBlink>Loader



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


TAG review statusIssues addressed

Risks


Interoperability and Compatibility

On the interoperability front, this got a positive position
from WebKit, and I'm implementing the feature there
. Mozilla didn't
object to the feature, but asked





I just realized that the meeting notes are not publicly viewable.
+Panos Astithas  - would you be able to 
open them up to the public somehow? (e.g. as a Chromium.org doc)


for a couple more weeks to evaluate it and provide a position,
as they might be planning broader-scope work on the front of
application integrity, and want to make sure this doesn't
collide with it.


On the compatibility front, the feature is polyfilled
, but
it's turned off for browsers that support import maps

.


Adding Guy Bedford, the polyfill author to this thread. Guy,
can you confirm this is the case?


/Gecko/: No signal


/WebKit/: Support


WebKit PR  has landed.



/Web developers/: Positive

This is based on a proposal from a developer (Guy Bedford).
Multiple Shopify properties are interested in this, to enable
using ES modules as bundler output in security sensitive
environments. Asking about this on twitter and mastodon showed
that some developers are interested in this, while others
discount SRI in general.

/Other signals/:

Activation

As long as support is not ubiquitous, the `integrity` part of
import maps will be ignored in non-supporting browsers,
resulting in scripts loading in those browsers even if they're
supposed to fail their integrity checks.

There's also a polyfill
 that
would enable sites to get integrity support for ES modules in
browsers that don't support import maps at all. That's an
increasingly slim part of the browser population.



WebView application risks

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


None



Debuggability

No issues in particular. The feature does emit a few console
errors in cases where parsing fails, to help developers debug
this.



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

Is this feature fully tested by web-platform-tests

Re: [blink-dev] Intent to Ship: Unrestricted WebUSB (available only to Isolated Web Apps)

[Mike Taylor]

Could you please request the various Privacy, Security, Enterprise, etc. 
review gates in your chromestatus entry?


On 5/22/24 1:08 PM, 'Ajay Rahatekar' via blink-dev wrote:



Contact emails

mattreyno...@chromium.org


Specification

https://wicg.github.io/webusb/#permissions-policy 




Summary

Enables trusted applications to bypass security restrictions in the 
WebUSB API.



The WebUSB specification defines a blocklist of vulnerable devices and 
a table of protected interfaces classes that are blocked from access 
through WebUSB. With this feature, Isolated Web Apps 
(https://github.com/WICG/isolated-web-apps) with permission to access 
the "usb-unrestricted" Permission Policy feature will be allowed to 
access blocklisted devices and protected interface classes.




Blink component

Blink>USB 




Search tags

usb , webusb 
, unrestricted 




TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

WebUSB is only implemented in Chromium-based browsers.



Gecko: No signal


WebKit: No signal


Web developers: No signals


Other signals:


WebView application risks

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


None



Debuggability

None



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

No

This feature is not available on Android because Isolated Web Apps are 
not supported in Chrome for Android.




Is this feature fully tested by web-platform-tests

?

No, this feature is only available in Isolated Web Apps which are not 
yet supported for web platform tests.



Flag name on chrome://flags

chrome://flags/#enable-unrestricted-usb


Finch feature name

UnrestrictedUsb


Requires code in //chrome?

False


Tracking bug

https://crbug.com/40783010 


Launch bug

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




Estimated milestones

Shipping on desktop



127


Anticipated spec changes

Open questions about a feature may be a source of future web compat or 
interop issues. Please list open issues (e.g. links to known 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/5106506475503616?gate=6251287998103552 




Links to previous Intent discussions

Intent to prototype: 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHB%2BDAgOvR6ggk64OaEGkfJE%2BOsMh0jKjORBZ_LyN2Pdad%3Dg3w%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/CAHB%2BDAigp8dfbrCYbzs7A9W03%2BpCzZmu58p90tptrTtXh7bRrg%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/22386875--4441-b722-10c5ddaac94e%40chromium.org.

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

[Mike Taylor]

Yes, agree. Can we please request a position from Mozilla at 
https://github.com/mozilla/standards-positions/issues/new?


On 5/22/24 6:43 PM, 'Daniel Clark' via blink-dev wrote:


Yeah, that’s what I was trying to get at – the Intent implies that 
Gecko has also shipped the breaking change but it seems that might not 
be the case.


If not, we should send a Request for Position to figure out whether 
there would be cross-browser alignment on shipping this.


-- Dan

*From:*Olli Pettay 
*Sent:* Wednesday, May 22, 2024 9:53 AM
*To:* blink-dev 
*Cc:* Daniel Clark ; Shuangshuang Zhou 

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





You don't often get email from opet...@mozilla.com 
. Learn why this is important 





I think it is because of this rather surprising non-backwards 
compatible recent change.


On Wednesday, May 22, 2024 at 7:28:45 PM UTC+3 Daniel Clark wrote:

The Gecko status is marked as Shipped/Shipping and the
Interop/Compat section mentions Firefox having shipped this, but
Firefox is still failing the WPTs at

https://wpt.fyi/results/selection/onselectionchange-on-distinct-text-controls.html

.

Can you help me understand the discrepancy there?

Thanks,

Dan

*From:*blin...@chromium.org  *On Behalf Of
*Shuangshuang Zhou
*Sent:* Tuesday, May 21, 2024 10:24 PM
*To:* blink-dev 
*Subject:* [blink-dev] Intent to Ship: Dispatch selectionchange
event per element




You don't often get email from shuangsh...@intel.com. Learn why
this is important 



*Contact emails*shuangsh...@intel.com

*Explainer*None

*Specification*https://w3c.github.io/selection-api/#selectionchange-event


*Summary*

Dispatches selectionchange event per element when this
element(input/textarea) provides a text selection or its selection
changes. This is to match the latest specification of
selectionchange event. This also matches Safari behavior.



*Blink component*Blink>Editing>Selection



*TAG review*None

*TAG review status*Issues addressed

*Risks*



*Interoperability and Compatibility*

Interoperability risk is low because Firefox and Safari have
shipped this according to the specification. Compatibility risk is
low because the selectionchange event targeting input/textarea
would bubble up, and existing codes listening on Document will
work well as ever.



/Gecko/: Shipped/Shipping

/WebKit/: Shipped/Shipping (https://commits.webkit.org/276238@main
)

/Web developers/: No signals

/Other signals/:

*WebView application risks*

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

Low WebView application risks.



*Debuggability*

None



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

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

*?*Yes



https://wpt.fyi/results/selection/onselectionchange-on-distinct-text-controls.html





*Flag name on chrome://flags*None

*Finch feature name*DispatchSelectionchangeEventPerElement

*Requires code in //chrome?*False

*Tracking bug*https://issues.chromium.org/issues/330766600


*Estimated milestones*
Shipping on desktop
127

*Anticipated spec changes*

/Open questions about a feature may be a source of future web
compat or interop issues. Please list open issues (e.g. links to
known 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/5255454895898624?gate=6043023317401600


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 

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

[Mike Taylor]

On 5/22/24 8:11 AM, Yoav Weiss (@Shopify) wrote:




On Tue, May 21, 2024 at 8:55 PM Mike Taylor  
wrote:


**


*Contact emails*

*

miketa...@chromium.org


Explainer


https://github.com/wanderview/quota-storage-partitioning/blob/main/explainer.md

<https://github.com/wanderview/quota-storage-partitioning/blob/main/explainer.md>


Specification

None


Summary

We shipped “storage partitioning” in Chrome 115, and a Deprecation
Trail

<https://developer.chrome.com/origintrials/#/view_trial/-8517432795264450559>(DT)
beginning in M113 that is set to expire in M126. There are also
enterprise policies available:


https://chromeenterprise.google/policies/#DefaultThirdPartyStoragePartitioningSetting

<https://chromeenterprise.google/policies/#DefaultThirdPartyStoragePartitioningSetting>


https://chromeenterprise.google/policies/#ThirdPartyStoragePartitioningBlockedForOrigins

<https://chromeenterprise.google/policies/#ThirdPartyStoragePartitioningBlockedForOrigins>


We are requesting a renewal for 6 milestones (M127 - M132
inclusive) for the DisableThirdPartyStoragePartitioning

<https://developer.chrome.com/origintrials/#/view_trial/-8517432795264450559>DT
(but notthe
DisableThirdPartySessionStoragePartitioningAfterGeneralPartitioning

<https://developer.chrome.com/origintrials/#/view_trial/3444127815031586817>DT).


Since we shipped the first Deprecation Trial, we have also shipped
the non-cookie storage extension to SAA

<https://groups.google.com/a/chromium.org/g/blink-dev/c/F5EV8I-j7Eg/m/OAi7lcykAAAJ>(M125+)
to address sites impacted by storage partitioning. We are
confident this API extension will address the majority of
“unpartitioned” storage use cases, however, we are aware of a few
partners with slightly different use cases that we are currently
exploring API solutions for.


Our near-term goal is to have this Deprecation Trial expire and
migrate the platform to partitioned-by-default 3rd party storage,
communications APIs, and service workers, especially ahead of 3rd
party cookie deprecation. Given that, we propose to only allow an
extension for sites that have already enrolled in the current
non-expired Deprecation Trial, taking advantage of the new OT
registration approval workflow.

*


That's exciting! Are there numbers you can share regarding the current 
participants? Is it realistic to expect the 6 milestone renewal to be 
the last one?


Sure thing - we have on the order of 600 registrants, but if you de-dupe 
the list that takes you down to about 400. Further removing localhost, 
or staging or obvious test domains (stuff like 
"https://testing-this-ot.vercel.app;, we're down to ~300. My hand-wavey 
guess is the majority of these will be served by the non-cookie SAA 
stuff we shipped, or have already resolved their need to use the OT.


Will this be the last renewal? Hard to predict the future, but if we do 
find ourselves in that bucket I would like to craft it in such a way to 
continue to narrow the funnel further than we are right now, especially 
to avoid timeline contention and side-channels with 3PCD.




*

We will respond to this intent with a link to a blog post once the
renewal process is in place.


Blink component

Blink>Storage

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


TAG review

Early Design Review
https://github.com/w3ctag/design-reviews/issues/629
<https://github.com/w3ctag/design-reviews/issues/629>


TAG review status

Resolution Satisfied


Chromium Trial Name

DisableThirdPartyStoragePartitioning


Origin Trial documentation link

https://developer.chrome.com/blog/storage-partitioning-deprecation-trial/
<https://developer.chrome.com/blog/storage-partitioning-deprecation-trial/>


Risks



Interoperability and Compatibility


Gecko: Shipped/Shipping


WebKit: Shipped/Shipping


Web developers: Mixed signals (some supportive, some concerns
around compatibility)



WebView application risks

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


Not enabled on WebView for now.




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

No, all but WebView.


Is this feature fully tested by web-platform-tests

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

We have basic WPT coverage.


DevTrial instructions

http

[blink-dev] Intent to Extend Deprecation Trial: Partitioning Storage, Service Workers, and Communication APIs

[Mike Taylor]

**


   *Contact emails*

*

miketa...@chromium.org


   Explainer

https://github.com/wanderview/quota-storage-partitioning/blob/main/explainer.md 




   Specification

None


   Summary

We shipped “storage partitioning” in Chrome 115, and a Deprecation Trail 
(DT) 
beginning in M113 that is set to expire in M126. There are also 
enterprise policies available:


https://chromeenterprise.google/policies/#DefaultThirdPartyStoragePartitioningSetting 



https://chromeenterprise.google/policies/#ThirdPartyStoragePartitioningBlockedForOrigins 




We are requesting a renewal for 6 milestones (M127 - M132 inclusive) for 
the DisableThirdPartyStoragePartitioning 
DT 
(but notthe 
DisableThirdPartySessionStoragePartitioningAfterGeneralPartitioning 
DT).



Since we shipped the first Deprecation Trial, we have also shipped the 
non-cookie storage extension to SAA 
(M125+) 
to address sites impacted by storage partitioning. We are confident this 
API extension will address the majority of “unpartitioned” storage use 
cases, however, we are aware of a few partners with slightly different 
use cases that we are currently exploring API solutions for.



Our near-term goal is to have this Deprecation Trial expire and migrate 
the platform to partitioned-by-default 3rd party storage, communications 
APIs, and service workers, especially ahead of 3rd party cookie 
deprecation. Given that, we propose to only allow an extension for sites 
that have already enrolled in the current non-expired Deprecation Trial, 
taking advantage of the new OT registration approval workflow.



We will respond to this intent with a link to a blog post once the 
renewal process is in place.



   Blink component

Blink>Storage 




   TAG review

Early Design Review https://github.com/w3ctag/design-reviews/issues/629 




   TAG review status

Resolution Satisfied


   Chromium Trial Name

DisableThirdPartyStoragePartitioning


   Origin Trial documentation link

https://developer.chrome.com/blog/storage-partitioning-deprecation-trial/ 




   Risks



   Interoperability and Compatibility


Gecko: Shipped/Shipping


WebKit: Shipped/Shipping


Web developers: Mixed signals (some supportive, some concerns around 
compatibility)




   WebView application risks

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



Not enabled on WebView for now.




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

No, all but WebView.


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

We have basic WPT coverage.


   DevTrial instructions

https://developer.chrome.com/en/blog/storage-partitioning-dev-trial 




   Finch feature name

DisableThirdPartyStoragePartitioning


   Non-finch justification

N/A


   Requires code in //chrome?

False


   Tracking bug

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




   Launch bug

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




   Estimated milestones

Shipping on desktop



115

Origin trial desktop first



113

Origin trial desktop last



132

DevTrial on desktop



105


Shipping on Android



115

DevTrial on Android



105





   Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5723617717387264?gate=5117857892663296 




   Links to previous Intent discussions

Intent to Experiment: 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d395956d-3a59-1ba9-1b5c-33505e1518d3%40chromium.org 





This intent message was 

Re: [blink-dev] Intent to Ship: Deprecate Mutation Events

[Mike Taylor]

LGTM3.

I had a slight concern about the quilljs usage - even though they've 
minted a new version, we know that getting sites to update is a major 
hurdle. That said, after reading through the comments and linked issues 
on upstream repos (react-quill, etc) - nobody seems to be describing any 
breakage, they just want the warning to go away. :)


On 5/20/24 1:09 AM, Domenic Denicola wrote:
LGTM2. This is extremely exciting. I hope that in a year, the 
deprecation process is fully complete, and we get to enjoy deleting a 
lot of code/specs/maybe tests.


I agree with your instinct to go to 100% directly with the 127 release.

On Mon, May 20, 2024 at 12:18 AM Philip Jägenstedt 
 wrote:


Hi Mason,

This is quite exciting! Mutation events is something I've long
assumed we'd have to live with forever, but your findings here are
extremely encouraging. Most compelling to me is (1) your analysis
of UKM data and the lack of clear breakage on any of the ~30
checked sites, and (2) that disabling the events on canary, dev
and beta only resulted in a single bug report. The previous
success of Shadow DOM v0 and event.path deprecation also shows
that use counter numbers aren't always a good proxy for risk of
breakage.

In https://github.com/WebKit/standards-positions/issues/192 the
point is made that there are other events that fire with the same
timing as mutation events, so this removal doesn't unblock
everything. Nevertheless, I share the assessment that mutation
events "significantly increase the complexity of adding new
features to the Web"  so if removal is within reach I think we
should go for it. From
https://github.com/mozilla/standards-positions/issues/807 it's
clear that there is enthusiasm beyond the Chromium project too.

Rolling this out with Finch is definitely prudent, and I agree
with the argument for going directly to 100% in 127 to make for a
less confusing debugging experience.

LGTM1 to this plan, while being ready to adapt to things that come
up in the process.

Best regards,
Philip

On Fri, May 17, 2024 at 9:28 PM Mason Freed 
wrote:



On Thu, May 16, 2024 at 11:00 AM Vladimir Levin
 wrote:

I looked into the UKM data about three months ago,
before I started the experiment to disable all
mutation events on Canary/Dev/Beta. I looked at the
top ~30 UKM hits and dug into the site's code to see
what the usage was. Many (~40% or so?) of the top
sites usage was due to quilljs
 which
has since updated their code to not rely on mutation
events. Another maybe 10% was due to a Sharepoint 2016
mquery.js utility

,
for which several folks have requested support from
MS, but it's a bit unclear what the plan is. The rest
of the sites appeared to have bespoke code looking at
mutation events.


Is Sharepoint 10% of the 1% usage? According to the thread
you linked


 they
will fix it in a Sept 2024 release but seem like they
won't backport the fix to previous versions. That seems a
bit risky, but also I'm not sure what the breakage looks
like and as you say, things seem to work.


I don't have a great way to break down how much of the 1% is
represented by the Sharepoint library, because it just shows
up as a JS dependency on affected sites. And yes that's what
the public thread there says, though I'm not sure how
authoritative that is. I've reached out privately to MS to see
if there's more info I can glean. Just to confirm, I can't
"see" any breakage on those sites. The most "visible" thing,
which is what gets folks to report issues like the Sharepoint
one, is the console warning that mutation events are being
used and might break. Those had the intended effect in all of
these cases, which is a good thing.

And finally, of course, assuming I'm approved to
disable in M127, I'll be very mindful of breakage and
will flip the events back on immediately in the case
that there is more breakage than I'm expecting.


Is the plan to do a finch rollout, something like 1%
stable increasing week by week? Or were you just thinking
of enabling it in 127 without finch?


So I'm definitely planning 

Re: [blink-dev] Intent to Ship: Protected Audience ads reporting - allow cross-origin subframes to send reportEvent() beacons

[Mike Taylor]

Thanks Liam!

LGTM1 to ship.

On 5/20/24 3:51 PM, Liam Brady wrote:
Thanks for your feedback on this intent! We plan on modifying the 
"Allow-Cross-Origin-Event-Reporting" response header to accept a 
boolean instead of a string literal to match the preferred convention 
for response headers.


On Thursday, May 9, 2024 at 1:21:43 PM UTC-4 Liam Brady wrote:

Can I ask why string literal vs boolean?


I had done this to match the convention already being used for
other Protected Audience-related response headers (such as
Ad-Auction-Allowed/X-Allow-FLEDGE

<https://source.chromium.org/chromium/chromium/src/+/main:content/services/auction_worklet/public/cpp/auction_downloader.cc;l=413-429;drc=b8d3dfef89a597a4e89d8cc76bcf8a15d655>).
At the time of implementation, I wasn't aware of the preferred
boolean convention of "?0" and "?1" defined in RFC8941
<https://www.rfc-editor.org/rfc/rfc8941#name-booleans>. Even
though this isn't what's preferred, I think it should still be
fine to keep in place for now, and being consistent with the rest
of the Protected Audience API is always a plus.

On Thu, May 9, 2024 at 12:19 PM Mike Taylor 
wrote:

On 5/9/24 12:13 PM, Liam Brady wrote:


Can you clarify what the type is for this new header? It
reads as if you're adding a String Item that looks like a
boolean, rather than a Boolean Item. Is that correct? It
doesn't seem to be actually defined in the spec. 



This is meant to be a string literal that is either "true" or
"false". I have a spec PR
<https://github.com/WICG/fenced-frame/pull/159>up to formally
define that and remove any confusion over what values it's
expecting. Thanks for calling this out!


Can I ask why string literal vs boolean?


This change would impact the ability of first parties to
regulate and prevent reportEvent beacons. Although this
requires mutual opt-in, I expect scenarios to eventually
come up where a site owner wants to allow cross-origin
reportEvent only for certain origins.


To clarify the first party piece, control over sending
reportEvent() beacons rests within the worklet owner that
invokes registerAdBeacon()/registerAdMacro() i.e. seller/
buyer and the document loaded with the main ad renderURL
(i.e. the buyer/advertisers). The first-party (i.e. the
publishers) don't have control over reportEvent() beacons
since that is considered part of the overall Protected
Audience API, and this feature doesn't change that.


On Wed, May 8, 2024 at 1:27 PM Mike Taylor
 wrote:

On 5/8/24 11:30 AM, 'Liam Brady' via blink-dev wrote:


Contact emails

lbr...@google.com, shiva...@chromium.org,
jka...@chromium.org


Explainer(s)

https://github.com/WICG/turtledove/pull/1134
<https://github.com/WICG/turtledove/pull/1134>


Spec(s)

https://github.com/WICG/fenced-frame/pull/152
<https://github.com/WICG/fenced-frame/pull/152>


Summary

Ad frames (both fenced frames and urn-iframes) created
through a Protected Audience auction, as well as their
same-origin nested iframes, are allowed to call
reportEvent() API

<https://github.com/WICG/turtledove/blob/main/Fenced_Frames_Ads_Reporting.md#reportevent-preregistered-destination-url>to
send event-level reports. It's also important for
third-parties on Protected Audience-created ads to have
the same measurement and reporting capabilities for spam
detection, brand safety, and measurement verification.
However, the API as it exists currently has a
same-origin child iframe restriction which poses a
complication as described below.


If an ad buyer wins an ad auction and its ad frame is
displayed on a page, it might choose to embed a subframe
that points to a third-party server that hosts the
actual ad instead. With this use case, and with the
current state of the reportEvent() API, the actual ad's
document cannot directly call reportEvent() the way that
its embedder can since the document is in a cross-origin
nested iframe. Instead, it has to get its embedder to
actually send the beacon by letting the embedder know
via a postMessage. This will not be an ergonomic
solution for this use case.


With this change, a cross-origin subframe can opt in to
sending reportEvent() beacons using its ancestor's

Re: [blink-dev] Intent to Ship: Attribution Reporting Feature: Referrer Policy for Attributionsrc Requests

[Mike Taylor]

LGTM2 (and yes, please don't emit other info in future intents - it 
really helps with reviews!)


On 5/20/24 1:19 AM, Domenic Denicola wrote:

LGTM1.

This looks like a small, well-considered change that makes the 
platform more consistent. I agree the compat risks are small.


From what I understand, fields like TAG review and standards-positions 
for other browsers should be covered by the larger umbrella feature, 
so we shouldn't block on them. However, I would encourage you to 
include those fields in future Intents, stating that rationale for 
omitting the reviews.


On Sat, May 18, 2024 at 1:21 AM 'Akash Nadan' via blink-dev 
 wrote:


Contact emails

akashna...@google.com ,
lin...@chromium.org ,
johni...@chromium.org 


Explainer

Attribution Reporting with event-level reports


Attribution Reporting API with Aggregatable Reports


Aggregation Service for the Attribution Reporting API




Specification

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



Blink component

Internals > AttributionReporting




Summary

We are landing the following change to the Attribution Reporting
API focused on:

 *

applying element-level referrer policy for specific html elements


This change is based on ad-tech feedback
and
so that attributionsrc requests are treated like other
subresources on the page.


Currently when the API is called through the use of the
attributionsrc attribution as part of various html elements (i.e.
, 

Re: [blink-dev] Intent to Experiment: Page Embedded Permission Control

[Mike Taylor]

Sorry - got too excited. LGTM to experiment % requesting the Security, 
Privacy, Debuggability bits.


On 5/16/24 1:28 PM, Mike Taylor wrote:


Thanks - LGTM to experiment from M126 to M131 inclusive.

On 5/16/24 1:26 PM, Penelope McLachlan wrote:

Sorry for not including that!

Origin trial desktop last: 131

On Thu, May 16, 2024 at 10:23 AM Mike Taylor  
wrote:


Hi!

I see a start milestone of 126 - do you have a desired milestone
end date?

On 5/16/24 1:20 PM, 'Penelope McLachlan' via blink-dev wrote:



Contact emails

andypa...@google.com <mailto:andypa...@google.com>,
pjmclach...@google.com <mailto:pjmclach...@google.com>,
eng...@google.com <mailto:eng...@google.com>


Explainer

https://github.com/WICG/PEPC/blob/main/explainer.md
<https://github.com/WICG/PEPC/blob/main/explainer.md>


Specification

none


Summary

Provide a new HTML element that interacts with the permission
flow. The permission prompt is currently triggered directly from
JS without the user agent having any strong signal of the user's
intent. Having an in-content element that the user uses to
trigger the permission flow allows for improved permission
prompt UX for users as well as a recovery path from the "denied"
permission state for sites.


Explainer: https://github.com/WICG/PEPC/blob/main/explainer.md
<https://github.com/WICG/PEPC/blob/main/explainer.md>


This Origin Trial focuses only on the use of the control for
camera/microphone permissions.


Blink component

Chromium Public Trackers > Chromium > Internals > Permissions >
PermissionElement


TAG review

None


TAG review status

Pending


Risks


Interoperability and Compatibility

There is risk that this feature fails to be adopted by other
browsers, though we believe we can address non-supportive signal
from other vendors


Gecko: neutral


WebKit: Initial Oppose
(https://github.com/WebKit/standards-positions/issues/270
<https://github.com/WebKit/standards-positions/issues/270>), we
are addressing feedback <https://github.com/WICG/PEPC/pull/17>.
Some concerns will require experimental data from OT
implementers to address, and this is a goal of the Origin Trial.


Web developers:

Positive - several first and third party partners are committed
to experimenting with the API and have implementations ready for
when the OT launches.


Other signals:


WebView application risks

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

None



Goals for experimentation

  * Solicit more informed Web developer feedback to validate the
element API shape & functionality, including styling
restrictions, specific to use of the Page-embedded
Permission Control for Camera / Mic.
  * Validate developer use cases
  * Ensure that the feature works correctly in conjunction with
adjacent features.
  * Ensure that the feature provides a better overall UX for
permission interactions by allowing users a recovery path
and less interruptions.
  * Check metrics against existing permission usage as a
baseline, for example, investigate any significant increases
or decreases in overall block/accept rates in OT to ensure
users are having a safe, easy to use experience


Debuggability

None


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

No - OT will not include Android & Android WebView



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/html/semantics/permission-element?label=experimental=master

<https://wpt.fyi/results/html/semantics/permission-element?label=experimental=master>


Flag name on chrome://flags

none


Finch feature name

PermissionElement


Tracking bug

https://issues.chromium.org/issues/40275129


Launch bug

https://launch.corp.google.com/launch/4320707/approver/14626
<https://launch.corp.google.com/launch/4320707/approver/14626>


Estimated milestones

Shipping OT on desktop



126



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5125006551416832
<https://chromestatus.com/feature/5125006551416832>


Links to previous Intent discussions

Ready fo

Re: [blink-dev] Intent to Experiment: Page Embedded Permission Control

[Mike Taylor]

Thanks - LGTM to experiment from M126 to M131 inclusive.

On 5/16/24 1:26 PM, Penelope McLachlan wrote:

Sorry for not including that!

Origin trial desktop last: 131

On Thu, May 16, 2024 at 10:23 AM Mike Taylor  
wrote:


Hi!

I see a start milestone of 126 - do you have a desired milestone
end date?

On 5/16/24 1:20 PM, 'Penelope McLachlan' via blink-dev wrote:



Contact emails

andypa...@google.com <mailto:andypa...@google.com>,
pjmclach...@google.com <mailto:pjmclach...@google.com>,
eng...@google.com <mailto:eng...@google.com>


Explainer

https://github.com/WICG/PEPC/blob/main/explainer.md
<https://github.com/WICG/PEPC/blob/main/explainer.md>


Specification

none


Summary

Provide a new HTML element that interacts with the permission
flow. The permission prompt is currently triggered directly from
JS without the user agent having any strong signal of the user's
intent. Having an in-content element that the user uses to
trigger the permission flow allows for improved permission prompt
UX for users as well as a recovery path from the "denied"
permission state for sites.


Explainer: https://github.com/WICG/PEPC/blob/main/explainer.md
<https://github.com/WICG/PEPC/blob/main/explainer.md>


This Origin Trial focuses only on the use of the control for
camera/microphone permissions.


Blink component

Chromium Public Trackers > Chromium > Internals > Permissions >
PermissionElement


TAG review

None


TAG review status

Pending


Risks


Interoperability and Compatibility

There is risk that this feature fails to be adopted by other
browsers, though we believe we can address non-supportive signal
from other vendors


Gecko: neutral


WebKit: Initial Oppose
(https://github.com/WebKit/standards-positions/issues/270
<https://github.com/WebKit/standards-positions/issues/270>), we
are addressing feedback <https://github.com/WICG/PEPC/pull/17>.
Some concerns will require experimental data from OT implementers
to address, and this is a goal of the Origin Trial.


Web developers:

Positive - several first and third party partners are committed
to experimenting with the API and have implementations ready for
when the OT launches.


Other signals:


WebView application risks

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

None



Goals for experimentation

  * Solicit more informed Web developer feedback to validate the
element API shape & functionality, including styling
restrictions, specific to use of the Page-embedded Permission
Control for Camera / Mic.
  * Validate developer use cases
  * Ensure that the feature works correctly in conjunction with
adjacent features.
  * Ensure that the feature provides a better overall UX for
permission interactions by allowing users a recovery path and
less interruptions.
  * Check metrics against existing permission usage as a
baseline, for example, investigate any significant increases
or decreases in overall block/accept rates in OT to ensure
users are having a safe, easy to use experience


Debuggability

None


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

No - OT will not include Android & Android WebView



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/html/semantics/permission-element?label=experimental=master

<https://wpt.fyi/results/html/semantics/permission-element?label=experimental=master>


Flag name on chrome://flags

none


Finch feature name

PermissionElement


Tracking bug

https://issues.chromium.org/issues/40275129


Launch bug

https://launch.corp.google.com/launch/4320707/approver/14626
<https://launch.corp.google.com/launch/4320707/approver/14626>


Estimated milestones

Shipping OT on desktop



126



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5125006551416832
<https://chromestatus.com/feature/5125006551416832>


Links to previous Intent discussions

Ready for Developer Testing :


https://groups.google.com/a/chromium.org/g/blink-dev/c/D-mE5qIlkWY/m/TTEImcBnAAAJ

<https://groups.google

Re: [blink-dev] Intent to Experiment: Page Embedded Permission Control

[Mike Taylor]

Hi!

I see a start milestone of 126 - do you have a desired milestone end date?

On 5/16/24 1:20 PM, 'Penelope McLachlan' via blink-dev wrote:



Contact emails

andypa...@google.com , 
pjmclach...@google.com , 
eng...@google.com 



Explainer

https://github.com/WICG/PEPC/blob/main/explainer.md 




Specification

none


Summary

Provide a new HTML element that interacts with the permission flow. 
The permission prompt is currently triggered directly from JS without 
the user agent having any strong signal of the user's intent. Having 
an in-content element that the user uses to trigger the permission 
flow allows for improved permission prompt UX for users as well as a 
recovery path from the "denied" permission state for sites.



Explainer: https://github.com/WICG/PEPC/blob/main/explainer.md 




This Origin Trial focuses only on the use of the control for 
camera/microphone permissions.



Blink component

Chromium Public Trackers > Chromium > Internals > Permissions > 
PermissionElement



TAG review

None


TAG review status

Pending


Risks


Interoperability and Compatibility

There is risk that this feature fails to be adopted by other browsers, 
though we believe we can address non-supportive signal from other vendors



Gecko: neutral


WebKit: Initial Oppose 
(https://github.com/WebKit/standards-positions/issues/270 
), we are 
addressing feedback . Some 
concerns will require experimental data from OT implementers to 
address, and this is a goal of the Origin Trial.



Web developers:

Positive - several first and third party partners are committed to 
experimenting with the API and have implementations ready for when the 
OT launches.



Other signals:


WebView application risks

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


None



Goals for experimentation

  * Solicit more informed Web developer feedback to validate the
element API shape & functionality, including styling restrictions,
specific to use of the Page-embedded Permission Control for Camera
/ Mic.
  * Validate developer use cases
  * Ensure that the feature works correctly in conjunction with
adjacent features.
  * Ensure that the feature provides a better overall UX for
permission interactions by allowing users a recovery path and less
interruptions.
  * Check metrics against existing permission usage as a baseline, for
example, investigate any significant increases or decreases in
overall block/accept rates in OT to ensure users are having a
safe, easy to use experience


Debuggability

None


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

No - OT will not include Android & Android WebView



Is this feature fully tested by web-platform-tests

?

Yes - 
https://wpt.fyi/results/html/semantics/permission-element?label=experimental=master 




Flag name on chrome://flags

none


Finch feature name

PermissionElement


Tracking bug

https://issues.chromium.org/issues/40275129


Launch bug

https://launch.corp.google.com/launch/4320707/approver/14626 




Estimated milestones

Shipping OT on desktop



126



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5125006551416832 




Links to previous Intent discussions

Ready for Developer Testing :

https://groups.google.com/a/chromium.org/g/blink-dev/c/D-mE5qIlkWY/m/TTEImcBnAAAJ 



Intent to prototype:

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





--
*Penny McLachlan*
(she/her)

Senior Product Manager
pjmclach...@google.com
Google Chrome

--
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 Experiment: FedCM multi IDP in single get() call

[Mike Taylor]

Sounds good - no concerns with shifting the milestones.

On 5/16/24 11:53 AM, Nicolás Peña Moreno wrote:
We decided to further delay the start of the OT since our partner 
needs more time before they can put it in front of real users, so the 
current plan it to do the experiment on milestones 128 - 132.


On Tuesday, April 23, 2024 at 4:01:15 PM UTC-4 Nicolás Peña Moreno wrote:

I sent this intent before the feature was ready, and this required
a lot of UX work, so trial has not started. Our plan is to start
on Chrome M126 so I will assume the approvals are shifted to 126 -
130. If there are concerns let me know, thanks!

On Tuesday, February 27, 2024 at 3:04:38 PM UTC-5 Yoav Weiss wrote:

LGTM to experiment M124-M128 inclusive

On Tue, Feb 27, 2024 at 4:16 PM Nicolás Peña
 wrote:

Done

On Monday, February 26, 2024 at 7:55:09 PM UTC-5 Mike
Taylor wrote:

Could you please request reviews for the
privacy/security/debuggability review gates in your
chromestatus entry?

On 2/21/24 3:21 PM, Nicolás Peña wrote:

Contact emails

n...@chromium.org


Explainer

The Federated Credential Management (FedCM) API
currently only allows one identity provider (IDP) to
be used when performing federated login in a website.
We would like to experiment with allowing multiple
providers to be specified in a single JavaScript
get() call, which allows FedCM to be used in cases
for which the website supports multiple IDPs for
federation. See also additional context in
https://github.com/fedidcg/FedCM/issues/319
<https://github.com/fedidcg/FedCM/issues/319>.


Specification

https://fedidcg.github.io/FedCM
<https://fedidcg.github.io/FedCM>


Summary

Allows FedCM to show multiple IDPs in the same
dialog. This provides developers with a convenient
way to present all supported identity providers to
users. In this I2E, we are tackling the simple case
of having all providers in the same get() call, while
building much of the UX infratructure that will allow
us to tackle more sophisticated production structures
later.



Blink component

Blink>Identity>FedCM

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


TAG review

https://github.com/w3ctag/design-reviews/issues/803
<https://github.com/w3ctag/design-reviews/issues/803>


TAG review status

Pending


Risks

Interoperability and Compatibility

This should not have additional interop risks on top
of the existing FedCM API which is generally
supported but not yet implemented by Firefox and
Safari. In order to determine whether multiple IDPs
are supported in a browser which supports FedCM, the
developer can attempt to first call get() with
multiple IDPs. It will be rejected immediately if not
supported and the RP can retry with a single IDP.



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


WebKit: No signal
(https://github.com/WebKit/standards-positions/issues/120
<https://github.com/WebKit/standards-positions/issues/120>)


Web developers: Positive
(https://github.com/fedidcg/FedCM/issues/319
<https://github.com/fedidcg/FedCM/issues/319>)


Other signals:


Ergonomics

Using this API will just require expanding the get()
to use more providers, so it will benefit from the
ergonomics of the initial FedCM API.



Activation

The main activation issue is having to include all
IDPs in the same get() call, which may be challenging
in some cases because IDPs generally are independent
from each other. That said, we do have developers who
can use the single get() call, so we wish to start
with the simpler version of multi IDP support.



Security

The security considerations are similar to those of
the s

Re: [blink-dev] Intent to Ship: Automatic Fullscreen Content Setting

[Mike Taylor]

LGTM1, with the commitment to follow up on Permissions API integration 
(thanks!).


On 5/15/24 6:34 PM, Reilly Grant wrote:
LGTM as an IWA OWNER (3x LGTM from Blink API OWNERS are still required 
according to the IWA-specific API launch process 
<https://www.chromium.org/blink/launching-features/isolated-web-apps/>).


Thank you for working with the IWA and Security reviewers to figure 
out the right restrictions to prevent this from 
exacerbating fullscreen-based phishing attacks. We have the option to 
loosen these restrictions if a better UX solution to the notice and 
consent is developed.
Reilly Grant | Software Engineer |reil...@chromium.org |Google Chrome 
<https://www.google.com/chrome>



On Wed, May 15, 2024 at 3:00 PM Mike Wasserman  wrote:

Our team can commit to adding Permissions API query integration,
with the requisite approvals.
That would provide feature detection, and also clarify
requestFullscreen method steps in the spec.

I'm requesting approval to ship the feature in its current state,
given our commitment to follow up.

Thanks,
Mike


On Wed, May 15, 2024 at 10:01 AM Mike Wasserman 
wrote:

No, this content setting does not have Permissions API
integration at this time.
That seems like a great future improvement, especially if user
control of the setting is extended to more contexts.

On Wed, May 15, 2024 at 9:37 AM Alex Russell
 wrote:

Will the status of the permission be reflected in the
Permissions API? I see Permissions Policy integration, but
not the Permissions API reflection that I'd expect.

Best,

Alex

On Tuesday, May 14, 2024 at 3:54:24 PM UTC-7 Mike
Wasserman wrote:

Thanks! I pinged the PR, and hope for some feedback
there soon.

Feature detection via Permissions API querying seems
like a great follow up here, ideally alongside
broadened feature availability (i.e. extending user
control beyond Isolated Web Apps).


On Tue, May 14, 2024 at 1:43 PM Mike Taylor
 wrote:

It would be nice for the PR to be reviewed and
approved, even without other stakeholder support.

Additionally - the explainer mentions a few
options for feature detection. Any progress on
that front? Or is it just hypothetical?

On 5/9/24 3:04 PM, Mike Wasserman wrote:

Sure. I'll note that whatwg/fullscreen's PR
merging includes a question or criteria "At least
two implementers are interested (and none opposed)".
I have filed standards position requests with
Mozilla and WebKit, and I will ping fullscreen
spec maintainers for input.

On Thu, May 9, 2024 at 11:39 AM Vladimir Levin
 wrote:

Ah thanks, I missed it in the explainer. The
spec changes make sense to me. The changes
don't look like they would be controversial,
but it's probably worthwhile to ensure that
this PR is under review and/or landing as a
part of shipping this.

Thanks!
Vlad

On Thu, May 9, 2024 at 12:20 PM Mike
Wasserman  wrote:

Yes, there's a draft PR
<https://github.com/whatwg/fullscreen/pull/235>
with the Explainer's anticipated spec
changes

<https://github.com/explainers-by-googlers/html-fullscreen-without-a-gesture#spec-changes>,
which are designed

<https://github.com/explainers-by-googlers/html-fullscreen-without-a-gesture?tab=readme-ov-file#detailed-design-discussion>
 alike
The rules for choosing a navigable

<https://html.spec.whatwg.org/multipage/document-sequences.html#the-rules-for-choosing-a-navigable>
when a new top-level traversable

<https://html.spec.whatwg.org/multipage/document-sequences.html#top-level-traversable>
is being requested, as invoked by
Window.open()

<https://html.spec.whatwg.org/multipage/nav-history-apis.html#dom-open-dev>:


  * If currentNavigable's active window

<https://html

Re: [blink-dev] New API owner: Vladimir Levin!

[Mike Taylor]

Congrats Vlad!

On 5/15/24 12:22 PM, danakj wrote:

Congrats, Vlad :)

On Wed, May 15, 2024 at 12:19 PM Chris Harrelson 
 wrote:


Hi all,

I'd like to welcome Vlad as our newest API owner. He is a
long-time member of the Blink community that many of you know
well, and has quite a bit of experience in graphics, Blink
rendering and standards.

Welcome Vlad, and congratulations!
-- 
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%2Bw9BACT3QX34KLKXKkA02WccSJmACtJa1nK8eVm0PNe55Q%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/CAHtyhaTEFMFARkpKtj_4JbcHREMNQAPRxEqPDFhVO-HextRDNQ%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/419eb2b4-6eb6-499e-9321-d4caa9c4a6fb%40chromium.org.

Re: [blink-dev] Intent to Ship: Multi-argument alt text in CSS Generated Content

[Mike Taylor]

From what I can tell, this shipped in Firefox a few days ago, and 
should be in 127: https://bugzilla.mozilla.org/show_bug.cgi?id=1281158#c26


LGTM1

On 5/13/24 4:15 PM, 'Daniel Clark' via blink-dev wrote:


/> Gecko: No signal 
(https://bugzilla.mozilla.org/show_bug.cgi?id=1281158//)/


/> It's hard to parse the sentiment in that bug, but it doesn't seem 
negative at least :) I don't know if it's worth filing a position request/


Since I last looked at this bug, Gecko has actually started 
implementing the feature: 
https://hg.mozilla.org/mozilla-central/rev/df46563babe2. Based on this 
comment 
 
they’re also excluding counter(), so they’ll match the behavior I’m 
proposing to ship here. Looking at 
https://bugzilla.mozilla.org/show_bug.cgi?id=1896047 the work isn’t 
quite finished yet. So based on these updates I think it’s fair to say 
that the Gecko position is actually “In Development” rather than “No 
Signal”.


/> I believe this is behind the CSSContentMultiArgAltText flag, right? /

That’s right.

-- Dan

*From:*Vladimir Levin 
*Sent:* Monday, May 13, 2024 11:44 AM
*To:* Daniel Clark 
*Cc:* blink-dev@chromium.org
*Subject:* Re: [blink-dev] Intent to Ship: Multi-argument alt text in 
CSS Generated Content


On Mon, May 13, 2024 at 2:23 PM 'Daniel Clark' via blink-dev 
 wrote:


*Contact emails*

dan...@microsoft.com

*Explainer*

None

*Specification*


https://drafts.csswg.org/css-content-3/#valdef-content---string--counter--attrand
https://drafts.csswg.org/css-content-3/#alt


*Summary*

The CSS content property allows developers to specify alternative
text for accessibility with the following syntax:

.has-before-content::before { content: url("cat.jpg") / "A cute
cat"; }

This functionality, where the alt text is given by a single
string, is already supported in Chromium
(https://chromestatus.com/feature/4550056227110912). However, the
spec allows the alt text to be given by an arbitrary number of
elements, which in addition to strings can be attr() functions or
counters.

For example:

.has-before-content::before { content: url("cat.jpg") / "A cute "
attr(data-animal); }

This Intent tracks the expansion of the Chromium implementation to
support an arbitrary number of arguments as well as attr()
functions in addition to strings.

Note that this Intent to Ship does **not** include the addition of
counter support. This turns out to add significant complexity
since counters are normally evaluated as part of layout tree
computation and the alt text being evaluated does not participate
in the layout tree. The existing WebKit implementation of this
feature does not support counters

,
so by shipping what’s proposed here Chromium will align with WebKit.

*Blink component*

Blink>Accessibility



*TAG review*

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

*TAG review status*

Issues Addressed

*Risks*

*Interoperability and Compatibility*

The new syntax will fail to parse in browser where it’s not
supported, so until browser support is widespread, developers
should include a preceding fallback line to specify the content:

.has-before-content::before {

content: url("cat.jpg"); /* Used if the following line doesn't
parse */

content: url("cat.jpg") / "A cute " attr(data-animal);

  }

This compat risk is not really new given the feature’s current
state of partial support.

The lack of counter support in this implementation means there
will still be a gap between what we’re planning to ship here and
the spec. However since Chromium already ships a partial
implementation, and the updated implementation supports more of
the spec and puts us into alignment with WebKit, shipping this
puts things in a strictly better position.


/Gecko/: No signal
(https://bugzilla.mozilla.org/show_bug.cgi?id=1281158)

It's hard to parse the sentiment in that bug, but it doesn't seem 
negative at least :) I don't know if it's worth filing a position request



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

/Web developers/: There have been several blog posts ([1]
,
[2]

,
[3]

,

Re: [blink-dev] Intent to Ship: Automatic Fullscreen Content Setting

[Mike Taylor]

It would be nice for the PR to be reviewed and approved, even without 
other stakeholder support.


Additionally - the explainer mentions a few options for feature 
detection. Any progress on that front? Or is it just hypothetical?


On 5/9/24 3:04 PM, Mike Wasserman wrote:
Sure. I'll note that whatwg/fullscreen's PR merging includes a 
question or criteria "At least two implementers are interested (and 
none opposed)".
I have filed standards position requests with Mozilla and WebKit, and 
I will ping fullscreen spec maintainers for input.


On Thu, May 9, 2024 at 11:39 AM Vladimir Levin  
wrote:


Ah thanks, I missed it in the explainer. The spec changes make
sense to me. The changes don't look like they would be
controversial, but it's probably worthwhile to ensure that this PR
is under review and/or landing as a part of shipping this.

Thanks!
Vlad

On Thu, May 9, 2024 at 12:20 PM Mike Wasserman 
wrote:

Yes, there's a draft PR
 with the
Explainer's anticipated spec changes

,
which are designed


 alike
The rules for choosing a navigable


when a new top-level traversable


is being requested, as invoked by Window.open()

:


  * If currentNavigable's active window


does not have transient activation


and the user agent has been configured to not show popups
(i.e., the user agent has a "popup blocker" enabled)
  o The user agent may inform the user that a popup has
been blocked.


On Thursday, May 9, 2024 at 7:30:09 AM UTC-7 Vladimir Levin wrote:

On Wed, May 8, 2024 at 7:46 PM Mike Wasserman
 wrote:


Contact emails

m...@chromium.org, fugu-...@chromium.org


Explainer


https://github.com/explainers-by-googlers/html-fullscreen-without-a-gesture




Specification


https://fullscreen.spec.whatwg.org/#dom-element-requestfullscreen




Design docs


https://github.com/explainers-by-googlers/html-fullscreen-without-a-gesture




Summary

A new "Automatic Fullscreen" content setting permits
Element.requestFullscreen() without a user gesture,
and permits browser dialogs to appear without exiting
fullscreen.


The setting is blocked by default and sites cannot
prompt for permission. New UI controls are limited to
Chrome's settings pages [1] and the site info bubble.
Users can allow Isolated Web Apps [2], and enterprise
admins can allow additional origins with the
AutomaticFullscreenAllowedForUrls policy.


Combined with Window Management permission [3] and
unblocked popups [4], this unlocks valuable fullscreen
capabilities:

- Open a fullscreen popup on another display, from one
gesture

- Show fullscreen content on multiple displays from
one gesture

- Show fullscreen content on a new display, when it's
connected

- Swap fullscreen windows between displays with one
gesture

- Show fullscreen content after user gesture expiry or
consumption


[1] chrome://settings/content/automaticFullScreen and
site details pages

[2] User control is initially scoped to
security-sensitive apps;
seehttps://chromestatus.com/feature/5146307550248960


[3] For multi-screen window placement features;

Re: [blink-dev] Intent to Implement and Ship: Conversion to RGB in VideoFrame.copyTo()

[Mike Taylor]

Ergonomics-wise, it does not seem intuitive to use a method called 
allocationSize() to feature detect copyTo support, even if the semantics 
are the same. Besides a very careful reading of the spec, how do we 
expect developers to know about it?


On 5/14/24 4:32 PM, Eugene Zemtsov wrote:
In that discussion Marcos Cáceres asked for a synchronous way to 
detect if format conversion is supported.
We have a synchronous call allocationSize() 
<https://www.w3.org/TR/webcodecs/#dom-videoframe-allocationsize> that 
throws an unsupported error in cases where format conversion is not 
supported.
I added a WPT test around it in a recent CL 
<https://chromium-review.googlesource.com/c/chromium/src/+/5530313>.


canCopyTo() might be needed if we have more settings in 
VideoFrameCopyToOptions 
<https://www.w3.org/TR/webcodecs/#dictdef-videoframecopytooptions> and 
might want to know which part exactly is causing an error.


On Tue, May 14, 2024 at 12:25 PM Mike Taylor  
wrote:


I see that WebKit raised an API concern around detectability

<https://github.com/WebKit/standards-positions/issues/341#issuecomment-2099746809>.
In your reply, you said "we should consider...". Has that
consideration happened, perhaps as follow-up work? :)

On 5/8/24 4:05 PM, Eugene Zemtsov wrote:

This feature has Privacy, Security, Enterprise, and Debuggability
approvals. Webkit gave a positive signal.

Any objections or questions from the API owners?



On Wed, May 1, 2024 at 4:26 PM Eugene Zemtsov
 wrote:

I've filed issues for TAG review and firefox and webkit
positions.

>  Have you looked into other platform APIs that could
benefit from being able to explicitly specify intermediate
format hinting and/or transformation?
I don't think this kind of review can be done for all web
APIs by one person. It's up to spec editors in each area to
identify these small changes that improve dev experience and
performance.

For media related things:
- VideoFrame is a versatile tool that can be created from
HTMLOrSVGImageElement, HTMLVideoElement, HTMLCanvasElement,
ImageBitmap,
         OffscreenCanvaswithout a copy. In a way this change
extends variety of export formatsfor all of them.
    So lots of things can be exported to RGB bitmaps without
a canvas now.
- AudioData has a way to be exported into different sampling
formats.



    On Wed, May 1, 2024 at 9:41 AM Mike Taylor
 wrote:

+1. Would you mind also filing gecko and webkit
positions? I expect them to be positive, given the
informal signals you have in the spec PRs already - but
this also lets them know we're moving ahead with
shipping. Thanks - Mike

On 5/1/24 11:51 AM, Alex Russell wrote:

hey Eugene,

This is an exciting an useful addition! Have you looked
into other platform APIs that could benefit from being
able to explicitly specify intermediate format hinting
and/or transformation? It's a place where (had the TAG
been consulted) I would have expected to see a larger
chain of additions to make this work in other areas, or
at least a discussion of why they aren't (or are?) being
pursued. Have you looked into that?

Best,

Alex

On Tuesday, April 30, 2024 at 3:51:01 PM UTC-7 Eugene
Zemtsov wrote:

> Can you please request reviews for privacy,
security, enterprise, etc in the chromestatus entry?

Done

    On Mon, Apr 29, 2024 at 7:44 AM Mike Taylor
 wrote:

Can you please request reviews for privacy,
security, enterprise, etc in the chromestatus entry?

On 4/25/24 6:19 PM, 'Eugene Zemtsov' via
blink-dev wrote:



Contact emails

ezemt...@google.com


Explainer


https://gist.github.com/Djuffin/9e2f98025ead49998524510cfeed8d33


Specification

https://www.w3.org/TR/webcodecs/#dom-videoframe-copyto


Summary

VideoFrame.copyTo() can convert pixel data to
RGB pixel format Converting YUV video frames to
RGB is often required for processing them in
libraries like TensorFlow.js and OpenCV.js.
Previously the only possible way to achieve
this was rendering the frame on a canvas.
Specifying VideoFrameCopyToOptions.format and

Re: [blink-dev] Re: Intent to Ship: WebRTC encoded transform - Constructor with custom Metadata (originally Modify Metadata functions)

[Mike Taylor]

Thanks for the doc. It sounds like the design evolved during the OT 
based on fedback from the WG, and at least one partner was satisfied 
with the shape and functionality.


LGTM1

On 5/14/24 8:05 AM, Guido Urdaneta wrote:
Here is a doc with feedback from the Origin Trial. There were two 
registrants reported with a large usage scale. We received feedback 
from one of them and will update the doc if/when we get feedback from 
the other one.


https://docs.google.com/document/d/1QSYbrlgE_6ZZag_VRd8Mn863Slb5-GLlJ_-X4WOiym0/edit?usp=sharing


On Wed, May 8, 2024 at 5:45 PM Alex Russell  
wrote:


Hey Guido,

This is a cool feature! The Milestones section shows that an OT
was run; is there a summary someplace of what we learned from the OT?

Best,

Alex

On Thursday, May 2, 2024 at 4:40:31 AM UTC-7 Guido Urdaneta wrote:


Contact emails


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


Explainer



https://github.com/guidou/webrtc-extensions/blob/main/constructor-explainer.md


Specification



https://w3c.github.io/webrtc-encoded-transform/#dom-rtcencodedvideoframe-constructor



https://w3c.github.io/webrtc-encoded-transform/#dom-rtcencodedaudioframe-constructor


Summary


Allow WebRTC Encoded Transform API to create encoded
audio and video frames specifying custom metadata.
This is achieved by introducing constructors for
encoded frames that take the original frame and custom
metadata as input. This supports use cases that
involve manipulation of not only the payload of
encoded video / audio frames but also its metadata.
Some examples: * Changing the mime type of the frame
if the transform changes the type of the payload *
Forwarding of media to a new peer connection set up to
use different metadata values * Altering the timestamp
of a frame to introduce a delay
Use cases:
https://w3c.github.io/webrtc-nv-use-cases/#live-encoded-media
https://w3c.github.io/webrtc-nv-use-cases/#stored-encoded-media
https://w3c.github.io/webrtc-nv-use-cases/#auction
Issue link:
https://github.com/w3c/webrtc-nv-use-cases/issues/77



This change has consensus in the WebRTC Working Group and has
been merged into the WebRTC Encoded Transform spec.


Blink component


Blink>WebRTC




TAG review


TAG review request for this specific change:
https://github.com/w3ctag/design-reviews/issues/942


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


TAG review status


Pending


Chromium Trial Name


RTCEncodedFrameSetMetadata


Origin Trial documentation link



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


WebFeature UseCounter name


RTCEncodedFrameSetMetadata


Risks




Interoperability and Compatibility


Interoperability risk: There is always the risk that
other browsers will not implement this feature. This
risk is mitigated by alignment across browser vendors
in the W3C WebRTC Working Group around the spec.
Compatibility risk: This is a new feature intended to
support new use cases. It introduces no breaking
changes, so we do not expect any compatibility issues.


/Gecko/: No signal
(https://github.com/mozilla/standards-positions/issues/1009)
During WebRTC WG meetings, Mozilla has shown positive
signals and agreed with merging the PR in the main
spec. See the exchange in
https://github.com/w3c/webrtc-encoded-transform/pull/223

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

Marked as "Invalid" in the position request because
this is a small change and the position was addressed
in the PR review. The comments from WebKit in the PR
review and during WebRTC WG meetings are positive and
they have agreed with merging the PR in the main spec.
See the exchange in

Re: [blink-dev] Intent to Implement and Ship: Conversion to RGB in VideoFrame.copyTo()

[Mike Taylor]

I see that WebKit raised an API concern around detectability 
<https://github.com/WebKit/standards-positions/issues/341#issuecomment-2099746809>. 
In your reply, you said "we should consider...". Has that consideration 
happened, perhaps as follow-up work? :)


On 5/8/24 4:05 PM, Eugene Zemtsov wrote:
This feature has Privacy, Security, Enterprise, and Debuggability 
approvals. Webkit gave a positive signal.


Any objections or questions from the API owners?



On Wed, May 1, 2024 at 4:26 PM Eugene Zemtsov  wrote:

I've filed issues for TAG review and firefox and webkit positions.

>  Have you looked into other platform APIs that could benefit
from being able to explicitly specify intermediate format hinting
and/or transformation?
I don't think this kind of review can be done for all web APIs by
one person. It's up to spec editors in each area to identify these
small changes that improve dev experience and performance.

For media related things:
-  VideoFrame is a versatile tool that can be created from
HTMLOrSVGImageElement, HTMLVideoElement, HTMLCanvasElement,
ImageBitmap,
         OffscreenCanvaswithout a copy. In a way this change
extends variety of export formatsfor all of them.
    So lots of things can be exported to RGB bitmaps without a
canvas now.
-  AudioData has a way to be exported into different sampling formats.



On Wed, May 1, 2024 at 9:41 AM Mike Taylor
 wrote:

+1. Would you mind also filing gecko and webkit positions? I
expect them to be positive, given the informal signals you
have in the spec PRs already - but this also lets them know
we're moving ahead with shipping. Thanks - Mike

On 5/1/24 11:51 AM, Alex Russell wrote:

hey Eugene,

This is an exciting an useful addition! Have you looked into
other platform APIs that could benefit from being able to
explicitly specify intermediate format hinting and/or
transformation? It's a place where (had the TAG been
consulted) I would have expected to see a larger chain of
additions to make this work in other areas, or at least a
discussion of why they aren't (or are?) being pursued. Have
you looked into that?

Best,

Alex

On Tuesday, April 30, 2024 at 3:51:01 PM UTC-7 Eugene Zemtsov
wrote:

> Can you please request reviews for privacy, security,
enterprise, etc in the chromestatus entry?

Done

On Mon, Apr 29, 2024 at 7:44 AM Mike Taylor
 wrote:

Can you please request reviews for privacy, security,
enterprise, etc in the chromestatus entry?

On 4/25/24 6:19 PM, 'Eugene Zemtsov' via blink-dev wrote:



Contact emails

ezemt...@google.com


Explainer

https://gist.github.com/Djuffin/9e2f98025ead49998524510cfeed8d33


Specification

https://www.w3.org/TR/webcodecs/#dom-videoframe-copyto


Summary

VideoFrame.copyTo() can convert pixel data to RGB
pixel format Converting YUV video frames to RGB is
often required for processing them in libraries like
TensorFlow.js and OpenCV.js. Previously the only
possible way to achieve this was rendering the frame
on a canvas. Specifying
VideoFrameCopyToOptions.format and
VideoFrameCopyToOptions.colorSpace makes it possible
to convert frames to RGB pixel formats by calling
VideoFrame.copyTo() without having to use an extra
canvas.


Blink component

Blink>Media>WebCodecs

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


Initial public proposal

https://github.com/w3c/webcodecs/issues/92


TAG review

N/A since the change is minor


Risks



Interoperability and Compatibility

None



/Gecko/: Positive

(https://github.com/w3c/webcodecs/pull/754#pullrequestreview-2008590591)

/WebKit/: Positive TPAC 2023. Media working group
session.

/Web developers/:

https://github.com/w3c/webcodecs/issues/92#issuecomment-1594083978


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

Re: [blink-dev] Re: Intent to Experiment: Element Capture

[Mike Taylor]

OK - thanks for the clarification. I would ask that you get in touch 
with every registered origin - expiring the experiment early may be 
surprising.


LGTM1 to experiment from M127 to M132 inclusive.

On 5/14/24 12:08 PM, Elad Alon wrote:
I'm asking for a break-off period starting July 1 and ending July 22 
(inclusive). That means that the original trial will end on June 30, 
and be restarted on July 23. This corresponds to breaking the original 
experiment early during the cycle of what would have otherwise been 
its final milestone (m126), the restarting the experiment over the 
m127-m132 range. (CC Panos for feasibility.)


On Friday, May 10, 2024 at 10:25:03 PM UTC+2 mike...@chromium.org wrote:

Note: Because you're asking for a renewal of 6 milestones, this
will require 3 LGTMs.

Can you clarify which milestones you're asking for? You've written
"(2024-May-14 to 2024-Jun-04)" - that range maps to M125 and M126
stable releases.

On 5/10/24 6:44 AM, 'Elad Alon' via blink-dev wrote:


Hello Blink owners,


We are asking for a breaking period of 3 weeks to this API,
followed by a renewed experiment for the traditional 6 milestones
(2024-May-14 to 2024-Jun-04). A request
that
seems similar to me was granted in January 2022 for another API,
and later shipped successfully with consensus with Mozilla and Apple.


At the time of writing, we have public support

for
this API from such companies as Zoom, Jitsi, Mux, DialPad,
Whereby, Intel and Tella. Tango’s co-founder wrote

“I
can't emphasize enough how instrumental this specification would
be for our product and user experience.” However, none of them
have signed up for the OT as of yet.


From the OT perspective:

This API allows Web developers to build novel new features;
however, it requires a non-trivial investment. We are hoping that
after giving more time, we will see more participation.


From the standardization perspective:

We need time to pick up discussions with Mozilla and Apple again.
As Chrome’s Security and Privacy experts do not share the
concerns Mozilla and Apple have previously voiced, it stands to
reason that additional discussions will allow us to converge -
and we will prioritize these discussions now.


Additionally, some possibilities remain for API changes that
could perhaps allow for a compromise, mostly around cross-origin
isolation. (Full disclosure - this is not my ideal outcome, but
it’s a fallback possibility worth mentioning.)


Progress made:

 *

Spec:The spec has evolved and is now more mature, dealing
better with such edge cases as loss of “eligibility for
restriction.”

 *

TAG:Previously we held off on the request for a TAG review
until we got some more developer feedback about the API
shape. Having received this initial feedback, the TAG request
has now
been submitted.

 *

Signals:Signals have been requested. Mozilla responded. We
intend to prioritize this discussion with them now.

 *

Feedback:Outreach for feedback from the spec community -
multiple issues

were
filed on the spec by Web developers.

 *

WPT:Coverage has recently been extended

.


Reasons to run a new trial:

Gain additional feedback from new participants. Examples for
remaining areas where new feedback could help include:

 *

Uncover new edge cases which were not uncovered by the spec
authors and reviewers, implementers and current OT
participants. The current edge cases here

demonstrate
how non-obvious these may be.

 *

Validate (or refute) the assumptions we have made about the
viability of an MVP that is missing some functionality. Examples:

 o

Events notifying apps when an element stops/starts being
“eligible for restriction”.

 o

Mechanism to force elements into an “eligible for
restriction” state.

 *

Encourage future OT participation by Web developers, by
demonstrating that risks associated with relying on an origin
trial, while real, are 

Re: [blink-dev] Intent to Ship: CSSPageRule to inherit from CSSGroupingRule

[Mike Taylor]

Hi Morten -

Appreciate the response. I spent some time looking at 
https://github.com/search?q=%22instanceof+CSSGroupingRule%22+language%3AJavaScript=code=JavaScript 
as well as "instanceof CSSRule" earlier, but didn't see anything 
immediately worrying (granted, it's hard to predict perfectly how the 
tooling-related scripts might handle sites in the wild that might ship 
the problematic patterns).


LGTM1 to ship.

On 5/9/24 6:16 AM, Morten Stenshorne wrote:

On Wed, 8 May 2024 at 17:18, Mike Taylor  wrote:

On 5/8/24 3:37 AM, Morten Stenshorne wrote:



Interoperability and Compatibility

Low risk. The one possible issue is if an author uses "instanceof
CSSGroupingRule" or "instanceof CSSRule" with a page rule object
and makes incorrect assumptions based on that. However, given
that this is already shipping in Firefox (and also that in
Firefox, even CSSStyleRule inherits from CSSGroupingRule, as the
spec says - whereas Blink still doesn't), the risk should be very
low.


I agree the risk is likely very low, or contained to just a few
sites/applications - have you done any investigation to try to
find any problematic code examples that you mention (via GitHub
search or HTTPArchive)?


There's a use counter - 
https://chromestatus.com/metrics/feature/timeline/popularity/4862 - 
for CSSPageRule, but I'm not sure how useful it is, since it will 
count as long as someone e.g. iterates over the rules in a style sheet 
and there happens to be an @page rule in there. The use is currently 
at 0.07, but the number isn't that useful, apart from being an 
absolute worst-case number.


Here's a constructed problematic case if CSSPageRule suddenly inherits 
from CSSGroupingRule:


```

  @media screen {
    div {
      color: hotpink;
    }
  }
  @page {
    margin: 1in;
    @top-center {
      content: "Header";
    }
  }


  for (const rule of document.styleSheets[0].cssRules) {
    if (rule instanceof CSSGroupingRule) {
      // Aha! You're a media rule! (d'oh!)
      // ...
    }
  }

```

How likely is that, though?


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

Noting that the patch should ship to Firefox release channel (126)
in about a week, per https://whattrainisitnow.com/calendar/.


Ah, right. Pretty recent change.

On that note, earlier (some time in 2023), Firefox changed 
CSSStyleRule to inherit from CSSGroupingRule - 
https://github.com/w3c/csswg-drafts/issues/8940#issuecomment-1747351690
That sounds like a much riskyisher change, but allegedly it went just 
fine.




/WebKit/: No signal

Can we request a signal? Or do we have any other indications about
their intentions here?


Done. https://github.com/WebKit/standards-positions/issues/346


--
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/ee67bf7d-78f9-4309-b831-00942ae69936%40chromium.org.

Re: [blink-dev] Request for Deprecation Trial: Media Previews opt-out

[Mike Taylor]

FWIW, a deprecation trial can surpass 6 milestones - but they require 
sufficient justification as well as 3 LGTMs.


That said, I'm not sure I understand the request here. I read the linked 
"Chrome Camera and Mic Previews" document, but I think the Rollout plan 
section is assuming more info than I have. Could you explain how this 
feature and PEPC relate, and why having them work together is a bad 
thing? Do you plan to deprecate one of the features once the Deprecation 
Trial is finished? (Or are you just requesting an Origin Trial to 
temporarily disable something, and expect it to be re-enabled in the 
future?)


Something that approaches an Explainer would probably be helpful here - 
thanks!


On 5/10/24 5:05 PM, mark a. foltz wrote:

I'm fine with shortening the trial, as long as extensions are possible 
in case we need longer to ship a long-term solution.


On Fri, May 10, 2024 at 12:39 PM Vladimir Levin  
wrote:




On Fri, May 10, 2024 at 2:40 PM mark a. foltz
 wrote:


Contact emails

mfo...@chromium.org, bryantchand...@chromium.org


Explainer

None


Specification


https://docs.google.com/document/d/1ZnX2JROjr9l4y2_OPMpfVlLOo-A5cQzD4mWarj9kXQ0/edit


Design docs



https://docs.google.com/document/d/1ZnX2JROjr9l4y2_OPMpfVlLOo-A5cQzD4mWarj9kXQ0/edit


Summary

Allow coordination between sites using Page Embedded
Permissions Controls and concurrent experiments with the
camera and microphone permissions UI in Chrome.



Blink component

Blink>MediaStream




TAG review

None


TAG review status

Not applicable


Chromium Trial Name

MediaPreviewsOptOutPersistent


Origin Trial documentation link


https://docs.google.com/document/d/1ZnX2JROjr9l4y2_OPMpfVlLOo-A5cQzD4mWarj9kXQ0/edit?usp=sharing


WebFeature UseCounter name

kOBSOLETE_PageDestruction


Risks



Interoperability and Compatibility

None as this feature concerns the functionality of Chrome's
permissions UI, and does not change the behavior of the APIs
that are gated by it: navigator.mediaDevices.enumerateDevices
and navigator.mediaDevices.getUserMedia Other browsers
implement their own permissions UIs independently of Chrome.



/Gecko/: N/A

/WebKit/: N/A

/Web developers/: No signals

/Other signals/:


Ergonomics

N/A



Activation

N/A



Security

N/A



WebView application risks

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

None



Goals for experimentation



Ongoing technical constraints

There are no plans to add media previews to Chrome on
platforms other than Windows/Mac/Linux.



Debuggability

N/A



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

No

There are currently no plans to launch previews outside of
Windows/Mac/Linux.



Is this feature fully tested by web-platform-tests

?

No

N/A



DevTrial instructions

https://tinyurl.com/yc6mvth8


Flag name on chrome://flags

--enable-features=camera-mic-preview


Finch feature name

CameraMicPreview


Requires code in //chrome?

False


Tracking bug

https://issues.chromium.org/330762482


Launch bug

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


Estimated milestones

Origin trial desktop first  126
Origin trial desktop last   137
DevTrial on desktop 122


According to
https://www.chromium.org/blink/launching-features/#deprecation-trial,
deprecation trials should only run for up to 6 milestones before
an extension is required, so this may need to be adjusted



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5100528783851520?gate=5123374989967360

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

Google Groups "blink-dev" 

Re: [blink-dev] Intent to Ship: CSS Anchor Positioning

[Mike Taylor]

On 5/12/24 10:30 PM, fantasai wrote:


On 5/2/24 16:43, Mason Freed wrote:

I think it’s a bit unfair to call this “shipping the first draft”.


I didn't call it one.

Your responses in this thread are often not to what I've actually been 
writing. Please be less sloppy in your reading, it's kindof obnoxious.


I appreciate that this is an important discussion to you and others, but 
it would be good to turn the temperature down on comments like this. We 
like to keep things respectful and constructive on this list (as you 
have in other replies).


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/f6b389fc-e34e-4fc9-871a-4aea1da437fe%40chromium.org.

Re: [blink-dev] Re: Intent to Experiment: Element Capture

[Mike Taylor]

Note: Because you're asking for a renewal of 6 milestones, this will 
require 3 LGTMs.


Can you clarify which milestones you're asking for? You've written 
"(2024-May-14 to 2024-Jun-04)" - that range maps to M125 and M126 stable 
releases.


On 5/10/24 6:44 AM, 'Elad Alon' via blink-dev wrote:


Hello Blink owners,


We are asking for a breaking period of 3 weeks to this API, followed 
by a renewed experiment for the traditional 6 milestones (2024-May-14 
to 2024-Jun-04). A request 
that 
seems similar to me was granted in January 2022 for another API, and 
later shipped successfully with consensus with Mozilla and Apple.



At the time of writing, we have public support 
for 
this API from such companies as Zoom, Jitsi, Mux, DialPad, Whereby, 
Intel and Tella. Tango’s co-founder wrote 
“I 
can't emphasize enough how instrumental this specification would be 
for our product and user experience.” However, none of them have 
signed up for the OT as of yet.



From the OT perspective:

This API allows Web developers to build novel new features; however, 
it requires a non-trivial investment. We are hoping that after giving 
more time, we will see more participation.



From the standardization perspective:

We need time to pick up discussions with Mozilla and Apple again. As 
Chrome’s Security and Privacy experts do not share the concerns 
Mozilla and Apple have previously voiced, it stands to reason that 
additional discussions will allow us to converge - and we will 
prioritize these discussions now.



Additionally, some possibilities remain for API changes that could 
perhaps allow for a compromise, mostly around cross-origin isolation. 
(Full disclosure - this is not my ideal outcome, but it’s a fallback 
possibility worth mentioning.)



Progress made:

 *

Spec:The spec has evolved and is now more mature, dealing better
with such edge cases as loss of “eligibility for restriction.”

 *

TAG:Previously we held off on the request for a TAG review until
we got some more developer feedback about the API shape. Having
received this initial feedback, the TAG request
has now been
submitted.

 *

Signals:Signals have been requested. Mozilla responded. We intend
to prioritize this discussion with them now.

 *

Feedback:Outreach for feedback from the spec community - multiple
issues
were
filed on the spec by Web developers.

 *

WPT:Coverage has recently been extended

.


Reasons to run a new trial:

Gain additional feedback from new participants. Examples for remaining 
areas where new feedback could help include:


 *

Uncover new edge cases which were not uncovered by the spec
authors and reviewers, implementers and current OT participants.
The current edge cases here

demonstrate
how non-obvious these may be.

 *

Validate (or refute) the assumptions we have made about the
viability of an MVP that is missing some functionality. Examples:

 o

Events notifying apps when an element stops/starts being
“eligible for restriction”.

 o

Mechanism to force elements into an “eligible for restriction”
state.

 *

Encourage future OT participation by Web developers, by
demonstrating that risks associated with relying on an origin
trial, while real, are partially offset by a commitment to keep
the OT going until discussions conclude.


Thanks,

Elad

On Monday, November 27, 2023 at 4:00:11 PM UTC+1 Elad Alon wrote:

Thank you for updating, Jan-Ivar. I have now updated this
information in the ChromeStatus entry. I am looking forward to
carry on the discussion about your position in your
standards-positions GitHub repo, in the Element Capture spec repo,
in the Screen Capture CG and in the WebRTC WG.

On Monday, November 27, 2023 at 3:53:51 PM UTC+1
jbru...@mozilla.com wrote:

The Gecko position has been updated to negative. See
https://github.com/mozilla/standards-positions/issues/857

On Monday, November 20, 2023 at 6:41:00 AM UTC-5 Elad Alon wrote:


Contact emails

elad...@chromium.org


Explainer

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

Re: [blink-dev] Intent to Experiment: Origin Trial for Third Party Cookie Deprecation

[Mike Taylor]

This intent is also missing the normal info we have in I2Es, but I found 
https://chromestatus.com/feature/5133113939722240.


LGTM to experiment from M127 to M130 inclusive.

On 5/10/24 9:38 AM, Joshua Hood wrote:



  Contact emails

j...@chromium.org 

wanderv...@chromium.org 


  Experiment Goals

The primary goal of the origin trial is to allow sites to 
performbroader testing of long-term alternatives to third-party 
cookies, ahead of the eventual phaseout of third-party cookies 
scheduled to take place in early 2025 in consultation with the 
CMA.Websites that rely on third-party embedded content or services can 
use the trial to limit third-party cookies while they work with those 
third-parties on long-term alternative solutions for their users based 
on technologies, such as CHIPS, Storage Access API, Related Website 
Sets, FedCM, etc.



  Experiment Risks

No, since this experiment allows sites to opt-in to limiting 
third-party cookies and does not expose any new functionality, the end 
of the experiment will not cause the loss of access to any important 
API or other functionality.



  Ongoing Constraints

None.


  Estimated milestones


  OT desktop start:

127


  OT desktop end:

130


  OT Android start:

127


  OT Android end:

130


  OT WebView start:

N/A


  OT WebView end:

N/A


--
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/CAAp0QgcMhFGWpB2dUJPFt1F0qoJAmshZ4kjHAQz8qz0Bm5aVQg%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/91598ba4-dd70-4da2-a199-2a543bf9aab1%40chromium.org.

Re: [blink-dev] Intent to Experiment: Keyboard-focusable scroll containers Opt Out

[Mike Taylor]

Is there a chromestatus entry associated with this intent? There's a lot 
of information missing from this Intent (see 
https://groups.google.com/a/chromium.org/g/blink-dev/c/LwgSKPBivuM/m/0dRsXWhBAgAJ 
as what is typical) - could you reply with the missing info?


(Did you use ChromeStatus to generate the email?)

Also note that origin trials can only run for 6 milestones initially 
(see https://www.chromium.org/blink/launching-features/#origin-trials) - 
or are you requesting a deprecation trial?


On 5/10/24 12:36 PM, Di Zhang wrote:

Contact emails

dizha...@chromium.org

dom-...@google.com


*Experiment Goals*The feature KeyboardFocusableScrollers changes the 
focusability of a a scroll container. This is an important improvement 
to help make scrollers and contents within scrollers more accessible 
to all users. The goal of this experiment is to collect feedback on 
this change from users who might depend on the previous behavior (when 
a scroller is not focusable by default) and help them adapt to the new 
behavior which will ship in M126. Sites can use this Origin Trial to 
opt out of the KeyboardFocusableScrollers feature.
*Experiment Risks*This experiment is to allow users to opt-out of the 
feature KeyboardFocusableScrollers. There is no risk to loss access to 
any important API or other functionality.

*Ongoing Constraints*None


OT desktop start126OT desktop end135OT Android start126OT Android 
end135OT WebView startN/AOT WebView endN/A



*Note: *The Intent to Ship for Keyboard Focusable Scrollers:
https://groups.google.com/a/chromium.org/g/blink-dev/c/jzMA5vUqNDs/m/VbhNdHgQAgAJ
--
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/c12e3f31-bd5d-4666-ab2b-10db54f26c74n%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/d7825eb3-36bf-4755-a466-e909dfc20530%40chromium.org.

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

[Mike Taylor]

LGTM2

On 5/9/24 10:48 AM, Chris Harrelson wrote:

Thanks for these clarifications.

LGTM1

On Wed, May 8, 2024 at 6:05 PM Daniel Murphy  wrote:

We don't have an objection to this feature existing - it's
actually currently in our backlog. But it is very low in our
priority list. While we can review patches, we will not be able to
dedicate resources for consultation or maintenance.

On Wed, May 8, 2024 at 9:19 AM Brett Wilson 
wrote:

On Wed, May 8, 2024 at 8:39 AM Alex Russell
 wrote:

I'm happy for this to be CrOS first, but would like to
unpack Brett's statement above a bit. If we (MSFT) were to
polish this up for Windows, would patches for that be
accepted?


I can't speak for the browser team. But my current
understanding is that the browser team likes this in principle
but doesn't prioritize it high enough to work on it right now
(this is a correction from my previous assertion). So I'm
pretty sure patches enabling this for other platforms would be
accepted.

Brett
-- 
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/CABiGVV-Zeyv3Rez%2BPQ%2B%2BfW4ihpRCwnnGN2HNxOyXTA7_uWehzw%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/CA%2B4qT32O-zoM4tarHQvoHkmYt%2B%3Dc5iOiPdkueMk%2BhUe7mkYU%2BA%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_QmtkQeDUW%2BEbWtQC4ghvpHFk-Uf65YqYjPMjEQEwwCg%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/201d6c2d-be84-4d6b-9c4b-b1c9f89b0bf8%40chromium.org.

Re: [blink-dev] Intent to Ship: Protected Audience ads reporting - allow cross-origin subframes to send reportEvent() beacons

[Mike Taylor]

On 5/9/24 12:13 PM, Liam Brady wrote:


Can you clarify what the type is for this new header? It reads as
if you're adding a String Item that looks like a boolean, rather
than a Boolean Item. Is that correct? It doesn't seem to be
actually defined in the spec. 



This is meant to be a string literal that is either "true" or "false". 
I have a spec PR <https://github.com/WICG/fenced-frame/pull/159>up to 
formally define that and remove any confusion over what values it's 
expecting. Thanks for calling this out!



Can I ask why string literal vs boolean?


This change would impact the ability of first parties to regulate
and prevent reportEvent beacons. Although this requires mutual
opt-in, I expect scenarios to eventually come up where a site
owner wants to allow cross-origin reportEvent only for certain
origins.


To clarify the first party piece, control over sending reportEvent() 
beacons rests within the worklet owner that invokes 
registerAdBeacon()/registerAdMacro() i.e. seller/ buyer and the 
document loaded with the main ad renderURL (i.e. the 
buyer/advertisers). The first-party (i.e. the publishers) don't have 
control over reportEvent() beacons since that is considered part of 
the overall Protected Audience API, and this feature doesn't change that.



On Wed, May 8, 2024 at 1:27 PM Mike Taylor  wrote:

On 5/8/24 11:30 AM, 'Liam Brady' via blink-dev wrote:


Contact emails

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


Explainer(s)

https://github.com/WICG/turtledove/pull/1134
<https://github.com/WICG/turtledove/pull/1134>


Spec(s)

https://github.com/WICG/fenced-frame/pull/152
<https://github.com/WICG/fenced-frame/pull/152>


Summary

Ad frames (both fenced frames and urn-iframes) created through a
Protected Audience auction, as well as their same-origin nested
iframes, are allowed to call reportEvent() API

<https://github.com/WICG/turtledove/blob/main/Fenced_Frames_Ads_Reporting.md#reportevent-preregistered-destination-url>to
send event-level reports. It's also important for third-parties
on Protected Audience-created ads to have the same measurement
and reporting capabilities for spam detection, brand safety, and
measurement verification. However, the API as it exists currently
has a same-origin child iframe restriction which poses a
complication as described below.


If an ad buyer wins an ad auction and its ad frame is displayed
on a page, it might choose to embed a subframe that points to a
third-party server that hosts the actual ad instead. With this
use case, and with the current state of the reportEvent() API,
the actual ad's document cannot directly call reportEvent() the
way that its embedder can since the document is in a cross-origin
nested iframe. Instead, it has to get its embedder to actually
send the beacon by letting the embedder know via a postMessage.
This will not be an ergonomic solution for this use case.


With this change, a cross-origin subframe can opt in to sending
reportEvent() beacons using its ancestor's reporting metadata by
calling reportEvent() with the parameter crossOriginExposed=true.
This is the same syntax as is currently used by the main render
URL frame to opt in to sending cross-origin automatic beacons
with data (this means the FenceEvent IDL will stay the same).


The main ad render URL frame will opt in with a new
"Allow-Cross-Origin-Event-Reporting" response header. Its valid
values will be true and false, and will default to false when
omitted. This will not be required for documents that are
same-origin to the FencedFrameConfig's mapped url.


Can you clarify what the type is for this new header? It reads as
if you're adding a String Item that looks like a boolean, rather
than a Boolean Item. Is that correct? It doesn't seem to be
actually defined in the spec.

(I filed https://github.com/WICG/fenced-frame/issues/158 for that.)



This is a convenience change (not privacy impacting), as it's
already possible (but cumbersome) for the third-party to
postMessage the parent frame to send the report on their behalf.
For security reasons, the proposal requires opt-ins from both the
main ad frame and the cross-origin iframe.


Blink component

Blink>FencedFrames

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


TAG reviews and status

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

<https://github.com/w3ctag/design-reviews/issues/838#issuecomment-1792881253>


Link to Origi

[blink-dev] Re: “Trial for Disable Third-party Storage Partitioning” not working

[Mike Taylor]

Hello - would you mind filing an issue at 
https://github.com/miketaylr/partitioned-storage-deprecation-trial-feedback 
for discussion?


On 5/9/24 3:28 AM, Accedeme wrote:


Hi there,

Find attached an explanation on what is not working for us.

Kind regards,


El lunes, 9 de enero de 2023 a las 21:46:30 UTC+1, Mike Taylor escribió:

**


*Contact emails*

*

wande...@chromium.org, m...@chromium.org, mike...@chromium.org


Explainer


https://github.com/wanderview/quota-storage-partitioning/blob/main/explainer.md

<https://github.com/wanderview/quota-storage-partitioning/blob/main/explainer.md>


Specification

We’re actively working on adding the relevant spec concepts with
the following WIP PRs (there has been some extensive refactoring
requested, so it’s taken longer than anticipated):


https://github.com/whatwg/html/pull/8447
<https://github.com/whatwg/html/pull/8447>

https://github.com/whatwg/html/pull/8036
<https://github.com/whatwg/html/pull/8036>

https://github.com/whatwg/html/pull/8027
<https://github.com/whatwg/html/pull/8027>

https://github.com/whatwg/storage/pull/144
<https://github.com/whatwg/storage/pull/144>


Summary

We intend to partition a number of APIs in third-party contexts. 
This effort is focused on partitioning APIs above the network
stack.  This includes quota-managed storage, service workers, and
communication APIs (such as BroadcastChannel).  See the explainer
for more details:



https://github.com/wanderview/quota-storage-partitioning/blob/main/explainer.md

<https://github.com/wanderview/quota-storage-partitioning/blob/main/explainer.md>


Blink component

Blink>Storage

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


TAG review

Early Design Review
https://github.com/w3ctag/design-reviews/issues/629
<https://github.com/w3ctag/design-reviews/issues/629>


TAG review status

Closed as “Satisfied”


Risks


Interoperability and Compatibility


Gecko: Shipped/Shipping


WebKit: Shipped/Shipping


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


We’re still investigating the risk for WebView, and if we should
ship in that context at a later date.


Goals for Deprecation Trial


We propose to ship two separate deprecation trials, each for
approximately one year (to give sites plenty of time to test and
update, if  needed). Aspirationally, we would like to ship
partitioned storage in M112, and our goal is to have a deprecation
trial available from M111 to M123.


The first
<https://bugs.chromium.org/p/chromium/issues/detail?id=1404959>is
a general-purpose deprecation trial that will allow a top-level
site to opt into unpartitioned storage, service workers, and
communication APIs for third-party contexts embedded in its site.
This will give sites more time for testing and migrating to
solutions that don’t require partitioned storage.


The second
<https://bugs.chromium.org/p/chromium/issues/detail?id=1399319>is
tailored to a behavior we discovered during the dev-trial that is
known to be used by the Firebase Auth library. This deprecation
trial only allows for unpartitioned `sessionStorage` across a
navigation (which is how the `signInWithRedirect()` method relies
on storing and postMessage’ing authentication tokens). The
Firebase team is aware of the issue (as it also affects Safari
users; Firefox has worked around the breakage by granting
unpartitioned storage via a shim

<https://github.com/mozilla-extensions/webcompat-addon/blob/f58cf9e13b088fde01a0551069d23862e71e6711/src/data/shims.js#L791-L801>),
and is working to migrate their users
<https://firebase.google.com/docs/auth/web/redirect-best-practices>to
cross-browser solutions that are compatible with partitioned
storage. Given the different nature of the Firebase issue, we
think it makes sense to ship a different deprecation trial entirely.


Debuggability

DevTools has support
<https://bugs.chromium.org/p/chromium/issues/detail?id=1296581>for
partitioned storage.



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

Yes for all others; TBD for WebView.


Is this feature fully tested by web-platform-tests

<https://chromium.googlesource.com/chromium/src/+/main/docs/tes

Re: [blink-dev] Intent to Ship: Protected Audience ads reporting - allow cross-origin subframes to send reportEvent() beacons

[Mike Taylor]

On 5/8/24 11:30 AM, 'Liam Brady' via blink-dev wrote:


Contact emails

lbr...@google.com , shivani...@chromium.org 
, jkar...@chromium.org 




Explainer(s)

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




Spec(s)

https://github.com/WICG/fenced-frame/pull/152 




Summary

Ad frames (both fenced frames and urn-iframes) created through a 
Protected Audience auction, as well as their same-origin nested 
iframes, are allowed to call reportEvent() API 
to 
send event-level reports. It's also important for third-parties on 
Protected Audience-created ads to have the same measurement and 
reporting capabilities for spam detection, brand safety, and 
measurement verification. However, the API as it exists currently has 
a same-origin child iframe restriction which poses a complication as 
described below.



If an ad buyer wins an ad auction and its ad frame is displayed on a 
page, it might choose to embed a subframe that points to a third-party 
server that hosts the actual ad instead. With this use case, and with 
the current state of the reportEvent() API, the actual ad's document 
cannot directly call reportEvent() the way that its embedder can since 
the document is in a cross-origin nested iframe. Instead, it has to 
get its embedder to actually send the beacon by letting the embedder 
know via a postMessage. This will not be an ergonomic solution for 
this use case.



With this change, a cross-origin subframe can opt in to sending 
reportEvent() beacons using its ancestor's reporting metadata by 
calling reportEvent() with the parameter crossOriginExposed=true. This 
is the same syntax as is currently used by the main render URL frame 
to opt in to sending cross-origin automatic beacons with data (this 
means the FenceEvent IDL will stay the same).



The main ad render URL frame will opt in with a new 
"Allow-Cross-Origin-Event-Reporting" response header. Its valid values 
will be true and false, and will default to false when omitted. This 
will not be required for documents that are same-origin to the 
FencedFrameConfig's mapped url.


Can you clarify what the type is for this new header? It reads as if 
you're adding a String Item that looks like a boolean, rather than a 
Boolean Item. Is that correct? It doesn't seem to be actually defined in 
the spec.


(I filed https://github.com/WICG/fenced-frame/issues/158 for that.)



This is a convenience change (not privacy impacting), as it's already 
possible (but cumbersome) for the third-party to postMessage the 
parent frame to send the report on their behalf. For security reasons, 
the proposal requires opt-ins from both the main ad frame and the 
cross-origin iframe.



Blink component

Blink>FencedFrames 




TAG reviews and status

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




Link to Origin Trial feedback summary

No Origin Trial performed


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


Supported on all the above platforms except Android WebView.


Debuggability

Additional debugging capabilities are not necessary for these feature 
changes.



Risks


Compatibility

This is an added functionality and is backward compatible.


Interoperability

There are no interoperability risks as no other browsers have decided 
to implement these features yet. We have not received any standards 
positions from Mozilla 
or Webkit 
.



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


Yes. New reportEvent() beacon tests have been added to test 
cross-origin beacons.


fence-report-event-cross-origin-content-initiated.https.html (test 
) 
(results 
)


fence-report-event-cross-origin-nested-urn-iframe.https.html (test 
) 
(results 
)

Re: [blink-dev] Re: Intent to Ship: Document picture-in-picture: propagate user activation

[Mike Taylor]

LGTM3

On 5/8/24 11:56 AM, Daniel Bratell wrote:


LGTM2

/Daniel

On 2024-05-08 17:11, Yoav Weiss (@Shopify) wrote:

LGTM1

On Tuesday, May 7, 2024 at 11:33:01 PM UTC+2 Tommy Steimel wrote:


Contact emails

stei...@chromium.org, liber...@chromium.org



Explainer

None


Specification

https://github.com/WICG/document-picture-in-picture/pull/117



Design docs



https://docs.google.com/document/d/1vtjK3iMEAjcfDCu-qZOYg2zAtTbhohmCX77T1Eu3usQ/edit?usp=sharing




Summary

This makes user activations in a document picture-in-picture
window usable inside its opener window and vice versa. This makes
it more ergonomic to use user-activation-gated APIs, since often
event handlers in the document picture-in-picture window are
actually run in the opener's context, so the opener's context
needs access to the user gesture.



Blink component

Blink>Media>PictureInPicture




TAG review

https://github.com/w3ctag/design-reviews/issues/798#issuecomment-2096837171




TAG review status

Pending


Risks



Interoperability and Compatibility

None



/Gecko/: No signal

(https://github.com/mozilla/standards-positions/issues/670#issuecomment-2096824367

)

/WebKit/: No signal

(https://github.com/WebKit/standards-positions/issues/41#issuecomment-2096824691

)

/Web developers/: No signals

/Other signals/:


Ergonomics

This should improve the ergnomics of user-activation-gated APIs
in document picture-in-picture windows, as the website no longer
needs to ensure that the user gesture occurred in the same
context as the code that is calling the API.



Activation

N/A



Security

One potential risk is that the website could use the same gesture
as two gestures (by using it in the opener and in the
picture-in-picture window). We mitigate this by ensuring that
consuming user activation in one uses it in the other.



WebView application risks

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

N/A



Debuggability

N/A



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

No

Document picture-in-picture is only available on desktop platforms



Is this feature fully tested by web-platform-tests

?

Yes

document-picture-in-picture/propagate-user-activation-from-opener.https.html
document-picture-in-picture/propagate-user-activation-to-opener.https.html



Flag name on chrome://flags

document-picture-in-picture-user-activation


Finch feature name

DocumentPictureInPictureUserActivation


Requires code in //chrome?

False


Tracking bug

https://issues.chromium.org/331246719



Sample links


https://steimelchrome.github.io/document-pip/user-gesture.html



Estimated milestones

Shipping on desktop 126



Anticipated spec changes

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

N/A


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5185710702460928?gate=5078256593403904



Links to previous Intent discussions

Intent to prototype:

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAE-AwApczWrtoZNMqtAJx-%2BNAxVF9Kqim2h1HBrAD3ukXTKgWA%40mail.gmail.com

Re: [blink-dev] Intent to Ship: CSSPageRule to inherit from CSSGroupingRule

[Mike Taylor]

On 5/8/24 3:37 AM, Morten Stenshorne wrote:



Interoperability and Compatibility

Low risk. The one possible issue is if an author uses "instanceof 
CSSGroupingRule" or "instanceof CSSRule" with a page rule object and 
makes incorrect assumptions based on that. However, given that this is 
already shipping in Firefox (and also that in Firefox, even 
CSSStyleRule inherits from CSSGroupingRule, as the spec says - whereas 
Blink still doesn't), the risk should be very low.


I agree the risk is likely very low, or contained to just a few 
sites/applications - have you done any investigation to try to find any 
problematic code examples that you mention (via GitHub search or 
HTTPArchive)?



/Gecko/: Shipped/Shipping 
(https://bugzilla.mozilla.org/show_bug.cgi?id=1868215)
Noting that the patch should ship to Firefox release channel (126) in 
about a week, per https://whattrainisitnow.com/calendar/.


/WebKit/: No signal
Can we request a signal? Or do we have any other indications about their 
intentions here?


/Web developers/: No signals

/Other signals/:


--
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/ba66dbb0-d472-4acd-97f2-a3502c5b74cb%40chromium.org.

Re: [blink-dev] Intent to Experiment: FedCM as a trust signal for the Storage Access API

[Mike Taylor]

LGTM to experiment from 126 to 127 inclusive.

On 5/7/24 10:52 AM, Chris Fredrickson wrote:


Contact emails

johann...@chromium.org, cfred...@chromium.org, y...@chromium.org


Explainer

https://github.com/explainers-by-googlers/storage-access-for-fedcm 




Specification

None (TBD)


Summary

Reconciles the FedCM and Storage Access APIs by making a prior FedCM 
grant a valid reason to automatically approve a storage access request.



When a user grants permission for using their identity with a 3rd 
party Identity Provider (IdP) on a Relying Party (RP), many IdPs 
require third-party cookies to function correctly and securely. This 
proposal aims to satisfy that requirement in a private and secure 
manner by updating the Storage Access API (SAA) permission checks to 
not only accept the permission grant that is given by a storage access 
prompt, but also the permission grant that is given by a FedCM prompt.



A key property of this mechanism is limiting the grant to cases 
explicitly allowed by the RP via the FedCM permissions policy, 
enforcing a per-frame control for the RP and preventing passive 
surveillance by the IdP beyond the capabilities that FedCM already 
grants, as outlined in the Privacy Considerations 
.




Blink component

Blink>StorageAccessAPI


TAG review

None


TAG review status

N/A


Risks



Interoperability and Compatibility

None




Gecko: No public signals, positive initial signals 
. 
We will request a formal position.



WebKit: No signal. We will request a formal position.


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?


N/A, not shipping on Android WebView.


Goals for experimentation

Evaluate the implementation, and the usability of the feature to 
ensure it adequately solves the problem.



Ongoing technical constraints

None


Debuggability

None


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


No. It will not be supported in Android WebView.


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

No. The implementation is primarily in permissions code in //chrome, 
which cannot be tested in WPTs since WPTs use a fake permission 
manager 
in 
Chromium.



Flag name on chrome://flags

#fedcm-with-storage-access-api


Finch feature name

FedCmWithStorageAccessAPI


Non-finch justification

None


Requires code in //chrome?

True


Estimated milestones

M126 through M127 (inclusive).



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5116478702747648 




Links to previous Intent discussions

Intent to prototype: 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAD_OO4iogs7O60r0YcVnDB5aCvs9WUYjWFcuHqcFi5bXLRBOig%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/9a75fe74-ca55-4ddc-93d7-120adfdee49en%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/e4cfab89-5510-4ce8-84f7-b7c4bbe071da%40chromium.org.

Re: [blink-dev] Intent to Implement and Ship: Conversion to RGB in VideoFrame.copyTo()

[Mike Taylor]

+1. Would you mind also filing gecko and webkit positions? I expect them 
to be positive, given the informal signals you have in the spec PRs 
already - but this also lets them know we're moving ahead with shipping. 
Thanks - Mike


On 5/1/24 11:51 AM, Alex Russell wrote:

hey Eugene,

This is an exciting an useful addition! Have you looked into other 
platform APIs that could benefit from being able to explicitly specify 
intermediate format hinting and/or transformation? It's a place where 
(had the TAG been consulted) I would have expected to see a larger 
chain of additions to make this work in other areas, or at least a 
discussion of why they aren't (or are?) being pursued. Have you looked 
into that?


Best,

Alex

On Tuesday, April 30, 2024 at 3:51:01 PM UTC-7 Eugene Zemtsov wrote:

> Can you please request reviews for privacy, security,
enterprise, etc in the chromestatus entry?

Done

On Mon, Apr 29, 2024 at 7:44 AM Mike Taylor
 wrote:

Can you please request reviews for privacy, security,
enterprise, etc in the chromestatus entry?

On 4/25/24 6:19 PM, 'Eugene Zemtsov' via blink-dev wrote:



Contact emails

ezemt...@google.com


Explainer

https://gist.github.com/Djuffin/9e2f98025ead49998524510cfeed8d33
<https://gist.github.com/Djuffin/9e2f98025ead49998524510cfeed8d33>


Specification

https://www.w3.org/TR/webcodecs/#dom-videoframe-copyto
<https://www.w3.org/TR/webcodecs/#dom-videoframe-copyto>


Summary

VideoFrame.copyTo() can convert pixel data to RGB pixel
format Converting YUV video frames to RGB is often required
for processing them in libraries like TensorFlow.js and
OpenCV.js. Previously the only possible way to achieve this
was rendering the frame on a canvas. Specifying
VideoFrameCopyToOptions.format and
VideoFrameCopyToOptions.colorSpace makes it possible to
convert frames to RGB pixel formats by calling
VideoFrame.copyTo() without having to use an extra canvas.


Blink component

Blink>Media>WebCodecs

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


Initial public proposal

https://github.com/w3c/webcodecs/issues/92
<https://github.com/w3c/webcodecs/issues/92>


TAG review

N/A since the change is minor


Risks



Interoperability and Compatibility

None



/Gecko/: Positive
(https://github.com/w3c/webcodecs/pull/754#pullrequestreview-2008590591

<https://github.com/w3c/webcodecs/pull/754#pullrequestreview-2008590591>)

/WebKit/: Positive TPAC 2023. Media working group session.

/Web developers/:
https://github.com/w3c/webcodecs/issues/92#issuecomment-1594083978
<https://github.com/w3c/webcodecs/issues/92#issuecomment-1594083978>


/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

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

Yes

https://wpt.fyi/results/webcodecs
<https://wpt.fyi/results/webcodecs> videoFrame-copyTo-rgb.any.js



Estimated milestones

Shipping on desktop 126

Shipping on Android 126



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4668827056209920
<https://chromestatus.com/feature/4668827056209920>

-- 
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
<mailto:blink-dev+unsubscr...@chromium.org>.
To view this discussion on the web visit

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK8JDrGyVMDipu_nqd%3DKw_9eE2UMtdbiWjbqac0NquwNmm4DMg%40mail.gmail.com

<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK8JDrGyVMDipu_nqd%3DKw_9eE2UMtdbiWjbqac0NquwNmm4DMg%40mail.gmail.com?utm_medium=email_source=footer>.




-- 
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 d