Re: [blink-dev] Intent to Extend Reverse Origin Trial: Trial for SharedArrayBuffers in non-isolated pages on Desktop platforms

[Mike Taylor]

LGTM to extend to 136.

The OT team can help you set up the approvals process - we did the same 
for the Storage Partitioning renewal 
<https://developers.google.com/privacy-sandbox/blog/storage-partitioning-deprecation-trial-renewal>. 
It does require a little bit of work up front, but I think it's a great 
tool to keep features we want to disappear from growing.


On 10/10/24 5:33 AM, Camille Lamy wrote:
Good to know about this new capability. In that case, yes we would 
prefer to only allow DT renewal for sites with existing registrations.


On Wed, Oct 9, 2024 at 4:37 AM Mike Taylor  wrote:

On 10/8/24 8:15 AM, Camille Lamy wrote:



Contact emails

v...@chromium.org cl...@chromium.org


Explainer


https://docs.google.com/document/d/1zDlfvfTJ_9e8Jdc8ehuV4zMEu9ySMCiTGMS9y0GU92k

<https://docs.google.com/document/d/1zDlfvfTJ_9e8Jdc8ehuV4zMEu9ySMCiTGMS9y0GU92k>


Specification

https://tc39.github.io/ecma262/#sec-sharedarraybuffer-objects
<https://tc39.github.io/ecma262/#sec-sharedarraybuffer-objects>


Design docs Including the new security requirements


https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer

<https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer>

Discussion how and what to gate

https://github.com/whatwg/html/issues/4732
<https://github.com/whatwg/html/issues/4732>


Summary

‘SharedArrayBuffers’ (SABs) on desktop platforms are restricted
to cross-origin isolated environments, matching the behavior
we've recently shipped on Android and Firefox. We've performed
that change in Chrome 92. A reverse OT was started to give
developers the option to use SABs in case they are not able to
adopt cross origin isolation yet.

We’ve worked with multiple internal and external users of the OT
to understand their use cases and why they can’t adopt yet. With
COEP:credentialless and iframes credentialless now available, the
SAB non COI usage went further down.

Unfortunately, the cascading requirements of COEP are still a
blocker for COI adoption. Some of the users of the OT rely
heavily on credentialled cross-origin subresources, so
credentialless modes are not an option for them. And their apps
are complex enough that they are still blocked on child iframes
supporting COEP.

To address this, we’ve explored ways of enabling COI that would
take advantage of process isolation in order to waive
requirements on child frames to enforce COEP.

We’ll be sending out the I2E for Document-Isolation-Policy in the
coming weeks and are aiming to OT it starting with M132. Giving
developers 3 milestones to verify and provide feedback, we’re
aiming for a release in M135.

As we know the cascading is the final blocker for COI adoption
and therefore SAB usage on Desktop, we’re asking to extend the OT
to M136.


Blink component

Blink>JavaScript

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


Search tags

SharedArrayBuffer
<https://chromestatus.com/features#tags:SharedArrayBuffer>,SAB
<https://chromestatus.com/features#tags:SAB>


TAG review


https://github.com/w3ctag/design-reviews/issues/471
<https://github.com/w3ctag/design-reviews/issues/471>


TAG review status


Closed


Risks


Interoperability and Compatibility

We expect this change to negatively impact developers using
`SharedArrayBuffer` today. Chrome was the only platform where
SABs have been available without COOP/COEP. Therefore we need to
give developers the right capabilities and a clear path forward
to ensure they have enough time to adopt. We aim to mitigate
these risks by adopting a longer-than-usual depreciation period
with console warnings/issues and a reverse origin trial.

Good news is usage is down to ~0.0223%

<https://chromestatus.com/metrics/feature/popularity#V8SharedArrayBufferConstructedWithoutIsolation>page
loads and that other browsers have or are shipping SABs again
gated behind COOP/COEP. Bad news is that Chromium was the only
browser that supported SABs without COI, therefore we need to
provide a migration path to not break existing sites.


Looking at
https://chromestatus.com/metrics/feature/timeline/popularity/3721
- it seems that usage has ~doubled in the past month. Do you have
any concerns about this? Have you considered only allowing DT
renewals for sites with existing registrations (that's a new
capability we have)?


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

Re: [blink-dev] Intent to Experiment: Summarizer API

[Mike Taylor]

LGTM to experiment from 131 to 136 inclusive.

On 10/9/24 7:58 PM, Domenic Denicola wrote:



Contact emails

dome...@chromium.org, fer...@chromium.org, kenjibah...@chromium.org


Explainer

https://github.com/explainers-by-googlers/writing-assistance-apis/blob/main/README.md 




Specification

None yet, although we'll be writing one during the experimentation period.


Summary

A JavaScript API for producing summaries of input text, backed by an 
AI language model.



Blink component

Blink>AI>Summarization 




TAG review

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




TAG review status

Pending


Risks


Interoperability and Compatibility

This feature has definite interoperability and compatibility risks, 
due to the likelihood that different implementations will use 
different language models, prompts, and fine-tunings, and even within 
a single implementation such as Chrome, these pieces will likely 
change over time. Additionally, not all browsers and operating systems 
will have a built-in language model to expose, and not all devices 
will be powerful enough to run one effectively.



We are taking a variety of steps to attempt to mitigate these risks. 
For example, the specification is designed to allow the API to be 
backed by a cloud-based language model. This approach could extend the 
functionality to a wider range of devices and users. The API is 
designed to abstract away the specifics of the underlying language 
model, including prompts and fine-tuning. This prevents developers 
from relying on specific outputs, ensuring they receive a generalized 
summary rather than structured data that might vary across 
implementations. Finally, the API surface is designed with many clear 
points of failure, that encourage the developer to probe for 
capabilities ahead of time and fall back to other techniques if a 
capability is not available.



Nevertheless, interoperability and compatibility risk remains high for 
these sorts of APIs, and we'll be closely monitoring it during the 
prototyping period.



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



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



Web developers: Mixed signals 
(https://github.com/WICG/proposals/issues/163 
). Prototyping with 
partners behind a flag revealed enthusiasm and many prototypes built, 
from which we drew the discussion of potential use cases [1]. Feedback 
on the WICG thread was more mixed. Some themes we saw include: asking 
for more capabilities (e.g. full prompting of a language model instead 
of higher-level APIs (our response at [2]); multi-modal support); 
desire to make sure the API actually works robustly in many real-world 
use cases; removal of any safety/ethical safeguards; and confusion 
about client-side vs. cloud APIs.



[1]: 
https://github.com/WICG/writing-assistance-apis/blob/main/README.md#summarizer-api 



[2]: 
https://github.com/WICG/writing-assistance-apis/blob/main/README.md#directly-exposing-a-prompt-api) 




Other signals:


Activation

This feature would definitely benefit from having polyfills, backed by 
any of: cloud services, lazily-loaded client-side models using WebGPU, 
or the web developer's own server. We anticipate seeing an ecosystem 
of such polyfills grow as more developers experiment with this API.




WebView application risks

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


None



Goals for experimentation

We're most interested in feedback on whether the summarization quality 
we can provide is useful to sites, and whether the options we've 
defined for controlling the summarization are useful. Additionally, we 
want to learn about the impact of the current API's limitations, e.g. 
maximum input length, to determine where we should spend our best 
effort lifting those limits.



The origin trial will be limited to English-language input to start. 
We are hoping to add support for more languages over time. Learning 
how much of a limitation this is, and which languages ought to be 
prioritized, will also be helpful.



Finally, we're also interested in feedback about the API shape and 
ease of use.



Ongoing technical constrai

Re: [blink-dev] Intent to Ship: Support external SVG resources for 'clip-path', 'fill', 'stroke' and 'marker-*' properties

[Mike Taylor]

LGTM2

On 10/9/24 8:52 AM, Yoav Weiss (@Shopify) wrote:

LGTM1

On Monday, October 7, 2024 at 3:47:43 PM UTC+2 f...@opera.com wrote:

On Mon, Oct 7, 2024 at 6:15 AM Domenic Denicola
 wrote:

This looks like a great straightforward way of making the
platform more consistent. Just a few minor questions for the
intent before approving...

On Fri, Oct 4, 2024 at 5:18 PM Chromestatus
mailto:ad...@cr-status.appspotmail.com>> wrote:


Contact emails

f...@opera.com


Explainer

None


Can you write up a quick paragraph or two explaining this
feature, and why web developers are excited about it?


This is what I wrote in the "Motivation" field:

"This feature allows easily sharing SVG paint servers, clip paths
and markers between different documents, and, for example, having
a library of such resources."

This allows creating reusable "components" in the form of clip
paths, gradients, patterns and markers. This is in a way similar
to how you, today, can have an external SVG with "symbols" that
can be reused via .



Specification

https://svgwg.org/svg2-draft/linking.html#URLReference



Summary

Allow external references for clip paths, markers, and
paint servers (for the 'fill' and 'stroke' properties).
For example, clip-path: url("resources.svg#myPath").



Blink component

Blink>SVG





Search tags

svg 


TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

The main interoperability risk is that these properties
still do not support referencing external resource
document in all browsers (not supported in WebKit yet). No
compatibility issues are known from similar cases (for
example 'mask-image'), and it's assumed that the support
in these additional set of properties will be similar.



/Gecko/: Shipped/Shipping Has been shipping for a long
time. No attempt was made to dig up the ancient scrolls
containing the relevant release notes.

/WebKit/: No signal


Can you file for signals?


https://github.com/WebKit/standards-positions/issues/411




/Web developers/: Strongly positive Has 123 stars/+1s when
this is being written.

/Other signals/:


Security

Requests the resources in the same way as similar
properties - for example 'mask-image' (same-origin
credentials mode).



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

Supported the same way as any other resource referenced
via CSS.



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-masking/clip-path/clip-path-url-reference-external.html



https://wpt.fyi/results/svg/linking/reftests/url-processing-fetch-properties-001.sub.svg



https://wpt.fyi/results/svg/linking/reftests/url-processing-fetch-properties-002.sub.svg



https://wpt.fyi/results/svg/painting/reftests/gradient-external-reference.svg



https://wpt.fyi/results/svg/painting/reftests/marker-external-reference.svg



https://wpt.fyi/results/svg/painting/reftests/pattern-external-reference.svg
   

Re: [blink-dev] Intent to Ship: Exempt Speculation-Rules Header from CSP restrictions

[Mike Taylor]

Got it, thanks for confirming Domenic.

LGTM2

On 10/9/24 2:10 AM, Yoav Weiss (@Shopify) wrote:

LGTM1

I agree that this is a web-exposed bug fix, and that the likelihood of 
negative impact here at this stage of the feature's life is slim.


On Wednesday, October 9, 2024 at 4:44:10 AM UTC+2 Domenic Denicola wrote:

(Note: feature owner hat on, API owner hat off.)

On Wed, Oct 9, 2024 at 11:24 AM Mike Taylor
 wrote:


On 10/8/24 1:05 PM, Liviu Tinta wrote:



Contact emails


dome...@chromium.org, jbro...@chromium.org
<mailto:jbro...@chromium.org>,
liviuti...@chromium.org <mailto:liviuti...@chromium.org>


Explainer



https://wicg.github.io/nav-speculation/speculation-rules.html#security-xss

<https://wicg.github.io/nav-speculation/speculation-rules.html#security-xss>


Specification



https://wicg.github.io/nav-speculation/speculation-rules.html#security-xss

<https://wicg.github.io/nav-speculation/speculation-rules.html#security-xss>


Summary


This is somewhat of a bug-fix, but it's a web-exposed
bug fix which deserves full web platform security
review, so we're using the Intent to Ship process.
When we initially shipped the Speculation-Rules
header, we reused much of the architecture from the

Re: [blink-dev] Intent to Extend Reverse Origin Trial: Trial for SharedArrayBuffers in non-isolated pages on Desktop platforms

[Mike Taylor]

On 10/8/24 8:15 AM, Camille Lamy wrote:



Contact emails

v...@chromium.org cl...@chromium.org


Explainer

https://docs.google.com/document/d/1zDlfvfTJ_9e8Jdc8ehuV4zMEu9ySMCiTGMS9y0GU92k 




Specification

https://tc39.github.io/ecma262/#sec-sharedarraybuffer-objects 




Design docs Including the new security requirements

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer 



Discussion how and what to gate

https://github.com/whatwg/html/issues/4732 




Summary

‘SharedArrayBuffers’ (SABs) on desktop platforms are restricted to 
cross-origin isolated environments, matching the behavior we've 
recently shipped on Android and Firefox. We've performed that change 
in Chrome 92. A reverse OT was started to give developers the option 
to use SABs in case they are not able to adopt cross origin isolation yet.


We’ve worked with multiple internal and external users of the OT to 
understand their use cases and why they can’t adopt yet. With 
COEP:credentialless and iframes credentialless now available, the SAB 
non COI usage went further down.


Unfortunately, the cascading requirements of COEP are still a blocker 
for COI adoption. Some of the users of the OT rely heavily on 
credentialled cross-origin subresources, so credentialless modes are 
not an option for them. And their apps are complex enough that they 
are still blocked on child iframes supporting COEP.


To address this, we’ve explored ways of enabling COI that would take 
advantage of process isolation in order to waive requirements on child 
frames to enforce COEP.


We’ll be sending out the I2E for Document-Isolation-Policy in the 
coming weeks and are aiming to OT it starting with M132. Giving 
developers 3 milestones to verify and provide feedback, we’re aiming 
for a release in M135.


As we know the cascading is the final blocker for COI adoption and 
therefore SAB usage on Desktop, we’re asking to extend the OT to M136.



Blink component

Blink>JavaScript 




Search tags

SharedArrayBuffer 
,SAB 




TAG review


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



TAG review status


Closed


Risks


Interoperability and Compatibility

We expect this change to negatively impact developers using 
`SharedArrayBuffer` today. Chrome was the only platform where SABs 
have been available without COOP/COEP. Therefore we need to give 
developers the right capabilities and a clear path forward to ensure 
they have enough time to adopt. We aim to mitigate these risks by 
adopting a longer-than-usual depreciation period with console 
warnings/issues and a reverse origin trial.


Good news is usage is down to ~0.0223% 
page 
loads and that other browsers have or are shipping SABs again gated 
behind COOP/COEP. Bad news is that Chromium was the only browser that 
supported SABs without COI, therefore we need to provide a migration 
path to not break existing sites.


Looking at 
https://chromestatus.com/metrics/feature/timeline/popularity/3721 - it 
seems that usage has ~doubled in the past month. Do you have any 
concerns about this? Have you considered only allowing DT renewals for 
sites with existing registrations (that's a new capability we have)?


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


WebKit: Added COOP/COEP and SAB support recently gated behind COOP/COEP


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

No - This OT is only for desktop, as this was the only platform where 
SABs have been available without COOP/COEP.


Android re-enabled SABs gated behind 
COOP/COEP:https://chromestatus.com/feature/5171863141482496 




Tracking bug

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




Launch bug

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




Blink-dev Thread

Planning isolation requirements (COOP/COEP) for SharedArrayBuffer 

Re: [blink-dev] Intent to Ship: Exempt Speculation-Rules Header from CSP restrictions

[Mike Taylor]

On 10/8/24 1:05 PM, Liviu Tinta wrote:



Contact emails


dome...@chromium.org, jbro...@chromium.org,
liviuti...@chromium.org


Explainer



https://wicg.github.io/nav-speculation/speculation-rules.html#security-xss


Specification



https://wicg.github.io/nav-speculation/speculation-rules.html#security-xss


Summary


This is somewhat of a bug-fix, but it's a web-exposed bug fix
which deserves full web platform security review, so we're
using the Intent to Ship process. When we initially shipped
the Speculation-Rules header, we reused much of the
architecture from the 

Re: [blink-dev] Intent to Ship: Disallow spaces in non-file:// URL hosts

[Mike Taylor]

LGTM3

On 10/8/24 6:59 AM, Chris Harrelson wrote:

LGTM2

On Mon, Oct 7, 2024, 11:51 PM Daniel Bratell  wrote:

LGTM1

/Daniel

On 2024-10-08 02:11, 'Daniel Clark' via blink-dev wrote:



Contact emails

dan...@microsoft.com 


Explainer

None


Specification

https://url.spec.whatwg.org/#forbidden-host-code-point



Summary

Perspec
,URL
hostnames cannot contain the space character, but currently URL
parsing in Chromium allows spaces in the hostname. This causes
Chromium to fail several tests included in the Interop2024HTTPS
URLs for WebSocket

andURL


focus areas.

To bring Chromium into spec compliance, ideally we would ban
spaces from allspecial 
URL hosts, but a difficulty with this is spaces could be used in
the host part in Windows file:// URLs (see discussion
athttps://github.com/whatwg/url/issues/599
).

So, the scope of this Intent is for the change to bring Chromium
closer to spec compliance by making spaces fail URL hostname
parsing for non-file:// URLs only.

For the full change and implementation details, see
https://chromium-review.googlesource.com/c/chromium/src/+/5753305


Blink component

Blink>Network




TAG review

None. This is implementing previously specced behavior, and Gecko
and WebKit already treat spaces in URL hostnames as URL parse errors.


TAG review status

Not applicable


Risks


Interoperability and Compatibility

From an interoperability perspective this is strictly positive:
the change brings Chromium closer to spec compliance and
interoperable URL parsing behavior with other engines. There is
some compat risk given this is a web-visible change to existing
URL parsing behavior. I believe the risk to be reasonable given
that we are now aligning with the 2 other browser engines, and
excluding the potentially risky file:// URL case.

In 2021, data was collected about the use of space and other
not-allowed-per-spec characters in hostnames. See here
 for
that data and some discussion. On Windows, space was escaped in
0.004143% of hostnames parsed. /Gecko/: Shipped/Shipping
/WebKit/: Shipped/Shipping /Web developers/: No signals /Other
signals/: This issue is causing Chromium/Edge failures in the
Interop2024 HTTPS URLs for WebSocket

//and//URL

focus
areas.


WebView application risks

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

None


Debuggability

None


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

Yes


Is this feature fully tested by web-platform-tests

?

Yes


Flag name on chrome://flags

None


Finch feature name

kDisallowSpaceCharacterInURLHostParsing


Non-finch justification

None


Requires code in //chrome?

False


Estimated milestones

Shipping on desktop



131


Anticipated spec changes

Depending on the result of
https://github.com/whatwg/url/issues/599
, file:// URLs may
either change to follow the same behavior of disallowing spaces,
or (more likely) change to be treated as having opaque hostnames
which would permanently allow them to have spaces. Either
resolution is compatible with this Intent since we are not
changing the behavior for file:// URLs.


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5083335148437504?gate=5097602358706176


This intent message was gen

Re: [blink-dev] Intent to Ship: Improvements to styling structure of and elements

[Mike Taylor]

LGTM3

On 10/7/24 8:08 AM, Chris Harrelson wrote:

LGTM2

On Sun, Oct 6, 2024 at 9:31 PM Domenic Denicola  
wrote:


LGTM1.

This seems like a great, well-thought-out, and widely-reviewed
improvement to the status quo. I appreciate the detailed compat
notes, and the mitigations taken so far (testing in Canary and
Dev). A use counter would have been ideal, but I don't think we
should hold this up waiting for that, especially since you have a
Finch feature so if this somehow causes terrible regressions, we
can flip it back. (I agree with your assumption that using
`display: contents` on details is likely rare.)

On Fri, Oct 4, 2024 at 11:54 PM David Baron 
wrote:


Contact emails

dba...@chromium.org


Explainer

https://github.com/dbaron/details-styling
https://dbaron.github.io/details-styling/phase-1


Specification


https://html.spec.whatwg.org/multipage/rendering.html#the-details-and-summary-elements


Summary

Support more CSS styling for the structure of  and
 elements to allow these elements to be used in more
cases where disclosure widgets or accordion widgets are built
on the web. In particular, this change removes restrictions
that prevented setting the display property on these elements,
and adds a ::details-content pseudo-element to style the
container for the part that expands and collapses.



Blink component

Blink>HTML>Details




TAG review

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


TAG review status

Issues addressed


Risks



Interoperability and Compatibility

There's some interoperability and compatibility risk around
changes to  styling. Currently styling of the list
marker is not interoperable as there are two different
approaches, one taken by Gecko and (current) Chromium, and
another taken by WebKit (which was previously shared with
Chromium). However, this initial phase of work doesn't address
marker styling very much. In most cases, the changes being
proposed here are compatible with existing content. However,
they do include one breaking change, in that they make the
 matched by the ::details-content pseudo-element be
display:block by default rather than being display:block when
closed and display:contents when open. This could potentially
break content that is currently using display:contents on the
details element, although such content is likely rare, and
could be easily fixed by explicitly setting the old style
(details[open]::details-content { display: contents }). This
change is included because it significantly improves the
developer ergonomics of using ::details-content; however, if
it turns out to cause compatibility issues then it could be
rolled back (at the cost of developer ergonomics for users of
::details-content, some of which who would need to explicitly
specify display to override the display:contents default). For
more details, see https://crrev.com/c/5594192 .


In order to get additional testing to uncover problems, this
feature was enabled for 50% of canary and dev channels from
early July until mid September. During that time no issues
were reported (or at least none that found their way to me).



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

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

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

see above regarding Compatibility risks



Debuggability

https://issues.chromium.org/40280502 describes one small-ish
issue with the way devtools shows the resulting CSS cascade.



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

Yes


Is this feature fully tested by web-platform-tests

?

Yes


https://wpt.fyi/results/html/rendering/the-details-element/details-display-type-001.html

https://wpt.fyi/results/html/rendering/the-details-element/details-display-type-002.html

http

Re: [blink-dev] Intent to Extend Experiment: Cookie Deprecation Label

[Mike Taylor]

OK - thanks John. LGTM to extend until 132 inclusive.

On 10/1/24 11:49 AM, John Delaney wrote:

Hey Mike,

We also plan to continue sending labels for the "label_only" groups as 
well, overall this <8.5% of browsers (these labels are also subject to 
a number of eligibility requirements).


Currently we plan to continue extending this until the new approach is 
shipped, but we will provide any updates on future I2EEs.



On Mon, Sep 30, 2024 at 6:03 PM Mike Taylor  
wrote:


Hey John,

Can you confirm these labels will only be sent to the 1% "Mode B"
population, until the new user choice approach is shipped? Or is
something else planned?

thx,
Mike

On 9/30/24 10:12 AM, John Delaney wrote:


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

As noted on the I2D&R for Third Party Cookies

<https://groups.google.com/a/chromium.org/g/blink-dev/c/RG0oLYQ0f2I/m/P62t84F1AQAJ)>:

We recently announced a new path focused on elevating user
choice, instead of third-party cookie deprecation. We will
continue to support and invest in the Privacy Sandbox
technologies. While we can't predict what exact user preferences
will be, it’s important for businesses and developers to prepare
for a likely increase in Chrome browsers without support for
third-party cookies, and to continue investing in
privacy-enhancing technologies.

*
*

The cookie deprecation labels are useful for developers to
evaluate and optimize deployments of the Privacy Sandbox APIs
prior to any changes in the number of browsers which support
third-party cookies, so we are asking to extend the current set
of labels

<https://developers.google.com/privacy-sandbox/relevance/setup/web/chrome-facilitated-testing>for
three more milestones.


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>

https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/v3PiIzm1M-Y
<https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/v3PiIzm1M-Y>

Goals for experimentation

Continued deployment and evaluation of Privacy Sandbox Ads APIs.

*
*

Experimental timeline

This feature was previously approved to run up until Chrome 129.

*
*

We would like to extend this for Chrome 130 through 132.

*
*

Any risks when the experiment finishes?

Minimal, the cookie deprecation labels are only available for a
subset of users and must be requested.

*
*

Reason this experiment is being extended

We have received feedback that these labels are useful for ad
tech companies to evaluate and optimize the APIs in preparation
for changes to third party cookie availability.

*
*

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/694264ea-eb98-41a8-a798-62d28f7715c5n%40chromium.org

<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/694264ea-eb98-41a8-a798-62d28f7715c5n%40chromium.org?utm_medium=email&utm_source=footer>.




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

Re: [blink-dev] Intent to Experiment: Storage Access Headers

[Mike Taylor]

On 10/3/24 4:05 PM, 'Sam LeDoux' via blink-dev wrote:



Contact emails

sled...@chromium.org, cfred...@chromium.org, johann...@chromium.org 




Explainer

https://github.com/cfredric/storage-access-headers 




Specification

None


Summary

Storage Access Headers offer an alternate way for authenticated embeds 
to opt in for unpartitioned cookies. These headers indicate whether 
embedded resources would like to load with permission they have 
already been granted, reducing loads and latency overall for these use 
cases.




Blink component

Blink>StorageAccessAPI 




TAG review

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




TAG review status

Completed


Risks


Interoperability and Compatibility

There is a small compatibility risk as this feature involves sending 
the Origin header in new contexts. We're working to limit the new 
Origin headers to be included only on "inactive" requests, in order to 
minimize compat impact.


Hey Sam, could you expand on the compat risk here? What might this 
break, and why?



WebView application risks

Not available on WebView



Goals for experimentation

This experiment would allow us to receive and incorporate feedback on 
the browser's application of the `Sec-Fetch-Storage-Access` request 
header, as well as the browser's handling of the 
`Activate-Storage-Access` header before the feature is fully launched.



Experiment behavior

This experiment would rely on an Origin Trial (OT) to test the Storage 
Access Header feature. Once the OT is active for an origin, requests 
to the same context that it was enabled on will include the 
`Sec-Fetch-Storage-Access` header, and the browser will handle 
responses with the `Activate-Storage-Access` header in accordance with 
the feature’s description.



This experiment relies on the use of a persistent OT 
. 
Developers opting into the use of Storage Access Headers should not 
expect the `Sec-Fetch-Storage-Access` request header to be included on 
initial navigations to their origin as the feature will only be active 
after receiving its first OT token. Additionally, all subsequent 
navigations to an opted-in origin should include the token, otherwise 
the browser will take this as a signal that the origin is no longer 
participating in the trial.



Ongoing technical constraints

None


Debuggability

Currently best debugged via chrome://net-export logs, as Chrome 
DevTools does not show the full chain of network events. We may add 
improved debugging capabilities in the future.




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

No.

Supported for Mac, Windows, Linux, Chrome OS, and Android.


Is this feature fully tested by web-platform-tests

?

No


Flag name on chrome://flags

#storage-access-headers


Requires code in //chrome?

Yes


Tracking bug

https://issues.chromium.org/issues/332335089 




Launch bug

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




Estimated milestones

Experiment desktop first130


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6146353156849664 




Links to previous Intent discussions

Intent to Prototype: 
https://groups.google.com/a/chromium.org/g/blink-dev/c/yfxV-jLMqNg/m/NJFVBEAyAQAJ



--
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/CABa1CXyYbxwh%3DPdnigTW80d9jez_835R1SV1bQPDjvk1ra5G4g%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/e01493f5-2ce8-4635-aa4b-659f9972d462%40chromium.org.

Re: [blink-dev] Intent to Ship: Fetch: Request.bytes() and Response.bytes()

[Mike Taylor]

LGTM1

On 10/4/24 6:41 AM, Chromestatus wrote:



Contact emails

perryuw...@chromium.org


Explainer

None


Specification

https://fetch.spec.whatwg.org/#dom-body-bytes


Summary

Add a bytes() method to the Request and Response interfaces, which 
returns a promise that resolves with a Uint8Array. While Request and 
Response have an arrayBuffer() method, we can't read directly from a 
buffer. We have to create a view such as a Uint8Array to read it. The 
bytes() method improves the ergonomics of getting the body of Request 
and Response.




Blink component

Blink>Network>FetchAPI 
Network>FetchAPI> 




TAG review

None


TAG review status

Issues addressed


Risks



Interoperability and Compatibility

None



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


/WebKit/: Shipped/Shipping 
(https://bugs.webkit.org/show_bug.cgi?id=274102)


/Web developers/: No signals

/Other signals/:


Activation

The feature can be easily polyfilled.



Security

The feature adds no capabilities that developers don't already have. 
The implementation mostly reuses existing logic, reducing the security 
risk.




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

Automatically supported as a feature implemented in WebIDL.



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
Presumably this is a mistake, given 
https://github.com/web-platform-tests/wpt/pull/46198/files



Flag name on chrome://flags

FetchBodyBytes


Finch feature name

None


Non-finch justification

None


Requires code in //chrome?

False


Tracking bug

https://issues.chromium.org/issues/340206277


Estimated milestones

Shipping on desktop 132
Shipping on Android 132
Shipping on WebView 132



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/5239268180754432?gate=6644384851034112

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/66ffc642.2b0a0220.d54b7.14c4.GAE%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/71723fdb-7b2f-4e0b-9131-7683637f60c5%40chromium.org.

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

[Mike Taylor]

On 10/4/24 1:56 AM, 'Marja Hölttä' via blink-dev wrote:

miketaylr@: It's very likely that the privacy & security reviews will 
be very straightforward in comparison to the API owners approval. This 
is essentially a JavaScript feature (though, not a semantics changing 
one) so it doesn't have privacy implications. Security-wise, it's 
much less risky than other V8 features on average, so I don't expect 
much work to be coming from that direction either. That's why I kicked 
off the API owner discussion first, since that's the most interesting 
one. Would it be ok to do the privacy & security reviews only after 
this discussion has converged?


We ask that everyone /request/ the various review gates before we give 
OWNERs approvals - but we don't block on the resolution of said reviews. 
Also, if you already have internal reviews (which is likely true given 
that you've already run an Origin Trial), you can just link to the 
internal launch bug and use the Request N/A button.


--
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/448934fc-6d9d-4e09-a728-64bf28201636%40chromium.org.

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

[Mike Taylor]

Thanks Akash - these changes help me better understand the features 
(especially the links to how registration / reporting works).


LGTM2

On 10/2/24 1:09 PM, 'Akash Nadan' via blink-dev wrote:

Hi All,

I just wanted to flag that we have also updated the example with 
diagrams that better show a comparison of the behavior before vs. 
after using this feature: 
https://github.com/WICG/attribution-reporting-api/blob/main/attribution_scopes.md#attribution-scope-examples


Thanks,
Akash

On Friday, September 27, 2024 at 11:00:09 AM UTC-7 Akash Nadan wrote:

Hi Alex,

We have updated the code in that example to now show a comparison
of the behavior before vs. after using this
feature: 
https://github.com/WICG/attribution-reporting-api/blob/main/attribution_scopes.md#example-1-distinct-attribution-scopes-comparison-with-attribution-filters



Let me know if you have any follow up questions on the example.

Thanks,
Akash

On Thursday, September 26, 2024 at 1:56:03 PM UTC-7 Alex Russell
wrote:

Hey Akash,

That example was the one I was referring to when asking for
more. This doesn't show a full in-situ example of how to use
this or what code would have been necessary before (or what
the "before" code's deficiencies were).

Best,

Alex

On Thu, Sep 26, 2024 at 11:07 AM Akash Nadan
 wrote:

Hi Alex,

We have the following end-to-end example in the explainer
that shows how this would work for a more real example:

https://github.com/WICG/attribution-reporting-api/blob/main/attribution_scopes.md#attribution-scope-examples

Let me know if you have any questions on the example! We
are also considering how to best add demo code for this
feature although that may take a little longer to share.

Thanks!
Akash


On Wednesday, September 25, 2024 at 8:43:21 AM UTC-7 Alex
Russell wrote:

Hey Akash,

This looks pretty uncontroversial, but I'm not sure
from the Explainer how this fits together in an
end-to-end scenario. Is there a fuller chunk of
example code you could point me at? Or update the
explainer to show how this works in practice?

Best,

Alex

On Tuesday, September 10, 2024 at 2:33:12 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 changes to the
Attribution Reporting API focused on:

 *

providing more control over the attribution
filtering


This change is based on ad-tech feedback and the
need for more fine grained filtering controls
before the attribution process takes place.


Currently the API performs filtering after a
source is chosen based on matching  fields. This results in
API callers either not receiving attribution
reports or incorrect attribution in scenarios
where there are multiple different
advertisers/campaigns that all convert on the same
  

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

[Mike Taylor]

Thanks LGTM to extend to 133 inclusive, given the progress on the 
proposal in the WG, and iteration on the API design/UI .


If you were to request another extension down the road, I would expect 
to see further progress on the spec PR, and updated tests to match.


thanks,
Mike

On 9/30/24 9:01 AM, Yi Gu wrote:



Contact emails

y...@chromium.org, tanzach...@chromium.org 
, cbiesin...@chromium.org, 




Explainer

https://github.com/w3c-fedid/active-mode


Specification

None


Summary


We plan to experiment with two new extensions for the
Federated Credential Management (FedCM) API:


 *

Button Mode API

 o

The button mode lets websites trigger FedCM directly
when a user clicks a button (like a "Sign-in with IdP"
button). This means FedCM will always display a
visible user interface for login, in contrast to the
widget mode where no UI is shown if a user’s login
status is logged out.

 o

When the FedCM API is used in "button mode" and a user
isn't logged in, they'll be taken to the IdP login
screen (in a pop-up window). Since this happens in
response to a clear user action, the UI might even be
more prominent (e.g., centered and modal) compared to
the more subtle UI of widget mode.


 *

Use Other Account API

 o

With this API, an Identity Provider can request the
browser to show a button that allows users to choose
other accounts.


Blink component

Blink>Identity>FedCM 




TAG review

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




TAG review status

Pending


Chromium Trial Name

FedCmButtonMode


Origin Trial documentation link

https://github.com/w3c-fedid/FedCM/blob/main/explorations/HOWTO-chrome.md#button-mode-api


WebFeature UseCounter name

kFedCmButtonMode


Risks


Interoperability and Compatibility



These are extensions to the FedCM API. Apple and Mozilla have
both expressed a positive opinion on the initial FedCM API
[1]. They have not yet shipped but Mozilla is prototyping [2].
If a user agent chooses not to implement these extensions, the
sign-in flow should not be affected in that user agent because
developers can fallback to the existing federated sign-in
mechanisms.


[1]

https://groups.google.com/a/chromium.org/g/blink-dev/c/URpYPPH-YQ4/m/bzghj9N3AQAJ



[2]

https://groups.google.com/a/mozilla.org/g/dev-platform/c/ncmUwK1uO98/m/COhPA4ZrAAAJ




Gecko: No signal


WebKit: No signal


Web developers: Positive
(https://github.com/fedidcg/FedCM/issues/442
) These features
are being developed to address existing feedback for the FedCM
API.


Other signals:


Activation



Similar to the FedCM API, we deliberately leave the bulk of
the work to the IdP to ensure that minimal RP change is needed.


This feature, specifically, is one that can be currently
controlled by IdP (via JS SDK for “button mode”, via
server-side config for “use other account”), so we expect
activation to have a similar profile as FedCM: immediately
enabled to websites (without redeployment) by IdPs making use
of it (by redeploying their JS SDKs).



Security



The button mode shares most of the security properties from
the widget mode. e.g. honoring CSP, CORS, using security
headers, not asking users to type in the browser UI etc.


It’s worth noting that the pop-up window has the same web
platform properties as what one would get with
window.open(url,””,”popup,noopener,noreferrer”) that loads the
login_url. It is important to note that there's no
communication allowed between the website and this pop-up
(e.g. no postMessage, no window.opener). We have shipped
LoginStatus API and Error API in FedCM that use this type of
pop-up window.



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?

  

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

[Mike Taylor]

Could you also please request the various Privacy, Security, Enterprise, 
etc. bits in your Chromestatus entry?


On 10/1/24 5:31 AM, Yoav Weiss (@Shopify) wrote:

Thanks for working on this! This is super interesting!!

On Monday, September 30, 2024 at 4:12:25 PM UTC+2 Marja Hölttä wrote:

(Sending this I2S as recommended by API owners, to continue the
discussion about shipping this feature.)
Contact emailsma...@google.com, lesz...@google.com



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




Specificationhttps://explainers-by-googlers.github.io/explicit-javascript-compile-hints-file-based




We don't typically ship features with specs on personal or 
Google-owned repos.
I think it would be good to try and move this to an incubation venue 
(e.g. WICG).
This would be a better place from an IPR perspective (i.e. allow 
contributions outside of Google), and will help us validate that this 
is something that has at least some industry support.




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 componentBlink>JavaScript



TAG review


Did you file for a TAG review?



TAG review statusPending

Chromium Trial NameJavaScriptCompileHintsMagic

Link to origin trial feedback
summaryhttps://google.qualtrics.com/jfe/form/SV_9SLyOGnTj2cwo0C


Origin Trial documentation

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



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 nameNone


I *think* you can put JavaScriptCompileHintsMagicRuntime 
 as 
the feature name.




Non-finch justificationNone

Requires code in //chrome?False

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


Estimated milestonesOrigin trial desktop first115Origin trial
desktop last117Origin trial extension 1 end milestone131

Anticipated spec changes

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



Link to entry on the Chrome Platform

Statushttps://chromestatus.com/feature/5100466238652416?gate=5172761812533248

Re: [blink-dev] Intent to Extend Experiment: Cookie Deprecation Label

[Mike Taylor]

Hey John,

Can you confirm these labels will only be sent to the 1% "Mode B" 
population, until the new user choice approach is shipped? Or is 
something else planned?


thx,
Mike

On 9/30/24 10:12 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

As noted on the I2D&R for Third Party Cookies 
:


We recently announced a new path focused on elevating user choice, 
instead of third-party cookie deprecation. We will continue to support 
and invest in the Privacy Sandbox technologies. While we can't predict 
what exact user preferences will be, it’s important for businesses and 
developers to prepare for a likely increase in Chrome browsers without 
support for third-party cookies, and to continue investing in 
privacy-enhancing technologies.


*
*

The cookie deprecation labels are useful for developers to evaluate 
and optimize deployments of the Privacy Sandbox APIs prior to any 
changes in the number of browsers which support third-party cookies, 
so we are asking to extend the current set of labels 
for 
three more milestones.



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

Continued deployment and evaluation of Privacy Sandbox Ads APIs.

*
*

Experimental timeline

This feature was previously approved to run up until Chrome 129.

*
*

We would like to extend this for Chrome 130 through 132.

*
*

Any risks when the experiment finishes?

Minimal, the cookie deprecation labels are only available for a subset 
of users and must be requested.


*
*

Reason this experiment is being extended

We have received feedback that these labels are useful for ad tech 
companies to evaluate and optimize the APIs in preparation for changes 
to third party cookie availability.


*
*

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/694264ea-eb98-41a8-a798-62d28f7715c5n%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/c76aba8a-91c9-4ef0-9f45-a131d2c541ab%40chromium.org.

Re: [blink-dev] Intent to Ship: @page margin boxes

[Mike Taylor]

Thanks for the clarifications.

LGTM1

On 9/23/24 12:00 AM, Morten Stenshorne wrote:

Mike Taylor  writes:


On 9/19/24 4:58 PM, Chromestatus wrote:

  Contact emails

  msten...@chromium.org

  Explainer

  https://github.com/mstensho/page-margin-boxes

  Specification

  https://drafts.csswg.org/css-page-3/#margin-boxes

  Summary

  Add support for page margin boxes, when printing a web document, or exporting 
it as PDF. @page margin boxes
  allows an author to define the contents in the margin area of a page, for 
instance to provide custom headers and
  footers, rather than using the built-in headers and footers generated by the 
browser. A margin box is defined via an
  at-rule inside a CSS @page rule. There are 16 rules defined, one for each 
page margin box. There's one margin box
  for each of the 4 corners on the page, and three (start, middle, end) for 
each of the 4 sides. The appearance and the
  contents of a margin box are specified with CSS properties inside the at-rule, 
including the "content" property.
  Counters are also to be supported, for page numbering. The specification 
defines two special counter names:
  "page" for the current page number, and "pages" for the total number of pages.

  Blink component

  Blink>Layout>Printing

  TAG review

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

  TAG review status

  Issues addressed

  Risks

  Interoperability and Compatibility

  The spec defines the CSS counter names 'page' and 'pages'. Both are 
accessible by the document's contents, so
  that any element may use the counters to tell the current page number, or the 
total number of pages. Documents
  that use these counter names without being aware of this feature may be in 
for a surprise. Most browsers offer to
  generate some default headers and footers, and they are usually enabled by 
default. If the document has margin
  at-rules, they may come in conflict. We need some way of making sure that we 
either use the browser-default
  headers and footers, or the author-defined @page margins.

Can you clarify what you mean by "in for a surprise"?

I don't think I understand the compat implications of @page+
margin boxes here.

I'll remove this at chromestatus. It is no concern for now, since
counters in page / margin contexts will not interact with those of the
document. I.e. it's something we don't implement yet. The spec suggests
that they should interact, but it is vague, not too well thought through
(the spec forgets about parallel flows, for one), and the whole thing is
kind of weird, as counters are resolved in DOM tree order (i.e. the
precense of out-of-flow box, floats, etc.) do not affect the counter
scopes / values. Page / margin counters, on the other hand, need to be
resolved during layout. So we can revisit this later.

I wrote about this here (but how to fix the spec hasn't been discussed
yet):
https://github.com/w3c/csswg-drafts/issues/4760#issuecomment-1959298806


Also, do you have a plan for default header/footer conflicts w/ 
developer-provided ones?

Yes, sorry, forgot to update chromestatus again. Now fixed.

Most browsers offer to generate some default headers and footers, and
they are usually enabled by default. If the document has margin
at-rules, they may come in conflict and overlap if no action is
taken. Our solution: When a page has author-defined @page margin boxes
at the same edge of the page as a browser-default header or footer, the
browser-default ones will be suppressed (not displayed). This is in a
way similar to how the browser-default headers and footers are
suppressed when @page margins become too small for them to fit there
(with @page margin boxes, the author kind of takes control of the margin
area, and therefore there's nothing left for the UA, as if the margin on
that edge is zero).


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

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

  Web developers: Positive 
https://bugs.chromium.org/p/chromium/issues/detail?id=320370 currently has 98 
stars.

  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

I think it's possible to emulate the print media via DevTools. Maybe there are 
other possible debug modes to visually
represent these named margin boxes (as follow up work)?

Yes, we can emulate print media, as in "match @media print rules". But
that doesn't give us pagination. Getting devtools to paginate, so that
one could inspect the page boxes and margins (and margin box contents)
could indeed be useful. This is something that would have been useful
for years already, but with richer pagination support (like @page margin
bo

Re: [blink-dev] Intent to Ship: Support currentcolor in Relative Color Syntax

[Mike Taylor]

LGTM2 - thanks for working on this!

On 9/19/24 2:54 PM, Alex Russell wrote:

LGTM1

On Thu, Sep 19, 2024 at 11:40 AM 'Kevin Babbitt' via blink-dev 
 wrote:


*Contact emails*

kbabb...@microsoft.com

*Explainer*

None

*Specification*

https://www.w3.org/TR/css-color-5/#resolving-rcs

*Design docs*

https://docs.google.com/document/d/1568wVjrIRbrU9_O37gPu10cj0CDWRiAc6ZMk9t0JpXs/edit

*Summary*

Allow relative colors in CSS (using the 'from' keyword) to use
'currentcolor' as a base. This will make it easy for web
developers to set complementary colors, based on an element's text
color, for that element's borders, shadows, backgrounds, etc.

This feature also includes use cases where color functions are
nested with a dependency on 'currentcolor', for example
`color-mix(in srgb, rgb(from currentcolor r g b), white))` or
`rgb(from rgb(from currentcolor 1 g b) b g r)`.

*Blink component*

Blink>CSS


*TAG review*

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

*TAG review status*

Issues addressed
The link above is for Relative Color Syntax in general. Tests for
'currentcolor' cases were added as part of the discussion before
the TAG signed off on the review. I discussed with Alex Russell,
and he supports my interpretation that the TAG is satisfied with
this use case.

*Risks*



*Interoperability and Compatibility*

Interoperability: Relative Color Syntax is a focus area for
Interop 2024, and inclusion of 'currentcolor' is well covered by
existing WPTs, so the risk of other engines not converging on an
interoperable implementation is low.

Compatibility: The only risk here is that enabling 'currentcolor'
support will "light up" color declarations that are being rejected
at present. Total usage of Relative Color Syntax on the Web
(including 'currentcolor' or otherwise) is ~0.15% of page loads as
of September 1, 2024[1]. I haven't done an analysis of
'currentcolor' in RCS, but given that no major engine supported it
until May of this year, I would expect it to be a tiny fraction of
those.

[1] https://chromestatus.com/metrics/feature/timeline/popularity/4632



/Gecko/: Positive
(https://github.com/mozilla/standards-positions/issues/841)
Implementation bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1893966

/WebKit/: Shipped/Shipping
(https://bugs.webkit.org/show_bug.cgi?id=245970) Changes landed
May 13.

/Web developers/: Positive
(https://github.com/web-platform-tests/interop/issues/426) This
feature is part of Interop 2024.

/Other signals/:

*WebView application risks*

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

Low risk. This feature is additive in nature and potential for app
impact is cosmetic only.



*Debuggability*

Covered by existing DevTools support for debugging CSS properties.
Property text displays correctly in the Styles and Computed panes.
I did identify one minor issue with color swatches in the Styles
pane, but that's now fixed:

https://issues.chromium.org/issues/367154236



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

Yes

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

?*

Yes


https://wpt.fyi/results/css/css-color?label=master&label=experimental&aligned&view=interop&q=label%3Ainterop-2024-relative-color



There are a few subtest failures that remain with this feature in
status=experimental, but those are cases for relative colors *not*
based on 'currentcolor' and are being tracked separately.

*Flag name on chrome://flags*

None

*Finch feature name*

CSSRelativeColorSupportsCurrentcolor

*Requires code in //chrome?*

False

*Tracking bug*

https://issues.chromium.org/issues/325309578

*Estimated milestones*

Shipping on desktop



131

Shipping on Android



131

Shipping on WebView



131



*Anticipated spec changes*

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

There are several ongoing discussi

Re: [blink-dev] Intent to Ship: @page margin boxes

[Mike Taylor]

On 9/19/24 4:58 PM, Chromestatus wrote:



Contact emails

msten...@chromium.org


Explainer

https://github.com/mstensho/page-margin-boxes


Specification

https://drafts.csswg.org/css-page-3/#margin-boxes


Summary

Add support for page margin boxes, when printing a web document, or 
exporting it as PDF. @page margin boxes allows an author to define the 
contents in the margin area of a page, for instance to provide custom 
headers and footers, rather than using the built-in headers and 
footers generated by the browser. A margin box is defined via an 
at-rule inside a CSS @page rule. There are 16 rules defined, one for 
each page margin box. There's one margin box for each of the 4 corners 
on the page, and three (start, middle, end) for each of the 4 sides. 
The appearance and the contents of a margin box are specified with CSS 
properties inside the at-rule, including the "content" property. 
Counters are also to be supported, for page numbering. The 
specification defines two special counter names: "page" for the 
current page number, and "pages" for the total number of pages.




Blink component

Blink>Layout>Printing 
Layout>Printing> 




TAG review

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


TAG review status

Issues addressed


Risks



Interoperability and Compatibility

The spec defines the CSS counter names 'page' and 'pages'. Both are 
accessible by the document's contents, so that any element may use the 
counters to tell the current page number, or the total number of 
pages. Documents that use these counter names without being aware of 
this feature may be in for a surprise. Most browsers offer to generate 
some default headers and footers, and they are usually enabled by 
default. If the document has margin at-rules, they may come in 
conflict. We need some way of making sure that we either use the 
browser-default headers and footers, or the author-defined @page margins.


Can you clarify what you mean by "in for a surprise"? I don't think I 
understand the compat implications of @page+ margin boxes here.


Also, do you have a plan for default header/footer conflicts w/ 
developer-provided ones?





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


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


/Web developers/: Positive 
https://bugs.chromium.org/p/chromium/issues/detail?id=320370 currently 
has 98 stars.


/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

I think it's possible to emulate the print media via DevTools. Maybe 
there are other possible debug modes to visually represent these named 
margin boxes (as follow up work)?



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

WPT tests will be written and submitted while working on this feature.



Flag name on chrome://flags

None


Finch feature name

PageMarginBoxes


Requires code in //chrome?

False


Tracking bug

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


Estimated milestones

Shipping on desktop 131
Shipping on Android 131
Shipping on WebView 131



Anticipated spec changes

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


None


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5195769732923392?gate=6322213557108736


Links to previous Intent discussions

Intent to Prototype: 
https://groups.google.com/a/chromium.org/g/blink-dev/c/ZCPkcu_dSF8



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/66ec9090.2b0a0220.b3b1b.006b.GAE%40google.com 
.


--
You received this message 

Re: [blink-dev] Re: Intent to Ship: [WebRTC] RTCRtpEncodingParameters.scaleResolutionDownTo

[Mike Taylor]

LGTM2

On 9/19/24 2:55 PM, Alex Russell wrote:

LGTM1

On Thursday, September 19, 2024 at 12:32:08 AM UTC-7 Henrik Boström wrote:

Forgot to link but here are the notes + recordings from the
virtual interim:
https://www.w3.org/2024/08/27-webrtc-minutes.html#t06


On Monday, September 16, 2024 at 2:21:43 PM UTC+2 Henrik Boström
wrote:

Contact emails
h...@chromium.org

Specification

https://w3c.github.io/webrtc-extensions/#dom-rtcrtpencodingparameters-scaleresolutiondownto



Summary

An API that configures WebRTC encoders to scale input frames
if they are greater than the specified maxWidth and maxHeight.
This API is similar to scaleResolutionDownBy except that
resolution constraints are expressed in absolute terms (e.g.
640x360) as opposed to relative terms (e.g. scale down by 2),
avoiding race conditions related to changing input frame size
on the fly.


In particular, when simulcast is used to send multiple
resolutions (e.g. 720p + 360p), the app may dynamically turn
the top layer(s) on and off. Having an API that gives the app
a race-free way to adjust the track resolution accordingly can
have big performance wins, e.g. video effects processing on a
360p track instead of a 720p track when all we're sending is
360p. The old way to do this "scale down by factor X" is racy
when track resolution changes dynamically (e.g. momentarily
doing 360p + 180p or temporarily disabling encoding), which is
not ideal for receive side quality. Not nice API ergonomics
either.


Blink component
Blink>WebRTC>PeerConnection



TAG review status
Not applicable - small addition to existing API

Risks


Interoperability and Compatibility

None assuming all browsers implement this, otherwise the app
can always fall back to the old way of configuring scaling
factors (the scaleResolutionDown/By/API)


/Gecko/:
https://github.com/mozilla/standards-positions/issues/1071

/WebKit/:
https://github.com/WebKit/standards-positions/issues/396


/Web developers/:
Positive (hearts and positive feedback on issue
 and
positively received in Virtual Interim)

WebView application risks

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


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



--
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/3fd13984-64b0-4f05-bb8b-50c6a4ae05afn%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/905d6d9d-d18c-4335-ac50-d190df742d4f%40chromium.org.

Re: [EXTERNAL] Re: [blink-dev] Web-Facing Change PSA: Improved error reporting in IndexedDB for large value read failures

[Mike Taylor]

Sounds good - thx!

On 9/17/24 10:38 AM, Abhishek Shanthkumar wrote:

Hi, Mike!

The DOMException.name was "DataError" for all cases before this 
change. It remains the same for the "recoverable" cases even after 
this change. I'll add this to the Summary, thanks!


This error is unique to Chromium because, yes, LevelDB is not used by 
other browsers.


Thanks,

Abhishek


----
*From:* Mike Taylor 
*Sent:* Tuesday, September 17, 2024 7:46 PM
*To:* Chromestatus ; 
blink-dev@chromium.org 
*Cc:* Abhishek Shanthkumar ; 
a...@chromium.org ; est...@chromium.org 
; Steve Becker 
*Subject:* [EXTERNAL] Re: [blink-dev] Web-Facing Change PSA: Improved 
error reporting in IndexedDB for large value read failures



You don't often get email from miketa...@chromium.org. Learn why this 
is important <https://aka.ms/LearnAboutSenderIdentification>



Hi! A couple of questions:

What was the DOMException.name before this change?

Do we know what do other browsers do in this situation? Or is LevelDB 
only used by Chromium?


On 9/17/24 10:11 AM, Chromestatus wrote:


Contact emails

abhishek.shanthku...@microsoft.com
<mailto:abhishek.shanthku...@microsoft.com>, est...@chromium.org
<mailto:est...@chromium.org>


Specification

https://www.w3.org/TR/IndexedDB/#dom-idbrequest-error
<https://www.w3.org/TR/IndexedDB/#dom-idbrequest-error>


Summary

Change to reporting for certain error cases that were previously
reported with a DOMException and the message "Failed to read large
IndexedDB value". Chromium will now raise a DOMException with the
name "NotFoundError" when the file containing the data being read
by an IDBRequest is missing from the disk so that sites can take
the appropriate corrective action when an unrecoverable failure
occurs. Corrective actions could include deleting the entry from
the DB, notifying the user, re-fetching the data from servers,
etc. More details: a large value (above a specific size threshold)
written to IndexedDB is not stored directly in the underlying
LevelDB database but instead stored as a separate file. An
IndexedDB read request for this value looks up the blob reference
from LevelDB, reads the blob, then unwraps and returns the stored
value. If a failure occurs in this process, the browser fires an
"error" event and sets the error property on the IDBRequest to a
DOMException with the message "Failed to read large IndexedDB
value". The failure could be recoverable (caused by low memory) or
unrecoverable (the blob file is missing from the disk). This
feature updates the name to "NotFoundError" to enable
distinguishing recoverable and unrecoverable cases.



Blink component

Blink>Storage>IndexedDB

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


TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

None



/Gecko/: No signal

/WebKit/: No signal

/Web developers/: No signals

/Other signals/:


WebView application risks

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

None



Debuggability

None



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

Yes

This change is in the blink layer of the IndexedDB API
implementation and hence applies to all Blink platforms.



Is this feature fully tested by web-platform-tests

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

No


Flag name on chrome://flags

None


Finch feature name

None


Non-finch justification

This is a simple change to the error type when a failure occurs
due to a specific cause. Web developers can choose to update their
sites to respond differently to this specific error, but existing
general error handling keyed to the "Failed to read large
IndexedDB value" message will continue to work. Hence, this is
unlikely to break sites and is therefore not behind a feature flag.



Requires code in //chrome?

False


Tracking bug

https://issues.chromium.org/issues/362123231
<https://issues.chromium.org/issues/362123231>


Estimated milestones

Shipping on desktop 130
Shipping on Android 130
Shipping on WebView 130

Re: [blink-dev] Intent to Ship: WebXr hand input module - Level 1

[Mike Taylor]

Thanks for requesting the positions - it seems fair to me to give 
Mozilla at least a week to respond (and looks like WebKit intends to 
give a formal "support" response).


On 9/12/24 7:23 PM, Alex Cooper wrote:
To be honest, I didn't feel it was necessary given that the 
specification was already shipped in Safari and on Quest (which 
admittedly is a Chromium fork), and my understanding was that Mozilla 
was not making active investments into any WebXR efforts. However, 
I've gone ahead and filed a standards position request for mozilla 
here: https://github.com/mozilla/standards-positions/issues/1070


And to head off any future request, I've also filed the WebKit one, 
though I assume it's mainly a formality given that it's shipping on 
the Apple Vision Pro: 
https://github.com/WebKit/standards-positions/issues/395


On Thu, Sep 12, 2024 at 3:56 PM Daniel Clark  wrote:

Any reason not to request a Gecko position on this? Per
https://mozilla.github.io/standards-positions/#webxr they’re
Positive on WebXR in general but I don’t think that necessarily
implies support for the modules like this one, so it might be good
to ask about this specifically.

Thanks,
Dan

From: Alex Cooper 
Date: Thursday, September 12, 2024 at 3:26 PM
To: Rik Cabanier 
Cc: blink-dev 
Subject: Re: [blink-dev] Intent to Ship: WebXr hand input module -
Level 1



You don't often get email from alcoo...@chromium.org. Learn why
this is important 


Thanks Rik,

Good catch! The actual impl here is fairly old and I assumed this
was something the underlying API already handled. My recent work
on the feature has largely been integrating with our permissions
framework and the launch process. This CL

addresses the issue. I think it should land in time for M130, but
if not, I won't enable the feature until it does land.

On Wed, Sep 11, 2024 at 1:40 PM Rik Cabanier 
wrote:

Awesome to hear to see this shipping on Chrome!
Quest browser has supported this API for close to 4 years and
it's used by many developers and supported by all WebXR
frameworks.

Does your implementation ensure that the hand joints are not
matched to the user?

On Wed, Sep 11, 2024 at 11:35 AM 'Alex Cooper' via blink-dev
 wrote:


Contact emails


alcoo...@chromium.org


Explainer



https://github.com/immersive-web/webxr-hand-input/blob/main/explainer.md


Specification


https://immersive-web.github.io/webxr-hand-input


Summary


Exposes hand joint data on XrInputSources for use
during a WebXr session. This allows developers to
have more fine grained interactions during WebXr
sessions.



Blink component


Blink>WebXR




TAG review


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


TAG review status


Issues addressed


Risks




Interoperability and Compatibility


None



/Gecko/: No signal

/WebKit/: Shipped/Shipping

(https://webkit.org/blog/15443/news-from-wwdc24-webkit-in-safari-18-beta)

/Web developers/: Strongly positive

/Other signals/: Shipped on Meta Quest, Initially
added to Chrome for HoloLens support


WebView application risks


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

None



Debuggability


None



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


No

WebXR is only supported on Windows and Android
(not WebView)



Is this feature fully tested by web-platform-tests

?


No

API shape is relatively simple consisting largely
of the enum and a simple idl to get a "joint
space", which is used in other tested APIs;
  

Re: [blink-dev] Web-Facing Change PSA: Improved error reporting in IndexedDB for large value read failures

[Mike Taylor]

Hi! A couple of questions:

What was the DOMException.name before this change?

Do we know what do other browsers do in this situation? Or is LevelDB 
only used by Chromium?


On 9/17/24 10:11 AM, Chromestatus wrote:



Contact emails

abhishek.shanthku...@microsoft.com, est...@chromium.org


Specification

https://www.w3.org/TR/IndexedDB/#dom-idbrequest-error


Summary

Change to reporting for certain error cases that were previously 
reported with a DOMException and the message "Failed to read large 
IndexedDB value". Chromium will now raise a DOMException with the name 
"NotFoundError" when the file containing the data being read by an 
IDBRequest is missing from the disk so that sites can take the 
appropriate corrective action when an unrecoverable failure occurs. 
Corrective actions could include deleting the entry from the DB, 
notifying the user, re-fetching the data from servers, etc. More 
details: a large value (above a specific size threshold) written to 
IndexedDB is not stored directly in the underlying LevelDB database 
but instead stored as a separate file. An IndexedDB read request for 
this value looks up the blob reference from LevelDB, reads the blob, 
then unwraps and returns the stored value. If a failure occurs in this 
process, the browser fires an "error" event and sets the error 
property on the IDBRequest to a DOMException with the message "Failed 
to read large IndexedDB value". The failure could be recoverable 
(caused by low memory) or unrecoverable (the blob file is missing from 
the disk). This feature updates the name to "NotFoundError" to enable 
distinguishing recoverable and unrecoverable cases.




Blink component

Blink>Storage>IndexedDB 
Storage>IndexedDB> 




TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

None



/Gecko/: No signal

/WebKit/: No signal

/Web developers/: No signals

/Other signals/:


WebView application risks

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


None



Debuggability

None



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

Yes

This change is in the blink layer of the IndexedDB API implementation 
and hence applies to all Blink platforms.




Is this feature fully tested by web-platform-tests

?

No


Flag name on chrome://flags

None


Finch feature name

None


Non-finch justification

This is a simple change to the error type when a failure occurs due to 
a specific cause. Web developers can choose to update their sites to 
respond differently to this specific error, but existing general error 
handling keyed to the "Failed to read large IndexedDB value" message 
will continue to work. Hence, this is unlikely to break sites and is 
therefore not behind a feature flag.




Requires code in //chrome?

False


Tracking bug

https://issues.chromium.org/issues/362123231


Estimated milestones

Shipping on desktop 130
Shipping on Android 130
Shipping on WebView 130



Anticipated spec changes

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


None


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5140210640486400?gate=5120313600507904

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/66e98e07.2b0a0220.195547.0126.GAE%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/5aeb2992-c5fe-413f-9135-f5f9c84ffd14%40chromium.org.

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

[Mike Taylor]

Thanks Chris and Rick for the clarifications. I'm happy to approve an 
extension given that partners are actively experimenting.


LGTM to extend to M130 or 131 inclusive - whichever is more useful 
(either way, you're still within the default 6 milestone limit for 
experiments).


On 9/12/24 6:49 PM, Chris Fredrickson wrote:
Thanks for your response Mike; I do appreciate that OTs shouldn't be 
used as soft launches, and it's nice to hear that TAG reviews 
technically aren't blocking.


Rick, thanks for providing that context. You are absolutely correct; 
that partner is still running an experiment and may have feedback for 
us, so we'd like to not interrupt their study. (My earlier email was 
definitely incorrect, I was thinking too hard about things I need to 
do for the I2S.) Re: shipping, yes; we're preparing to ship a 
conservative behavior, but would still like to support the partner as 
they'recollecting metrics to evaluate that behavior.


On Thursday, September 12, 2024 at 3:40:44 PM UTC-4 Rick Byers wrote:

    On Wed, Sep 11, 2024 at 3:04 PM Mike Taylor
 wrote:

Hey Chris,

A few thoughts:

We do not block shipping features if TAG is slow with their
responses. But that said, I see the TAG review was requested
just 20 hours ago - we do like to give them a reasonable
amount of time to respond (this is usually on the order of a
few weeks, maybe longer if there's an active dialog happening)
before approving an I2S. If you were to send an I2S today,
that would probably be the case[1].

We also don't like using OTs/experiments as "soft launches".
The first two points of the "contract" that a site agrees to
when registering for an OT are:

 1. "I understand that this feature is experimental and may at
any point become unavailable, and may never be enabled
beyond this experiment, and even if Chrome decides to
enable the feature after this trial, it will be
unavailable for some time."
 2.  "I understand that this feature may change throughout the
course of the trial."

Other API OWNERs may disagree with me (and that's OK), but I'm
not personally inclined to approve an extension here in order
to prevent a small gap in availability until an I2S is sent
and approved (in short order, it sounds like).

I'm involved with FedCM and have a different perspective in trying
to represent a partner's interests here so I'll recuse myself as
an API owner on this one.

As I understand it, we have a major partner who is currently
experimenting with SAA autogrant with a small fraction of their
traffic. They are evaluating some properties of the design with
that experiment which may influence future versions of our design.
While we are expecting to I2S before they conclude their
experiment, it would be harmful to their experimentation if we
caused a gap in it - causing a delay in their own work for at
least a month, or possibly even resetting their work more than
that. Does that all match your understanding Chris? When you said
"It's not exactly for experimentation", did you mean that we
(Chrome / Privacy Sandbox) are now confident in our design and are
preparing to ship even though we have a partner who is still
experimenting themselves and not yet ready to go to 100% of their
traffic?

Also note this OT was approved for 2 milestones and renewed once
for 2. If Chris had just requested the max of 6 milestones at the
start (or max of 3 for the first renewal), we wouldn't even need
any extension approval for the 5 milestones we ultimately expect
the trial to run I believe. To what extent do we think this should
have a bearing on how API owners reason about extensions?

later,
Mike

[1] FWIW, I've noticed that TAG has recently reduced their
latency in responding to and engaging with reviews, which is
great to see.

On 9/11/24 12:54 PM, Chris Fredrickson wrote:

It's not exactly for experimentation, technically. My
understanding is that we need to have a verdict from the TAG
review before we send an I2S, but I don't think it's
realistic to expect one before M130 branch cut (9/16/23). (I
also need to go through I2S pre-review and launch bug
approval before I can actually enable this feature by
default, which will take some time.)

I'm trying to avoid creating a gap between the OT and when
the feature ships in Chrome, since that would be a bad
experience for OT participants. (I have seen the technical
note about "gapless" OTs
  

Re: [blink-dev] Intent to Ship: Attribution Reporting Feature: Debug Key Privacy Improvement

[Mike Taylor]

LGTM1 - this seems like an important privacy bugfix. Compatibility-wise, 
this won't affect user experience (if my mental model is correct), but 
sites using the API may receive less info than expected - but that's 
kinda the point.


On 9/11/24 6:03 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 changes to the Attribution Reporting API 
focused on:


 *

Improving privacy for debug keys


This change helps to mitigate a potential privacy gap with debug keys.


Currently the API allows a source debug key or a trigger debug key to 
be specified if third party cookies are available and can be set by 
API callers. If either a source or trigger debug key is specified then 
it will be included in the attribution report. This may lead to a 
privacy leak if third party cookies are only allowed on either the 
publisher or the advertiser site but not both.



This change mitigates this issue by enforcing that source debug keys 
and trigger debug keys are only included in the attribution report if 
they’re present on both the source and trigger, which would mean that 
third party cookies were available on both the publisher and 
advertiser site. This change will apply to both event-level reports 
and aggregatable reports.




Explainer/Spec changes

1.

Explainer & Spec:
https://github.com/WICG/attribution-reporting-api/pull/1403



Risks
Interoperability and Compatibility

This is a backwards incompatible change. API callers will continue to 
receive Attribution Reporting API reports but the information 
contained in the report may change if the API caller only specifies a 
debug key on only the source or trigger registration. If they only 
specify a debug key on one side, then they will no longer receive 
debug key information in the report they receive but they will 
continue to receive reports. We expect this to have minimal impact 
since the API caller will continue to receive attribution reports as 
expected.



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 
)




WebView application risks

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


No


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


The attribution reporting feature will be supported on all platforms 
with the exception of Android WebView



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



Yes


Estimated milestones

This feature is anticipated to ship as part ofChrome 130 
.



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6257907243679744 




Links to previous Intent discussions

Previous I2S:

Intent to Ship: Attribution Reporting API 



Intent to Ship: Attribution Reporting features M117 



Intent to Ship: Attribution Reporting features M118 



Intent to Ship: Attribution Reporting features M119 



Intent to Ship: Attribution Reporting features M120 



Intent to Ship: Attribution Reporting fea

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

[Mike Taylor]

LGTM2

On 9/12/24 9:13 AM, Yoav Weiss (@Shopify) wrote:

LGTM1

Thanks for catching us up! :)

On Wed, Sep 11, 2024 at 5:20 PM 'Munira Tursunova' via blink-dev 
 wrote:



Contact emails


moon...@google.com


Explainer


None


Specification


https://www.w3.org/TR/css-fonts-4/#font-variant-emoji-prop


Design docs




https://docs.google.com/document/d/1NyIKm0PnWUwX6j0smDwxDAPSUoiyBHPL95oH2lvjjpc/edit?usp=sharing&resourcekey=0-ubYsGJCgRSQnT9i_guM64g




Summary


Font-variant-emoji CSS property provides users an easy way
to control between colored (emoji-style) and monochromatic
(text-style) emoji glyphs presentations. This can be also
done by adding an emoji Variation Selector, specifically
U+FE0E for text and U+FE0F for emojis, after each emoji
codepoint. Using font-variant-emoji CSS property allows
web developers to select between emoji style (colored)
emoji presentation, text style (monochromatic) emoji
presentation and unicode default emoji presentation [0].
This property only affects emojis that are part of a
Unicode emoji presentation sequence [1]. [0]
https://www.unicode.org/reports/tr51/tr51-25.html#Emoji_Presentation
[1] http://www.unicode.org/emoji/charts/emoji-variants.html



Blink component


Blink>Fonts>Emoji




Search tags


emoji ,
variation selectors
,
font-variant-emoji
,
variation sequences



TAG review


None


TAG review status


Not applicable


Risks




Interoperability and Compatibility


None, already shipped in Firefox and Safari.



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

/WebKit/: Shipped/Shipping
(https://bugs.webkit.org/show_bug.cgi?id=246911)

/Web developers/: Positive

  * Salesforce web developer Nolan Lawson shares the
struggles of controlling emoji presentation in the
article

(https://nolanlawson.com/2022/04/08/the-struggle-of-using-native-emoji-on-the-web/).
  * Ollie Williams expressed interest in emoji
presentation control in the blog
(https://fullystacked.net/posts/using-emoji-on-the-web/).
  * Chris Coyier, co-founder of codepen, shared the
struggles with emoji presentations in the blog post
(https://front-end.social/@chriscoyier/112328067179677693).
  * Alibaba developer 一丝 also shared the struggles with
using emojis in chrome in the blog post
(https://x.com/yisibl/status/1826841566469566779).
  * ByteDance has been interested in this feature for
quite a while, their developer, ChangSeok Oh posted an
Intent to Prototype in blink-dev group

(https://groups.google.com/a/chromium.org/g/blink-dev/c/MaXgbE4vTbk/m/Q3QbI37IBQAJ).


/Other signals/:


WebView application risks


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

None



Debuggability


No additional DevTools support is needed.
Font-variant-emoji property is inspectable in DevTools
same way as any other CSS property.



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


No

Supported on all platforms for web fonts. Support of the
feature for system fallback fonts depends on the fonts
installed in the system, so some platforms may lack system
fonts that cover desired emoji unicode codepoints with
desired Variation Selectors. Since on Linux, installed
fonts can greatly vary, it's hard to pick a unified
colored and monochromatic emoji fallback font. Therefore
the feature for fallback system fonts is only supported on
   

Re: [EXTERNAL] Re: [blink-dev] Re: Intent to Prototype: Canvas Formatted Text

[Mike Taylor]

According to https://issues.chromium.org/u/2/issues/40160099#comment20 - 
it is not being pursued.


On 9/12/24 2:56 AM, Joe Lewis wrote:
Is this initiative progressing. I'm writing a web-based word processor 
and this will save a lot of efforts.
Curious to know if this is something that's still being pursued or 
should I write my own layouting engine?


Thanks,
Joe
On Thursday 16 December, 2021 at 2:30:17 pm UTC+5:30 Frank Tang wrote:

I am proposing an enhancement of Intl.Segmenter API (adding line
break support) to TC39 for ECMA402 (see
https://github.com/tc39-transfer/proposal-intl-segmenter-v2 ) The
API expose "line break opportunity" of text which implement the
Unicode® Standard Annex #14
 UNICODE LINE
BREAKING ALGORITHM (see https://www.unicode.org/reports/tr14/)
so it can be used for developer to use it with

 1. multiple lines of text rendering in 
 2. jsPDF and other context which need to layout text into
multiple lines
 3. SVG multiple lines of text

During the stage advancement discussion, one delegate suggest me
to reach out to Houdini to see which one of the following is better

 1. Instead of adding that to ECMA402 as a low level API, leave
that part of job (breaking text into multiple lines of text)
to Houdini to add such API to empower developers to use it on
, SVG , or for jsPDF and therefore there are no need
to add them into ECMA402, OR
 2. TC39 add such low level API into ECMA402 to allow developers
to use that with the currently defined Houdini APIs, OR
 3. TC39 add such low level API into ECMA402 to allow Houdini to
depends on Intl.Segmenter for the job of finding out
linguistic line break opportunity.

Please comment so we can move forward better in TC39 / ECMA402. Thanks


Similar question to you- do you think the enhancement to
Intl.Segmenter will be conflict or redundant to your API? or will
it complement the API you intend to implement?



On Mon, Dec 14, 2020 at 10:30 AM 'Sushanth Rajasankar' via
blink-dev  wrote:

Thanks, Ashley. I'm excited to see that we can help simplify
code and address your use case. Looking forward to your
feedback once we have a prototype in Chromium.


*From:* Ashley Gullen 
*Sent:* Wednesday, December 9, 2020 2:53 AM
*To:* Sushanth Rajasankar 
*Cc:* blin...@chromium.org ; Travis
Leithead 
*Subject:* [EXTERNAL] Re: [blink-dev] Re: Intent to Prototype:
Canvas Formatted Text
This would be good for our game engine Construct 3
(www.construct.net

)
as well.

Our engine renders entirely to a canvas, and for displaying
text we use the canvas text APIs. Since ~2012 we've had to
maintain our own custom word wrap engine in JavaScript to
handle multi-line text, and I doubt it does everything this
proposal does especially with regards to break opportunities
and bidi text, so it would be great if the browser could
handle that for us. I do think backwards compatibility would
be tricky though, as switching existing content to a different
word wrap engine will probably result in unwanted differences,
but there's not much that can be done about that.


On Tue, 8 Dec 2020 at 21:27, 'Sushanth Rajasankar' via
blink-dev  wrote:

Fixing the row for "Web Developer signals"

We do have positive signals from web developers, they are
interested in adopting this API for both performance and
correctness reasons

nhelfman · GitHub


 -
Excel Online - Microsoft
bonmotbot (Igor Kopylov) · GitHub

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

[Mike Taylor]

LGTM3

On 9/12/24 9:57 AM, Yoav Weiss (@Shopify) wrote:

LGTM2

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

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

On Thu, Sep 12, 2024 at 9:09 AM Yoav Weiss (@Shopify)
 wrote:


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

Thank you for the feedback Robert!

> updating the safe area while scrolling requires a main
thread update for the developer drawn controls (e.g.
footer) to respond

I've attached a recording of the same feature's behavior
on iOS

.
One of the initiatives for this change is to align Chrome
on Android parity with iOS.

> Can you attach this video so that it is available
externally?

Here's the link to the recording


 -
I've updated that in chrome status too:

https://chromestatus.com/feature/5174306712322048?gate=5101473814544384



On Wed, Sep 11, 2024 at 7:41 AM Robert Flack
 wrote:

My only concern with the current feature is that
dynamically updating the safe area while scrolling
requires a main thread update for the developer drawn
controls (e.g. footer) to respond. This is going to be
slow. Hopefully there is a path by which we can
recognize this positioning and update it frame
perfectly on the compositor similar to fixed / sticky
position content.

Otherwise, this seems in line with the established
pattern for devices which draw the viewport to an area
that is not entirely guaranteed to be visible.

On Mon, Sep 9, 2024 at 12:54 PM Wenyu Fu
 wrote:

Friendly ping :) This feature has an associated
Chrome milstone, it'd be great if I can get some
feedback so I can have them addressed in a timely
manner

On Fri, Sep 6, 2024 at 7:58 AM Wenyu Fu
 wrote:

For Chrome on Android, we are aiming to draw
the web contents edge to edge, drawing part of
the web contents under the bezels (i.e.
navigation bar). This change allows us to
correctly dispatch the safe-area-inset*
attributes based on the shown ration of the
browser controls, so if websites has control
elements that anchor to the bottom, they can
read the CSS env variable
"safe-area-inset-bottom" to avoid having the
controls being occluded by the navigation bar.
This Intent to Ship is targeting the render
side of the change.



On Fri, Sep 6, 2024 at 3:59 AM Yoav Weiss
(@Shopify)  wrote:

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


MDN has a great explanation and examples
 
of
how this variable is used by developers. I suspect
given this is already an established feature and that
this is changing it to be dynamic in the case of
native UI which only covers the content some of the
time that this could have been a PSA

.
The only risk I can think of is if this is the first
instance of a dynamically changing inset, there may be
developers who read it once from Javascript and don't
have a signal to update their UI when it changes.


Makes sense! Can y'all take a look at the HTTP archive to make
sure we don't see evidence of this happening in the wild?


FWIW, given this is already shipped on iOS, I personally think the
compat risk is quite small. Even if we did find a few sites that
read it once and then didn't update, they'd probably not be any
more broken than they are today with non-dynamic safe areas, right?

Personally I 

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

[Mike Taylor]

Hey Chris,

A few thoughts:

We do not block shipping features if TAG is slow with their responses. 
But that said, I see the TAG review was requested just 20 hours ago - we 
do like to give them a reasonable amount of time to respond (this is 
usually on the order of a few weeks, maybe longer if there's an active 
dialog happening) before approving an I2S. If you were to send an I2S 
today, that would probably be the case[1].


We also don't like using OTs/experiments as "soft launches". The first 
two points of the "contract" that a site agrees to when registering for 
an OT are:


1. "I understand that this feature is experimental and may at any point
   become unavailable, and may never be enabled beyond this experiment,
   and even if Chrome decides to enable the feature after this trial,
   it will be unavailable for some time."
2.   "I understand that this feature may change throughout the course
   of the trial."

Other API OWNERs may disagree with me (and that's OK), but I'm not 
personally inclined to approve an extension here in order to prevent a 
small gap in availability until an I2S is sent and approved (in short 
order, it sounds like).


later,
Mike

[1] FWIW, I've noticed that TAG has recently reduced their latency in 
responding to and engaging with reviews, which is great to see.


On 9/11/24 12:54 PM, Chris Fredrickson wrote:
It's not exactly for experimentation, technically. My understanding is 
that we need to have a verdict from the TAG review before we send an 
I2S, but I don't think it's realistic to expect one before M130 branch 
cut (9/16/23). (I also need to go through I2S pre-review and launch 
bug approval before I can actually enable this feature by default, 
which will take some time.)


I'm trying to avoid creating a gap between the OT and when the feature 
ships in Chrome, since that would be a bad experience for OT 
participants. (I have seen the technical note about "gapless" OTs 
<https://www.chromium.org/blink/launching-features/#origin-trials>, 
but I'm not 100% clear on what that means, since it seems to imply 
that OT extension requests are irrelevant from a technical perspective.)


On Wednesday, September 11, 2024 at 11:23:17 AM UTC-4 Chris Harrelson 
wrote:


Hi Chris,

Sounds like good progress, thanks. Could you also tell us the
reasons you need to continue experimenting?

On Wed, Sep 11, 2024 at 6:43 AM Chris Fredrickson
 wrote:

Hello again - we'd like to request another OT extension,
through M130 inclusive. As a demonstration of progress, we have:

  * Opened a spec PR
<https://github.com/privacycg/storage-access/pull/206>
  * Requested formal position signals from Firefox
<https://github.com/mozilla/standards-positions/issues/1065>
and WebKit
<https://github.com/WebKit/standards-positions/issues/390>
  * Written WPTs
<https://github.com/web-platform-tests/wpt/pull/47728>
  * Requested TAG review
<https://github.com/w3ctag/design-reviews/issues/992>


On Wednesday, July 24, 2024 at 2:39:32 PM UTC-4 Mike Taylor wrote:

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
 

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

[Mike Taylor]

The server seems to be working now, FWIW.

On 9/11/24 9:31 AM, Munira Tursunova wrote:
Latest published version doesn't include  as a valid syntax 
for custom property registration: 
(https://www.w3.org/TR/css-properties-values-api-1/#supported-names), 
but I also found a PR with the spec change that adds  syntax 
support for registered custom properties 
(https://github.com/w3c/css-houdini-drafts/pull/1104). Will this work?


On Wed, Sep 11, 2024 at 3:06 PM Yoav Weiss (@Shopify) 
 wrote:




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

LGTM1

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


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


Right, thanks!

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

On Thu, Sep 5, 2024 at 1:44 PM Chromestatus
mailto:ad...@cr-status.appspotmail.com>> wrote:

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

Explainer None

Specification

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

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


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




Summary

Support for "" syntax component name in
@property.

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

-- 
Rune Lillesveen


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

Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from
it, send an email to blink-dev+unsubscr...@chromium.org
<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/CAAO7W_BcN%3Djo2yVEu8w93RXgTqOms%3DQMVY63NkOdDpR70Q_RMA%40mail.gmail.com

<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAO7W_BcN%3Djo2yVEu8w93RXgTqOms%3DQMVY63NkOdDpR70Q_RMA%40mail.gmail.com?utm_medium=email&utm_source=footer>.




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

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

[Mike Taylor]

LGTM1

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


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


Right, thanks!

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


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


Contact emails

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


Explainer

None


Specification


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



Summary

Support for "" syntax component name in @property.

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

-- 
Rune Lillesveen


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


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

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

[Mike Taylor]

LGTM2 % requesting review bits for Enterprise, Debuggability, and Testing.

Sites could fail if they're still calling this, but I trust the team to 
handle outreach (as they've already done) and react accordingly.


On 9/10/24 8:09 AM, Yoav Weiss (@Shopify) wrote:

OK, LGTM1 then :D

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


I've checked with a Chromium build that removes the
requestAdapterInfo() method and the websites I've tried are not
broken.
The content of the string sent for analytics is simply different
but the POST request still happens properly.

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

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

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

LGTM1

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


https://github.com/gpuweb/gpuweb/pull/4662#issuecomment-2338982367
indicates they have just removed it in WebKit as expected.


On Mon, Sep 9, 2024 at 5:48 PM François Beaufort
 wrote:



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

On 9/9/24 11:45 AM, François Beaufort wrote:


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

On 9/9/24 10:38 AM, 'François Beaufort'
via blink-dev wrote:



Contact emails

fbeauf...@google.com


Explainer

None


Specification

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


Summary

The WebGPU WG decided it was impractical
for requestAdapterInfo() to trigger a
permission prompt so they’ve removed
that option and replaced it with the
GPUAdapter info attribute so that web
developers can get the same
GPUAdapterInfo value synchronously this
time. See the previous intent to ship at

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




Blink component

Blink>WebGPU

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


Motivation

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

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

According to

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

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



Initial public proposal

None


TAG review

None


TAG review status

Not applicable


Risks



Interoperability and 

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

[Mike Taylor]

On 9/9/24 11:45 AM, François Beaufort wrote:


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

On 9/9/24 10:38 AM, 'François Beaufort' via blink-dev wrote:



Contact emails

fbeauf...@google.com


Explainer

None


Specification

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


Summary

The WebGPU WG decided it was impractical for requestAdapterInfo()
to trigger a permission prompt so they’ve removed that option and
replaced it with the GPUAdapter info attribute so that web
developers can get the same GPUAdapterInfo value synchronously
this time. See the previous intent to ship at

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




Blink component

Blink>WebGPU

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


Motivation

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

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

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

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



Initial public proposal

None


TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

When WebGPU eventually launches in Safari and Firefox, websites
will be able to get GPUAdapterInfo values exclusively through the
standardized GPUAdapter info attribute. We anticipate Safari and
Firefox will soon support WebGPU, but won't include this
non-standard method. Therefore, the sooner Chromium implements
the Deprecate and Remove process, the less likely it is that
content will work in Chromium but not in other browsers. In
Chromium-based browsers, as the requestAdapterInfo() asynchronous
method returned a promise, websites that followed best practices
were already catching rejected promises. Web developers have been
made aware of this change in July 2024 at

https://developer.chrome.com/blog/new-in-webgpu-127?hl=en#gpuadapter_info_attribute.
They can use the following one-line code during the transition
period: const info = adapter.info <http://adapter.info> || await
adapter.requestAdapterInfo();


I know that WebKit !== Safari, but I do see they have
requestAdapterInfo

<https://github.com/WebKit/WebKit/blob/e5b033ce5afcc666cf85ec75d53179dbd75006df/Source/WebCore/Modules/WebGPU/GPUAdapter.idl#L41>
today. Do we have any sense of what their plans are there (maybe a
standards position could clarify that)?


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





/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

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

No


Flag name on chrome://flags

None


Finch feature name

None


Non-finch justification

None


Requires code in //chrome?

False


Estimated milestones

No milestones specified



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5140787340509184?gate=5110989125844992

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 

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

[Mike Taylor]

On 9/9/24 10:38 AM, 'François Beaufort' via blink-dev wrote:



Contact emails

fbeauf...@google.com


Explainer

None


Specification

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


Summary

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





Blink component

Blink>WebGPU 




Motivation

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


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


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


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




Initial public proposal

None


TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

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


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



/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


Estimated milestones

No milestones specified



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5140787340509184?gate=5110989125844992

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/CAPpwU5KohE-NU%2B0bAsWzgaNLUCPGCqBr%2BH3jpoY58yGK-frwOg%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/53bb5eb0-59ff-4ad3-9609-bb37f924bc63%40chromium.org.

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

[Mike Taylor]

LGTM2

On 9/4/24 11:38 AM, Yoav Weiss (@Shopify) wrote:

LGTM1

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

Those open items are now addressed (by
https://github.com/WICG/turtledove/pull/1246
 and
https://github.com/WICG/turtledove/pull/1253
).

On Thu, Aug 8, 2024 at 2:52 PM Chris Harrelson
 wrote:

Hi,

I see that there are a couple of open items on the spec
(mentioned here
),
should we wait for those to resolve?

On Thu, Aug 8, 2024 at 11:32 AM Paul Jensen
 wrote:

We also extended our feature detection API to facilitate
detecting this feature:
Explainer: https://github.com/WICG/turtledove/pull/1238

Spec: https://github.com/WICG/turtledove/pull/1245

On Wednesday, July 31, 2024 at 12:51:08 PM UTC-4 Paul
Jensen wrote:


Contact emails

pauljen...@chromium.org


Explainer


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




Specification

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



Summary

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


Blink component

Blink>InterestGroups




TAG review

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



TAG review status

Completed for Protected Audience, resolved unsatisfied.


Risks


Privacy

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

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

 *

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

 *

It reveals to the ad tech the fact that it had an
interest group present on the device. This is
mitigated by the fact that the reports are sent to
a fixed path and include only heavily noised
signals. We also considered sending reports to all
eligibleauction participants for a given auction
   

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

[Mike Taylor]

Sorry, LGTM3 conditioned upon Testing and Debuggability bits being 
requested in the chromestatus entry.


On 9/4/24 10:21 AM, Mike Taylor wrote:


LGTM3

On 9/4/24 10:07 AM, Yoav Weiss (@Shopify) wrote:

LGTM2

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


LGTM1. This seems like a good change for overall web consistency,
and compat risks seem well-managed.

On Thursday, August 29, 2024 at 4:32:20 AM UTC+9 Cammie Smith
Barnes wrote:

Intent to Ship: Shared Storage: Allowing Cross-Origin Script
in addModule & Aligning createWorklet


Contact emails


cam...@chromium.org, jkar...@chromium.org,
yao...@chromium.org, ashame...@google.com


Explainer


https://github.com/WICG/shared-storage/blob/main/README.md
<https://github.com/WICG/shared-storage/blob/main/README.md>


Specification


https://github.com/WICG/shared-storage/pull/161
<https://github.com/WICG/shared-storage/pull/161>


Summary


We now allow sharedStorage.worklet.addModule to load
cross-origin script, while still using the invoking
context's origin as the data partition origin for
accessing shared storage data. We also align the
behavior of sharedStorage.createWorklet, so that when
it loads a cross-origin script, it also uses the
invoking context's origin as the data partition
origin by default (instead of using the script origin
as it did when initially implemented). Finally, to
preserve the ability to use the script's origin as
the data partition origin, we introduce a new
dataOrigin option for createWorklet.


We have received feedback from developers stating
they wanted to be able to host and run their worklet
script on a separate origin from the origin that owns
and writes their shared storage data. So we remove
the same-origin restriction for addModule. Note that,
when the worklet script is cross-origin to the
invoking context, the invoking context's origin is
used as the partition origin for accessing shared
storage.


To help avoid developer confusion in the long term,
we align the default behavior of createWorklet to use
the invoking context's origin instead of the script
origin as its data partition origin. This is a
breaking change, but current usage of createWorklet
is low as it was introduced in M125 and those that
are using it have upgraded to a forward-compatible
incantation. We also introduce a dataOrigin option
that can be passed to use the previous behavior.



Blink component


Blink>Storage>SharedStorage

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


TAG review & status


Notification of the change is here

<https://github.com/w3ctag/design-reviews/issues/747#issuecomment-2288670353>but
not expecting feedback as the entire Shared Storage
feature is resolved as unsatisfied.



Risks



Interoperability and Compatibility


There are no interop risks as no other browser has
implemented shared storage. There is a compat risk
for the recently released createWorklet API. The
worklet created by createWorklet before this change
had the data partition of the script’s origin. We’re
changing it, to align with addModule, to use the
calling context’s origin instead. We’re monitoring
usage here

<https://chromestatus.com/metrics/feature/timeline/popularity/5007>of
the backwards-incompatible usage of the existing API
and reaching out to folks using it to let them know
that they should make the following
forward-compatible change if they want the existing
default behavior of createWorklet to continue to
function after this change:


before: sharedStorage.createWorklet(worklet_url);


after: sharedStorage.createWorklet(worklet_url, {
dataOrigin: “script-origin” });


The dataOrigin option will be ignored on browsers
previous to this change, and honored correctly

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

[Mike Taylor]

LGTM3

On 9/4/24 10:07 AM, Yoav Weiss (@Shopify) wrote:

LGTM2

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


LGTM1. This seems like a good change for overall web consistency,
and compat risks seem well-managed.

On Thursday, August 29, 2024 at 4:32:20 AM UTC+9 Cammie Smith
Barnes wrote:

Intent to Ship: Shared Storage: Allowing Cross-Origin Script
in addModule & Aligning createWorklet


Contact emails


cam...@chromium.org, jkar...@chromium.org,
yao...@chromium.org, ashame...@google.com


Explainer


https://github.com/WICG/shared-storage/blob/main/README.md



Specification


https://github.com/WICG/shared-storage/pull/161



Summary


We now allow sharedStorage.worklet.addModule to load
cross-origin script, while still using the invoking
context's origin as the data partition origin for
accessing shared storage data. We also align the
behavior of sharedStorage.createWorklet, so that when
it loads a cross-origin script, it also uses the
invoking context's origin as the data partition origin
by default (instead of using the script origin as it
did when initially implemented). Finally, to preserve
the ability to use the script's origin as the data
partition origin, we introduce a new dataOrigin option
for createWorklet.


We have received feedback from developers stating they
wanted to be able to host and run their worklet script
on a separate origin from the origin that owns and
writes their shared storage data. So we remove the
same-origin restriction for addModule. Note that, when
the worklet script is cross-origin to the invoking
context, the invoking context's origin is used as the
partition origin for accessing shared storage.


To help avoid developer confusion in the long term, we
align the default behavior of createWorklet to use the
invoking context's origin instead of the script origin
as its data partition origin. This is a breaking
change, but current usage of createWorklet is low as
it was introduced in M125 and those that are using it
have upgraded to a forward-compatible incantation. We
also introduce a dataOrigin option that can be passed
to use the previous behavior.



Blink component


Blink>Storage>SharedStorage




TAG review & status


Notification of the change is here

but
not expecting feedback as the entire Shared Storage
feature is resolved as unsatisfied.



Risks



Interoperability and Compatibility


There are no interop risks as no other browser has
implemented shared storage. There is a compat risk for
the recently released createWorklet API. The worklet
created by createWorklet before this change had the
data partition of the script’s origin. We’re changing
it, to align with addModule, to use the calling
context’s origin instead. We’re monitoring usage here

of
the backwards-incompatible usage of the existing API
and reaching out to folks using it to let them know
that they should make the following forward-compatible
change if they want the existing default behavior of
createWorklet to continue to function after this change:


before: sharedStorage.createWorklet(worklet_url);


after: sharedStorage.createWorklet(worklet_url, {
dataOrigin: “script-origin” });


The dataOrigin option will be ignored on browsers
previous to this change, and honored correctly after.


As of today, all users have switched to the
forward-compatible incantation. We are also monitoring
usage of addModule with scripts that are cross-origin
to the calling context here
  

Re: [blink-dev] Intent to Ship: relaunch Intl Locale Info feature in newly added functions

[Mike Taylor]

Thanks Frank. LGTM2

On 8/30/24 6:42 PM, Chris Harrelson wrote:

Thanks for these updates. LGTM1

On Fri, Aug 30, 2024 at 12:21 PM Frank Tang (譚永鋒)  
wrote:


1. I confirm, this particular launch is just adding new getter
methods.
2. This particular launch is NOT removing the existing getter
properties that shipped in M99.
3. The type of firstDay  returned by `getWeekInfo()`  is NOT
different than before. It is always an integer 1..7
4. Plan to deprecate getter properties- Launch this one first,
after available, launch the deprecation separately in
https://chromestatus.com/feature/5148228059398144 (Stage 131, Ship
132)

On Fri, Aug 30, 2024 at 11:51 AM Mike Taylor
 wrote:

On 8/29/24 3:57 PM, 'Frank Tang (譚永鋒)' via blink-dev wrote:




On Wed, Aug 28, 2024 at 1:23 PM Chris Harrelson
 wrote:

Does this feature change the behavior of existing
web-exposed APIs for Locale? If so, what is the compat
risk of breaking existing sites?


With this launch, the pre-existing Intl.Locale object will
add 7 additional functions

 *

Add Intl.Locale.prototype.getCalendars ( )

 *

Add Intl.Locale.prototype.getCollations ( )

 *

Add Intl.Locale.prototype.getHourCycles ( )

 *

Add Intl.Locale.prototype.getNumberingSystems ( )

 *

Add Intl.Locale.prototype.getTimeZones ( )

 *

Add Intl.Locale.prototype.getTextInfo ( )

 *

Add Intl.Locale.prototype.getWeekInfo ( )


These functions are already available in Safari 17 (Released
September 18, 2023 — Version 17 (19616.1.27))
"Updated Intl.Locale to replace info getters with individual
get… methods. (105570888)" (see

https://developer.apple.com/documentation/safari-release-notes/safari-17-release-notes?language=_6)


so it should have minimum compat risk of breaking existing sites


To clarify: this intent adds the new getter methods, but we're
not deprecating or removing the existing getter properties
that shipped in M99, correct? I see that the type for
`firstDay` is different when returned by `getWeekInfo()` - are
there any other notable changes?

Do you have a plan to deprecate the getter properties?




On Thu, Aug 22, 2024 at 4:11 PM Chromestatus
 wrote:


Contact emails

ft...@google.com


Explainer

None


Specification

https://tc39.es/proposal-intl-locale-info


Design docs



https://docs.google.com/document/d/1BSpa-LKE69LL1g5CHZ3G06XEfffauwS24atfSUQiIDY/edit?usp=sharing



Summary

Intl Locale Info API is a new Stage ECMAScript TC39
proposal to enhance the Intl.Locale object by
exposing Locale information, such as week data (first
day in a week, weekend start day, weekend end day,
minimun day in the first week), and text direction
hour cycle used in the locale.
https://github.com/tc39/proposal-intl-locale-info We
launch Intl Locale Info API w/ getters but later the
proposal changed to rename these getters to
functions. We need to deprecate the getter and
relaunch the functions . The deprecation of getters
is tracked in
https://chromestatus.com/feature/5148228059398144



Blink component

Blink>JavaScript>Internationalization

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



TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

None



/Gecko/: Positive
(https://bugzilla.mozilla.org/show_bug.cgi?id=1693576)

/WebKit/: Shipped/Shipping

(https://developer.apple.com/documentation/safari-release-notes/safari-17-release-notes)
Shipped in Safari version 17

/Web developers/: Positive

(https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/Locale/getCalendars)

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/Locale/getCalendars

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/Locale/getCollations

https:/

Re: [blink-dev] Intent to Experiment: WebAuthn attestationFormats

[Mike Taylor]

On 8/30/24 3:09 PM, Adam Langley wrote:

On Fri, Aug 30, 2024 at 11:32 AM Mike Taylor  
wrote:


Could you clarify which milestones you're requesting? Is it 130 to
140? If so, can you explain why you think 11 milestones are
required for this experiment (vs 6, which is the default allowed)?

The sites who are interested in this are large and operate in the 
financial sector, so I expect they will proceed cautiously. Also, 
mid-November to mid-January may simply be production freeze periods 
for them and thus almost not count.


However, I wasn't aware of the 6-milestone norm. Happy to say 130–136 
and revisit if needed, if that avoids cutting against the grain now.


To be clear: you can get approval for 6 milestones w/ just 1 LGTM. 
Longer trials are definitely possible - but need justification and 3 LGTMs.


That said, LGTM to experiment from 130 to 136. If you'd prefer a longer 
trial just let us know here, and perhaps other owners will also 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/717e356d-3cab-400f-a695-69e420481cae%40chromium.org.

Re: [blink-dev] Intent to Ship: relaunch Intl Locale Info feature in newly added functions

[Mike Taylor]

On 8/29/24 3:57 PM, 'Frank Tang (譚永鋒)' via blink-dev wrote:




On Wed, Aug 28, 2024 at 1:23 PM Chris Harrelson 
 wrote:


Does this feature change the behavior of existing web-exposed APIs
for Locale? If so, what is the compat risk of breaking existing sites?


With this launch, the pre-existing Intl.Locale object will add 7 
additional functions


 *

Add Intl.Locale.prototype.getCalendars ( )

 *

Add Intl.Locale.prototype.getCollations ( )

 *

Add Intl.Locale.prototype.getHourCycles ( )

 *

Add Intl.Locale.prototype.getNumberingSystems ( )

 *

Add Intl.Locale.prototype.getTimeZones ( )

 *

Add Intl.Locale.prototype.getTextInfo ( )

 *

Add Intl.Locale.prototype.getWeekInfo ( )


These functions are already available in Safari 17 (Released September 
18, 2023 — Version 17 (19616.1.27))
"Updated Intl.Locale to replace info getters with individual get… 
methods. (105570888)" (see 
https://developer.apple.com/documentation/safari-release-notes/safari-17-release-notes?language=_6) 



so it should have minimum compat risk of breaking existing sites


To clarify: this intent adds the new getter methods, but we're not 
deprecating or removing the existing getter properties that shipped in 
M99, correct? I see that the type for `firstDay` is different when 
returned by `getWeekInfo()` - are there any other notable changes?


Do you have a plan to deprecate the getter properties?




On Thu, Aug 22, 2024 at 4:11 PM Chromestatus
 wrote:


Contact emails

ft...@google.com


Explainer

None


Specification

https://tc39.es/proposal-intl-locale-info


Design docs



https://docs.google.com/document/d/1BSpa-LKE69LL1g5CHZ3G06XEfffauwS24atfSUQiIDY/edit?usp=sharing



Summary

Intl Locale Info API is a new Stage ECMAScript TC39 proposal
to enhance the Intl.Locale object by exposing Locale
information, such as week data (first day in a week, weekend
start day, weekend end day, minimun day in the first week),
and text direction hour cycle used in the locale.
https://github.com/tc39/proposal-intl-locale-info We launch
Intl Locale Info API w/ getters but later the proposal changed
to rename these getters to functions. We need to deprecate the
getter and relaunch the functions . The deprecation of getters
is tracked in https://chromestatus.com/feature/5148228059398144



Blink component

Blink>JavaScript>Internationalization





TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

None



/Gecko/: Positive
(https://bugzilla.mozilla.org/show_bug.cgi?id=1693576)

/WebKit/: Shipped/Shipping

(https://developer.apple.com/documentation/safari-release-notes/safari-17-release-notes)
Shipped in Safari version 17

/Web developers/: Positive

(https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/Locale/getCalendars)

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/Locale/getCalendars

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/Locale/getCollations

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/Locale/getHourCycles

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/Locale/getNumberingSystems

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/Locale/getTextInfo

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/Locale/getTimeZones

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/Locale/getWeekInfo


/Other signals/:


Ergonomics

minor change, similar to all other functions in Intl.Locale
object already.



Activation

non- minor change, similar to all other functions in
Intl.Locale object already.



Security

none - minor change, similar to all other functions in
Intl.Locale object already.



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

minor change, similar to all other functions in Intl.Locale
object already.



Will this feature be supported on all six Blink
platfo

Re: [blink-dev] Intent to Experiment: WebAuthn attestationFormats

[Mike Taylor]

Could you clarify which milestones you're requesting? Is it 130 to 140? 
If so, can you explain why you think 11 milestones are required for this 
experiment (vs 6, which is the default allowed)?


thx

On 8/28/24 5:14 PM, Adam Langley wrote:



Contact emails

a...@chromium.org



Specification

https://w3c.github.io/webauthn/#dom-publickeycredentialcreationoptions-attestationformats


Summary

Support the attestationFormats field from WebAuthn L3. WebAuthn L3 
supports a site expressing an ordered preference for credential 
attestation formats in the new attestationFormats field[1]. We plan on 
running an origin trial for this new field to allow some interested 
sites to experiment with this field on the one OS that currently 
supports it (Android). At the end, we'll gauge whether it has 
sufficient utility to support on an ongoing basis.



Blink component

Blink>WebAuthentication 




TAG review

None — this one extra field is one of many passed in WebAuthn from a 
browser to passkey providers and doesn't represent any meaningful 
change in design.



Risks


Interoperability and Compatibility

No risks in general. Users of this field trial will have to keep in 
mind that it'll expire, but this is true of all trials.



/Gecko/: No signal

/WebKit/: No signal

/Web developers/: No signals

/Other signals/:


WebView application risks

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


No



Goals for experimentation

To let a handful of interested sites experiment with this 
functionality without having to support it ~forever in the broad Web 
Platform. At the end of the trial we'll consider whether full support 
is warranted.



Ongoing technical constraints

None


Debuggability

The usual tricks for inspecting WebAuthn requests still work, but much 
of the logic is implemented by the user's chosen passkey provider.



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

No, because it can only be supported in cases where the underlying 
passkey provider infrastructure supports this field, which is 
currently only true on Android.



Is this feature fully tested by web-platform-tests

?

No. If we decide in the future to ship this feature fully we'll add 
WebDriver support and flesh out the testing. But the need for 
integration into a virtual authenticator for testing makes this a 
non-trivial amount of work.



Requires code in //chrome?

No


Estimated milestones

Origin trial Android first  130
Origin trial Android last   <= 140



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5121935290400768?gate=6201855156420608 


--
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/CAL9PXLxCRDEFwvz-KrPymBz53OZh92PRHTChTeStDEOsYZe%3Dzw%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/9b29230d-b4bf-4937-814c-5e2cf11df915%40chromium.org.

Re: [blink-dev] Intent to Ship: Compression dictionary transport with Shared Brotli and Shared Zstandard

[Mike Taylor]

LGTM3

On 8/28/24 4:25 PM, Chris Harrelson wrote:

LGTM2

On Wed, Aug 28, 2024 at 11:10 AM Alex Russell 
 wrote:


LGTM1. Congrats, all. This is a big deal!

On Tuesday, August 27, 2024 at 10:06:16 AM UTC-7 Patrick Meenan wrote:

It's probably worth mentioning that, even though the spec is
in the IETF process, there was heavy involvement with w3c and
whatwg as well.  The w3c TAG performed several reviews, there
are several discussions in the whatwg HTML
 and Fetch
 issue trackers
and discussion/review by the w3c web performance working group
(where it originated). The linked HTML and Fetch issues are
the tracking issues for adding the processing language to the
relevant specs (or make sure the existing language covers the
expanded use cases from the IETF draft).

On Tue, Aug 27, 2024 at 12:47 PM Patrick Meenan
 wrote:

I just pushed the update to the explainer to redirect it
to the IETF spec (will update it again when we have an RFC
number).

I kept the changelog in the WICG explainer just so
existing users of the earlier OT's will know what changes
they need to make for the release. OT v3 had the changes
and most of the users that were actively testing already
picked up the changes but this makes it clearer.

On Tue, Aug 27, 2024 at 12:31 PM Patrick Meenan
 wrote:



On Tue, Aug 27, 2024 at 12:21 PM Jeffrey Yasskin
 wrote:

Congratulations on getting compression
dictionaries through the standards gauntlet!

On Tue, Aug 27, 2024 at 2:36 AM Tsuyoshi Horo
 wrote:



Explainer



https://github.com/WICG/compression-dictionary-transport


The explainer still has "All actual header values
and names still TBD". I assume that's not the case
anymore?


Thanks. The explainer is actually going away and
deferring to the RFC as the authoritative source. I'll
go through and make a pass now to at least remove the
redundant bits and point to the draft.


Specification



https://datatracker.ietf.org/doc/draft-ietf-httpbis-compression-dictionary


Is there a specification for the browser side of
this? I'd expect to find something in Fetch that
describes, for example, the CORS, same-origin, and
partitioning behavior.


There will be a few updates to the fetch spec to
include the content encoding processing but the core
parts of the CORS logic are in the IETF draft in
section 9.3

,
including the CORS checks. The partitioning behaviour
is described in section 10

:




Interoperability and Compatibility


Interoperability and Compatibility
risk are low. This feature introduces
a new compression method for
transporting resources over HTTP. Web
sites can know the browser support for
the new feature by checking

`document.createElement('link').relList.supports('dictionary')`.



https://www.ietf.org/archive/id/draft-ietf-httpbis-compression-dictionary-17.html#name-the-compression-dictionary-
says the link relation is "compression-dictionary"
instead of "dictionary". Which is being shipped?


Sorry, missed that on the I2S draft from a previous
I2E - the name changed and "compression-dictionary" is
what is shipping.

-- 
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/893b961c-c763-44a0-abe4-361ba276ab1en%40chromium.org

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

[Mike Taylor]

LGTM2

On 8/28/24 8:03 AM, Yoav Weiss (@Shopify) wrote:
LGTM1 - the use case is clear, as well as the dangers of enabling this 
over the open web. Confining this API to IWAs seems to strike a 
reasonable balance.


On Mon, Aug 19, 2024 at 3:46 PM 'Randell Jesup' via blink-dev 
 wrote:


This was not closed by Mozilla with no opinion, it was closed as
Harmful.

Randell Jesup, Mozilla Networking Team

On Tue, Aug 13, 2024, 2:59 PM Chromestatus
 wrote:


Contact emails

greengr...@google.com


Explainer

https://github.com/WICG/direct-sockets/blob/main/docs/explainer.md



Specification

https://wicg.github.io/direct-sockets


Summary

Allows Isolated Web Apps to establish direct transmission
control protocol (TCP) and user datagram protocol (UDP)
communications with network devices and systems as well as
listen to and accept incoming connections.



Blink component

Blink>Network>Direct Sockets





Search tags

networking , TCP
, UDP ,
sockets 


TAG review

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


TAG review status

Pending


Risks



Interoperability and Compatibility

Other browsers may choose to implement this API.



/Gecko/: Closed Without a Position
(https://github.com/mozilla/standards-positions/issues/431)

/WebKit/: No signal

/Web developers/: Positive

(https://discourse.wicg.io/t/filling-the-remaining-gap-between-websocket-webrtc-and-webtranspor/4366)
Numerous potential use cases have been suggested.

/Other signals/:


Security

Various security risks and mitigations are noted in

https://github.com/WICG/raw-sockets/blob/master/docs/explainer.md#security-considerations
This is a powerful API. Users will have the opportunity to
give Isolated Web Apps access to local hardware, and
information systems behind organization firewalls. Mitigations
are designed to ensure this cannot happen accidentally, and
only through enterprise policies or the friction of installing
a native app.



WebView application risks

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

N/A. Feature not compiled in Android.



Debuggability

The code using this API can be debugged using the standard
tools. Integrating the API with the DevTools Networking tab to
enable easier introspection of the state of these connections
as well as the data transferred could be a beneficial future
improvement.



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

No

This feature is implemented on desktop platforms, although it
will only be available to the end users on platforms that
support Isolated Web Apps, which is currently only ChromeOS.
Android is excluded for historical reasons, although there are
no apparent interoperability blockers here.



Is this feature fully tested by web-platform-tests

?

Yes

These tests require a specific --isolated-context-origins flag
to be tested in WPTs, so they're run as a part of a virtual
suite and are not reflected on wpt.fyi.



Flag name on chrome://flags

#enable-direct-sockets-web-api


Finch feature name

DirectSockets


Requires code in //chrome?

False


Tracking bug

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


Launch bug

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


Measurement

We have the following histograms for tracking network failures
upon creating sockets (prefixed with DirectSockets.*): -
TCPNetworkFailures - UDPNetworkFailures -
TCPServerNetworkFailures Separate programmatic counters for
the .idl methods and attributes (via MeasureAs) are also
included to track the stats for API usage.


Availability expectation

Feature is available only in Isolated Web Apps on desktop
platforms. https

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

[Mike Taylor]

Also, would you remind requesting reviews for Enteprise, Debuggability, 
and Testing in the chromestatus entry? Thanks!


On 8/26/24 12:40 PM, Mike Taylor wrote:


LGTM1 to remove - if there's no usage, now is the time to get that done.

Relevant use counter for those interested: 
https://chromestatus.com/metrics/feature/timeline/popularity/5017


On 8/26/24 12:13 PM, Chromestatus wrote:



Contact emails

sahir.vell...@microsoft.com


Explainer

None


Specification

https://wicg.github.io/ink-enhancement


Summary

The attribute tells web developers how much improvement the 
DelegatedInkTrails API will provide to their current ink latency. 
However, this attribute is not worth increases to fingerprinting entropy.




Blink component

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




Motivation

expectedImprovement tells web developers how much improvement the 
DelegatedInkTrails API will provide to their current ink latency. 
However, this attribute is not worth increases to fingerprinting 
entropy. The difference in cost to the web developer between using 
the expectedImprovement attribute and actually delegating the "wet" 
ink trail to the OS/Browser is minimal, and upon additional 
discussion, there was no good reason found for the web developer not 
delegating the ink trail after receiving some value from the 
expectedImprovement attribute (all improvement is good improvement). 
The removal of this attribute should have minimal impact to web 
compatibility as it was never implemented in Blink in the first 
place. This is the intent to remove the attribute from the web 
exposed DelegatedInkTrailPresenter interface. There is no usage of 
this attribute according to blink use counters.




Initial public proposal

None


TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

No interoperability or compatibility risks as the feature was not 
implemented and is not used; even incorrectly.




/Gecko/: No signal

/WebKit/: No signal

/Web developers/: No signals

/Other signals/:


WebView application risks

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


None



Debuggability

None



Is this feature fully tested by web-platform-tests

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

No


Flag name on chrome://flags

None


Finch feature name

None


Non-finch justification

None


Requires code in //chrome?

False


Tracking bug

https://bugs.chromium.org/347647410


Estimated milestones

Shipping on desktop 130



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5194773674328064?gate=5169972251459584

This intent message was generated by Chrome Platform Status 
<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/6923df06209867e8%40google.com 
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6923df06209867e8%40google.com?utm_medium=email&utm_source=footer>.


--
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c5506e66-53ee-44ce-8046-27f73cd1f81c%40chromium.org.

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

[Mike Taylor]

LGTM1 to remove - if there's no usage, now is the time to get that done.

Relevant use counter for those interested: 
https://chromestatus.com/metrics/feature/timeline/popularity/5017


On 8/26/24 12:13 PM, Chromestatus wrote:



Contact emails

sahir.vell...@microsoft.com


Explainer

None


Specification

https://wicg.github.io/ink-enhancement


Summary

The attribute tells web developers how much improvement the 
DelegatedInkTrails API will provide to their current ink latency. 
However, this attribute is not worth increases to fingerprinting entropy.




Blink component

Blink>Input 
Input> 




Motivation

expectedImprovement tells web developers how much improvement the 
DelegatedInkTrails API will provide to their current ink latency. 
However, this attribute is not worth increases to fingerprinting 
entropy. The difference in cost to the web developer between using the 
expectedImprovement attribute and actually delegating the "wet" ink 
trail to the OS/Browser is minimal, and upon additional discussion, 
there was no good reason found for the web developer not delegating 
the ink trail after receiving some value from the expectedImprovement 
attribute (all improvement is good improvement). The removal of this 
attribute should have minimal impact to web compatibility as it was 
never implemented in Blink in the first place. This is the intent to 
remove the attribute from the web exposed DelegatedInkTrailPresenter 
interface. There is no usage of this attribute according to blink use 
counters.




Initial public proposal

None


TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

No interoperability or compatibility risks as the feature was not 
implemented and is not used; even incorrectly.




/Gecko/: No signal

/WebKit/: No signal

/Web developers/: No signals

/Other signals/:


WebView application risks

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


None



Debuggability

None



Is this feature fully tested by web-platform-tests

?

No


Flag name on chrome://flags

None


Finch feature name

None


Non-finch justification

None


Requires code in //chrome?

False


Tracking bug

https://bugs.chromium.org/347647410


Estimated milestones

Shipping on desktop 130



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5194773674328064?gate=5169972251459584

This intent message was generated by Chrome Platform Status 
.

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


--
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f4597df0-80e0-4503-881b-181d803584db%40chromium.org.

Re: [blink-dev] Intent to Ship: Update the syntax of `text-wrap` to match the new spec

[Mike Taylor]

LGTM2

On 8/21/24 5:52 PM, Alex Russell wrote:

LGTM1

On Tuesday, August 20, 2024 at 12:05:14 AM UTC-7 Koji Ishii wrote:

Thank you for pointing this out, Demenic.

Will there be any compatibility issues, i.e. code that means
something different before and after the change?


You're right, there will be. The `balance` and `pretty` are valid
for the `text-wrap` property, before or after this change, but
they are no longer valid values for the `white-space` property.

The risk is considered low for the reasons below:

 1. It's more common to use the `text-wrap` property for these
values than to use the `white-space` property, as articles
such as
https://developer.chrome.com/docs/css-ui/css-text-wrap-balance

suggest using the `text-wrap` property.
 2. Gecko and WebKit didn't ship the old spec behavior, and thus
they never supported these values for the `white-space` property.
 3. When there were breaks, at worst, balancing or the Knuth-Plass
algorithm don't apply, but the text is still readable in
reasonably good layout.

Updated the chromestatus entry
 with this text.

2024年8月20日(火) 14:06 Domenic Denicola :



On Tue, Aug 20, 2024 at 1:59 PM Koji Ishii
 wrote:


Contact emails

ko...@chromium.org


Explainer

None


Specification

https://drafts.csswg.org/css-text-4/#text-wrap-shorthand



Design docs



https://docs.google.com/document/d/1Xl3J1WCg--fUm1-FX5gHbJIIC0szNwulQV7nW4n6_aY/edit?usp=sharing




Summary

Updates the CSS syntax for the CSS white-space and
text-wrap properties to match the spec and other browsers.
Blink changed the CSS white-space property in
crbug.com/40257360 , shipped
in M114. The CSS white-space and text-wrap properties have
changed since then, and other browsers are shipping the
new behavior. This feature makes Blink match the new spec
and other browsers.



Blink component

Blink>Layout>Inline




TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

None


Will there be any compatibility issues, i.e. code that means
something different before and after the change?



/Gecko/: Shipped/Shipping

/WebKit/: Shipped/Shipping
(https://bugs.webkit.org/show_bug.cgi?id=249840
)

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

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-text/parsing?label=experimental&label=master&aligned&view=interop&q=label%3Ainterop-2024-text-wrap





Flag name on chrome://flags

None


Finch feature name

None


Non-finch justification

None


Please provide either a Finch feature name or a non-Finch
justification.



Requires code in //chrome?

False


Estimated milestones

Shipping on desktop 130
Shipping on Android 130
Shipping on WebView 130



Anticipated spec changes

Open questions about a feature may be a source of future
web compat or interop issue

Re: [blink-dev] Intent to Ship: meter element fallback styles

[Mike Taylor]

LGTM2 - it would be great to add additional tests as mentioned.

On 8/21/24 5:43 PM, Alex Russell wrote:

LGTM1; thanks for the detailed responses to Domenic.

On Sunday, August 18, 2024 at 10:30:50 PM UTC-7 Traian Captan wrote:

This relates to the interoperability issues discussed below.
You say "This change increases interop with Safari and Firefox
which already provide a reasonable fallback style for 
elements with `appearance: none`," but don't give detail on
whether our "reasonable fallback style" is the same as or
different from theirs.

We match both their fall back styles. Safari was already matching
Firefox's fallback style.

From what I can tell with some brief testing with Firefox
Linux and Safari Tech Preview MacOS, they both produce a 80x16
box with 0 margin and padding in this "primitive appearance"
mode. Firefox's inspector does not show any UA styles, but
Safari shows UA styles of: { box-sizing: border-box; display:
inline-block; block-size: 1em; inline-size: 5em;
vertical-align: -0.2em; }. These actually match the spec's
expected "native appearance", but I guess the "native
appearance" has slightly different visuals, e.g. rounded
corners and a shinier progress color.


What UA styles will we follow? Is there a chance we could
agree on the same styles as Safari, and thus update the part
of the HTML spec I pointed out above?

Yes. We


match Safari's UA style

.

I don't think we should block this intent on getting this all
specified perfectly, since the change you're making is
bringing us closer to interop in a historically
under-specified area. But I do want to understand to what
extent we'll match Firefox and Safari, and it would be an
excellent bonus if we took this opportunity to improve the
spec for everyone while we were here.

Agreed. The fallback styles I added match both Firefox and Safari.
There is also an open css-ui github issue regarding how the fall
back styles should look like : [css-ui-4] appearance: none on
 

Those tests are a great start. If we can agree on the UA
styles per the above, we could expand them using tests similar
to these

.

Thanks! That sounds good to me.

Regards,
Traian

--
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/e7572a42-b918-4efa-876f-f1165a4b33c4n%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/30e3195e-d23f-4e3b-afe4-afbbd21eaf37%40chromium.org.

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

[Mike Taylor]

Thanks for the thoughtful article and feedback Yoav - we'll chat about 
it internally.


On 8/20/24 11:24 PM, Yoav Weiss (@Shopify) wrote:



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


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

Email Body


Contact emails

victor...@chromium.org ,
miketa...@chromium.org 


Explainer

https://github.com/explainers-by-googlers/reduce-accept-language



TAG review


To be filed.


Summary

In order to reduce the amount of passively available entropy in
HTTP requests, we want to reduce the amount of information the
Accept-Language header exposes in HTTP requests and JS interface
navigator.languages. Instead of sending every user's language
preferences via Accept-Language, we only send the user’s most
preferred language after language negotiation in the
Accept-Language header. For the HTTP Accept-Language header, we
will potentially expand a base language based on the
language-region pair (e.g., if the preferred language is “en-US”
we will expand to “en-US, en;q=0.9”). The JS getter
navigator.languages returns the same value as navigator.language.


We would like to run a Finch 1% experiment from M128 to M131
inclusive.


Blink component

Privacy>Fingerprinting



Risks


Interoperability and Compatibility

The compatibility risk is relatively low for most users since
we're planning to reduce the amount of information in the
Accept-Language header and navigator.languages, rather than remove
the header or change value format in the header. Most existing
Accept-Language detection code should continue to work. This
experiment should help us validate this assumption and identify
corner cases.


As for interoperability, for multilingual sites to rely on the
Accept-Language, developers would need to depend on a user's full
Accept-Language list for some browsers and a primary user's
Accept-Language for others. Another signal is that the Chrome
incognito model already reduced the Accept-Language header and JS
interface navigator.languages to one language, and Safari ships
this behavior for many users today.


Gecko: Pending
(https://github.com/mozilla/standards-positions/issues/1014
)


WebKit: Shipped
(https://github.com/WebKit/standards-positions/issues/338
) Safari
already reduced the Accept-Language to a single language in most
cases.


Web developers: Some web developers are concerned about the
client-side language negotiation implications
(https://github.com/Tanych/accept-language/issues/10
).


Experiment Goals

The goal of this experiment is to ensure web compatibility with
our proposed changes. Developers can also test how reducing the
Accept-Language request header and the JS getter
navigator.languages will affect their systems via the
chrome://flags/#reduce-accept-language flag, especially to
understand the impact on client side language negotiation via
navigator.languages. We will be relying heavily on user and
developer feedback to identify where breakage occurs,  or where
use cases are not accounted for, especially for multilingual sites
depending on the Accept-Language header, and navigator.languages.


Experiment Risks

There are some risks, as many multilingual sites have come to rely
on the value in Accept-Language header and JS interfaces
navigator.languages to send the right representation pages to the
user.  Site breakage can take many forms, both obvious and
non-obvious - which is the point of running this experiment. If we
are confident the design is largely web-compatible, we will
request a Deprecation Trial for sites to be able to have time to
migrate or modify how their sites work.


Debuggability

Both of these settings and the resulting network requests are
visible in DevTools.


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

No (All but WebView)


Is this feature fully tested byweb-platform-tests

?

 

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

[Mike Taylor]

Thanks for the feedback - but if you re-read the explainer, you'll note 
that preferred languages will continue to work with the proposed 
Avail-Language API.


On 8/11/24 1:14 AM, Eli Grey wrote:
Restricting accept-language to 'common combinations' is fundamentally 
at odds with personal agency. This can break the web for people with 
uncommon combinations of accepted languages. This change would 
effectively discriminate against these people by denying them access 
to websites in their preferred languages that previously worked just 
fine.


Language preferences should not be ignored just because they're 
unique, and therefore trackable.


On Wednesday, August 7, 2024 at 8:41:48 AM UTC-7 vict...@chromium.org 
wrote:


Email Body


Contact emails

vict...@chromium.org, mike...@chromium.org


Explainer

https://github.com/explainers-by-googlers/reduce-accept-language



TAG reviewTo be filed.
Summary

In order to reduce the amount of passively available entropy in
HTTP requests, we want to reduce the amount of information the
Accept-Language header exposes in HTTP requests and JS interface
navigator.languages. Instead of sending every user's language
preferences via Accept-Language, we only send the user’s most
preferred language after language negotiation in the
Accept-Language header. For the HTTP Accept-Language header, we
will potentially expand a base language based on the
language-region pair (e.g., if the preferred language is “en-US”
we will expand to “en-US, en;q=0.9”). The JS getter
navigator.languages returns the same value as navigator.language.


We would like to run a Finch 1% experiment from M128 to M131
inclusive.


Blink component

Privacy>Fingerprinting



Risks


Interoperability and Compatibility

The compatibility risk is relatively low for most users since
we're planning to reduce the amount of information in the
Accept-Language header and navigator.languages, rather than remove
the header or change value format in the header. Most existing
Accept-Language detection code should continue to work. This
experiment should help us validate this assumption and identify
corner cases.


As for interoperability, for multilingual sites to rely on the
Accept-Language, developers would need to depend on a user's full
Accept-Language list for some browsers and a primary user's
Accept-Language for others. Another signal is that the Chrome
incognito model already reduced the Accept-Language header and JS
interface navigator.languages to one language, and Safari ships
this behavior for many users today.


Gecko: Pending
(https://github.com/mozilla/standards-positions/issues/1014
)


WebKit: Shipped
(https://github.com/WebKit/standards-positions/issues/338
) Safari
already reduced the Accept-Language to a single language in most
cases.


Web developers: Some web developers are concerned about the
client-side language negotiation implications
(https://github.com/Tanych/accept-language/issues/10
).


Experiment Goals

The goal of this experiment is to ensure web compatibility with
our proposed changes. Developers can also test how reducing the
Accept-Language request header and the JS getter
navigator.languages will affect their systems via the
chrome://flags/#reduce-accept-language flag, especially to
understand the impact on client side language negotiation via
navigator.languages. We will be relying heavily on user and
developer feedback to identify where breakage occurs,  or where
use cases are not accounted for, especially for multilingual sites
depending on the Accept-Language header, and navigator.languages.


Experiment Risks

There are some risks, as many multilingual sites have come to rely
on the value in Accept-Language header and JS interfaces
navigator.languages to send the right representation pages to the
user.  Site breakage can take many forms, both obvious and
non-obvious - which is the point of running this experiment. If we
are confident the design is largely web-compatible, we will
request a Deprecation Trial for sites to be able to have time to
migrate or modify how their sites work.

Debuggability

Both of these settings and the resulting network requests are
visible in DevTools.


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

No (All but WebView)


Is this feature fully teste

Re: [blink-dev] Intent to Deprecate and Remove: Remove CanvasRenderingContext2D method scrollPathIntoView

[Mike Taylor]

+1 - no approvals needed. :)

On 8/9/24 1:20 AM, Domenic Denicola wrote:
If this method was only ever enabled behind a flag, I don't think this 
removal requires any API owner approval. Happy removing!


On Thu, Aug 8, 2024 at 10:30 PM Chromestatus 
 wrote:



Contact emails

schen...@chromium.org


Explainer

None


Specification

https://github.com/whatwg/html/issues/8216


Summary

The scrollPathIntoView method on CanvasRenderingContext2D was
implemented in Chrome behind a flag, but never shipped and never
implemented by any other browsers in the nearly 10 years of its
existence. The WHATWG has agreed to remove the method due to lack
of interest. It has zero usage according to the stats, and MDN
says it is not implemented anywhere. We are removing the method
and associated flag and tests.



Blink component

Blink>Canvas





Motivation

The scrollPathIntoView method has been in the spec since 2011 and
no browsers have shipped it yet, though there is an experimental
implementation hidden behind a runtime flag in Chromium. There
seems to be no implementer or web developer interest for this
feature: No usage reported in chromestatus No related outstanding
issues in the chromium issue tracker. No activity on the WebKit
issue until it was just closed:
https://bugs.webkit.org/show_bug.cgi?id=149987 Firefox bug has
been open for 10 years with no activity:
https://bugzilla.mozilla.org/show_bug.cgi?id=1120401 It was agreed
by WHATWG to remove the method after a suggestion from Justin
Novosad, and there is even a WPT test ensuring it is removed
(https://wpt.fyi/results/html/canvas/historical.window.html,
"CanvasRenderingContext2D.scrollPathIntoView method is removed").
It has now been removed from the spec and from MDN.



Initial public proposal

None


TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

None



/Gecko/: No signal

/WebKit/: No signal

/Web developers/: No signals

/Other signals/:


WebView application risks

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

None



Debuggability

None



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


Estimated milestones

No milestones specified



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5891170383953920?gate=6550238987550720


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/fb93b6061f2c07e6%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/CAM0wra_9_CvXEWJ%2BfXqSZSh8%3Dg4EXaeWyiKrWV1g%2BGe6cbxHrg%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/fa915996-9810-4dab-8839-3554c389b7fd%40chromium.org.

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

[Mike Taylor]

Hey Philip,

Yes - we have discussed this a little bit, and are open to finalizing on 
that as a solution. But we'd like to gather some baseline metrics on the 
most minimal version first (which is the point of this experiment), and 
explore other solutions depending on compat impact (which we plan to 
measure in a handful of ways, including number of times users are trying 
to use the in-browser translation feature).


later,
Mike

On 8/7/24 11:59 AM, Philip Jägenstedt wrote:
Looking at the alternatives considered 
, 
I wonder if you've also explored identifying common combinations of 
languages, and limiting the header to the most common current values 
of the header? The combination of a small language like Swedish and a 
large language (English, Chinese, Spanish, etc) in some order is 
probably very common.


Heads up that I am going OOO, so I won't be able to follow up, so 
don't block this intent on me.


On Wed, Aug 7, 2024 at 5:51 PM Alex Russell  
wrote:


Hey Victor,

As you know, removal of entropy is not in and of itself a useful
goal. A large number of users on the web are bi-lingual. Is there
any analysis that this will do more good than harm?

Thanks,

Alex

On Wed, Aug 7, 2024 at 8:41 AM Victor Tan 
wrote:

Email Body


Contact emails

victor...@chromium.org ,
miketa...@chromium.org 


Explainer

https://github.com/explainers-by-googlers/reduce-accept-language



TAG review


To be filed.


Summary

In order to reduce the amount of passively available entropy
in HTTP requests, we want to reduce the amount of information
the Accept-Language header exposes in HTTP requests and JS
interface navigator.languages. Instead of sending every user's
language preferences via Accept-Language, we only send the
user’s most preferred language after language negotiation in
the Accept-Language header. For the HTTP Accept-Language
header, we will potentially expand a base language based on
the language-region pair (e.g., if the preferred language is
“en-US” we will expand to “en-US, en;q=0.9”). The JS getter
navigator.languages returns the same value as navigator.language.


We would like to run a Finch 1% experiment from M128 to M131
inclusive.


Blink component

Privacy>Fingerprinting



Risks


Interoperability and Compatibility

The compatibility risk is relatively low for most users since
we're planning to reduce the amount of information in the
Accept-Language header and navigator.languages, rather than
remove the header or change value format in the header. Most
existing Accept-Language detection code should continue to
work. This experiment should help us validate this assumption
and identify corner cases.


As for interoperability, for multilingual sites to rely on the
Accept-Language, developers would need to depend on a user's
full Accept-Language list for some browsers and a primary
user's Accept-Language for others. Another signal is that the
Chrome incognito model already reduced the Accept-Language
header and JS interface navigator.languages to one language,
and Safari ships this behavior for many users today.


Gecko: Pending
(https://github.com/mozilla/standards-positions/issues/1014
)


WebKit: Shipped
(https://github.com/WebKit/standards-positions/issues/338
)
Safari already reduced the Accept-Language to a single
language in most cases.


Web developers: Some web developers are concerned about the
client-side language negotiation implications
(https://github.com/Tanych/accept-language/issues/10
).


Experiment Goals

The goal of this experiment is to ensure web compatibility
with our proposed changes. Developers can also test how
reducing the Accept-Language request header and the JS getter
navigator.languages will affect their systems via the
chrome://flags/#reduce-accept-language flag, especially to
understand the impact on client side language negotiation via
navigator.languages. We will be relying heavily on user and

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

[Mike Taylor]

LGTM3

On 8/7/24 11:45 AM, Chris Harrelson wrote:

LGTM2

On Wed, Aug 7, 2024 at 8:25 AM Yoav Weiss (@Shopify) 
 wrote:


LGTM1 % spec nit

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

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

On Mon, Jul 22, 2024 at 5:26 PM 'Maksim Orlovich' via
blink-dev  wrote:

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


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


Summary

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


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

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

1.

unintentional/accidental misconfiguration where the
trusted signals origin (specified in the interest group or
auction configuration) could now be a different origin but
the script processing these signals might not be updated
to understand this or process signals from another origin, or

2.

intentional/malicious misconfiguration where someone might
have changed the origin of the trusted signals unbeknownst
to the script processing them.  This isn’t possible for
trusted bidding signals as the interest group (where the
trusted bidding signals URL is specified) is only settable
from same-origin contexts.


That last part is using AsyncTask

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

1.

  Auction configurations (where the trusted scoring
signals URL is specified) don’t have the same same-origin
setting requirements, but this is why this proposal
requires the scoring script to include the
Ad-Auction-Allow-Trusted-Scoring-Signals-From response
header which lists allowed origins for the trusted scoring
signals.  Misconfiguration here could look like a scoring
script allowing two trusted scoring signals origins, and
someone switching between these allowed origins unexpectedly.

To prevent these misconfigurations, we changed how the trusted
signals are passed to the scripts: they are passed in a new
parameter so as not to be confused with the previously
always-same-origin signals parameter, and this new parameter
is a map from the origin of the signals to the signals
themselves.  This was discussed as risk #2 in my GitHub post
.

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

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

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

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f3759194-8de5-45d1-9c96-6c4421194337n%40chromium.org

.

--
You re

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&utm_source=footer>.



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

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

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:

https:

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

  

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&s=created_time:desc>

Mobile>WebView

<https://g-issues.chromium.org/issues?q=status:open%20componentid:1456456&s=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&label=experimental&product=chrome&product=firefox&product=safari&product=android_webview&aligned>


Flag name on chrome://flags

None


Finch feature name

WebPermissionsApi


Requires code in //chrome?

False


 

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

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

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 f

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 fi

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

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 ab

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 th

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 platf

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&label=experimental&aligned&q=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 g

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 Inte

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 (e.g

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 blink-

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

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 Go

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&utm_source=footer>.




--
You 

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&utm_source=footer>.




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

Re: [blink-dev] Intent to 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&utm_source=footer>.




--
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/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&utm_source=footer>.


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

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%3DVDdJ9q1nwovSJdgP

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&utm_source=footer>.




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





De

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