Re: [chromium-dev] Re: [blink-dev] Inactive OWNERS cleanup

[Glen Robertson]

> Having your name on OWNERS is an award for your previous amazing
contributions
I'm concerned that being in OWNERS is regarded as a reward, and being
removed as a penalty -- it is part of the problem with cleaning up inactive
OWNERS. I'd much prefer to have a separate "amazing contributors" file to
list people who have made amazing contributions, without this affecting the
code review process.

Owners are supposed to be

active reviewers for a directory. I'd even expect us to remove people who
go on long leave, unless Gerrit can understand that status and avoid
suggesting them for reviews (currently it does not do that well). Re-adding
an owner is not an arduous process, but adding days to a code review is a
significant cost.

I recently tried a similar automated audit of inactive owners - I looked
for anyone who hadn't reviewed or authored a CL in 12 months anywhere,
regardless of activity in the directory and found
 (as
list, Google internal only
)
many accounts that no longer exist (or perhaps never did) in OWNERS. It
probably has different false positives than the proposed set above. Maybe
the intersection of the two sets would be sensible?

On Thu, 28 Jul 2022 at 07:45, Pavel Feldman  wrote:

> The data in the table seems off, what is considered a "review": is that a
> "Code Review +1" or is that any review comment?
> I also have an edge case where I'm mostly interested in several files in a
> folder where other files are being changed more frequently, should I be
> optimizing OWNERS to list myself as per-file?
>
> On Wednesday, July 27, 2022 at 2:16:47 PM UTC-7 Matt Menke wrote:
>
>> Maybe it would make more sense to identify OWNERS who are not active
>> globally in chrome/, instead of owners not active in a particular
>> directory?  How common are OWNERS active in Chrome, but high latency only
>> for specific directories?  I'm asking as someone who was recently inundated
>> by auto-generated removal CLs, the majority of which did not make sense
>> (admittedly, I believe it wasn't based on activity).  The tool even seemed
>> to want to remove all owners from some directories.
>>
>> On Wednesday, July 27, 2022 at 5:03:05 PM UTC-4 k...@chromium.org wrote:
>>
>>> I echo Dana's concern about removing per-file owners and would like to
>>> see that policy rethought. Agree with Peter's observations as well.
>>>
>>> -Ken
>>>
>>>
>>>
>>> On Wed, Jul 27, 2022 at 9:12 AM Peter Boström 
>>> wrote:
>>>
 I'm worried that this process excludes/penalizes folks who may be OOO
 for extended leave (incl long stretches of parental leave, bereavement) and
 have that in their Gerrit status. This should not be a source of review
 latency, if it is Gerrit should better surface that they are OOO.

 Are any of the inactive owners, who did opt out last time, a source of
 review latency? I.e. are reviews assigned to them but they don't review
 them within some SLO window? Otherwise I strongly suggest we let folks
 decline the OWNERS removal (at other OWNERS' discretion who should probably
 review removal CLs).

 On Wed, Jul 27, 2022 at 8:08 AM  wrote:

>>> This list includes per-file owners, did the script look for 100 CLs in 
>>> *those
> files* named by the rule when deciding to remove the person?
>
> On Tue, Jul 26, 2022 at 9:16 PM Kentaro Hara 
> wrote:
>
 Hi
>>
>> As of 2022 July, Chromium has 4531 OWNERS files containing 6850
>> names. These include inactive owners, which are one of the sources of 
>> slow
>> code review latency. One year ago, we cleaned up inactive owners
>> 
>> and removed ~500 inactive owners. I propose running the clean-up process
>> again to keep the OWNERS files updated.
>>
>> Specifically, a person is identified as an "inactive" owner iff:
>>
>>-
>>
>>The person didn't commit or review any CLs in the directory they
>>own while there were 100+ CLs that touched the directory in the past 6
>>months (as of July 6, 2022).
>>
>> Last year, I gave the inactive owners an option to flip the decision
>> manually to stay as an owner, but for this cycle, I'm planning to remove
>> the inactive owners unconditionally. The rationale is 1) if the person 
>> made
>> no contribution on a very active directory for 6 months, it will be
>> reasonable to say that the person is inactive, and 2) if there is any
>> special reason for it and the person needs to stay as an owner, the 
>> person
>> can show evidence that they are meeting the owners expe

[blink-dev] Re: Intent to Ship: MSE in Workers

[Matthew Wolenetz]

I've filed a new request-for-position using the new WebKit process for this
today.
The previous request was:
https://lists.webkit.org/pipermail/webkit-dev/2021-June/031916.html
The new one is: https://github.com/WebKit/standards-positions/issues/40

I've also updated chromestatus' WebKit signals citation to use the new
request.

On Wed, Jul 27, 2022 at 12:32 PM Matthew Wolenetz 
wrote:

> Further note, this feature's shipping will entail switching two
> blink RuntimeEnabled features from experimental to stable simultaneously:
>
>- MediaSourceInWorkers
>- MediaSourceInWorkersUsingHandle
>
> A CL [1] is already prepared to do this switch once this intent is
> approved. The plan is, once that CL has landed and baked in trunk, to
> request and merge it to the branch for M105.
>
> [1] https://chromium-review.googlesource.com/c/chromium/src/+/3781750
>
> On Wed, Jul 27, 2022 at 12:06 PM Matthew Wolenetz 
> wrote:
>
>> Contact emailswolen...@chromium.org
>>
>> Explainer
>> https://github.com/wicg/media-source/blob/mse-in-workers-using-handle/mse-in-workers-using-handle-explainer.md
>>
>> Specificationhttps://www.w3.org/TR/media-source-2
>>
>> Design docs
>>
>> https://github.com/wicg/media-source/blob/mse-in-workers-using-handle/mse-in-workers-using-handle-explainer.md
>> https://goto.google.com/mse-in-workers
>>
>> Summary
>>
>> Enable Media Source Extensions (MSE) API usage from DedicatedWorker
>> contexts to enable improved performance of buffering media for playback by
>> an HTMLMediaElement on the main Window context. By creating a MediaSource
>> object on a DedicatedWorker context, an application may then obtain a
>> MediaSourceHandle from it and transfer that handle to the main thread for
>> use in attaching to an HTMLMediaElement. The context that created the
>> MediaSource object may then use it to buffer media.
>>
>>
>> Blink componentBlink>Media
>> 
>>
>> Search tagsMSE , MediaSource
>> ,
>> MediaSourceExtensions
>> 
>>
>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/656
>>
>> TAG review statusIssues addressed
>>
>> Link to origin trial feedback summary
>> https://github.com/w3c/media-source/issues/175#issuecomment-1045018594
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> Main interoperability risk is that other browsers may not implement it.
>> Compatibility risk is mitigated by unchanged same-thread MSE API support
>> and proactive feature-detectability of MSE-in-Workers with a new
>> canConstructInDedicatedWorker attribute on the MediaSource interface.
>>
>>
>> *Gecko*: Positive (
>> https://github.com/mozilla/standards-positions/issues/547)
>>
>> *WebKit*: No signal (
>> https://lists.webkit.org/pipermail/webkit-dev/2021-June/031916.html)
>> @jernoble has been involved in feature specification discussions in the
>> Media Workgroup and has provided generally positive feedback.
>>
>> *Web developers*: Strongly positive (
>> https://github.com/w3c/media-source/issues/175#issuecomment-1045018594)
>> Twitch reported "large positive impact on our topline metrics such as
>> buffering and time to video. We'd love for all browsers to adopt
>> MSE-in-Workers." More (positive) details have been shared and are currently
>> pending them posting them at a public location.
>>
>> *Other signals*:
>>
>> Ergonomics
>>
>> DedicatedWorker, WorkerGlobalScope and postMessage/onmessage availability
>> is integral to using this feature.
>>
>>
>> Activation
>>
>> The primary risk is the potential difficulty in refactoring existing MSE
>> web applications to (conditionally, depending on browser support) perform
>> buffering in a different execution context from the Window context that
>> hosts the DOM and the media element. The benefit of potentially improved
>> buffering performance by offloading the MSE API usage to a worker context
>> provides motivation to overcome this challenge.
>>
>>
>> Security
>>
>> Unpredictability of racing context destruction of either the main thread
>> hosting the media element (and owning the underlying MSE media demuxer and
>> player) or the dedicated worker thread hosting the interface to the MSE
>> demuxer when using MSE from a worker context motivated careful design of a
>> refcounted, outside-of-Oilpan, attachment abstraction to ensure safety of
>> operations using locks and having a lifetime that exceeds those execution
>> contexts. Preventing use-after-free and similar was a primary complexity of
>> implementation and a focus area of added tests.
>>
>>
>> WebView application risks
>>
>> Does this intent deprecate or change behavior of existing APIs, such that
>> it has potentially high risk for Android WebView-based applications?
>>
>> Not potentially high risk.
>>
>>
>> Debuggability
>>
>> Feature consists of exposing e

Re: [chromium-dev] Re: [blink-dev] Inactive OWNERS cleanup

[Pavel Feldman]

The data in the table seems off, what is considered a "review": is that a 
"Code Review +1" or is that any review comment?
I also have an edge case where I'm mostly interested in several files in a 
folder where other files are being changed more frequently, should I be 
optimizing OWNERS to list myself as per-file?

On Wednesday, July 27, 2022 at 2:16:47 PM UTC-7 Matt Menke wrote:

> Maybe it would make more sense to identify OWNERS who are not active 
> globally in chrome/, instead of owners not active in a particular 
> directory?  How common are OWNERS active in Chrome, but high latency only 
> for specific directories?  I'm asking as someone who was recently inundated 
> by auto-generated removal CLs, the majority of which did not make sense 
> (admittedly, I believe it wasn't based on activity).  The tool even seemed 
> to want to remove all owners from some directories.
>
> On Wednesday, July 27, 2022 at 5:03:05 PM UTC-4 k...@chromium.org wrote:
>
>> I echo Dana's concern about removing per-file owners and would like to 
>> see that policy rethought. Agree with Peter's observations as well.
>>
>> -Ken
>>
>>
>>
>> On Wed, Jul 27, 2022 at 9:12 AM Peter Boström  wrote:
>>
>>> I'm worried that this process excludes/penalizes folks who may be OOO 
>>> for extended leave (incl long stretches of parental leave, bereavement) and 
>>> have that in their Gerrit status. This should not be a source of review 
>>> latency, if it is Gerrit should better surface that they are OOO.
>>>
>>> Are any of the inactive owners, who did opt out last time, a source of 
>>> review latency? I.e. are reviews assigned to them but they don't review 
>>> them within some SLO window? Otherwise I strongly suggest we let folks 
>>> decline the OWNERS removal (at other OWNERS' discretion who should probably 
>>> review removal CLs).
>>>
>>> On Wed, Jul 27, 2022 at 8:08 AM  wrote:
>>>
>> This list includes per-file owners, did the script look for 100 CLs in 
>> *those 
 files* named by the rule when deciding to remove the person?

 On Tue, Jul 26, 2022 at 9:16 PM Kentaro Hara  
 wrote:

>>> Hi
>
> As of 2022 July, Chromium has 4531 OWNERS files containing 6850 names. 
> These include inactive owners, which are one of the sources of slow code 
> review latency. One year ago, we cleaned up inactive owners 
> 
>  
> and removed ~500 inactive owners. I propose running the clean-up process 
> again to keep the OWNERS files updated.
>
> Specifically, a person is identified as an "inactive" owner iff:
>
>- 
>
>The person didn't commit or review any CLs in the directory they 
>own while there were 100+ CLs that touched the directory in the past 6 
>months (as of July 6, 2022).
>
> Last year, I gave the inactive owners an option to flip the decision 
> manually to stay as an owner, but for this cycle, I'm planning to remove 
> the inactive owners unconditionally. The rationale is 1) if the person 
> made 
> no contribution on a very active directory for 6 months, it will be 
> reasonable to say that the person is inactive, and 2) if there is any 
> special reason for it and the person needs to stay as an owner, the 
> person 
> can show evidence that they are meeting the owners expectations 
> 
>  
> and be readded through the standard OWNERS nomination process.
>
> Specifically, people listed in this spreadsheet 
> 
>  
> are identified as inactive owners and will be removed.
>
> I understand this is a tricky proposal. Having your name on OWNERS is 
> an award for your previous amazing contributions, and I understand your 
> feeling about your name being removed. However, I think it's important to 
> keep the OWNERS files updated so that Chromium developers can find active 
> owners and improve the code review latency.
>
> If you have any questions / concerns, please let me know. Thanks!
> -- 
> Kentaro Hara, Tokyo
>
> -- 
> 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/CABg10jyArLjDp0ixPu%2BCSZ9NVrn0M1GwNFiJqiPGRE1f0mrbfQ%40mail.gmail.com
>  
> 
> .
>
 -

[blink-dev] Re: PSA: Multi-Screen Window Placement implementation change (Accurate Screen Labels)

['Ajay Rahatekar' via blink-dev]

Please let us know of any comments/concerns. As mentioned in the PSA, we 
are hoping to target M105 for shipping this change.

Thanks in advance.

On Friday, July 22, 2022 at 1:05:36 PM UTC-7 Brad Triebwasser wrote:

> Hello blink-dev,
>
> Following previous guidance, I would like to distribute this PSA regarding 
> an implementation change for a previously shipped Multi Screen Window 
> Placement API surface. In particular, we are changing Chrome's 
> implementation of the ScreenDetailed.label attribute.
>
>
> See below for the specifics of this change including the implementation 
> and launch bugs. We are currently targeting a launch in M105.
>
>
> Contact emails
>
> btr...@chromium.org, m...@chromium.org
>
>
> Explainer
>
>
> https://github.com/w3c/window-placement/blob/main/EXPLAINER.md#:~:text=DOMString%20label
>  
> 
>
>
> Specification
>
> https://w3c.github.io/window-placement/#dom-screendetailed-label
>
>
> Summary
>
> Enhances screen label strings provided by the Multi-Screen Window 
> Placement API: 
>
>
> This launch refines the `ScreenDetailed.label` implementation by replacing 
> the current placeholder values (e.g. 'External Display 1') with data 
> sourced from display device EDIDs (e.g. 'HP Z27n') and higher-level OS APIs 
> (e.g. localized descriptions such as 'Built-in Retina Display'). These more 
> accurate labels match those shown by OSes in display settings UI surfaces. 
> The labels are only exposed to sites which have been granted the 
> window-placement permission by the user.
>
>
> This revised implementation aligns with the current attribute 
> specification  and 
> definitions used for the M93-M96 Origin Trial and the M100 API launch. 
> There is no structural change to the API, only a change in the string 
> content returned by the `ScreenDetailed.label` attribute. The new labels 
> are intended to allow the end user to better identify and tell the 
> difference between screens. Applications can’t assume that the label 
> contains any specific information, such as the device type, model, 
> dimensions, density, etc.
>
>
> Blink component
>
> Blink>Screen>MultiScreen 
> 
>
>
> Motivation
>
> Multi-Screen Window Placement API partners have requested this change to 
> provide more recognizable and user-friendly entries in screen selection 
> interfaces.
>
>
> Initial public proposal
>
>
> https://github.com/w3c/window-placement/blob/f2386c13d879aa3a84e3a46e380d00a663644654/EXPLAINER.md#:~:text=DOMString%20label
>
>
> TAG review
>
> The original window placement API design review is here:
>
> https://github.com/w3ctag/design-reviews/issues/602
>
>
> TAG review status
>
> Issues open
>
>
> Risks
> Interoperability and Compatibility
>
>
> Gecko: No signal (
> https://github.com/mozilla/standards-positions/issues/542) Link is for 
> the original window placement API which has some feedback but no definitive 
> signal.
>
>
> WebKit: No signal (
> https://lists.webkit.org/pipermail/webkit-dev/2021-June/031903.html) Link 
> is for the original window placement API which has some feedback but no 
> definitive signal.
>
>
> Web developers: Positive
>
> (Specifically requested by Multi-Screen Window Placement API partners)
>
>
> Other signals:
>
> WebView application risks
> N/A
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac, 
> Linux, Chrome OS, Android, and Android WebView)?
>
> The Multi-Screen Window Placement API is currently available only on 
> desktop platforms (Windows, Mac, Linux, Chrome OS).
>
>
> Is this feature fully tested by web-platform-tests 
> 
> ?
>
> Yes. WPTs are limited to checking the string type for now.
>
>
> https://wpt.fyi/results/screen-details/getScreenDetails.tentative.https.window.html
>
>
> DevTrial instructions
>
> https://github.com/w3c/window-placement/blob/main/HOWTO.md
>
>
> Flag name
>
> --enable-blink-features=WindowPlacementEnhancedScreenLabels
>
>
> Requires code in //chrome?
>
> False
>
>
> Tracking bug
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=1254885
>
>
> Launch bug
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=1317749
>
>
> Sample links
>
> https://michaelwasserman.github.io/window-placement-demo
>
>
> Estimated milestones
>
> DevTrial on desktop: 104
>
> Shipping on desktop: 105
>
>
> Anticipated spec changes
>
> None
>
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/6317530778959872
>
>
> This message was generated by Chrome Platform Status 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" gro

Re: [chromium-dev] Re: [blink-dev] Inactive OWNERS cleanup

['Matt Menke' via blink-dev]

Maybe it would make more sense to identify OWNERS who are not active 
globally in chrome/, instead of owners not active in a particular 
directory?  How common are OWNERS active in Chrome, but high latency only 
for specific directories?  I'm asking as someone who was recently inundated 
by auto-generated removal CLs, the majority of which did not make sense 
(admittedly, I believe it wasn't based on activity).  The tool even seemed 
to want to remove all owners from some directories.

On Wednesday, July 27, 2022 at 5:03:05 PM UTC-4 k...@chromium.org wrote:

> I echo Dana's concern about removing per-file owners and would like to see 
> that policy rethought. Agree with Peter's observations as well.
>
> -Ken
>
>
>
> On Wed, Jul 27, 2022 at 9:12 AM Peter Boström  wrote:
>
>> I'm worried that this process excludes/penalizes folks who may be OOO for 
>> extended leave (incl long stretches of parental leave, bereavement) and 
>> have that in their Gerrit status. This should not be a source of review 
>> latency, if it is Gerrit should better surface that they are OOO.
>>
>> Are any of the inactive owners, who did opt out last time, a source of 
>> review latency? I.e. are reviews assigned to them but they don't review 
>> them within some SLO window? Otherwise I strongly suggest we let folks 
>> decline the OWNERS removal (at other OWNERS' discretion who should probably 
>> review removal CLs).
>>
>> On Wed, Jul 27, 2022 at 8:08 AM  wrote:
>>
> This list includes per-file owners, did the script look for 100 CLs in *those 
>>> files* named by the rule when deciding to remove the person?
>>>
>>> On Tue, Jul 26, 2022 at 9:16 PM Kentaro Hara  
>>> wrote:
>>>
 Hi

 As of 2022 July, Chromium has 4531 OWNERS files containing 6850 names. 
 These include inactive owners, which are one of the sources of slow code 
 review latency. One year ago, we cleaned up inactive owners 
 
  
 and removed ~500 inactive owners. I propose running the clean-up process 
 again to keep the OWNERS files updated.

 Specifically, a person is identified as an "inactive" owner iff:

- 

The person didn't commit or review any CLs in the directory they 
own while there were 100+ CLs that touched the directory in the past 6 
months (as of July 6, 2022).

 Last year, I gave the inactive owners an option to flip the decision 
 manually to stay as an owner, but for this cycle, I'm planning to remove 
 the inactive owners unconditionally. The rationale is 1) if the person 
 made 
 no contribution on a very active directory for 6 months, it will be 
 reasonable to say that the person is inactive, and 2) if there is any 
 special reason for it and the person needs to stay as an owner, the person 
 can show evidence that they are meeting the owners expectations 
 
  
 and be readded through the standard OWNERS nomination process.

 Specifically, people listed in this spreadsheet 
 
  
 are identified as inactive owners and will be removed.

 I understand this is a tricky proposal. Having your name on OWNERS is 
 an award for your previous amazing contributions, and I understand your 
 feeling about your name being removed. However, I think it's important to 
 keep the OWNERS files updated so that Chromium developers can find active 
 owners and improve the code review latency.

 If you have any questions / concerns, please let me know. Thanks!
 -- 
 Kentaro Hara, Tokyo

 -- 
 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/CABg10jyArLjDp0ixPu%2BCSZ9NVrn0M1GwNFiJqiPGRE1f0mrbfQ%40mail.gmail.com
  
 
 .

>>> -- 
>>> -- 
>>> Chromium Developers mailing list: chromi...@chromium.org
>>> View archives, change email options, or unsubscribe: 
>>> http://groups.google.com/a/chromium.org/group/chromium-dev
>>> --- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Chromium-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to chromium-dev...@chromium.org.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/a/chromi

Re: [chromium-dev] Re: [blink-dev] Inactive OWNERS cleanup

[Ken Russell]

I echo Dana's concern about removing per-file owners and would like to see
that policy rethought. Agree with Peter's observations as well.

-Ken



On Wed, Jul 27, 2022 at 9:12 AM Peter Boström  wrote:

> I'm worried that this process excludes/penalizes folks who may be OOO for
> extended leave (incl long stretches of parental leave, bereavement) and
> have that in their Gerrit status. This should not be a source of review
> latency, if it is Gerrit should better surface that they are OOO.
>
> Are any of the inactive owners, who did opt out last time, a source of
> review latency? I.e. are reviews assigned to them but they don't review
> them within some SLO window? Otherwise I strongly suggest we let folks
> decline the OWNERS removal (at other OWNERS' discretion who should probably
> review removal CLs).
>
> On Wed, Jul 27, 2022 at 8:08 AM  wrote:
>
>> This list includes per-file owners, did the script look for 100 CLs in *those
>> files* named by the rule when deciding to remove the person?
>>
>> On Tue, Jul 26, 2022 at 9:16 PM Kentaro Hara 
>> wrote:
>>
>>> Hi
>>>
>>> As of 2022 July, Chromium has 4531 OWNERS files containing 6850 names.
>>> These include inactive owners, which are one of the sources of slow code
>>> review latency. One year ago, we cleaned up inactive owners
>>> 
>>> and removed ~500 inactive owners. I propose running the clean-up process
>>> again to keep the OWNERS files updated.
>>>
>>> Specifically, a person is identified as an "inactive" owner iff:
>>>
>>>-
>>>
>>>The person didn't commit or review any CLs in the directory they own
>>>while there were 100+ CLs that touched the directory in the past 6 months
>>>(as of July 6, 2022).
>>>
>>> Last year, I gave the inactive owners an option to flip the decision
>>> manually to stay as an owner, but for this cycle, I'm planning to remove
>>> the inactive owners unconditionally. The rationale is 1) if the person made
>>> no contribution on a very active directory for 6 months, it will be
>>> reasonable to say that the person is inactive, and 2) if there is any
>>> special reason for it and the person needs to stay as an owner, the person
>>> can show evidence that they are meeting the owners expectations
>>> 
>>> and be readded through the standard OWNERS nomination process.
>>>
>>> Specifically, people listed in this spreadsheet
>>> 
>>> are identified as inactive owners and will be removed.
>>>
>>> I understand this is a tricky proposal. Having your name on OWNERS is an
>>> award for your previous amazing contributions, and I understand your
>>> feeling about your name being removed. However, I think it's important to
>>> keep the OWNERS files updated so that Chromium developers can find active
>>> owners and improve the code review latency.
>>>
>>> If you have any questions / concerns, please let me know. Thanks!
>>> --
>>> Kentaro Hara, Tokyo
>>>
>>> --
>>> 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/CABg10jyArLjDp0ixPu%2BCSZ9NVrn0M1GwNFiJqiPGRE1f0mrbfQ%40mail.gmail.com
>>> 
>>> .
>>>
>> --
>> --
>> Chromium Developers mailing list: chromium-...@chromium.org
>> View archives, change email options, or unsubscribe:
>> http://groups.google.com/a/chromium.org/group/chromium-dev
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Chromium-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to chromium-dev+unsubscr...@chromium.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAHtyhaTNC4tgQbqbUq%2BQdFfcORr3aFobjgbeE%2BTaVf7eDgU2Bg%40mail.gmail.com
>> 
>> .
>>
> --
> --
> Chromium Developers mailing list: chromium-...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-dev
> ---
> You received this message because you are subscribed to the Google Groups
> "Chromium-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to chromium-dev+unsubscr...@chromium.org.
> To view this di

[blink-dev] Re: Intent to Extend Origin Trial: MSE in Workers

[Matthew Wolenetz]

I need to request a further extension of this origin trial, to end in M104
instead of the current end of 103.

While I've just sent the intent-to-ship for this feature
 (with
target milestone 105), I have just received a request from another major
web developer for the origin trial to be extended into 104.

The full implementation and stabilization of this feature didn't land until
early in the 105 milestone due to some API changes requested by
participants in the media workgroup discussions of this feature.
While these changes in 105 are not expected to be part of the origin trial,
the bulk of the MSE-in-Workers implementation remains usable via the
origin-trial-feature "MediaSourceInWorkers" using the older API shape.
The primary change in the API shape is to use a MediaSourceHandle for
attaching a worker MediaSource instead of a MediaSource object URL.
Extending the OT into 104 will enable experimentation as requested by the
web developer.

Please review this request and advise on next steps. Note, this is not
intended to replace the intent to ship in 105 for this feature, but instead
to let the feature continue to be experimented with in 104.

Thank you,
Matt

On Wed, Feb 23, 2022 at 9:06 AM Matthew Wolenetz 
wrote:

> Thank you. The results so far have been very encouraging, so I expect no
> further extension would be necessary beyond 103.
>
> On Wed, Feb 23, 2022 at 5:18 AM Yoav Weiss  wrote:
>
>> LGTM to continue experimenting till M103. Note that this will bring the
>> OT to 9 releases, so it'd be good to wrap up experimentation by this
>> extension's end.
>>
>> On Wednesday, February 16, 2022 at 11:03:08 PM UTC+1 Matthew Wolenetz
>> wrote:
>>
>>> Hello blink-dev,
>>>
>>> We'd like to ask for an extension to our Origin Trial, from M99 to M103.
>>>
>>> There are two reasons extension is necessary:
>>>
>>> 1) A breaking error discovered in the middle of the trial (see
>>> https://crbug.com/1268614) caused participation to drop before the 2021
>>> holiday period. While the fix landed by early 2022 and at least one
>>> participant has reported excellent improvement in metrics in their
>>> experiment since then, further stabilization is desired.
>>>
>>> 2) An API change for this feature (using srcObject for MSE-in-Workers
>>> attachments instead of baking in objectURL attachment further) was agreed
>>> with the media workgroup last September [1] following the previous
>>> objectURL-based attachment design getting more recent feedback [2], and I'm
>>> working on getting that into both the feature spec and Chromium's
>>> experimental implementation currently for rapid experimentation during the
>>> extended trial.
>>>
>>> [1] https://www.w3.org/2021/09/14-mediawg-minutes.html
>>> [2] https://github.com/mozilla/standards-positions/issues/547
>>>
>>>
>>> Please find the Chrome status template, below:
>>>
>>>
>>> Contact emailswolen...@chromium.org
>>>
>>> Explainer
>>> https://github.com/wicg/media-source/blob/mse-in-workers-using-handle/mse-in-workers-using-handle-explainer.md
>>>
>>> Specificationhttps://github.com/w3c/media-source/pull/282
>>>
>>> Summary
>>>
>>> Enable Media Source Extensions (MSE) API usage from DedicatedWorker
>>> contexts to enable improved performance of buffering media for playback by
>>> an HTMLMediaElement on the main Window context. By creating a MediaSource
>>> object on a DedicatedWorker context, an application may then create an
>>> ObjectURL for it and postMessage that URL to the main thread for use in
>>> attaching to an HTMLMediaElement. The context that created the MediaSource
>>> object may then use it to buffer media.
>>>
>>>
>>> Blink componentBlink>Media
>>> 
>>>
>>> Search tagsMSE , MediaSource
>>> ,
>>> MediaSourceExtensions
>>> 
>>>
>>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/656
>>>
>>> TAG review statusIssues addressed
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> Main interoperability risk is that other browsers may not implement it.
>>> Compatibility risk is mitigated by unchanged same-thread MSE API support
>>> and proactive feature-detectability of MSE-in-Workers with a new
>>> canConstructInDedicatedWorker attribute on the MediaSource interface.
>>>
>>>
>>> Gecko: No signal (
>>> https://github.com/mozilla/standards-positions/issues/547)
>>>
>>> WebKit: No signal (
>>> https://lists.webkit.org/pipermail/webkit-dev/2021-June/031916.html)
>>>
>>> Web developers: No signals
>>>
>>> Other signals:
>>>
>>> Ergonomics
>>>
>>> DedicatedWorker, WorkerGlobalScope and postMessage/onmessage
>>> availability is integral to using this feature.
>>>
>>>
>>> Activation
>>>
>>> The primary risk is the potential difficulty in refactoring e

[blink-dev] Re: Intent to Ship: MSE in Workers

[Matthew Wolenetz]

Further note, this feature's shipping will entail switching two
blink RuntimeEnabled features from experimental to stable simultaneously:

   - MediaSourceInWorkers
   - MediaSourceInWorkersUsingHandle

A CL [1] is already prepared to do this switch once this intent is
approved. The plan is, once that CL has landed and baked in trunk, to
request and merge it to the branch for M105.

[1] https://chromium-review.googlesource.com/c/chromium/src/+/3781750

On Wed, Jul 27, 2022 at 12:06 PM Matthew Wolenetz 
wrote:

> Contact emailswolen...@chromium.org
>
> Explainer
> https://github.com/wicg/media-source/blob/mse-in-workers-using-handle/mse-in-workers-using-handle-explainer.md
>
> Specificationhttps://www.w3.org/TR/media-source-2
>
> Design docs
>
> https://github.com/wicg/media-source/blob/mse-in-workers-using-handle/mse-in-workers-using-handle-explainer.md
> https://goto.google.com/mse-in-workers
>
> Summary
>
> Enable Media Source Extensions (MSE) API usage from DedicatedWorker
> contexts to enable improved performance of buffering media for playback by
> an HTMLMediaElement on the main Window context. By creating a MediaSource
> object on a DedicatedWorker context, an application may then obtain a
> MediaSourceHandle from it and transfer that handle to the main thread for
> use in attaching to an HTMLMediaElement. The context that created the
> MediaSource object may then use it to buffer media.
>
>
> Blink componentBlink>Media
> 
>
> Search tagsMSE , MediaSource
> ,
> MediaSourceExtensions
> 
>
> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/656
>
> TAG review statusIssues addressed
>
> Link to origin trial feedback summary
> https://github.com/w3c/media-source/issues/175#issuecomment-1045018594
>
> Risks
>
>
> Interoperability and Compatibility
>
> Main interoperability risk is that other browsers may not implement it.
> Compatibility risk is mitigated by unchanged same-thread MSE API support
> and proactive feature-detectability of MSE-in-Workers with a new
> canConstructInDedicatedWorker attribute on the MediaSource interface.
>
>
> *Gecko*: Positive (
> https://github.com/mozilla/standards-positions/issues/547)
>
> *WebKit*: No signal (
> https://lists.webkit.org/pipermail/webkit-dev/2021-June/031916.html)
> @jernoble has been involved in feature specification discussions in the
> Media Workgroup and has provided generally positive feedback.
>
> *Web developers*: Strongly positive (
> https://github.com/w3c/media-source/issues/175#issuecomment-1045018594)
> Twitch reported "large positive impact on our topline metrics such as
> buffering and time to video. We'd love for all browsers to adopt
> MSE-in-Workers." More (positive) details have been shared and are currently
> pending them posting them at a public location.
>
> *Other signals*:
>
> Ergonomics
>
> DedicatedWorker, WorkerGlobalScope and postMessage/onmessage availability
> is integral to using this feature.
>
>
> Activation
>
> The primary risk is the potential difficulty in refactoring existing MSE
> web applications to (conditionally, depending on browser support) perform
> buffering in a different execution context from the Window context that
> hosts the DOM and the media element. The benefit of potentially improved
> buffering performance by offloading the MSE API usage to a worker context
> provides motivation to overcome this challenge.
>
>
> Security
>
> Unpredictability of racing context destruction of either the main thread
> hosting the media element (and owning the underlying MSE media demuxer and
> player) or the dedicated worker thread hosting the interface to the MSE
> demuxer when using MSE from a worker context motivated careful design of a
> refcounted, outside-of-Oilpan, attachment abstraction to ensure safety of
> operations using locks and having a lifetime that exceeds those execution
> contexts. Preventing use-after-free and similar was a primary complexity of
> implementation and a focus area of added tests.
>
>
> WebView application risks
>
> Does this intent deprecate or change behavior of existing APIs, such that
> it has potentially high risk for Android WebView-based applications?
>
> Not potentially high risk.
>
>
> Debuggability
>
> Feature consists of exposing existing interfaces also on a
> DedicatedWorker, and addition of a WebIDL method for proactively detecting
> support for this feature, and are covered by basic tooling.
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?Yes
>
> MSE and DedicatedWorker already exist on all six Blink platforms. This
> feature lets MSE work from DedicatedWorker contexts.
>
>
> Is this feature fully tested by web-platform-tests
> 

[blink-dev] Intent to Ship: MSE in Workers

[Matthew Wolenetz]

Contact emailswolen...@chromium.org

Explainer
https://github.com/wicg/media-source/blob/mse-in-workers-using-handle/mse-in-workers-using-handle-explainer.md

Specificationhttps://www.w3.org/TR/media-source-2

Design docs
https://github.com/wicg/media-source/blob/mse-in-workers-using-handle/mse-in-workers-using-handle-explainer.md
https://goto.google.com/mse-in-workers

Summary

Enable Media Source Extensions (MSE) API usage from DedicatedWorker
contexts to enable improved performance of buffering media for playback by
an HTMLMediaElement on the main Window context. By creating a MediaSource
object on a DedicatedWorker context, an application may then obtain a
MediaSourceHandle from it and transfer that handle to the main thread for
use in attaching to an HTMLMediaElement. The context that created the
MediaSource object may then use it to buffer media.


Blink componentBlink>Media


Search tagsMSE , MediaSource
, MediaSourceExtensions


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

TAG review statusIssues addressed

Link to origin trial feedback summary
https://github.com/w3c/media-source/issues/175#issuecomment-1045018594

Risks


Interoperability and Compatibility

Main interoperability risk is that other browsers may not implement it.
Compatibility risk is mitigated by unchanged same-thread MSE API support
and proactive feature-detectability of MSE-in-Workers with a new
canConstructInDedicatedWorker attribute on the MediaSource interface.


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

*WebKit*: No signal (
https://lists.webkit.org/pipermail/webkit-dev/2021-June/031916.html)
@jernoble has been involved in feature specification discussions in the
Media Workgroup and has provided generally positive feedback.

*Web developers*: Strongly positive (
https://github.com/w3c/media-source/issues/175#issuecomment-1045018594)
Twitch reported "large positive impact on our topline metrics such as
buffering and time to video. We'd love for all browsers to adopt
MSE-in-Workers." More (positive) details have been shared and are currently
pending them posting them at a public location.

*Other signals*:

Ergonomics

DedicatedWorker, WorkerGlobalScope and postMessage/onmessage availability
is integral to using this feature.


Activation

The primary risk is the potential difficulty in refactoring existing MSE
web applications to (conditionally, depending on browser support) perform
buffering in a different execution context from the Window context that
hosts the DOM and the media element. The benefit of potentially improved
buffering performance by offloading the MSE API usage to a worker context
provides motivation to overcome this challenge.


Security

Unpredictability of racing context destruction of either the main thread
hosting the media element (and owning the underlying MSE media demuxer and
player) or the dedicated worker thread hosting the interface to the MSE
demuxer when using MSE from a worker context motivated careful design of a
refcounted, outside-of-Oilpan, attachment abstraction to ensure safety of
operations using locks and having a lifetime that exceeds those execution
contexts. Preventing use-after-free and similar was a primary complexity of
implementation and a focus area of added tests.


WebView application risks

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

Not potentially high risk.


Debuggability

Feature consists of exposing existing interfaces also on a DedicatedWorker,
and addition of a WebIDL method for proactively detecting support for this
feature, and are covered by basic tooling.


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

MSE and DedicatedWorker already exist on all six Blink platforms. This
feature lets MSE work from DedicatedWorker contexts.


Is this feature fully tested by web-platform-tests

?Yes

DevTrial instructions
https://github.com/w3c/media-source/issues/175#issuecomment-721395481

Flag nameMediaSourceInWorkers

Requires code in //chrome?False

Tracking bughttps://crbug.com/878133

MeasurementPrior to M105 (when worker MediaSource was attachable only by
object URL): Blink.UseCounter.Features.CreateObjectURLMediaSourceFromWorker
As of 105.0.5180.0 (when attachment of worker MediaSource was changed to be
done using transferable MediaSourceHandle):
Blink.UseCounter.Features.MediaSourceGetHandle

Non-OSS dependencies

Does the feature depend on any code or APIs outside the Chromium open
source repository and its open-source dep

Re: [blink-dev] Intent to extend experiment: Privacy Sandbox Ads APIs

[Johnny Stenback]

Hey Josh,

As a general rule, please send one intent per feature as that'll help
ensure all the intents get marked as approved in Chromestatus appropriately
and we can help ensure that OT milestones etc are all up to date.

Thanks,
Johnny

On Wed, Jul 27, 2022 at 9:48 AM Josh Karlin  wrote:

> Greetings. The Privacy Sandbox Ads APIs experiment includes several APIs
> and we'd like to extend all of them another three milestones to M107, with
> the expectation that we will likely continue to ask for extensions to
> support ecosystem testing.
>
> This OT covers several APIs (Attribution Reporting
> ,
> FLEDGE
> ,
> Topics
> ,
> Fenced Frames
> ,
> and Shared Storage
> )
> that are part of the Privacy Sandbox initiative. Based on feedback we
> have already received
> , it
> will take more time before experimenters can provide the feedback that we
> need to validate and improve them. We also expect to add several new
> features for testing (including Shared Storage and support for FLEDGE on
> mobile) in upcoming releases.
>
> I've bundled the requests for each API into a single intent to extend
> since they are part of the same OT and all require the extension. If you'd
> like, they can instead be requested individually.
>
> Thanks,
>
> Josh
>
> --
> 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/CAANMuaO4BR3PMHJ8r-%2BzBpb2cDfbMKs%2Bg8syM-8ZUnSnrA5KTw%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/CACZRgz5tN-jpoSkqM2%3DxXj1%3DzXe5zZR-HYjMoNTm4KeEtSsK%3Dw%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: CSS Overflow for replaced elements

[jmedley via Chromestatus]

Yoav, Im putting together the beta post draft. Is the deprecation being 
extended? Joe

-- 
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/0150c505e4ccd008%40google.com.

[blink-dev] Intent to extend experiment: Privacy Sandbox Ads APIs

[Josh Karlin]

Greetings. The Privacy Sandbox Ads APIs experiment includes several APIs
and we'd like to extend all of them another three milestones to M107, with
the expectation that we will likely continue to ask for extensions to
support ecosystem testing.

This OT covers several APIs (Attribution Reporting
,
FLEDGE
,
Topics
,
Fenced Frames
,
and Shared Storage
)
that are part of the Privacy Sandbox initiative. Based on feedback we have
already received
, it
will take more time before experimenters can provide the feedback that we
need to validate and improve them. We also expect to add several new
features for testing (including Shared Storage and support for FLEDGE on
mobile) in upcoming releases.

I've bundled the requests for each API into a single intent to extend since
they are part of the same OT and all require the extension. If you'd like,
they can instead be requested individually.

Thanks,

Josh

-- 
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/CAANMuaO4BR3PMHJ8r-%2BzBpb2cDfbMKs%2Bg8syM-8ZUnSnrA5KTw%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Ship: Intl.NumberFormat v3 API

[Mike Taylor]

LGTM2

On 7/27/22 8:08 AM, Daniel Bratell wrote:


LGTM1

/Daniel

On 2022-07-23 02:41, Frank Tang wrote:

It was flip to stage on m105 and try to flip to ship for m106
R2T for m105 could be found on 1Q2FHx9hBAAJ 



On Fri, Jul 22, 2022 at 5:36 PM Frank Tang  wrote:



Contact emails

ft...@google.com


Specification


https://github.com/tc39/proposal-intl-numberformat-v3#ecma-402-proposal-intlnumberformat-v3


Design docs



https://docs.google.com/document/d/19jAogPBb6W4Samt8NWGZKu47iv0_KoQhBvLgQH3xvr8/edit#heading=h.86ckkob9p59r

https://docs.google.com/document/d/14zxGub6Os6nARzH6XstOZX05w2537sZo_ZSSlGjGpBM/edit#heading=h.86ckkob9p59r


Summary

Intl.NumberFormat v3 API is a new TC39 ECMA402 stage 3 proposal
extend the pre-existing Intl.NumberFormat, with the following new
features: 1. Add 3 new functions to format range of number:
formatRange / formatRangeToParts / selectRange 2. Grouping Enum
3. New Rounding/Precision Options 4. Rounding Priority 5.
Interpret Strings as Decimals 6. Rounding Modes 7. Sign Display
Negative https://github.com/tc39/proposal-intl-numberformat-v3



Blink component

Blink>JavaScript>Internationalization




TAG review



TAG review status

Not applicable


Risks



Interoperability and Compatibility

This API change the pre-existing Intl.NumberFormat API by adding
new options to control the formatted output, adding several new
method to Intl.NumberFormat and take string form of data for
higher precision. It is advanced to TC39 Stage 3 in the July
2020. Engineer from Firefox team is supporting this proposal .



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

/WebKit/: Shipped/Shipping
(https://bugs.webkit.org/show_bug.cgi?id=215438)
https://developer.apple.com/safari/technology-preview/release-notes/ 
(Release
139)

/Web developers/: No signals

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

/Other signals/: https://github.com/tc39/test262/issues/3132


Ergonomics

The implementation depend on ICU class
LocalizedNumberRangeFormatter class. To avoid producing negative
impact to pre-exiting usage of Intl.NumberFormat, we optimize it
by using lazy eval in
https://chromium-review.googlesource.com/c/v8/v8/+/3555261.



Activation

Web developers could use the API immediately upon our shipment,
based on the usage of previous well supported Intl.NumberFormat
object.



Security

no risk aware off



WebView application risks

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



Debuggability

nothing special



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

Yes


Is this feature fully tested by web-platform-tests

?

No


Flag name

--harmony-intl-number-format-v3


Requires code in //chrome?

False


Tracking bug

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


Launch bug

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


Estimated milestones

DevTrial on desktop 106

DevTrial on Android 106


sorry both should be DevTrail for 105 (already flipped a month ago).

I intend to *ship* for *m106* but maybe I change the values in the 
incorrect place in the UI causing this draft email incorrect.




Anticipated spec changes

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



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5707621009981440


Links to previous Intent discussions

Intent to prototype:

https://mail.google.com/mail/u/0/#search/stage+intl+numberformat/KtbxLxgRQQFXbKqWhsdWzfnRLCZNTWHnvV


This intent message was generated by Chrome Platform Status
.

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

Re: [blink-dev] Re: Intent to Experiment: COOP: restrict-properties

[Mike Taylor]

LGTM to experiment from M106 to M110.

On 7/27/22 9:00 AM, 'Arthur Hemery' via blink-dev wrote:

Please note that a TAG issue was just filed:
https://github.com/w3ctag/design-reviews/issues/760

On Tue, Jul 26, 2022 at 4:59 PM Arthur Hemery  wrote:


Contact emails

ahem...@chromium.org


Explainer

https://github.com/hemeryar/explainers/blob/main/coop_restrict_properties.md


Specification

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


Summary

Cross-Origin-Opener-Policy is used to sever the relationship
between popup and openers, to increase security.
"restrict-properties" is a proposed value that restricts the
relationship instead of completely severing it. It would enable
crossOriginIsolated when paired with COEP.



Blink component

Blink>SecurityFeature>COOP




Search tags

COOP ,
restrict-properties





Risks



Interoperability and Compatibility

It could fail to become an interoperable part of the web platform
if other browsers do not implement it. The OT is intended to
gather user feedback to get support from Mozilla.



/Gecko/: No signal

/WebKit/: No signal

/Web developers/: No signals

/Other signals/: Have a few partners interested in trying this out
like Zoom and Facebook, as well as at least one internal partner
(altimin@ for perfetto dashboards).


WebView application risks

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



Goals for experimentation

The goal for this experiment is to give partners the possibility
to try the new value at scale and to discover potential deployment
blockers that were not anticipated (e.g. external dependency,
same-origin communications required, etc.)


Debuggability

COOP reporting will support restricted cross-origin properties
reporting, similar to what exists for other COOP values.


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

Yes

COOP is parsed on all platforms, but the process model implied
might vary.



Is this feature fully tested by web-platform-tests

?

Yes under
wpt/html/cross-origin-opener-policy/tentative/restrict-properties.


Flag name

--enable-features='CoopRestrictProperties'


Requires code in //chrome?

False


Tracking bug

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


Launch bug

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


Estimated milestones

OriginTrial desktop last110
OriginTrial desktop first   106

OriginTrial Android last110
OriginTrial Android first   106




Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5072630953017344


Links to previous Intent discussions

Intent to prototype:

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAF07A2Uw-Oh0d7ktTPnV%3D8TTrr%2BNcTgfiLxzFd2P2QLD18qNsw%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/CAF07A2Uj8%3DeUzcs8-o4RxAJnJN8%2BGCpPZNY3ky5Y88-UvhFtiA%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/bc9e72bf-fc63-f842-d132-0eb84b76d2b3%40chromium.org.

Re: [blink-dev] Intent to Experiment: Anonymous iframes

[Mike Taylor]

LGTM to experiment from M106 to M108 (I think that's the range you're 
requesting, please let me know if I'm reading it wrong).


On 7/27/22 6:34 AM, Arthur Sonzogni wrote:



Contact emails

arthursonzo...@chromium.org, cl...@chromium.org


Explainer

https://github.com/WICG/anonymous-iframe


Specification

https://wicg.github.io/anonymous-iframe/#specification


Design docs


https://docs.google.com/document/d/1poI75BaQ9aqcMGJn_K01-QHsQQbEOwRWvg3Af4VWTmY/edit


Summary

Anonymous iframes give developers a way to load documents in third 
party iframes using new and ephemeral contexts. Anonymous iframes are 
a generalization of COEP credentialless to support 3rd party iframes 
that may not deploy COEP. Like with COEP credentialless, we replace 
the opt-in of cross-origin subresources by avoiding to load non-public 
resources. This will remove the constraint that 3rd party iframes must 
support COEP in order to be embedded in a COEP page and will unblock 
developers looking to adopt cross-origin-isolation. This way, 
developers using COEP can now embed third party iframes that do not.




Blink component

Blink>SecurityFeature 




Search tags

coep , 
cross-origin-embedder-policy 
, 
iframe , anonymous 




TAG review

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


TAG review status

Issues addressed


Risks



Interoperability and Compatibility

The main risk is that anonymous iframes fail to become an 
interoperable part of the web platform if other browsers do not 
implement the API.




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


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


/Web developers/: Positive 
(https://github.com/WICG/proposals/issues/53) Zoom, Google Display 
Ads, StackBlitz are supportive. Several other developer also expressed 
their need to get anonymous iframe to embed 3rd party iframes inside 
crossOriginIsolated contexts.


/Other signals/:


Ergonomics

None.



Activation

We are going to publish a blog post: We don't expect developers having 
difficulties using is as-is. It only requires adding the "anonymous" 
attribute to .




Security

See the threat model doc: 
https://wicg.github.io/anonymous-iframe/#security 
http://go/anonymous-iframe-threat-model




WebView application risks

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


No risks identified. This is platform independent. WebView is not an 
exception.




Goals for experimentation

- Double check the feature makes sense given large developers like 
Google Ads and Zoom. - Confirm this resolves the difficulties 
deploying COEP and understand any limitations. - Get feedback about 
the shape of the API. - Understand if developers need additional APIs 
to use it. For instance: 
https://github.com/w3ctag/design-reviews/issues/742 or others.




Reason this experiment is being extended



Ongoing technical constraints

None



Debuggability

Anonymous iframes were designed to avoid breaking iframes. They do not 
introduce new kinds of failures. In the devtool issue explaining an 
iframe was blocked by COEP, Anonymous iframes will be suggested as a 
potential solution. The JS API: `window.isAnonymouslyFramed` already 
reflects whether a document is embedded inside an anonymous iframe or 
not. This is not reflected in devtool yet, but it could be in the 
future, if we think this is worth it.




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

Yes

This is a web platform feature. Consistent behavior among all the 
platforms is important.




Is this feature fully tested by web-platform-tests

?

Yes


DevTrial instructions

https://anonymous-iframe.glitch.me


Flag name

--enable-blink-features=AnonymousIframe


Requires code in //chrome?

False


Tracking bug

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


Launch bug

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


Estimated milestones

OriginTrial desktop last108
OriginTrial desktop first   106
DevTrial on desktop 105

OriginTrial Android last108
OriginTrial Android first   106
DevTrial on Android 105

OriginTrial webView last108
OriginTria

[blink-dev] Re: Intent to Experiment: COOP: restrict-properties

['Arthur Hemery' via blink-dev]

Please note that a TAG issue was just filed:
https://github.com/w3ctag/design-reviews/issues/760

On Tue, Jul 26, 2022 at 4:59 PM Arthur Hemery  wrote:

> Contact emailsahem...@chromium.org
>
> Explainer
> https://github.com/hemeryar/explainers/blob/main/coop_restrict_properties.md
>
> Specificationhttps://github.com/whatwg/html/issues/6364
>
> Summary
>
> Cross-Origin-Opener-Policy is used to sever the relationship between popup
> and openers, to increase security. "restrict-properties" is a proposed
> value that restricts the relationship instead of completely severing it. It
> would enable crossOriginIsolated when paired with COEP.
>
>
> Blink componentBlink>SecurityFeature>COOP
> 
>
> Search tagsCOOP ,
> restrict-properties
> 
>
>
> Risks
>
>
> Interoperability and Compatibility
>
> It could fail to become an interoperable part of the web platform if other
> browsers do not implement it. The OT is intended to gather user feedback to
> get support from Mozilla.
>
>
> *Gecko*: No signal
>
> *WebKit*: No signal
>
> *Web developers*: No signals
>
> *Other signals*: Have a few partners interested in trying this out like
> Zoom and Facebook, as well as at least one internal partner (altimin@ for
> perfetto dashboards).
>
> WebView application risks
>
> Does this intent deprecate or change behavior of existing APIs, such that
> it has potentially high risk for Android WebView-based applications?
>
>
>
> Goals for experimentation
>
> The goal for this experiment is to give partners the possibility to try
> the new value at scale and to discover potential deployment blockers that
> were not anticipated (e.g. external dependency, same-origin communications
> required, etc.)
>
> Debuggability
>
> COOP reporting will support restricted cross-origin properties reporting,
> similar to what exists for other COOP values.
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?Yes
>
> COOP is parsed on all platforms, but the process model implied might vary.
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?Yes under
> wpt/html/cross-origin-opener-policy/tentative/restrict-properties.
>
> Flag name
> --enable-features='CoopRestrictProperties'
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1221127
>
> Launch bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1347385
>
> Estimated milestones
> OriginTrial desktop last 110
> OriginTrial desktop first 106
> OriginTrial Android last 110
> OriginTrial Android first 106
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5072630953017344
>
> Links to previous Intent discussionsIntent to prototype:
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAF07A2Uw-Oh0d7ktTPnV%3D8TTrr%2BNcTgfiLxzFd2P2QLD18qNsw%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/CAF07A2Uj8%3DeUzcs8-o4RxAJnJN8%2BGCpPZNY3ky5Y88-UvhFtiA%40mail.gmail.com.

Re: [blink-dev] Intent to Remove: window.webkitStorageInfo

[Daniel Bratell]

The low usage counters indicate that this is something that could 
relatively safely be removed, though I wonder if you have taken a look 
at any of the sites listed with the usage counter?


/Daniel

On 2022-07-26 23:26, Ayu Ishii wrote:

*Contact emails
*a...@chromium.org 

*Specification
*https://storage.spec.whatwg.org/

*Summary
*We propose to remove the following prefixed quota API, 
window.webkitStorageInfo in M106.


 *

window.webkitStorageInfo.queryUsageAndQuota()

 *

window.webkitStorageInfo.requestQuota()

The deprecation thread predates the Intent process, but has been 
marked as deprecated since 2013 
(https://bugs.webkit.org/show_bug.cgi?id=88396).


*Blink component
*Blink>Storage>Quota 



*Motivation
*Chrome proposed and implemented  
the prefixed quota API in 2011, which was immediately succeeded by the 
Quota API  which 
has since been deprecated as well. The legacy storage quota API was 
never implemented by any other browser, and has been showing a 
deprecation warning since 2013. Rather than investing more support on 
these legacy APIs, we propose to remove it entirely.


*Search tags
*legacy , quota 
, storage 



*TAG review
*N/A

*Risks
*We previously made an attempt to remove window.webkitStorageInfo in 
2017 (I2D 
). 
Since then, the modern quota API navigator.storage.estimate() shows 
increased adoption while window.webkitStorageInfo usage has decreased.


The top level use counter (PrefixedStorageInfo 
) 
still reports 0.6% of page loads, but we think this can’t be trusted 
since enumeration of global properties is common and will tick the 
counter. The actual  usage of the methods on webkitStorageInfo: is 
significantly lower:


 *

window.webkitStorageInfo.queryUsageAndQuota()

- 0.000632%

 *

window.webkitStorageInfo.requestQuota()

- 0.000172%

As a replacement for window.webkitStorageInfo.queryUsageAndQuota(), we 
recommend using the now standardized navigator.storage.estimate() 
. 
This has been added to Chrome since M61, and adopted by Firefox since 
M57.


window.webkitStorageinfo.requestQuota() will not have a recommended 
replacement. Although navigator.webkitXXXStorage.requestQuota() 
 
will still exist, this has never been standardized or adopted by other 
browsers. Its current usage is at 0.01% 
 
and will need to do some work before full removal, but we are 
motivated to remove them. Explicitly requesting quota is only used in 
conjunction with the deprecated and Chrome-only 
webkitRequestFileSystem() API, which we also hope to remove when feasible.


This removal is part of a larger effort to remove deprecated storage 
APIs from the codebase 
. 
For feedback on other API deprecations, please use this doc for 
commenting.



Interoperability and Compatibility

Gecko: Never implemented

WebKit: Never  implemented

Web developers: No signals


*Debuggability
*Shows a deprecation warning in the console when used (since 2013).

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

*no

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

*Estimated milestones
*Removal proposed for M106

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

--
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/1534fcf9-585e-437c-a014-9eb5ba82ed2en%40chromium.org 
.


--
You received this message because you are subscribed to the Google Groups 
"blink-dev" group

Re: [blink-dev] Re: Intent to Ship: Intl.NumberFormat v3 API

[Daniel Bratell]

LGTM1

/Daniel

On 2022-07-23 02:41, Frank Tang wrote:

It was flip to stage on m105 and try to flip to ship for m106
R2T for m105 could be found on 1Q2FHx9hBAAJ 



On Fri, Jul 22, 2022 at 5:36 PM Frank Tang  wrote:



Contact emails

ft...@google.com


Specification


https://github.com/tc39/proposal-intl-numberformat-v3#ecma-402-proposal-intlnumberformat-v3


Design docs



https://docs.google.com/document/d/19jAogPBb6W4Samt8NWGZKu47iv0_KoQhBvLgQH3xvr8/edit#heading=h.86ckkob9p59r

https://docs.google.com/document/d/14zxGub6Os6nARzH6XstOZX05w2537sZo_ZSSlGjGpBM/edit#heading=h.86ckkob9p59r


Summary

Intl.NumberFormat v3 API is a new TC39 ECMA402 stage 3 proposal
extend the pre-existing Intl.NumberFormat, with the following new
features: 1. Add 3 new functions to format range of number:
formatRange / formatRangeToParts / selectRange 2. Grouping Enum 3.
New Rounding/Precision Options 4. Rounding Priority 5. Interpret
Strings as Decimals 6. Rounding Modes 7. Sign Display Negative
https://github.com/tc39/proposal-intl-numberformat-v3



Blink component

Blink>JavaScript>Internationalization




TAG review



TAG review status

Not applicable


Risks



Interoperability and Compatibility

This API change the pre-existing Intl.NumberFormat API by adding
new options to control the formatted output, adding several new
method to Intl.NumberFormat and take string form of data for
higher precision. It is advanced to TC39 Stage 3 in the July 2020.
Engineer from Firefox team is supporting this proposal .



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

/WebKit/: Shipped/Shipping
(https://bugs.webkit.org/show_bug.cgi?id=215438)
https://developer.apple.com/safari/technology-preview/release-notes/ 
(Release
139)

/Web developers/: No signals

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

/Other signals/: https://github.com/tc39/test262/issues/3132


Ergonomics

The implementation depend on ICU class
LocalizedNumberRangeFormatter class. To avoid producing negative
impact to pre-exiting usage of Intl.NumberFormat, we optimize it
by using lazy eval in
https://chromium-review.googlesource.com/c/v8/v8/+/3555261.



Activation

Web developers could use the API immediately upon our shipment,
based on the usage of previous well supported Intl.NumberFormat
object.



Security

no risk aware off



WebView application risks

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



Debuggability

nothing special



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

Yes


Is this feature fully tested by web-platform-tests

?

No


Flag name

--harmony-intl-number-format-v3


Requires code in //chrome?

False


Tracking bug

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


Launch bug

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


Estimated milestones

DevTrial on desktop 106

DevTrial on Android 106


sorry both should be DevTrail for 105 (already flipped a month ago).

I intend to *ship* for *m106* but maybe I change the values in the 
incorrect place in the UI causing this draft email incorrect.




Anticipated spec changes

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



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5707621009981440


Links to previous Intent discussions

Intent to prototype:

https://mail.google.com/mail/u/0/#search/stage+intl+numberformat/KtbxLxgRQQFXbKqWhsdWzfnRLCZNTWHnvV


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 fro

Re: [blink-dev] Inactive OWNERS cleanup

[danakj]

This list includes per-file owners, did the script look for 100 CLs in *those
files* named by the rule when deciding to remove the person?

On Tue, Jul 26, 2022 at 9:16 PM Kentaro Hara  wrote:

> Hi
>
> As of 2022 July, Chromium has 4531 OWNERS files containing 6850 names.
> These include inactive owners, which are one of the sources of slow code
> review latency. One year ago, we cleaned up inactive owners
> 
> and removed ~500 inactive owners. I propose running the clean-up process
> again to keep the OWNERS files updated.
>
> Specifically, a person is identified as an "inactive" owner iff:
>
>-
>
>The person didn't commit or review any CLs in the directory they own
>while there were 100+ CLs that touched the directory in the past 6 months
>(as of July 6, 2022).
>
> Last year, I gave the inactive owners an option to flip the decision
> manually to stay as an owner, but for this cycle, I'm planning to remove
> the inactive owners unconditionally. The rationale is 1) if the person made
> no contribution on a very active directory for 6 months, it will be
> reasonable to say that the person is inactive, and 2) if there is any
> special reason for it and the person needs to stay as an owner, the person
> can show evidence that they are meeting the owners expectations
> 
> and be readded through the standard OWNERS nomination process.
>
> Specifically, people listed in this spreadsheet
> 
> are identified as inactive owners and will be removed.
>
> I understand this is a tricky proposal. Having your name on OWNERS is an
> award for your previous amazing contributions, and I understand your
> feeling about your name being removed. However, I think it's important to
> keep the OWNERS files updated so that Chromium developers can find active
> owners and improve the code review latency.
>
> If you have any questions / concerns, please let me know. Thanks!
> --
> Kentaro Hara, Tokyo
>
> --
> 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/CABg10jyArLjDp0ixPu%2BCSZ9NVrn0M1GwNFiJqiPGRE1f0mrbfQ%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/CAHtyhaTNC4tgQbqbUq%2BQdFfcORr3aFobjgbeE%2BTaVf7eDgU2Bg%40mail.gmail.com.

Re: [blink-dev] Intent to Prototype: Borderless Mode for Installed Desktop Web Apps

['Sonja Laurila' via blink-dev]

Correct! Now the CL for supporting installability is merged but the actual
CL  for enabling the borderless is still under
review but should also be merged soon :)

On Mon, Jul 25, 2022 at 2:21 PM Thomas Steiner  wrote:

> Thanks, François, I'll just check it out later then.
>
> On Mon, Jul 25, 2022 at 1:41 PM François Beaufort 
> wrote:
>
>> I believe the CL
>>  that
>> will fix support for instability is still WIP and not merged in Chrome yet.
>> See
>> https://chromium-review.googlesource.com/c/chromium/src/+/3780810/2/components/webapps/browser/installable/installable_manager.cc
>>
>> On Mon, Jul 25, 2022 at 1:23 PM 'Thomas Steiner' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> I tried this with on 106.0.5199.0 (Official Build) canary (arm64)  with
>>> the chrome://flags/#enable-desktop-pwas-borderless set, but it failed the
>>> installability checks:
>>>
>>> [image: Screenshot 2022-07-25 at 13.21.24.png]
>>>
>>> Is this not enabled on macOS yet?
>>>
>>> Thanks,
>>> Tom
>>>
>>>
>>> --
>>> 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/CALgRrLnv-LTt3h8-F3HcDZQs0rWtEVoLrXPGUBeYF0M2GuaCJg%40mail.gmail.com
>>> 
>>> .
>>>
>>
>
> --
> Thomas Steiner, PhD—Developer Relations Engineer (https://blog.tomayac.com
> , https://twitter.com/tomayac)
>
> Google Germany GmbH, ABC-Str. 19, 20354 Hamburg, Germany
> Geschäftsführer: Paul Manicle, Liana Sebastian
> Registergericht und -nummer: Hamburg, HRB 86891
>
> - BEGIN PGP SIGNATURE -
> Version: GnuPG v2.3.4 (GNU/Linux)
>
>
> iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck0fjumBl3DCharaCTersAttH3b0ttom.
> hTtPs://xKcd.cOm/1181/
> - END PGP SIGNATURE -
>


-- 

Sonja Laurila

Software Engineer

laur...@google.com
+49 1728 644080

Google Germany GmbH

Erika-Mann-Straße 33

80636 München

Geschäftsführer: Paul Manicle, Liana Sebastian

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Diese E-Mail ist vertraulich. Falls Sie diese fälschlicherweise erhalten
haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter,
löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen,
dass die E-Mail an die falsche Person gesendet wurde.



This e-mail is confidential. If you received this communication by mistake,
please don't forward it to anyone else, please erase all copies and
attachments, and please let me know that it has gone to the wrong person.

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe 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/CAKk9GFMc5NFp_BrdfHzoJM_zkZ35ZA0MbeA3s-mkiY2eZTUZog%40mail.gmail.com.

[blink-dev] Intent to Experiment: Anonymous iframes

[Arthur Sonzogni]

Contact emailsarthursonzo...@chromium.org, cl...@chromium.org

Explainerhttps://github.com/WICG/anonymous-iframe

Specificationhttps://wicg.github.io/anonymous-iframe/#specification

Design docs
https://docs.google.com/document/d/1poI75BaQ9aqcMGJn_K01-QHsQQbEOwRWvg3Af4VWTmY/edit

Summary

Anonymous iframes give developers a way to load documents in third party
iframes using new and ephemeral contexts. Anonymous iframes are a
generalization of COEP credentialless to support 3rd party iframes that may
not deploy COEP. Like with COEP credentialless, we replace the opt-in of
cross-origin subresources by avoiding to load non-public resources. This
will remove the constraint that 3rd party iframes must support COEP in
order to be embedded in a COEP page and will unblock developers looking to
adopt cross-origin-isolation. This way, developers using COEP can now embed
third party iframes that do not.


Blink componentBlink>SecurityFeature


Search tagscoep ,
cross-origin-embedder-policy
,
iframe , anonymous


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

TAG review statusIssues addressed

Risks


Interoperability and Compatibility

The main risk is that anonymous iframes fail to become an interoperable
part of the web platform if other browsers do not implement the API.


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

*WebKit*: No signal (
https://lists.webkit.org/pipermail/webkit-dev/2022-April/032205.html)

*Web developers*: Positive (https://github.com/WICG/proposals/issues/53)
Zoom, Google Display Ads, StackBlitz are supportive. Several other
developer also expressed their need to get anonymous iframe to embed 3rd
party iframes inside crossOriginIsolated contexts.

*Other signals*:

Ergonomics

None.


Activation

We are going to publish a blog post: We don't expect developers having
difficulties using is as-is. It only requires adding the "anonymous"
attribute to .


Security

See the threat model doc: https://wicg.github.io/anonymous-iframe/#security
http://go/anonymous-iframe-threat-model


WebView application risks

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

No risks identified. This is platform independent. WebView is not an
exception.


Goals for experimentation

- Double check the feature makes sense given large developers like Google
Ads and Zoom. - Confirm this resolves the difficulties deploying COEP and
understand any limitations. - Get feedback about the shape of the API. -
Understand if developers need additional APIs to use it. For instance:
https://github.com/w3ctag/design-reviews/issues/742 or others.


Reason this experiment is being extended



Ongoing technical constraints

None


Debuggability

Anonymous iframes were designed to avoid breaking iframes. They do not
introduce new kinds of failures. In the devtool issue explaining an iframe
was blocked by COEP, Anonymous iframes will be suggested as a potential
solution. The JS API: `window.isAnonymouslyFramed` already reflects whether
a document is embedded inside an anonymous iframe or not. This is not
reflected in devtool yet, but it could be in the future, if we think this
is worth it.


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

This is a web platform feature. Consistent behavior among all the platforms
is important.


Is this feature fully tested by web-platform-tests

?Yes

DevTrial instructionshttps://anonymous-iframe.glitch.me

Flag name--enable-blink-features=AnonymousIframe

Requires code in //chrome?False

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

Launch bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1342928

Estimated milestones
OriginTrial desktop last 108
OriginTrial desktop first 106
DevTrial on desktop 105
OriginTrial Android last 108
OriginTrial Android first 106
DevTrial on Android 105
OriginTrial webView last 108
OriginTrial webView first 106

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

Links to previous Intent discussionsIntent to prototype:
https://groups.google.com/a/chromium.org/g/blink-dev/c/CjrLTguZuO4


This intent message was generated by Chrome Platform Status
.

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