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

[Darren Willis]

Sorry for the late reply. Agreed that we'll want this feature to bypass
service workers, I'll add this to the explainer.

On Mon, May 9, 2022 at 11:29 PM Ben Kelly  wrote:

> 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/CAG%2BRaU734Kwy5T%3DnZXaW8S5A%3DgCBNJ4zsUubhsVGXXrSDt666g%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: WebGL canvas color management

[Ken Russell]

LGTM not as API owner, but as member of Khronos' WebGL working group (and
also the chair).

-Ken



On Tue, May 17, 2022 at 3:40 PM 'Christopher Cameron' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emailsccame...@chromium.org
>
> Specification
> This is part of the WebGL specification. In particular:
>
>- 5.14.1 context attributes
> discusses
>drawingBufferColorSpace and unpackColorSpace
>- 5.14.8 texture objects
> discusses
>unpackColorSpace
>
> This spec was originally developed in the W3C's ColorWeb community group
>  along with the 2D canvas color
> management proposal at
>
>
> https://github.com/WICG/canvas-color-space/blob/main/CanvasColorSpaceProposal.md
> It was broken out and iterated upon separately in Khronos (in particular
> by Mozilla and Chrome representatives). The final changes to the Khronos
> WebGL spec are in
> https://github.com/KhronosGroup/WebGL/pull/3292
>
> *Summary*
>
> Implementation of WebGL color management API WebGL allows specification of
> - the color space that its drawing buffer is - the color space that content
> should be converted to when importing as a texture This feature is to
> update our implementation to include this functionality. Prior to this
> feature, both of these defaulted to sRGB. Now they can also use
> "display-p3".
>
> Blink componentBlink>WebGL
> 
>
> Search tagscanvas , webgl
> , display-p3
> , color space
> 
>
> TAG review status
> N/A. Canvas 2D color managment API already TAG reviewed at
> https://github.com/w3ctag/design-reviews/issues/646
> This specification change was developed in Khronos and followed the
> processes there.
>
> Risks
>
>
> Interoperability and Compatibility
>
>
>
> Gecko: Positive Developed in close collaboration with Mozilla, spec
> changes reviewed by Mozilla.
>
> WebKit: Positive Discussed in ColorWeb CG with WebKit representatives
>
> Web developers: Strongly positive
>
> Other signals:
>
> Privacy: N/A
> This exposes no information about the user's system to the web. This API
> can be used on systems that do not support wide color gamut (the
> out-of-gamut colors are clipped, as they are for 2D canvas, images, and
> video).
>
> Security: N/A
>
> This allows a WebGL canvas to specify its color space. This functionality
> is already present for 2D canvas, images, and video content.
>
>
>
> Debuggability
>
> Debugging is currently limited to sRGB colors. This limits visibility into
> wide color gamut image, video, and 2D canvas. This limitation is being
> looked at in the context of adding CSS color level 4 support.
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?No, this is tested instead by WebGL conformance tests.
>
> Flag nameWebGLColorManagement
>
> Requires code in //chrome?No
>
> Tracking bughttps://crbug.com/1208480
>
> Sample linkshttps://ccameron-chromium.github.io/webgl-examples/p3.html
>
> Estimated milestones
>
> No milestones specified
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/4814886323355648
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGnfxj_6radHqyNz4Sxa3SxZET-93xJCdMdZe6WptHxOLyhC3A%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/CAMYvS2ekSB4fFQ0-NHHs2ESFPu5jHauTEZWiURVGSWcbDcF0VQ%40mail.gmail.com.

[blink-dev] Intent to Ship: WebGL canvas color management

['Christopher Cameron' via blink-dev]

Contact emailsccame...@chromium.org

Specification
This is part of the WebGL specification. In particular:

   - 5.14.1 context attributes
    discusses
   drawingBufferColorSpace and unpackColorSpace
   - 5.14.8 texture objects
    discusses
   unpackColorSpace

This spec was originally developed in the W3C's ColorWeb community group
 along with the 2D canvas color
management proposal at

https://github.com/WICG/canvas-color-space/blob/main/CanvasColorSpaceProposal.md
It was broken out and iterated upon separately in Khronos (in particular by
Mozilla and Chrome representatives). The final changes to the Khronos WebGL
spec are in
https://github.com/KhronosGroup/WebGL/pull/3292

*Summary*

Implementation of WebGL color management API WebGL allows specification of
- the color space that its drawing buffer is - the color space that content
should be converted to when importing as a texture This feature is to
update our implementation to include this functionality. Prior to this
feature, both of these defaulted to sRGB. Now they can also use
"display-p3".

Blink componentBlink>WebGL


Search tagscanvas , webgl
, display-p3
, color space


TAG review status
N/A. Canvas 2D color managment API already TAG reviewed at
https://github.com/w3ctag/design-reviews/issues/646
This specification change was developed in Khronos and followed the
processes there.

Risks


Interoperability and Compatibility



Gecko: Positive Developed in close collaboration with Mozilla, spec changes
reviewed by Mozilla.

WebKit: Positive Discussed in ColorWeb CG with WebKit representatives

Web developers: Strongly positive

Other signals:

Privacy: N/A
This exposes no information about the user's system to the web. This API
can be used on systems that do not support wide color gamut (the
out-of-gamut colors are clipped, as they are for 2D canvas, images, and
video).

Security: N/A

This allows a WebGL canvas to specify its color space. This functionality
is already present for 2D canvas, images, and video content.



Debuggability

Debugging is currently limited to sRGB colors. This limits visibility into
wide color gamut image, video, and 2D canvas. This limitation is being
looked at in the context of adding CSS color level 4 support.


Is this feature fully tested by web-platform-tests

?No, this is tested instead by WebGL conformance tests.

Flag nameWebGLColorManagement

Requires code in //chrome?No

Tracking bughttps://crbug.com/1208480

Sample linkshttps://ccameron-chromium.github.io/webgl-examples/p3.html

Estimated milestones

No milestones specified

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

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

[blink-dev] Intent to prototype and ship: CSS grid-template properties interpolation

['Ana Sollano Kim' via blink-dev]

Contact emails
ansol...@microsoft.com, 
dli...@microsoft.com
Explainer
None
Specification
https://www.w3.org/TR/css-grid-1/#track-sizing
Summary

In CSS Grid, the grid-template-columns and grid-template-rows properties allow 
developers to define line names and track sizing of grid columns and rows, 
respectively. Supporting interpolation for these properties will allow grid 
layouts to smoothly transition between states, instead of snapping at the 
halfway point of an animation or transition. Web developers can use this 
functionality to achieve specific interactive effects without having to resort 
to driving animations via JavaScript.

Blink component
Blink>Layout>Grid
TAG review

TAG review status
Not applicable. We don't believe this merits TAG review - it fits into the 
existing framework of CSS Animations/Transitions and it has been in the CSS 
Grid spec for years. But we're happy to file a request if API_OWNERS feel this 
change should have one.
Risks

Interoperability and Compatibility

Gecko: Shipped since 2019
WebKit: Recently implemented in preview 
https://bugs.webkit.org/show_bug.cgi?id=204580
Web developers: Positive (383 stars)
Other signals: N/A

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it 
has potentially high risk for Android WebView-based applications?
No
Debuggability
Existing grid support in devtools will allow inspection of the grid tracks 
created by the grid-template property values.

Is this feature fully tested by 
web-platform-tests?
Yes. 
https://wpt.fyi/results/css/css-grid/animation?label=experimental&label=master&aligned
Flag name
--enable-blink-features=CSSGridTemplatePropertyInterpolation
Requires code in //chrome?
False

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

Estimated milestones

No milestones specified

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

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

[杨飞]

Hi Ken,

I've just hacked through it!! 
Turns out that things just got a little bit complicated after the 
"ES31ForTesting" context was added.

The final list of hacks:

* In gpu/command_buffer/services/gl_utils.cc
In PopulateNumericCapabilities():
Skip IsES31ForTestingContext check. Always set "minor_version" to 1

* In gpu/command_buffer/services/service_utils.cc
In GenerateGLContextAttribs():
Changing "client_minor_es_version" from 0 to 1.

* In gpu/command_buffer/services/gles2_cmd_decoder.cc
In GetCapabilities():
Changing " minor_version " from 0 to 1.

* In gpu/command_buffer/services/gles2_cmd_decoder_passthrough_handlers.cc
and 
gpu/command_buffer/services/gles2_cmd_decoder_passthrough_handlers_autogen.cc 
Skip all "if(!IsES31ForTestingContext ())" checks.
Commented out all of them because not sure how to run 
"build_cmd_buffer_lib.py".

Thanks.

Fei

On Tuesday, May 17, 2022 at 1:48:03 AM UTC+8 杨飞 wrote:

> Hi Ken,
>
> Thanks for answering.
>
> I haven't given up on this yet. But there's something really difficult for 
> me to get through.
>
> To make it clear, I'm not attempting to bring back the dropped "WebGL2 
> compute" feature. 
> Instead, I just want to enable an underlying GLES3.1 context (powered by 
> ANGLE), so that I can use it in my own fork of Chromium, internally in C++ 
> code.
> Therefore, it won't envolve exposing any addition APIs to JavaScript. It's 
> just about the context creation.
>
> I made some progress by doing to following hacks:
>
> * In gpu/command_buffer/client/implementation_base.cc
> Forcing the capabilites to version 3.1 by:
> In constructor ImplementationBase::ImplementationBase():
>
> if (capabilities_.major_version == 3)
> {
>   capabilities_.minor_version = 1;
>   capabilities_.max_shader_storage_buffer_bindings = 32768;
>  }
>
> * In gpu/command_buffer/services/service_utils.cc
> In GenerateGLContextAttribs():
> Changing "client_minor_es_version" from 0 to 1.
>
> Currently, I'm able to compile a compute shader, creating and binding 
> SSBOs, 
> but it still crashes when I call GLES2Interface::DispatchCompute() to 
> launch a compute shader. (STATUS_ACCESS_VIOLATION)
>
> I feel I still hadn't found the correct places where the GLES context 
> creation is happening, where Blink tells ANGLE which GLES version to use.
>
> I'll really appreciate you if you point me to the correct place to look 
> at. The source code is just too Huge.
>
> Thanks!!
>
> Fei
>
> On Tuesday, May 10, 2022 at 5:44:31 AM UTC+8 Kenneth Russell wrote:
>
>> 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+...@chromium.org.
>>> To view this discussion on th

[blink-dev] The countdown to BlinkOn 16 is almost over!

[Ashley Haman]

Bcc: blink-dev@ and BlinkOn 16 attendees



Hi everyone,



The countdown to BlinkOn 16 is almost over! If you haven't already done so,
now is your last chance to register 
and sign up

to host a 25-minute breakout talk.



BlinkOn 16 will kick off with an optional networking session at 6:30am PDT
followed by opening remarks at 7:00am PDT. Preview the event
 to add these and other
segments to your Hopin agenda and/or calendar so that you don't miss
anything!



If you have any questions or concerns, contact us at blin...@chromium.org
or visit our FAQ at chromium.org/events/blinkon-16.



See you tomorrow!



Best,

BlinkOn Planning Committee

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

[blink-dev] Re: [webkit-dev] Intent to Remove: Legacy Client Hint Mode

[Ari Chivukula]

M104

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

On Tue, May 17, 2022, 10:59 Joe Medley  wrote:

> Hi,
>
> In which version do you intend to remove this?
>
> Joe
>
> On Monday, March 7, 2022 at 7:54:29 AM UTC-8 ari...@chromium.org wrote:
>
>> Contact emails
>>
>> ari...@chromium.org, jadek...@chromium.org, mike...@chromium.org
>>
>> Design Doc
>>
>>
>> https://docs.google.com/document/d/1igtMPtVTiX24bVaUo6tBgx3B16-HmUVPG7iDP5HkzD0/edit
>>
>> Specification
>>
>> https://wicg.github.io/client-hints-infrastructure/
>>
>> Summary
>>
>> One residue of the rapid Client Hints Infrastructure
>>  iteration is the
>> concept of a `legacy` client hint. It’s a set of 4 hints (`dpr`, `width`,
>> `viewport-width`, and `device-memory`) which have a default allowlist of
>> `self` (meaning that they are not sent to third-party subresources unless
>> delegated via Permissions Policy) but behave as though they have a default
>> allowlist of `*` (meaning they are sent to third-party subresources as long
>> as the first-party page requests them) on Android.
>>
>> This `legacy` client concept on Android will be removed and a permissions
>> policy will be required to delegate the 4 affected hints. As of M100, Markup
>> based Client Hint Delegation
>> 
>> is now available to allow delegation via HTML instead of HTTP headers.
>>
>>
>>
>> Blink component
>>
>> Blink>Network>ClientHints
>> 
>>
>>
>>
>> Motivation
>>
>> We want to bring these 4 hints in line with the spec; fixing this will
>> increase privacy on Android by requiring explicit delegation of these hints.
>>
>> TAG review
>>
>> N/A (this change brings Android behavior in line with the spec and better
>> preserves privacy)
>>
>> Compatibility
>>
>> Websites visited by android devices that request the legacy
>> device-memory, dpr, width, and viewport-width would no longer have these
>> hints delegated by default to third-party subresources. This would match
>> the current behavior on desktop. Third-party subresources which need these
>> hints would need to get the first-party that loads them to adopt HTTP
>>  or
>> HTML
>> 
>> delegation of client hints. The design doc
>> 
>> has usage/top-site information, and outreach is underway to ensure
>> third-parties expecting this information are aware of the change. The sites
>> which require default third-party delegation of these hints are likely much
>> lower than the sites which incidentally do so by default. As we encourage
>> Client Hint adoption, we want to ensure dependency doesn’t form on legacy,
>> non-compliant behavior.
>>
>>
>> Interoperability
>>
>> Gecko: Client Hints not yet implemented (considered non-harmful
>> )
>>
>> WebKit: Client Hints not yet implemented
>>
>> Web developers: No feedback yet
>>
>> Debuggability
>>
>> N/A
>>
>> Is this feature fully tested by web-platform-tests?
>>
>> New WPT will be added to ensure these hints are not delegated by default.
>>
>> Tracking bug
>>
>> https://crbug.com/1227043
>>
>> Link to entry on the Chrome Platform Status
>>
>> https://chromestatus.com/feature/5694492182052864
>>
>>
>>

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

[blink-dev] Re: [webkit-dev] Intent to Remove: Legacy Client Hint Mode

['Joe Medley' via blink-dev]

Hi,

In which version do you intend to remove this?

Joe

On Monday, March 7, 2022 at 7:54:29 AM UTC-8 ari...@chromium.org wrote:

> Contact emails
>
> ari...@chromium.org, jadek...@chromium.org, mike...@chromium.org
>
> Design Doc
>
>
> https://docs.google.com/document/d/1igtMPtVTiX24bVaUo6tBgx3B16-HmUVPG7iDP5HkzD0/edit
>
> Specification
>
> https://wicg.github.io/client-hints-infrastructure/
>
> Summary
>
> One residue of the rapid Client Hints Infrastructure 
>  iteration is the 
> concept of a `legacy` client hint. It’s a set of 4 hints (`dpr`, `width`, 
> `viewport-width`, and `device-memory`) which have a default allowlist of 
> `self` (meaning that they are not sent to third-party subresources unless 
> delegated via Permissions Policy) but behave as though they have a default 
> allowlist of `*` (meaning they are sent to third-party subresources as long 
> as the first-party page requests them) on Android.
>
> This `legacy` client concept on Android will be removed and a permissions 
> policy will be required to delegate the 4 affected hints. As of M100, Markup 
> based Client Hint Delegation 
> 
>  
> is now available to allow delegation via HTML instead of HTTP headers.
>
>  
>
> Blink component
>
> Blink>Network>ClientHints 
> 
>
>  
>
> Motivation
>
> We want to bring these 4 hints in line with the spec; fixing this will 
> increase privacy on Android by requiring explicit delegation of these hints.
>
> TAG review
>
> N/A (this change brings Android behavior in line with the spec and better 
> preserves privacy)
>
> Compatibility
>
> Websites visited by android devices that request the legacy device-memory, 
> dpr, width, and viewport-width would no longer have these hints delegated 
> by default to third-party subresources. This would match the current 
> behavior on desktop. Third-party subresources which need these hints would 
> need to get the first-party that loads them to adopt HTTP 
>  or 
> HTML 
> 
>  
> delegation of client hints. The design doc 
> 
>  
> has usage/top-site information, and outreach is underway to ensure 
> third-parties expecting this information are aware of the change. The sites 
> which require default third-party delegation of these hints are likely much 
> lower than the sites which incidentally do so by default. As we encourage 
> Client Hint adoption, we want to ensure dependency doesn’t form on legacy, 
> non-compliant behavior.
>
>  
> Interoperability
>
> Gecko: Client Hints not yet implemented (considered non-harmful 
> )
>
> WebKit: Client Hints not yet implemented
>
> Web developers: No feedback yet
>
> Debuggability
>
> N/A
>
> Is this feature fully tested by web-platform-tests?
>
> New WPT will be added to ensure these hints are not delegated by default.
>
> Tracking bug
>
> https://crbug.com/1227043
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5694492182052864
>
>
>

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

Re: [blink-dev] Intent to Prototype and Ship: User-Agent Client Hints API Updates

[Mike Taylor]

PSA: In https://chromium-review.googlesource.com/c/chromium/src/+/3646649 I 
landed a fix to navigator.userAgentData.toJSON() which has been missing the 
"platform" hint since it the toJSON method was added. 

This is a purely additive bugfix, but please let me know if anyone runs 
into any breakage or has any concerns as a result.

thx,
Mike

On Monday, June 21, 2021 at 10:17:50 AM UTC-4 Mathias Bynens wrote:

> Brilliant, thanks!
>
> On Mon, Jun 21, 2021 at 4:16 PM Mike Taylor  
> wrote:
>
>> Hey Mathias,
>>
>> On 6/21/21 6:46 AM, Mathias Bynens wrote:
>> > The Intent* email template includes a “Debuggability” section, which 
>> > is missing in this case. How would web developers debug this new 
>> > functionality through DevTools? Do we need anything beyond existing 
>> > DevTools functionality in the Network tab? See 
>> > https://goo.gle/devtools-checklist 
>> >  for context.
>>
>> The only DevTools task that needs to be taken care for these changes of 
>> is to ensure that the the new bitness hint is exposed in editable fields 
>> like the others, but that should be fairly mechanical. It's on our radar 
>> to make sure it gets taken care of. The rest should come "for free".
>>
>> Thanks for the question!
>>
>> 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/69110142-a365-495b-ab3a-086913e5e0e3n%40chromium.org.

[blink-dev] Intent to Prototype: Secure Payment Confirmation - Opt-Out Support

[Stephen Mcgruer]

Contact emailssmcgr...@chromium.org

ExplainerNone

Specificationhttps://w3c.github.io/secure-payment-confirmation

Design docshttps://github.com/w3c/secure-payment-confirmation/issues/172

Summary

Adds an 'opt-out' flow to Secure Payment Confirmation. When the (optional)
input flag is set, the SPC UXes will render an 'opt-out' link of some sort
that the user can interact with to indicate to the RP that they wish to be
opted out.


Note: This work is *very experimental*, and this I2P should not be taken as
a sign of anything other than we are experimenting with this proposal.
Blink componentBlink>Payments


Motivation

In certain regions and situations, developers interacting with Secure
Payment Confirmation may need to offer an opt-out experience - in which the
user can indicate that they want their information removed from the
developers server. Traditionally access to the opt-out experience is
embedded directly into the Relying Party's website. However in the case of
SPC the Relying Party may not be part of the web content flow, as the
authentication may be initiated from a third-party website (e.g., a
merchant site). In order to support these needs for an opt-out flow, we are
experimenting with direct support for opt-out in the SPC browser UX. (Note
that Chrome-stored information is NOT in scope here).

Initial public proposal
https://github.com/w3c/secure-payment-confirmation/issues/172

TAG review
TAG review statusNot applicable

Risks

Interoperability and CompatibilityGecko: No signal

WebKit: No signal

Web developers: No signals

Other signals:

WebView application risks

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

No


Debuggability

Normal devtools javascript debugging capabilities should suffice.

Is this feature fully tested by web-platform-tests

?Not at this time.

Flag name
SecurePaymentConfirmationOptOut (expected, not yet landed)

Requires code in //chrome?True

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

Estimated milestones

No milestones specified


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

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/CADY3MaeKbgWe%3DJV%2Bo7_MkYFdjduVxNUshLPd_iuqtSKtZ3xLzg%40mail.gmail.com.

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

[Mike West]

I'm comfortable with the risk here, given both the low overall upper bound
on the number of requests that might be affected (and the presumably lower
number of page views), coupled with the security benefits of hardening CORB
and simplifying the mental model for developers. LGTM1.

That said, I agree with Yoav that we should get the spec into Fetch to the
extent possible. Given support from Mozilla and us, that could hopefully be
a straightforward replacement of https://fetch.spec.whatwg.org/#corb, with
TODO blocks around the bits we're not sure of yet (JavaScript sniffing, for
instance). Łukasz, perhaps you could collaborate with +Anne van Kesteren
 to get that done? If you don't have time, I can look
around for someone to support y'all (+Daniel Vogelheim
, for instance! Hello, Daniel!).

-mike


On Tue, May 17, 2022 at 8:50 AM Yoav Weiss  wrote:

>
>
> On Thu, May 12, 2022 at 12:12 AM Łukasz Anforowicz 
> wrote:
>
>>
>>
>> On Wed, May 11, 2022 at 12:24 AM Yoav Weiss 
>> wrote:
>>
>>>
>>>
>>> On Wed, May 11, 2022 at 2:56 AM Łukasz Anforowicz 
>>> wrote:
>>>
 On Mon, May 9, 2022 at 11:35 PM Mike West  wrote:

> 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?
>
> 0.01% is just a conservative rounding of the 0.002%-0.006% numbers
 from the other doc.  (Sorry about that... https://xkcd.com/2585/ seems
 somewhat applicable I guess...)

>>>
>>> Also, that number is presented as a percentage from HTTP requests. Do
>>> you have the data on how this presents itself as a percentage of page views?
>>>
>>
>> No, we don't have such a breakdown of the data.
>>
>> One reason is that ORB (and code gathering ORB's telemetry data) is
>> hosted inside the NetworkService process which is mostly unaware of pages
>> and page views (I think;  I guess UKM would require knowing about pages,
>> but I wasn't able to find UKM-related code under //services/network).  We
>> could try to count the various ORB outcomes per URLLoaderFactory (which
>> roughly corresponds to a single HTML frame;  I note that in the past
>> about:blank frame might have shared a URLLoaderFactory with their
>> opener/parent/initiator - that's probably ok), but getting this data would
>> take time...
>>
>
> OK, would it be fair to assume that at least for no-cors range requests
> (most likely video/audio requests), there would be more than one per page
> view, and hence we could expect page view based %ages to be significantly
> lower?
>
>
>>
>> If the majority of these requests are range requests, there's reason to
>>> believe there was more than one per page view.
>>>
>>
>> We can try to estimate how many responses report HTTP 206 status code.  I
>> looked at Net.HttpResponseCode and "206: Partial Content" accounts for
>> around 0.35% - 1.13% of all HTTP responses (depending on the platform I
>> looked at).  I've added more detailed data + links to a new section in the 
>> ORB
>> telemetry results - Mar 2022
>> 
>>  document.
>>
>>>
>>>


>
>1.
>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?
>
> Hmmm... this is a fair point.  We have some docs, but I am not sure if
 they are distilled/clear enough for public consumption.  Notably, the 
 "Gradual
 CORB -> ORB transition " doc talks about the main difference
 between full ORB and ORB v0.1 (JS sniffing -vs- HTML/JSON/XML sniffing) and
 also provides a fairly comprehensive list of other, minor differences is in
 the "Appendix: ORB v0.1 vs full ORB differences
 "
 section of the doc.

 But... I think that explaining Chrome b