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

[Mike West]

Hey Łukasz,

I'm in favor of shipping this change. It will harden our defenses against
side-channel attacks at minimal web-visible cost, and clear a path for a
WebKit implementation that some folks have expressed interest in (see the CORB
thread on webkit-dev@
).
That said, I have two questions:

   1. The ORB telemetry results - Mar 2022
   

document
   suggests a substantially smaller impact than the 0.01% number you mention a
   few times in this intent: 0.002% - 0.006% (it would be ideal if you could
   create a public version of that document :) ). Can you help me understand
   the distinctions between those measurements?

   2. The current specification situation is confusing.
   https://fetch.spec.whatwg.org/#corb doesn't match what Chrome does, and
   https://github.com/annevk/orb doesn't match what this v0.1
   implementation does. Is there something we can point developers to which
   would explain Chrome's behavior once we ship this initial stab at ORB?

Thanks!

-mike


On Mon, May 9, 2022 at 8:26 PM Łukasz Anforowicz 
wrote:

> On Fri, May 6, 2022 at 4:45 PM Mike Taylor  wrote:
>
>> Hi there,
>>
>> While we review this, can we ask WebKit for a signal? (
>> bit.ly/blink-signals).
>>
>
> Done - see:
> https://lists.webkit.org/pipermail/webkit-dev/2022-May/03.html
>
>
>> Also, https://github.com/w3ctag/design-reviews/issues/618 is the TAG
>> review for this, correct?
>>
>
> Not quite.  This was a review of just one aspect of ORB - having a list of
> MIME types for which it is never allowed to have a response in mode=no-cors
> (this aspect is shared across ORB and CORB) .  OTOH some comments in this
> review
> 
> did highlight that ORB has no impact on behavior and
> functionality (assuming HTTP responses use correct `Content-Type`).
>
> For now, I assume that no additional reviews are needed given that
>
>- No new API surface
>- No behavior change if HTTP responses use correct `Content-Type`.
>- If an incorrect or inaccurate `Content-Type` is used, then ORB v0.1
>introduces minimal change in behavior compared to CORB (blocking additional
>0.01% of HTTP responses;  see the original email for more details and
>examples).
>
> FWIW, since ORB does cause known changes in 0.01% of HTTP responses, we
> thought that an official intent-to-ship route is the safest path going
> forward.  OTOH, feel free to guide us toward another process if needed -
> e.g. maybe an argument can be made to use the "web developer facing
> change to existing code
> "
> path instead.
>
> Thanks,
>
> -Lukasz
>
>
>> On 5/5/22 2:02 PM, Łukasz Anforowicz wrote:
>>
>> Hello!
>>
>> The goal of this email is to:
>>
>>- Seek LGTMs from Blink API owners for the intent to ship ORB v0.1
>> in Chrome M103.
>>A formal, semi-automatically-generated intent-to-ship data can be found at
>>the end of this email.
>>- Provide an overview of ORB, motivations for shipping it, and its
>>(low) risks.
>>- Highlight scenarios where web developers might want to double-check
>>the MIME types used by their HTTP servers when serving certain resources.
>>
>>
>> *Overview of ORB*
>>
>> Opaque Response Blocking (ORB) is a replacement for Cross-Origin Read
>> Blocking (CORB).  CORB and ORB are both heuristics that attempt to prevent
>> cross-origin disclosure of “no-cors” subresources.  An example attack that
>> ORB and CORB prevent is where an attacker’s frame contains > https://victim.example.com/secret.json”> which an attacker reads using
>> either Spectre or a compromised renderer.  Site Isolation depends on either
>> CORB or ORB to keep cross-site secrets out of the renderer process.  For
>> more information please see
>> https://www.chromium.org/Home/chromium-security/corb-for-developers.
>>
>> We are considering replacing CORB with ORB because ORB is more secure:
>> CORB fails open (it only blocks what its heuristics recognize as blockable)
>> and ORB fails closed (it only allows what its heuristics recognize as
>> scripts, stylesheets, images, audio, or video).  Improved security
>> properties mean that ORB is more likely to be a broadly adopted standard.
>>
>> ORB spec is being iterated on at https://github.com/annevk/orb.  ORB has
>> not been shipped by any browser today (Firefox tracks their efforts in
>> 1532642  and
>> plans to resume the work soon).  CORB is partially covered by
>> https://fetch.spec.whatwg.org/#corb (HTML, JSON, JS-parser-breaker, nor
>> XML sniffing is not covered).  Chromium is the only browser that implements
>> CORB today.
>

[blink-dev] Intent to Prototype: Back/forward cache NotRestoredReason API

['Yuzu Saijo' via blink-dev]

Contact emails

yu...@chromium.org, fer...@chromium.org

Explainer

https://github.com/rubberyuzu/bfcache-not-retored-reason/blob/main/NotRestoredReason.md

Specification

(Not yet ready)

Summary

NotRestoredReason API will report the list of reasons why a page is not
served from BFcache in a frame tree structure, via
PerformanceNavigationTiming API (and Reporting API in the future).


Blink component

UI>Browser>Navigation>BFCache


Motivation

Today pages can be blocked from BFCache for different reasons, such as
reasons required by spec and reasons specific to the browser
implementation.

For example, if a page uses a feature such as WebLock and does not release
the acquired lock in the pagehide handler, Chrome does not put the page
into BFCache. If developers want to make their site restored from BFCache,
they have to release the lock in the pagehide handler.

Developers can gather the hit-rate of BFCache on their site, i.e. what % of
history navigation is served by BFCache, by using the pageshow handler
persisted parameter and PerformanceNavigationTiming.type(back-forward).
However, there is no way for developers to tell what reasons are blocking
their pages from BFCache in the wild. They are not able to know what
actions to take to improve the hit-rate.

We would like to make it possible for sites to collect information on why
BFCache is not used on a history navigation, so that they can take actions
on each reason and make their page BFCache compatible.



Initial public proposal

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

https://discourse.wicg.io/t/proposal-back-forward-cache-notrestoredreason-api/5773

TAG review

(Not sent yet)

Risks

Interoperability and Compatibility

Gecko: Positive feedback on the GitHub discussion (link
)

WebKit: No signal

Web developers:

Positive reactions in W3C WG presentation (minutes

)

Performance Navigation API GitHub thread (link
)

Positive reactions in TPAC WebPerf WG (minutes

)



Debuggability

Is this feature fully tested by web-platform-tests

?

No

Flag name

(Not yet ready)


Requires code in //chrome?

False

Estimated milestones

No milestones specified


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5684908759449600

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

[blink-dev] Intent to Prototype and Ship: Multi-Screen Window Placement: Fullscreen Companion Window

[Mike Wasserman]

Contact emails

m...@chromium.org


Explainer

https://github.com/w3c/window-placement/blob/main/EXPLAINER_initiating_multi_screen_experiences.md

Specification

https://github.com/w3c/window-placement/blob/main/EXPLAINER_initiating_multi_screen_experiences.md#spec-changes

Design docs

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

Summary

Fullscreen Companion Window allows sites to place fullscreen content and a
popup window on separate screens from a single user activation.

This is a small requested enhancement of the Multi-Screen Window Placement
feature: https://chromestatus.com/feature/5252960583942144

Blink component

Blink>Screen>MultiScreen


TAG review

https://github.com/w3ctag/design-reviews/issues/602#issuecomment-1121694034

TAG review status

Pending

Risks
Interoperability and Compatibility

The main risk is that this feature fails to become an interoperable part of
the web platform if other browsers do not implement it. Scripted attempts
to open a popup window after requesting fullscreen would likely be blocked
by user agents that do not implement this feature, even if they implement
the basic Multi-Screen Window Placement API.

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

WebKit: No signal (
https://lists.webkit.org/pipermail/webkit-dev/2022-May/032223.html)

Web developers: Positive (
https://bugs.chromium.org/p/chromium/issues/detail?id=1233970) This
functionality is requested by a prominent API partner

Ergonomics

There is currently no way to detect feature support before attempted usage;
see
https://docs.google.com/document/d/1RRlGQharWVnmxKTomfKhNiaeE31L7iXHeXVfifOvwJA/edit?pli=1#heading=h.vu2lz7aeddz6

Activation

Developers can make immediate use of this API enhancement.

Security

This feature was designed from the ground-up to adhere to the strictest
usable security measures possible, as an incremental enhancement of
existing web platform APIs. See the design document for details.

WebView application risks

None

Debuggability

Existing mechanisms support debugging fullscreen and popup window open
requests.

Is this feature fully tested by web-platform-tests

?

No. An existing automated/manual WPT covers the ability to open
cross-screen popups . We aim to extend
test coverage for this specific scenario soon .

DevTrial instructions

https://github.com/w3c/window-placement/blob/main/HOWTO.md

Flag name

--enable-blink-features=WindowPlacement

Requires code in //chrome?

True -
https://docs.google.com/spreadsheets/d/1QV4SW4JBG3IyLzaonohUhim7nzncwK4ioop2cgUYevw/edit#gid=0&range=34:34

Tracking bug

https://crbug.com/1233970

Launch bug

https://crbug.com/1315615

Sample links

https://michaelwasserman.github.io/window-placement-demo/

(See DevTrial instructions)

Estimated milestones

DevTrial on desktop: 102

Shipping on desktop: 103

Anticipated spec changes

No changes anticipated that would introduce web compat/interop risk

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5173162437246976

Links to previous Intent discussions

Intents for the Multi-Screen Window Placement API:

   -

   I2P: 
   -

   I2E1: 
   -

   I2E2: 
   -

   I2S: 

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 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%2BkdQ4FcB_qto8h5GQrA4_ELUUwsyWWKyR0%3DmPsVxftr1uu2g%40mail.gmail.com.

Re: [blink-dev] Intent to Implement and Ship: Fullscreen Capability Delegation

[Mike Taylor]

Hey Mustaq - welcome back. :)

Thanks for the answers, and for requesting the missing WebKit position.

LGTM1

On 5/9/22 5:04 PM, Mustaq Ahmed wrote:

Hi Mike:

Sorry for the delay due to vacation etc!  Below are my answers to your 
queries.  Note that we are still asking for M103, so we will be prompt 
now :)


> Does this only work for standard requestFullscreen, or will it work 
for webkitRequestFullscreen as well?


This covers all forms: we are proposing changes in the core algorithm 
for request-fullscreen, regardless of the JS interface used to call it.


>> Gecko: Positive 
(https://github.com/mozilla/standards-positions/issues/565, also see: 
https://github.com/WICG/capability-delegation/issues/10)
> I don't think these quite count as official Positive signals (but 
yes, the comments from Anne are promising!). Can we ping the 
standards-position issue and ask for one?


See the recent comments in the issue asking for Gecko's position, thanks.
https://github.com/mozilla/standards-positions/issues/565

>> WebKit: No signal
> Have we asked? I looked at the Payment Request, and it seems like we 
didn't, but maybe I'm looking in the wrong spot. If not, can we?


I missed this with the intent for payment, sorry!  Filed a single 
request to cover both payment and fullscreen capabilities:

https://lists.webkit.org/pipermail/webkit-dev/2022-May/032221.html

>> Is this feature fully tested by web-platform-tests?
>> Not yet
> Is there something missing to test this (or capability detection in 
general), or is it just that you haven't written the WPTs yet?


We hadn't written a WPT at that time.  We have one under review now:
https://github.com/web-platform-tests/wpt/pull/34004

Mustaq


On Sun, May 8, 2022 at 11:07 PM Ajay Rahatekar 
 wrote:


+Ajay Rahatekar

On Monday, April 25, 2022 at 12:29:29 PM UTC-7
mike...@chromium.org wrote:

Hi Mustaq,

On 4/21/22 11:05 AM, Mustaq Ahmed wrote:



Contact emails

mus...@chromium.org, m...@chromium.org


Explainer

https://github.com/WICG/capability-delegation



Specification

https://wicg.github.io/capability-delegation/spec.html


(Work in progress for fullscreen algorithm change:
https://github.com/WICG/capability-delegation/pull/28
)


Design doc


https://docs.google.com/document/d/1ax54Lf2W3_TovVOj35duKTbcOlXe-nJ-KQdWiy1Ye0c




Summary

This feature is based on the general delegation mechanism
(https://chromestatus.com/feature/5708770829139968
) shipped
on M100.


Fullscreen Capability Delegation allows a Window to transfer
the ability to call requestFullscreen() to another Window it
trusts after relinquishing the transient user activation at
the sender Window.


Does this only work for standard requestFullscreen, or will it
work for webkitRequestFullscreen as well?



Blink component

Blink>Fullscreen




TAG review

Covered by the review for the general delegation mechanism:
https://github.com/w3ctag/design-reviews/issues/655



TAG review status

Covered by the approval for the general delegation
mechanism:https://github.com/WICG/capability-delegation/pull/23



Risks

Interoperability and Compatibility risks remain unchanged
from the general delegation mechanism; see that intent here:

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




External signals

Gecko:Positive
(https://github.com/mozilla/standards-positions/issues/565
,
also see:
https://github.com/WICG/capability-delegation/issues/10
)


I don't think these quite count as official Positive signals
(but yes, the comments from Anne are promising!). Can we ping
the standards-position issue and ask for one?


WebKit:No signal


Have we asked? I looked at the Payment Request, and it seems
like we didn't, but maybe I'm looking in the wrong spot. If
not, can we?


 

Re: [blink-dev] Is it possible to enable GLES 3.1 features?

[Ken Russell]

Hi Fei,

Several years ago there was much discussion about which direction to take
web graphics standards - either continue to extend WebGL toward OpenGL ES
3.1/3.2, or pursue the new family of low-level explicit graphics APIs
(D3D12/Metal/Vulkan). After much investigation it was decided to leave the
legacy behind and pursue a new standard, WebGPU. There is a tremendous
amount of cross-industry momentum behind WebGPU; the first version, and
implementations, will ship later this year.

I recommend you abandon the course of trying to get an OpenGL ES 3.1
JavaScript binding in Chromium, and instead see whether you can achieve
what you want using the existing WebGPU implementation in Chromium, as well
as Dawn, Chromium's native implementation of the API.

https://gpuweb.github.io/gpuweb/
https://gpuweb.github.io/gpuweb/explainer/
https://dawn.googlesource.com/dawn/

Best,

-Ken



On Mon, May 9, 2022 at 5:02 AM 杨飞  wrote:

> Hi everyone.
>
> I've asked a similar question in chromium-dev, then I realized here might
> be the better place to ask.
>
> I'm trying to hack Blink (in Chromium) to embed a native 3D rendering
> engine behind Chromium. In addtion, I want it to shared the same context as
> the WebGL2 context of a Canvas.
>
> The problem is that OpenGL ES 3.1 features are disabled by default. For
> example, when I try to call GLES2Interface::CreateShader with
> GL_COMPUTE_SHADER, I got "GL_INVALID_ENUM: OpenGL ES 3.1 Required". That
> basically means, the features of GLES2Interface are the same as those
> already exposed as WebGL.
>
> I therefore wonder, is there an easy way to enable the OpenGL ES 3.1
> features during Chromium building? Maybe using some gn args?
>
> Here is my project (without involving Chromium):
> https://github.com/fynv/Three.V8
>
> The whole purpose of the attempt is to try to utilize the native OpenGL
> features which are not exposed through WebGL. But it looks like, if the
> GLES 3.1 features are enabled in
> GLES2Interface, they will also be exposed to WebGL. Is that the case?
>
> Thanks
>
> Fei
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7ce0a611-68b0-4433-9dbb-7af6f8d74a6dn%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/CAMYvS2dzr_MMct2xuPTrDzE1u79%3DiH_ej0ivhcrF%2B_ZZz7%3D3ZA%40mail.gmail.com.

Re: [blink-dev] Intent to Implement and Ship: Fullscreen Capability Delegation

['Mustaq Ahmed' via blink-dev]

Hi Mike:

Sorry for the delay due to vacation etc!  Below are my answers to your
queries.  Note that we are still asking for M103, so we will be prompt now
:)

> Does this only work for standard requestFullscreen, or will it work for
webkitRequestFullscreen as well?

This covers all forms: we are proposing changes in the core algorithm for
request-fullscreen, regardless of the JS interface used to call it.

>> Gecko: Positive (
https://github.com/mozilla/standards-positions/issues/565, also see:
https://github.com/WICG/capability-delegation/issues/10)
> I don't think these quite count as official Positive signals (but yes,
the comments from Anne are promising!). Can we ping the standards-position
issue and ask for one?

See the recent comments in the issue asking for Gecko's position, thanks.
https://github.com/mozilla/standards-positions/issues/565

>> WebKit: No signal
> Have we asked? I looked at the Payment Request, and it seems like we
didn't, but maybe I'm looking in the wrong spot. If not, can we?

I missed this with the intent for payment, sorry!  Filed a single request
to cover both payment and fullscreen capabilities:
https://lists.webkit.org/pipermail/webkit-dev/2022-May/032221.html

>> Is this feature fully tested by web-platform-tests?
>> Not yet
> Is there something missing to test this (or capability detection in
general), or is it just that you haven't written the WPTs yet?

We hadn't written a WPT at that time.  We have one under review now:
https://github.com/web-platform-tests/wpt/pull/34004

Mustaq


On Sun, May 8, 2022 at 11:07 PM Ajay Rahatekar 
wrote:

> +Ajay Rahatekar
>
> On Monday, April 25, 2022 at 12:29:29 PM UTC-7 mike...@chromium.org wrote:
>
>> Hi Mustaq,
>>
>> On 4/21/22 11:05 AM, Mustaq Ahmed wrote:
>>
>> Contact emails
>>
>> mus...@chromium.org, m...@chromium.org
>> Explainer
>>
>> https://github.com/WICG/capability-delegation
>> Specification
>>
>> https://wicg.github.io/capability-delegation/spec.html
>>
>> (Work in progress for fullscreen algorithm change:
>> https://github.com/WICG/capability-delegation/pull/28)
>> Design doc
>>
>>
>> https://docs.google.com/document/d/1ax54Lf2W3_TovVOj35duKTbcOlXe-nJ-KQdWiy1Ye0c
>> Summary
>>
>> This feature is based on the general delegation mechanism (
>> https://chromestatus.com/feature/5708770829139968) shipped on M100.
>>
>> Fullscreen Capability Delegation allows a Window to transfer the ability
>> to call requestFullscreen() to another Window it trusts after relinquishing
>> the transient user activation at the sender Window.
>>
>> Does this only work for standard requestFullscreen, or will it work for
>> webkitRequestFullscreen as well?
>>
>> Blink component
>>
>> Blink>Fullscreen
>> 
>> TAG review
>>
>> Covered by the review for the general delegation mechanism:
>> https://github.com/w3ctag/design-reviews/issues/655
>> TAG review status
>>
>> Covered by the approval for the general delegation mechanism:
>> https://github.com/WICG/capability-delegation/pull/23
>> Risks
>>
>> Interoperability and Compatibility risks remain unchanged from the
>> general delegation mechanism; see that intent here:
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/PHT_2X7oRBE/m/gR9UiZxBAQAJ
>> External signals
>>
>> Gecko: Positive (
>> https://github.com/mozilla/standards-positions/issues/565, also see:
>> https://github.com/WICG/capability-delegation/issues/10)
>>
>> I don't think these quite count as official Positive signals (but yes,
>> the comments from Anne are promising!). Can we ping the standards-position
>> issue and ask for one?
>>
>> WebKit: No signal
>>
>> Have we asked? I looked at the Payment Request, and it seems like we
>> didn't, but maybe I'm looking in the wrong spot. If not, can we?
>>
>> Web developers: Positive (https://crbug.com/931966#c5)
>> Debuggability
>>
>> This remains unchanged from the general intent:
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/PHT_2X7oRBE/m/gR9UiZxBAQAJ
>> Ongoing technical constraints
>>
>> 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
>> 
>> ?
>>
>> Not yet
>>
>> Is there something missing to test this (or capability detection in
>> general), or is it just that you haven't written the WPTs yet?
>>
>> Flag name
>>
>> --enable-blink-features=CapabilityDelegationFullscreenRequest
>> Requires code in //chrome?
>>
>> Yes, work in progress
>> Tracking bug
>>
>> https://crbug.com/1293083
>> Estimated milestone
>>
>> 103
>> Link to entry on the Chrome Platform Status
>>
>> https://chromestatus.com/feature/6441688242323456
>> Links to previous Intent discussions
>>
>> Intents for the general delegation mechanism:
>>
>>-
>>
>>I2P:
>>
>> https://groups.g

[blink-dev] Sign up to host a breakout talk @ BlinkOn16!

[Ben Goodger]

*TLDR:* By *Wednesday**,** May 11th*, *sign up here*

to host a breakout talk at BlinkOn 16.

Hi everyone,

With BlinkOn 16 being just over two weeks away, this is a final
reminder to *sign
up here*

to host a 25-minute breakout talk (presentation, discussion, etc.). The
sign up will remain open until *Wednesday**,** May 11th *(previously May
4th). You can view the breakout talks that have already been proposed *here*

.

If you have any questions or concerns, please visit *chromium.org/events*

or email us at *blin...@chromium.org* .

Thanks!

-Ben

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

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

[Łukasz Anforowicz]

On Fri, May 6, 2022 at 4:45 PM Mike Taylor  wrote:

> Hi there,
>
> While we review this, can we ask WebKit for a signal? (
> bit.ly/blink-signals).
>

Done - see:
https://lists.webkit.org/pipermail/webkit-dev/2022-May/03.html


> Also, https://github.com/w3ctag/design-reviews/issues/618 is the TAG
> review for this, correct?
>

Not quite.  This was a review of just one aspect of ORB - having a list of
MIME types for which it is never allowed to have a response in mode=no-cors
(this aspect is shared across ORB and CORB) .  OTOH some comments in this
review

did highlight that ORB has no impact on behavior and
functionality (assuming HTTP responses use correct `Content-Type`).

For now, I assume that no additional reviews are needed given that

   - No new API surface
   - No behavior change if HTTP responses use correct `Content-Type`.
   - If an incorrect or inaccurate `Content-Type` is used, then ORB v0.1
   introduces minimal change in behavior compared to CORB (blocking additional
   0.01% of HTTP responses;  see the original email for more details and
   examples).

FWIW, since ORB does cause known changes in 0.01% of HTTP responses, we
thought that an official intent-to-ship route is the safest path going
forward.  OTOH, feel free to guide us toward another process if needed -
e.g. maybe an argument can be made to use the "web developer facing change
to existing code
"
path instead.

Thanks,

-Lukasz


> On 5/5/22 2:02 PM, Łukasz Anforowicz wrote:
>
> Hello!
>
> The goal of this email is to:
>
>- Seek LGTMs from Blink API owners for the intent to ship ORB v0.1
> in Chrome M103.  A
>formal, semi-automatically-generated intent-to-ship data can be found at
>the end of this email.
>- Provide an overview of ORB, motivations for shipping it, and its
>(low) risks.
>- Highlight scenarios where web developers might want to double-check
>the MIME types used by their HTTP servers when serving certain resources.
>
>
> *Overview of ORB*
>
> Opaque Response Blocking (ORB) is a replacement for Cross-Origin Read
> Blocking (CORB).  CORB and ORB are both heuristics that attempt to prevent
> cross-origin disclosure of “no-cors” subresources.  An example attack that
> ORB and CORB prevent is where an attacker’s frame contains  https://victim.example.com/secret.json”> which an attacker reads using
> either Spectre or a compromised renderer.  Site Isolation depends on either
> CORB or ORB to keep cross-site secrets out of the renderer process.  For
> more information please see
> https://www.chromium.org/Home/chromium-security/corb-for-developers.
>
> We are considering replacing CORB with ORB because ORB is more secure:
> CORB fails open (it only blocks what its heuristics recognize as blockable)
> and ORB fails closed (it only allows what its heuristics recognize as
> scripts, stylesheets, images, audio, or video).  Improved security
> properties mean that ORB is more likely to be a broadly adopted standard.
>
> ORB spec is being iterated on at https://github.com/annevk/orb.  ORB has
> not been shipped by any browser today (Firefox tracks their efforts in
> 1532642  and
> plans to resume the work soon).  CORB is partially covered by
> https://fetch.spec.whatwg.org/#corb (HTML, JSON, JS-parser-breaker, nor
> XML sniffing is not covered).  Chromium is the only browser that implements
> CORB today.
>
>
>
> *Motivation for ORB v0.1 *
>
> At this point, there remain open questions about the feasibility of the JS
> detection heuristics required by full ORB.  Still, the incremental benefits
> of adopting even a subset of ORB are definitely desirable.  We call this
> subset ORBv0.1 - the main difference from full ORB is replacing JS
> sniffing/parsing with CORB’s more limited HTML, JSON, and XML sniffers. In
> other words, ORBv0.1 still fails open and only blocks a subset of known
> response types, but it blocks more than CORB.
>
> *ORBv0.1 offers incremental security benefits compared to CORB*.  ORBv0.1
> blocks the following kinds of HTTP responses that CORB wouldn’t block:
>
>- CORB blocks responses that contain HTML and XML only if they are
>labeled with HTML mime type
> or XML mime type
>.  ORBv0.1 blocks
>responses that contain HTML and XML even if they are mislabeled (e.g. HTML
>served as application/octet-stream, or XML served as text/html).
>- CORB blocks range request responses only if they are labeled with
>HTML, JSON, or XML mime type.  ORBv0.1 blocks all range request responses,
>unless they come from a URL that ORBv0.1 has earlier recognized (via
>sniffing, or vi

[blink-dev] Re: Intent to Ship: Local Fonts Access API

['Ajay Rahatekar' via blink-dev]

Hello API Owners,

Please let us know if there are any outstanding concerns apart from the 
discussion on the Mozilla position 
,
 
that we can address. The team is targeting M103 for shipping this api. 

Thanks for all your help and guidance.

-Ajay

On Wednesday, May 4, 2022 at 8:37:03 AM UTC-7 sligh...@chromium.org wrote:

> I LGTM'd in the tool but it didn't show up here, but y'all have my +1. 
> Thanks for getting this done.
>
> On Thursday, April 28, 2022 at 5:01:51 PM UTC-7 Joshua Bell wrote:
>
>> FYI, non-normative note added. I also followed up on the questions in the 
>> Moz standards position thread, added a few more notes to the spec as well.
>>
>> On Wed, Apr 27, 2022 at 9:01 AM Alex Russell  
>> wrote:
>>
>>> A non-normative note in the spec sounds good. Wouldn't want to block 
>>> shipping on it.
>>>
>>> On Wednesday, April 27, 2022 at 2:05:53 AM UTC-7 Yoav Weiss wrote:
>>>
 If we're going with exposing byte-by-byte representation of the fonts 
 on the user's filesystem, we should make that slightly more explicit. 
 Maybe 
 add a note to 
 https://wicg.github.io/local-font-access/#font-representation-data-bytes 
 clarifying that point?

 I *think* that lack of normalization should resolve the issues Anne was 
 concerned about in https://github.com/WICG/local-font-access/issues/20, 
 where different normalization algorithms result in compatibility issues. I 
 also *think* it should resolve Tess' concerns RE user assumptions of the 
 fonts being Open-Type. Can you clarify those points with them?

 On Monday, April 25, 2022 at 6:12:00 PM UTC+2 Alex Russell wrote:

> Normalisation isn't usually a goal for users that want the actual 
> bytes of the local font in order to do the rendering themselves and can 
> be 
> an active non-goal given the ways that folks want to do custom grouping, 
> enumeration, and rendering. Partners have consistently asked us not to 
> remove information and I've never heard of a request for normalisation 
> from 
> a partner.
>
> This is in line with not adding OTS sanitisation for these files  (we 
> don't need to when the OS rendering pipeline isn't at potential risk), 
> and 
> highlights the way that the current design is isomorphic with local file 
> access. 
>
> I've LGTM'd it in the tool as a result.
>
> Thanks to everyone at Google for continuing to push this forward.
>
> Best Regards,
>
> Alex
>
> On Thursday, April 21, 2022 at 9:46:15 AM UTC-7 Joshua Bell wrote:
>
>> On Wed, Apr 20, 2022 at 4:21 AM Yoav Weiss  
>> wrote:
>>
>>>
>>>
>>> On Wed, Apr 13, 2022 at 6:46 PM Joshua Bell  
>>> wrote:
>>>
 On Wed, Apr 13, 2022 at 6:36 AM Yoav Weiss  
 wrote:

> Also, any learnings/feedback from the Origin Trial?
>
>
 Not distinct from the dev trial (i.e. developers trying the API 
 behind a flag). There was a feature request for additional metadata 
 which 
 was implemented, then the request was withdrawn so that code was 
 backed 
 out. Other requests are marked as "enhancements" in the issue tracker, 
 e.g. 
 font modification timestamps.
  

> On Wednesday, April 13, 2022 at 3:35:02 PM UTC+2 Yoav Weiss wrote:
>
>> On Friday, April 8, 2022 at 8:15:42 PM UTC+2 Ajay Rahatekar wrote:
>>
>>> Contact emails
>>>
>>> ds...@chromium.org, jsb...@chromium.org
>>>
>>> Explainer
>>>
>>> https://github.com/WICG/local-font-access
>>>
>>> Specification
>>>
>>> https://wicg.github.io/local-font-access/
>>>
>>> Design docsDesign Doc: https://bit.ly/2HWBOLi 
>>> 
>>>
>>> Blog: https://web.dev/local-fonts/
>>>
>>>
>>> Summary
>>>
>>> Gives web applications the ability to enumerate local fonts and 
>>> some metadata about each. Today, no API exists to provide a list of 
>>> local 
>>> fonts to web applications.  
>>>
>>> Also gives web applications access to the font data as a binary 
>>> blob, allowing those fonts to be rendered within their applications 
>>> using 
>>> custom text stacks.
>>>
>>> Blink component
>>>
>>> Blink>Fonts 
>>> 
>>>
>>> TAG review
>>>
>>> https://github.com/w3ctag/design-reviews/issues/400
>>>
>>> TAG review status
>>>
>>> Pen

Re: [blink-dev] Intent to Ship: Capability Delegation with Payment Request

['Mustaq Ahmed' via blink-dev]

Looks like we missed asking for the official position of Webkit.  Just sent
the request
.

On Fri, Jan 28, 2022 at 12:02 PM Chris Harrelson 
wrote:

>
>
> On Fri, Jan 28, 2022 at 9:01 AM Stephen Mcgruer 
> wrote:
>
>> > Am I correct that currently Chromium allows the Payment Request API to
>> be used unconditionally in iframes? Do you then intend to send another
>> intent to change the behavior to require activation, after a suitable
>> period and working with sites to migrate?
>>
>> Correct. This is Intent to Deprecate and Remove: Calling
>> PaymentRequest.show without user activation
>> 
>> .
>>
>
> LOL. I feel like I might have LGTMed that one.
>
>
>> We had hoped to land them simultaneously (as we have a good relationship
>> with the primary user that does not currently have user-activation when
>> calling show()), however our partner is having trouble with their
>> migration and we may request to push the enforcement (aka the deprecation)
>> back to M102. (TBD still; I expect to make the request on the deprecation
>> thread in the next few days.)
>>
>
> SGTM!
>
> LGTM3 for this intent (shipping the API).
>
>
>>
>> On Fri, 28 Jan 2022 at 11:55, Chris Harrelson 
>> wrote:
>>
>>> I'm a bit confused about the bit regarding transitioning existing sites.
>>> Am I correct that currently Chromium allows the Payment Request API to be
>>> used unconditionally in iframes? Do you then intend to send another intent
>>> to change the behavior to require activation, after a suitable period and
>>> working with sites to migrate?
>>>
>>> Chris
>>>
>>> On Thu, Jan 27, 2022 at 11:13 PM Yoav Weiss 
>>> wrote:
>>>
 LGTM2 % fixing the spec issue.

 On Thu, Jan 27, 2022 at 9:53 PM Mike Taylor 
 wrote:

> Appreciate the replies, Mustaq.
>
> This seems like a useful addition to the platform, thanks for working
> on it. LGTM1.
>
> On 1/27/22 12:35 PM, Mustaq Ahmed wrote:
>
> Hi Mike:
>
> Appreciate your feedback.  My answers are inline.
>
> Mustaq
>
>
> On Wed, Jan 26, 2022 at 6:03 PM Mike Taylor 
> wrote:
>
>> Hi Mustaq,
>>
>> On 1/25/22 4:45 PM, Mustaq Ahmed wrote:
>>
>> Contact emails
>>
>> mus...@chromium.org, smcgr...@chromium.org
>> Explainer
>>
>> https://github.com/WICG/capability-delegation
>> Specification
>>
>> https://wicg.github.io/capability-delegation/spec.html
>> Design doc
>>
>>
>> https://docs.google.com/document/d/1IYN0mVy7yi4Afnm2Y0uda0JH8L2KwLgaBqsMVLMYXtk/edit?usp=sharing
>> Summary
>>
>> Capability delegation means allowing a frame to relinquish its
>> ability to call a restricted API and transfer the ability to another
>> (sub)frame it trusts.
>>
>> Can you expand more on the relinquishing aspect and how regaining the
>> capability happens? I can't find any normative text in
>> https://wicg.github.io/capability-delegation/spec.html that explains
>> how it happens. Do we look for expired timestamps in
>> DELEGATED_CAPABILITY_TIMESTAMPS["feature"] of all frames? Something else?
>>
>> (maybe I'm looking in the wrong place!)
>>
> You got it right: our proposal missed the normative text around the
> relinquishing, yikes!  I opened this spec issue
> , we will
> send out a PR to fix this when we get a chance.  In the meantime here is
> what we wanted to mean: access to activation-gated APIs
> 
>  is
> lost from the sender frame through consumption, and the receiver frame
> checks its own DELEGATED_CAPABILITY_TIMESTAMPS["feature"] only.
>
> If an app wants to delegate its ability to call a restricted JS
>> capability (e.g. popups, fullscreen, etc) to a known+trusted third-party
>> frame, the app would utilize a Capability Delegation API to "transfer" 
>> the
>> ability to the target frame in a time-constrained manner (unlike static
>> mechanisms like  attributes).
>>
>> What happens if the delegation is refused (or fails) by the browser
>> for some reason? As a developer, how do I know that I shouldn't fire off 
>> a
>> PaymentRequest that's going to fail? Do we signal anything in the message
>> event, if not, should we?
>>
>> (From the PaymentRequest side, I guess I can handle the failure if
>> PaymentRequest.show() is rejected.)
>>
> Yes, just trying PaymentRequest.show() works on the receiver side
> today.  As we get more use-cases around delegation, we can explore
> signaling on the received message event.  I would suggest starting a new
> issue to discuss this.
>
> That's fair - I'l

Re: [blink-dev] Intent to Prototype: Declarative PendingBeacon API

[Ben Kelly]

How does this feature interact with service workers?  Will it trigger a
FetchEvent to be fired in the worker thread?

I expect we probably want this feature to bypass service workers and not
fire a FetchEvent.  Otherwise this is an avenue for background SW
processing which has privacy and abuse risks.

On Mon, May 9, 2022 at 8:01 AM Darren Willis  wrote:

> Contact emails...@chromium.org
>
> Explainer
> https://github.com/darrenw/docs/blob/main/explainers/beacon_api.md
>
> Specification
>
> Summary
>
> A stateful API for beacons that has the browser control the time beacons
> are sent. Existing beacon APIs are all based around a developer
> constructing and sending a beacon, and there's no good time for that "send"
> call to be made. (Handlers such as 'unload' are often ignored, for
> example.) This API delegates the sending to the browser itself, so it can
> support beacons on page unload or on page hide, without the developer
> having to implement send calls at exactly the right times.
>
>
> Blink componentBlink
> 
>
> Motivation
>
> Web developers have a need for ‘beaconing’ - that is, sending a bundle of
> data to a backend server, without expecting a particular response, ideally
> at the ‘end’ of a user’s visit to a page. There are currently four major
> methods of beaconing used around the web; all suffer from reliability
> problems, stemming from one core issue: There is not an ideal time in a
> page’s lifecycle to make the Javascript call to send out the beacon.
> ‘unload’ and ‘beforeUnload’ are unreliable (and outright ignored by several
> major browsers), and pageHide and visibilityChanged have issues on mobile
> platforms. To simplify this issue and make beaconing more reliable, we
> propose adding a stateful Javascript API where a page can register that it
> wants a beacon (or beacons) issued when it unloads or the page is hidden.
> Developers can populate beacon(s) with data as the user uses the page, and
> the browser ensures beacon(s) are reliably sent at some point in time. This
> frees developers from worrying about which part of the page lifecycle to
> send their beacon calls in.
>
>
> Initial public proposal
> https://discourse.wicg.io/t/proposal-stateful-javascript-page-unload-beacon-api/5776
>
> TAG review
>
> TAG review statusPending
>
> Risks
>
>
> Interoperability and Compatibility
>
>
>
> Gecko: No signal
>
> WebKit: No signal
>
> Web developers: No signals
>
> Other signals:
>
> WebView application risks
>
> No
>
> Debuggability
>
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?No
>
> Flag namePendingBeaconAPI
>
> Requires code in //chrome?False
>
> Estimated milestones
>
> No milestones specified
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5690553554436096
>
> 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/CAG%2BRaU7yMQ%2BRkeSpXhgbfCSGb4BvpW-exTUFZzb_eMFRE%2B_syQ%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/CAK7rkMjjWrtCKtp2WSrKwrAbdakGuzUwGbswBRT1ADExV3%3DrsQ%40mail.gmail.com.

[blink-dev] Is it possible to enable GLES 3.1 features?

[杨飞]

Hi everyone.

I've asked a similar question in chromium-dev, then I realized here might 
be the better place to ask.

I'm trying to hack Blink (in Chromium) to embed a native 3D rendering 
engine behind Chromium. In addtion, I want it to shared the same context as 
the WebGL2 context of a Canvas.

The problem is that OpenGL ES 3.1 features are disabled by default. For 
example, when I try to call GLES2Interface::CreateShader with 
GL_COMPUTE_SHADER, I got "GL_INVALID_ENUM: OpenGL ES 3.1 Required". That 
basically means, the features of GLES2Interface are the same as those 
already exposed as WebGL. 

I therefore wonder, is there an easy way to enable the OpenGL ES 3.1 
features during Chromium building? Maybe using some gn args? 

Here is my project (without involving 
Chromium): https://github.com/fynv/Three.V8

The whole purpose of the attempt is to try to utilize the native OpenGL 
features which are not exposed through WebGL. But it looks like, if the 
GLES 3.1 features are enabled in 
GLES2Interface, they will also be exposed to WebGL. Is that the case?

Thanks

Fei

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

[blink-dev] Intent to Prototype: Declarative PendingBeacon API

[Darren Willis]

Contact emails...@chromium.org

Explainerhttps://github.com/darrenw/docs/blob/main/explainers/beacon_api.md

Specification

Summary

A stateful API for beacons that has the browser control the time beacons
are sent. Existing beacon APIs are all based around a developer
constructing and sending a beacon, and there's no good time for that "send"
call to be made. (Handlers such as 'unload' are often ignored, for
example.) This API delegates the sending to the browser itself, so it can
support beacons on page unload or on page hide, without the developer
having to implement send calls at exactly the right times.


Blink componentBlink


Motivation

Web developers have a need for ‘beaconing’ - that is, sending a bundle of
data to a backend server, without expecting a particular response, ideally
at the ‘end’ of a user’s visit to a page. There are currently four major
methods of beaconing used around the web; all suffer from reliability
problems, stemming from one core issue: There is not an ideal time in a
page’s lifecycle to make the Javascript call to send out the beacon.
‘unload’ and ‘beforeUnload’ are unreliable (and outright ignored by several
major browsers), and pageHide and visibilityChanged have issues on mobile
platforms. To simplify this issue and make beaconing more reliable, we
propose adding a stateful Javascript API where a page can register that it
wants a beacon (or beacons) issued when it unloads or the page is hidden.
Developers can populate beacon(s) with data as the user uses the page, and
the browser ensures beacon(s) are reliably sent at some point in time. This
frees developers from worrying about which part of the page lifecycle to
send their beacon calls in.


Initial public proposal
https://discourse.wicg.io/t/proposal-stateful-javascript-page-unload-beacon-api/5776

TAG review

TAG review statusPending

Risks


Interoperability and Compatibility



Gecko: No signal

WebKit: No signal

Web developers: No signals

Other signals:

WebView application risks

No

Debuggability



Is this feature fully tested by web-platform-tests

?No

Flag namePendingBeaconAPI

Requires code in //chrome?False

Estimated milestones

No milestones specified


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

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/CAG%2BRaU7yMQ%2BRkeSpXhgbfCSGb4BvpW-exTUFZzb_eMFRE%2B_syQ%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: User Agent Client Hints GREASE Update

[Mike West]

LGTM3.

-mike


On Wed, May 4, 2022 at 11:37 AM Daniel Bratell  wrote:

> LGTM2
>
> /Daniel
> On 2022-05-03 16:23, Yoav Weiss wrote:
>
> LGTM1
>
> Thanks for aligning with the spec and tackling this change carefully.
> Hoping it sticks.
>
> On Tue, May 3, 2022 at 4:18 PM Matt Reichhoff 
> wrote:
>
>> Contact emails
>>
>> mreichh...@chromium.org, miketa...@chromium.org
>>
>> Explainer
>>
>> https://github.com/WICG/ua-client-hints#user-agent-client-hints
>>
>> Specification
>>
>> https://wicg.github.io/ua-client-hints/#grease
>>
>> Summary
>>
>> We seek to align our implementation of GREASE in User Agent Client Hints
>> with the current spec, which includes additional GREASE characters beyond
>> the current semicolon and space, and which recommends varying the arbitrary
>> version. This is to help prevent bad assumptions from being built on top of
>> User-Agent strings.
>>
>> After experimentation over the course of several releases, we propose to
>> make the updated algorithm the default behavior starting with M103. See
>> below for potential risks and their mitigation.
>>
>> Blink component
>>
>> Privacy>Fingerprinting
>> 
>>
>> TAG review
>>
>> N/A. This is a small change to a feature that was already reviewed by
>> the TAG .
>>
>> TAG review status
>>
>> Not applicable
>>
>> Risks
>> Interoperability and Compatibility
>>
>> A prior implementation including escaped ASCII 0x22 (double quote) and
>> 0x5C (backslash) proved to be web incompatible and was rolled back.
>>
>> We do not anticipate similar issues with the updated algorithm, because
>> experimentation was run in M98 and M99 (during February and March, 2022),
>> and did not uncover statistically significant shifts in response codes,
>> with the worst finding showing a potential effect size of an additional 2-3
>> requests per 100k returning 502 responses; it was marked low-to-medium
>> statistical confidence and did not show up consistently across timeframes
>> and platforms, leading us to believe it was noisy. We have also not been
>> able to find bug reports tied to the changes.
>>
>> However, because there are hundreds of permutations of the GREASE string,
>> we also performed the following set of safety checks:
>>
>>-
>>
>>Ran a multi-group experiment where each of the new characters was
>>checked in the canary and dev channels; we again did not get statistically
>>significant results for response codes.
>>-
>>
>>Ran a fuzzer against the top 10,000 sites (per Tranco
>>) with each of the new characters and did
>>not observe breakage.
>>-
>>
>>   Per experimental results, special attention was paid to 502
>>   responses; none seen with the fuzzer were reproducible in canary with 
>> the
>>   updated algorithm, reinforcing our belief that the 502 metric was just
>>   occasionally noisy.
>>   -
>>
>>Implemented and will maintain for at least an additional 1 year an
>>enterprise escape hatch to opt out of the new behavior; that timeframe 
>> will
>>ensure sufficient coverage of permutations.
>>-
>>
>>Implemented and will maintain for the same timeframe the ability to
>>override the behavior via Finch if problems are uncovered.
>>-
>>
>>Implemented once-per-version rotation of the string, meaning we would
>>have the full release cycle to uncover any issues with a given 
>> permutation,
>>much like we do with any other change to chromium.
>>
>>
>> Gecko: Non-harmful (
>> https://mozilla.github.io/standards-positions/#ua-client-hints)
>>
>> WebKit: No signal on this particular change. But unofficially mildly
>> positive
>>  on
>> UA-CH as a whole.
>>
>> Web developers: No 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; Android WebView is not affected.
>>
>>
>> Debuggability
>>
>> N/A; no change required
>>
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?
>>
>> Yes
>>
>> Flag name
>>
>> --enable-features="GreaseUACH:updated_algorithm/true"
>>
>> Requires code in //chrome?
>>
>> False
>>
>> Tracking bug
>>
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1164423
>>
>>
>>
>> Anticipated spec changes
>>
>> None
>>
>>
>> Link to entry on the Chrome Platform Status
>>
>> https://chromestatus.com/feature/5630916006248448
>>
>> Links to previous Intent discussions
>>
>> Intent to prototype:
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/ueudFsZzT1M
>> Intent to Experiment:
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGg35ayyQVGYm%2BE7LreK50L0