[blink-dev] Inactive OWNERS cleanup

[Kentaro Hara]

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.

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

[Ayu Ishii]

*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.

Re: [blink-dev] Re: Intent to Experiment: User Agent Reduction Origin Trial

[Noah Lemen]

Are there any plans to extend this Origin Trial? We (Meta) are considering 
using it to test the impact of UA reduction, but just noticed that its "end 
date" is tomorrow, and was marked with availability ending after version 
103.
On Thursday, October 14, 2021 at 5:29:45 PM UTC-4 abe...@chromium.org wrote:

> Just an FYI, the blog post has been updated to give instructions on how to 
> participate in the User-Agent Reduction Origin Trial as a third-party 
> embed: 
> https://developer.chrome.com/blog/user-agent-reduction-origin-trial/#how-to-participate-in-the-origin-trial-as-a-third-party-embed
>
> On Tue, Sep 14, 2021 at 9:39 AM Ali Beyad  wrote:
>
>> A blog post just went out for this OT: 
>> https://developer.chrome.com/blog/user-agent-reduction-origin-trial/
>>
>> On Thu, Aug 12, 2021 at 9:47 AM Ali Beyad  wrote:
>>
>>> An update on this: it will be too rushed to get the User-Agent Reduction 
>>> OT into the M94 branch cutoff (this Thursday), so we moved this OT for the 
>>> M95 release.
>>>
>>> On Wed, Aug 11, 2021 at 4:02 PM Ali Beyad  wrote:
>>>
 An update on this: it will be too rushed to get the User-Agent 
 Reduction OT into the M94 branch cutoff (this Thursday), so we moved this 
 OT for the M95 release.

 On Thu, Jul 15, 2021 at 6:39 PM Ali Beyad  wrote:

> Thanks for the feedback and the LGTMs, everyone!
>
> On Thu, Jul 15, 2021 at 6:30 PM Rick Byers  
> wrote:
>
>> I agree this OT is quite different from a regular OT, there's not 
>> really a "burn-in risk" to be worried about since this isn't really 
>> about 
>> any new functionality sites want access to. So LGTM3 for a longer trial.
>>
>> If necessary I'd also be supportive of expanding usage limits 
>> arbitrarily. The more usage we can get of this trial, the lower the 
>> compat 
>> risk will be of making the breaking change later. So in this case it 
>> makes 
>> no sense to worry about excessive usage of the OT. 
>>
>> I'm glad to hear the inherited JS semantics will match that of the 
>> header. Like for the header, I'd otherwise be worried about masking 
>> potential compat issues if that JS APIs were unaffected.
>>
>> Rick
>>
>> On Thu, Jul 15, 2021 at 11:18 AM Ali Beyad  
>> wrote:
>>
>>>
>>>
>>> On Thu, Jul 15, 2021 at 4:02 AM Mike West  
>>> wrote:
>>>
 Thanks for the clarifications, Ali. This looks pretty reasonable to 
 me. LGTM1 % the below:

 I would recommend that you adjust the design doc to remove the 
 reference to "a client hint token that will reduce the User-Agent 
 header", 
 as it doesn't sound like that's what you're aiming to experiment with. 
 My 
 understanding of your response is that you'll only adjust the UA in 
 the 
 presence of the Origin Trial token.

>>>
>>> I updated 
>>> 
>>>  
>>> the design doc to make the point clear that the UA will only be reduced 
>>> in 
>>> the presence of the OT token, and I clarified the role of the new 
>>> client 
>>> hint in all this.  Thanks for the feedback!
>>>  
>>>

 With regard to the OT schedule, ~6 months from M94 would take us 
 more or less through M100. In 
 https://groups.google.com/a/chromium.org/g/blink-api-owners-discuss/c/dhfejxAtj84/m/vr889GowAgAJ,
  
 we agreed (but I don't think documented... I'll fix that) that we'd be 
 taking ~4 milestones as a typical OT length as we shift into a 4-week 
 cadence.

 That said, it sounds like you want to use this experiment as a 
 lead-in to a behavior change and deprecation trial, and holding you to 
 4 
 milestones would put you squarely in the holiday season of M98. I'm 
 comfortable with y'all extending this out a little longer than usual, 
 but 
 I'd appreciate two other API owners weighing in to confirm that plan.

 -mike


 On Mon, Jul 12, 2021 at 4:55 PM Ali Beyad  
 wrote:

> Hey Mike,
>
> Thanks for your questions.  Answers inline.
>
> On Mon, Jul 12, 2021 at 9:15 AM Mike West  
> wrote:
>
>> Hey Ali,
>>
>> There are a few details here that I'm not sure I understand.
>>
>> 1.  The linked design doc describes opting into UA reduction 
>> through both an origin trial, and a client hint-based opt-in. Does 
>> this 
>> intent include both mechanisms? Or is it only about the origin trial?
>>
>
> The I2E is for an origin trial that would control two behaviors:
>
>1. The Javascript ge

[blink-dev] Upcoming chromestatus.com edit permissions change

['Jason Robbins' via blink-dev]

Hello blink-dev,

TL;DR  We are tightening permissions for editing feature entries to only
people who are listed as owners or editors of the feature entry.  Email us
if you need to edit other people's features frequently.

For the past several years, editing permissions on chromestatus.com have
been very lax, with thousands of accounts being able to edit any feature.
This lenient edit permission policy puts the site at risk of accidental
edits or abuse from a compromised account.

In the coming weeks, we'll be rolling out new permission checking logic
that should reduce risk while supporting normal usage.  Here's how it will
work:

* The set of users who can create a new feature is not changing.

* Once a feature is created, it can only be edited by accounts listed in
the "Feature owners" field, or the new "Feature editors" field.  Those
users can grant access by adding another email address to the "Feature
editors" field.  The list of editors is not displayed publicly.

* Users who need to edit a wide range of features can email
webstatus-requ...@google.com to request the "Site editor" role. E.g.,
jmedley and fantasai frequently update feature entries as part of their
jobs.


The "Feature editors" field is already available on the site today.  So, if
you are collaborating on a feature entry with folks who are not listed as
feature owners, please add them as either feature owners or feature
editors.   The new field is located in the feature metadata form:



Thanks,
jason!

-- 
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/CADPkFo028iU8d8RnoNrazJ_kP0SFtFWqytwZY6VpH5g%2B%2B8rhRg%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

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

['Arthur Hemery' via blink-dev]

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/CAF07A2UMOnEEY%2BG4bjE6kiPtw9insquxztWYDb%3DE9bnb-_dZow%40mail.gmail.com.