Re: [EXTERNAL] Re: [blink-dev] Intent to Implement and Ship: Add support for Promise to Blobs in clipboard item

[Mike West]

On Fri, Oct 29, 2021 at 3:56 AM Anupam Snigdha  wrote:

> Let me try to clarify few things. Currently there is *no *user activation
> requirements in async clipboard read/write in Chromium browsers. e.g.
> https://clumsy-garnet-meeting.glitch.me/. Just load this page and refresh
> it without clicking anywhere on the page, you will see the content will get
> written to the clipboard without any gesture.
>

Writing to the clipboard is quite distinct from reading from the clipboard,
isn't it? https://gifted-stingy-ketchup.glitch.me/ actually surfaces a
permission prompt when executing `navigator.clipboard.read()`, which is
more in line with my expectations.


> Safari, due to security concerns, implemented a gesture requirement to
> access clipboard via async clipboard APIs. The read()/write() method can
> only be called inside a trusted user gesture event handler, but the
> promises to Blobs can be resolved later which gives the web authors the
> flexibility to not block the thread to populate the payload.
>

The question in my mind relates to the content of that promise's
resolution. Is the resulting blob created at the point at which the
`read()` method is called (as a "copy of the system clipboard data")? Or is
the resolution "active" in some sense, returning a blob representing
whatever happens to be in the clipboard at the time the promise is resolved?


> In Pickling API
> ,
> which adds capability to the async clipboard API to read/write unsanitized
> content, initially we added a transient user activation requirement because
> the API lets web authors read/write unsanitized content using a custom
> clipboard format. Both Chrome security team(see "User Gesture Requirement"
> section in https://github.com/w3c/editing/issues/315) and TAG(
> https://github.com/w3ctag/design-reviews/issues/636#issuecomment-857829725)
> raised the concern that transient user activation is NOT sufficient to give
> clipboard access to web authors.
>

That sounds right to me, and points again to the question above: does a
click give you access to the clipboard _now_, or at some arbitrary point in
the future?

This change is required to not only support the Pickling API's user gesture
> event handling requirements, but also improve the security by adding an
> even stronger signal of the user intent to copy. We also talked about this
> in the Editing WG call with Apple and they are opposed to transient user
> activation and I believe Firefox raised concerns as well(
> https://github.com/w3c/clipboard-apis/issues/52#issuecomment-599443986).
>
> Re: clipboard spec: I believe the spec needs to be updated so I've started
> this PR: https://github.com/w3c/clipboard-apis/pull/158.
>
> Please let me know if you have any other quesions/concerns.
>
> -Anupam
>
>
>
> --
> *From:* Mike West 
> *Sent:* Thursday, October 28, 2021 12:17 PM
> *To:* Anupam Snigdha 
> *Cc:* bratel...@gmail.com ; dome...@chromium.org <
> dome...@chromium.org>; yoavwe...@chromium.org ;
> blink-dev@chromium.org ; ann...@annevk.nl <
> ann...@annevk.nl>; m...@chromium.org ; Bo Cupp <
> pc...@microsoft.com>
> *Subject:* Re: [EXTERNAL] Re: [blink-dev] Intent to Implement and Ship:
> Add support for Promise to Blobs in clipboard item
>
> We discussed this in the API owners' meeting, and there's some confusion
> both about what's specified, and what Chromium's implementation does. I
> read https://github.com/w3c/clipboard-apis/issues/161
> 
> as suggesting that the `ClipboardItem` has a promise which, when resolved,
> provides access to the current contents of the clipboard (and a response
> suggests that there's a 1 second limit on that). Step 2.3 of
> https://www.w3.org/TR/clipboard-apis/#dom-clipboard-read
> 
> suggests that read operations return "a copy of the system clipboard data",
> which seems inconsistent.
>
> Can y'all help me understand what our model is here? And what the model
> ought to be, if it diverges from what we've currently implemented?
>
> -mike
>
>
> On Wed, Oct 27, 2021 at 8:07 PM 'Anupam Snigdha' via blink-dev <

Re: [blink-dev] Re: Intent to Continue Experimenting: Digital Goods API

[Glen Robertson]

Hi Blink Owners,

We have now implemented DGAPI v2.0 which is in M96 as a separate OT. The
DGAPI v1 code has been removed in M96 so the v1 trial will not be exposed
to versions greater than M95.

However, the OT system is based around dates instead of milestones, and the
v1 OT is currently set to end on 2021-12-14, two weeks after M96 hits
stable. At that point we expect a large percentage of CrOS users to still
be on M95 (or lower), with that percentage decreasing asymptotically over
the following weeks. As previously discussed, we would strongly like to
avoid dropping support for users in between the origin trials and launch.

Would it be possible to extend the end date of this v1 API trial (for M95
and below only) to allow more time for users to update to M96 before the
API is cut off? Two months total would allow time for the majority of users
to update (2022-01-30).

Web developers wishing to use DGAPI are already required to update their
code to support the new version in M96, so there is no risk of burn-in of
the v1 API.

Thanks for considering,
-Glen

On Fri, 10 Sept 2021 at 06:25, Mike West  wrote:

> LGTM3.
>
> -mike
>
> On Thu 9. Sep 2021 at 22:22 Daniel Bratell  wrote:
>
>> LGTM2 to the plan and comments outlined by Chris.
>>
>> /Daniel
>> On 2021-09-09 22:18, Chris Harrelson wrote:
>>
>> Hi Glen,
>>
>> Thanks for your patience while we (collectively - your team, API owners,
>> and others) worked through a response to your request.
>>
>> The API owners met today and discussed this request to extend the Origin
>> Trial. Here is some new data I got:
>>
>> * The team showed evidence of recent further engagement with partners and
>> getting as soon as possible to the v2 you mentioned. The Web Payments team
>> also signed up to help accelerate that.
>> * There is new evidence (to me) of the potential & importance of this API
>> for the web that I hadn't considered. This would really help the web
>> platform be more useful, IMO.
>>
>> I'm still concerned about the length of the trial and its impact on
>> burn-in and other risks of a long OT. But I'm now ok with approving this
>> request.
>>
>> Finally, we also concluded that because of the length of the Origin
>> Trial, it's outside the bounds of approval via one LGTM, and requires
>> three. So please wait for two more LGTMs.
>>
>> LGTM1 to extend this trial to M96.
>>
>>
>> On Thu, Sep 2, 2021 at 9:32 PM Glen Robertson 
>> wrote:
>>
>>> Hi Blink Owners,
>>>
>>> Have you had a chance to consider this yet? We are quickly approaching
>>> the end date of the current OT (2021-09-14).
>>>
>>> On Fri, 27 Aug 2021 at 14:56, Glen Robertson 
>>> wrote:
>>>
 Would it be possible for us to extend by 2 milestones to M95
 (inclusive) instead? We believe we can get a new v2 API (which will be
 a significant breaking change) implemented in time for M96; M94 is already
 in beta and M95 will not ship on CrOS, so the earliest we can get new code
 out to developers is in M96 anyway. This would make our total OT timeline
 M88 to M95 (8 milestones total), which is within the maximum OT time limit
 of 8 milestones Alex mentioned above (in fact shorter total time due to the
 changing milestone period). We would very much like to avoid the disruption
 to developers of having the OT turned off and this functionality being
 entirely unavailable during the intervening period before the new OT 
 starts.

 We understand your concern about an extended OT risking burn-in, but
 this is a complex API for developers to start using, as they have to create
 a product and payment flow around it. Usage of the API is still low — a few
 hundred calls per day total for all methods (excluding
 getDigitalGoodsService, which is used for feature detection even when
 the API is otherwise unavailable).

 Shipping a subset of the API now wouldn't help because we are proposing
 breaking changes to enough of the API that it probably isn't useful to ship
 the rest. Also, we are proposing a breaking change in the behaviour of the
 feature detection function that must be called before any other calls, so
 it would be mildly risky to ship that immediately.

 I have made a draft version of the proposed v2 API publicly available
 
 (though it is still being reviewed). It will be a significant breaking
 change to the API.
 Thanks,
 -Glen

 On Fri, 20 Aug 2021 at 06:33, Chris Harrelson 
 wrote:

> Hi,
>
> The API owners met to discuss this intent today (Chris, Yoav, Alex,
> Mike). We're glad to see you are still pursuing the API and responding to
> feedback with the v2 API.
>
> However, 9 milestones is very long, much longer than we are typically
> comfortable with, and within the range where there starts to be 
> substantial
> risk of burn-in. 

Re: [blink-dev] Intent to Ship: New Canvas 2D API

[Yoav Weiss]

Hey Domenic! :)

On Thu, Oct 28, 2021 at 11:00 PM Domenic Denicola 
wrote:

>
>
> On Thu, Oct 28, 2021 at 3:48 PM 'Aaron Krajeski' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> yoavweiss@:
>>
>> Great video, thanks for that!!
>>
>>   Thanks!
>>
>> Were the concerns WebKit raised on the issue
>>  addressed? Can you expand
>> on that front?
>>
>>   Yes, othermaciej@'s comments lead to us changing the name of that
>> function to `reset` instead of `clear`.
>>
>> Is the hold-up on the Filters PR editorial or something more fundamental?
>>
>>   The hold-up is mostly over the question of whether `new
>> CanvasFilter({filter: "someNonExistantFilterType"})` should throw an error.
>> You can read the (very long) discussion in the pull request
>> . Unfortunately it's been
>> extremely hard to reach consensus on that specific issue for the past 3
>> months. Any comments from this group that would help drive us towards
>> consensus would be much appreciated!
>>
>
> FWIW the two HTML editors on the thread (myself and Anne, with our HTML
> editor hats on), as well as Mozilla (via Anne with his Mozilla hat on),
> prefer the throwing behavior. I think in most cases to overcome that
> position we would need some really strong reasons why the Chromium project
> believes the non-throwing behavior is better. It's not clear to me how
> strong Chromium's position is on this issue, and whether it's worth
> delaying the feature over. (Or indeed, delaying all the features, since the
> plan seems to be to bundle them together?)
>

My concerns with the throwing behavior are similar to the ones we have
discussed
 in
the context of MediaSession actions.
If we go with the throwing behavior, every future addition of filters would
have a significant interop risk, in case adopting developers won't use
try/catch properly. If they do that and they are not testing in
not-yet-supporting browsers, their apps are likely to break entirely in
those browsers.
If we go with a silent failure + feature detection approach, developers
using the feature without properly detecting it may not have the desired
visual effects they are going for, but won't have unrelated parts of their
app break.

>From my perspective (with my API owner hat on), less risk is better, and
the second approach seems less risky to me.


>
>>
>> Are these features individually detectable? Do we have reasonable
>> developer advice on how we want folks to use those features with backwards
>> compat/fallbacks in mind?
>>
>>   We're working with the DevRel team on some polyfills that will be
>> included in a web.dev article that is launching. All the features are
>> trivially detectable except for perhaps contextlost/restored events. I can
>> look further into that if you'd like?
>>
>
> Those two are feature detectable using 'oncontextlost' in
> Document.prototype, happily enough.
>
>
>>   For polyfills, there are different degrees of effectiveness/difficulty.
>>   Easy: roundRect (small perf hit), reset
>>   Hard, maybe we should just advertise a polyfill that avoids errors:
>> filters, conic gradient, text modifiers
>>   Doesn't make sense to polyfill: contextloss, willReadFrequently
>>
>> On Thursday, October 21, 2021 at 3:07:21 AM UTC-4 yoav...@chromium.org
>> wrote:
>>
>>> Thanks for modernizing Canvas! :)
>>>
>>> On Thu, Oct 14, 2021 at 11:06 PM Aaron Krajeski 
>>> wrote:
>>>

 *Contact emails*aar...@chromium.org, fs...@chromium.org

 *Explainer*
 https://github.com/fserb/canvas2d
 https://youtu.be/dfOKFSDG7IM

>>>
>>> Great video, thanks for that!!
>>>
>>>

 *Specification*
 Context Lost Event
 
 Context Restored Event
 
 Will Read Frequently
 
 New Text Modifiers
 
 Reset
 

>>>
>>> Were the concerns WebKit raised on the issue
>>>  addressed? Can you expand
>>> on that front?
>>>
>>>
 RoundRect

 Conic
 Gradient

 
 Filters  (still in progress)

>>>
>>> Is the hold-up on the Filters PR editorial or something more fundamental?
>>> I noticed Mozilla's opposition on their position. Is that something that
>>> has changed since?
>>>
>>> Are these features individually detectable? Do we hav

Re: [blink-dev] Intent to Prototype and Ship: self.structuredClone

[Yoav Weiss]

LGTM1

On Thu, Oct 28, 2021 at 10:56 PM Andreu Botella 
wrote:

> I don't think the differences are listed anywhere. I know there are some
> because of the failures in
> https://wpt.fyi/results/html/infrastructure/safe-passing-of-structured-data?label=experimental&label=master&aligned,
> but there might be others that aren't tested. Although it seems like some
> of the failures in the shared-array-buffer folder seem to be bugs with
> the tests rather than with the implementations.
>

OK, as these differences are already exposed, I don't think shipping this
significantly increases risk. The fact that they're covered by WPTs makes
it more likely we'd (eventually) converge on the specified behavior.


> On Wednesday, October 27, 2021 at 11:12:32 PM UTC+2 fs...@chromium.org
> wrote:
>
>> This is amazing! :)
>>
>> I agree it shouldn't block this, but do we have anywhere written what
>> are the browser's differences on structured clone algorithms? Is it a spec
>> issue? Could we add WPT tests for it?
>>
>> On Wed, Oct 27, 2021 at 2:45 PM Andreu Botella 
>> wrote:
>>
>>> * Contact emails*
>>> and...@andreubotella.com, jbr...@chromium.org, su...@chromium.org
>>>
>>> *Explainer*
>>> https://github.com/whatwg/html/issues/793
>>>
>>> *Specification*
>>> https://html.spec.whatwg.org/#structured-cloning
>>>
>>> * Summary*
>>> Enables using the HTML structured clone algorithm synchronously for
>>> cloning and transferring objects within a single realm.
>>>
>>> * Initial public proposal*
>>> https://github.com/whatwg/html/issues/793
>>> https://github.com/whatwg/html/pull/3414
>>>
>>> *Blink component*
>>> Blink>Messaging
>>> 
>>>
>>> * TAG review*
>>> This is just exposing existing browser functionality, with a two-line
>>> spec. It doesn’t seem like there’s much to discuss architecturally, but
>>> I’ll file for review if the community thinks it would help.
>>>
>>> *TAG review status*
>>> Not applicable
>>>
>>> * Risks*
>>>
>>> * Interoperability and Compatibility*
>>> Low. There are some differences across the browsers’ implementations of
>>> the structured cloning algorithm, but they are very minor and already
>>> present in other APIs that use it.
>>>
>>> Gecko: Shipped/Shipping (
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1722576)
>>> Edge: No signal
>>> WebKit: Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=228331)
>>>
>>>
>>> Web developers: Positive (
>>> https://github.com/whatwg/html/pull/3414#issuecomment-854051942 and
>>> following comments). There seems to be a lot of demand for a built-in deep
>>> clone, and while structured clone is not exactly that, it fulfills many of
>>> the use cases.
>>>
>>> * Debuggability*
>>> n/a
>>>
>>> * Is this feature fully tested by web-platform-tests
>>> ?*
>>> Yes
>>> 
>>>
>>> * Requires code in //chrome?*
>>> False
>>>
>>> * Tracking bug*
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1233571
>>>
>>> *Estimated milestones*
>>> No milestones specified
>>>
>>> * Link to entry on the Chrome Platform Status*
>>> https://chromestatus.com/feature/5630001077551104
>>>
>>> *Requesting approval to ship? *
>>> Yes. This is a relatively small feature which exposes existing
>>> functionality.
>>>
>>> --
>>> 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/e7299674-54df-4f4d-8c30-d922ebf4e47cn%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/74ab6933-2925-455a-9e24-a95ae08f3cf5n%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/CAL5BFfVnABD048Xi6r3J9%2BGwBmYUX6pM1Auqp6MQSuwJUaNejg%40mail.gmail.com.

Re: [blink-dev] RE: [EXTERNAL] Re: Intent to Implement and Ship: Feature policy for Keyboard API

['Anupam Snigdha' via blink-dev]

Thanks Daniel! I have opened a bug to investigate this issue: 
https://bugs.chromium.org/p/chromium/issues/detail?id=1264662

From: Daniel Bratell 
Sent: Thursday, October 28, 2021 12:22 PM
To: blink-dev 
Cc: Dave Tapuska ; sligh...@chromium.org 
; blin...@chromium.org ; 
yoav...@chromium.org ; Bo Cupp ; 
Scott Low ; gar...@chromium.org ; 
dom...@chromium.org ; Anupam Snigdha 

Subject: Re: [blink-dev] RE: [EXTERNAL] Re: Intent to Implement and Ship: 
Feature policy for Keyboard API

LGTM3, (but follow up with Dave about the implementation details, and make sure 
to listen to any late comments from other reviews)

On Wednesday, 27 October 2021 at 23:52:31 UTC+2 Dave Tapuska wrote:
For a cross origin renderer the browser process would be involved because the 
allow attribute restriction is in one renderer, and the enforcement of the 
permission is in the renderer that wants to use it. I do not think it is 
difficult to check the policy on the mojo request of the keyboard map in the 
browser process. Although you'll likely want some additional response 
enums.

I ask because we would need to adjust this model for fenced frames 
implementation and the enforcement on the browser side better aligns with our 
security design.

dave.

On Wed, Oct 27, 2021 at 5:42 PM Anupam Snigdha  wrote:

I’m not sure if checking that in the browser would make sense here because the 
allow attribute restriction is specified in the DOM and the browser process 
isn’t involved. I did ask this in the slack channel and pretty much got the 
same response that the renderer should be enforcing this check. If you have any 
other ideas though, then please let me know!



From: Dave Tapuska 
Sent: Wednesday, October 27, 2021 2:27 PM
To: Anupam Snigdha 
Cc: sligh...@chromium.org; blin...@chromium.org; yoav...@chromium.org; Bo Cupp 
; Scott Low ; gar...@chromium.org; 
dom...@chromium.org
Subject: Re: [blink-dev] RE: [EXTERNAL] Re: Intent to Implement and Ship: 
Feature policy for Keyboard API



I was looking at the implementation of this. Is it possible to move the check 
of the policy to be based in the browser when the map is fetched? As of right 
now the policy enforcement is on the renderer side, so a compromised renderer 
can request the keyboard map.



dave.



On Wed, Oct 27, 2021 at 4:53 PM 'Anupam Snigdha' via blink-dev 
 wrote:

Created an issue to get feedback from TAG: 
https://github.com/w3ctag/design-reviews/issues/685

I added this to the webappsec-permission policy: 
https://github.com/w3c/webappsec-permissions-policy/pull/428,
 but will also create an issue to investigate Permissions API integration. 
Thanks!



From: Alex Russell 
Sent: Thursday, October 21, 2021 12:21 PM
To: blink-dev 
Cc: Yoav Weiss ; Anupam Snigdha ; 
blin...@chromium.org ; Bo Cupp ; 
Scott Low ; gar...@chromium.org ; 
Domenic Denicola 
Subject: Re: [blink-dev] RE: [EXTERNAL] Re: Intent to Implement and Ship: 
Feature policy for Keyboard API



Not consulting the TAG in this instance may have been an error. In general, we 
should be putting things into consistent surfaces that they affect. In this 
case, it seems like we're missing integrations w/ the Permissions API.



I'm LGTM2 on this intent contingent on a commitment to follow up w/ the TAG as 
an FYI and a commitment to investigate Permissions API integration.



Best Regards,



Alex



On Sunday, October 17, 2021 at 10:16:58 PM UTC-7 Yoav Weiss wrote:

LGTM1



On Sat, Oct 16, 2021 at 12:35 AM Dome

Re: [EXTERNAL] Re: [blink-dev] Intent to Implement and Ship: Add support for Promise to Blobs in clipboard item

['Anupam Snigdha' via blink-dev]

Hi Mike,

Let me try to clarify few things. Currently there is no user activation 
requirements in async clipboard read/write in Chromium browsers. e.g. 
https://clumsy-garnet-meeting.glitch.me/. Just load this page and refresh it 
without clicking anywhere on the page, you will see the content will get 
written to the clipboard without any gesture.
Safari, due to security concerns, implemented a gesture requirement to access 
clipboard via async clipboard APIs. The read()/write() method can only be 
called inside a trusted user gesture event handler, but the promises to Blobs 
can be resolved later which gives the web authors the flexibility to not block 
the thread to populate the payload.

In Pickling 
API,
 which adds capability to the async clipboard API to read/write unsanitized 
content, initially we added a transient user activation requirement because the 
API lets web authors read/write unsanitized content using a custom clipboard 
format. Both Chrome security team(see "User Gesture Requirement" section in 
https://github.com/w3c/editing/issues/315) and 
TAG(https://github.com/w3ctag/design-reviews/issues/636#issuecomment-857829725) 
raised the concern that transient user activation is NOT sufficient to give 
clipboard access to web authors.

This change is required to not only support the Pickling API's user gesture 
event handling requirements, but also improve the security by adding an even 
stronger signal of the user intent to copy. We also talked about this in the 
Editing WG call with Apple and they are opposed to transient user activation 
and I believe Firefox raised concerns as 
well(https://github.com/w3c/clipboard-apis/issues/52#issuecomment-599443986).

Re: clipboard spec: I believe the spec needs to be updated so I've started this 
PR: https://github.com/w3c/clipboard-apis/pull/158.

Please let me know if you have any other quesions/concerns.

-Anupam




From: Mike West 
Sent: Thursday, October 28, 2021 12:17 PM
To: Anupam Snigdha 
Cc: bratel...@gmail.com ; dome...@chromium.org 
; yoavwe...@chromium.org ; 
blink-dev@chromium.org ; ann...@annevk.nl 
; m...@chromium.org ; Bo Cupp 

Subject: Re: [EXTERNAL] Re: [blink-dev] Intent to Implement and Ship: Add 
support for Promise to Blobs in clipboard item

We discussed this in the API owners' meeting, and there's some confusion both 
about what's specified, and what Chromium's implementation does. I read 
https://github.com/w3c/clipboard-apis/issues/161
 as suggesting that the `ClipboardItem` has a promise which, when resolved, 
provides access to the current contents of the clipboard (and a response 
suggests that there's a 1 second limit on that). Step 2.3 of 
https://www.w3.org/TR/clipboard-apis/#dom-clipboard-read
 suggests that read operations return "a copy of the system clipboard data", 
which seems inconsistent.

Can y'all help me understand what our model is here? And what the model ought 
to be, if it diverges from what we've currently implemented?

-mike


On Wed, Oct 27, 2021 at 8:07 PM 'Anupam Snigdha' via blink-dev 
mailto:blink-dev@chromium.org>> wrote:

Thanks Daniel for raising this concern. I have opened an issue to discuss with 
the Editing WG: 
https://github.com/w3c/clipboard-apis/issues/161.
 In the current implementation, I think verifying whether the Document is 
active or not after the promises have been resolved should mitigate some of the 
concerns.



From: Daniel Bratell mailto:bratel...@gmail.com>>
Sent: Thursday, October 21, 2021 12:48 PM
To: Domenic Denicola mailto:dome...@chromium.org>>; Yoav 
Weiss mailto:yoavwe...@chromium.org>>
Cc: blink-dev mailto:blink-

[blink-dev] Intent to Ship: forced-color-adjust: preserve-parent-color

['Sara Tang' via blink-dev]

Contact emails
sart...@microsoft.com, 
alison.ma...@microsoft.com

Explainer
https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Accessibility/PreserveParentColor/explainer.md

Specification
https://www.w3.org/TR/css-color-adjust-1/#forced-color-adjust-prop

Summary

Adds the ‘preserve-parent-color' value to the ‘forced-color-adjust' CSS 
property. When Forced Colors Mode is enabled, the ‘color’ property is 
inherited, and we’ve set ‘forced-color-adjust: preserve-parent-color', the 
‘color’ property will compute to the used value of its parent. Otherwise, 
‘forced-color-adjust: preserve-parent-color' value behaves the same as 
‘forced-color-adjust: none’.

Contact emails
sart...@microsoft.com, 
alison.ma...@microsoft.com

Explainer
https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Accessibility/PreserveParentColor/explainer.md

Specification
https://www.w3.org/TR/css-color-adjust-1/#forced-color-adjust-prop

Summary

Adds the ‘preserve-parent-color' value to the ‘forced-color-adjust' CSS 
property. When Forced Colors Mode is enabled, the ‘color’ property is 
inherited, and we’ve set ‘forced-color-adjust: preserve-parent-color', the 
‘color’ property will compute to the used value of its parent. Otherwise, 
‘forced-color-adjust: preserve-parent-color' value behaves the same as 
‘forced-color-adjust: none’.

Motivation

‘forced-color-adjust' is a CSS property that allows developers to opt out of 
Forced Colors Mode.

Previously, there were two supported values: ‘auto’ and ‘none’, which can be 
used to control whether or not an element’s styles are adjusted by the UA in 
Forced Colors Mode. A third value, ‘preserve-parent-color', has recently been 
introduced in the spec, which provides similar behavior to ‘none’, except that 
it also allows an element to inherit its parent's used ‘color’ value. In other 
words, ‘preserve-parent-color' provides the ability for an element to inherit 
its parent’s Forced Colors Mode adjusted ‘color’ value.

The intention of ‘preserve-parent-color’ is to get a reasonable behavior for 
SVG icons that utilize ‘currentColor’ when styling ‘fill’ and ‘stroke’ in 
Forced Colors Mode, as described in [css-color-adjust-1] Spec currently breaks 
use of currentColor for SVG icons in WHCM · Issue #6310 · w3c/csswg-drafts · 
GitHub.

The use of ‘currentColor’ when styling an SVG icon is a common pattern used by 
authors to ensure an accessible experience in Forced Colors Mode. For example, 
in this sample logo, an author 
would expect the logo to automatically adjust to use the ‘CanvasText’ system 
color for ‘fill’ and ‘stroke’ in Forced Colors Mode, as a result of setting 
each to ‘currentColor’.

This behavior, however, became broken when we moved from forcing colors at 
computed value time to used value time: [css-color-adjust-1] Is forced color 
computed or used value? · Issue #4915 · w3c/csswg-drafts · 
GitHub. Instead of inheriting 
‘CanvasText’, as before, the above sample 
logo would inherit the computed 
‘color’ value of its parent, resulting in a logo that is no longer readable in 
Forced Colors Mode.

The new ‘preserve-parent-color' value was added to address this common SVG use 
case. By changing the default value of ‘forced-color-adjust’ for SVGs from 
‘none’ to ‘preserve-parent-color', SVG icons that make use of ‘currentColor’ 
will now inherit the used ‘color’ value of its parent, as expected.

It is important to note that this may break SVGs that expect the opposite 
inheritance behavior for the ‘color’ property. However, the behavior of 
`preserve-parent-color` handles the most common SVG use cases, and the behavior 
better matches legacy implementations of High Contrast Mode.

Blink component
Blink>CSS

Search tags
css, 
forced, 
colors, 
forced-colors, 
forced-color-adjust,
 
preserve-parent-color

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

TAG review status
Issues open

Risks


Interoperability and Compatibility

Interoperability Risks Gecko has shipped a version of Forced Colors Mode 
without support for ‘forced-color-adjust’. Although there is an open bug for 
adding support (https://bugzilla.mozilla.org/show_bug.cgi?id=1591210), 
development has not been started yet. Compatibility Risks We are updating the 
defa

Re: [blink-dev] Intent to Ship: New Canvas 2D API

[Domenic Denicola]

On Thu, Oct 28, 2021 at 3:48 PM 'Aaron Krajeski' via blink-dev <
blink-dev@chromium.org> wrote:

> yoavweiss@:
>
> Great video, thanks for that!!
>
>   Thanks!
>
> Were the concerns WebKit raised on the issue
>  addressed? Can you expand on
> that front?
>
>   Yes, othermaciej@'s comments lead to us changing the name of that
> function to `reset` instead of `clear`.
>
> Is the hold-up on the Filters PR editorial or something more fundamental?
>
>   The hold-up is mostly over the question of whether `new
> CanvasFilter({filter: "someNonExistantFilterType"})` should throw an error.
> You can read the (very long) discussion in the pull request
> . Unfortunately it's been
> extremely hard to reach consensus on that specific issue for the past 3
> months. Any comments from this group that would help drive us towards
> consensus would be much appreciated!
>

FWIW the two HTML editors on the thread (myself and Anne, with our HTML
editor hats on), as well as Mozilla (via Anne with his Mozilla hat on),
prefer the throwing behavior. I think in most cases to overcome that
position we would need some really strong reasons why the Chromium project
believes the non-throwing behavior is better. It's not clear to me how
strong Chromium's position is on this issue, and whether it's worth
delaying the feature over. (Or indeed, delaying all the features, since the
plan seems to be to bundle them together?)


>
> Are these features individually detectable? Do we have reasonable
> developer advice on how we want folks to use those features with backwards
> compat/fallbacks in mind?
>
>   We're working with the DevRel team on some polyfills that will be
> included in a web.dev article that is launching. All the features are
> trivially detectable except for perhaps contextlost/restored events. I can
> look further into that if you'd like?
>

Those two are feature detectable using 'oncontextlost' in
Document.prototype, happily enough.


>   For polyfills, there are different degrees of effectiveness/difficulty.
>   Easy: roundRect (small perf hit), reset
>   Hard, maybe we should just advertise a polyfill that avoids errors:
> filters, conic gradient, text modifiers
>   Doesn't make sense to polyfill: contextloss, willReadFrequently
>
> On Thursday, October 21, 2021 at 3:07:21 AM UTC-4 yoav...@chromium.org
> wrote:
>
>> Thanks for modernizing Canvas! :)
>>
>> On Thu, Oct 14, 2021 at 11:06 PM Aaron Krajeski 
>> wrote:
>>
>>>
>>> *Contact emails*aar...@chromium.org, fs...@chromium.org
>>>
>>> *Explainer*
>>> https://github.com/fserb/canvas2d
>>> https://youtu.be/dfOKFSDG7IM
>>>
>>
>> Great video, thanks for that!!
>>
>>
>>>
>>> *Specification*
>>> Context Lost Event
>>> 
>>> Context Restored Event
>>> 
>>> Will Read Frequently
>>> 
>>> New Text Modifiers
>>> 
>>> Reset
>>> 
>>>
>>
>> Were the concerns WebKit raised on the issue
>>  addressed? Can you expand
>> on that front?
>>
>>
>>> RoundRect
>>>
>>> Conic
>>> Gradient
>>>
>>> 
>>> Filters  (still in progress)
>>>
>>
>> Is the hold-up on the Filters PR editorial or something more fundamental?
>> I noticed Mozilla's opposition on their position. Is that something that
>> has changed since?
>>
>> Are these features individually detectable? Do we have reasonable
>> developer advice on how we want folks to use those features with backwards
>> compat/fallbacks in mind?
>>
>>
>>>
>>> *Summary*
>>> Updated functionality for the Canvas2D API. Adds seven new
>>> features/functions to CanvasRenderingContext2D:
>>>
>>> - "ContextLost" and "ContextRestored" events
>>> - "willReadFrequently" option for canvases where lots of readback is
>>> expected
>>> - More CSS text modifier support
>>> - A reset function
>>> - A roundRect draw primitive
>>> - Conic gradients
>>> - Better support for SVG filters
>>>
>>> https://github.com/fserb/canvas2d
>>>
>>> *Blink component*
>>> Blink>Canvas
>>> 
>>>
>>>
>>> *TAG review status*Resolution: satisfied
>>> 
>>>
>>> *Risks*
>>> Security and privacy team expressed concerns with ContextLost and
>>> ContextRestored events during the intent to implement phase. These concerns
>>> were addressed by re-desig

Re: [blink-dev] Intent to Prototype and Ship: self.structuredClone

[Andreu Botella]

I don't think the differences are listed anywhere. I know there are some 
because of the failures in 
https://wpt.fyi/results/html/infrastructure/safe-passing-of-structured-data?label=experimental&label=master&aligned,
 
but there might be others that aren't tested. Although it seems like some 
of the failures in the shared-array-buffer folder seem to be bugs with the 
tests rather than with the implementations.

On Wednesday, October 27, 2021 at 11:12:32 PM UTC+2 fs...@chromium.org 
wrote:

> This is amazing! :)
>
> I agree it shouldn't block this, but do we have anywhere written what 
> are the browser's differences on structured clone algorithms? Is it a spec 
> issue? Could we add WPT tests for it?
>
> On Wed, Oct 27, 2021 at 2:45 PM Andreu Botella  
> wrote:
>
>> * Contact emails*
>> and...@andreubotella.com, jbr...@chromium.org, su...@chromium.org 
>>
>> *Explainer*
>> https://github.com/whatwg/html/issues/793 
>>
>> *Specification*
>> https://html.spec.whatwg.org/#structured-cloning 
>>
>> * Summary*
>> Enables using the HTML structured clone algorithm synchronously for 
>> cloning and transferring objects within a single realm. 
>>
>> * Initial public proposal*
>> https://github.com/whatwg/html/issues/793 
>> https://github.com/whatwg/html/pull/3414 
>>
>> *Blink component*
>> Blink>Messaging 
>> 
>>  
>>
>> * TAG review*
>> This is just exposing existing browser functionality, with a two-line 
>> spec. It doesn’t seem like there’s much to discuss architecturally, but 
>> I’ll file for review if the community thinks it would help. 
>>
>> *TAG review status*
>> Not applicable 
>>
>> * Risks*
>>
>> * Interoperability and Compatibility*
>> Low. There are some differences across the browsers’ implementations of 
>> the structured cloning algorithm, but they are very minor and already 
>> present in other APIs that use it. 
>>
>> Gecko: Shipped/Shipping (
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1722576) 
>> Edge: No signal 
>> WebKit: Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=228331) 
>>
>>
>> Web developers: Positive (
>> https://github.com/whatwg/html/pull/3414#issuecomment-854051942 and 
>> following comments). There seems to be a lot of demand for a built-in deep 
>> clone, and while structured clone is not exactly that, it fulfills many of 
>> the use cases. 
>>
>> * Debuggability*
>> n/a 
>>
>> * Is this feature fully tested by web-platform-tests 
>> ?*
>> Yes 
>> 
>>  
>>
>> * Requires code in //chrome?*
>> False 
>>
>> * Tracking bug*
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1233571 
>>
>> *Estimated milestones*
>> No milestones specified 
>>
>> * Link to entry on the Chrome Platform Status*
>> https://chromestatus.com/feature/5630001077551104 
>>
>> *Requesting approval to ship? *
>> Yes. This is a relatively small feature which exposes existing 
>> functionality.
>>
>> -- 
>> 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/e7299674-54df-4f4d-8c30-d922ebf4e47cn%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/74ab6933-2925-455a-9e24-a95ae08f3cf5n%40chromium.org.

Re: [blink-dev] Intent to Prototype and Ship: self.structuredClone

[Andreu Botella]

About the differences in the structured clone algorithm across 
implementations: I don't think those are listed anywhere. I know there are 
some because of the failures in 
https://wpt.fyi/results/html/infrastructure/safe-passing-of-structured-data?label=experimental&label=master&aligned,
 
but there might be others that aren't tested. Although it seems like some 
of the failures in the shared-array-buffer folder seem to be bugs with the 
tests rather than with the implementations.

For the record, I recently fixed in 
https://chromium-review.googlesource.com/c/chromium/src/+/3229544 one of 
Chromium's failures, where it was throwing a TypeError rather than a 
DataCloneException in one particular case. And it seems like the RegExp 
failures in Safari are fixed in the WebKit trunk / master branch.

On Thursday, October 28, 2021 at 8:56:15 PM UTC+2 yoav...@chromium.org 
wrote:

> On Thursday, October 28, 2021 at 12:42:10 PM UTC+2 jo...@igalia.com wrote:
>
>> This would be a great addition. Node.js also has been shipping this since 
>> v17.0.0 .
>> On Thursday, October 28, 2021 at 5:12:32 AM UTC+8 fs...@chromium.org 
>> wrote:
>>
>>> This is amazing! :)
>>>
>>> I agree it shouldn't block this, but do we have anywhere written what 
>>> are the browser's differences on structured clone algorithms? Is it a spec 
>>> issue? Could we add WPT tests for it?
>>>
>>> On Wed, Oct 27, 2021 at 2:45 PM Andreu Botella  
>>> wrote:
>>>
 * Contact emails*
 and...@andreubotella.com, jbr...@chromium.org, su...@chromium.org 

>>>
 *Explainer*
 https://github.com/whatwg/html/issues/793 

 *Specification*
 https://html.spec.whatwg.org/#structured-cloning 

 * Summary*
 Enables using the HTML structured clone algorithm synchronously for 
 cloning and transferring objects within a single realm. 

 * Initial public proposal*
 https://github.com/whatwg/html/issues/793 
 https://github.com/whatwg/html/pull/3414 

 *Blink component*
 Blink>Messaging 
 
  

 * TAG review*
 This is just exposing existing browser functionality, with a two-line 
 spec. It doesn’t seem like there’s much to discuss architecturally, but 
 I’ll file for review if the community thinks it would help.
>>>
>>>
> I agree this doesn't need a TAG review, but for other reasons.
> This change has landed in HTML and is shipped in 2 engines, so there's no 
> need for a TAG review for that reason.
>  
>
>>

 *TAG review status*
 Not applicable 

 * Risks*

 * Interoperability and Compatibility*
 Low. There are some differences across the browsers’ implementations of 
 the structured cloning algorithm, but they are very minor and already 
 present in other APIs that use it.
>>>
>>>
> Are there tests that highlight those differences?
>  
>
>>

 Gecko: Shipped/Shipping (
 https://bugzilla.mozilla.org/show_bug.cgi?id=1722576) 
 Edge: No signal 
 WebKit: Shipped/Shipping (
 https://bugs.webkit.org/show_bug.cgi?id=228331) 
>>>
>>>

 Web developers: Positive (
 https://github.com/whatwg/html/pull/3414#issuecomment-854051942 and 
 following comments). There seems to be a lot of demand for a built-in deep 
 clone, and while structured clone is not exactly that, it fulfills many of 
 the use cases. 

 * Debuggability*
 n/a 

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

 * Requires code in //chrome?*
 False 

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

 *Estimated milestones*
 No milestones specified 

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

 *Requesting approval to ship? *
 Yes. This is a relatively small feature which exposes existing 
 functionality.

 -- 
 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/e7299674-54df-4f4d-8c30-d922ebf4e47cn%40chromium.org
  
 
 .

>>>

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

[blink-dev] Re: Intent to Ship: HTTP->HTTPS redirect for HTTPS DNS records

[Eric Orth]

We just started rolling the behavior to 50% on Chrome Beta.

On Tue, Oct 19, 2021 at 1:09 PM Ralf Weber  wrote:

> Moin!
>
> On 19 Oct 2021, at 17:22, Eric Orth wrote:
>
> > Yes.  Chrome 96 should start going to Beta this week, and we will most
> > likely be turning the experiment up to 50% on Beta sometime next week.
> And
> > sometime after Chrome 96 hits Stable (late November), we will begin a
> > careful and gradual rollout of the feature, but the details and timeline
> > there are very much still TBD.
> Thanks a lot for the quick reply. I will continue to watch traffic. I
> assume
> that the details will be announced here so I continue to watch this space.
>
> So long
> -Ralf
> —--
> Ralf Weber
>

-- 
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/CAMOjQcFVRXAd%2BD%2B6oCuZXwmjmzmsbmY5w_i46oESZvWaFJr5tg%40mail.gmail.com.

Re: [blink-dev] Intent to Extend Experiment: Capture Handle

['Elad Alon' via blink-dev]

If 2021-11-01 is too short-notice by now, we could also do 2021-08 to 
2021-11-28.

On Wednesday, October 27, 2021 at 4:08:38 PM UTC+2 Elad Alon wrote:

> Thank you, Yoav, for this suggestion about resetting the clock. We would 
> like to now do just that, pausing the experiment 2021-11-01 to 2021-11-21, 
> and restarting it again on 2021-11-22. We would like to experiment for 4 
> milestones (96 to 99, inclusive). However, if it's possible to also have 
> the experiment active for older milestones during this time, that would be 
> nice, too.
>
> On Friday, August 20, 2021 at 6:44:10 AM UTC+2 yoav...@chromium.org wrote:
>
>> LGTM to continue experimenting.
>>
>> Note that it might be worthwhile to stop the experiment at some point, as 
>> that could "reset the clock" in terms of burn-in risk, and enable an 
>> overall longer experimentation period.
>>
>> On Tuesday, August 17, 2021 at 3:41:14 PM UTC+2 Elad Alon wrote:
>>
>>> Thanks, Yoav.
>>> Yes, I intend to formally reach out to Mozilla and Apple soon.
>>> Agreed about strong positive signals from developers.
>>>
>>> On Tuesday, August 17, 2021 at 10:56:26 AM UTC+2 yoav...@chromium.org 
>>> wrote:
>>>
 On Mon, Aug 16, 2021 at 11:42 PM 'Elad Alon' via blink-dev <
 blin...@chromium.org> wrote:

> Contact emailselad...@chromium.org
>
> Explainerhttps://github.com/WICG/capture-handle/blob/main/README.md
>
> Specificationhttps://wicg.github.io/capture-handle/
>
> Summary
>
> We introduce a mechanism that allows an application to opt-in to 
> exposing certain information to other applications which are 
> video-capturing it. This allows collaboration between capturing and 
> captured applications. For example, a VC application that's 
> video-capturing 
> a tab where a presentation application lives, could expose user-facing 
> controls in the VC tab for navigating the presentation in the captured 
> tab. 
>
>
> Blink componentBlink>GetUserMedia>Tab 
> 
>
> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/645
>
> TAG review statusPending
>
> Risks
>
>
> Interoperability and Compatibility
>
>
>
> Gecko: No signal
>
> WebKit: No signal
>
 Have we reached out? https://bit.ly/blink-signals is not required for 
 an experiment, but may be good to reach out nevertheless.


> Web developers: No signals
>

 I'd say 
 https://discourse.wicg.io/t/proposal-capture-handle-bootstrap-app-collaboration-when-screensharing/5354/
  
 gives you a strong positive signal..
  

>
>
> Reason this experiment is being extended
>
> Enthusiastic support for the feature: 
> https://discourse.wicg.io/t/proposal-capture-handle-bootstrap-app-collaboration-when-screensharing/5354
>  
> Efforts to build useful features on top of this new API are still ongoing.
> Request extension m95-m97 (three months).
> Debuggability
>
> No DevTools support is needed.
>
>
> Will this feature be supported on all six Blink platforms (Windows, 
> Mac, Linux, Chrome OS, Android, and Android WebView)?
>
> Supported on all Desktop platforms. Not supported on any Mobile 
> platform.
>
>
> Is this feature fully tested by web-platform-tests 
> 
> ?No
>
> Flag nameCaptureHandle
>
> Tracking bug
> https://bugs.chromium.org/p/chromium/issues/detail?id=1200910
>
> Launch bug
> https://bugs.chromium.org/p/chromium/issues/detail?id=1200907
>
> Estimated milestones
> OriginTrial desktop first 92
> OriginTrial desktop last 94Request extension m95-m97 (three months).
>
> Link to entry on the Chrome Platform Status
> https://www.chromestatus.com/feature/4854125411958784
>
> Links to previous Intent discussionsIntent to prototype: 
> https://groups.google.com/a/chromium.org/g/blink-dev/c/yLTykllpNmI
> Intent to Experiment: 
> https://groups.google.com/a/chromium.org/g/blink-dev/c/RKONugfoGwM/m/mpFizHPxAwAJ
>
>
> This intent message was generated by Chrome Platform Status 
> .
>
> -- 
> You received this message because you are subscribed to the Google 
> Groups "blink-dev" group.
>
 To unsubscribe from this group and stop receiving emails from it, send 
> an email to blink-dev+...@chromium.org.


> To view this discussion on the web visit 
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMO6jDOMkgjL_HUMohx4hk7tbC__M53aX3NEiGxeTPfw8nJUHw%40mail.gmail.com
>  
> 

Re: [blink-dev] Intent to Ship: New Canvas 2D API

['Aaron Krajeski' via blink-dev]

yoavweiss@:

Great video, thanks for that!!

  Thanks!

Were the concerns WebKit raised on the issue 
 addressed? Can you expand on 
that front?

  Yes, othermaciej@'s comments lead to us changing the name of that 
function to `reset` instead of `clear`.

Is the hold-up on the Filters PR editorial or something more fundamental?

  The hold-up is mostly over the question of whether `new 
CanvasFilter({filter: "someNonExistantFilterType"})` should throw an error. 
You can read the (very long) discussion in the pull request 
. Unfortunately it's been 
extremely hard to reach consensus on that specific issue for the past 3 
months. Any comments from this group that would help drive us towards 
consensus would be much appreciated!

Are these features individually detectable? Do we have reasonable developer 
advice on how we want folks to use those features with backwards 
compat/fallbacks in mind?

  We're working with the DevRel team on some polyfills that will be 
included in a web.dev article that is launching. All the features are 
trivially detectable except for perhaps contextlost/restored events. I can 
look further into that if you'd like?
  For polyfills, there are different degrees of effectiveness/difficulty.
  Easy: roundRect (small perf hit), reset
  Hard, maybe we should just advertise a polyfill that avoids errors: 
filters, conic gradient, text modifiers
  Doesn't make sense to polyfill: contextloss, willReadFrequently

On Thursday, October 21, 2021 at 3:07:21 AM UTC-4 yoav...@chromium.org 
wrote:

> Thanks for modernizing Canvas! :)
>
> On Thu, Oct 14, 2021 at 11:06 PM Aaron Krajeski  
> wrote:
>
>>
>> *Contact emails*aar...@chromium.org, fs...@chromium.org
>>
>> *Explainer*
>> https://github.com/fserb/canvas2d
>> https://youtu.be/dfOKFSDG7IM
>>
>
> Great video, thanks for that!!
>  
>
>>
>> *Specification*
>> Context Lost Event 
>> 
>> Context Restored Event 
>> 
>> Will Read Frequently 
>> 
>> New Text Modifiers 
>> 
>> Reset 
>> 
>>
>
> Were the concerns WebKit raised on the issue 
>  addressed? Can you expand on 
> that front?
>
>
>> RoundRect
>>
>> Conic
>>  
>> Gradient
>>
>> 
>> Filters  (still in progress)
>>
>
> Is the hold-up on the Filters PR editorial or something more fundamental?
> I noticed Mozilla's opposition on their position. Is that something that 
> has changed since?
>
> Are these features individually detectable? Do we have reasonable 
> developer advice on how we want folks to use those features with backwards 
> compat/fallbacks in mind?
>  
>
>>
>> *Summary*
>> Updated functionality for the Canvas2D API. Adds seven new 
>> features/functions to CanvasRenderingContext2D:
>>
>> - "ContextLost" and "ContextRestored" events
>> - "willReadFrequently" option for canvases where lots of readback is 
>> expected
>> - More CSS text modifier support
>> - A reset function
>> - A roundRect draw primitive
>> - Conic gradients
>> - Better support for SVG filters
>>
>> https://github.com/fserb/canvas2d
>>
>> *Blink component*
>> Blink>Canvas 
>> 
>>
>>
>> *TAG review status*Resolution: satisfied 
>> 
>>
>> *Risks*
>> Security and privacy team expressed concerns with ContextLost and 
>> ContextRestored events during the intent to implement phase. These concerns 
>> were addressed by re-designing the event to not launch simultaneously 
>> across different contexts.
>>
>> *Interoperability and Compatibility*
>> Gecko: In development (https://github.com/whatwg/html/issues/5431 
>> )
>>  
>> Already implemented conic gradient. Okay with willReadFrequently, 
>> transforms and reset.
>>
>> WebKit: Positive (https://github.com/whatwg/html/issues/5619). Positive 
>> signal on text modifiers, round rect and color input.
>>
>> Web developers: Positive (https://www.youtube.com/watch?v=dfOKFSDG7IM) 
>> CDN talk in December was received very positively.
>>
>> *Signals*
>> Gecko: https://github.com/mozilla/standards-positions/issues/519
>> WebKit: 
>> https://lists.webkit.org/pipermail/webkit-dev/2021-May/031833.html
>>
>> *Is this feature fully tested by* web-platf

[blink-dev] Re: Intent to Extend Origin Trial: Conversion Measurement API (Attribution Reporting API)

[Alex Russell]

hey John,

In line with the policy we adopted earlier regarding trials in this bucket 
of features [1], I appreciate the reporting around total page loads.

We're inclined to extend this OT, but wanted to quickly check in to see if 
y'all have any interim results from the trial thus far. Are you surveying 
developers? Is there some feedback you could perhaps aggregate to give us a 
sense for how it's going?

Thanks,

Alex

[1]: 
https://groups.google.com/a/chromium.org/g/blink-dev/c/c4noVavt-uM/m/OhB3cd0EAgAJ

On Thursday, October 21, 2021 at 6:45:39 AM UTC-7 John Delaney wrote:

> *Contact emails*
> johni...@chromium.org, csharri...@chromium.org
>
> *Explainer*
>
> https://github.com/WICG/conversion-measurement-api/blob/main/event_attribution_reporting_clicks.md
>
> *Design docs/spec*
> https://wicg.github.io/conversion-measurement-api/
>
> *Summary*
> This is a new API for measuring conversions (e.g. purchases) and 
> attributing them to clicked ads, without using cross-site persistent 
> identifiers like third party cookies.
>
> *Link to “Intent to Prototype” blink-dev discussion*
>
> https://groups.google.com/a/chromium.org/d/msg/blink-dev/7B0ldtZR_68/GjLBu0n4DgAJ
>  
> *Link to “Intent to Experiment” blink-dev discussion*
>
> https://groups.google.com/a/chromium.org/d/msg/blink-dev/Ib9-tDFitns/Sm9RXTNaBwAJ
>
> First extension: 
> https://groups.google.com/a/chromium.org/g/blink-dev/c/C0P7ePjITJQ/m/ZYFmn30SDQAJ
>   
> 
> Second extension: 
> https://groups.google.com/a/chromium.org/g/blink-dev/c/xCWP1ltlAgw/m/acwN0GIRBQAJ
> Third extension:
>
> https://groups.google.com/a/chromium.org/g/blink-dev/c/DmsUL3KHqMk/m/J2v3I_aEBAAJ
>
> *Goals for experimentation*
> We hope to see that the data produced by the API is comparable to existing 
> cookie-based mechanisms.
>
> *Experimental timeline*
> We'd like to extend the origin trial for 3 milestones, continuing through 
> Chrome 97 (95/96/97). The experiment has been running from Chrome 86-94.
>
> *Any risks when the experiment finishes?*
> This API is only additive and does not affect any existing state. Current 
> conversion measurement solutions will work as expected with and without the 
> API, so we don’t believe there are any risks.
>
> The Origin Trial tokens for Chrome 94 expired on October 12th. The API has 
> been effectively disabled since then, so there will be a gap in 
> availability.
>
> We have previously requested an exception to the .5% page load usage limit 
> for Origin Trials. Page load usage is currently around .48% in October, and 
> was at .5% on average in September.
> https://chromestatus.com/metrics/feature/timeline/popularity/3365
>
> *Reason this experiment is being extended*
> We have two more non-google testers interested in experimenting with the 
> API who have not yet been able to start experiments. The proposed API is 
> fundamentally different in a number of ways from cookie-based mechanisms, 
> which can make setting up experiments time consuming.
>
> Given the wide range of environments where this API will be used, we 
> expect new testers to produce different learnings and feedback on the API, 
> even without changes to the API.
>
> *Ongoing technical constraints*
> None.
>
> *Will this feature be supported on all five Blink platforms supported by 
> Origin Trials (Windows, Mac, Linux, Chrome OS, and Android)?*
> Yes.
>
> *Link to entry on the feature dashboard*
> *https://chromestatus.com/feature/6412002824028160 
> *
>
>

-- 
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/ef274ea9-48ff-4913-8b26-4230296adecen%40chromium.org.

Re: [blink-dev] Intent to Ship: CORS non-wildcard request-header

[Mike West]

I think it's reasonable for us to dig into the data a little bit to
determine whether the 0.04% number quoted above will result in user-facing
breakage. Yutaka, is that something you'd be willing to dig into?

The direction seems philosophically correct to me, so I'd like to see it
ship, but I'd also like to make sure we're not making the web worse for
users by doing so.

-mike


On Thu, Oct 21, 2021 at 12:04 PM Yutaka Hirano  wrote:

>
>
> On Thu, Oct 21, 2021 at 6:25 PM Yoav Weiss  wrote:
>
>>
>>
>> On Thu, Oct 21, 2021 at 9:55 AM Yutaka Hirano 
>> wrote:
>>
>>> (The implementation CL
>>>  is
>>> under review. This intent is written as if it's landed.)
>>>
>>> Contact emailsyhir...@chromium.org
>>>
>>> Specification
>>> https://fetch.spec.whatwg.org/#cors-non-wildcard-request-header-name
>>>
>>> Summary
>>>
>>> A CORS non-wildcard request header[1] is an HTTP request header which is
>>> not covered by the wildcard symbol ("*") in the
>>> access-control-allow-headers header. "authorization" is the only member of
>>> CORS non-wildcard request-header. Currently we treat the header as a usual
>>> header, which is problematic for security reasons. Implement it, and change
>>> the current behavior. 1:
>>> https://fetch.spec.whatwg.org/#cors-non-wildcard-request-header-name
>>>
>>>
>>> Blink componentBlink>SecurityFeature>CORS
>>> 
>>>
>>> TAG reviewNot needed because this implements an existing feature.
>>>
>>> TAG review statusNot applicable
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> Interoperability risk is low because Mozilla and Apple showed an intent
>>> to implement this behavior. There is some compatibility risk, as the use
>>> counter[2] shows 0.04% websites would be affected. To mitigate the risk,
>>> we've shown a deprecation message for a few milestones.
>>>
>>
>> Can you similarly send deprecation reports as well? How long have the
>> deprecation messages been in place? Did we see any decline in the numbers?
>>
>> We've shown the deprecation message since Chrome 94
> 
>  whose
> beta promotion was on Aug 26 and stable release was on Sep 21.
> We use CountDeprecation which sends deprecation reports automatically IIUC.
>
> I don't see any decline.
>
>
>> Have we looked into which URLs are triggering this? (and if it's a few
>> medium-sized properties or many tiny ones)
>>
>
> I haven't looked at the data.
>
>> Did we try outreach?
>>
> No.
>
>>
>> We have an enterprise policy so that administrators can keep the existing
>>> behavior. We're planning to remove the policy on Chrome 103. 2:
>>> https://www.chromestatus.com/metrics/feature/popularity#AuthorizationCovered
>>> ByWildcard
>>>
>>>
>>> Gecko: Positive Firefox showed a positive signal in a private thread.
>>>
>>> WebKit: Positive Apple showed a positive signal in a private thread.
>>>
>>> Web developers: No signals
>>>
>>>
>>> Debuggability
>>>
>>> We'll show a CORS error to the devtools console.
>>>
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?Yes
>>>
>>> Flag nameCorsNonWildcardRequestHeadersSupport
>>>
>>> Requires code in //chrome?False (or, True only for the enterprise
>>> policy.)
>>>
>>> Tracking bughttps://crbug.com/1176753
>>>
>>> Estimated milestones
>>>
>>> 97
>>>
>>> Link to entry on the Chrome Platform Status
>>> https://chromestatus.com/feature/5742041264816128
>>>
>>> --
>>> 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/CABihn6G2mzUAH_Ghrqmb1xM7XetfKgB%3DMUkX0DED7yWbL4JfGg%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/CABihn6GB-CbbCqx0VHa7%3DLoZr%2BZN-O7o7XwTGkxXEYQa9OfupQ%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 

Re: [blink-dev] Intent to Ship: New Canvas 2D API

[Alex Russell]

It would be worth discussing this with the folks responsible for paint 
worklets; there has been a lot of work to ensure that the worklets don't 
include APIs that would allow for readback.

Adding Xida and Ian for that.

Best regards,

Alex

On Monday, October 25, 2021 at 7:28:50 AM UTC-7 Aaron Krajeski wrote:

> They are not yet available on paint worklets (they're not in the idls). It 
> doesn't look like it would be too much work to add them. Looking at the 
> WHATWG spec, it doesn't seem like there would need to be any spec change. 
> Am I correct in assuming that?
>
> On Thu, Oct 21, 2021 at 3:32 PM Alex Russell  
> wrote:
>
>> I'm excited to see these move forward. I probably missed it from the 
>> github explainers (which seem pretty IDL heavy, but not particularly 
>> use-case driven?), but which of these will be available on Paint Worklets 
>> as part of this intent?
>>
>> On Thursday, October 21, 2021 at 12:07:21 AM UTC-7 Yoav Weiss wrote:
>>
>>> Thanks for modernizing Canvas! :)
>>>
>>> On Thu, Oct 14, 2021 at 11:06 PM Aaron Krajeski  
>>> wrote:
>>>

 *Contact emails*aaro...@chromium.org, fs...@chromium.org

 *Explainer*
 https://github.com/fserb/canvas2d
 https://youtu.be/dfOKFSDG7IM

>>>
>>> Great video, thanks for that!!
>>>  
>>>

 *Specification*
 Context Lost Event 
 
 Context Restored Event 
 
 Will Read Frequently 
 
 New Text Modifiers 
 
 Reset 
 

>>>
>>> Were the concerns WebKit raised on the issue 
>>>  addressed? Can you expand 
>>> on that front?
>>>
>>>
 RoundRect

 Conic
  
 Gradient

 
 Filters  (still in progress)

>>>
>>> Is the hold-up on the Filters PR editorial or something more fundamental?
>>> I noticed Mozilla's opposition on their position. Is that something that 
>>> has changed since?
>>>
>>> Are these features individually detectable? Do we have reasonable 
>>> developer advice on how we want folks to use those features with backwards 
>>> compat/fallbacks in mind?
>>>  
>>>

 *Summary*
 Updated functionality for the Canvas2D API. Adds seven new 
 features/functions to CanvasRenderingContext2D:

 - "ContextLost" and "ContextRestored" events
 - "willReadFrequently" option for canvases where lots of readback is 
 expected
 - More CSS text modifier support
 - A reset function
 - A roundRect draw primitive
 - Conic gradients
 - Better support for SVG filters

 https://github.com/fserb/canvas2d

 *Blink component*
 Blink>Canvas 
 


 *TAG review status*Resolution: satisfied 
 

 *Risks*
 Security and privacy team expressed concerns with ContextLost and 
 ContextRestored events during the intent to implement phase. These 
 concerns 
 were addressed by re-designing the event to not launch simultaneously 
 across different contexts.

 *Interoperability and Compatibility*
 Gecko: In development (https://github.com/whatwg/html/issues/5431 
 )
  
 Already implemented conic gradient. Okay with willReadFrequently, 
 transforms and reset.

 WebKit: Positive (https://github.com/whatwg/html/issues/5619). 
 Positive signal on text modifiers, round rect and color input.

 Web developers: Positive (https://www.youtube.com/watch?v=dfOKFSDG7IM) 
 CDN talk in December was received very positively.

 *Signals*
 Gecko: https://github.com/mozilla/standards-positions/issues/519
 WebKit: 
 https://lists.webkit.org/pipermail/webkit-dev/2021-May/031833.html

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

 *Flag name*
 #new-canvas-2d-api

 *Requires code in //chrome?*
 False

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

 *Estimated milestones*
 OriginTrial desktop first
 95

 OriginTrial desktop last
 98

 Or

Re: [blink-dev] RE: [EXTERNAL] Re: Intent to Implement and Ship: Feature policy for Keyboard API

[Daniel Bratell]

LGTM3, (but follow up with Dave about the implementation details, and make 
sure to listen to any late comments from other reviews)

On Wednesday, 27 October 2021 at 23:52:31 UTC+2 Dave Tapuska wrote:

> For a cross origin renderer the browser process would be involved because 
> the allow attribute restriction is in one renderer, and the enforcement of 
> the permission is in the renderer that wants to use it. I do not think it 
> is difficult to check the policy on the mojo request of the keyboard map in 
> the browser process. Although you'll likely want some additional response 
> enums 
> 
> .
>
> I ask because we would need to adjust this model for fenced frames 
> implementation and the enforcement on the browser side better aligns with 
> our security design.
>
> dave.
>
> On Wed, Oct 27, 2021 at 5:42 PM Anupam Snigdha  
> wrote:
>
>> I’m not sure if checking that in the browser would make sense here 
>> because the allow attribute restriction is specified in the DOM and the 
>> browser process isn’t involved. I did ask this in the slack channel and 
>> pretty much got the same response that the renderer should be enforcing 
>> this check. If you have any other ideas though, then please let me know!
>>
>>  
>>
>> *From:* Dave Tapuska  
>> *Sent:* Wednesday, October 27, 2021 2:27 PM
>> *To:* Anupam Snigdha 
>> *Cc:* sligh...@chromium.org; blin...@chromium.org; yoav...@chromium.org; 
>> Bo Cupp ; Scott Low ; 
>> gar...@chromium.org; dom...@chromium.org
>> *Subject:* Re: [blink-dev] RE: [EXTERNAL] Re: Intent to Implement and 
>> Ship: Feature policy for Keyboard API
>>
>>  
>>
>> I was looking at the implementation of this. Is it possible to move the 
>> check of the policy to be based in the browser when the map is fetched? As 
>> of right now the policy enforcement is on the renderer side, so a 
>> compromised renderer can request the keyboard map.
>>
>>  
>>
>> dave.
>>
>>  
>>
>> On Wed, Oct 27, 2021 at 4:53 PM 'Anupam Snigdha' via blink-dev <
>> blin...@chromium.org> wrote:
>>
>> Created an issue to get feedback from TAG: 
>> https://github.com/w3ctag/design-reviews/issues/685 
>> 
>>
>> I added this to the webappsec-permission policy: 
>> https://github.com/w3c/webappsec-permissions-policy/pull/428 
>> ,
>>  
>> but will also create an issue to investigate Permissions API integration. 
>> Thanks!
>>
>>  
>>
>> *From:* Alex Russell  
>> *Sent:* Thursday, October 21, 2021 12:21 PM
>> *To:* blink-dev 
>> *Cc:* Yoav Weiss ; Anupam Snigdha <
>> sni...@microsoft.com>; blin...@chromium.org ; Bo 
>> Cupp ; Scott Low ; 
>> gar...@chromium.org ; Domenic Denicola <
>> dom...@chromium.org>
>> *Subject:* Re: [blink-dev] RE: [EXTERNAL] Re: Intent to Implement and 
>> Ship: Feature policy for Keyboard API
>>
>>  
>>
>> Not consulting the TAG in this instance may have been an error. In 
>> general, we should be putting things into consistent surfaces that they 
>> affect. In this case, it seems like we're missing integrations w/ the 
>> Permissions API.
>>
>>  
>>
>> I'm LGTM2 on this intent contingent on a commitment to follow up w/ the 
>> TAG as an FYI and a commitment to investigate Permissions API integration.
>>
>>  
>>
>> Best Regards,
>>
>>  
>>
>> Alex
>>
>>  
>>
>> On Sunday, October 17, 2021 at 10:16:58 PM UTC-7 Yoav Weiss wrote:
>>
>> LGTM1
>>
>>  
>>
>> On Sat, Oct 16, 2021 at 12:35 AM Domenic Denicola  
>> wrote:
>>
>> Just chiming in from the sidelines: in general I think this sort of 
>> exposure via permissions policies is a good thing, and should be encouraged.
>>
>>  
>>
>> It shouldn't have any additional concerns for an API like this which is 
>> about exposing information:
>>
>>- Same-origin iframes can already call 
>>top.navigator.keyboard.getLayoutMap()
>>- The parent can call navigator.keyboard.getLayoutMap(), serialize 
>>the information, and send it to any cross-origin descendants that it 
>> wants 
>>

Re: [blink-dev] RE: [EXTERNAL] Re: Intent to Implement and Ship: Feature policy for Keyboard API

[Alex Russell]

Thanks for filing a TAG issue and an issue in permission policy. Would also 
like to make sure that there is integration with the Permissions API:

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

On the question of browser signals, it's fine to note that Apple wasn't 
interested, but that probably isn't a reasonably strong signal.

On Wednesday, October 27, 2021 at 2:52:31 PM UTC-7 Dave Tapuska wrote:

> For a cross origin renderer the browser process would be involved because 
> the allow attribute restriction is in one renderer, and the enforcement of 
> the permission is in the renderer that wants to use it. I do not think it 
> is difficult to check the policy on the mojo request of the keyboard map in 
> the browser process. Although you'll likely want some additional response 
> enums 
> 
> .
>
> I ask because we would need to adjust this model for fenced frames 
> implementation and the enforcement on the browser side better aligns with 
> our security design.
>
> dave.
>
> On Wed, Oct 27, 2021 at 5:42 PM Anupam Snigdha  
> wrote:
>
>> I’m not sure if checking that in the browser would make sense here 
>> because the allow attribute restriction is specified in the DOM and the 
>> browser process isn’t involved. I did ask this in the slack channel and 
>> pretty much got the same response that the renderer should be enforcing 
>> this check. If you have any other ideas though, then please let me know!
>>
>>  
>>
>> *From:* Dave Tapuska  
>> *Sent:* Wednesday, October 27, 2021 2:27 PM
>> *To:* Anupam Snigdha 
>> *Cc:* slightly...@chromium.org; blink-dev@chromium.org; 
>> yoavwe...@chromium.org; Bo Cupp ; Scott Low <
>> sc...@microsoft.com>; gary...@chromium.org; dome...@chromium.org
>> *Subject:* Re: [blink-dev] RE: [EXTERNAL] Re: Intent to Implement and 
>> Ship: Feature policy for Keyboard API
>>
>>  
>>
>> I was looking at the implementation of this. Is it possible to move the 
>> check of the policy to be based in the browser when the map is fetched? As 
>> of right now the policy enforcement is on the renderer side, so a 
>> compromised renderer can request the keyboard map.
>>
>>  
>>
>> dave.
>>
>>  
>>
>> On Wed, Oct 27, 2021 at 4:53 PM 'Anupam Snigdha' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>> Created an issue to get feedback from TAG: 
>> https://github.com/w3ctag/design-reviews/issues/685 
>> 
>>
>> I added this to the webappsec-permission policy: 
>> https://github.com/w3c/webappsec-permissions-policy/pull/428 
>> ,
>>  
>> but will also create an issue to investigate Permissions API integration. 
>> Thanks!
>>
>>  
>>
>> *From:* Alex Russell  
>> *Sent:* Thursday, October 21, 2021 12:21 PM
>> *To:* blink-dev 
>> *Cc:* Yoav Weiss ; Anupam Snigdha <
>> sni...@microsoft.com>; blin...@chromium.org ; Bo 
>> Cupp ; Scott Low ; 
>> gar...@chromium.org ; Domenic Denicola <
>> dome...@chromium.org>
>> *Subject:* Re: [blink-dev] RE: [EXTERNAL] Re: Intent to Implement and 
>> Ship: Feature policy for Keyboard API
>>
>>  
>>
>> Not consulting the TAG in this instance may have been an error. In 
>> general, we should be putting things into consistent surfaces that they 
>> affect. In this case, it seems like we're missing integrations w/ the 
>> Permissions API.
>>
>>  
>>
>> I'm LGTM2 on this intent contingent on a commitment to follow up w/ the 
>> TAG as an FYI and a commitment to investigate Permissions API integration.
>>
>>  
>>
>> Best Regards,
>>
>>  
>>
>> Alex
>>
>>  
>>
>> On Sunday, October 17, 2021 at 10:16:58 PM UTC-7 Yoav Weiss wrote:
>>
>> LGTM1
>>
>>  
>>
>> On Sat, Oct 16, 2021 at 12:35 AM Domenic Denicola  
>> wrote:
>>
>> Just chiming in from the sidelines: in general I think this sort of 
>> exposure via permissions policies is a good thing, and should be encouraged.
>>
>>  
>>
>> It shouldn't have any additional concerns for an API like this which is 
>> about exposing information:
>>
>>- Same-origin iframes

Re: [blink-dev] Intent to Ship: [WebAuthn] Authenticator Attachment in Public Key Credential

[Yoav Weiss]

LGTM3 even

On Thursday, October 28, 2021 at 8:28:32 PM UTC+2 Yoav Weiss wrote:

> LGTM2 with similar conditions.
>
> On Thursday, October 21, 2021 at 9:23:45 PM UTC+2 Alex Russell wrote:
>
>> Thanks for explaining, Adam.
>>
>> I'm LGTM1 contingent on:
>>
>>- An explainer being produced with at least the content of Adam's 
>>last post being included.
>>- An FYI being sent to the TAG w/ that Explainer attached. We don't 
>>have a policy that allows folks to arbitrarily decide not to send things 
>> to 
>>them w/o justification.
>>
>> Thanks
>>
>> On Friday, October 15, 2021 at 12:15:34 PM UTC-7 Adam Langley wrote:
>>
>>> On Thursday, October 14, 2021 at 1:49:39 AM UTC-7 yoav...@chromium.org 
>>> wrote:
>>>
 Apologies, but it's not clear to me what this does. A higher-level 
 explainer may be helpful here.

>>>
>>> When returning a WebAuthn assertion, browsers will say whether the 
>>> assertion came from a removable device or not. I.e. if you touch a security 
>>> key it'll say "cross-platform", but if you use Touch ID / Windows Hello 
>>> it'll say "platform".
>>>
>>> Sites could already figure this out because they learn the supported 
>>> transports of an authenticator during registration and removable devices 
>>> offer things like "usb" or "ble", while the platform authenticators (Touch 
>>> ID / Hello) say "internal". But we want to make this simpler for sites so 
>>> that they have a clear signal when offering to register the platform as an 
>>> authenticator might be useful.
>>>
>>> The vision is that, when phones are fully usable as security keys, users 
>>> will be able to sign into sites on a desktop browser with them. But that 
>>> site might want to know that a "removable" device was used (e.g. a phone) 
>>> because registering the platform authenticator for future sign-ins is 
>>> probably a better experience.
>>>
>>>
> *TAG review*
>
> N/A
>

 Why is a TAG review not applicable? 

>>>
>>> Seems like a very minor change and TAG is a very heavy process.
>>>  
>>>
 Web developers: No signals
>
  
 Are developers likely to adopt this? If not, why are we adding this?
 https://goo.gle/developer-signals

>>>
>>> Other parts of an ecosystem need to slot into place in order for 
>>> everything to hang together: phones as security keys, syncing credentials, 
>>> conditional UI, etc. So developers are probably uninterested in this part 
>>> in isolation, but all together there's a fair amount of interest. GitHub, 
>>> at least, are public about WebAuthn L2 being insufficient without several 
>>> of changes in this set: 1  
>>> 2  3 
>>> .
>>>  
>>>

> Edge: Support Signals
>
 Any links?

>>>
>>> Microsoft supporting here 
>>> . 
>>> (See "Assertion Transports" section; WG discussion changed "transports" to 
>>> "attachment", which is what this thread is talking about.)
>>>
>>>
>>> Cheers
>>>
>>> AGL
>>>
>>

-- 
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/23cf4a6f-a874-43c8-a5ce-134af98632edn%40chromium.org.

Re: [EXTERNAL] Re: [blink-dev] Intent to Implement and Ship: Add support for Promise to Blobs in clipboard item

[Mike West]

We discussed this in the API owners' meeting, and there's some confusion
both about what's specified, and what Chromium's implementation does. I
read https://github.com/w3c/clipboard-apis/issues/161 as suggesting that
the `ClipboardItem` has a promise which, when resolved, provides access to
the current contents of the clipboard (and a response suggests that there's
a 1 second limit on that). Step 2.3 of
https://www.w3.org/TR/clipboard-apis/#dom-clipboard-read suggests that read
operations return "a copy of the system clipboard data", which seems
inconsistent.

Can y'all help me understand what our model is here? And what the model
ought to be, if it diverges from what we've currently implemented?

-mike


On Wed, Oct 27, 2021 at 8:07 PM 'Anupam Snigdha' via blink-dev <
blink-dev@chromium.org> wrote:

> Thanks Daniel for raising this concern. I have opened an issue to discuss
> with the Editing WG: https://github.com/w3c/clipboard-apis/issues/161. In
> the current implementation, I think verifying whether the Document is
> active or not after the promises have been resolved should mitigate some of
> the concerns.
>
>
>
> *From:* Daniel Bratell 
> *Sent:* Thursday, October 21, 2021 12:48 PM
> *To:* Domenic Denicola ; Yoav Weiss <
> yoavwe...@chromium.org>
> *Cc:* blink-dev ; Anupam Snigdha <
> sni...@microsoft.com>; ann...@annevk.nl ; Marijn
> Kruisselbrink ; Bo Cupp 
> *Subject:* Re: [EXTERNAL] Re: [blink-dev] Intent to Implement and Ship:
> Add support for Promise to Blobs in clipboard item
>
>
>
> Inspired by the recent talk about user interaction, I feel like there is
> one thing I want to understand.
>
> So with a Promise you move the execution to a later time. Is it possible
> here for a malicious page to delay an action to much, much later and then
> do that clipboard operation on data that was not available at the time of
> the clipboard operation the user initiated?
>
> If so, could that have security implications?
>
> Could there even be more than one ongoing clipboard operation at a time?
>
> /Daniel
>
>
>
> On 2021-10-21 17:20, Domenic Denicola wrote:
>
>
>
>
>
> On Thu, Oct 21, 2021 at 5:21 AM Yoav Weiss  wrote:
>
> LGTM1 to ship conditional that y'all continue to work on PR #158
> 
>  specifically,
> and clarifying the spec's processing model in general.
>
> On Thursday, October 21, 2021 at 2:04:53 AM UTC+2 snianu wrote:
>
> Gentle ping as the branch cutoff date for 97 is pretty close. While I
> agree that the issues related to clipboard API spec need to be addressed, I
> don’t think this feature needs to be blocked on that. It’s not a breaking
> change i.e. sites can continue to use Blobs if they want to(although I
> don’t think any developer would want to have different codepaths for Apple
> and Chromium browsers)
>
>
>
> FWIW, I got curious RE why that *should* work, and did some digging.
>
> It seems like the bindings methods that accept a `Promise` input value
> call `NativeValueTraits
> `
> on that value, which casts
> 
> the value foo into a `Promise.resolve(foo)`, if it wasn't a Promise already.
>
> The same seems to work in WebKit as well. Do you know if this bindings
> behavior is specified?
>
>
>
> It is: https://webidl.spec.whatwg.org/#es-promise
> 

Re: [blink-dev] Intent to Ship: HDR CSS Media Queries

[David Baron]

On Thu, Oct 28, 2021 at 2:38 PM Yoav Weiss  wrote:

>
>
> On Friday, October 22, 2021 at 10:19:44 PM UTC+2 Fernando Serboncini wrote:
>
>> [coming from the other thread... :) ]
>>
>> +1 to what David said. It doesn't seem that returning dynamic-range: high
>> right now would be useful.
>>
>> The spec could use some clarification:
>> - clarify if those criterias need to be supported on different
>> conditions: CSS, images, canvas, ...
>> - clarify if the criterias need to be supported for both with/without
>> alpha (afaik there may be implementation differences there, but I may be
>> wrong here).
>> - I wonder if the definitions of high contrast/peak brightness should
>> match the industry definitions for HDR displays? I'm not an expert, but I
>> know those exist.
>> I think it's potentially okay to ignore those definitions, but I'd ask
>> for a rationale here.
>>
>> I think it's a great thing to summarize hdr into a single media query,
>> but the risk here would be to release a semantic that guarantees very
>> little, and therefore is not useful in the long run.
>>
>>
>> On Fri, Oct 22, 2021 at 10:04 AM David Baron  wrote:
>>
>>> This sounds like exactly the sort of case where an implementation should
>>> report (dynamic-range: standard) and (video-dynamic-range: high).  It
>>> would be great to see the spec clarified to make it clearer what UA support
>>> is expected for each, though.
>>>
>>> -David
>>>
>>> On Thu, Oct 21, 2021 at 7:03 PM Will Cassella 
>>> wrote:
>>>
 Copying over from the other thread (trying to continue the discussion
 here):

 The spec  requires
> that "The combination of the User Agent and the output device fulfill all
> of the following criteria" when describing what it means to be high
> dynamic-range.  Since Chromium doesn't support wide-gamut colors in CSS,
> HTML, or Canvas


> David - I'm likely missing something here, but I thought (based on this
> thread
> )
> that we do have wide-gamut support in CSS, HTML and Canvas.
> Are you saying we don't support this due to lack of color level 4 support?
> Or something else?
>

That intent makes it sound like we have wide-gamut support for canvas
(though others would be able to speak more authoritatively about it) but I
don't think we do in HTML or CSS.  (I also should have included images in
my list, though I think if we have support with canvas then we probably do
for images as well.).)


> I also didn't interpret the spec as saying anything about gamut (but
> rather about color depth ),
> although it may be possible that wide gamuts and high color depth correlate
> 1:1. Can you clarify if that's what you meant?
>

I should have been more precise about meeting the spec's requirements
rather than just using the term "wide-gamut".  You're correct that it's not
1:1, though I think that in practice an implementation is unlikely to meet
the spec's requirements on color depth and contrast ratio without
supporting colors beyond sRGB's gamut.

(I also suspect we may not meet the color depth requirement in the spec,
perhaps not for canvas or images as well.)

-David


>
>
>> , I think it's probably incorrect to report that (dynamic-range: high) is
> true based only on the device, which is what it looks to me like the 
> current
> code
> 
>  does.
> Admittedly, the spec could probably use some clarification as to what it
> means for the User Agent to fulfill the criteria for both the
> dynamic-range and video-dynamic-range queries, but my understanding
> of what the spec is trying to say is that Chrome probably shouldn't say
> that (dynamic-range: high) is true until it supports wide-gamut
> colors in at least some and maybe all of those contexts.


 I think you're right that the spec needs some clarification, since
 we're trying to incrementally enable adoption of HDR on the web the intent
 isn't to signal that HDR is supported by all APIs. We do already
 support HDR in some scenarios, such as the  element, so having these
 queries exist to let developers detect display capabilities is already
 useful.

 On Wed, Oct 20, 2021 at 11:27 PM Yoav Weiss 
 wrote:

>
>
> On Thu, Oct 21, 2021 at 7:01 AM Will Cassella 
> wrote:
>
>> Thanks for the feedback! I've updated that section:
>>
>> Debuggability
>>
>> Styles with these media queries can be viewed and edited in the
>> devtools frontend, albeit without proper highlighting. I've created pull
>> requests on the relevant libraries used in the devtools frontend to 
>> ena

Re: [blink-dev] Intent to Prototype and Ship: self.structuredClone

[Yoav Weiss]

On Thursday, October 28, 2021 at 12:42:10 PM UTC+2 jo...@igalia.com wrote:

> This would be a great addition. Node.js also has been shipping this since 
> v17.0.0 .
> On Thursday, October 28, 2021 at 5:12:32 AM UTC+8 fs...@chromium.org 
> wrote:
>
>> This is amazing! :)
>>
>> I agree it shouldn't block this, but do we have anywhere written what 
>> are the browser's differences on structured clone algorithms? Is it a spec 
>> issue? Could we add WPT tests for it?
>>
>> On Wed, Oct 27, 2021 at 2:45 PM Andreu Botella  
>> wrote:
>>
>>> * Contact emails*
>>> and...@andreubotella.com, jbr...@chromium.org, su...@chromium.org 
>>>
>>
>>> *Explainer*
>>> https://github.com/whatwg/html/issues/793 
>>>
>>> *Specification*
>>> https://html.spec.whatwg.org/#structured-cloning 
>>>
>>> * Summary*
>>> Enables using the HTML structured clone algorithm synchronously for 
>>> cloning and transferring objects within a single realm. 
>>>
>>> * Initial public proposal*
>>> https://github.com/whatwg/html/issues/793 
>>> https://github.com/whatwg/html/pull/3414 
>>>
>>> *Blink component*
>>> Blink>Messaging 
>>> 
>>>  
>>>
>>> * TAG review*
>>> This is just exposing existing browser functionality, with a two-line 
>>> spec. It doesn’t seem like there’s much to discuss architecturally, but 
>>> I’ll file for review if the community thinks it would help.
>>
>>
I agree this doesn't need a TAG review, but for other reasons.
This change has landed in HTML and is shipped in 2 engines, so there's no 
need for a TAG review for that reason.
 

>
>>>
>>> *TAG review status*
>>> Not applicable 
>>>
>>> * Risks*
>>>
>>> * Interoperability and Compatibility*
>>> Low. There are some differences across the browsers’ implementations of 
>>> the structured cloning algorithm, but they are very minor and already 
>>> present in other APIs that use it.
>>
>>
Are there tests that highlight those differences?
 

>
>>>
>>> Gecko: Shipped/Shipping (
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1722576) 
>>> Edge: No signal 
>>> WebKit: Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=228331
>>> ) 
>>
>>
>>>
>>> Web developers: Positive (
>>> https://github.com/whatwg/html/pull/3414#issuecomment-854051942 and 
>>> following comments). There seems to be a lot of demand for a built-in deep 
>>> clone, and while structured clone is not exactly that, it fulfills many of 
>>> the use cases. 
>>>
>>> * Debuggability*
>>> n/a 
>>>
>>> * Is this feature fully tested by web-platform-tests 
>>> ?*
>>> Yes 
>>> 
>>>  
>>>
>>> * Requires code in //chrome?*
>>> False 
>>>
>>> * Tracking bug*
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1233571 
>>>
>>> *Estimated milestones*
>>> No milestones specified 
>>>
>>> * Link to entry on the Chrome Platform Status*
>>> https://chromestatus.com/feature/5630001077551104 
>>>
>>> *Requesting approval to ship? *
>>> Yes. This is a relatively small feature which exposes existing 
>>> functionality.
>>>
>>> -- 
>>> 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/e7299674-54df-4f4d-8c30-d922ebf4e47cn%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/8b0b0a76-3bca-4640-bfb6-5e2010b485bcn%40chromium.org.

Re: [blink-dev] Intent to Ship: HDR CSS Media Queries

[Yoav Weiss]

On Friday, October 22, 2021 at 10:19:44 PM UTC+2 Fernando Serboncini wrote:

> [coming from the other thread... :) ]
>
> +1 to what David said. It doesn't seem that returning dynamic-range: high 
> right now would be useful.
>
> The spec could use some clarification:
> - clarify if those criterias need to be supported on different conditions: 
> CSS, images, canvas, ...
> - clarify if the criterias need to be supported for both with/without 
> alpha (afaik there may be implementation differences there, but I may be 
> wrong here).
> - I wonder if the definitions of high contrast/peak brightness should 
> match the industry definitions for HDR displays? I'm not an expert, but I 
> know those exist. 
> I think it's potentially okay to ignore those definitions, but I'd ask for 
> a rationale here.
>
> I think it's a great thing to summarize hdr into a single media query, but 
> the risk here would be to release a semantic that guarantees very little, 
> and therefore is not useful in the long run.
>
>
> On Fri, Oct 22, 2021 at 10:04 AM David Baron  wrote:
>
>> This sounds like exactly the sort of case where an implementation should 
>> report (dynamic-range: standard) and (video-dynamic-range: high).  It 
>> would be great to see the spec clarified to make it clearer what UA support 
>> is expected for each, though.
>>
>> -David
>>
>> On Thu, Oct 21, 2021 at 7:03 PM Will Cassella  
>> wrote:
>>
>>> Copying over from the other thread (trying to continue the discussion 
>>> here):
>>>
>>> The spec  requires 
 that "The combination of the User Agent and the output device fulfill all 
 of the following criteria" when describing what it means to be high 
 dynamic-range.  Since Chromium doesn't support wide-gamut colors in CSS, 
 HTML, or Canvas
>>>
>>>
David - I'm likely missing something here, but I thought (based on this 
thread 
)
 
that we do have wide-gamut support in CSS, HTML and Canvas.
Are you saying we don't support this due to lack of color level 4 support? 
Or something else?

I also didn't interpret the spec as saying anything about gamut (but rather 
about color depth ), although 
it may be possible that wide gamuts and high color depth correlate 1:1. Can 
you clarify if that's what you meant?
 

> , I think it's probably incorrect to report that (dynamic-range: high) is 
 true based only on the device, which is what it looks to me like the 
 current 
 code 
 
  does.  
 Admittedly, the spec could probably use some clarification as to what it 
 means for the User Agent to fulfill the criteria for both the 
 dynamic-range and video-dynamic-range queries, but my understanding of 
 what the spec is trying to say is that Chrome probably shouldn't say that 
 (dynamic-range: 
 high) is true until it supports wide-gamut colors in at least some and 
 maybe all of those contexts.
>>>
>>>
>>> I think you're right that the spec needs some clarification, since we're 
>>> trying to incrementally enable adoption of HDR on the web the intent isn't 
>>> to signal that HDR is supported by all APIs. We do already support HDR 
>>> in some scenarios, such as the  element, so having these queries 
>>> exist to let developers detect display capabilities is already useful.
>>>
>>> On Wed, Oct 20, 2021 at 11:27 PM Yoav Weiss  
>>> wrote:
>>>


 On Thu, Oct 21, 2021 at 7:01 AM Will Cassella  
 wrote:

> Thanks for the feedback! I've updated that section:
>
> Debuggability
>
> Styles with these media queries can be viewed and edited in the 
> devtools frontend, albeit without proper highlighting. I've created pull 
> requests on the relevant libraries used in the devtools frontend to 
> enable 
> this. https://github.com/stylelint/stylelint/pull/5613 
> https://github.com/codemirror/CodeMirror/pull/6803
>
> On Wednesday, October 20, 2021 at 9:10:36 AM UTC-7 Mathias Bynens 
> wrote:
>
>> On Wed, Oct 20, 2021 at 5:44 PM Will Cassella  
>> wrote:
>>
>>> Contact emailscas...@chromium.org, chcunning...@chromium.org, 
>>> videostack-...@chromium.org
>>>
>>> Explainer
>>> Adds MediaQueries for detecting HDR vs HDR displays
>>> https://www.w3.org/TR/mediaqueries-5/#dynamic-range
>>> https://www.w3.org/TR/mediaqueries-5/#video-dynamic-range
>>>
>>> Specificationhttps://www.w3.org/TR/mediaqueries-5/#dynamic-range
>>>
>>> Summary
>>>
>>> Adds media queries to CSS which allow a page to detect the current 
>>> display device’s support for HDR. This feature adds two new CSS media 

Re: [blink-dev] Intent to Extend Origin Trial: Subresource loading with Web Bundles

[Mike West]

On Thu, Oct 28, 2021 at 6:49 AM Daisuke Enomoto 
wrote:

>
> Contact emails
>
> hay...@chromium.org, denom...@chromium.org
>
> Explainer
>
>
> https://github.com/WICG/webpackage/blob/master/explainers/subresource-loading.md
>
> Specification
> Design docs
>
>
> https://chromium.googlesource.com/chromium/src.git/+/refs/heads/master/content/browser/web_package/subresource_loading_origin_trial.md
>
> Summary
>
> Provides a new approach to load a large number of resources efficiently
> using a format that allows multiple resources to be bundled, e.g. Web
> Bundles.
>
> Blink component
>
> Blink>Loader>WebPackaging
> 
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/616
>
> (We’ll reopen this once we can have a consensus in the discussion here
> )
>
> TAG review status
>
> Pending
>
> Risks
> Interoperability and Compatibility
>
> No interoperability and compatibility risk has been identified for the
> prototype phase. This is purely a feature addition for the performance
> optimization for now.
>
> It is expected that a browser which doesn’t support this feature should
> load subresources from the network, as usual.
>
>
> Gecko: No signal
>
> WebKit: No signal
>
> Web developers: No signals
>

This might be a good time to ask, as per https://bit.ly/blink-signals. :)


>
> Ergonomics
> Activation
>
> Developers need to package their subresoruces beforehand in order to take
> advantage of this feature. We'll work with JS bundler ecosystems to provide
> a plugin to package subresources as Web Bundles.
>
> Security
>
> No security risk has been identified for the prototype phase.
>
> Goals for experimentation
>
> 
>
> This Intent to Extend includes a few major changes based on the feedback
> collected during the original OT, which are 1) 

Re: [blink-dev] Intent to Ship: [WebAuthn] Authenticator Attachment in Public Key Credential

[Yoav Weiss]

LGTM2 with similar conditions.

On Thursday, October 21, 2021 at 9:23:45 PM UTC+2 Alex Russell wrote:

> Thanks for explaining, Adam.
>
> I'm LGTM1 contingent on:
>
>- An explainer being produced with at least the content of Adam's last 
>post being included.
>- An FYI being sent to the TAG w/ that Explainer attached. We don't 
>have a policy that allows folks to arbitrarily decide not to send things 
> to 
>them w/o justification.
>
> Thanks
>
> On Friday, October 15, 2021 at 12:15:34 PM UTC-7 Adam Langley wrote:
>
>> On Thursday, October 14, 2021 at 1:49:39 AM UTC-7 yoav...@chromium.org 
>> wrote:
>>
>>> Apologies, but it's not clear to me what this does. A higher-level 
>>> explainer may be helpful here.
>>>
>>
>> When returning a WebAuthn assertion, browsers will say whether the 
>> assertion came from a removable device or not. I.e. if you touch a security 
>> key it'll say "cross-platform", but if you use Touch ID / Windows Hello 
>> it'll say "platform".
>>
>> Sites could already figure this out because they learn the supported 
>> transports of an authenticator during registration and removable devices 
>> offer things like "usb" or "ble", while the platform authenticators (Touch 
>> ID / Hello) say "internal". But we want to make this simpler for sites so 
>> that they have a clear signal when offering to register the platform as an 
>> authenticator might be useful.
>>
>> The vision is that, when phones are fully usable as security keys, users 
>> will be able to sign into sites on a desktop browser with them. But that 
>> site might want to know that a "removable" device was used (e.g. a phone) 
>> because registering the platform authenticator for future sign-ins is 
>> probably a better experience.
>>
>>
 *TAG review*

 N/A

>>>
>>> Why is a TAG review not applicable? 
>>>
>>
>> Seems like a very minor change and TAG is a very heavy process.
>>  
>>
>>> Web developers: No signals

>>>  
>>> Are developers likely to adopt this? If not, why are we adding this?
>>> https://goo.gle/developer-signals
>>>
>>
>> Other parts of an ecosystem need to slot into place in order for 
>> everything to hang together: phones as security keys, syncing credentials, 
>> conditional UI, etc. So developers are probably uninterested in this part 
>> in isolation, but all together there's a fair amount of interest. GitHub, 
>> at least, are public about WebAuthn L2 being insufficient without several 
>> of changes in this set: 1  2 
>>  3 
>> .
>>  
>>
>>>
 Edge: Support Signals

>>> Any links?
>>>
>>
>> Microsoft supporting here 
>> . 
>> (See "Assertion Transports" section; WG discussion changed "transports" to 
>> "attachment", which is what this thread is talking about.)
>>
>>
>> Cheers
>>
>> AGL
>>
>

-- 
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/dcf59370-4687-4c34-90cf-6ca18635cdfdn%40chromium.org.

Re: [blink-dev] Intent to Ship: [WebAuthn] Authenticator Attachment in Public Key Credential

[Mike West]

LGTM2 with similar caveats to Alex's comments above. I realize that this is
a small change, but I hope that also means that the work required to
produce a clear explanation of the change is minimal. Alternatively, it
might be helpful to produce an explainer walking through the overarching
story around phones as authenticators, with this as a small piece of that
bigger picture. That might be more valuable, both for you and for the TAG.

-mike


On Thu, Oct 21, 2021 at 9:23 PM Alex Russell 
wrote:

> Thanks for explaining, Adam.
>
> I'm LGTM1 contingent on:
>
>- An explainer being produced with at least the content of Adam's last
>post being included.
>- An FYI being sent to the TAG w/ that Explainer attached. We don't
>have a policy that allows folks to arbitrarily decide not to send things to
>them w/o justification.
>
> Thanks
>
> On Friday, October 15, 2021 at 12:15:34 PM UTC-7 Adam Langley wrote:
>
>> On Thursday, October 14, 2021 at 1:49:39 AM UTC-7 yoav...@chromium.org
>> wrote:
>>
>>> Apologies, but it's not clear to me what this does. A higher-level
>>> explainer may be helpful here.
>>>
>>
>> When returning a WebAuthn assertion, browsers will say whether the
>> assertion came from a removable device or not. I.e. if you touch a security
>> key it'll say "cross-platform", but if you use Touch ID / Windows Hello
>> it'll say "platform".
>>
>> Sites could already figure this out because they learn the supported
>> transports of an authenticator during registration and removable devices
>> offer things like "usb" or "ble", while the platform authenticators (Touch
>> ID / Hello) say "internal". But we want to make this simpler for sites so
>> that they have a clear signal when offering to register the platform as an
>> authenticator might be useful.
>>
>> The vision is that, when phones are fully usable as security keys, users
>> will be able to sign into sites on a desktop browser with them. But that
>> site might want to know that a "removable" device was used (e.g. a phone)
>> because registering the platform authenticator for future sign-ins is
>> probably a better experience.
>>
>>
 *TAG review*

 N/A

>>>
>>> Why is a TAG review not applicable?
>>>
>>
>> Seems like a very minor change and TAG is a very heavy process.
>>
>>
>>> Web developers: No signals

>>>
>>> Are developers likely to adopt this? If not, why are we adding this?
>>> https://goo.gle/developer-signals
>>>
>>
>> Other parts of an ecosystem need to slot into place in order for
>> everything to hang together: phones as security keys, syncing credentials,
>> conditional UI, etc. So developers are probably uninterested in this part
>> in isolation, but all together there's a fair amount of interest. GitHub,
>> at least, are public about WebAuthn L2 being insufficient without several
>> of changes in this set: 1  2
>>  3
>> .
>>
>>
>>>
 Edge: Support Signals

>>> Any links?
>>>
>>
>> Microsoft supporting here
>> .
>> (See "Assertion Transports" section; WG discussion changed "transports" to
>> "attachment", which is what this thread is talking about.)
>>
>>
>> Cheers
>>
>> AGL
>>
> --
> 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/dd8302d9-709c-4d5a-9d14-b33da77039f8n%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/CAKXHy%3Dc_3rHUJ9xG4om9j9s8qU%2BpM%3DeZ73ZzzeGLN%2BXt%2B16YLw%40mail.gmail.com.

Re: [blink-dev] Intent to Prototype: Capability Delegation

['Mustaq Ahmed' via blink-dev]

Thanks for your feedback, Jun.  That's an important point that calls for
clarification:

This is spec is probably written with the assumption that Permission
> Delegation
> 
> is implemented (or should be implemented) in all browsers. However,
> Permission Delegation is not a Web Standard, and browsers (and other user
> agent) are free to implement any sort of permission model.
>

We made no such assumption here about Permissions.  Our intent is to only
define a generic API for delegation  here, and to leave any
capability-specific details to capability-owners.  Any "capability" here
could be Permission-gated (like camera and web-usb) or Permission-agnostic
(like fullscreen and popup), and the capability-owners will decide, on a
case-by-case basis, which Permission model they would like to incorporate,
if at all.

Having said that, a recent comment in our TAG review issue
 seems to be
suggesting a generalized behavior for capabilities which is not what we
intended this for.  Let's continue this discussion there for greater
visibility.


On Wed, Oct 27, 2021 at 3:28 AM 'Jun Kokatsu' via blink-dev <
blink-dev@chromium.org> wrote:

> This is spec is probably written with the assumption that Permission
> Delegation
> 
> is implemented (or should be implemented) in all browsers. However,
> Permission Delegation is not a Web Standard, and browsers (and other user
> agent) are free to implement any sort of permission model.
>
> For example, a browser without Permission Delegation would require
> permission prompt from iframe (which contains origin of iframe in the
> prompt) in order to use any permission-based API. Permission Policy or
> allow attribute are just there to allow permission request from iframes,
> but that doesn't necessary mean that permission is delegated directly to
> iframe.
>
> If you try to ship Capability Delegation API in above model, this would be
> a bypass of permission prompt or delegating permission to cross-origin
> iframes without user's knowledge.
>
> Thanks,
>
> Jun
>
> On Monday, July 12, 2021 at 9:31:24 AM UTC-7 Mustaq Ahmed wrote:
>
>> A few quick updates:
>> - The WICG/capability-delegation
>>  repository is the
>> current home for the explainer and a spec draft
>> .
>> - Please use a new/existing issue
>>  for any comments
>> or suggestions.
>> - We filed a TAG review request
>>  two weeks ago.
>>
>>
>>
>> On Wed, Nov 18, 2020 at 5:01 PM Mustaq Ahmed  wrote:
>>
>>> Hi Daniel:
>>>
>>> Sorry for the delay, thanks for listing those concerns.
>>>
>>> I have added a Privacy and security considerations
>>> 
>>>  section
>>> in the design doc to address three of the concerns, please take a look and
>>> let us know if we missed anything.  I haven't yet replied to the Spectre
>>> point, I need to fully understand the attack vector you are thinking of.
>>>
>>> The relation to Feature/Permission Policy is still an open question, we
>>> will need some time to answer this.
>>>
>>> Mustaq
>>>
>>>
>>> On Fri, Nov 6, 2020 at 12:04 PM Daniel Vogelheim 
>>> wrote:
>>>
 Hello Mustaq,

 We've discussed your intent within security + privacy teams. The
 discussion raised a number of concerns, but we couldn't find enough detail
 to either substantiate or allay them. This unfortunately makes it difficult
 to give you actionable feedback.

 Our thoughts: This API effectively packages a permission / user
 interaction in a token and allows it to be sent somewhere else, creating a
 permission-capability-thing. This raises a number of questions:

 - The idea of gating functionality on user interaction is to make sure
 that the user understands what they are interacting with. If a user
 interaction is 'packaged' and sent for consumption elsewhere, does this
 still hold? Could a malicious user put the 'packaged' interaction to a
 surprising use?
 - Are there limits to where it can be passed to? Could it be passed -
 via a server round-trip - to another site running in the same browser?
 - Is there any info on the API that would consume the token?
 - The token is unspecified, but seems to follow the pattern of
 'unguessable secret number'. The problem here is with the Spectre attack
 family, where we've had to change our assumption to assume that any data
 within a process is potentially readable, even by sandboxed code. Under
 this assumption, could the tok

Re: [blink-dev] Intent to Deprecate and Remove: WebSQL in third-party contexts

[Ari Chivukula]

I agree with you, and hope we can soon make such an announcement (and add
the warning for developers).

On Thu, Oct 28, 2021 at 07:56 Fernando Serboncini 
wrote:

> Given that we are disabling this for 3rd parties, would it make sense to
> already start warning 1st-party usage (saying that this doesn't work at all
> for 3rd parties and that it will be removed in the future)?
>
> I don't know what's the guideline regarding having a deprecation warning
> without a clear milestone and also if it's reasonable to do a warning for a
> feature that has 1% usage
> .
> But I suggest this because:
> 1. the current behavior (only 1st party) may be a bit surprising, if not
> contextualized with "this feature is being deprecated".
> 2. early warning is better?
>
>
> On Wed, Oct 27, 2021 at 5:33 PM Ari Chivukula 
> wrote:
>
>> Sorry for the delay, the data for actually reading/writing a database
>> 
>> (as opposed to opening it
>> )
>> in a third party context ended up being nearly identical (0.03% of loads
>> and about 10% of top-sites).
>>
>> The code I spot checked still seems to gate usage of WebSQL on
>> availability. That said, the change in M97 is linked to a feature flag so
>> can be undone if there are issues in dev/beta. Also, there's an enterprise
>> policy available to enable it (planned to exist until M102, when it'll be
>> removed entirely and not simply disabled by default).
>>
>> ~ Ari Chivukula (Their/There/They're)
>>
>>
>> On Thu, Aug 5, 2021 at 12:21 PM Alex Russell 
>> wrote:
>>
>>> LGTM3 with the caveats Yoav outlines. Would like to hear back about the
>>> new usecounter data on this thread before 97 branch point.
>>>
>>> Thank you for taking so much care with this deprecation.
>>>
>>> On Thursday, July 29, 2021 at 3:50:14 PM UTC-7 Chris Harrelson wrote:
>>>
 LGTM2

 On Wed, Jul 28, 2021 at 9:50 AM Yoav Weiss 
 wrote:

> Deprecating in M94 while adding a usecounter sounds like a solid
> strategy. Please update this thread with the results from the usecounter
> once they are available.
>
> *LGTM1* to deprecate in M94 and remove support in M97, barring
> usecounter surprises.
>
> On Wed, Jul 28, 2021 at 6:38 PM Ari Chivukula 
> wrote:
>
>> I'm saying something slightly different, that the usage I'm seeing is
>> (1) checking for the existence of the function (instead of simply looking
>> for if the engine is Blink) and (2) wrapping the subsequent call to
>> opendatabase in a try statement (as per the spec which allows errors to 
>> be
>> raised https://www.w3.org/TR/webdatabase/#databases). I think we're
>> safe to (1) deprecate the function in third party contexts to alert
>> developers to the change in M94 and then (2) raise SECURITY_ERR in a 
>> later
>> milestone once we've completed outreach around M97 or later.
>>
>> When I do (1) I could also add a counter into M94 which looks for
>> actual usage of a created database beyond the feature detection we seem 
>> to
>> be catching now.
>>
>> ~ Ari Chivukula (Their/There/They're)
>>
>>
>> On Wed, Jul 28, 2021 at 6:21 AM Yoav Weiss 
>> wrote:
>>
>>> So, you're saying that the usage we see is simply feature detection
>>> for the API and not real usage? Any way to add use counters that would
>>> confirm this?
>>>
>>> On Monday, July 26, 2021 at 6:38:19 PM UTC+2 Ari Chivukula wrote:
>>>
 @manuel: Thanks for the corrected code pointer!
 @yoav: The sample on the platform status page (
 https://www.chromestatus.com/metrics/feature/timeline/popularity/3865)
 highlighted a bunch of Hyundai dealerships, but when loading locally 
 I'm
 unable to reproduce the creation of any WebSQL databases. I did find 
 usage
 on https://accounts.mint.com/index.html, but when searching the
 scripts which created it I found that all checked if 
 window.openDatabase
 even existed. The lack of support in Gecko and WebKit seems to have 
 broken
 in the deprecation/removal codepath for us.

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


 On Mon, Jul 26, 2021 at 7:46 AM Manuel Rego Casasnovas <
 r...@igalia.com> wrote:

>
>
> On 26/07/2021 12:32, Yoav Weiss wrote:
> > WebKit: Deprecated in version 608 (Safari 13)
> > <
> https://github.com/WebKit/WebKit/commit/761bce943c0696a6bb93116eb0576ed07dbfdc65
> >
>
> That's a change related to WebKitGTK+ and WPE, where they marked
> the API
> as deprecated.
>
> Anyway it seems this was re

Re: [blink-dev] Intent to Deprecate and Remove: WebSQL in third-party contexts

[Fernando Serboncini]

Given that we are disabling this for 3rd parties, would it make sense to
already start warning 1st-party usage (saying that this doesn't work at all
for 3rd parties and that it will be removed in the future)?

I don't know what's the guideline regarding having a deprecation warning
without a clear milestone and also if it's reasonable to do a warning for a
feature that has 1% usage
.
But I suggest this because:
1. the current behavior (only 1st party) may be a bit surprising, if not
contextualized with "this feature is being deprecated".
2. early warning is better?


On Wed, Oct 27, 2021 at 5:33 PM Ari Chivukula  wrote:

> Sorry for the delay, the data for actually reading/writing a database
> 
> (as opposed to opening it
> )
> in a third party context ended up being nearly identical (0.03% of loads
> and about 10% of top-sites).
>
> The code I spot checked still seems to gate usage of WebSQL on
> availability. That said, the change in M97 is linked to a feature flag so
> can be undone if there are issues in dev/beta. Also, there's an enterprise
> policy available to enable it (planned to exist until M102, when it'll be
> removed entirely and not simply disabled by default).
>
> ~ Ari Chivukula (Their/There/They're)
>
>
> On Thu, Aug 5, 2021 at 12:21 PM Alex Russell 
> wrote:
>
>> LGTM3 with the caveats Yoav outlines. Would like to hear back about the
>> new usecounter data on this thread before 97 branch point.
>>
>> Thank you for taking so much care with this deprecation.
>>
>> On Thursday, July 29, 2021 at 3:50:14 PM UTC-7 Chris Harrelson wrote:
>>
>>> LGTM2
>>>
>>> On Wed, Jul 28, 2021 at 9:50 AM Yoav Weiss 
>>> wrote:
>>>
 Deprecating in M94 while adding a usecounter sounds like a solid
 strategy. Please update this thread with the results from the usecounter
 once they are available.

 *LGTM1* to deprecate in M94 and remove support in M97, barring
 usecounter surprises.

 On Wed, Jul 28, 2021 at 6:38 PM Ari Chivukula 
 wrote:

> I'm saying something slightly different, that the usage I'm seeing is
> (1) checking for the existence of the function (instead of simply looking
> for if the engine is Blink) and (2) wrapping the subsequent call to
> opendatabase in a try statement (as per the spec which allows errors to be
> raised https://www.w3.org/TR/webdatabase/#databases). I think we're
> safe to (1) deprecate the function in third party contexts to alert
> developers to the change in M94 and then (2) raise SECURITY_ERR in a later
> milestone once we've completed outreach around M97 or later.
>
> When I do (1) I could also add a counter into M94 which looks for
> actual usage of a created database beyond the feature detection we seem to
> be catching now.
>
> ~ Ari Chivukula (Their/There/They're)
>
>
> On Wed, Jul 28, 2021 at 6:21 AM Yoav Weiss 
> wrote:
>
>> So, you're saying that the usage we see is simply feature detection
>> for the API and not real usage? Any way to add use counters that would
>> confirm this?
>>
>> On Monday, July 26, 2021 at 6:38:19 PM UTC+2 Ari Chivukula wrote:
>>
>>> @manuel: Thanks for the corrected code pointer!
>>> @yoav: The sample on the platform status page (
>>> https://www.chromestatus.com/metrics/feature/timeline/popularity/3865)
>>> highlighted a bunch of Hyundai dealerships, but when loading locally I'm
>>> unable to reproduce the creation of any WebSQL databases. I did find 
>>> usage
>>> on https://accounts.mint.com/index.html, but when searching the
>>> scripts which created it I found that all checked if window.openDatabase
>>> even existed. The lack of support in Gecko and WebKit seems to have 
>>> broken
>>> in the deprecation/removal codepath for us.
>>>
>>> ~ Ari Chivukula (Their/There/They're)
>>>
>>>
>>> On Mon, Jul 26, 2021 at 7:46 AM Manuel Rego Casasnovas <
>>> r...@igalia.com> wrote:
>>>


 On 26/07/2021 12:32, Yoav Weiss wrote:
 > WebKit: Deprecated in version 608 (Safari 13)
 > <
 https://github.com/WebKit/WebKit/commit/761bce943c0696a6bb93116eb0576ed07dbfdc65
 >

 That's a change related to WebKitGTK+ and WPE, where they marked
 the API
 as deprecated.

 Anyway it seems this was removed in Safari (at least on WebKit2, it
 might be still available in WebKit1 though). See this thread:

 https://lists.webkit.org/pipermail/webkit-dev/2019-November/030970.html
 And also this commit:
 https://trac.webkit.org/changeset/277564/webkit

 Cheers,
   Rego
>>

Re: [blink-dev] Intent to Ship: CSS Color Adjust: 'only' keyword for color-scheme

[Rune Lillesveen]

On Thu, Oct 28, 2021 at 12:11 PM Manuel Rego Casasnovas 
wrote:

> Hi,
>
> Some comments inline.
>
> On 27/10/2021 16:09, Rune Lillesveen wrote:
> > Summary
> >
> > The 'only' keyword has been re-added to the specification for
> > color-scheme as a way of per-element opt-out of color-scheme override
> > like forced darkening.
>
> I guess this is the CSSWG discussion about re-adding it:
> https://github.com/w3c/csswg-drafts/issues/5089


Correct.

> Previously, both declarations below would force the div element into
> > color-scheme dark and apply forced darkening. With this change, the
> > second declaration would opt-out of forced darkening and keep the used
> > color-scheme 'light'.
> >
> > div { color-scheme: light } div { color-scheme: only light } will keep
> > the color-scheme for the element light and opt-out of forced darkening.
>
> Let me clarify this comment, this is happening when we're in forced
> darkening, am I right?
> First I read it too quickly and "color-scheme: light" forcing the DIV
> into color-scheme dark was weird.
>

Correct, when we're in forced darkening, or color-scheme override which is
the term used by the specification.

> This feature is already enabled as part of an original trial in M96:
> > https://chromestatus.com/features/5672533924773888
> > 
>
> Do we have any results to comment from the origin trial? Or it was
> mostly for auto dark mode and this was just a small bit of it?
>

That was mostly for auto dark mode, but Peter can confirm.

> Gecko: In development
> > (https://bugzilla.mozilla.org/show_bug.cgi?id=1576289
> > ) Development of
> > the color-scheme property in progress. At least blocker issues are being
> > fixed.
>
> Not sure if this is in development, as there seems to be not recent
> activity on the bug; but they indeed look interested in implementing
> color-scheme property. Do we have any feedback from Mozilla about this
> "only" keyword?
>

Emilio (added) has been fixing blocker issues, fixing tests, doing spec
changes for , etc, which I took as a signal of
Mozilla working on it.

-- 
Rune Lillesveen

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

Re: [blink-dev] Intent to Prototype and Ship: self.structuredClone

[Joyee Cheung]

This would be a great addition. Node.js also has been shipping this since 
v17.0.0 .
On Thursday, October 28, 2021 at 5:12:32 AM UTC+8 fs...@chromium.org wrote:

> This is amazing! :)
>
> I agree it shouldn't block this, but do we have anywhere written what 
> are the browser's differences on structured clone algorithms? Is it a spec 
> issue? Could we add WPT tests for it?
>
> On Wed, Oct 27, 2021 at 2:45 PM Andreu Botella  
> wrote:
>
>> * Contact emails*
>> and...@andreubotella.com, jbr...@chromium.org, su...@chromium.org 
>>
>> *Explainer*
>> https://github.com/whatwg/html/issues/793 
>>
>> *Specification*
>> https://html.spec.whatwg.org/#structured-cloning 
>>
>> * Summary*
>> Enables using the HTML structured clone algorithm synchronously for 
>> cloning and transferring objects within a single realm. 
>>
>> * Initial public proposal*
>> https://github.com/whatwg/html/issues/793 
>> https://github.com/whatwg/html/pull/3414 
>>
>> *Blink component*
>> Blink>Messaging 
>> 
>>  
>>
>> * TAG review*
>> This is just exposing existing browser functionality, with a two-line 
>> spec. It doesn’t seem like there’s much to discuss architecturally, but 
>> I’ll file for review if the community thinks it would help. 
>>
>> *TAG review status*
>> Not applicable 
>>
>> * Risks*
>>
>> * Interoperability and Compatibility*
>> Low. There are some differences across the browsers’ implementations of 
>> the structured cloning algorithm, but they are very minor and already 
>> present in other APIs that use it. 
>>
>> Gecko: Shipped/Shipping (
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1722576) 
>> Edge: No signal 
>> WebKit: Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=228331) 
>>
>>
>> Web developers: Positive (
>> https://github.com/whatwg/html/pull/3414#issuecomment-854051942 and 
>> following comments). There seems to be a lot of demand for a built-in deep 
>> clone, and while structured clone is not exactly that, it fulfills many of 
>> the use cases. 
>>
>> * Debuggability*
>> n/a 
>>
>> * Is this feature fully tested by web-platform-tests 
>> ?*
>> Yes 
>> 
>>  
>>
>> * Requires code in //chrome?*
>> False 
>>
>> * Tracking bug*
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1233571 
>>
>> *Estimated milestones*
>> No milestones specified 
>>
>> * Link to entry on the Chrome Platform Status*
>> https://chromestatus.com/feature/5630001077551104 
>>
>> *Requesting approval to ship? *
>> Yes. This is a relatively small feature which exposes existing 
>> functionality.
>>
>> -- 
>> 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/e7299674-54df-4f4d-8c30-d922ebf4e47cn%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/e3668dd8-59c0-4aea-8126-643512f61085n%40chromium.org.

Re: [blink-dev] Intent to Ship: CSS Color Adjust: 'only' keyword for color-scheme

[Manuel Rego Casasnovas]

Hi,

Some comments inline.

On 27/10/2021 16:09, Rune Lillesveen wrote:
> Summary
> 
> The 'only' keyword has been re-added to the specification for
> color-scheme as a way of per-element opt-out of color-scheme override
> like forced darkening.

I guess this is the CSSWG discussion about re-adding it:
https://github.com/w3c/csswg-drafts/issues/5089

> Previously, both declarations below would force the div element into
> color-scheme dark and apply forced darkening. With this change, the
> second declaration would opt-out of forced darkening and keep the used
> color-scheme 'light'.
> 
> div { color-scheme: light } div { color-scheme: only light } will keep
> the color-scheme for the element light and opt-out of forced darkening.

Let me clarify this comment, this is happening when we're in forced
darkening, am I right?
First I read it too quickly and "color-scheme: light" forcing the DIV
into color-scheme dark was weird.

> This feature is already enabled as part of an original trial in M96:
> https://chromestatus.com/features/5672533924773888
> 

Do we have any results to comment from the origin trial? Or it was
mostly for auto dark mode and this was just a small bit of it?

> Gecko: In development
> (https://bugzilla.mozilla.org/show_bug.cgi?id=1576289
> ) Development of
> the color-scheme property in progress. At least blocker issues are being
> fixed.

Not sure if this is in development, as there seems to be not recent
activity on the bug; but they indeed look interested in implementing
color-scheme property. Do we have any feedback from Mozilla about this
"only" keyword?

Cheers,
  Rego

-- 
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/d0597dcb-b87a-cd31-8a2e-1650ae4f%40igalia.com.

Re: [blink-dev] Intent to Implement and Ship : onsecuritypolicyviolation event handler IDL attribute

[Manuel Rego Casasnovas]

This will ship in M97.

Cheers,
  Rego

On 27/10/2021 19:24, 'Joe Medley' via blink-dev wrote:
> Hi,
> 
> In which version of Chrome do you hope to ship?
> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com
>  | 816-678-7195
> /If an API's not documented it doesn't exist./
> 
> 
> On Thu, Oct 21, 2021 at 11:14 AM Daniel Bratell  > wrote:
> 
> Indeed, so I'm making my LGTM2 on the other thread into an LGTM3 on
> this thread.
> 
> /Daniel
> 
> On 2021-10-21 09:08, Yoav Weiss wrote:
>> LGTM2 to catch up here
>>
>> (Apparently we have 2 intent emails for this..)
>>
>> On Thu, Oct 21, 2021 at 3:50 AM TAMURA, Kent > > wrote:
>>
>> LGTM1.  It's a small straight-forward change.
>>
>>
>>
>> On Thu, Oct 21, 2021 at 12:44 AM > > wrote:
>>
>> Contact emails
>> ssin...@igalia.com ,
>> fw...@chromium.org 
>>
>> Explainer:
>> The securitypolicyviolation event is already implemented
>> in all
>> browsers, one can find document on
>> 
>> MDN(https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers/onsecuritypolicyviolation
>> 
>> ,
>> 
>> https://developer.mozilla.org/en-US/docs/Web/API/Element/securitypolicyviolation_event
>> 
>> ).
>> The securitypolicyviolation event is dispatched when there
>> is a Content
>> Security Policy violation. Typically, the JS code of the
>> web component
>> will listen to securitypolicyviolation events and react
>> with necessary
>> updates.
>>
>> One could just use addEventListener, but for convenience
>> and consistency
>> with other events (e.g. slotchange) it makes sense to add
>> a IDL
>> onsecuritypolicyviolation attribute which also reflect the
>> attribute on
>> elements. We recently shipped slotchange idl attriubte as well
>> 
>> (https://groups.google.com/a/chromium.org/g/blink-dev/c/cagoIboJ6Oo/m/yje1mcIUBAAJ
>> 
>> )
>>
>> Developers are habitual to use EventTarget.onload = ...
>> and > onload="..."> , but if this does not work for all events,
>> it will be
>> surprising.
>>
>> Currently, the way to listen an event is:
>> target.addEventListener("securitypolicyviolation",
>> mylistener);
>>
>> After this addition an alternative attribute-based form
>> will be
>> availlable for the developers
>> element
>> 
>>
>> Doc Link(s):
>> -
>> https://html.spec.whatwg.org/#handler-onsecuritypolicyviolation
>> 
>> - https://github.com/whatwg/html/pull/2651
>> 
>> -
>> https://chromium-review.googlesource.com/c/chromium/src/+/3226366
>> 
>> 
>>
>> Specification
>> https://html.spec.whatwg.org 
>>
>> Summary
>> The securitypolicyviolation event is fired when a Content
>> Security
>> Policy is violated.One can listen to that event via the
>> EventTarget.addEventListener() API. The goal is now to
>> expose the
>> onsecuritypolicyviolation IDL attribute from the
>> GlobalEventHandlers
>> interface, so that one can register a listener by
>> attaching this
>> attribute to target elements.
>>
>> Blink component
>> Blink>DOM
>>
>> Motivation
>> The securitypolicyviolation event is fired when a Content
>> Security
>> Policy is violated.
>> One can naturally listen to that event via the
>> EventTarget.addEventListener() API. However, web
>> developers are also
>> familiar with the alternative attribute-based form (e.g.
>> element.addEventListener("securitypolicyviolation
>> ", ...) Vs on )
>> which is sometimes convenient for quick testing. For
>> consistency with
>> other events, an attribute