from:"Mike Taylor"

Re: [blink-dev] Intent to Ship: MediaCapabilities: Query HDR support with decodingInfo()

2023-10-25 Thread Mike Taylor


LGTM2

On 10/25/23 3:06 PM, 'Rick Byers' via blink-dev wrote:
Looks pretty straightforward to me, especially with Safari already 
shipping. LGTM1


On Wed, Oct 18, 2023 at 7:18 PM Dale Curtis  
wrote:



Contact emails


v...@microsoft.com, gw...@microsoft.com,
gur...@microsoft.com, dalecur...@chromium.org


Explainer



https://github.com/w3c/media-capabilities/blob/main/explainer.md#decode-capabilities


Specification


https://www.w3.org/TR/media-capabilities/#hdrmetadatatype


Summary


Extends the Media Capabilities API to allow detection of
HDR rendering support via three new VideoConfiguration
dictionary fields: hdrMetadataType, colorGamut,
transferFunction. Chromium implements its own tone-mapping
algorithms so will always return true for HDR10
(smpteSt2086) static metadata. HDR10+ (smpteSt2094-10) and
Dolby Vision (smpteSt2094-40) dynamic metadata are not
currently supported, so will return false. We anticipate
adding support for dynamic metadata in the future, so this
API will allow developers to select the appropriate
content for users with support.



Blink component


Blink>Media>Capabilities




TAG review


Already shipping by another UA. The now-closed Media
Capabilities TAG review covered similar discussions:
https://github.com/w3ctag/design-reviews/issues/218


TAG review status


Not applicable


Risks




Interoperability and Compatibility


Low interop risk: Already shipping in Safari.



/Gecko/: Neutral
(https://github.com/mozilla/standards-positions/issues/910)

/WebKit/: Shipped/Shipping
(https://www.w3.org/2019/11/19-mediawg-minutes.html)

/Web developers/: Positive

(https://github.com/w3c/media-capabilities/issues/118#issuecomment-511461132)

/Other signals/:


Activation


Will start returning false for some DolbyVision and HDR10+
metadata types on the web -- playback would have been
broken already for these.



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 risks unique to WebView.



Debuggability


Debuggable through media dev tools and chrome://gpu
information.



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


Yes


Is this feature fully tested by web-platform-tests

?


Yes


https://wpt.fyi/results/media-capabilities/decodingInfo.any.html?label=experimental=master




Thanks! Is there a bug filed for the three  tests failing in Chrome?


Flag name on chrome://flags




Finch feature name


MediaCapabilitiesDynamicRange


Requires code in //chrome?


False


Tracking bug


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


Estimated milestones


Shipping on desktop 120

Shipping on Android 120

Shipping on WebView 120



Anticipated spec changes


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

Spec changes have already been submitted since the feature
is shipping in Safari.


Link to entry on the Chrome Platform Status


https://chromestatus.com/feature/6640863931269120


Links to previous Intent discussions


Intent to prototype:

https://groups.google.com/a/chromium.org/g/blink-dev/c/jBzVLBz-Yk4/m/ORuQg2zAEwAJ

This intent message was generated by Chrome Platform
Status .

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

Re: [blink-dev] Intent to ship: The Login Status API and its use in FedCM

2023-10-25 Thread Mike Taylor


LGTM2

On 10/25/23 2:39 PM, 'Rick Byers' via blink-dev wrote:
FWIW since the PR has landed, the correct link to reference the spec 
is https://fedidcg.github.io/FedCM/#browser-api-login-status. Since 
WebKit has expressed some interest in using this API in other 
scenarios than just FedCM I imagine there may be a request at some 
point to move it out of the FedCM spec. But that seems like a bridge 
we can cross if/when we come to it. Thank you for putting the extra 
work in at TPAC to get consensus on unification with login status.


And +1 that the WPTs are in place and running where it currently 
matters, and it's just the wpt.fyi infra that we're waiting on review 
for. So I don't see any need to block on that.


LGTM1 to ship


On Wed, Oct 25, 2023 at 12:17 PM Nicolás Peña  wrote:

To add to what Christian mentioned, we do have WPT tests for this
feature here


 and
they have been running in Chromium CQ, so it is only WPT.fyi that
is missing coverage. And we already know that Firefox and Apple
have not yet implemented FedCM, so at the moment we would not gain
any additional information from having the tests pass in WPT.fyi.

On Wednesday, October 25, 2023 at 12:11:54 PM UTC-4 blink-dev wrote:

It seems I may have a reviewer *now*, maybe. It's been very
hard to get someone to review this and I don't know if I will
be able to get a timely lgtm, so I am hoping that this I2S
won't get blocked on this, since this is mostly outside my
control. (I don't think past I2S were blocked on wpt tests
when the problem was missing infrastructure support)

Christian

On Wed, Oct 25, 2023 at 12:04 PM Philip Jägenstedt
 wrote:

Hi Christian,

Do you have a reviewer for
https://github.com/web-platform-tests/wpt/pull/40709 so
you can get it merged? Just like spec changes, tests are
ideally merged and showing results on wpt.fyi before we
ship, so that any issues are apparent and can be addressed.

Best regards,
Philip

On Wed, Oct 18, 2023 at 6:54 PM Christian Biesinger
 wrote:

+Ben and Martin from Mozilla -- could you weigh in on
whether we should create a Mozilla standards position
request for this?

Daniel: there is no technical limitation that prevents
a non-IDP from calling this API, apologies for the
unclear phrasing. However, a non-IDP (or indeed an IDP
that does not use FedCM) will get no benefit from
calling this API.

Christian

On Wed, Oct 18, 2023 at 12:11 PM Daniel Bratell
 wrote:

Hi, I just have a couple of questions without
having read through the intent in detail.

You say "Our goal is to open this up to other
websites in the future.", but what does that mean?
Is there some kind of web site restriction today?

Not creating a
https://github.com/mozilla/standards-positions/issues
entry seems a bit wrong even if someone at Mozilla
has said it is not needed. They have in the past
specifically wanted us to explicitly use the
standards-positions repo rather than relying on
negative or positive statements elsewhere. Would
it be best to post one just in case?

/Daniel

On 2023-10-12 21:04, Christian Biesinger wrote:



Contact emails

cbiesin...@chromium.org


Explainer


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




Specification

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



Summary

The Login Status API
(formerly
IdP Sign-in Status API) allows identity providers
to signal to the browser when their users are
logging-in/out. Our goal is to open this up to
other websites in the future.

This signal, in this intent, is used by FedCM to
address a silent timing attack, and in doing so,
allows FedCM to operate

Re: [blink-dev] Third-party deprecation trial

2023-10-25 Thread Mike Taylor


Hi there,

On 10/25/23 2:09 PM, J C wrote:
I am looking forward to requesting this third-party deprecation trial 
. 
I am a little bit confused whether "Register for 
DisableThirdPartyStoragePartitioning Trial 
" 
is the one? Or, there will be dedicated trial will be released soon.


No, DisableThirdPartyStoragePartitioning does not affect Third Party 
Cookies (though I can understand how that is confusing). You can 
continue to follow this list and watch out for an Intent covering that 
dedicated trial, and I imagine the linked blog post will be updated once 
it's released as well.


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/54abbb0d-57bd-43a9-8460-6cce1abc594e%40chromium.org.

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

2023-10-25 Thread Mike Taylor


On 10/20/23 2:27 PM, 'Philipp Hancke' via blink-dev wrote:



Contact emails


*

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


*


Explainer


*

None

*

For those looking for an explainer, hope down to the design docs section 
(nice explainer, btw!).



*
*


Specification


*


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




*


Design docs


*


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




*


Summary


*

Adds AV1EncoderConfig (a dictionary containing
forceScreenContentTools) to the VideoEncoderConfig along these
lines:

encoder.configure({ codec: 'av01.0.04M.08', av1: {
forceScreenContentTools: true}, width: 1920, height: 1080,
bitrate: 2_000_000, framerate: 5, });

This allows an application to encode “screen content”, in
particular presentation slides, in a more efficient way
supported by the AV1 codec.

This material is typically static, often includes text, a
limited set of colors, lots of repetitive content (e.g.
straight lines, shapes) for which the encoder can optimize.

See the explainer for a lot of visual examples. This AV1
feature is already supported by WebRTC and enabled for screen
sharing MediaStreamTracks so this increases platform consistency.



*


Blink component


*

Blink>Media>WebCodecs




*


TAG review


*

None


*


TAG review status


*

Not applicable

*

An FYI review would be nice (especially given the discussions around 
per-frame/per-codec options), can you send one?



*
*


Risks


*

*


Interoperability and Compatibility


*

None


Gecko: Neutral similar to this situation

https://github.com/mozilla/standards-positions/issues/837#issuecomment-1614666364



*

Can we go ahead and request a position? It's not clear to me that 
Mozilla was present when the feature was discussed at 
https://lists.w3.org/Archives/Public/public-media-wg/2023Apr/0007.html.



*

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


Web developers: No signals Presented in the screen capture
community group during TPAC 2023, slides here:

https://docs.google.com/presentation/d/10i4HFYZ4CylpFUuoJcigfiI5uS7pK3uaseQpcYhugAY/edit#slide=id.g27ea3fad398_0_0




Other signals:


*


WebView application risks


*

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

None


*


Debuggability


*

None


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


*

Yes


*


Is this feature fully tested by web-platform-tests

?


*

No

Unclear to what degree this is testable. Enabling this feature
reduces the encoded frame size which makes it tough to test,
it might be possible with a canvas source that provides
predictable input similar

tohttps://webrtc.github.io/samples/src/content/insertable-streams/video-processing/





*


Flag name on chrome://flags


*

None


*


Finch feature name


*

None


*


Non-finch justification


*

None


*


Requires code in //chrome?


*

False


*


Tracking bug


*

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



*


Estimated milestones

Re: [blink-dev] Re: Intent to Extend Experiment: No-Vary-Search header, Speculation Rules expects_no_vary_search support in prefetch cache

2023-10-25 Thread Mike Taylor

Apologies - this intent didn't show up in our review tooling (cc Jason),
so it's slipped under the radar.

I believe y'all have met the bar to extend again, given that the below
criteria are largely done:

Draft spec
TAG review
bit.ly/blink-signals requests
Outreach for feedback from the spec community (maybe except this one?)
WPT tests

LGTM to extend from 119 to 120 inclusive.

On 10/25/23 11:19 AM, Liviu Tinta wrote:
Following up on this intent. Is there anything else needed from a
process perspective to extend the experiment ?

On Monday, October 2, 2023 at 6:31:39 PM UTC-4 blink-dev wrote:

Contact emails

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

Original I2E

https://groups.google.com/a/chromium.org/g/blink-dev/c/6gsc52WQgrU/m/qcTayjt6DAAJ

Previous Intent to Extend Experiment:

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

No-Vary-Search Spec

https://wicg.github.io/nav-speculation/no-vary-search.html

No-Vary-Search hint explainer

https://github.com/WICG/nav-speculation/blob/main/triggers.md#no-vary-search-hint

No-Vary-Search hint spec

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

Origin Trial

https://developer.chrome.com/origintrials/#/view_trial/4146689356901384193

Summary

We propose extending the "No-Vary-Search support in navigation
prefetch cache" origin trial. We decided to extend the experiment
based on positive feedback from the developer experimenting with
the No-Vary-Search header and No-Vary-Search hint. (see
ChromeStatus entry:
https://chromestatus.com/feature/4887338302308352
).

We are planning to extend the experiment for 2 more milestones
M119 to M120 inclusive.

Blink component

Internals>Preload

Motivation

The developer we are working with would like to experiment more
with No-Vary-Search hint in the context of No-Vary-Search header
to evaluate the added impact of the new functionality.

TAG review

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

TAG review status

Complete at this time. TAG didn't see any major issue and
encouraged us to continue experimenting.

Risks

Interoperability and Compatibility

Gecko: No signal. Request for Standards
Position:https://github.com/mozilla/standards-positions/issues/717
.

WebKit: No signal. Informal positive signals from individual
engineers at TPAC 2022. Request for Standards
Position:https://github.com/WebKit/standards-positions/issues/106
.

Web developers: 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".
"expects_no_vary_search" functionality of Speculation Rules wasn't
available until M116, and even after that it was only available to
a small percentage of the population because of cautious roll-out
of a feature that

Re: [blink-dev] Intent to Ship: WebAssembly Multi-Memory

2023-10-25 Thread Mike Taylor


LGTM3

On 10/25/23 11:25 AM, Chris Harrelson wrote:

LGTM2

On Wed, Oct 25, 2023 at 8:23 AM Yoav Weiss  wrote:

LGTM1

On Wednesday, October 25, 2023 at 4:24:04 PM UTC+2 Clemens Backes
wrote:

There has not been an update on this ITS in 8 days. What's the
expected timeline to get the LGTMs?


Last week was BlinkOn and we do most reviews in our weekly meeting on 
Wednesdays.



As the M120 branch cut is around the corner, I'll go ahead and
prepare the launch, given that this is a feature voted to
phase 4 in the W3C WebAssembly Community Group and all other
approvals are there.

On Tue, Oct 17, 2023 at 8:09 PM Clemens Backes
 wrote:

On Tue, Oct 17, 2023 at 7:42 PM Alex Russell
 wrote:

It's unclear why the TAG is not being informed or
consulted. This has deep architectural implications
for DOM integration and I'd expect to see those
explained and worked.


As written in the ITS, a TAG review is not required as per
https://v8.dev/docs/feature-launch-process#tag. The
changes to the WebAssembly JS API are actually very
minimal: Instead of one exported memory, you can now have
multiple.

I don't see any implication for anything DOM related (but
I am also not entirely sure what you mean by "DOM
integration", there is nothing like this planned in
WebAssembly). Can you elaborate on that?


On Tue, Oct 17, 2023, 10:08 AM Clemens Backes
 wrote:


Contact emails

cleme...@google.com


Explainer

We are ready for shipping the Multi-Memory
proposal for WebAssembly, which recently moved to
phase 4 according to the WebAssembly W3C process.


Specification


https://github.com/WebAssembly/multi-memory/blob/main/proposals/multi-memory/Overview.md


Design docs


https://github.com/WebAssembly/multi-memory/blob/main/proposals/multi-memory/Overview.md


Summary

Add support for more than one memory per
WebAssembly module as specified in the WebAssembly
Multi-Memory proposal:

https://github.com/WebAssembly/multi-memory/blob/main/proposals/multi-memory/Overview.md


Blink component

Blink>JavaScript>WebAssembly




Search tags

Wasm
,
WebAssembly
,
Multi-Memory



TAG review


Not required as per:
https://v8.dev/docs/feature-launch-process.


TAG review status

Not applicable


Risks


Interoperability and Compatibility

None



/Gecko/: Positive

/WebKit/: Positive

/Web developers/: Strongly positive
(https://github.com/WebAssembly/proposals)

/Other signals/: This was voted to phase 4
(standardization) at the October 2023 WebAssembly
Community Group meeting. 38 of 43 votes were
"strongly for".


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

All memories are inspectable from DevTools, just
like the first memory.


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

Yes


Is this feature fully tested by
web-platform-tests

?

The WebAssembly proposal comes with all relevant

Re: [blink-dev] Re: Intent to Ship: WebGPU maxBindGroupsPlusVertexBuffers limit

2023-10-25 Thread Mike Taylor


LGTM2

On 10/25/23 4:32 AM, 'François Beaufort' via blink-dev wrote:



On Wed, Oct 25, 2023 at 10:28 AM Yoav Weiss  
wrote:


LGTM1

On Tuesday, October 24, 2023 at 3:32:23 PM UTC+2 blink-dev wrote:

Contact emails

fbeauf...@google.com, cwal...@google.com


Specification


https://gpuweb.github.io/gpuweb/#dom-gpusupportedlimits-maxbindgroupsplusvertexbuffers




Summary

The WebGPU maxBindGroupsPlusVertexBuffers limit is the maximum
number of bind group and vertex buffer slots used
simultaneously, counting any empty slots below the highest
index. It is validated in createRenderPipeline() and in draw
calls. This change adds maxBindGroupsPlusVertexBuffers to the
GPUSupportedLimits interface, and as an accepted key by the
GPUDeviceDescriptor.requiredLimits record.


Blink component

Blink>WebGPU




TAG review

None


Presumably not required as this has landed in the standard and
implemented by another engine.


Yes. It has landed in the WebGPU specification and it is added to 
other engines as shown below.



TAG review status

Not applicable


Risks

Interoperability and Compatibility

The maxBindGroupsPlusVertexBuffers limit has not yet been
implemented in any browser, but it has been fully approved by
the GPU for the Web Community Group, with representatives from
Safari, Firefox, and Chrome.
Seehttps://github.com/gpuweb/gpuweb/issues/2749#issuecomment-1447717468



Gecko: Positive
(https://hg.mozilla.org/mozilla-central/rev/5ed1439037c4
)


WebKit: In development

(https://github.com/WebKit/WebKit/commit/26f539228dd0a3ee85e38e886753c41955e93971

)


I'm guessing this is implemented in both? I agree with your
request on another thread that it'd be simpler if we had a
"stages" system here similar to WASM and JS.


It is being implemented, yes. Linking to their repo was a way for me 
to show their support.

Let's hope we'll have "stages" soon ;)


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


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 at the moment, WebGPU currently does not ship on Android
WebView. Parallel work is occurring to launch WebGPU on Android.



Debuggability

No DevTools changes are required, treated like any other
attribute.


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

No

All platforms will eventually have support. Will immediately
be available on ChromeOS, Mac, and Windows, since those
platforms already support WebGPU. Linux and Android are
planned to have WebGPU support in the future, so this feature
will become available when WebGPU does.


Is this feature fully tested by web-platform-tests

?


Yes

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


Requires code in //chrome?

False


Tracking bug

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



Availability expectation

Feature is available only in Chromium browsers for the near
future, on the order of months. Other browsers intend to ship
WebGPU support, but don't have specified timelines.


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 desktop

120


Anticipated spec changes

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

Re: [blink-dev] Intent to Ship: CSS masking

2023-10-25 Thread Mike Taylor

On 10/25/23 10:00 AM, Philip Rogers wrote:

Contact emails

p...@chromium.org, tcap...@chromium.org, yo...@chromium.org, f...@opera.com

Explainer

None

Specification

https://drafts.fxtf.org/css-masking/#positioned-masks

Design docs

https://developer.mozilla.org/en-US/docs/Web/CSS/mask

Summary

CSS mask, and related properties such as mask-image, mask-mode, etc,
are used to hide an element (partially or fully) by masking or
clipping the image at specific points. This feature unprefixes the
-webkit-mask* properties and brings them up to spec. This includes
mask-image, mask-mode, mask-repeat, mask-position, mask-clip,
mask-origin, mask-size, and mask-composite, as well as the "mask"
shorthand. Local mask-image references are supported, serialization
now matches the spec, and accepted values now match the spec (for
example, "add" instead of "source-over" for mask-composite).

Blink component

Blink>CSS

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

There is some compatibility risk in adding an unprefixed feature while
still supporting the prefixed version. This is minimized as we are
following the same pattern Webkit has already shipped. In addition,
Firefox supports several of the legacy -webkit- prefixed properties too.

Is there anywhere that documents the differences, beyond what is written
in the summary? It would be nice if we can capture that in the Compat
standard, where they are no longer simple aliases.

/Gecko/: Shipped/Shipping Firefox has nearly 100% pass rate on
css-masking WPT tests.

/WebKit/: Shipped/Shipping Safari has shipped much of the unprefixing
of these properties (https://bugs.webkit.org/show_bug.cgi?id=229082),
as well as many implementation improvements, though some interop fixes
are still in development.

/Web developers/: Strongly positive
(https://github.com/web-platform-tests/interop/issues/148) This is
part of interop-2023.

/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

Basic debugging support with existing CSS support in devtools.

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

Yes

Is this feature fully tested by web-platform-tests

Yes

https://wpt.fyi/results/css/css-masking?label=master=experimental=chrome=firefox=safari=interop

Flag name on chrome://flags

None

Finch feature name

CSSMaskingInterop

Requires code in //chrome?

False

Tracking bug

https://crbug.com/1418401

Measurement

https://chromestatus.com/metrics/css/timeline/popularity/772

Estimated milestones

Shipping on desktop 120
DevTrial on desktop 120

Shipping on Android 120
DevTrial on Android 120

Shipping on WebView 120

Anticipated spec changes

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

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5839739127332864

Links to previous Intent discussions

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

This intent message was generated by Chrome Platform Status
.

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

2023-10-24 Thread Mike Taylor

Hi Daniel,

You can read more about the Blink process for shipping features here:

https://www.chromium.org/blink/launching-features/

And yes, we do have plans for phase 0 and phase 1 experiments (and
possibly others, depending on what we learn in the process).

best,
Mike

On 10/24/23 2:00 PM, Daniel Santiago Rincón Silva wrote:
Can you describe in more detail what are the steps that this proposal
would go through in order to be approved? Is there voting from the
community that needs to happen or internal Google decisions? Are the
'experimentation phases' mentioned by Mike above the phase 0 and 1
mentioned in the other doc?

On Tuesday, October 24, 2023 at 9:58:02 AM UTC-7 ayumi hamasaki wrote:

What's the advantages / disadvantages of the IP Protection
(formerly known as Gnatcatcher) compared to something like the Tor
browser?

On Tuesday, 24 October 2023 at 00:28:24 UTC+1 Mike Taylor wrote:

Hi Eric,

Sure - we will have more details about which domains will be
proxied as we get past the experimentation phases and sent an
Intent to Ship.

thanks,
Mike

On 10/23/23 5:21 PM, Eric Browning wrote:

Please publish the domains this feature will use so that
school and district admins may block it because of required
governmental child safety filtering concerns.

On Thursday, October 19, 2023 at 2:52:53 PM UTC-6 Brianna
Goldstein wrote:

Contact emails

Brianna Goldstein, James Bradley, David Schinazi

Explainer

IP Protection formerly known as Gnatcatcher
<https://github.com/GoogleChrome/ip-protection>

Specification

None

Summary

IP Protection
<https://github.com/GoogleChrome/ip-protection>is a
feature that sends third-party traffic for a set of
domains through proxies for the purpose of protecting the
user by masking their IP address from those domains.

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

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

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

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

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

A small percentage of clients will be automatically
enrolled in this initial test, though the architecture
and design will evolve between this test and future
launches. To access the proxy, a user must be logged in
to Chrome. To prevent abuse, a Google-run authentication
server will grant access tokens to the Google run proxy
based on a per-user quota.

In future phases we plan to use a 2-hop proxy, as had
previously been indicated in the IP Protection explainer.

Blink component

Privacy>Fingerprinting>IPProtection

<https://bugs.chromium.org/p/chromium/issues/list?q=component:Privacy%3EFingerprinting%3EIPProtection>

TAG review

None

TAG review status

N/A

Risks

Interoperability and Compatibility

IP Protection changes how stable a client's IP address is
but does not otherwise cause a breaking change for
existing sites. In this experiment the only sites
impacted are Google owned domains which include the

Re: [blink-dev] Re: Intent to Ship: Deprecate and remove Theora support.

2023-10-24 Thread Mike Taylor

LGTM1 to deprecate and remove. RIP Theora, we hardly knew ye.

On 10/24/23 1:01 PM, Dale Curtis wrote:
On Tue, Oct 24, 2023 at 4:49 AM Mike Taylor
wrote:

On 10/23/23 1:13 PM, Dale Curtis wrote:

On Mon, Oct 23, 2023 at 10:02 AM Mike Taylor
wrote:

On 10/23/23 11:54 AM, Dale Curtis wrote:

Hmm, not sure why the description got reflowed, here's the
formatted version:

Chrome will deprecate and remove support for the Theora
video codec in desktop Chrome due to emerging security
risks. Theora's low (and now often incorrect) usage no
longer justifies support for most users.

Notes:
- Zero day attacks against media codecs have spiked.
- Usage has fallen below measurable levels in UKM.
- The sites we manually inspected before levels dropped off
were incorrectly preferring Theora over more modern codecs
like VP9.

Meaning, once Theora support is gone, video playback
continues to work for all sites you inspected because media
source selection found something else playable?

Correct, if Theora support was missing users would have a higher
quality experience due to a more modern codec being selected.

- It's never been supported by Safari or Chrome on Android.
- An ogv.js polyfill exists for the sites that still need
Theora support.
- We are not removing support for ogg containers.

Our plan is to begin escalating experiments turning down
Theora support in M120. During this time users can
reactivate Theora support via
chrome://flags/#theora-video-codec if needed.

The tentative timeline for this is (assuming everything goes
smoothly):
- ~Oct 23, 2023: begin 50/50 canary dev experiments.
- ~Nov 1-6, 2023: begin 50/50 beta experiments.
- ~Dec 6, 2023: begin 1% stable experiments.

Even though UKM appears to be exceedingly low, if you're not
100% confident this will be a no-op, you might consider
beginning the stable experiment after the new year (and many
production freezes).

I did consider this and ran this plan by Finch team ahead of
time, however given the low usage, long dev/beta experiments,
that these sites would already be broken on Android/Safari, and
that we'd still have time to turn down the 1% stable experiment
before Finch freeze, leaving at 1% until after holiday freezes
should be safe.

OK, that sounds reasonable. Can you also request the rest of the
review bits in the chromestatus entry?

Done, thanks I thought that was automatic these days.

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

2023-10-24 Thread Mike Taylor


Understood - thanks!

LGTM1

On 10/24/23 9:16 AM, Rune Lillesveen wrote:
On Tue, Oct 24, 2023 at 1:58 AM Mike Taylor  
wrote:


Hey Rune,

On 10/20/23 9:30 AM, Rune Lillesveen wrote:



Contact emails

futh...@chromium.org, andr...@chromium.org


Explainer

None


Specification

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


Summary

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


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

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


Blink component

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


TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

None



/Gecko/: Positive Implementation behind a flag.

/WebKit/: Shipped/Shipping

/Web developers/: No signals

/Other signals/:


WebView application risks

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

None



Debuggability

No additional devtools support necessary compared to existing
syntaxes.



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

Yes


Is this feature fully tested by web-platform-tests

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

Yes


https://wpt.fyi/css/css-properties-values-api/animation/custom-property-animation-list-type-mismatch.html

https://wpt.fyi/css/css-properties-values-api/animation/custom-property-animation-transform-function.html

https://wpt.fyi/css/css-properties-values-api/animation/custom-property-animation-transform-list-multiple-values.html

https://wpt.fyi/css/css-properties-values-api/animation/custom-property-animation-transform-list-single-values.html

https://wpt.fyi/css/css-properties-values-api/animation/custom-property-transition-transform-function.html

https://wpt.fyi/css/css-properties-values-api/animation/custom-property-transition-transform-list.html
https://wpt.fyi/css/css-properties-values-api/at-property.html

https://wpt.fyi/css/css-properties-values-api/registered-property-computation.html

https://wpt.fyi/css/css-properties-values-api/registered-property-initial.html

https://wpt.fyi/css/css-properties-values-api/register-property-syntax-parsing.html
https://wpt.fyi/css/css-properties-values-api/typedom.html


These 5 tests have a lot of failures, is that expected?

  * 
https://wpt.fyi/results/css/css-properties-values-api/animation/custom-property-animation-transform-function.html?label=master=experimental

<https://wpt.fyi/results/css/css-properties-values-api/animation/custom-property-animation-transform-function.html?label=master=experimental>
  * 
https://wpt.fyi/results/css/css-properties-values-api/animation/custom-property-animation-transform-list-multiple-values.html?label=experimental=master

<https://wpt.fyi/results/css/css-properties-values-api/animation/custom-property-animation-transform-list-multiple-values.html?label=experimental=master>
  * 
https://wpt.fyi/results/css/css-properties-values-api/animation/custom-property-animation-transform-list-single-values.html?label=experimental=master

<https://wpt.fyi/results/css/css-properties-values-api/animation/custom-property-animation-transform-list-single-values.html?label=experimental=master>
  * 
https://wpt.fyi/results/css/css-properties-values-api/animation/custom-property-transit

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

2023-10-24 Thread Mike Taylor


Thanks - LGTM to experiment from 120 to 123 inclusive.

On 10/24/23 3:47 AM, Yifan Luo wrote:

Hello Mike,

Sure and done.

Yifan

On Tuesday, October 24, 2023 at 1:36:32 AM UTC+2 blink-dev wrote:

Hi Yifan,

Could you please request Privacy, Security, and Debuggability
reviews in the chromestatus entry?

thanks,
Mike

On 10/20/23 9:49 AM, 'Yifan Luo' via blink-dev wrote:



Contact emails

l...@chromium.org, cl...@chromium.org


Explainer

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


Specification

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


Design docs


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


Summary

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



Blink component

Blink>SecurityFeature>CORS>PrivateNetworkAccess




TAG review

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


TAG review status

Issues addressed


Risks



Interoperability and Compatibility



/Gecko/: No signal

/WebKit/: No signal

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

/Other signals/:


Ergonomics

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



Activation

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



Security

This is a security positive feature.



WebView application risks

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

None



Goals for experimentation



Ongoing technical constraints

None.



Debuggability

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



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

No

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



Is this feature fully tested by web-platform-tests

?

No


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





Flag name on chrome://flags



Finch feature name

None


Non-finch justification

None


Requires code in //chrome?

True


Tracking bug

https://crbug.com/1338439


Estimated milestones

OriginTrial desktop last123
OriginTrial desktop first   120



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5954091755241472


Links to previous Intent discussions

Intent to prototype:

https://groups.google.com/a/chromium.org/g/blink-dev/c/6MczoSFGiHo/m/IigYuhu7AwAJ

This intent message was generated by Chrome Platform Status
.

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

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

Re: [blink-dev] Re: Intent to Ship: Deprecate and remove Theora support.

2023-10-24 Thread Mike Taylor

On 10/23/23 1:13 PM, Dale Curtis wrote:

On Mon, Oct 23, 2023 at 10:02 AM Mike Taylor
wrote:

On 10/23/23 11:54 AM, Dale Curtis wrote:

Hmm, not sure why the description got reflowed, here's the
formatted version:

Chrome will deprecate and remove support for the Theora video
codec in desktop Chrome due to emerging security risks. Theora's
low (and now often incorrect) usage no longer justifies support
for most users.

Notes:
- Zero day attacks against media codecs have spiked.
- Usage has fallen below measurable levels in UKM.
- The sites we manually inspected before levels dropped off were
incorrectly preferring Theora over more modern codecs like VP9.

Meaning, once Theora support is gone, video playback continues to
work for all sites you inspected because media source selection
found something else playable?

Correct, if Theora support was missing users would have a higher
quality experience due to a more modern codec being selected.

- It's never been supported by Safari or Chrome on Android.
- An ogv.js polyfill exists for the sites that still need Theora
support.
- We are not removing support for ogg containers.

Our plan is to begin escalating experiments turning down Theora
support in M120. During this time users can reactivate Theora
support via chrome://flags/#theora-video-codec if needed.

Even though UKM appears to be exceedingly low, if you're not 100%
confident this will be a no-op, you might consider beginning the
stable experiment after the new year (and many production freezes).

I did consider this and ran this plan by Finch team ahead of time,
however given the low usage, long dev/beta experiments, that these
sites would already be broken on Android/Safari, and that we'd still
have time to turn down the 1% stable experiment before Finch freeze,
leaving at 1% until after holiday freezes should be safe.

OK, that sounds reasonable. Can you also request the rest of the review
bits in the chromestatus entry?

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

2023-10-23 Thread Mike Taylor


Hey Rune,

On 10/20/23 9:30 AM, Rune Lillesveen wrote:



Contact emails

futh...@chromium.org, andr...@chromium.org


Explainer

None


Specification

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


Summary

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



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


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



Blink component

Blink>CSS 




TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

None



/Gecko/: Positive Implementation behind a flag.

/WebKit/: Shipped/Shipping

/Web developers/: No signals

/Other signals/:


WebView application risks

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


None



Debuggability

No additional devtools support necessary compared to existing syntaxes.



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

Yes


Is this feature fully tested by web-platform-tests

?

Yes

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



These 5 tests have a lot of failures, is that expected?

 * 
https://wpt.fyi/results/css/css-properties-values-api/animation/custom-property-animation-transform-function.html?label=master=experimental
 * 
https://wpt.fyi/results/css/css-properties-values-api/animation/custom-property-animation-transform-list-multiple-values.html?label=experimental=master
 * 
https://wpt.fyi/results/css/css-properties-values-api/animation/custom-property-animation-transform-list-single-values.html?label=experimental=master
 * 
https://wpt.fyi/results/css/css-properties-values-api/animation/custom-property-transition-transform-function.html?label=experimental=master
 * 
https://wpt.fyi/results/css/css-properties-values-api/animation/custom-property-transition-transform-list.html?label=experimental=master




Flag name on chrome://flags

#enable-experimental-web-platform-features


Finch feature name

CSSVariables2TransformValues


Requires code in //chrome?

False


Tracking bug

https://crbug.com/911156


Estimated milestones

Shipping on desktop 120
DevTrial on desktop 115

Shipping on Android 120
DevTrial on Android 115

Shipping on WebView 120



Anticipated spec changes

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

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

2023-10-23 Thread Mike Taylor


Hi Yifan,

Could you please request Privacy, Security, and Debuggability reviews in 
the chromestatus entry?


thanks,
Mike

On 10/20/23 9:49 AM, 'Yifan Luo' via blink-dev wrote:



Contact emails

l...@chromium.org, cl...@chromium.org


Explainer

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


Specification

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


Design docs

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


Summary

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




Blink component

Blink>SecurityFeature>CORS>PrivateNetworkAccess 




TAG review

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


TAG review status

Issues addressed


Risks



Interoperability and Compatibility



/Gecko/: No signal

/WebKit/: No signal

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


/Other signals/:


Ergonomics

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




Activation

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




Security

This is a security positive feature.



WebView application risks

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


None



Goals for experimentation



Ongoing technical constraints

None.



Debuggability

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




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

No

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




Is this feature fully tested by web-platform-tests

?

No

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





Flag name on chrome://flags



Finch feature name

None


Non-finch justification

None


Requires code in //chrome?

True


Tracking bug

https://crbug.com/1338439


Estimated milestones

OriginTrial desktop last123
OriginTrial desktop first   120



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5954091755241472


Links to previous Intent discussions

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


This intent message was generated by Chrome Platform Status 
.


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


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

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

2023-10-23 Thread Mike Taylor


Hi Eric,

Sure - we will have more details about which domains will be proxied as 
we get past the experimentation phases and sent an Intent to Ship.


thanks,
Mike

On 10/23/23 5:21 PM, Eric Browning wrote:
Please publish the domains this feature will use so that school and 
district admins may block it because of required governmental child 
safety filtering concerns.


On Thursday, October 19, 2023 at 2:52:53 PM UTC-6 Brianna Goldstein wrote:


Contact emails

Brianna Goldstein, James Bradley, David Schinazi


Explainer

IP Protection formerly known as Gnatcatcher



Specification

None


Summary

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


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

 *

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

 *

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

 *

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


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


A small percentage of clients will be automatically enrolled in
this initial test, though the architecture and design will evolve
between this test and future launches. To access the proxy, a user
must be logged in to Chrome. To prevent abuse, a Google-run
authentication server will grant access tokens to the Google run
proxy based on a per-user quota.


In future phases we plan to use a 2-hop proxy, as had previously
been indicated in the IP Protection explainer.


Blink component

Privacy>Fingerprinting>IPProtection




TAG review

None


TAG review status

N/A


Risks


Interoperability and Compatibility

IP Protection changes how stable a client's IP address is but does
not otherwise cause a breaking change for existing sites. In this
experiment the only sites impacted are Google owned domains which
include the some domains

when
they are loaded in a third party context.

For those requests, a stable IP address for a client can no longer
be expected. There is no impact to other domains at this time.


Gecko: No signal


WebKit: Shipped a similar feature in Intelligent Tracking
Protection. This experiment is only a single proxy, however we
plan in a later phase to move to the double hop proxy model that
Safari has also shipped.


Web developers: No signals


Other signals:


WebView application risks

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

This experiment does not include Webview.



Goals for experimentation

We will enable this experiment in the pre-stable Chrome channels
at most to 33% of clients. For this initial experiment we want to
test our infrastructure and the integrations between various
components for bugs, stability and reliability. We want to measure
the latency of requests using the full flow to get an early
picture of where we can improve performance as we ramp up traffic.


Ongoing technical constraints

None


Debuggability

How to test IP Protection if the feature is enabled on your client

1.

Navigate your configured browser to chrome://net-export.

2.

Click “Start Logging To Disk” and save the log

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

2023-10-23 Thread Mike Taylor

Hi Pete,

Yes, users will be able to turn the feature off. See:

https://github.com/GoogleChrome/ip-protection/issues/16
https://support.google.com/chrome/a/answer/7679408?sjid=15843372962730454051-NA#upChromeBrsrX118

thanks,
Mike

On 10/23/23 3:21 PM, Pete Stergion wrote:
Will we be able to turn this feature off once it rolled out or will it
be REQUIRED? The issue for us here at the Cornell University Library
IT department is that we have resources that we access by whitelisting
domain ip address/vlans to our ERM (Electronic Resource Mangement.) We
do not want to use a SAML solution because these are public computers
that have a requirement to not have user identifiable information
associated with them.

On Thursday, October 19, 2023 at 4:52:53 PM UTC-4 Brianna Goldstein wrote:

Contact emails

Brianna Goldstein, James Bradley, David Schinazi

Explainer

IP Protection formerly known as Gnatcatcher

Specification

None

Summary

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

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

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

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

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

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

A small percentage of clients will be automatically enrolled in
this initial test, though the architecture and design will evolve
between this test and future launches. To access the proxy, a user
must be logged in to Chrome. To prevent abuse, a Google-run
authentication server will grant access tokens to the Google run
proxy based on a per-user quota.

In future phases we plan to use a 2-hop proxy, as had previously
been indicated in the IP Protection explainer.

Blink component

Privacy>Fingerprinting>IPProtection

TAG review

None

TAG review status

N/A

Risks

Interoperability and Compatibility

IP Protection changes how stable a client's IP address is but does
not otherwise cause a breaking change for existing sites. In this
experiment the only sites impacted are Google owned domains which
include the some domains

when
they are loaded in a third party context.

For those requests, a stable IP address for a client can no longer
be expected. There is no impact to other domains at this time.

Gecko: No signal

WebKit: Shipped a similar feature in Intelligent Tracking
Protection. This experiment is only a single proxy, however we
plan in a later phase to move to the double hop proxy model that
Safari has also shipped.

Web developers: No signals

Other signals:

WebView application risks

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

This experiment does not include Webview.

Goals for experimentation

We will enable this experiment in the pre-stable Chrome channels
at most to 33% of clients. For this initial experiment we want to
test our infrastructure and the integrations between various
components for bugs, stability and reliability. We want to measure
the latency of requests using the full flow to get an early
picture of

Re: [blink-dev] Re: Intent to Ship: Deprecate and remove Theora support.

2023-10-23 Thread Mike Taylor


On 10/23/23 11:54 AM, Dale Curtis wrote:

Hmm, not sure why the description got reflowed, here's the formatted 
version:


Chrome will deprecate and remove support for the Theora video codec in 
desktop Chrome due to emerging security risks. Theora's low (and now 
often incorrect) usage no longer justifies support for most users.


Notes:
- Zero day attacks against media codecs have spiked.
- Usage has fallen below measurable levels in UKM.
- The sites we manually inspected before levels dropped off were 
incorrectly preferring Theora over more modern codecs like VP9.
Meaning, once Theora support is gone, video playback continues to work 
for all sites you inspected because media source selection found 
something else playable?

- It's never been supported by Safari or Chrome on Android.
- An ogv.js polyfill exists for the sites that still need Theora support.
- We are not removing support for ogg containers.

Our plan is to begin escalating experiments turning down Theora 
support in M120. During this time users can reactivate Theora support 
via chrome://flags/#theora-video-codec if needed.


The tentative timeline for this is (assuming everything goes smoothly):
- ~Oct 23, 2023: begin 50/50 canary dev experiments.
- ~Nov 1-6, 2023: begin 50/50 beta experiments.
- ~Dec 6, 2023: begin 1% stable experiments.
Even though UKM appears to be exceedingly low, if you're not 100% 
confident this will be a no-op, you might consider beginning the stable 
experiment after the new year (and many production freezes).

- ~Jan 8, 2024: begin 50% stable experiments.
- ~Jan 16th, 2024: launch at 100%.
- ~Feb 2024: remove code and chrome://flag in M123.
- ~Mar 2024: Chrome 123 will roll to stable.

- dale

On Mon, Oct 23, 2023 at 8:52 AM Dale Curtis  
wrote:



Contact emails

dalecur...@chromium.org


Explainer

None


Specification

https://en.wikipedia.org/wiki/Theora


Summary

Chrome will deprecate and remove support for the Theora video
codec in desktop Chrome due to emerging security risks. Theora's
low (and now often incorrect) usage no longer justifies support
for most users. Notes: - Zero day attacks against media codecs
have spiked. - Usage has fallen below measurable levels in UKM. -
The sites we manually inspected before levels dropped off were
incorrectly preferring Theora over more modern codecs like VP9. -
It's never been supported by Safari or Chrome on Android. - An
ogv.js polyfill exists for the sites that still need Theora
support. - We are not removing support for ogg containers. Our
plan is to begin escalating experiments turning down Theora
support in M120. During this time users can reactivate Theora
support via chrome://flags/#theora-video-codec if needed. The
tentative timeline for this is (assuming everything goes
smoothly): - ~Oct 23, 2023: begin 50/50 canary dev experiments. -
~Nov 1-6, 2023: begin 50/50 beta experiments. - ~Dec 6, 2023:
begin 1% stable experiments. - ~Jan 8, 2024: begin 50% stable
experiments. - ~Jan 16th, 2024: launch at 100%. - ~Feb 2024:
remove code and chrome://flag in M123. - ~Mar 2024: Chrome 123
will roll to stable.



Blink component

Internals>Media>Codecs




Search tags

theora , vp3
, video



TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

Sites which only provide a Theora video source will no longer have
video playback. These sites would already be broken in Chrome for
Android or Safari.



/Gecko/: Under consideration Private discussions. I asked if
they'd like an RFP for this, but haven't yet heard back.

/WebKit/: Shipped/Shipping (https://caniuse.com/ogv) Safari never
shipped support for Theora.

/Web developers/: Mixed signals Most developers are not likely to
have an opinion, some may lament the loss of one of the first open
codecs on the web.

/Other signals/:


Security

Security positive change -- removes support for a complicated
binary parsing and decoding mechanism.



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, never supported on Android or WebView.



Debuggability

Can be debugged through media dev tools or chrome://media-internals.



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

Yes

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

2023-10-23 Thread Mike Taylor

LGTM2

On 10/23/23 5:54 AM, Yoav Weiss wrote:

LGTM1

On Mon, Oct 23, 2023 at 10:14 AM Luke  wrote:

> I'm guessing we're missing ways to test if the styles were
applied. Is that correct?
> If so, can you file relevant WPT bugs to make sure we'd be able
to expand coverage in the future?

Yeah I'll take a look into filing those bugs, as I understand it
there's APIs missing to enable the common scrollbar implementation
and you'd then need some form of pixel test or as you say an API
to check that the scrollbar has the relevant colours.

Thanks!

> Also, it seems like Safari is passing many of the tests despite
not having shipped this. The same is true for stable Chrome

.
Might be worthwhile to take a look and make sure the tests are
actually testing the feature..

Lots of the tests are repaint tests so just make sure that when
implemented it handles various cases (lots of them cases that I've
come across while implementing). When the properties aren't
supported lots of the repaint tests will pass as they rely on the
properties in both the actual and expected. I'm not sure on the
best way to avoid this?

Yeah, not sure how that can be resolved without flaky 
platform-specific screenshots. As such, I don't consider this a blocker.

+Chris Harrelson  - Is this an issue y'all 
ran into in the past?

On Monday, 23 October 2023 at 07:18:34 UTC+1 yoav...@chromium.org
wrote:

Thanks for working on this!!

On Sat, Oct 21, 2023 at 4:58 AM Luke  wrote:

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

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

Will scrollbar-color work on overlay scrollbars on
macOS? It does in Firefox.

On Friday, October 20, 2023 at 10:46:36 PM UTC+2 Luke
wrote:

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

*Contact emails *lukewa...@gmail.com

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

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

Summary

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

Blink componentBlink>Layout>Scrollbars

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

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

TAG review statusIssues addressed

Risks

Interoperability and Compatibility

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

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

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

/Web developers/: Positive
(https://insights.developer.mozilla.org)
"Inability to style

Re: [blink-dev] Intent to ship: Interoperable Pointer and Mouse boundary events after DOM changes

2023-10-23 Thread Mike Taylor

Hi Mustaq,

Please take a moment to request the other review bits (API OWNERs will
wait until those are in progress to begin our review). See
https://groups.google.com/a/chromium.org/g/blink-dev/c/bqvB1oap0Yc/m/YlO8DEHgAQAJ
for more info.

thanks!
Mike

On 10/19/23 3:41 PM, Mustaq Ahmed wrote:

Contact emails

mus...@chromium.org, fla...@chromium.org

Specification

https://www.w3.org/TR/uievents/#events-mouseevent-event-order

Summary

After an event target gets removed from the DOM, the logical target of
the pointer as implied by the Pointer and Mouse boundary events (i.e.
over, out, enter and leave events) should be the nearest ancestor
still attached to the DOM. PEWG has recently reached consensus on this
behavior, see
https://github.com/web-platform-tests/interop/issues/380. Chrome has
been keeping track of a node even after it gets removed from DOM. As a
result, if the pointer moves to a new node B after the hit-test node A
is removed from DOM, the boundary event sequence (pointerover,
pointerout, pointerenter, pointerleave events and the corresponding
mouse events) used to imply a pointer movement from A to B. As per the
new consensus, the event sequence should imply a pointer movement from
the "parent of A" to B.

Blink component

Blink>Input

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

There is no interop risk because major browsers are currently all
slightly different from one another. We are strictly improving the
situation through the intent here by having Chrome match an
agreed-upon behavior that's already tested
(https://github.com/web-platform-tests/interop/issues/380). The compat
risk is negligible for the same reason, existing sites could not rely
on the current behavior in all browsers. This is also changing a very
narrow use-case.

/Gecko/: Positive
(https://github.com/web-platform-tests/interop/issues/380) Mozilla
originally called out the interop problem here.

/WebKit/: No signal

/Web developers/: Positive (https://crbug.com/1147998)

/Other signals/:

WebView application risks

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

None

Debuggability

None

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

Yes

Is this feature fully tested by web-platform-tests

Yes

https://wpt.fyi/results/pointerevents?label=master=experimental=pointerevent_after_target_appended.html%20or%20pointerevent_after_target_removed.html%20or%20pointerup_after_pointerdown_target_removed.html

Flag name on chrome://flags

None

Finch feature name

BoundaryEventDispatchTracksNodeRemoval

Requires code in //chrome?

False

Tracking bug

https://crbug.com/1147998

Sample links

https://output.jsbin.com/yumacid

Estimated milestones

Shipping on desktop 121

Shipping on Android 121

Shipping on WebView 121

Anticipated spec changes

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5182447084109824

This intent message was generated by Chrome Platform Status
.

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

2023-10-23 Thread Mike Taylor


On 10/20/23 3:41 AM, 'Thomas Steiner' via blink-dev wrote:

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


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

Is this on purpose?


Yep, for the ~* retro vibes *~.

(But also, this is a test list in the first of a few experiments.)



On Thu, Oct 19, 2023 at 10:52 PM 'Brianna Goldstein' via blink-dev 
 wrote:



Contact emails

Brianna Goldstein , James Bradley
, David Schinazi



Explainer

IP Protection formerly known as Gnatcatcher



Specification

None


Summary

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


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

 *

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

 *

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

 *

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


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


A small percentage of clients will be automatically enrolled in
this initial test, though the architecture and design will evolve
between this test and future launches. To access the proxy, a user
must be logged in to Chrome. To prevent abuse, a Google-run
authentication server will grant access tokens to the Google run
proxy based on a per-user quota.


In future phases we plan to use a 2-hop proxy, as had previously
been indicated in the IP Protection explainer.


Blink component

Privacy>Fingerprinting>IPProtection




TAG review

None


TAG review status

N/A


Risks


Interoperability and Compatibility

IP Protection changes how stable a client's IP address is but does
not otherwise cause a breaking change for existing sites. In this
experiment the only sites impacted are Google owned domains which
include the some domains

when
they are loaded in a third party context.

For those requests, a stable IP address for a client can no longer
be expected. There is no impact to other domains at this time.


Gecko: No signal


WebKit: Shipped a similar feature in Intelligent Tracking
Protection. This experiment is only a single proxy, however we
plan in a later phase to move to the double hop proxy model that
Safari has also shipped.


Web developers: No signals


Other signals:


WebView application risks

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

This experiment does not include Webview.



Goals for experimentation

We will enable this experiment in the pre-stable Chrome channels
at most to 33% of clients. For this initial experiment we want to
test our infrastructure and the integrations between various
components for bugs, stability and reliability. We want to measure
the latency of requests using the full flow to get an early
picture of where we can improve performance as we ramp up traffic.


Ongoing technical constraints

None

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

2023-10-20 Thread Mike Taylor

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


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


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



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


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

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

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

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

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

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

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

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

Why has the TAG not been consulted?

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

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

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


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


Contact emails

Brianna Goldstein
<mailto:brgoldst...@google.com>, James Bradley
<mailto:jhbrad...@google.com>, David Schinazi
<mailto:dschin...@google.com>


Explainer

IP Protection formerly known as Gnatcatcher
<https://github.com/GoogleChrome/ip-protection>


Specification

None


Summary

IP Protection
<https://github.com/GoogleChrome/ip-protection>is
a feature that sends third-party traffic for a
set of domains through proxies for the purpose of
protecting the user by masking their IP address
from those domains.


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

 *

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

 *

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

 *

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

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

2023-10-19 Thread Mike Taylor

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


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


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

Why has the TAG not been consulted?

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


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

https://chromestatus.com/feature/5111460239245312



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


Contact emails

Brianna Goldstein , James
Bradley , David Schinazi



Explainer

IP Protection formerly known as Gnatcatcher



Specification

None


Summary

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


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

 *

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

 *

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

 *

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


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


A small percentage of clients will be automatically enrolled
in this initial test, though the architecture and design will
evolve between this test and future launches. To access the
proxy, a user must be logged in to Chrome. To prevent abuse, a
Google-run authentication server will grant access tokens to
the Google run proxy based on a per-user quota.


In future phases we plan to use a 2-hop proxy, as had
previously been indicated in the IP Protection explainer.


Blink component

Privacy>Fingerprinting>IPProtection




TAG review

None


TAG review status

N/A


Risks


Interoperability and Compatibility

IP Protection changes how stable a client's IP address is but
does not otherwise cause a breaking change for existing sites.
In this experiment the only sites impacted are Google owned
domains which include the some domains

when
they are loaded in a third party context.

For those requests, a stable IP address for a client can no
longer be expected. There is no impact to other domains at
this time.


Gecko: No signal


WebKit: Shipped a similar feature in Intelligent Tracking
Protection. This experiment is only a single proxy, however we
plan in a later phase to move to the double hop proxy model
that Safari has also shipped.


Web developers: No signals


Other signals:


WebView application risks

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

2023-10-19 Thread Mike Taylor

LGTM to experiment from M119 to M121 (inclusive). Extending another 3 
milestones if needed will be fairly mechanical, given our current policy 
<https://www.chromium.org/blink/launching-features/#:~:text=An%20initial%20origin%20trial%20for%20a%20feature%20may%20only%20run%20for%206%20milestones%20of%20Chromium> 
on OT length.

On 10/19/23 6:48 AM, Paul Jensen wrote:
> Please fill out and start the reviews for Privacy, Security and 
Debuggability in your chromestatus entry, thanks.

These are all in review now.  Sorry, I forgot about this new step.

> Can you clarify what the proposed end milestone will be?
I hope the Origin Trial to last M119 through M121, though I strongly 
suspect I'll need to extend this further to provide sufficient time to 
test.

On Wed, Oct 18, 2023 at 12:04 PM Mike Taylor  
wrote:

Hi Paul,

Can you clarify what the proposed end milestone will be?

thanks,
Mike

On 10/13/23 10:46 AM, Chris Harrelson wrote:

Please fill out and start the reviews for Privacy, Security and
Debuggability in your chromestatus entry, thanks.

On Thu, Oct 12, 2023 at 3:40 PM Paul Jensen
 wrote:

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

May be influenced by Origin Trial feedback, so not yet
started.  Protected Audience auctions running on Bidding &
Auction Services provide functionality very similar to
existing on-device auctions so much of the existing spec
<https://wicg.github.io/turtledove/>applies.

Summary

The Protected Audience API (formerly known as FLEDGE) is a
Privacy Sandbox proposal to serve remarketing and custom
audience use cases, designed so third parties cannot track
user browsing behavior across sites. This proposal, the
Protected Audience Bidding & Auction Services proposal,
outlines a way to allow Protected Audience computation to
take place on cloud servers in a Trusted Execution
Environment (TEE), rather than running locally on a user's
device. Moving computation to cloud servers can help optimize
the Protected Audience auction, and free up computational
cycles and network bandwidth for a device.

Blink component

Blink>InterestGroups

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

TAG review

The parent proposal, Protected Audience, is still pending:
https://github.com/w3ctag/design-reviews/issues/723
<https://github.com/w3ctag/design-reviews/issues/723>

TAG review status

Pending

Risks

Interoperability and Compatibility

None. This is an optional new feature of the Protected
Audience API. Ad techs can use this new feature by calling
navigator.getInterestGroupAdAuctionData() and specifying
values for new fields in the auction config. Without invoking
the new function or explicit values for those new fields,
there's no functional behavioral change as a result of this
feature.

Gecko & WebKit: No signal on parent proposal, Protected
Audience.  Asked in the Mozilla forumhere
<https://github.com/mozilla/standards-positions/issues/770>,
and in the Webkit forum here
<https://github.com/WebKit/standards-positions/issues/158>.

Web developers: Extensive interest in this feature from
adtechs, evidenced by the myriad of discussions on Protected
Audience’s issue tracker
<https://github.com/WICG/turtledove/issues>and weekly WICG
calls <https://github.com/WICG/turtledove/issues/88>.

Goals for experimentation

Operating Bidding and Auction services in TEEs represents a
major shift from running Protected Audience auctions inside
the browser.  During this Origin Trial we’d like to gain
confidence that this is possible to do at scale and in a
performant manner.  We want feedback on new API surfaces and

Re: [blink-dev] Re: PSA: Web MIDI Permissions Prompt Change

2023-10-18 Thread Mike Taylor


LGTM3 (if you need it...)

On 10/18/23 2:32 PM, Chris Harrelson wrote:

LGTM2

On Wed, Oct 18, 2023 at 1:31 PM Hongchan Choi  
wrote:


Yes - we are thinking about publishing a short developer-facing
article about Chrome's permission change when the implementation
is ready.

Thanks Alex!


On Wed, Oct 18, 2023 at 1:14 PM Alex Russell
 wrote:

Thanks for the explanation. I was also unsure if this needs an
intent, and my gut feeling is "no", except that it will be
useful for this to get captured in docs and updates for
developers.

In that spirit, LGTM1, and thanks for filing.

On Wed, Oct 18, 2023, 10:45 AM Hongchan Choi
 wrote:

Hello Alex,

What's the rationale for this change?


There have been several reported problems around Web MIDI
API's drive-by access to client MIDI devices. (crbug
, blog post
)
To address this problem, the Audio WG decided to place an
explicit permission on the general MIDI API access. (spec
)
Originally, the explicit permission was only required for
the advanced MIDI usage (e.g. system exclusive message) in
Chrome, but the completion of this work will expand the
scope of the permission even to the regular MIDI API usage.

Is it documented anywhere? I don't see an Explainer
linked.


As Michael pointed out, we are not sure if this work
requires an explainer since a) FireFox already implemented
with a wider permission per the spec and b) this work does
not involve API changes. We can expand the Chrome Status
entry to include more context and rationale if that's helpful.

Best,
Hongchan


On Tue, Oct 17, 2023 at 3:32 PM Michael Wilson
 wrote:

In case you were asking about the permissions prompt
change instead of the schedule change:

This is not an API change and that's why we are
sending out a PSA instead of an intent. The nature of
the permission prompt change is described in the
Chromestatus entry.

Please let me know if you have more questions.

Best,
Michael


On Tue, Oct 17, 2023 at 3:11 PM Michael Wilson
 wrote:

Hi Alex,

We've been having trouble finishing up the
engineering work, hence the delay.  I'm trying to
make some workflow adjustments now.

Best,
Michael

On Tue, Oct 17, 2023 at 2:30 PM Alex Russell
 wrote:

What's the rationale for this change? Is it
documented anywhere? I don't see an Explainer
linked.

On Tue, Oct 17, 2023, 2:11 PM 'Ajay Rahatekar'
via blink-dev  wrote:

This feature is now planned to ship in M121.

On Tuesday, July 18, 2023 at 12:59:23 PM
UTC-7 Ajay Rahatekar wrote:

This feature is planned to ship in M118.

On Thursday, April 13, 2023 at
10:56:40 AM UTC-7 Ajay Rahatekar wrote:

A correction. The permission
prompt will not be released on
Webview at this time. This is
planned for to be revisited later.

On Wednesday, April 5, 2023 at
4:54:20 PM UTC-7 Ajay Rahatekar wrote:


Contact emails

mjwi...@chromium.org,
sinaf...@chromium.org,
hong...@chromium.org


Specification


https://www.w3.org/TR/webmidi/#requestmidiaccess


Summary

This change will require users
to grant permission before
they can use the Web MIDI API.
Currently, users must
explicitly grant permission to

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

2023-10-18 Thread Mike Taylor


Hi Paul,

Can you clarify what the proposed end milestone will be?

thanks,
Mike

On 10/13/23 10:46 AM, Chris Harrelson wrote:
Please fill out and start the reviews for Privacy, Security and 
Debuggability in your chromestatus entry, thanks.


On Thu, Oct 12, 2023 at 3:40 PM Paul Jensen  
wrote:



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

May be influenced by Origin Trial feedback, so not yet started. 
Protected Audience auctions running on Bidding & Auction Services
provide functionality very similar to existing on-device auctions
so much of the existing spec
applies.


Summary

The Protected Audience API (formerly known as FLEDGE) is a Privacy
Sandbox proposal to serve remarketing and custom audience use
cases, designed so third parties cannot track user browsing
behavior across sites. This proposal, the Protected Audience
Bidding & Auction Services proposal, outlines a way to allow
Protected Audience computation to take place on cloud servers in a
Trusted Execution Environment (TEE), rather than running locally
on a user's device. Moving computation to cloud servers can help
optimize the Protected Audience auction, and free up computational
cycles and network bandwidth for a device.


Blink component

Blink>InterestGroups




TAG review

The parent proposal, Protected Audience, is still pending:
https://github.com/w3ctag/design-reviews/issues/723



TAG review status

Pending


Risks


Interoperability and Compatibility

None. This is an optional new feature of the Protected Audience
API. Ad techs can use this new feature by calling
navigator.getInterestGroupAdAuctionData() and specifying values
for new fields in the auction config. Without invoking the new
function or explicit values for those new fields, there's no
functional behavioral change as a result of this feature.


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


Web developers: Extensive interest in this feature from adtechs,
evidenced by the myriad of discussions on Protected Audience’s
issue tracker and
weekly WICG calls .


Goals for experimentation

Operating Bidding and Auction services in TEEs represents a major
shift from running Protected Audience auctions inside the
browser.  During this Origin Trial we’d like to gain confidence
that this is possible to do at scale and in a performant manner. 
We want feedback on new API surfaces and how these servers are
operated.


Debuggability

On-device API surfaces should be debuggable in Chrome DevTools,
and we’ve added extensive mechanisms for debugging Bidding and
Auction services

.


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

It will be supported on all platforms that support Protected
Audience, so all but WebView.


Is this feature fully tested by web-platform-tests

?

No. Moreweb-platform-test

coverage
is expected when the specification is closer to completion.


Flag name on chrome://flags

Overall control is not possible via chrome://flags, though the
consented debugging support

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

2023-10-18 Thread Mike Taylor

Apologies, I missed that there wasn't yet a spec. I'll retract my LGTM
until then.

On 10/17/23 4:16 AM, Yoav Weiss wrote:

On Tue, Oct 17, 2023 at 12:42 AM Mike Taylor
wrote:

LGTM1

On 10/15/23 11:07 AM, 'Sahir Vellani' via blink-dev wrote:

Thanks for the feedback, I wasn't aware they were mandatory. The
steps have been started, just awaiting feedback from Security and
Privacy reviewers. I've received LGTMs for all other areas. After
our response to WebKit's question, they did not have any further
follow-up questions. So I'm assuming all is well.

On Wednesday, October 11, 2023 at 4:59:15 AM UTC-7 Daniel Bratell
wrote:

I see that various mandatory steps in chromestatus
(privacy,security,enterprise,debuggability,testing) seems to
be unstarted. It is possible they were made mandatory after
you create the entry, but it would be good if you could get
them started now at least.

Also, it's unfortunate that TAG and standards positions
requests have not resulted in anything, but that is hardly
your fault. There were some questions in the WebKit request.
Is all that ok now?

/Daniel

On 2023-10-06 20:10, 'Sahir Vellani' via blink-dev wrote:

On Friday, October 6, 2023 at 9:03:35 AM UTC-7
mike...@chromium.org wrote:

On 10/4/23 7:43 PM, 'Sahir Vellani' via blink-dev wrote:

Contact emails
gerc...@microsoft.com, sahir@microsoft.com

Explainer

https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/PointerEventDeviceId/explainer.md

Specification

https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/PointerEventDeviceId/explainer.md

Is there a more formal spec for this?
Any support outside of Microsoft that would enable y'all to move this
to the WICG?

Summary

As devices with advanced pen input capabilities are
becoming increasingly prevalent, it is important that
the web platform continues to evolve to fully support
these advanced features in order to unlock rich
experiences for both end users and developers. One such
advancement is the ability for a device's digitizer to
recognize more than one pen device interacting with it
simultaneously. This feature is an extension to the
PointerEvent interface to include a new attribute,
deviceId, that represents a session-persistent,
document isolated, unique identifier that a developer
can reliably use to identify individual pens
interacting with the page.

Blink component
Blink>Input

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

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

TAG review status
Pending. TAG review has been pending for 2 months.

Risks

Interoperability and Compatibility

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

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

/Web developers/: No signals

/Other signals/:

WebView application risks

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

None

Debuggability

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

Is this feature fully tested by web-platform-tests

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

No. However, there are web tests in Chromium that test
PointerEventInit with this feature.

Flag name on chrome://flags
PointerEventDeviceId

Finch feature name

Non-finch justification
Edge origin trials successfully underway.

Any Origin Trial feedback you can share?

Absolutely, the feature has been working well. Our partners
(Microsoft Whiteboard) have enabled the feature that is
dependent on this API for their general audience! We did not
receive any constructive feedback. This API is being used by
them on Microsoft Surface Hub devices, which support
multi-pen inking.

Requires code in //chrome?
False

Measurement
PointerEventDeviceId use counter implemented.

Availability expectation
Init

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

2023-10-16 Thread Mike Taylor

LGTM1

On 10/15/23 11:07 AM, 'Sahir Vellani' via blink-dev wrote:
Thanks for the feedback, I wasn't aware they were mandatory. The steps
have been started, just awaiting feedback from Security and Privacy
reviewers. I've received LGTMs for all other areas. After our response
to WebKit's question, they did not have any further follow-up
questions. So I'm assuming all is well.

On Wednesday, October 11, 2023 at 4:59:15 AM UTC-7 Daniel Bratell wrote:

I see that various mandatory steps in chromestatus
(privacy,security,enterprise,debuggability,testing) seems to be
unstarted. It is possible they were made mandatory after you
create the entry, but it would be good if you could get them
started now at least.

Also, it's unfortunate that TAG and standards positions requests
have not resulted in anything, but that is hardly your fault.
There were some questions in the WebKit request. Is all that ok now?

/Daniel

On 2023-10-06 20:10, 'Sahir Vellani' via blink-dev wrote:

On Friday, October 6, 2023 at 9:03:35 AM UTC-7
mike...@chromium.org wrote:

On 10/4/23 7:43 PM, 'Sahir Vellani' via blink-dev wrote:

Contact emails
gerc...@microsoft.com, sahir@microsoft.com

Explainer

https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/PointerEventDeviceId/explainer.md

Specification

https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/PointerEventDeviceId/explainer.md

Summary

As devices with advanced pen input capabilities are becoming
increasingly prevalent, it is important that the web
platform continues to evolve to fully support these advanced
features in order to unlock rich experiences for both end
users and developers. One such advancement is the ability
for a device's digitizer to recognize more than one pen
device interacting with it simultaneously. This feature is
an extension to the PointerEvent interface to include a new
attribute, deviceId, that represents a session-persistent,
document isolated, unique identifier that a developer can
reliably use to identify individual pens interacting with
the page.

Blink component
Blink>Input

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

TAG review status
Pending. TAG review has been pending for 2 months.

Risks

Interoperability and Compatibility

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

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

/Web developers/: No signals

/Other signals/:

WebView application risks

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

None

Debuggability

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

Is this feature fully tested by web-platform-tests

No. However, there are web tests in Chromium that test
PointerEventInit with this feature.

Flag name on chrome://flags
PointerEventDeviceId

Finch feature name

Non-finch justification
Edge origin trials successfully underway.

Any Origin Trial feedback you can share?

Absolutely, the feature has been working well. Our partners
(Microsoft Whiteboard) have enabled the feature that is dependent
on this API for their general audience! We did not receive any
constructive feedback. This API is being used by them on
Microsoft Surface Hub devices, which support multi-pen inking.

Requires code in //chrome?
False

Measurement
PointerEventDeviceId use counter implemented.

Availability expectation
Initially available on Chromium browsers on Windows.

Out of curiosity, are there limitations on other platforms
that prevent supporting this feature?

We haven't been able to get our hands on hardware that supports
other platforms in addition to multi pen inking in order to
implement and appropriately test this feature. We welcome any
sponsors for implementing and testing this, especially on
Linux/Android.

Adoption expectation
Feature is used by specific partner(s) to provide
functionality immediately upon launch.

Adoption plan
This feature has been through origin trials on Edge. It is
being used by partners that provide

Re: [blink-dev] Intent to Ship: Attribution Reporting API feature (aggregation coordinator selection)

2023-10-16 Thread Mike Taylor


LGTM1

On 10/16/23 7:48 AM, Nan Lin wrote:

Thanks Mike, please see the inline comment.

On Mon, Oct 16, 2023 at 10:41 AM Mike Taylor  
wrote:




Interoperability and Compatibility

The change is backwards compatible, and allows developers to
select the deployment option for the aggregation service. By
default, the AWS coordinator will be used (the existing
behavior), and the public keys will be served on both old and new
endpoints during the transition period.


Can you say more about this transition period? Is this related to
"transitional debugging reports", or something else entirely?


This is about the transition period for releasing multiple cloud 
providers support. M119+ is going to fetch public keys from the new 
endpoint, whereas older versions still fetch from the old endpoint.
Therefore to ensure not breaking older versions, the public keys will 
be served on both endpoints for some time after M119 release.
OK - got it. At some future point you'll send an Intent to Deprecate & 
Remove sending public keys from the old endpoint. :)


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

Re: [blink-dev] Intent to Ship: Attribution Reporting API feature (aggregation coordinator selection)

2023-10-16 Thread Mike Taylor


On 10/16/23 7:57 AM, Nan Lin wrote:


A few more inline comments, thanks!

On Mon, Oct 16, 2023 at 10:41 AM Mike Taylor  
wrote:


Hi Nan, a few questions inline:

On 10/6/23 8:45 AM, Nan Lin wrote:



Contact emails

lin...@chromium.org <mailto:lin...@chromium.org>,
johni...@chromium.org


Explainer

Attribution Reporting with event-level reports
<https://github.com/WICG/attribution-reporting-api/blob/main/EVENT.md>

Attribution Reporting API with Aggregatable Reports
<https://github.com/WICG/attribution-reporting-api/blob/main/AGGREGATE.md>

Aggregation Service for the Attribution Reporting API

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


Specification

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


Blink component

Internals > AttributionReporting

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


Summary

We plan on landing one change to the Attribution Reporting API
focused on:

 *

Multiple cloud providers support for aggregate reporting,
supporting AWS and GCP

 o

**Note**: This change will also affect Private
Aggregation API

<https://github.com/patcg-individual-drafts/private-aggregation-api>’s
aggregatable reports by adding a new top-level field
aggregation_coordinator_origin.


Does this proposed change correspond to the TODO at the bottom of

https://github.com/WICG/attribution-reporting-api/blob/main/AGGREGATE.md#data-processing-through-a-secure-aggregation-service?
I think no, but I'm not entirely sure.

The TODO is actually related to the proposed change. We have a pending 
PR <https://github.com/WICG/attribution-reporting-api/pull/1068> to 
expose the allowlist of the aggregation coordinator origins that will 
be used to verify the aggregation coordinator origin specified in the 
API surface. Any origins not included in the allowlist will be rejected.
Thanks for the pointer to the updated explainer (PR...). I see that the 
PR is approved - landing it ASAP may make reviews easier for others.


In the Private Aggregation API,

https://patcg-individual-drafts.github.io/private-aggregation-api/#serializing-reports
seems to define this aggregation_coordinator_origin but there's an
open inline spec issue just after (pointing to a closed issue 78).
Is that entirely resolved, or are there still open questions that
may change the API?

This is not resolved yet and the proposed spec change is here 
<https://github.com/patcg-individual-drafts/private-aggregation-api/pull/106>. 
The aggregation coordinator selection is not supported in Private 
Aggregation API yet, which is being spec'ed and implemented,
but the aggregatable reports created by the API will include the 
aggregation_coordinator_origin field with the default value.

I see - thanks.




Explainer changes

 *

Add aggregation coordinator identifier to support multiple
cloud providers
<https://github.com/WICG/attribution-reporting-api/pull/622>

 *

Use aggregation coordinator origin instead of identifier
<https://github.com/WICG/attribution-reporting-api/pull/829>


Spec changes

 *

Add aggregation coordinator identifier to aggregatable report
<https://github.com/WICG/attribution-reporting-api/pull/728>

 *

Use aggregation coordinator origin instead of identifier
<https://github.com/WICG/attribution-reporting-api/pull/829>

 *

Add aggregation_coordinator_origin to PAA serialized report

<https://github.com/patcg-individual-drafts/private-aggregation-api/pull/105>


Risks


Interoperability and Compatibility

The change is backwards compatible, and allows developers to
select the deployment option for the aggregation service. By
default, the AWS coordinator will be used (the existing
behavior), and the public keys will be served on both old and new
endpoints during the transition period.


Can you say more about this transition period? Is this related to
"transitional debugging reports", or something else entirely?



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

All except Android WebView


Is this feature fully tested by web-platform-tests

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

Yes


Estimated milestones

Chrome 119


Link t

Re: [blink-dev] Intent to Re-implement and Ship: CSS Font Loading API - FontFaceSet: check() method

2023-10-16 Thread Mike Taylor


LGTM2

On 10/16/23 1:35 PM, Alex Russell wrote:

LGTM1

On Sun, Oct 15, 2023 at 1:01 PM ChangSeok Oh  wrote:

Contact emails
changseok...@bytedance.com,shivami...@gmail.com

Specification
https://drafts.csswg.org/css-font-loading/#font-face-set-check

Summary

The FontFaceSet's check() function verifies whether it's possible
to display text using the specified fonts without attempting to
utilize fonts in the FontFaceSet that have not completed loading.
This allows users to safely employ the font without later
triggering a font replacement (i.e., font swap).


*Motivation
*While having a review [1] to fix issue 1416842 [2], I heard that
an "Intent to ship" email is required since the fix changes
Blink's behavior. The font loading API was updated, so we need to
update our implementation in conformance with the spec.

[1] https://chromium-review.googlesource.com/c/chromium/src/+/4913179
[2] https://crbug.com/1416842

Blink component
Blink>Fonts


Search tags
CSS ,Font
,Loading
,FontFaceSet
,check


TAG review
None

TAG review status
Not applicable

Risks

Interoperability and Compatibility

The current behavior of Blink does neither follow the updated spec
nor match other engines' behavior. This proposal aims at fixing
it. https://github.com/w3c/csswg-drafts/issues/5744


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

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

/Web developers/: No signals

/Other signals/:

WebView application risks

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

None


Debuggability

None


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

Is this feature fully tested byweb-platform-tests

?Yes


The following WPT tests cover this feature. *
css/css-fonts/fallback-remote-to-data-url.html *
css/css-fonts/fallback-url-to-local.html


Flag name on chrome://flags
None

Finch feature name
None

Non-finch justification
None

Requires code in //chrome?
False

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

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

Anticipated spec changes

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

None

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

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

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

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f1705c1e-cf65-4c2e-bfe2-3ee3b4fb12d1n%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/CAA44PQj9Q67soyyTMG_eP_2PUPyRNEHh63HXbcbA5TT0mGEe3g%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

Re: [blink-dev] Intent to Ship: Attribution Reporting API feature (aggregation coordinator selection)

2023-10-16 Thread Mike Taylor


Hi Nan, a few questions inline:

On 10/6/23 8:45 AM, Nan Lin wrote:



Contact emails

lin...@chromium.org , johni...@chromium.org


Explainer

Attribution Reporting with event-level reports 



Attribution Reporting API with Aggregatable Reports 



Aggregation Service for the Attribution Reporting API 




Specification

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




Blink component

Internals > AttributionReporting 




Summary

We plan on landing one change to the Attribution Reporting API focused on:

 *

Multiple cloud providers support for aggregate reporting,
supporting AWS and GCP

 o

**Note**: This change will also affect Private Aggregation API
’s
aggregatable reports by adding a new top-level field
aggregation_coordinator_origin.

Does this proposed change correspond to the TODO at the bottom of 
https://github.com/WICG/attribution-reporting-api/blob/main/AGGREGATE.md#data-processing-through-a-secure-aggregation-service? 
I think no, but I'm not entirely sure.


In the Private Aggregation API, 
https://patcg-individual-drafts.github.io/private-aggregation-api/#serializing-reports 
seems to define this aggregation_coordinator_origin but there's an open 
inline spec issue just after (pointing to a closed issue 78). Is that 
entirely resolved, or are there still open questions that may change the 
API?




Explainer changes

 *

Add aggregation coordinator identifier to support multiple cloud
providers 

 *

Use aggregation coordinator origin instead of identifier



Spec changes

 *

Add aggregation coordinator identifier to aggregatable report


 *

Use aggregation coordinator origin instead of identifier


 *

Add aggregation_coordinator_origin to PAA serialized report




Risks


Interoperability and Compatibility

The change is backwards compatible, and allows developers to select 
the deployment option for the aggregation service. By default, the AWS 
coordinator will be used (the existing behavior), and the public keys 
will be served on both old and new endpoints during the transition period.


Can you say more about this transition period? Is this related to 
"transitional debugging reports", or something else entirely?



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

All except Android WebView


Is this feature fully tested by web-platform-tests

?

Yes


Estimated milestones

Chrome 119


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5197591256236032 




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 




--
You received this message because you are subscribed to the Google 
Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BVrgPkpNoOJk60RjTsK2u%2BbCMbM2VkDwjPzqFUEaP7oZ2egoQ%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

Re: [blink-dev] Intent to Prototype and Ship: URL.canParse

2023-10-16 Thread Mike Taylor

LGTM1

On 10/13/23 6:08 PM, Jeremy Roman wrote:

Contact emails

jbro...@chromium.org

Explainer

None

Specification

https://url.spec.whatwg.org/#dom-url-canparse

Summary

A static operation to determine whether a URL string is valid. More
concise than catching an exception thrown from the URL constructor.

Blink component

Blink>DOM

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

This improves interoperability -- this feature is already supported in
stable releases of Firefox and Safari. It is not expected to have any
compatibility risk.

/Gecko/: Shipped/Shipping

/WebKit/: Shipped/Shipping

/Web developers/: Positive (https://github.com/whatwg/url/issues/713)

/Other signals/:

Ergonomics

Improves ergonomics of checking URL validity.

Activation

None anticipated.

Security

None -- this is an ergonomic change.

WebView application risks

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

None

Debuggability

None.

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

Yes

Is this feature fully tested by web-platform-tests

Yes

Covered under url/ directory, and functionality is close to trivial.

Flag name on chrome://flags

None

Finch feature name

None

Non-finch justification

None

Requires code in //chrome?

False

Estimated milestones

Shipping on desktop 120

Shipping on Android 120

Shipping on WebView 120

Anticipated spec changes

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5123302532317184

This intent message was generated by Chrome Platform Status
.

Re: [blink-dev] Intent to Deprecate and Remove: Same-origin blanket enforcement in CSPEE

2023-10-13 Thread Mike Taylor


LGTM2

On 10/13/23 1:32 PM, 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/514b9c06079c71ba%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/95fd3da6-9a69-4ee8-9c1e-412a972b6a1d%40chromium.org.

Re: [blink-dev] Intent to Experiment: Web app scope extensions

2023-10-12 Thread Mike Taylor

Jason, could you please work with Lu to figure out why he can't post 
comments in the chromestatus entry (but can request a review)?


thanks.

On 10/11/23 5:25 PM, 'Lu Huang' via blink-dev wrote:
For the 3 review categories in chromestatus (security, privacy, and 
debuggability), I have clicked on request review but have not found a 
way to post comments from the UI.


For security and privacy, we have a self-review at: 
manifest-incubations/scope_extensions-security-privacy-questionnaire.md 
at gh-pages · WICG/manifest-incubations (github.com) 
<https://github.com/WICG/manifest-incubations/blob/gh-pages/scope_extensions-security-privacy-questionnaire.md>
For debuggability, here are the survey responses until I find out how 
to add to the comments at chromestatus:


(1) Does the introduction of the new Web Platform feature break Chrome 
DevTools' existing developer experience? No. (2) Does Chrome DevTools' 
existing set of tooling features interact with the new Web Platform 
feature in an expected way?
Yes. (3) Would the new Web Platform feature's acceptance and/or 
adoption benefit from adding a new developer workflow to Chrome 
DevTools? Yes. If adopted, this new feature would benefit from new UI 
and tooling in the Application Page of Chrome DevTools. DevTools 
support can help developers determine if they have set up the web app 
association configuration correctly and if their specified 
scope_extensions are valid.


On Wednesday, October 11, 2023 at 2:12:09 PM UTC-7 Lu Huang wrote:

We would like to start running this experiment from 120 through
123 inclusive, but may have to delay start to 121 running through
124.



On Wednesday, October 11, 2023 at 7:54:51 AM UTC-7 Chris Harrelson
wrote:

Please also fill out the 3 other review categories (security,
privacy, debuggability) in chromestatus.


On Wed, Oct 11, 2023 at 7:13 AM Mike Taylor
 wrote:

Hi there,

Could you clarify which milestones you would like to run
the experiment on?

thanks,
Mike

On 10/11/23 6:05 AM, 'Lu Huang' via blink-dev wrote:

Contact emails
lu...@microsoft.com, luig...@microsoft.com,
alanc...@chromium.org

Explainer

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

Specification
None

Design docs

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

Summary

Adds a "scope_extensions" app manifest member that
enables web apps to extend their scope to other origins.
Example usage: { "name": "Example", "display":
"standalone", "start_url": "/index.html",
"scope_extensions": [ {"origin": "https://*.example.com
<http://example.com>"}, {"origin":
"https://example.co.uk; <https://example.co.uk>},
{"origin": "https://*.example.co.uk
<http://example.co.uk>"} ] } This allows sites that
control multiple subdomains and top level domains to be
presented as a single web app. Requires listed origins to
confirm association with the web app using a
.well-known/web-app-origin-association configuration
file. { "web_apps" : [ {"web_app_identity":
"https://sample-app.com/; <https://sample-app.com/>} ] }



Blink component
UI>Browser>WebAppInstalls

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

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

TAG review status
Pending

Risks

Interoperability and Compatibility
/Gecko/: No signal
(https://github.com/mozilla/standards-positions/issues/904)

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

/Web developers/: No signals

/Other signals/:

Ergonomics

None.



Activation

None.



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 experimentationAllow app partners to experiment
more broadly with the scope_extensions feature and
provide feedback. We want to evaluate the shape of the
scope_extensions API for ease of use and expose any
corner c

Re: [blink-dev] Intent to Ship: Shared Storage API Enhancements

2023-10-11 Thread Mike Taylor

LGTM3

On 10/11/23 10:45 AM, Chris Harrelson wrote:

LGTM2

On Wed, Oct 11, 2023 at 7:32 AM Yoav Weiss wrote:

LGTM1

On Friday, October 6, 2023 at 4:41:48 PM UTC+2 Mike Taylor wrote:

Thanks Jason!

And yes, Cammie (and team), please request approval bits in
Chromestatus - API OWNERs will wait on that (not approvals,
just beginning the process for each) before approving.

thanks,
Mike

On 10/4/23 9:08 PM, 'Jason Robbins' via blink-dev wrote:

At this morning's API Owners meeting, they asked me to add
all review gate types to all of the "web developer facing
code change" features that are currently under review,
including this one. So, I have added Privacy, Security,
Enterprise, Debuggability, and Testing gates to your feature
entry.

Please click the gate chips in the "Prepare to ship" stage on
your feature detail page. For each one, answer survey
questions and request that cross-functional review. You can
request them all in parallel. In cases where you already
have the go/launch <https://goto.google.com/launch> bit
approved, you can note that in a comment on that gate for a
potentially faster review.

Thanks,
jason!

On Wednesday, October 4, 2023 at 9:01:02 AM UTC-7 Chris
Harrelson wrote:

This looks good, but please file for all of the 5 other
chips necessary for shipping a feature.

On Wed, Sep 27, 2023 at 11:13 AM Cammie Smith Barnes
wrote:

Contact emails

cam...@chromium.org

jka...@chromium.org

ale...@chromium.org

yao...@chromium.org

Explainer

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

Specification

https://wicg.github.io/shared-storage/
<https://wicg.github.io/shared-storage/>

Summary

We plan to ship the following changes to the Shared
Storage API:

Only allow Private Aggregation reports for up to
5 seconds after a worklet operation starts

This is a privacy measure to prevent timing
attacks.

Reports sent after this point are silently
dropped

Allow writing to and deleting from Shared Storage
via HTTP response header

This is a performance improvement and is
backwards compatible

Per-site privacy budgeting

This change enforces budgets to per-site
rather than per-origin

Blink component

Blink>Storage>SharedStorage

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

Risks

Interoperability and Compatibility

Change [1] will drop the private aggregation
contributions issued after 5 seconds after a worklet
operation starts. 5 seconds should be sufficient for
all known use cases, so this change should have
negligible backward compatibility issues.

Change [2] is optional and fully backwards compatible.

Change [3] could decrease budget for those that are
using multiple origins today that are considered part
of the same eTLD+1. Since the API is new (shipped in
M115), the expectation is for the impact to be low.
It will not break script since the APIs gracefully
handle situations where the budget is exceeded, but
could impact the overall quality of the returned data
for that site.

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

Shared Storage database contents for an origin can be
viewed and modified within devtools. Support for
d

Re: [blink-dev] Intent to Experiment: Web app scope extensions

2023-10-11 Thread Mike Taylor

Hi there,

Could you clarify which milestones you would like to run the experiment on?

thanks,
Mike

On 10/11/23 6:05 AM, 'Lu Huang' via blink-dev wrote:

Contact emails
lu...@microsoft.com, luigo...@microsoft.com, alancut...@chromium.org

Explainer
https://github.com/WICG/manifest-incubations/blob/gh-pages/scope_extensions-explainer.md

Specification
None

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

Summary

Adds a "scope_extensions" app manifest member that enables web apps to
extend their scope to other origins. Example usage: { "name":
"Example", "display": "standalone", "start_url": "/index.html",
"scope_extensions": [ {"origin": "https://*.example.com"}, {"origin":
"https://example.co.uk"}, {"origin": "https://*.example.co.uk"} ] }
This allows sites that control multiple subdomains and top level
domains to be presented as a single web app. Requires listed origins
to confirm association with the web app using a
.well-known/web-app-origin-association configuration file. {
"web_apps" : [ {"web_app_identity": "https://sample-app.com/"} ] }

Blink component
UI>Browser>WebAppInstalls

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

TAG review status
Pending

Risks

Interoperability and Compatibility
/Gecko/: No signal
(https://github.com/mozilla/standards-positions/issues/904)

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

/Web developers/: No signals

/Other signals/:

Ergonomics

None.

Activation

None.

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 experimentationAllow app partners to experiment more broadly
with the scope_extensions feature and provide feedback. We want to
evaluate the shape of the scope_extensions API for ease of use and
expose any corner cases. Specifically, we want to understand if
origin-level granularity is sufficient without path filters. We will
evaluate this based on feedback from OT participants.

Ongoing technical constraints

None.

Debuggability

DevTools Application pane will be the appropriate surface to add
debugging support. Specifically, a section can be added to help
troubleshoot the status of origin association validation.
Additionally, edge://web-app-internals/ also have relevant information
for debugging.

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

Supported on Windows, MacOS, Linux, ChromeOS. Not supported on mobile
platforms where app identity is implemented differently.

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

Flag name on chrome://flags
about://flags/#enable-desktop-pwas-scope-extensions

Finch feature name
None

Non-finch justification
None

Requires code in //chrome?
False

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

Estimated milestones
Dev Trial - 115
Origin Trial 120 or 121

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

Links to previous Intent discussions
Intent to prototype:
https://groups.google.com/a/chromium.org/g/blink-dev/c/-iySPmw8o34/m/oLgrCUQXAQAJ
Ready for Trial:
https://groups.google.com/a/chromium.org/g/blink-dev/c/OBZBZwS6qr0/m/VRySwd40AQAJ

This intent message was generated by Chrome Platform Status
.

Re: [blink-dev] Intent to Ship: MediaStreamTrack Stats

2023-10-11 Thread Mike Taylor

Also, could you please create a chromestatus entry and request the
various review gate bits?

On 10/11/23 10:08 AM, Mike Taylor wrote:

LGTM2

On 10/11/23 8:49 AM, Philip Jägenstedt wrote:
LGTM1, this is a minor addition to an existing API, was discussed in
the WG at TPAC, and has a positive standards position from Mozilla.

On Mon, Oct 9, 2023 at 4:16 PM Henrik Boström wrote:

*Contant emails:*
h...@chromium.org, h...@chromium.org

*Explainer:*
This is a small addition to the MediaStreamTrack

<https://rawgit.com/w3c/mediacapture-main/master/getusermedia.html#dom-mediastreamtrack>.
The new `track.stats` attribute getter allows a JS app to obtain
statistics of a track, which in the case of video refers to frame
counters. For example, if you use getUserMedia() to open a camera
at a specific frame rate setting, this API lets you know how many
frames the camera is actually producing (e.g. frame rate may be
lower in low light conditions or higher than the app wants due to
HW capabilities) and how many frames, if any, are discarded or
dropped by the user agent, which is useful for investigations and
experiments (some concrete examples mentioned here
<https://github.com/mozilla/standards-positions/issues/895>).

*Spec:*
https://w3c.github.io/mediacapture-extensions/#mediastreamtrack-statistics*
*
This is an extension spec, owned by the same working group who
owns the main spec.

The spec and implementation currently only covers video frames,
but similar audio frame counters are being considered for the
future as well.

*Summary:*
Add frame counters to MediaStreamTrack.

*Is this feature supported on all six Blink platforms?*
Yes.

*Measurements*
Will add [Measure].
*
*
*Risks*
Compatibility: MediaStreamTrack is supported on all browsers and
the new stats API is a read-only statistics API rather than core
functionality, so interop risks should be relatively limited.

Signals from other implementers:
- Firefox: positive (request for position
<https://github.com/mozilla/standards-positions/issues/895>)
- Safari: no signal at the time of writing (request for position
<https://github.com/WebKit/standards-positions/issues/260>)

Ergonomics: Used together with MediaStreamTrack and WebRTC
(RTCPeerConnection)

Activation: N/A
*
*
*Web Platform Tests*

https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/mediacapture-extensions/MediaStreamTrack-video-stats.https.html

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

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

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/029c4aea-9a60-4e9e-bc9c-773cac617454n%40chromium.org

<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/029c4aea-9a60-4e9e-bc9c-773cac617454n%40chromium.org?utm_medium=email_source=footer>.

--
You received this message because you are subscribed to the Google
Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYcfV8inYFU5ChgPrTVRUX7%3D%2BFTTjL4D%3DLaYYYdQX1Wsbw%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYcfV8inYFU5ChgPrTVRUX7%3D%2BFTTjL4D%3DLaYYYdQX1Wsbw%40mail.gmail.com?utm_medium=email_source=footer>.

Re: [blink-dev] Intent to Ship: MediaStreamTrack Stats

2023-10-11 Thread Mike Taylor

LGTM2

On 10/11/23 8:49 AM, Philip Jägenstedt wrote:
LGTM1, this is a minor addition to an existing API, was discussed in
the WG at TPAC, and has a positive standards position from Mozilla.

On Mon, Oct 9, 2023 at 4:16 PM Henrik Boström wrote:

*Contant emails:*
h...@chromium.org, h...@chromium.org

*Explainer:*
This is a small addition to the MediaStreamTrack

.
The new `track.stats` attribute getter allows a JS app to obtain
statistics of a track, which in the case of video refers to frame
counters. For example, if you use getUserMedia() to open a camera
at a specific frame rate setting, this API lets you know how many
frames the camera is actually producing (e.g. frame rate may be
lower in low light conditions or higher than the app wants due to
HW capabilities) and how many frames, if any, are discarded or
dropped by the user agent, which is useful for investigations and
experiments (some concrete examples mentioned here
).

*Spec:*
https://w3c.github.io/mediacapture-extensions/#mediastreamtrack-statistics*
*
This is an extension spec, owned by the same working group who
owns the main spec.

The spec and implementation currently only covers video frames,
but similar audio frame counters are being considered for the
future as well.

*Summary:*
Add frame counters to MediaStreamTrack.

*Is this feature supported on all six Blink platforms?*
Yes.

Signals from other implementers:
- Firefox: positive (request for position
)
- Safari: no signal at the time of writing (request for position
)

Ergonomics: Used together with MediaStreamTrack and WebRTC
(RTCPeerConnection)

Activation: N/A
*
*
*Web Platform Tests*

https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/mediacapture-extensions/MediaStreamTrack-video-stats.https.html

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

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

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/029c4aea-9a60-4e9e-bc9c-773cac617454n%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/CAARdPYcfV8inYFU5ChgPrTVRUX7%3D%2BFTTjL4D%3DLaYYYdQX1Wsbw%40mail.gmail.com
.

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

2023-10-11 Thread Mike Taylor

LGTM2

On 10/11/23 7:06 AM, Daniel Bratell wrote:

LGTM1

(Privacy and Security steps in Chromestatus are not completed but they
are unlikely to affect anything)

/Daniel

On 2023-10-04 12:23, Rune Lillesveen wrote:

On Wed, Oct 4, 2023 at 11:08 AM Rune Lillesveen
wrote:

Contact emails

futh...@chromium.org, andr...@chromium.org

Explainer

None

Specification

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

Summary

Supports using the syntax for custom properties
registered with @property or registerProperty(). The
syntax can be used to restrict values of the custom property to
url() values and generated images like gradients.

This syntax was initially excluded from the valid syntaxes mainly
because images were not interpolable and that it would add to the
usefulness of the syntax to be able to interpolate directly on
the custom property. The other engines have shipped the image
syntax without supporting interpolation. There are two
interpolation methods in css-image-4, cross-fade() and per stop
interpolation for gradients. The gradient interpolation is not
shipped by any browser (even for standard properties). Safari
ships a non-standard compliant cross-fade() interpolation for
standard properties (at least for background-image), but not for
the registered custom properties.

We have an OKR to look into cross-fade() for Q4. If we end up
shipping that, it will work for both registered custom properties
and standard properties.

The syntax for registered custom properties is part of
Interop 2023.

Blink component

Blink>CSS

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

None

/Gecko/: Shipped/Shipping Does not support interpolation

Sorry, this is not correct. It's implemented behind a flag, not
shipping yet.

/WebKit/: Shipped/Shipping Does not support interpolation

/Web developers/: No signals

/Other signals/:

WebView application risks

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

None

Debuggability

No additional devtools support necessary compared to existing
syntaxes.

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

Yes

Is this feature fully tested by web-platform-tests

Yes

https://wpt.fyi/css/css-properties-values-api/at-property.html

https://wpt.fyi/css/css-properties-values-api/register-property-syntax-parsing.html
https://wpt.fyi/css/css-properties-values-api/typedom.html

Flag name on chrome://flags

#enable-experimental-web-platform-features

Finch feature name

CSSVariables2ImageValues

Requires code in //chrome?

False

Estimated milestones

Shipping on desktop 120
DevTrial on desktop 115

Shipping on Android 120
DevTrial on Android 115

Anticipated spec changes

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

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5142205606133760

This intent message was generated by Chrome Platform Status
.

--
Rune Lillesveen

Re: [blink-dev] Intent to Ship: HTMLSelectElement showPicker()

2023-10-11 Thread Mike Taylor


LGTM2, same condition.

On 10/11/23 7:16 AM, Daniel Bratell wrote:


LGTM1 (dependent on the PR landing)

Looks like the spec text is more or less complete with no remaining 
possible showstoppers. I do find it both amusing and a bit Kafkaesque 
that the web community seems to have a process where the spec waits 
for implementers and implementers (at least us) wait for the spec. In 
this case it was a small and positive change so it was no issue but it 
could be for larger changes.


(Security review not completed in chromestatus but since this is a 
clone of the other showPicker(), I find it unlikely that it uncovers 
some problem)


/Daniel

On 2023-10-04 17:34, Mason Freed wrote:

On Tuesday, October 3, 2023 at 9:47:02 AM UTC-7 Luke wrote:

That makes perfect sense. For now I've removed the target
milestones all together (they were rather arbitrary). But
targeting 120 or 121 seems like a good idea. As for merging the
spec change I think it should be ready to go assuming my response
on the PR satisfies the question you had?


Thanks! I think it'd be good to explicitly target a milestone - 
perhaps 121? And yes, thanks for your reply on the spec. It sounds 
like there is only a focus question remaining.


Thanks,
Mason

Thanks,
Luke

On Tuesday, 3 October 2023 at 17:34:15 UTC+1 mas...@chromium.org
wrote:

I'm generally supportive of adding showPicker to select
elements - it's a handy API for developers and it avoids some
JS hacks. I do think we should a) land the spec changes
, and b) allow some
developer test time, before we ship this API. There were some
bugs that got discovered while testing input.showPicker, so
I'd like to leave some time for those to be found for select.
Your chromestatus
 lists
M119 as the target shipping milestone, but the addition of
the code

landed Sept 29, after the feature freeze for M119. Maybe we
should instead target M120 or M121 to ship, at the earliest?

Thanks,
Mason

On Tuesday, October 3, 2023 at 6:53:59 AM UTC-7 Luke wrote:



On Tuesday, 3 October 2023 at 14:43:23 UTC+1
yoav...@chromium.org wrote:

On Mon, Oct 2, 2023 at 4:40 AM Luke
 wrote:

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

Explainer
https://github.com/whatwg/html/pull/9754



Thanks for the explainer! :)

What's preventing us from landing the PR?

+Chris Harrelson - Can we mark Chromium as positive
for WHATWG purposes?

I think it's just the needing two supporters, we have
Gecko now and I was told Chrome would require this intent
process. WebKit also don't seem opposed.



Specification

https://whatpr.org/html/9754/input.html#dom-select-showpicker



Summary
Developers have been asking for a way to
programmatically open the option picker of a
select element. See

https://www.google.com/search?q=programmatically+open+select+site%3Astackoverflow.com



This is currently impossible in almost every
browser. Providing showPicker() gives developers
a supported way to do this. Following the pattern
of input.showPicker().



Blink component
Blink>Forms

Search tags
showPicker

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



+Aaron Leventhal - Can you take a look at the a11y
questions and see that a) the implementation behavior
makes sense from your perspective b) that we have
testing in place to make sure it stays that way.

Yeah it'd be great if the accessibility aspect could be
reviewed (possibly in the wider context of
input.showPicker too?) as for any missing tests I'm happy
to add any that are needed. I think right now it's just
the WPT tests. Wasn't sure how or if it was even possible
to test further than that.

Re: [blink-dev] Intent to Extend Origin Trial: Cross App and Web Attribution Measurement M120-M123

2023-10-06 Thread Mike Taylor

LGTM to extend from 120 to 122 inclusive.

On 10/6/23 1:43 PM, Nan Lin wrote:

Thanks Chris.

Since the original OT request, we have spec'd most of the cross app
and web algorithms:
https://wicg.github.io/attribution-reporting-api/#cross-app-and-web.

The Cross App and Web Attribution Reporting is an extension to the
Attribution Reporting API (shipped in M115, I2S
),
for which the TAG review
is in progress,
and signals from other implementations have been requested.
We plan to request reviews and signals for this particular extension
as comments to those requests soon.

Here are the feedbacks from the current experiment.

* Initial experiments saw some unexpected losses (e.g.
source/trigger registration failures or ARA reports not received)
that the Android team is debugging & addressing. Some fixes depend
on Android release schedules which are much longer than Chrome.
* We're also adding the ability to register sources and triggers
from WebView

.
We plan for that functionality to be available later this year and
included in the same Origin Trial for ease of implementation.

BTW, I just realized that we should only request extension for 3
milestones at a time, so that would be from 120-122 inclusive.

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

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

2023-10-06 Thread Mike Taylor



On 10/4/23 7:43 PM, 'Sahir Vellani' via blink-dev wrote:



Contact emails

gerch...@microsoft.com , 
sahir.vell...@microsoft.com 



Explainer

https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/PointerEventDeviceId/explainer.md 




Specification

https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/PointerEventDeviceId/explainer.md 




Summary

As devices with advanced pen input capabilities are becoming 
increasingly prevalent, it is important that the web platform 
continues to evolve to fully support these advanced features in order 
to unlock rich experiences for both end users and developers. One such 
advancement is the ability for a device's digitizer to recognize more 
than one pen device interacting with it simultaneously. This feature 
is an extension to the PointerEvent interface to include a new 
attribute, deviceId, that represents a session-persistent, document 
isolated, unique identifier that a developer can reliably use to 
identify individual pens interacting with the page.




Blink component

Blink>Input 




TAG review

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




TAG review status

Pending. TAG review has been pending for 2 months.


Risks



Interoperability and Compatibility



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


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


/Web developers/: No signals

/Other signals/:


WebView application risks

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


None



Debuggability



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

No


Is this feature fully tested by web-platform-tests

?

No. However, there are web tests in Chromium that test 
PointerEventInit with this feature.



Flag name on chrome://flags

PointerEventDeviceId


Finch feature name



Non-finch justification

Edge origin trials successfully underway.

Any Origin Trial feedback you can share?



Requires code in //chrome?

False


Measurement

PointerEventDeviceId use counter implemented.


Availability expectation

Initially available on Chromium browsers on Windows.
Out of curiosity, are there limitations on other platforms that prevent 
supporting this feature?



Adoption expectation

Feature is used by specific partner(s) to provide functionality 
immediately upon launch.



Adoption plan

This feature has been through origin trials on Edge. It is being used 
by partners that provide features on devices with multi pen support.



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


Operating system API's are used to obtain the device id, and are 
necessary for this feature to function. Please see the security 
questionnaire in the TAG review on security and privacy concerns 
related to the use of these APIs.



Estimated milestones

Shipping on desktop

120



Anticipated spec changes

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


WICG Proposal: https://github.com/WICG/proposals/issues/101 
 No web compat/interop risk.



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/511413223424 




Links to previous Intent discussions

Intent to prototype: 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/SA0PR00MB1033E5DE0BDE42239E647E9AFB189%40SA0PR00MB1033.namprd00.prod.outlook.com 



This intent message was generated by

Re: [blink-dev] Re: Intent to Deprecate and Remove: Same-origin blanket enforcement in CSPEE

2023-10-06 Thread Mike Taylor

Also, please request cross-functional review bits in the chromestatus 
entries.


On 10/6/23 10:59 AM, Mike Taylor wrote:


LGTM2

On 10/4/23 6:38 AM, Yoav Weiss wrote:

LGTM1

Usage seems low enough to make this safe still.

On Friday, September 29, 2023 at 2:24:11 AM UTC+2 Jun Kokatsu wrote:

Contact emails

jkoka...@google.com


Explainer

None


Specification

https://github.com/w3c/webappsec-cspee/pull/28/files
<https://github.com/w3c/webappsec-cspee/pull/28/files>


Summary

Removes a special treatment for same-origin iframes from CSP
Embedded Enforcement. This aligns the behavior of enforcing CSP
Embedded Enforcement for cross-origin iframes and same-origin
iframes.



Blink component

Blink>SecurityFeature>ContentSecurityPolicy

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


Motivation

The same-origin blanket enforcement logic specific to same-origin
iframes exposes a new way to block certain resources from loading
in the iframe. This allowed an attack which was not possible
before (example

<https://github.com/google/google-ctf/tree/master/2023/quals/web-biohazard/solution#reviving-xss-auditor-primitive>).



Additionally, this caused a bug
<https://github.com/w3c/webappsec-cspee/issues/26>where CSP nonce
value enforced by CSPEE from a top frame had to exactly match
nonce value served in grand-child frame, if the top frame and
child frame are cross-origin, but child frame and grand-child
frame are same-origin.


Given this part of blanket enforcement is rarely used (~0.17%
<https://chromestatus.com/metrics/feature/timeline/popularity/4599>),
let's remove this logic.



Initial public proposal

None


TAG review

None


TAG review status

Not applicable


Risks

Interoperability and Compatibility

None



Gecko: Positive
<https://github.com/mozilla/standards-positions/issues/878>


WebKit: No signal
<https://github.com/WebKit/standards-positions/issues/251>


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


Yes <https://github.com/web-platform-tests/wpt/pull/41926>


Flag name on chrome://flags

None


Finch feature name

None


Non-finch justification

None


Requires code in //chrome?

False


Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1263288
<https://bugs.chromium.org/p/chromium/issues/detail?id=1263288>


Estimated milestones

M120



Link to entry on the Chrome Platform Status

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


--
You received this message because you are subscribed to the Google 
Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, 
send an email to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d968fa5a-7c9f-4c2e-9a42-8dd3e468fa63n%40chromium.org 
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d968fa5a-7c9f-4c2e-9a42-8dd3e468fa63n%40chromium.org?utm_medium=email_source=footer>.


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

Re: [blink-dev] Re: Intent to Deprecate and Remove: Same-origin blanket enforcement in CSPEE

2023-10-06 Thread Mike Taylor


LGTM2

On 10/4/23 6:38 AM, Yoav Weiss wrote:

LGTM1

Usage seems low enough to make this safe still.

On Friday, September 29, 2023 at 2:24:11 AM UTC+2 Jun Kokatsu wrote:

Contact emails

jkoka...@google.com


Explainer

None


Specification

https://github.com/w3c/webappsec-cspee/pull/28/files



Summary

Removes a special treatment for same-origin iframes from CSP
Embedded Enforcement. This aligns the behavior of enforcing CSP
Embedded Enforcement for cross-origin iframes and same-origin iframes.



Blink component

Blink>SecurityFeature>ContentSecurityPolicy




Motivation

The same-origin blanket enforcement logic specific to same-origin
iframes exposes a new way to block certain resources from loading
in the iframe. This allowed an attack which was not possible
before (example

).



Additionally, this caused a bug
where CSP nonce
value enforced by CSPEE from a top frame had to exactly match
nonce value served in grand-child frame, if the top frame and
child frame are cross-origin, but child frame and grand-child
frame are same-origin.


Given this part of blanket enforcement is rarely used (~0.17%
),
let's remove this logic.



Initial public proposal

None


TAG review

None


TAG review status

Not applicable


Risks

Interoperability and Compatibility

None



Gecko: Positive



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

?


Yes 


Flag name on chrome://flags

None


Finch feature name

None


Non-finch justification

None


Requires code in //chrome?

False


Tracking bug

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



Estimated milestones

M120



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5098158594195456



--
You received this message because you are subscribed to the Google 
Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d968fa5a-7c9f-4c2e-9a42-8dd3e468fa63n%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/c1c64694-fd27-47fb-8f72-5b3aa102b20d%40chromium.org.

Re: [blink-dev] Intent to Ship: CSS :dir() pseudo-class selector

2023-10-06 Thread Mike Taylor


LGTM2 (or 5??)

On 10/4/23 5:28 AM, Manuel Rego Casasnovas wrote:

LGTM1

Just for context, this was already approved 3 years ago:
https://groups.google.com/a/chromium.org/g/blink-dev/c/p0Wc66rbVOc/m/khHJ0dSsAwAJ 



But then we realized the spec text was not ready, there were some 
misunderstandings and things got blocked on that.


Big thanks to push this to the finish line!

Cheers,
  Rego

On 03/10/2023 20:37, David Baron wrote:


    Contact emails

dba...@chromium.org , 
dizha...@chromium.org , 
myid.s...@igalia.com 



    Explainer

None


    Specification

https://www.w3.org/TR/selectors-4/#the-dir-pseudo 




    Summary

The :dir() CSS pseudo-class selector matches elements based on 
directionality, which is determined based on the HTML dir attribute. 
:dir(ltr) matches left-to-right text directionality, and :dir(rtl) 
matches elements with right-to-left text directionality. It is not 
equivalent to [dir] attribute selectors because it matches against 
directions inherited from an ancestor with the dir attribute, and 
because it matches against the direction computed from use of 
dir=auto (which determines directionality from the first character in 
the text with strong directionality).




    Blink component

Blink>CSS 




    TAG review



    TAG review status

Not applicable


    Risks



    Interoperability and Compatibility

This is largely an additive feature. However, as part of the process 
of preparing to ship the feature, we worked on more clearly 
specifying exactly how directionality in HTML works, and particularly 
how it interacts with shadow DOM. This work is occurring in 
https://github.com/whatwg/html/issues/3699 
 
https://github.com/whatwg/html/pull/9554 
 and 
https://github.com/whatwg/html/pull/9796 
 . Since these changes to 
HTML directionality also affect the dirname attribute (which is a 
form submission feature), they have been implemented behind the same 
flag as the pseudo-class. However, they are likely to be low risk 
because the recommended way of using the dirname attribute is to use 
dir=auto on the same element as the dirname attribute, and that usage 
pattern should not be affected. This feature is part of Interop2023's 
focus area on CSS Pseudo-classes: https://wpt.fyi/interop-2023 





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


/WebKit/: Shipped/Shipping 
(https://bugs.webkit.org/show_bug.cgi?id=64861 
) Supported as of 
Safari 16.4 according to https://caniuse.com/css-dir-pseudo 



/Web developers/: No signals

/Other signals/: CSSWG consensus to ship documented in 
https://www.w3.org/TR/css-2017/#experimental 
 (CSSWG includes reps 
from all major browser vendors)



    WebView application risks

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


no



    Debuggability

Same as other pseudo-classes



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

No


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

Yes

WPT test plan (somewhat out of date, since recent CLs have added many 
tests) at https://github.com/web-platform-tests/wpt/issues/25569 
 Existing 
tests have names starting with "dir" in 
https://wpt.fyi/results/css/selectors 
 and 
https://wpt.fyi/results/html/dom/elements/global-attributes 
 PR for 
testing shadow DOM interaction at 
https://github.com/web-platform-tests/wpt/pull/29820 
 which will add 
additional tests




    Flag name on chrome://flags



    Finch feature name

kCSSPseudoDir


    Requires code in //chrome?

False


    Tracking bug

https://code.google.com/p/chromium/issues/detail?id=576815 




    Availability expectation

Available in all major browsers once we ship.


    Sample links


https://jsfiddle.net/fxc9a8uc/1 


    Estimated milestones

Shipping on desktop    120

Re: [blink-dev] Intent to Ship: Shared Storage API Enhancements

2023-10-06 Thread Mike Taylor


Thanks Jason!

And yes, Cammie (and team), please request approval bits in Chromestatus 
- API OWNERs will wait on that (not approvals, just beginning the 
process for each) before approving.


thanks,
Mike

On 10/4/23 9:08 PM, 'Jason Robbins' via blink-dev wrote:
At this morning's API Owners meeting, they asked me to add all review 
gate types to all of the "web developer facing code change" features 
that are currently under review, including this one.  So, I have added 
Privacy, Security, Enterprise, Debuggability, and Testing gates to 
your feature entry.


Please click the gate chips in the "Prepare to ship" stage on your 
feature detail page.  For each one, answer survey questions and 
request that cross-functional review.  You can request them all in 
parallel.  In cases where you already have the go/launch bit approved, 
you can note that in a comment on that gate for a potentially faster 
review.


Thanks,
jason!

On Wednesday, October 4, 2023 at 9:01:02 AM UTC-7 Chris Harrelson wrote:

This looks good, but please file for all of the 5 other chips
necessary for shipping a feature.

On Wed, Sep 27, 2023 at 11:13 AM Cammie Smith Barnes
 wrote:


Contact emails

cam...@chromium.org

jka...@chromium.org

ale...@chromium.org

yao...@chromium.org


Explainer

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



Specification

https://wicg.github.io/shared-storage/



Summary

We plan to ship the following changes to the Shared Storage API:

1.

Only allow Private Aggregation reports for up to 5 seconds
after a worklet operation starts

1.

This is a privacy measure to prevent timing attacks.

2.

Reports sent after this point are silently dropped

2.

Allow writing to and deleting from Shared Storage via HTTP
response header

1.

This is a performance improvement and is backwards
compatible

3.

Per-site privacy budgeting

1.

This change enforces budgets to per-site rather than
per-origin


Blink component

Blink>Storage>SharedStorage







Risks


Interoperability and Compatibility

Change [1] will drop the private aggregation contributions
issued after 5 seconds after a worklet operation starts. 5
seconds should be sufficient for all known use cases, so this
change should have negligible backward compatibility issues.

Change [2] is optional and fully backwards compatible.

Change [3] could decrease budget for those that are using
multiple origins today that are considered part of the same
eTLD+1. Since the API is new (shipped in M115), the
expectation is for the impact to be low. It will not break
script since the APIs gracefully handle situations where the
budget is exceeded, but could impact the overall quality of
the returned data for that site.


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

Shared Storage database contents for an origin can be viewed
and modified within devtools. Support for debugging Shared
Storage worklets will be available within the next couple of
milestones.



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

All but WebView


Is this feature fully tested by web-platform-tests

?

Yes


Flag name



Finch feature name

SharedStorageAPIM118


Requires code in //chrome?

No


Estimated milestones

We intend to ship in  M119.


Anticipated spec changes

1.

Timeout enforcement:

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

2.

Allow writing to Shared Storage via response headers

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

3.

Per-site privacy budgeting

Re: [blink-dev] Intent to Ship: Private Aggregation API bundled enhancements

2023-10-06 Thread Mike Taylor


LGTM3

On 10/5/23 6:51 PM, Chris Harrelson wrote:

LGTM2

On Wed, Oct 4, 2023 at 10:46 PM Yoav Weiss  wrote:

LGTM1

On Wed, Oct 4, 2023 at 7:17 PM Alex Turner 
wrote:

Mike: thanks for the clarification, I've added a comment to
the TAG review and kicked off those reviews in a new entry:
https://chromestatus.com/feature/5148973702840320. I'll ping
this thread when those reviews are complete.

Yoav: yes, that's our understanding (although until enrollment
is enforced there is a chance we don't have a complete view of
the testers). We're in touch with a few partners who are using
it that we will communicate to directly. We also have a
mailing list to broadcast these kinds of updates more
generally. Given that, we feel confident the impact will be
minimal to those testing the API.

Alex

On Wed, Oct 4, 2023 at 6:50 AM Yoav Weiss
 wrote:

Am I right to assume that the API is still only being used
by a relatively small number of partners to which y'all
can communicate the new constraints?

On Monday, October 2, 2023 at 11:08:43 PM UTC+2 Mike
Taylor wrote:

Hey Alex,

Apologies for the delay. It would probably be good to
make a new entry and request all the relevant review
approvals (sorry for the extra work).

Also, probably useful to drop a link in the TAG review
to this Intent, so reviewers can eventually be aware
of these changes.

On 9/27/23 2:35 PM, Alex Turner wrote:

I set this feature up as a "Web developer facing
change to existing code", but I'm seeing that "New
feature incubation" may have been more appropriate
(although the guidance

<https://www.chromium.org/blink/launching-features/#feature-types>
is a bit uncertain). Unfortunately, that
means chromestatus won't let me request any reviews
other than API owners; would it make sense to create
a new feature entry? (Note also that these changes
have already gone through internal privacy and
security reviews.)

Thanks!
Alex

On Wed, Sep 27, 2023 at 12:02 PM Chris Harrelson
 wrote:

Please also fill out the other chromestatus
review categories for this Intent, in particular
for Privacy and Security, thanks.

On Tue, Sep 26, 2023 at 11:14 PM Yoav Weiss
 wrote:



On Mon, Sep 25, 2023 at 11:52 PM Alex Turner
 wrote:


Contact emails

ale...@chromium.org


Specification

 *

Null report fixes:

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

<https://github.com/patcg-individual-drafts/private-aggregation-api/pull/91>

 *

Debug mode eligibility changes:

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

<https://github.com/patcg-individual-drafts/private-aggregation-api/pull/90>

 *

Padding report payloads:

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

<https://github.com/patcg-individual-drafts/private-aggregation-api/pull/98>,

https://github.com/WICG/attribution-reporting-api/pull/1030

<https://github.com/WICG/attribution-reporting-api/pull/1030>

 *

Reducing delay:

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

<https://github.com/patcg-individual-drafts/private-aggregation-api/pull/103>


Summary

We're planning a few bundled changes to
Private Aggregation:

 *

Null report fixes: Currently reports
with no contributions are
inadvertently dropped. This change
ensures that, when a context ID is

Re: [blink-dev] Intent to Ship: Unprefix -webkit-background-clip for "text" and make it an alias

2023-10-02 Thread Mike Taylor

LGTM2, can you also please request reviews for the other categories in
chromestatus (and file any relevant issues in the compat spec, if needed)?

On 9/28/23 1:16 PM, Daniil Sakhapov wrote:
Sure, I'm saying that old -webkit-background-clip works with keywords:
border, content, padding. The new one - background-clip works with
border-box, content-box, padding-box.
So, per compat spec -webkit-background-clip should be alias to
background-clip. But since the keywords are different, in order to
handle round trip better (e.g. setting -webkit-background-clip to
content would read back content-box, as it's an alias to
background-clip), we want to drop support of old keywords without -box
for -webkit-background-clip. To see how bad that would we've set up
use counters.
The biggest one is 0.08%. I've manually checked 80% of the websites
reported by that use counter, but found that all of them use *-box
keywords, and only one uses -webkit-background-clip: content.

So I think it's safe to remove support for old keywords.
Hope it's more clear now.
On Wednesday, September 27, 2023 at 4:55:53 PM UTC+2 Daniel Bratell wrote:

It allows to use the unprefixed version for background-clip: text
and makes -webkit-background-clip an alias for background-clip.
Also, it drops support for non-suffixed keywords (content,
padding and border) for better round-trip with alias.

Can you clarify exactly what this means? I'm perfectly fine with
lgtm-ing unprefixing and adding a (temporary?) alias for the old
keyword, but if we start removing support for keywords we need to
be more careful and I want to be sure I understand.

/Daniel

On 2023-09-27 09:53, Daniil Sakhapov wrote:

Also forgot to mention: the highest use counter for unsuffixed
keyword is 0.08 - and among those I've analyzed 80% of websites
and all of them use suffixed *-box version, so it's safe to remove.

On Wednesday, September 27, 2023 at 9:49:35 AM UTC+2 Yoav Weiss
wrote:

LGTM1

On Wed, Sep 27, 2023 at 2:38 AM 一丝 wrote:

I think the correct specification address would be
https://drafts.csswg.org/css-backgrounds-4/#typedef-bg-clip

In css-backgrounds-4 also added `border` value, should we
support it when removing the prefix? Maybe this needs to
be discussed further by the CSSWG.

在2023年9月27日星期三 UTC+8 06:04:54
写道：

Is there any interest in doing the same for
-webkit-text-fill-color? The two get typically used
in combination for gradient effects:

https://github.com/tomayac/blogccasion/blob/6ee3722011661db7a0c95c4379d7905bd8e95404/css/main.css#L100-L113

.
(See any of the headings on https://blog.tomayac.com/
for an example.)

On Tue, Sep 26, 2023, 16:33 Daniil Sakhapov
wrote:

Contact emails

sakh...@chromium.org

Specification

https://drafts.csswg.org/css-backgrounds/#background-clip

Summary

It allows to use the unprefixed version for
background-clip: text and makes
-webkit-background-clip an alias for
background-clip. Also, it drops support for
non-suffixed keywords (content, padding and
border) for better round-trip with alias.

Blink component

Blink>CSS

Risks

Interoperability and Compatibility

None

/Gecko/: Shipped/Shipping Firefox doesn't support
keywords with no suffix for prefixed version

/WebKit/: Shipped/Shipping Safari supports
keywords with no suffix (border, content,
padding), but only for prefixed version

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

Yes

Is this feature fully tested by
web-platform-tests

Re: [blink-dev] Re: Intent to Ship: Intersection Observer Scroll Margin

2023-10-02 Thread Mike Taylor


LGTM1

On 9/29/23 8:04 PM, Traian Captan wrote:

Hi Alex,

Just in case, I file a TAG review issue:
https://github.com/w3ctag/design-reviews/issues/905

Regards,
Traian


On Fri, Sep 29, 2023 at 2:22 PM Traian Captan  
wrote:


Hi Alex,

The much larger intersection observer feature went through a TAG
review in https://github.com/w3ctag/design-reviews/issues/197, and
this is only a minor addition to that.

Regards,
Traian


On Fri, Sep 29, 2023 at 12:43 PM Alex Russell
 wrote:

This looks relatively non-controversial, but why wasn't a TAG
review requested?

--
You received this message because you are subscribed to the Google 
Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFxahvujC4h6MHxdfFWZnXTa2_8bawUTk7%2B_XCUXC1d1aZFnJw%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/ceaf567c-b0a5-4d4a-b0ef-a3d9f3a62cc1%40chromium.org.

Re: [blink-dev] Intent to Ship: Private Aggregation API bundled enhancements

2023-10-02 Thread Mike Taylor


Hey Alex,

Apologies for the delay. It would probably be good to make a new entry 
and request all the relevant review approvals (sorry for the extra work).


Also, probably useful to drop a link in the TAG review to this Intent, 
so reviewers can eventually be aware of these changes.


On 9/27/23 2:35 PM, Alex Turner wrote:
I set this feature up as a "Web developer facing change to existing 
code", but I'm seeing that "New feature incubation" may have been more 
appropriate (although the guidance 
 is 
a bit uncertain). Unfortunately, that means chromestatus won't let me 
request any reviews other than API owners; would it make sense to 
create a new feature entry? (Note also that these changes have already 
gone through internal privacy and security reviews.)


Thanks!
Alex

On Wed, Sep 27, 2023 at 12:02 PM Chris Harrelson 
 wrote:


Please also fill out the other chromestatus review categories for
this Intent, in particular for Privacy and Security, thanks.

On Tue, Sep 26, 2023 at 11:14 PM Yoav Weiss
 wrote:



On Mon, Sep 25, 2023 at 11:52 PM Alex Turner
 wrote:


Contact emails

ale...@chromium.org


Specification

 *

Null report fixes:

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



 *

Debug mode eligibility changes:

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



 *

Padding report payloads:

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

,
https://github.com/WICG/attribution-reporting-api/pull/1030


 *

Reducing delay:

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




Summary

We're planning a few bundled changes to Private Aggregation:

 *

Null report fixes: Currently reports with no
contributions are inadvertently dropped. This change
ensures that, when a context ID is specified, a null
report is sent even if budget is denied. Separately,
it fixes a bug causing budget to always be denied for
null reports.

 *

Debug mode eligibility changes: Currently, debug mode
is always available. This change only allows debug
mode for callers that are allowed access to
third-party cookies, silently dropping the debug mode
otherwise. Note that this will allow debug mode to
automatically sunset when third-party cookies are
deprecated.

 *

Padding report payloads: To avoid the payload size
being dependent on the number of contributions, we
will pad it with 'null' contributions to a fixed
length. **Note**: this change will also affect
Attribution Reporting’s aggregatable reports.

 *

Reducing delay: When a context ID is specified, we
remove the randomized 10-60 minute delay, which is
superfluous as a report is always sent in this case.
Instead, we just wait until the Shared Storage
operation timeout.


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

  * Null report fixes: Increases the number of reports
sent to reporting endpoints, reporting endpoints using
plaintext debug payloads will need to handle the null
report case.

Do you know if current reporting endpoints are ready to handle
this change?

  * Debug mode eligibility changes: Backwards incompatible
for

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

2023-10-02 Thread Mike Taylor

LGTM1 % landing https://github.com/WICG/turtledove/pull/796. Please
follow up with the WPTs as well.

On 9/27/23 11:56 AM, Chris Harrelson wrote:
Please fill out the other chromestatus review categories (privacy,
security, etc); we'll re-review once those are done.

On Wed, Sep 20, 2023 at 2:42 PM 'Orr Bernstein' via blink-dev
wrote:

Contact emails

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

Explainer

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

Specification

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

Summary

In online ad auctions for ad space, it’s sometimes useful to
prevent showing an ad to certain audiences, a concept known as
negative targeting. For example, you might not want to show a new
customer advertisement to existing customers. New customer
acquisition campaigns most often have this as a critical
requirement. Protected Audience currently enables ads to target
users that have been joined to a given interest group through some
past activity on the web. This feature extends Protected Audience
to enable negative targeting by allowing new ads to target only
those users who have not been joined to a given interest group. In
this way, we're enabling advertisers to target new groups of users
using the existing privacy-preserving concepts of the Protected
Audience API.

Blink component

Blink>InterestGroups

TAG review

The parent proposal, Protected Audience, is still pending:
https://github.com/w3ctag/design-reviews/issues/723

TAG review status

Pending

Risks

Interoperability and Compatibility

None. This is an optional new feature of the Protected Audience
API. Ad techs can use this new feature by specifying values for
new fields in the auction config. Without explicit values for
those new fields, there's no functional behavioral change as a
result of this feature.

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

Web developers: Adtech asked for this via Protected Audience
Github issue #319 .

Debuggability

Additional bids sent into the auction are visible in their
response headers via DevTools. You can determine if the additional
bid was sent for scoring by adding a breakpoint in the scoring
script in DevTools. Error scenarios, e.g. signature verification
errors and joining origin mismatch on negative interest groups -
are written to the console. We're considering additional DevTools
enhancements to aid additional bids debugging.

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

It will be supported on all platforms that support Protected
Audience, so all but WebView.

Is this feature fully tested by web-platform-tests

We plan to add WPTs to cover this API in the next month.

Flag name on chrome://flags

None

Finch feature name

FledgeNegativeTargeting

Requires code in //chrome?

False

Estimated milestones

Shipping on desktop and Android in M118.

Anticipated spec changes

None related to this feature.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5021508157571072

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

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

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5ebd44f6-57b2-448f-b32c-87d63acfa471n%40chromium.org

[blink-dev] PSA: Enabling partitioned 3rd party storage when “Block 3rd Party Cookies” setting is enabled

2023-09-28 Thread Mike Taylor

*Howdy blink-dev, *

In https://chromium-review.googlesource.com/c/chromium/src/+/4899223 we
intend to enable the 3rd party storage partitioning feature when 3rd
party cookies (3PCs) are disabled, given that 3rd party storage
partitioning is enabled for 100% of M115 and above.

Previously, when a user blocked 3PCs, storage in 3rd party contexts was
also blocked. Given that partitioned storage does not contribute to
cross site tracking, it is desirable to allow this storage when 3PCs are
blocked - especially as we move towards deprecating 3PCs. Note that user
specified allow/block cookie settings will continue to work and a page
with a user block cookie setting will also block all storage.

This follows closely in the footsteps of CHIPS, for which we already
aligned on the acceptable privacy implications as well as the required
UI updates. We have now landed the same UI treatment for partitioned
storage as well, to avoid unpleasant surprises.

This change will ride the M119 train, so we should be able to observe
any compatibility issues before it reaches stable (but we don’t
anticipate any new breakage beyond what we've seen by shipping
partitioned storage to stable).

thanks, Mike

Re: [blink-dev] PSA: Fire beforeinput event before compositionupdate event during IME composition.

2023-09-26 Thread Mike Taylor

Hi there -

Given that this change is web observable, have you all done any
compatibility testing or analysis to ensure sites aren't relying on the
differences between engines here (hopefully not, but you know...)?

On 9/25/23 7:59 PM, 'Siye Liu' via blink-dev wrote:

Hi blink-dev,

We've been landing a change
to
enable new event ordering for beforeinput and compositionupdate during
IME composition.

The previous event ordering for IME composition was:

keydown -> compositionstart -> *beforeinput -> compositionupdate* ->
input -> keyup -> keydown -> *beforeinput -> compositionupdate* ->
textInput -> input -> compositionend -> keyup.

The new ordering is:

keydown -> compositionstart -> *compositionupdate -> beforeinput* ->
input -> keyup -> keydown -> *compositionupdate -> beforeinput* ->
textInput -> input -> compositionend -> keyup.

This change aligns our event ordering with the behavior of Firefox and
Safari, which fire the beforeinput event after the compositionupdate
event.

The new event ordering is controlled by a runtime enabled feature flag
that is set to stable status (enabled by default).

Re: [blink-dev] Intent to Ship: Change SVGClipPathElement to inherit from SVGElement

2023-09-22 Thread Mike Taylor

LGTM3

On 9/22/23 9:59 AM, Chris Harrelson wrote:

LGTM2

On Fri, Sep 22, 2023, 5:40 AM Daniel Bratell wrote:

Aligning all the browsers is a good thing. Risk seems small enough
to just do it.

LGTM1

/Daniel

On 2023-09-22 12:00, Fredrik Söderquist wrote:

Contact emails

f...@opera.com

Specification

https://www.w3.org/TR/css-masking-1/#InterfaceSVGClipPathElement

Summary

SVGClipPathElement (the interface for the element) is
changed to inherit from the SVGElement interface rather than the
SVGGraphicsElement interface.

Blink component

Blink>SVG

Search tags

svg , dom

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

This is aligning Blink with other engines. There is a risk due to
how the prototype chain changes, but given that this has already
shipped in the other engines we expect the actual risk to be
relatively low.

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

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

/Web developers/: No signals

/Other signals/:

WebView application risks

No additional risks

Debuggability

None

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

Yes

Is this feature fully tested by web-platform-tests

Yes

Flag name on chrome://flags

None

Finch feature name

None

Non-finch justification

Changes to the prototype chain is difficult (if even possible?)
to flag guard.

Requires code in //chrome?

False

Tracking bug

https://crbug.com/851080

Estimated milestones

Shipping on desktop 119

Shipping on Android 119

Shipping on WebView 119

Anticipated spec changes

N/A

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5759124080164864

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/CAHediLRm5KS2Leb1xKWO7fZjScx2qQzBTc9L0MYFhXPKLN6Nig%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/51684e35-c5cd-2868-f837-0ada5b663a52%40gmail.com

Re: [blink-dev] Intent to Ship: WebRTC Codec Selection API

2023-09-21 Thread Mike Taylor

LGTM2

On 9/21/23 5:31 AM, 'Philipp Hancke' via blink-dev wrote:
Am Do., 21. Sept. 2023 um 10:43 Uhr schrieb Florent Castelli
:

On Wed, Sep 20, 2023 at 5:21 PM Yoav Weiss
wrote:

LGTM1

On Wed, Sep 20, 2023 at 11:48 AM Florent Castelli
wrote:

Contact emails

orp...@chromium.org

Explainer

https://github.com/Orphis/webrtc-extensions/blob/explainer/explainers/codec-selection.md

Specification

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

Summary

This new API extends WebRTC encoding parameters to allow
developers to choose a specific negotiated codec to be
used for encoding an RTP stream.

Blink component

Blink>WebRTC>PeerConnection

TAG review

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

TAG review status

Issues addressed

Risks

Interoperability and Compatibility

Interoperability risks are low. This is a new dictionary
member and API surface, if it isn't used by current
applications, it should not cause any impact on compatibility.

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

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

/Web developers/: No signals

Presumably this is something WebRTC developers are interested
in. Any ways you can think of to extract such a signal for
WebRTC things in the future?

WebRTC developers are indeed interested but have nothing to link
to. Google Meet is interested in using the API and other
conferencing solutions have been interested in advanced scenarios
this API allows as well.

Same for MSFT Teams which I work on. Switching between codecs on the
fly is becoming important (e.g. because AV1 has encoding tools which
very much benefit static content for slide sharing).
While this is already possible with SDP renegotiation (even locally),
the API is much more ergonomic and avoids some race conditions.

The API also enables use-cases where multiple simulcast streams (i.e.
same picture but different resolutions) can use different codecs, e.g.
a more modern one like AV1 for small resolutions where software
encoding is feasible and a hardware encoded one (H264, VP9 I think)
for large resolutions

What I heard from Jitsi Meet via Saul (cc'd in case he wants to say
more) sounded similar.

Ergonomics

No ergonomic risks. This API is part of WebRTC and will be
used with other encoding parameters. One of its goals is
to improve the WebRTC ergonomics by removing the need to
make several calls with possible side effects to change
the active codec, which should improve performance as well.

Debuggability

WebRTC is not supported by DevTools at the moment.
chrome://webrtc-internals will reflect in the RTP stream
statistics which codec is currently used.

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

Yes

Is this feature fully tested by web-platform-tests

Yes

Flag name on chrome://flags

Finch feature name

RTCRtpEncodingParametersCodec

Requires code in //chrome?

False

Tracking bug

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

Estimated milestones

Shipping on desktop 119

Shipping on Android 119

Shipping on WebView 119

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5200982281027584

Links to previous Intent discussions

Intent to prototype:

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADRnnSXEi2i3DzkXQo1ptX-KR%2BULh-4LOt5zpOi14BTstZN_9g%40mail.gmail.com

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

the Google

Re: [blink-dev] Intent to Ship: Horizontal rules inside select elements

2023-09-20 Thread Mike Taylor

LGTM2

On 9/20/23 12:41 PM, Joey Arhar wrote:

For developer signals:

The material design menu component supports dividers like this: 
https://m2.material.io/components/menus#anatomy:~:text=Text-,Divider,-Text%20and%20icon

Bootstrap has a "dropdown-divider" class for the "dropdown-menu" class 
which is like a select with : 
https://getbootstrap.com/docs/4.0/components/dropdowns/

This intent adds support for dividers but not styling.

On Wed, Sep 20, 2023 at 8:10 AM Joey Arhar  wrote:

> Can we file a Mozilla position? (to raise awareness on their end
if nothing else)

https://github.com/mozilla/standards-positions/issues/887

> Have you talked to devrel folks about getting some signal there?
Presumably this is something developers would want to be able to do

I just reached out to devrel about this

On Wed, Sep 20, 2023 at 7:54 AM Yoav Weiss
 wrote:

LGTM1

On Tue, Sep 19, 2023 at 7:51 PM Joey Arhar
 wrote:

Contact emails

jar...@chromium.org

Explainer

None

Specification

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

Summary

This feature makes the HTML parser allow  tags inside
 tags. These  elements create horizontal
borders in between  elements in the listbox popup,
which we already support if you manually insert an hr
element with javascript.

Neat!

WebKit implemented this and just put it in their release
notes:

https://webkit.org/blog/14445/webkit-features-in-safari-17-0/#:~:text=Horizontal%20rules%20inside%20select%20elements

Blink component

Blink>DOM

TAG review

None

You spelled "Not required as this landed in HTML and shipped
in WebKit" wrong :)

TAG review status

Not applicable

Risks

Interoperability and Compatibility

None

/Gecko/: No signal
(https://bugzilla.mozilla.org/show_bug.cgi?id=1830909)

Can we file a Mozilla position? (to raise awareness on their
end if nothing else)

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

/Web developers/: No signals

Have you talked to devrel folks about getting some signal
there? Presumably this is something developers would want to
be able to do

/Other signals/:

WebView application risks

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

None

Debuggability

None

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

Yes

Is this feature fully tested by web-platform-tests

?

Yes

Flag name on chrome://flags

SelectHr

Finch feature name

SelectHr

Requires code in //chrome?

False

Estimated milestones

Shipping on desktop 118
DevTrial on desktop 118

Shipping on Android 118
DevTrial on Android 118

Shipping on WebView 118

Anticipated spec changes

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

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6198448366026752

This intent message was generated by Chrome Platform
Status .

-- 
You received this message because you are subscribed to

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

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

2023-09-20 Thread Mike Taylor


And gentle reminder to please land the spec PRs :)

On 9/20/23 12:54 PM, Chris Harrelson wrote:

LGTM3

On Wed, Sep 20, 2023 at 9:53 AM Yoav Weiss  wrote:

LGTM2

Talking to the team, the 10K limit is Finchable, so we'd be able
to lower it if this runs into issues in the field. Also
presumably, having that as a limit doesn't mean most responses
would actually use that.

On Sat, Sep 16, 2023 at 6:52 AM Yoav Weiss
 wrote:




On Fri, Sep 15, 2023 at 10:00 PM Mike Taylor
 wrote:

Thanks, LGTM1 pending the PRs landing.

On 9/12/23 12:29 AM, Caleb Raitto wrote:


Hi Mike,


Pull request 695
<https://github.com/WICG/turtledove/pull/695>is the
change to update the explainer to describe the new
header-based directFromSellerSignals, whereas 771
<https://github.com/WICG/turtledove/pull/771>and 774
<https://github.com/WICG/turtledove/pull/774>are for the
spec changes.


The explainer change describes usage of the new API and
provides context for the differences between header-based
and the prior bundles based versions of
directFromSellerSignals, whereas the spec change
describes how to implement the header-based version.


We intend to land all 3 pull requests.


Thanks,

-Caleb

On Monday, September 11, 2023 at 11:18:26 AM UTC-4 Mike
Taylor wrote:


On 9/11/23 12:55 PM, Mike Taylor wrote:


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


Hi Yoav, some responses inline:

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

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

Contact emails*

pauljen...@chromium.org


*Explainer*

https://github.com/WICG/turtledove/pull/69
<https://github.com/WICG/turtledove/pull/695>5

*


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

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


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



Can you outline that flow more explicitly? Apologies, but I'd
like to better understand its performance characteristics.
IIUC, in both cases we have an initial page that triggers a
request, where in one that request is to a WBN (using a 
?) and the other it's to a random resource using
fetch({adAuctionHeaders: true}) ?

I guess it's unclear to me why the former would be slower than
the latter, especially given the large payloads and the fact
that headers can't really be compressed.



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


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


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



1K header is a lot. 10KB header is... really a lot.
Have you tested that with a variety of CDNs and othe

Re: [blink-dev] Re: Intent to Prototype And Ship: Allow transferring ArrayBuffer into VideoFrame, AudioData, EncodedVideoChunk, EncodedAudioChunk, ImageDecoder constructors

2023-09-20 Thread Mike Taylor

LGTM3

On 9/20/23 11:48 AM, Chris Harrelson wrote:

LGTM2

Would be great to file official vendor signals just so they know this
is happening, if you're willing.

On Wed, Sep 20, 2023 at 7:41 AM Yoav Weiss wrote:

LGTM1 given the consistency here with other platform APIs and the
need to extend this in the future.

On Tue, Sep 5, 2023 at 8:39 PM Dale Curtis
wrote:

I wouldn't say it's urgent, but I would hope for feedback
within a week or two. Thanks!

- dale

On Sun, Sep 3, 2023 at 4:32 AM Sangwhan Moon
wrote:

Thank you for filing this. If it is urgent, I could flag
it as time constrained.

On Aug 31, 2023, at 7:14, 'Eugene Zemtsov' via blink-dev
wrote:

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

On Wed, Aug 30, 2023 at 9:50 AM Dale Curtis
wrote:

Alex, I assume you mean TAG's views on consistency
regarding transfer ergonomics? Otherwise
https://www.w3.org/TR/design-principles/#consistency
is what we followed here. We have not asked, given
that we felt this was a small performance
improvement, with pre-existing ergonomics, and
already has Media WG approval. We can certainly file
a TAG request, but as you know, litigating minor
features like this through TAG is unlikely to have a
timely resolution.

Regarding Yoav's proposal above of a single boolean,
that might make sense today where we have a single
transfer, but we expect more input ArrayBuffers over
time for some of these APIs, which would mean it
becomes all-or-nothing for developers. E.g., we are
likely to accept arrays of metadata, HDR data, etc.
The boolean would mean they must transfer everything,
which may lead to them making temporary copies of
smaller buffers to get transfer effects on the larger
ones.

Daniel, sorry, that's just an oversight in the
chromestatus entry. There are tests added (here's the
one for videoFrame):

https://chromium-review.googlesource.com/c/chromium/src/+/4529012/17/third_party/blink/web_tests/external/wpt/webcodecs/videoFrame-construction.any.js

- dale

On Wed, Aug 30, 2023 at 9:19 AM Daniel Bratell
wrote:

In addition to Alex's question, I also noticed
that you answered the web-platform-tests with a
"no", which is a bit unexpected to me. Is there a
reason this cannot or won't be tested in
web-platform-tests?

/Daniel

On 2023-08-30 18:03, Alex Russell wrote:

Hey Eugene,

I'm a little worried that we're debating API
shape here when there hasn't been any guidance
from the TAG on design consistency. Have you
either asked the TAG to weigh in (didn't see a
review link in the Intent) or asked Chromium
(ex)TAG members to give the API a once-over?

Best,

Alex

On Thursday, August 24, 2023 at 9:45:42 AM UTC-7
Eugene Zemtsov wrote:

> Can you clarify if this was in response to
my questions or to Jonathan's?

Yours.
Sorry, I missed Jonathan's question.

> Once an ArrayBuffer is transferred and
detached, any further access will result in
some sort of TypeError, right?

Detached ArrayBuffers look like an empty
ArrayBuffers.
you can play with them using this code

let ab = new ArrayBuffer(100);
let ab2 = structuredClone(ab, { transfer:
[ab] })
ab is empty now

On Thu, Aug 24, 2023 at 12:51 AM Yoav Weiss
wrote:

On Wed, Aug 23, 2023 at 12:26 PM
Jonathan Hao wrote:

Thanks for the clarification!

On Tue, Aug 22, 2023 at 9:20 PM
Eugene Zemtsov
wrote:

A transfer list is consistent
with the approach taken by

Re: [blink-dev] Intent to Ship: Private Network Access restrictions for automotive

2023-09-18 Thread Mike Taylor

LGTM1. Curious to know (but happy to not know) how many local servers 
are running in my car...


On 9/18/23 5:30 AM, Jonathan Hao wrote:



Contact emails


p...@chromium.org


Explainer


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


Specification


https://github.com/WICG/private-network-access


Design docs




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


Summary


Enforce (instead of just warn) Private Network Access
restrictions on Chrome for Android Automotive (if
BuildInfo::is_automotive), including: - Private Network Access
preflight requests for subresources. See
https://chromestatus.com/feature/5737414355058688, and -
Private Network Access for Workers. See
https://chromestatus.com/feature/5742979561029632



Blink component


Blink>SecurityFeature>CORS>PrivateNetworkAccess




TAG review


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


TAG review status


Issues addressed


Origin Trial documentation link


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


Risks




Interoperability and Compatibility


Android Automotive is going to be a new platform, so no
websites should rely on making private network requests yet.
And our purpose is to ship this from the beginning to avoid
future compatibility risks.



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

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

/Web developers/: Mixed signals Anecdotal evidence so far
suggests that most web developers are OK with this new
requirement, though some do not control the target endpoints
and would be negatively impacted.

/Other signals/:


Security


This change aims to be security-positive, preventing CSRF
attacks against soft and juicy targets such as router admin
interfaces. It does not cover navigation requests, which are
to be addressed in followup launches. DNS rebinding threats
were of particular concern during the design of this feature:

https://docs.google.com/document/d/1FYPIeP90MQ_pQ6UAo0mCB3g2Z_AynfPWHbDnHIST6VI/edit#heading=h.189j5gnadts9



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


Relevant information (client and resource IP address space) is
already piped into the DevTools network panel. Deprecation
warnings and errors will be surfaced in the DevTools issues
panel explaining the problem when it arises.



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


No


Is this feature fully tested by web-platform-tests

?


Yes


Flag name on chrome://flags


None


Finch feature name


PrivateNetworkAccessRestrictionsForAutomotive


Requires code in //chrome?


False


Estimated milestones


Shipping on Android (only when is_automotive=true)  119



Anticipated spec changes


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

None


Link to entry on the Chrome Platform Status


https://chromestatus.com/feature/5082807021338624


Links to previous Intent discussions


Intent to prototype:

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

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/CAOC%3DiP%2BAu2epCdGTM-VgyBXj61C%2BJ4WUv3WTO9SZ_OAeaf2JmQ%40mail.gmail.com

Re: [blink-dev] Intent to Ship: Attribution Reporting features (change registration limit, remove 1hr delay)

2023-09-18 Thread Mike Taylor


LGTM2

On 9/16/23 10:28 AM, Yoav Weiss wrote:

LGTM1

On Mon, Sep 11, 2023 at 10:58 PM 'Akash Nadan' via blink-dev 
 wrote:


Contact emails

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


Explainer

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


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



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




Specification

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



Blink component

Internals > AttributionReporting




Summary

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

 *

Increasing limits on registration data size to allow more
flexibility

 *

Removing non-privacy-bearing browser-imposed delay to allow
reports to be received faster


Spec changes

 1. Remove aggregation keys size limit on trigger registration

 2. Remove 1-hour delay between end of report window and
transmission



Risks
Interoperability and Compatibility

Change (1) and (2) are both fully backwards compatible. (1) will
allow registration of more data than before. (2) will allow
reports to arrive more quickly than before.


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

All except Android WebView


Is this feature fully tested by web-platform-tests

?


Yes


Estimated milestones

Chrome 118


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5089526405398528



Links to previous Intent discussions

Previous I2S:

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



https://groups.google.com/a/chromium.org/g/blink-dev/c/nWF61c8xu-M/m/uMmH1ewcAQAJ




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

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

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2a8f10f8-b85f-42eb-9059-3eacb4b0ba27n%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/CAL5BFfUXxO4swOYcMtWxKEieM32%2B4n-G8bwG2irQggNR-a04hw%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/5d013682-8763-43a7-85d8-cf7c7e989f3a%40chromium.org.

Re: [blink-dev] Intent to Ship: WebAssembly Garbage Collection (WasmGC)

2023-09-16 Thread Mike Taylor

LGTM2 - thanks Adam.

On 9/16/23 7:39 AM, Yoav Weiss wrote:

LGTM1

On Fri, Sep 15, 2023 at 11:13 PM Adam Klein wrote:

Thanks for the reply, Mike. I'm going to fill in some of this to
avoid blocking over the weekend.

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

On 9/12/23 9:22 PM, 'Emanuel Ziegler' via blink-dev wrote:

Dear API owners,

Following the continued experiment for Garbage
Collected WebAssembly (WasmGC), we plan to ship the
feature in M119 after the positive vote to phase 4 by
the WebAssembly Community Group today.

The feature has shown very good performance with
reasonable compromises. The findings from the origin
trial are summarized in a public document

<https://docs.google.com/document/d/1KsbQLh_RzM9ixF6bzmJwyRMQLE-rSFlz_zNoGv-EITY/edit?usp=sharing>.

This feature is tied to the Function References
<https://github.com/WebAssembly/function-references>proposal
which is a de-facto part of WasmGC (no current use
outside of the proposal, hard requirement for WasmGC)
and only listed as a separate proposal for historic
reasons. The Function References proposal has
therefore also been voted to phase 4 on the same day
as WasmGC.

We plan to launch the feature in the following manner:

End the current origin trial with M118 as its
last milestone

Refactor the binary instruction representation to
match the final spec (incompatible change)

Ship the feature with M119

This plan sounds good. Thx.

Our data from the trial has shown that there is a
need for fast string interoperability with JS that
this proposal does not address. We plan to launch a
new experiment investigating different approaches to
this problem (see separate I2E mail).

Contact emails

ad...@chromium.org, jkumme...@chromium.org

Explainer

https://github.com/WebAssembly/gc/blob/master/proposals/gc/Overview.md

https://github.com/WebAssembly/function-references/blob/main/proposals/function-references/Overview.md

Specification

https://github.com/WebAssembly/gc/tree/main/proposals/gc

Summary

The GC proposal adds efficient support for high-level managed
languages to WebAssembly, via struct and array types that
enable language compilers targeting Wasm to integrate with a
garbage collector in the host VM. In Chrome, enabling this
feature implies enabling Typed Function References, which
allow function references to be stored in the aforementioned
structs and arrays.

Blink component

Blink>JavaScript>WebAssembly

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

Search tags

wasm <https://chromestatus.com/features#tags:wasm>,
webassembly
<https://chromestatus.com/features#tags:webassembly>, gc
<https://chromestatus.com/features#tags:gc>, managed objects
<https://chromestatus.com/features#tags:managed%20objects>,
wasmgc <https://chromestatus.com/features#tags:wasmgc>

TAG review

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

TAG review status

Issues addressed

Risks

Interoperability and Compatibility

/Gecko/: Positive

/WebKit/: No signal

Can we request a signal?
https://github.com/WebKit/standards-positions/issues/new/choose

Since this is a Phase 4 proposal within the Wasm CG, the process
does not normally require a signal, as documented in
https://bit.ly/blink-signals. Are you requesting an
exception-to-the-exception here?

I don't think an exception to the exception is needed here.

Nah, that's just me forgetting the exceptions. :) Thanks for reminding me.

FWIW an implementation is well underway, tracked at
https://bugs.webkit.org/show_bug.cgi?id=247394.

/Web developers/: Positive Google Sheets, which is currently
compiling Java to JavaScript, is experimenting with using
WasmGC to speed up their calculation engine. JetBrains is
working on a Kotlin -> WasmGC compiler. Dart is working on a
Dart -> WasmGC compiler, in collaboration with Flutter.

/Other signals/:

WebView application

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

2023-09-16 Thread Mike Taylor


LGTM2

On 9/16/23 8:22 AM, Yoav Weiss wrote:

LGTM1

Very neat!! That would definitely have simplified some testing code I 
recently wrote :)


On Fri, Sep 15, 2023 at 1:50 AM 'Shu-yu Guo' via blink-dev 
 wrote:



Contact emails

s...@chromium.org


Explainer

None


https://github.com/tc39/proposal-promise-with-resolvers/blob/main/README.md 
seems to be the explainer for this. (which I found useful)




Specification

https://tc39.es/proposal-promise-with-resolvers


Summary

Promise.withResolvers is a static methods that returns a new
Promise along with its resolver functions, i.e. `const { promise,
resolve, reject } = Promise.withResolvers()`. This is a standard
version of a common helper function found in many JS libraries.
Historically, some may know it as `defer` or `deferred`.



Blink component

Blink>JavaScript>Language




TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

Very little risk. This is a new static method on the Promise
constructor.



/Gecko/: Positive This is a Stage 3 TC39 proposal.

/WebKit/: Positive
(https://bugs.webkit.org/show_bug.cgi?id=259153) This is a Stage 3
TC39 proposal.

/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



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

Yes


Is this feature fully tested by web-platform-tests

?

In test262

.


Flag name on chrome://flags

--js-promise-withresolvers


Finch feature name

JavaScriptPromiseWithResolvers


Requires code in //chrome?

False


Estimated milestones

Shipping on desktop 119
DevTrial on desktop 117

Shipping on Android 119
DevTrial on Android 117



Anticipated spec changes

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

None


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5810984110784512


Links to previous Intent discussions



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

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

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAN-e9e-C0T4tV-8kOVfYZVG1nL9wXqK-twi-Tj3fFp3K8V398Q%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/CAL5BFfUAbkMkS6wuNiat9DJv1VCgz8es5wdbXMAQkydcdjoJ%2BQ%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/d4b87868-7193-4f74-bfd7-39c3e57aca0a%40chromium.org.

Re: [blink-dev] Intent to Prototype and Ship: Clip-path xywh() and rect() values

2023-09-16 Thread Mike Taylor

Cool - thanks for the answers. LGTM3.

On 9/16/23 6:23 AM, Yoav Weiss wrote:

LGTM2

On Sat, Sep 16, 2023, 02:20 'Philip Rogers' via blink-dev
wrote:

On Friday, September 15, 2023 at 1:19:06 PM UTC-7 Mike Taylor wrote:

On 9/11/23 7:18 PM, Philip Rogers wrote:

Contact emails p...@chromium.org

Explainer None

Specification
https://www.w3.org/TR/css-shapes/#supported-basic-shapes

Summary

Support the xywh() and rect() values on clip-path, which make
it easier to specify rectangular or rounded-rectangular clips.

Blink component Blink>Paint

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

Motivation

None

Initial public proposal None

TAG review None

Do you know if the TAG has reviewed this spec at all?

The TAG reviewed object-view-box (tag review
<https://github.com/w3ctag/design-reviews/issues/740>) which also
supports these values. These values are also
supported on other existing properties, such as offset-path.

TAG review status Not applicable

Risks

Interoperability and Compatibility

Low: this has shipped in Firefox.

/Gecko/: Shipped/Shipping

/WebKit/: No signal

Could we request a signal please?
https://github.com/WebKit/standards-positions/issues/new/choose

This should now be "WebKit: Shipping".
I didn't know it at the time I sent this intent, but WebKit was
actively working on this feature too, and just landed these
changes (see 一丝's reply, above). I've updated the chromestatus
entry to note that this landed in WebKit.

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

/Other signals/:

WebView application risks

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

None

Debuggability

This is debuggable with existing basic CSS tooling.

Is this feature fully tested by web-platform-tests

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

Flag name on chrome://flags None

Finch feature name ClipPathXYWHAndRect

Requires code in //chrome? False

Tracking bug https://crbug.com/1481015

Estimated milestones Shipping on desktop 119 Shipping on
Android 119 Shipping on WebView 119

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

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+...@chromium.org.
To view this discussion on the web visit

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

<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJgFLLvZuwE_Bqf8DkKoV8CZTwts8H_7ZdtjECp2cVgAx71Pow%40mail.gmail.com?utm_medium=email_source=footer>.

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

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

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/95a73775-2e66-4e14-a11c-3537153eb546n%40chromium.org

<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/95a73775-2e66-4e14-a11c-3537153eb546n%40chromium.org?utm_medium=email_source=footer>.

Re: [blink-dev] Intent to Ship: WebAssembly Garbage Collection (WasmGC)

2023-09-15 Thread Mike Taylor

On 9/12/23 9:22 PM, 'Emanuel Ziegler' via blink-dev wrote:

Dear API owners,

Following the continued experiment for Garbage Collected
WebAssembly (WasmGC), we plan to ship the feature in M119
after the positive vote to phase 4 by the WebAssembly
Community Group today.

The feature has shown very good performance with reasonable
compromises. The findings from the origin trial are summarized
in a public document

This feature is tied to the Function References
proposal
which is a de-facto part of WasmGC (no current use outside of
the proposal, hard requirement for WasmGC) and only listed as
a separate proposal for historic reasons. The Function
References proposal has therefore also been voted to phase 4
on the same day as WasmGC.

We plan to launch the feature in the following manner:

End the current origin trial with M118 as its last milestone

Refactor the binary instruction representation to match
the final spec (incompatible change)

Ship the feature with M119

This plan sounds good. Thx.

Our data from the trial has shown that there is a need for
fast string interoperability with JS that this proposal does
not address. We plan to launch a new experiment investigating
different approaches to this problem (see separate I2E mail).

Contact emails

ad...@chromium.org, jkumme...@chromium.org

Explainer

https://github.com/WebAssembly/gc/blob/master/proposals/gc/Overview.md
https://github.com/WebAssembly/function-references/blob/main/proposals/function-references/Overview.md

Specification

https://github.com/WebAssembly/gc/tree/main/proposals/gc

Summary

The GC proposal adds efficient support for high-level managed
languages to WebAssembly, via struct and array types that enable
language compilers targeting Wasm to integrate with a garbage
collector in the host VM. In Chrome, enabling this feature implies
enabling Typed Function References, which allow function references to
be stored in the aforementioned structs and arrays.

Blink component

Blink>JavaScript>WebAssembly

Search tags

wasm , webassembly
, gc
, managed objects
, wasmgc

TAG review

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

TAG review status

Issues addressed

Risks

Interoperability and Compatibility

/Gecko/: Positive

/WebKit/: No signal
Can we request a signal?
https://github.com/WebKit/standards-positions/issues/new/choose

/Web developers/: Positive Google Sheets, which is currently compiling
Java to JavaScript, is experimenting with using WasmGC to speed up
their calculation engine. JetBrains is working on a Kotlin -> WasmGC
compiler. Dart is working on a Dart -> WasmGC compiler, in
collaboration with Flutter.

/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

Can you say more about this?

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

Can you say more about this?

Is this feature fully tested by web-platform-tests

In this case, is this new feature covered by existing wasm test suites?

Flag name on chrome://flags

Finch feature name

None

Presumably this is behind a feature, if an Origin Trial occured, right?

Non-finch justification

The feature does not enable any functionality without the module being
explicitly compiled for that feature. We therefore chose to use an
origin trial to evaluate its suitability and stability. This allowed
websites that want to try this feature to opt in and do their own A/B
comparisons.

Requires code in //chrome?

False

Tracking bug

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

Launch bug

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

Estimated milestones

OriginTrial desktop last120
OriginTrial desktop first 112

OriginTrial Android last120

Re: [blink-dev] Intent to Prototype and Ship: Clip-path xywh() and rect() values

2023-09-15 Thread Mike Taylor


On 9/11/23 7:18 PM, Philip Rogers wrote:



Contact emails

p...@chromium.org


Explainer

None


Specification

https://www.w3.org/TR/css-shapes/#supported-basic-shapes


Summary

Support the xywh() and rect() values on clip-path, which make it 
easier to specify rectangular or rounded-rectangular clips.




Blink component

Blink>Paint 




Motivation

None



Initial public proposal

None


TAG review

None

Do you know if the TAG has reviewed this spec at all?



TAG review status

Not applicable


Risks



Interoperability and Compatibility

Low: this has shipped in Firefox.



/Gecko/: Shipped/Shipping

/WebKit/: No signal
Could we request a signal please? 
https://github.com/WebKit/standards-positions/issues/new/choose


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


/Other signals/:


WebView application risks

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


None



Debuggability

This is debuggable with existing basic CSS tooling.



Is this feature fully tested by web-platform-tests

?

Yes


Flag name on chrome://flags

None


Finch feature name

ClipPathXYWHAndRect


Requires code in //chrome?

False


Tracking bug

https://crbug.com/1481015


Estimated milestones

Shipping on desktop 119

Shipping on Android 119

Shipping on WebView 119



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5672616710373376

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/CAJgFLLvZuwE_Bqf8DkKoV8CZTwts8H_7ZdtjECp2cVgAx71Pow%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/0e9e9d17-03dd-4357-bee0-b3abaef351be%40chromium.org.

Re: [blink-dev] Intent to Ship: TLS Encrypted Client Hello (ECH)

2023-09-15 Thread Mike Taylor

On 9/11/23 6:34 PM, 'David Adrian' via blink-dev wrote:

Contact emails

david...@chromium.org, dadr...@google.com

Explainer

None

Specification

https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni

Summary

The TLS Encrypted ClientHello (ECH) extension enables clients to
encrypt ClientHello messages, which are normally sent in cleartext,
under a server’s public key. This allows websites to opt-in to avoid
leaking sensitive fields, like the server name, to the network by
hosting a special HTTPS RR DNS record. (Earlier iterations of this
extension were called Encrypted Server Name Indication, or ESNI.)

Blink component

Internals>Network>SSL

Search tags

ech , esni
, tls
, ssl

TAG review

Not applicable; this is a protocol under IETF

TAG review status

Not applicable

Risks

Interoperability and Compatibility

As a networking protocol, interoperability risks look different from a
web platform API: This is a draft of a developing protocol, so the
final standard will differ from what we ship now. We manage this as in
other protocol work: the draft uses different codepoints in the DNS
record and ClientHello, set up to not conflict with the final
standard. There is also a risk of breaking buggy servers or network
middleware. ECH is DNS-gated, so non-ECH servers won't be exposed to
ECH itself. We do implement ECH's GREASE mechanism (section 6.2 of the
draft), but this should appear as any normal unrecognized extension to
non-ECH servers. Servers and network elements that are compliant with
RFC 8446, section 9.3, should not be impacted. We will be monitoring
for these issues as part of the experiment, comparing error rates and
handshake times both for HTTPS servers as a whole, and the subset of
those that advertise ECH in DNS.

/Gecko/: In development
(https://blog.mozilla.org/security/2021/01/07/encrypted-client-hello-the-future-of-esni-in-firefox)

/WebKit/: No signal

Could we please request a signal?

https://github.com/WebKit/standards-positions/issues/new/choose

/Web developers/: Positive
(https://blog.cloudflare.com/encrypted-client-hello)

/Other signals/:

Ergonomics

ECH is part of TLS, so it is largely abstracted away from web platform
APIs themselves.

Activation

This is a network protocol and thus inherently requires server
software changes. It also requires keys deployed in the HTTPS DNS
record. At this stage in the process, we do not expect ECH to be
deployed beyond a few early adopters. Rather, this experiment is part
of real-world testing for the developing protocol. The connection with
the DNS record is of particular note. It is possible that, due to DNS
caching, etc., that the DNS record we fetch is out of sync with the
server instance we talk to. ECH has a built-in recovery mechanism to
repair these mismatches. One of the aims of the experiment will be to
validate this mechanism.

Security

See
https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-14#section-10
for security considerations in the specification

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 WebView-specific risks

Debuggability

Servers that use ECH are visible in the DevTools security panel.

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

Yes

While supported on all platforms, ECH requires keys fetched via DNS in
the new HTTPS record. Chrome can currently fetch the HTTPS record over
DoH and over our built-in DNS resolver.

Is this feature fully tested by web-platform-tests

Flag name on chrome://flags

encrypted-client-hello

Finch feature name

None

Non-finch justification

None

Requires code in //chrome?

False

Tracking bug

https://crbug.com/1091403

Launch bug

https://crbug.com/1349902

Availability expectation

Feature is also being launched in Firefox.

Sample links

https://tls-ech.dev

Estimated milestones

Shipping on desktop 117
OriginTrial desktop last116
OriginTrial desktop first 115
DevTrial on desktop 105

Shipping on Android 117
OriginTrial Android last116
OriginTrial Android first 115
DevTrial on Android 105

Anticipated spec changes

Open questions about a feature may

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

2023-09-15 Thread Mike Taylor


Thanks, LGTM1 pending the PRs landing.

On 9/12/23 12:29 AM, Caleb Raitto wrote:


Hi Mike,


Pull request 695 <https://github.com/WICG/turtledove/pull/695>is the 
change to update the explainer to describe the new header-based 
directFromSellerSignals, whereas 771 
<https://github.com/WICG/turtledove/pull/771>and 774 
<https://github.com/WICG/turtledove/pull/774>are for the spec changes.



The explainer change describes usage of the new API and provides 
context for the differences between header-based and the prior bundles 
based versions of directFromSellerSignals, whereas the spec change 
describes how to implement the header-based version.



We intend to land all 3 pull requests.


Thanks,

-Caleb

On Monday, September 11, 2023 at 11:18:26 AM UTC-4 Mike Taylor wrote:


On 9/11/23 12:55 PM, Mike Taylor wrote:


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


Hi Yoav, some responses inline:

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

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

Contact emails*

pauljen...@chromium.org


*Explainer*

https://github.com/WICG/turtledove/pull/69
<https://github.com/WICG/turtledove/pull/695>5

*


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

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


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


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


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


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


[0]

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

<https://github.com/WICG/turtledove/pull/695/files#diff-d65ba9778fe3af46de3edfce2266b5b035192f8869280ec07179963b81f4e624R465>


[1]

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

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


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

I maybe have just been confused. I'm not sure if 695 is intended
to land, beyond 771 and 774, both of which have much more recent
activity.



Thanks,

-Caleb

*
*Specification*

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

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


*Summary*

Protected Audience already supports a mechanism to
ensure the authenticity and integrity of information
passed into the auction from the seller called
directFromSellerSignals. Currently this is implemented
by the seller providing subresources in a WebBundle to
the browser, which after a year of testing has proved to
not be as efficient as originally planned. It either

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

2023-09-13 Thread Mike Taylor

LGTM3

On 9/13/23 5:46 PM, Daniel Bratell wrote:

LGTM2

/Daniel

On 2023-09-13 17:14, Philip Jägenstedt wrote:

LGTM1

If there is feedback on the TAG review or Mozilla issue while this
feature is on its way to stable, can you loop back to this thread?

On Thu, Sep 7, 2023 at 4:01 PM Philip Jägenstedt
wrote:

Thanks for investigating and fixing the failures, Koji!

On the UA defined rules, if other vendors are happy with the
examples used, then that's what matters in practice. If you do
get pushback on specific examples I hope there are others that
can be used that are a common ground.

I think everything looks good here, but since the TAG review and
Mozilla issue were filed recently, I'd like to give those a bit
more time.

On Thu, Sep 7, 2023 at 11:14 AM Koji Ishii
wrote:

I've got two updates on the questions:

On Thu, Sep 7, 2023 at 2:46 AM Koji Ishii
wrote:

Good point, thanks for asking.

Technically speaking, we can't write any tests because
the language-specific content analysis is UA defined.
Tests use common and easy words that most engines would
analyze the same way, but you're right that we may need
to modify tests if any engine analyzes them differently.

Tests contain that in comments, like this

or this

.
I'm also talking to WebKit about tests, since there are
currently two known engines; one in ICU and one in
macOS/iOS. We'll work together to ensure words in tests
are common and easy enough for both engines.

In case this helps, the situation is the same as hyphenation
tests. In the past, wpt tests needed updates when one
implementation hyphenates differently from other browsers. I
remember this happened at least once before.

Four tests failing is strange, thanks for pointing them
out too, they all pass in Chromium bots. I'll check them
and make sure they're all green before shipping.

I've figured them out, all fixes landed, I'll watch when
wpt.fyi will be updated. One was a recent spec change I
wasn't aware of, three were differences between wpt bots and
chromium bots (#41851
.)

Re: [blink-dev] Intent to Ship: Payment handler minimal header UX

2023-09-13 Thread Mike Taylor

LGTM1 (I'm not sure you need our approvals to ship this UX change, but
you can have mine).

On 9/8/23 7:09 PM, Rouslan Solomakhin wrote:

*Contact emails
*nbur...@chromium.org

*Explainer*
https://crbug.com/1385136 - see comment 14 for screenshot

*Specification*
Not applicable

*Design docs*
(Google internal only, sorry):
https://docs.google.com/document/d/1hCIzyBALzpFPuHQ_xCNvIpSrMThq8PA6Qgi0M2iF9vk/edit?resourcekey=0-VMUV90L2bb2OqlrBVepW4A#heading=h.bat9awopsp53

*Summary*
This is a refresh of the browser UI associated with the Payment
Handler API. There are no API changes. The origin trial is concluding
and we'd like to ship this feature in M119. See R2E <
https://groups.google.com/a/chromium.org/g/blink-dev/c/NQ-WLvfmPs8/m/hDKJNnmOBgAJ>
for more details.

*Blink component*
Blink>Payments

*TAG review*
Not applicable

*TAG review status*
Not applicable

*Risks*

*Interoperability and Compatibility*
None.

/Gecko: N/A/
/WebKit: N/A/

/Web developers: No signals/

/Other signals: No signals/

*WebView application risks*

/None/

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

*Debuggability*
N/A because it is a UI-only change.

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

No. Only desktop platforms - Windows, Mac, Linux, Chrome OS.

*Is this feature fully tested by web-platform-tests?*
No, because this is a UI-only change.

*Flag name*
PaymentHandlerMinimalHeaderUX

*Finch feature name*
None

*Non-finch justification*
None

*Requires code in //chrome?*
True

*Estimated milestones*
Shipping on desktop: 119

*Anticipated spec changes*
N/A, because there is no spec for a UI-only change.

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

*Links to previous Intent discussions*
Intent to Experiment:
https://groups.google.com/a/chromium.org/g/blink-dev/c/NQ-WLvfmPs8/m/hDKJNnmOBgAJ

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/CAMMzaWEp6JQOKeYBjkhGa_w%3DQvDuEOPZu590FrDLj3%2Bg2eWQWQ%40mail.gmail.com
.

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

2023-09-11 Thread Mike Taylor



On 9/11/23 12:55 PM, Mike Taylor wrote:


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


Hi Yoav, some responses inline:

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

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

Contact emails*

pauljen...@chromium.org


*Explainer*

https://github.com/WICG/turtledove/pull/69
<https://github.com/WICG/turtledove/pull/695>5

*


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

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


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



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



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


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



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



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


Thanks for the explanation - what's preventing 
https://github.com/WICG/turtledove/pull/695 from landing? It seems 
rather old (and references stuff that no longer exists, like 
`X-FLEDGE-Auction-Only`. (It also doesn't seem to define any 
error-handling for parsing the JSON that a server returns, which would 
be good to do.)
I maybe have just been confused. I'm not sure if 695 is intended to 
land, beyond 771 and 774, both of which have much more recent activity.


Thanks,

-Caleb

*
*Specification*

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

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


*Summary*

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


*Blink component*

Blink>InterestGroups

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


*TAG review*

The parent proposal, Protected Audience, is still pending:
https://github.com/w3ctag/design-reviews/issues/723
<https://github.com/w3ctag/design-reviews/issues/723>


*TAG review status*

Pending


*Risks*
*

Interoperability and Compatibility

*

None as this is an optional new way of providing
directFromSellerSignals.  It cannot be used jointly
with the old mechanism, but there shouldn’t be a

Re: [blink-dev] Intent to Extend Experiment: Speculation Rules - Document rules, response header

2023-09-11 Thread Mike Taylor

LGTM to extend from 119 to 120 (inclusive).

On 9/11/23 12:45 PM, Domenic Denicola wrote:

Contact emails

jbro...@chromium.org ,
adith...@chromium.org ,
dome...@chromium.org

Explainer

https://github.com/WICG/nav-speculation/blob/main/triggers.md#document-rules

Specification

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

Summary

Two enhancements to speculation rules-based speculative loading, under
a combined experiment:

An extension to speculation rules syntax that lets the browser obtain
URLs for speculation from link elements in a page. They may include
criteria which restrict which of these links can be used.

Currently developers can only specify speculation rules using inline
script tags. The proposed feature provides an alternative through the
"Speculation-Rules" header. Its value must be a URL to a text resource
with "application/speculationrules+json" MIME type. The resource's
rules will be added to the document's rule set.

Blink component

Internals>Preload

TAG review

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

TAG review status

Complete at this time. TAG has reservations about whether the use
cases of this feature justify its complexity, as compared to a simpler
solution which would address some but not all of the use cases.

Chromium Trial Name

SpeculationRulesPrefetchFuture

Link to origin trial feedback summary

https://docs.google.com/document/d/13cJcoygFD64UcQH-P30dXCLbdD6SXpQwhpOUym64KXw/edit?usp=sharing

Origin Trial documentation link

https://github.com/WICG/nav-speculation/blob/main/chrome-2023q1-experiment-overview.md

WebFeature UseCounter name

SpeculationRulesDocumentRules

Risks

Interoperability and Compatibility

Because authors cannot rely on document rules being evaluated (or
preloading generally), applications which use them should function
correctly in other browsers and should continue to function correctly
were the feature to be deprecated. Of course, ideally other browsers
do find it compelling to implement this feature.

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

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

Web developers: Strongly positive on document rules from various
sources; recent positive feedback from one partner on the response
header. See origin trial feedback summary for more details.

Activation

Some developers might not be immediately aware of which URLs they can
prefetch or prerender without side effects; this risk is reduced if
they primarily use the feature for same-origin URL patterns they are
familiar with.

Security

Seehttps://wicg.github.io/nav-speculation/speculation-rules.html#security-considerations
.

WebView application risks

None that are specifically anticipated.

Reason this experiment is being extended

Document rules have proven a lot of value. However, we have a few
minor breaking changes we'd like to make over the next couple of
milestones before shipping them unrestricted.

The response header-based delivery of speculation rules has only
recently started being used, as the partner which originally requested
it shifted priorities. Now that experimentation with it has begun in
earnest, we'd like to give it a few milestones of testing before
sending an Intent to Ship.

Ongoing technical constraints

At this time the constraints are believed to be minimal.

Debuggability

Speculative loading which occurs is visible in the Network panel and
the new Preloading panel. Console warnings are logged when several
types of issues are encountered.

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

Yes

Is this feature fully tested by web-platform-tests

Yes

Finch feature name

SpeculationRulesPrefetchFuture

Requires code in //chrome?

False

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

2023-09-11 Thread Mike Taylor


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


Hi Yoav, some responses inline:

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

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

Contact emails*

pauljen...@chromium.org


*Explainer*

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

*


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

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


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



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



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


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



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




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



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


Thanks,

-Caleb

*
*Specification*

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


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



*Summary*

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


*Blink component*

Blink>InterestGroups




*TAG review*

The parent proposal, Protected Audience, is still pending:
https://github.com/w3ctag/design-reviews/issues/723



*TAG review status*

Pending


*Risks*
*

Interoperability and Compatibility

*

None as this is an optional new way of providing
directFromSellerSignals.  It cannot be used jointly
with the old mechanism, but there shouldn’t be a need
to use the old mechanism.

*

*
*

*

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

Re: [blink-dev] IP Protection feature status

2023-09-09 Thread Mike Taylor


Hi David,

I just set it to "In Development".

thanks,
Mike

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

Hello.

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


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


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


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

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

2023-09-08 Thread Mike Taylor

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

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

Contact emails

jkoka...@google.com

Specification

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

Summary

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

Blink component

Blink>SecurityFeature

Motivation

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

Initial public proposal

None

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

None

Gecko: Positive

WebKit: Shipped/Shipping

Web developers: No signals

Other signals:

WebView application risks

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

None

Debuggability

None

Is this feature fully tested by web-platform-tests

Yes

Flag name on chrome://flags

None

Finch feature name

None

Non-finch justification

None

Requires code in //chrome?

False

Tracking bug

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

Estimated milestones

119

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5073969773805568

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

2023-09-08 Thread Mike Taylor

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

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

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

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

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

LGTM1 to ship.

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

2023-09-06 Thread Mike Taylor


LGTM2

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


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




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


Contact emails

fbeauf...@google.com 

elada...@google.com 


Explainer


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




Specification


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




Summary

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


Blink component

Blink>GetDisplayMedia




TAG review

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



TAG review status

Pending


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


Risks


Interoperability and Compatibility

None


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


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

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

.


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

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




Other signals:


WebView application risks

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

None



Debuggability

None


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

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


Is this feature fully tested by web-platform-tests

?

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


Flag name on chrome://flags

None


Finch feature name

MonitorTypeSurfaces


Requires code in //chrome?

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


Tracking bug

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



Estimated milestones

Shipping on desktop



119


Anticipated spec changes

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

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

2023-09-06 Thread Mike Taylor


LGTM2

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

LGTM1

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

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

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

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



Contact emails

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


Explainer


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


Specification


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


Summary

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



Blink component

Blink>CSS




Search tags

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

,
prefers-reduced-transparency



TAG review


Anything relevant to link here?



TAG review status

Pending


Risks



Interoperability and Compatibility



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

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

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

/Other signals/:


Activation

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



Security

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



WebView application risks

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



Debuggability

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



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

Yes

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



Is this feature fully tested by web-platform-tests

?

Yes


Flag name on chrome://flags

#enable-experimental-web-platform-features


Finch feature name

ClientHintsPrefersReducedTransparency


Requires code in //chrome?

False


Tracking bug

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


Sample links


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


Estimated milestones

Shipping on desktop 118
DevTrial on desktop 118

Shipping on Android 118
DevTrial on Android 118



Anticipated spec changes

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

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

2023-09-05 Thread Mike Taylor


LGTM2

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

LGTM1



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


Hi, sorry for the long delay.

The feature page

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


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



Thanks,

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

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

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

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

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

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

Sounds great, thanks!! :)

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

Hi Yoav,

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

Thanks,


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

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

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

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

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

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

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

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

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

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

2023-09-01 Thread Mike Taylor


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


Thanks Mike! Responses inline.

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

Hi Shivani,

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

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



Contact emails

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


Explainer

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


A few questions about the attestation format:

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

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

Also, how does unenrollment happen?

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




Design document


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

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


Specification

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


Private aggregation (section with note on enrollment

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


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

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

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

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


Summary and Motivation

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

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


Blink component

Blink>PrivateAggregation

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

Blink>Storage>SharedStorage

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

Blink>TopicsAPI

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

Internals > AttributionReporting

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

Blink>InterestGroups

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


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

Supported on all the above platforms except Android WebView.

In the initial version, no

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

2023-09-01 Thread Mike Taylor


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



Contact emails

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


Explainer

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


Specification

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


Summary

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




Blink component

Blink>CSS 




Search tags

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




TAG review


Anything relevant to link here?



TAG review status

Pending


Risks



Interoperability and Compatibility



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


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


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


/Other signals/:


Activation

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




Security

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




WebView application risks

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




Debuggability

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




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

Yes

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




Is this feature fully tested by web-platform-tests

?

Yes


Flag name on chrome://flags

#enable-experimental-web-platform-features


Finch feature name

ClientHintsPrefersReducedTransparency


Requires code in //chrome?

False


Tracking bug

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


Sample links


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


Estimated milestones

Shipping on desktop 118
DevTrial on desktop 118

Shipping on Android 118
DevTrial on Android 118



Anticipated spec changes

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




Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6242983812268032


Links to previous Intent discussions

Intent to prototype: 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/B1ED49A6-31BF-4D28-89B3-D2973F9F12DA%40gmail.com


This intent message was generated by Chrome Platform Status 
.

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

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

2023-09-01 Thread Mike Taylor


Hi David,

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


thanks,
Mike

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



Contact emails

dadr...@google.com


Explainer

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


Specification

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


Summary

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




Blink component

Internals>Network>SSL 




Search tags

tls , kem 
, kyber 
, postquantum 




TAG review



TAG review status

Pending


Risks



Interoperability and Compatibility

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



Any pointers to learn more about this possible compat problem?



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


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


/Web developers/: No signals

/Other signals/:


WebView application risks

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




Goals for experimentation

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

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



Ongoing technical constraints



Debuggability



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

Yes


Is this feature fully tested by web-platform-tests

?

No


Flag name on chrome://flags

enable-tls13-kyber


Finch feature name

PostQuantumKyber


Requires code in //chrome?

False


Tracking bug

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


Launch bug

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


Estimated milestones

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

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

Shipping on WebView 119



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5257822742249472


Links to previous Intent discussions

Intent to prototype: 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGkh42%2BgKeCTA6vWwzrE%3DDVR%3DTmQaCyDFQxqnXkOy9GcVyGtnA%40mail.gmail.com


This intent message was generated by Chrome Platform Status 
.

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


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

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

2023-09-01 Thread Mike Taylor

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

LGTM1 to ship.

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

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

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

Hi Daniel,

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

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

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

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

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

Hope this answers your questions,
Garrett

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

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

2023-09-01 Thread Mike Taylor


Hi Shivani,

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


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



Contact emails

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



Explainer

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




A few questions about the attestation format:

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


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


Also, how does unenrollment happen?



Design document

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




Specification

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



Private aggregation (section with note on enrollment 
) 



Shared Storage (pull request 
)


Topics (pull request 
)


Attribution reporting API (pull request 
)


Protected Audience (pull requests: 1 
, 2 
)



Summary and Motivation

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



Blink component

Blink>PrivateAggregation 



Blink>Storage>SharedStorage 



Blink>TopicsAPI 



Internals > AttributionReporting 



Blink>InterestGroups 




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


Supported on all the above platforms except Android WebView.

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



Debuggability


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


Is integration with the Reporting API also planned?


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


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

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



Initial public proposal

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




TAG review

Private Aggregation (comment 
)


Shared Storage (comment

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

2023-09-01 Thread Mike Taylor


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


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



Contact emails

ko...@chromium.org


Explainer

None


Specification

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


Design docs


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


Summary

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




Blink component

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



TAG review

None


TAG review status

Not applicable

Any reason to not request a TAG review?

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



Risks



Interoperability and Compatibility



/Gecko/: No signal

Can we request one?


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


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


/Other signals/:


WebView application risks

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


No.



Debuggability



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

Yes


Is this feature fully tested by web-platform-tests

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

Yes


Flag name on chrome://flags



Finch feature name



Non-finch justification

None


Requires code in //chrome?

False


Tracking bug

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


Sample links


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


Estimated milestones

Shipping on desktop 119

Shipping on Android 119

Shipping on WebView 119



Anticipated spec changes

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




Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5133892532568064


Links to previous Intent discussions

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


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

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


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

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

2023-09-01 Thread Mike Taylor


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



Contact emails

ko...@chromium.org


Explainer

None


Specification

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


Design docs


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


Summary

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




Blink component

Blink>Layout>Inline 




TAG review

None


TAG review status

Not applicable

Any reason to not request a TAG review?



Risks



Interoperability and Compatibility



/Gecko/: No signal

Can we request one?


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


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


/Other signals/:


WebView application risks

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


No.



Debuggability



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

Yes


Is this feature fully tested by web-platform-tests

?

Yes


Flag name on chrome://flags



Finch feature name



Non-finch justification

None


Requires code in //chrome?

False


Tracking bug

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


Sample links


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


Estimated milestones

Shipping on desktop 119

Shipping on Android 119

Shipping on WebView 119



Anticipated spec changes

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




Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5133892532568064


Links to previous Intent discussions

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


This intent message was generated by Chrome Platform Status 
.

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


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

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

2023-09-01 Thread Mike Taylor


No issues, thanks for the update.

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


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

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

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

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

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

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

Is it available in CSS media queries?

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


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



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

LGTM to experiment M116-122 (inclusive)

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


Contact emails

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



Explainer


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


Specification

None


Summary

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



Blink component

Blink>AppManifest




TAG review

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


TAG review status

Pending


Risks



Interoperability and Compatibility



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

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

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

/Other signals/:


WebView application risks

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

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



Goals for experimentation

Gather feedback on the API design.


Ongoing technical constraints



Debuggability

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



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

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


Is this feature fully tested by
web-platform-tests

?

No


Flag name on chrome://flags

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


Finch feature name

None


Non-finch justification

None


Requires code in //chrome?

True


Tracking bug

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

2023-09-01 Thread Mike Taylor


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



Contact emails

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


Explainer

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


Specification

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


Design docs

N/A


Summary

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




Blink component

Blink>Layout 




Motivation

None



Initial public proposal

None


Search tags

css , forms 
, form-sizing 




TAG review

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



TAG review status

Issue open


Risks



Interoperability and Compatibility



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


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


/Web developers/: No signals

/Other signals/:


WebView application risks

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


None



Debuggability

None



Is this feature fully tested by web-platform-tests

?

Yes, it should be.


Flag name on chrome://flags

None


Finch feature name

None


Non-finch justification

None


Requires code in //chrome?

False


Tracking bug

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


Estimated milestones

No milestones specified



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5176596826161152

This intent message was generated by Chrome Platform Status 
.


--
TAMURA Kent
Software Engineer, Google


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


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

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

2023-08-31 Thread Mike Taylor

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


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


Hi,

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


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


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


Hello,

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


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


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


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


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


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




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


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


Thanks,
Nicolò Ribaudo

--
You received this message because you are subscribed to the Google 
Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, 
send an email to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/192d117b-b2b9-4835-a6bd-bf5e49b64757n%40chromium.org 
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/192d117b-b2b9-4835-a6bd-bf5e49b64757n%40chromium.org?utm_medium=email_source=footer>.


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

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

2023-08-28 Thread Mike Taylor

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

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

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

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

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

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

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

Thanks for working on this important problem!

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

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

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

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

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

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

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

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

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

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

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

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

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

Christian

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

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

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

Contact emails

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

Explainer

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

Specification

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

Summary

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

Blink component

Privacy>NavTracking

TAG review

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

TAG review status

Issues addressed

Risks

Interoperability and Compatibility

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

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

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

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

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

2023-08-28 Thread Mike Taylor

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

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

Thank you!

☆*PhistucK*

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

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

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

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

☆*PhistucK*

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

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

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

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

☆*PhistucK*

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

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

> along with other form-related ones

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

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

Sounds good!

> Debuggability

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

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

image.png

☆*PhistucK*

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

Contact emailsjar...@chromium.org

ExplainerNone

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

Summary

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

Blink componentBlink>CSS

TAG reviewNone

TAG review statusNot applicable

Risks

Interoperability and Compatibility

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

/Gecko/: Shipped/Shipping

/WebKit/: Shipped/Shipping

/Web developers/: No signals

/Other signals/:

Ergonomics

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

Activation

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

Security

There are no security risks for this feature.

WebView application risks

Does this intent deprecate or change

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

2023-08-28 Thread Mike Taylor


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


Hello,

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


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


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


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


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


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




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


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


Thanks,
Nicolò Ribaudo

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


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

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

2023-08-23 Thread Mike Taylor


LGTM3

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

LGMT2

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

LGTM1

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



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



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


Contact emails


*

andr...@chromium.org


*


Specification


*

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



*


Summary


*

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


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


div {

  view-timeline-inset: 10px;

  view-timeline: mytimeline;

}


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


Use-counters:

 *

view-timeline: ~0.015%



 *

view-timeline-inset: ~0.019%



 *

No sample sites at the time of writing.


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


1 https://store.marketwatch.com/

2 https://www.inbank.it/

3 https://store.thetimes.ie/

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

5 https://www.gameort.com/

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

7 https://assinaturaglobo.globo.com/

8 https://mobile.thestar.com/

9 https://readerschoice.thestar.com/

10 https://sourcingjournal.com/

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

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


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


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



*


Blink component


*

Blink>Animation




*


TAG review


*

None


*


TAG review status


*

Not applicable


*


Risks


*

*


Interoperability and Compatibility


*

None



Gecko: No signal


WebKit: No signal

*



Are we the first to implement this spec change?


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

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


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

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

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

2023-08-23 Thread Mike Taylor

LGTM1

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

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

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

Thanks, Mathias.

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

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

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

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

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

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

With that said...

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

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

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

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

2023-08-23 Thread Mike Taylor

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


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

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

And the relevant source files:

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

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


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


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

Hello Kyra,

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

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

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

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

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

Thank you,

Junji

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

Hi all,

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

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

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

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

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

Thanks!

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

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

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

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

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

thanks,
Mike

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

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

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

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

2023-08-22 Thread Mike Taylor

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

1.

Firefox: 30 calendar days.

2.

Chrome: 30 calendar days.

3.

Safari: 30 days of browser usage.

2.

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

1.

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

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

2.

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

3.

Safari: always

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


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

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

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

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

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

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


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

Contact emails

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


Explainer


https://github.com/privacycg/storage-access/blob/main/README.md

<https://github.com/privacycg/storage-access/blob/main/README.md>


https://github.com/cfredric/chrome-storage-access-api/blob/main/README.md

<https://github.com/cfredric/chrome-storage-access-api/blob/main/README.md>


Specification

https://privacycg.github.io/storage-access
<https://privacycg.github.io/storage-access>


Summary

The Storage Access API provides a means
for authenticated cross-site embeds to
check whether access to unpartitioned
cookies is blocked and request access if
it is blocked. This request may be

Re: [blink-dev] Intent to Ship: Opaque Response Blocking (ORB, aka CORB++) v0.2

2023-08-22 Thread Mike Taylor


LGTM3

On 8/22/23 10:37 AM, Yoav Weiss wrote:

LGTM2

On Wed, Aug 16, 2023 at 7:23 PM Chris Harrelson 
 wrote:


LGTM1 to turn it on in M118 beta and report back to this group
about use counter results/bugs reported on beta before it reaches
stable.

On Fri, Aug 11, 2023 at 2:50 AM 'Daniel Vogelheim' via blink-dev
 wrote:

On Wed, Jul 26, 2023 at 11:29 AM Yoav Weiss
 wrote:

On Tue, Jul 25, 2023 at 6:48 PM Daniel Vogelheim
 wrote:

On Tue, Jul 25, 2023 at 9:10 AM Yoav Weiss
 wrote:

On Mon, Jul 24, 2023 at 7:27 PM Daniel Vogelheim
 wrote:

On Mon, Jul 24, 2023 at 5:55 PM Yoav Weiss
 wrote:

On Mon, Jul 24, 2023 at 5:44 PM Daniel
Vogelheim  wrote:

On Mon, Jul 24, 2023 at 5:24 PM Yoav
Weiss  wrote:

On Fri, Jul 21, 2023 at 5:53 PM
'Daniel Vogelheim' via blink-dev
 wrote:


Contact emails

vogelh...@chromium.org


Specification


https://github.com/whatwg/fetch/pull/1442


Summary

Opaque Response Blocking (ORB)
is a replacement for
Cross-Origin Read Blocking
(CORB -

https://chromestatus.com/feature/5629709824032768).
CORB and ORB are both
heuristics that attempt to
prevent cross-origin
disclosure of “no-cors”
subresources. This entry
tracks "v0.2" of ORB -
Chrome's second step towards a
full ORB implementation. ORB
specifies error handling for
blocked resources differently
from CORB: ORB raises network
errors, while CORB injects an
empty response. ORB "v0.1"
still used CORB-style response
injection. This change brings
our implementation more in
line with the ORB proposal, by
changing the error handling of
all fetches (except when
initiated by a script) to be
compliant with ORB. We've made
a carve-out for
script-initiated fetches
(where we retain CORB
behaviour for now) to limit
compatibility risk.



Blink component

Internals>Sandbox>SiteIsolation




TAG review

None
(A TAG review of a particular
aspect happened

in:https://github.com/w3ctag/design-reviews/issues/618)


TAG review status

Not applicable


Risks


Interoperability and
Compatibility

This release does not modify
blocking behaviour, but only
how a blocked resource is
represented. Ideally, this
change shouldn't break any
existing code since any
resource that loads (or gets

Re: [blink-dev] Intent to Ship: HTML search element

2023-08-22 Thread Mike Taylor


LGTM2

On 8/22/23 10:29 AM, Yoav Weiss wrote:

LGTM1

Thanks for catching us up here! :)


On Thu, Aug 17, 2023 at 5:31 AM Vladimir Levin  
wrote:




On Wed, Aug 16, 2023 at 4:37 PM Joey Arhar 
wrote:


Contact emails

jar...@chromium.org


Explainer

None


Specification


https://html.spec.whatwg.org/multipage/grouping-content.html#the-search-element


Summary

The  element applies a "search" role for
accessibility. It is basically the same as .
From the HTML spec: The search element represents a part of a
document or application that contains a set of form controls
or other content related to performing a search or filtering
operation. This could be a search of the web site or
application; a way of searching or filtering search results on
the current web page; or a global or Internet-wide search
function.



Blink component

Blink>HTML




TAG review

None


TAG review status

Not applicable


FYI, there has already been a (satisfied with concerns) TAG review
for this: https://github.com/w3ctag/design-reviews/issues/714



Risks



Interoperability and Compatibility

There is minimal compat risk for this. Even if a website is
erroneously already using  tags, there likely won't be
any difference in behavior.



/Gecko/: Shipped/Shipping
(https://bugzilla.mozilla.org/show_bug.cgi?id=1824121)

/WebKit/: Shipped/Shipping
(https://github.com/WebKit/WebKit/pull/13887)

/Web developers/: No signals

/Other signals/:


Ergonomics

There are no other platform APIs this feature will be used in
tandem with. The default usage of this API will not make it
hard for chrome to maintain good performance.



Activation

It will not be challenging for developers to take advantage of
this feature immediately. I don't think that
polyfills/documentation/outreach is needed for this feature.



Security

This feature does not have any security or privacy implications.



WebView application risks

Does this intent deprecate or change behavior of existing
APIs, such that it has potentially high risk for Android
WebView-based applications?

This has no risk for WebView.



Debuggability

The DevTools accessibility panel will show the new
accessibility role associated with search elements.



Will this feature be supported on all six Blink
platforms (Windows, Mac, Linux, Chrome OS, Android,
and Android WebView)?

Yes


Is this feature fully tested by web-platform-tests

?

Yes


Flag name on chrome://flags

HTMLSearchElement


Finch feature name

HTMLSearchElement


Requires code in //chrome?

False


Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1294294


Availability expectation

This feature has already been implemented in firefox and
webkit, so it will be available immediately.


Adoption expectation

This feature has already been implemented in firefox and
webkit, so it will be available immediately.


Adoption plan

No actions are needed because this feature has already shipped
in firefox and safari.


Estimated milestones

Shipping on desktop 118
DevTrial on desktop 118

Shipping on Android 118
DevTrial on Android 118

Shipping on WebView 118



Anticipated spec changes

Open questions about a feature may be a source of future web
compat or interop issues. Please list open issues (e.g. links
to known github issues in the project for the feature
specification) whose resolution may introduce web
compat/interop risk (e.g., changing to naming or structure of
the API in a non-backward-compatible way).

There are no open spec issues for the search element.


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5126108151808000

This intent message was generated by Chrome Platform Status
.
-- 
You received this message because you are subscribed to the

Google Groups

Re: [blink-dev] Intent to Implement & Ship: AudioEncoderConfig.bitrateMode

2023-08-22 Thread Mike Taylor

LGTM2

On 8/22/23 10:10 AM, Yoav Weiss wrote:
LGTM1. Mirroring video codecs makes sense. Glad to see Mozilla being
supportive.

On Thu, Aug 17, 2023 at 8:51 PM 'Thomas Guilbert' via blink-dev
wrote:

Contact emails

tguilb...@google.com

Explainer

None

Specification

https://w3c.github.io/webcodecs/#dom-audioencoderconfig-bitratemode

Summary

Some audio codecs support specifying the audio encoder bitrate
modes. This feature adds a "bitrateMode" flag with a default value
of “variable” to WebCodec's AudioEncoderConfig, which mirrors the
functionality already present for VideoEncoderConfig
.

This flag will allow web authors to choose between encoding audio
with a variable bitrate or a constant bitrate. Specific codec
encoder implementations might have slightly different terminology
(e.g. `CBR` vs `VBR` for Opus), but all of them should map to the
general concept of "constant" versus "variable" bitrate.

The two options have the following effects:

“variable”: allows an audio encoder to increase or lower its
bitrate according to the content of the audio it is encoding,
in order to preserve bandwidth/binary-size, while still
maintaining a target quality. For example, an encoder might
lower its bitrate when encoding silence, and revert to a full
bitrate when encoding speech.

“constant” : forces an audio encoder to maintain the same
bitrate, regardless of the audio content. This can be useful
when a predictable bandwidth consumption is preferable.

As of M118, this flag will affect two codecs on Chromium: Opus and
AAC.

Blink component

Blink>Media>WebCodecs

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

The risk is low. Firefox has not yet shipped WebCodecs, but is
currently developing it. Safari has developed video WebCodecs, but
not yet audio. The flag should be easy for other browsers to add
as they implement WebCodecs.

Gecko: Positive
(https://github.com/mozilla/standards-positions/issues/837
)

WebKit: No signal
(https://github.com/WebKit/standards-positions/issues/218
)

Web developers: Positive, as feature was originally a developper
request – https://github.com/w3c/webcodecs/issues/649

Other signals:

WebView application risks

This change does not deprecate existing APIs, and only supplements
existing APIs, with a sensible default. This should not be a
WebView risk.

Debuggability

Will this feature be supported on all six Blink platforms
(Windows, Mac, Linux, Chrome OS, Android, and Android
WebView)?

Yes

Is this feature fully tested by web-platform-tests

It will be at the time it is implemented. Example test

Flag name on chrome://flags

N/A

Finch feature name

N/A

Non-finch justification

Simple parameter change

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1462467

Estimated milestones

Shipping on desktop

118

Shipping on Android

118

Anticipated spec changes

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5084320053592064

--
You received this message because you are subscribed to the Google

Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABrVPoak2%3DgxnREAhxe83D-BpSD0xF%3DnRFDbSiS8qrF0ZBQB7A%40mail.gmail.com

Re: [blink-dev] Intent to Ship: Baselines in New TextMetrics API in Canvas

2023-08-21 Thread Mike Taylor

LGTM1

On 8/21/23 1:52 PM, Yi Xu wrote:

Hi Yoav,

In first attempt link
,
we tried to ship all the attributes under TextMetrics API (in 2018).
Some definitions were not clear so we was not able to do it.
In second attempt
,
we shipped
actualBoundingBoxLeft, actualBoundingBoxRight, fontBoundingBoxAscent,
fontBoundingBoxDescent, actualBoundingBoxAscent,
actualBoundingBoxDescent, emHeightAscent and emHeightDescent.
In third attempt
,
we shipped fontBoundingBoxAscent, fontBoundingBoxDescent
In this attempt, we are trying to ship alphabeticBaseline,
hangingBaseline and ideographicBaseline. Note that both Safari and
firefox have shipped it, so we will like to catch up on this.

Thank you,

Yi Xu

On Sun, Aug 20, 2023 at 10:40 PM Yoav Weiss
wrote:

On Fri, Aug 18, 2023 at 8:25 PM Yi Xu wrote:

Contact emails

yi...@chromium.org, aaro...@chromium.org, fs...@chromium.org

Explainer

https://learn.microsoft.com/en-us/typography/opentype/spec/baselinetags

Specification

https://html.spec.whatwg.org/multipage/canvas.html#textmetrics
we are launching the following attributes in TextMetrics:
alphabeticBaseline, hangingBaseline and ideographicBaseline

*Tag Review*
https://github.com/w3ctag/design-reviews/issues/302

Summary

This is the 4th installment in extending the TextMetrics API
(first attempt link

,
second
attempt
,
third attempt)

.The
current canvas TextMetrics API exposes the actualBoundingBox
and the fontBoundingBox readings. The definition of baseline
is more clear now. Both Firefox and Safari have already
shipped this *extension to TextMetrics*.

Thanks for pushing through this!! Any details on why the past
attempts weren't successful?

The original feature bug (https://crbug.com/277215
) has strong user support (23 stars).

Blink component

Blink>Canvas

Is this feature supported on all six Blink platforms (Windows,
Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Is this feature fully tested byweb-platform-tests

?
Link to test suite results fromwpt.fyi
.

https://wpt.fyi/results/html/canvas/element/text/2d.text.measure.baselines.html?label=experimental=master

Entry on thefeature dashboard

https://chromestatus.com/feature/6516079022571520

Risks

Interoperability and Compatibility

Safari and Firefox have has already shipped these metrics in
the spec.

Firefox:Shipped

Safari:Shipped

We know this is a feature requested by developers (as well as
internal Google teams like Google Docs). This API will help
developers have more control and more accurate text rendering.
As of today a different way to achieve this is by using
rendering text to the DOM and using getBoundingClientRect to
get some measurements. This process requires a relayout of the
page.

Activation

Enable the platform experiment ExtendedTextMetrics

--
You received this message because you are subscribed to the

Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from
it, send an email to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAC3hXJeKqXo9QKyreEM%2BqiNM0gi_us%3DWZ_-17AxpMg-bF%2BoLkA%40mail.gmail.com

< 1 2 3 4 5 6 7 8 9 >

301 - 400 of 854 matches

Mail list logo