Re: [blink-dev] Re: Intent to Ship: HTTPS Upgrades

[Mike West]

een waiting a bit to see if the experiment would blow
>>>>>>>>>> anything up, but if it doesn't, and continue to not do so, then
>>>>>>>>>>
>>>>>>>>>> LGTM1 as soon as the PR has landed.
>>>>>>>>>>
>>>>>>>>>> /Daniel
>>>>>>>>>> On 2023-06-14 17:40, Yoav Weiss wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Thursday, June 8, 2023 at 5:53:49 PM UTC+2 Chris Thompson
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> On Wed, Jun 7, 2023 at 9:41 PM Yoav Weiss 
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Thanks for working on this!
>>>>>>>>>>
>>>>>>>>>> On Wed, Jun 7, 2023 at 11:44 PM Chris Thompson <
>>>>>>>>>> cth...@chromium.org> wrote:
>>>>>>>>>>
>>>>>>>>>> Thanks all. Some updates:
>>>>>>>>>>
>>>>>>>>>>- We have filed a TAG review request
>>>>>>>>>><https://github.com/w3ctag/design-reviews/issues/853>
>>>>>>>>>>- We are working on writing WPTs and we will update this
>>>>>>>>>>thread when those are ready -- thanks for the added details about 
>>>>>>>>>> how those
>>>>>>>>>>are run
>>>>>>>>>>- We have added a `Non-Authoritative-Reason: HttpsUpgrades`
>>>>>>>>>>header to the synthetic redirects (CL
>>>>>>>>>>
>>>>>>>>>> <https://chromium-review.googlesource.com/c/chromium/src/+/4584420>,
>>>>>>>>>>which we are planning to merge back to M-115)
>>>>>>>>>>- We are continuing to iterate on the spec PR
>>>>>>>>>>
>>>>>>>>>> For now we will continue to provide updates on this I2S -- closer
>>>>>>>>>> to M115 going to Stable we may send an I2E to request the ability to
>>>>>>>>>> proceed with a 1% Stable experiment if we have not yet been able to 
>>>>>>>>>> resolve
>>>>>>>>>> everything here.
>>>>>>>>>>
>>>>>>>>>> @Harald Alvestrand  : In general, this feature
>>>>>>>>>> should work fine with captive portals. A captive portal that 
>>>>>>>>>> intercepts
>>>>>>>>>> HTTPS connections will result in a certificate error, which will 
>>>>>>>>>> cause the
>>>>>>>>>> upgrade to fail and automatically fall back to HTTP. Alternatively, 
>>>>>>>>>> the
>>>>>>>>>> captive portal could reset the connection for HTTPS requests, which 
>>>>>>>>>> would
>>>>>>>>>> accomplish the same.
>>>>>>>>>>
>>>>>>>>>> We have had one report of a middlebox that returned an HTTP 404
>>>>>>>>>> error over HTTPS instead of rejecting the connection, causing 
>>>>>>>>>> breakage (the
>>>>>>>>>> upgraded HTTPS page would load but have useless content). We do not 
>>>>>>>>>> believe
>>>>>>>>>> the browser should fallback on *application* level errors, as
>>>>>>>>>> they do not provide a useful signal that the site does not support 
>>>>>>>>>> HTTPS --
>>>>>>>>>> in the vast majority of cases the same application error will occur 
>>>>>>>>>> over
>>>>>>>>>> HTTP as well. (This specific case was an enterprise situation, with 
>>>>>>>>>> an
>>>>>>>>>> enterprise installed root certificate making the middlebox's HTTPS 
>>>>>>>>>> work,
>>>>>>>>>> and we have enterprise policies to allow organizations to disable 
>>>>>&

Re: [blink-dev] Intent to Deprecate and Remove: Dangling markup in target name

[Mike West]

LGTM3.

-mike


On Fri, Sep 8, 2023 at 4:52 PM Chris Harrelson 
wrote:

> LGTM2
>
> On Fri, Sep 8, 2023 at 7:04 AM Mike Taylor  wrote:
>
>> LGTM1 to ship. Risk seems very low (and worth it, given security
>> improvements), but thanks for adding a runtime enabled feature.
>> On 9/7/23 12:44 AM, 'Jun Kokatsu' via blink-dev wrote:
>>
>> Contact emails
>>
>> jkoka...@google.com
>>
>> Specification
>>
>> https://github.com/whatwg/html/pull/9309/files
>>
>> Summary
>>
>> This change replaces the navigable target name (which is usually set by
>> target attribute) to `_blank`, if it contains a dangling markup (i.e. `\n`
>> and `<`). Which fixes a bypass in the dangling markup injection mitigation.
>>
>>
>> Blink component
>>
>> Blink>SecurityFeature
>> 
>>
>> Motivation
>>
>> Blink has shipped a mitigation for dangling markup injection
>>  attack while back.
>> However, it was discovered that the mitigation can be bypassed
>> 
>> through target name. Navigations with such target names are low
>> 
>> (~0.07%). Therefore, this change removes the limitation discovered in
>> the previous mitigation.
>>
>>
>> Initial public proposal
>>
>> None
>>
>> TAG review
>>
>> None
>>
>> TAG review status
>>
>> Not applicable
>>
>> Risks
>>
>> Interoperability and Compatibility
>>
>> None
>>
>>
>> Gecko: Positive
>> 
>>
>> WebKit: Shipped/Shipping 
>>
>> Web developers: No signals
>>
>> Other signals:
>>
>> WebView application risks
>>
>> Does this intent deprecate or change behavior of existing APIs, such that
>> it has potentially high risk for Android WebView-based applications?
>>
>> None
>>
>>
>> Debuggability
>>
>> None
>>
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?
>>
>> Yes 
>>
>> Flag name on chrome://flags
>>
>> None
>>
>> Finch feature name
>>
>> None
>>
>> Non-finch justification
>>
>> None
>>
>> Requires code in //chrome?
>>
>> False
>>
>> Tracking bug
>>
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1421440
>>
>> Estimated milestones
>>
>> 119
>>
>>
>> Link to entry on the Chrome Platform Status
>>
>> https://chromestatus.com/feature/5073969773805568
>>
>> --
>> 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/CAOWKMF4CR50EbS%3DMrYxMa5PcyiYPFg%2B4X2e6F5S0kzcxJLygew%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/e68e959c-0a28-45b0-90f1-d35aa2e0c17b%40chromium.org
>> 
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8iH9LMurSC%2BNnmSeJoBVHQ-tOnHYszZ5BnYjiNw0GW-g%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/CAKXHy%3DdKgcioD_w9Aax4P7DzhRZj-SKWK86_y3%3D0wg5ycSTTVA%40mail.gmail.com.

Re: [blink-dev] Intent to Experiment: Capture all screens

[Mike West]

6 milestones is consistent with our OT process' recommendations. Still
LGTM. Good luck with the experimentation.

-mike


On Wed, Aug 16, 2023 at 4:52 PM 'Simon Hangl' via blink-dev <
blink-dev@chromium.org> wrote:

> Hi everybody,
>
> I'd like to update the OT milestones mentioned above to an OT of 6 months
> duration [1]:
> OriginTrial desktop last: 124
> OriginTrial desktop first: 118
>
> [1] https://www.chromium.org/blink/launching-features/#origin-trials
>
> On Monday, July 10, 2023 at 5:29:35 PM UTC+2 Simon Hangl wrote:
>
>> | Lastly, this API is currently only shipping for CrOS, where the user is
>> already prompted to consent to this capture before they log into the
>> system[*].
>>
>> One correction - due to technical limitations, the user is NOT warned on
>> the login screen that if they proceed they might be recorded. This
>> notification is only shown (immediately) after login. As mentioned, it is a
>> notification that shows up even before recording starts, letting the user
>> know that they *might* be recorded at any moment.
>>
>> On Thursday, June 15, 2023 at 5:33:21 PM UTC+2 Artur Janc wrote:
>>
>>> On Thu, Jun 15, 2023 at 3:52 PM Elad Alon  wrote:
>>>
 Hi Arthur!

 Using the pre-existing getDisplayMedia(), an application can already
 gain access to the user's screen and capture content in pop-ups, detect
 browsing history, etc. - provided the user chooses to capture their (often
 only) screen. All of the concerns above apply for gDM. Further, any website
 can call gDM.

>>>
>>> The "provided the user chooses to capture their screen" part is what
>>> does the heavy lifting here. Each time gDM is called the user has to
>>> explicitly consent to sharing their screen and decide what to share; as
>>> such, even an XSS in an application which calls gDM generally isn't enough
>>> to read the contents of the user's screen because the user has to interact
>>> with the UI that will enable screen sharing.
>>>
>>> This feature doesn't have an equivalent protection and permits the
>>> allowlisted origin to call the API at any time without obtaining consent
>>> from the user, making it possible to abuse the privileges of the
>>> allowlisted origin if an attacker finds an XSS bug in it.
>>>
>>>

 In contrast, getAllScreensMedia() can only be called by websites
 expressly allowlisted by the device's owner. This configuration would
 typically be carried out by an admin who is more tech-savvy than the
 average user, and it would usually be the admin's job to apply some good
 judgement with respect to security risks their organization might face.

 It is expected that a reasonable company would only allowlist:
 1. Its own applications.
 2. Applications from providers who were contracted specifically for
 this purpose, and who are trusted by the contracting company to such an
 extent, that long-term full-screen recording is permitted.

>>>
>>> It's not at all clear that domain admins who want to monitor their
>>> users' activity are familiar with the web security posture of all the
>>> origins they want to allowlist. Even if the scope of the allowlist is just
>>> "the company's own applications", there is a substantial risk that an XSS
>>> bug in any of the applications (which could previously only access the
>>> user's data in that single application) will now be granted the privileges
>>> to access the user's data on all other websites.
>>>
>>> Lastly, this API is currently only shipping for CrOS, where the user is
 already prompted to consent to this capture before they log into the
 system[*]. Shipping for non-CrOS platforms will naturally be harder, and
 that work is not currently on anyone's OKRs.

>>>
>>> In this case the entity calling the API is an attacker with a
>>> vulnerability in any of the origins allowlisted in the Enterprise Policy. I
>>> don't think the fact that a user has clicked through a dialog when logging
>>> into the device serves as any protection for the user in this case because
>>> it's the attacker that is abusing the persisted privileges of the
>>> allowlisted origins to read the user's data, rather than the application
>>> that the domain admin has added to their allowlist.
>>>
>>> Wdyt?

 ---
 [*] As Matthew and Simon tell me. I have not checked.

 On Thursday, June 15, 2023 at 2:36:41 PM UTC+2 Artur Janc wrote:

> Hey folks,
>
> I've taken a look at the explainer as part of our security/privacy
> triage process (note: it looks like the link above is broken, it should be
> https://github.com/screen-share/capture-all-screens) and wanted to
> chime in with some security feedback.
>
> Concretely, this API gives any origin that has the ability to call it
> (anything allowlisted in the Enterprise Policy) access to ~all of the
> user's browsing data -- not just what's displayed on the screen. This is
> because the 

Re: [blink-dev] Re: Request for Deprecation Trial: Deprecate TLS SHA-1 server signatures

[Mike West]

LGTM to experiment from M115 to M116.

Good luck!

-mike

On Tue 13. Jun 2023 at 20:31 David Adrian  wrote:

> We plan to start in M115. Four milestones seems a bit long---this breakage
> likely either be immediately evident or a no-op. I was thinking M115 and
> M116, but we'll defer to your judgement.
>
> On Tue, Jun 13, 2023 at 2:50 AM Mike West  wrote:
>
>> Per the conversation on the previous thread, carefully rolling this out
>> to measure breakage seems like the right path forward. Do you have a
>> timeline along which you'd like to run this experiment? M115-M118?
>>
>> -mike
>>
>>
>> On Thu, Jun 8, 2023 at 9:54 PM 'David Adrian' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> Per request on the previous thread
>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/ZdpqIOKTHeM>,
>>> converting the previous Ready for Trial to an Intent to Experiment /
>>> Request for Deprecation Trial.
>>>
>>> Due to the nature of the TLS stack, this experiment will be managed by
>>> Finch, rather than site opt-in.
>>>
>>> On Thu, Jun 8, 2023 at 1:52 PM David Adrian  wrote:
>>>
>>>> Contact emailsdadr...@google.com
>>>> david...@chromium.org
>>>>
>>>> ExplainerNone
>>>>
>>>> Specificationhttps://www.rfc-editor.org/rfc/rfc9155.html
>>>>
>>>> Summary
>>>>
>>>> Chrome is removing support for signature algorithms using SHA-1 for
>>>> server signatures during the TLS handshake. This does not affect SHA-1
>>>> support in server certificates, which was already removed, or in client
>>>> certificates, which continues to be supported.
>>>>
>>>>
>>>> Blink componentInternals>Network>SSL
>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3ENetwork%3ESSL>
>>>>
>>>> Search tagstls <https://chromestatus.com/features#tags:tls>, ssl
>>>> <https://chromestatus.com/features#tags:ssl>, sha1
>>>> <https://chromestatus.com/features#tags:sha1>
>>>>
>>>> TAG reviewNone
>>>>
>>>> TAG review statusNot applicable
>>>>
>>>> Risks
>>>>
>>>>
>>>> Interoperability and Compatibility
>>>>
>>>> At most 0.02% of page loads use the SHA1 fallback. However, we cannot
>>>> disambiguate between a flaky first connection, and actually requiring SHA1.
>>>> We expect the actual amount is lower.
>>>>
>>>>
>>>> *Gecko*: No signal (
>>>> https://github.com/mozilla/standards-positions/issues/812)
>>>>
>>>> *WebKit*: No signal (
>>>> https://github.com/WebKit/standards-positions/issues/196)
>>>>
>>>> *Web developers*: No signals
>>>>
>>>> *Other signals*:
>>>>
>>>> WebView application risks
>>>>
>>>> Does this intent deprecate or change behavior of existing APIs, such
>>>> that it has potentially high risk for Android WebView-based applications?
>>>>
>>>> None
>>>>
>>>>
>>>> Goals for experimentation
>>>>
>>>> Since this takes place before a document is loaded, sites cannot
>>>> opt-in. We plan on doing a 1% stable experiment and monitoring any increase
>>>> in page load failures and SSL failures.
>>>>
>>>> This experiment is managed via Finch, not as an Origin / Deprecation
>>>> Trial.
>>>>
>>>> Experiment Risks
>>>> Sites that are incapable of SHA2 signatures would fail to load.
>>>> However, we believe the actual set of sites that don't support SHA2 is very
>>>> small. Due to how negotiation works in TLS, we can't tell the difference
>>>> between "prefers SHA1 to SHA2, but has a flaky network" and "only supports
>>>> SHA1". In the worst case, this is 0.02% of TLS connections. In the best
>>>> case, this is 0%.
>>>>
>>>> Ongoing technical constraints
>>>>
>>>> None
>>>>
>>>>
>>>> Debuggability
>>>>
>>>> n/a, this happens pre-devtools
>>>>
>>>>
>>>> Will this feature be supported on all six Blink platforms (Windows,
>>>> Mac, Linux, Chrome OS, Android, and Android WebView)?Yes
>>>>
>>>> Is this f

Re: [blink-dev] Re: Request for Deprecation Trial: Deprecate TLS SHA-1 server signatures

[Mike West]

Per the conversation on the previous thread, carefully rolling this out to
measure breakage seems like the right path forward. Do you have a timeline
along which you'd like to run this experiment? M115-M118?

-mike


On Thu, Jun 8, 2023 at 9:54 PM 'David Adrian' via blink-dev <
blink-dev@chromium.org> wrote:

> Per request on the previous thread
> ,
> converting the previous Ready for Trial to an Intent to Experiment /
> Request for Deprecation Trial.
>
> Due to the nature of the TLS stack, this experiment will be managed by
> Finch, rather than site opt-in.
>
> On Thu, Jun 8, 2023 at 1:52 PM David Adrian  wrote:
>
>> Contact emailsdadr...@google.com
>> david...@chromium.org
>>
>> ExplainerNone
>>
>> Specificationhttps://www.rfc-editor.org/rfc/rfc9155.html
>>
>> Summary
>>
>> Chrome is removing support for signature algorithms using SHA-1 for
>> server signatures during the TLS handshake. This does not affect SHA-1
>> support in server certificates, which was already removed, or in client
>> certificates, which continues to be supported.
>>
>>
>> Blink componentInternals>Network>SSL
>> 
>>
>> Search tagstls , ssl
>> , sha1
>> 
>>
>> TAG reviewNone
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> At most 0.02% of page loads use the SHA1 fallback. However, we cannot
>> disambiguate between a flaky first connection, and actually requiring SHA1.
>> We expect the actual amount is lower.
>>
>>
>> *Gecko*: No signal (
>> https://github.com/mozilla/standards-positions/issues/812)
>>
>> *WebKit*: No signal (
>> https://github.com/WebKit/standards-positions/issues/196)
>>
>> *Web developers*: No signals
>>
>> *Other signals*:
>>
>> WebView application risks
>>
>> Does this intent deprecate or change behavior of existing APIs, such that
>> it has potentially high risk for Android WebView-based applications?
>>
>> None
>>
>>
>> Goals for experimentation
>>
>> Since this takes place before a document is loaded, sites cannot opt-in.
>> We plan on doing a 1% stable experiment and monitoring any increase in page
>> load failures and SSL failures.
>>
>> This experiment is managed via Finch, not as an Origin / Deprecation
>> Trial.
>>
>> Experiment Risks
>> Sites that are incapable of SHA2 signatures would fail to load. However,
>> we believe the actual set of sites that don't support SHA2 is very small.
>> Due to how negotiation works in TLS, we can't tell the difference between
>> "prefers SHA1 to SHA2, but has a flaky network" and "only supports SHA1".
>> In the worst case, this is 0.02% of TLS connections. In the best case, this
>> is 0%.
>>
>> Ongoing technical constraints
>>
>> None
>>
>>
>> Debuggability
>>
>> n/a, this happens pre-devtools
>>
>>
>> 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 nameuse-sha1-server-handshakes
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=658905
>>
>> Launch bughttps://launch.corp.google.com/launch/4233200
>>
>> Estimated milestones
>> Shipping on desktop 117
>> OriginTrial desktop last 116
>> OriginTrial desktop first 115
>> DevTrial on desktop 115
>> Shipping on Android 117
>> OriginTrial Android last 116
>> OriginTrial Android first 115
>> DevTrial on Android 115
>> OriginTrial webView last 116
>> OriginTrial webView first 115
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/4832850040324096
>>
>> Links to previous Intent discussions
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/ZdpqIOKTHeM
>>
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/rfPtQpqNixk/m/WF3a12okCgAJ
>>
>> This intent message was generated by Chrome Platform Status
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGkh42LkdzFVgWn%3DEngqRQekuV%2B4rCQRWGcGjz4x5QJGpzgvig%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 

Re: [blink-dev] Intent to Ship: Partitioning Storage, Service Workers, and Communication APIs

[Mike West]

LGTM3 with all the caveats about careful rollout discussed above.

-mike


On Tue, May 30, 2023 at 5:39 PM Mike Taylor  wrote:

> OK - let's consider this I2S officially revived. Looking for a 3rd LGTM to
> begin shipping in M115.
>
> We have implemented 3rd party deprecation trial support for M115+ (see
> https://developer.chrome.com/blog/storage-partitioning-deprecation-trial/#participate-in-the-deprecation-trials),
> and extended the deprecation trial's expiration date accordingly to account
> for the delay. And we have the Enterprise policy ready to go.
>
> The rollout schedule will look something like the following, pending
> metrics and compatibility stability:
>
> July 25th: 1% of Stable population (approximately 1 week after M115 is
> released)
> Aug 8th: 10%
> Aug 22nd: 50%
> Sep 5: 100%
>
> As always, if we discover significant user-facing breakage we'll explore
> pausing or rolling back to address.
>
> thanks,
> Mike
> On 5/1/23 10:43 AM, Mike Taylor wrote:
>
> Thanks Rick and Yoav.
>
> We learned from two partners (one internal, one external) late last week
> that a 3P deprecation trial would be needed for them to preserve
> widely-used functionality while they work on a migration strategy.
>
> We're tracking the work in crbug.com/1441411 and hope to have that ready
> by M115. Once we land the fix, I'll circle back and look for a 3rd LGTM and
> have an updated rollout schedule. :)
> On 5/1/23 12:21 AM, Yoav Weiss wrote:
>
> LGTM2
>
> On Thu, Apr 27, 2023, 16:23 Rick Byers  wrote:
>
>>
>>
>> On Wed, Apr 26, 2023 at 2:02 PM Mike Taylor 
>> wrote:
>>
>>> On 4/26/23 9:36 AM, Mike Taylor wrote:
>>>
>>> > On 4/25/23 12:00 PM, Rick Byers wrote:
>>> >
>>> >> In terms of the standards / process piece, it looks as if the spec
>>> >> PRs have all stalled for several months. What do you think is
>>> >> necessary to get these unblocked and landed? As the last engine to
>>> >> implement this behavior, perhaps we shouldn't feel too compelled to
>>> >> block shipping on PRs landing?
>>>
>>> I was gently reminded offline that I didn't answer this part of your
>>> question - oops.
>>>
>>> Right now it seems to me that the costs of landing these spec PRs is
>>> higher than we're willing to block on, given the requested refactoring
>>> (and yes, it's unfortunate that 3 engines would be shipping essentially
>>> unspecced behavior, but that's where we're at). That said, I'm happy to
>>> devote my few IC hours to pushing these along as a personal project over
>>> the coming months.
>>>
>>
>> Thanks Mike. I trust your and wanderview@'s judgement here - I know how
>> hard y'all have been willing to work in the past to get the right thing
>> done in specs. Thanks for being willing to keep pushing in parallel. But
>> given two other implementations have already shipped this, it was clearly
>> already a spec bug that the spec didn't reflect reality. I agree that we
>> shouldn't block shipping a 3rd implementation on spec refactoring work.
>>
>> LGTM1 to ship from my perspective. Obviously this will need a very
>> thoughtful and careful roll-out. But I trust Mike and his team to engage
>> with impacted folks to make sure it goes smoothly, as they did with UA
>> reduction.
>>
> --
> 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/bc52292b-9142-adad-d126-b93231468ed0%40chromium.org
> 
> .
>

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

Re: [blink-dev] Re: Intent to Ship: HTTPS Upgrades

['Mike West' via blink-dev]

-mike


On Wed, May 31, 2023 at 4:17 PM Rick Byers  wrote:

> As a long-time user of HTTPS-first mode, I'm excited to see this ship ASAP!
>
> On Wed, May 31, 2023, 5:29 a.m. 'Mike West' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> On Fri, May 26, 2023 at 1:32 AM Chris Thompson 
>> wrote:
>>
>>> On Thu, May 25, 2023 at 3:36 AM Mike West  wrote:
>>>
>>>> I am enthusiastic about this (and not just because it should allow us
>>>> to deprecate/remove `Upgrade-Insecure-Requests`). A few comments inline:
>>>>
>>>> On Thu, May 25, 2023 at 1:13 AM Chris Thompson 
>>>> wrote:
>>>>
>>>>> Contact emailscth...@chromium.org, dadr...@google.com
>>>>>
>>>>> Explainer
>>>>> https://github.com/dadrian/https-upgrade/blob/main/explainer.md
>>>>>
>>>>> Specificationhttps://github.com/whatwg/fetch/pull/1655
>>>>>
>>>>
>>>> Thanks for putting this together! I'll leave some comments on the PR.
>>>> Given that we haven't gotten any feedback from Fetch editors, it might be
>>>> prudent to let them take a pass before locking in our current behavior.
>>>>
>>>
>>>  Yes, hopefully we can get some feedback, but I'm optimistic that we
>>> won't be locking in behavior if we ship this as it should hopefully be not
>>> site or user visible, so if we need to change the behavior to align
>>> cross-browser we can iterate.
>>>
>>
>> I left a few comments last week. I think the PR needs some work before we
>> can reasonably expect it to land in Fetch.
>>
>> Do we have tests in place for this behavior in Web Platform Tests?
>>>> https://wpt.fyi/results/mixed-content/tentative/autoupgrades?label=experimental=master
>>>> holds some tests for subresources, but I didn't see any around
>>>> navigation or fallback behavior (which seems like it might need some WPT
>>>> infrastructure change to produce a domain that's only served over HTTP).
>>>>
>>>
>>> We do not have Web Platform Tests but we can look into adding them.
>>> Currently this is implemented in //chrome which I think might make this
>>> more difficult (my understanding is that the WPT suite is run against
>>> content_shell rather than chrome).  We are currently relying on browser
>>> tests for our integration testing.
>>>
>>
>> WPT is a pretty important part of shipping features that affect the
>> platform. It would be ideal if we could share these tests with our friends
>> at other vendors (and update existing tests that might be expecting
>> different behavior). Shifting the implementation to //content to make that
>> possible would also have the advantage of helping other Chromium embedders
>> ship this feature, which would be excellent for consistency in the project.
>>
>
> Note that the official WPT results on wpt.fyi are using full Chrome
> builds. IIRC there are other features that require Chrome. I  personally
> only consider having WPTs passing on upstream infra to be blocking I2S. @Panos
> Astithas  can say more authoritatively.
>
> +1 to the benefits of having this in content, but I personally think
> that's outside the scope of API owners so not something that should block
> an I2S.
>

I agree with this. I didn't mean to imply that //content implementation was
necessary, but that _having_ web platform tests is important for interop.
Browser tests are less useful in that regard. :)


>
>
>> Summary
>>>>>
>>>>> Automatically and optimistically upgrade all main-frame navigations to
>>>>> HTTPS, with fast fallback to HTTP.
>>>>>
>>>>>
>>>>> Blink componentInternals>Network>SSL
>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3ENetwork%3ESSL>
>>>>>
>>>>> TAG reviewFetch change process does not mention a TAG review,
>>>>> therefore this is N/A (https://github.com/whatwg/fetch#pull-requests)
>>>>>
>>>>
>>>> Blink's process does mention a TAG review. I think it would be a good
>>>> idea to put this in front of them. I also think they will appreciate it,
>>>> since it's directly in line with their previous guidance (e.g.
>>>> https://www.w3.org/2001/tag/doc/web-https).
>>>>
>>>>
>>>
>>> Sure, we can file a TAG review. I'll update this thread once that's done.
>>>
>>>

Re: [blink-dev] Intent to Ship: BYOB support for Fetch

[Mike West]

LGTM1.

Following along with Mozilla's long-standing implementation SGTM, and
obviates the need for a TAG review. It would be ideal to file an official
standards position issue with WebKit, however, to make sure they understand
that we do intend to ship this and can incorporate that information into
their planning and positioning.

There were questions in that earlier thread about web platform tests. Looks
like they landed in
https://github.com/web-platform-tests/wpt/pull/37910/files, which is great.

Thanks!

-mike


On Fri, May 26, 2023 at 11:32 AM Nidhi Jaju  wrote:

> Contact emailsnidhij...@chromium.org
>
> ExplainerNone
>
> Specificationhttps://fetch.spec.whatwg.org/#http-network-fetch
>
> Summary
>
> Makes Response.body be a readable byte stream instead of a "default"
> readable stream. This enables it to be used with bring-your-own-buffer
> (BYOB) readers, reducing garbage collection overhead and copies.
>
> As mentioned in the Activation section below, we plan to ship the
> ReadableStreamTeeCloneForBranch2 feature first, and then the FetchBYOB
> feature later.
> Blink componentBlink>Network>FetchAPI
> 
>
> TAG reviewNone
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> Low risk because streams and fetch have already been standardized for a
> long time. Other browsers have implemented other parts of the standard, and
> Firefox has already shipped this behavior for many months and others will
> most likely also adapt this feature as well soon.
>
>
> *Gecko*: Shipped/Shipping (
> https://github.com/whatwg/fetch/issues/267#issuecomment-1350303670)
> Already shipped in Firefox in 2022.
>
> *WebKit*: Positive (https://github.com/whatwg/fetch/pull/1593) @annevk
> from Apple approved the PR to update the spec with relevant changes and
> expressed interest as an implementer on behalf of Apple.
>
> *Web developers*: No signals
>
> *Other signals*: Deno is also interested in, and somewhat shipped, this
> behavior (https://github.com/denoland/deno/issues/17386).
>
> Activation
>
> Currently, to clone a body, we tee the body's stream, but teeing always
> returns two "default" streams, where the chunks are not cloned for both
> streams. Making Response.body into a byte stream, will mean that cloning it
> will result in cloning the chunks for the second stream, which is different
> behavior. In order to mitigate activation risks, we are splitting this
> change into two releases. One where the default teeing behavior will also
> start to clone for the second stream behind the
> "ReadableStreamTeeCloneForBranch2" feature flag, and then make
> Response.body a readable byte stream behind the "FetchBYOB" feature flag.
>
>
> 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
>
> No special support needed.
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?Yes
>
> This feature will be purely implemented in Blink and so cross-platform
> support is automatic.
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?Yes
>
> Flag nameReadableStreamTeeCloneForBranch2 and FetchBYOB
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1243329
>
> Estimated milestones
> Shipping on desktop 116
> Shipping on Android 116
> Shipping on WebView 116
>
> 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).
> None. The spec change for BYOB support for Fetch was already landed at
> https://github.com/whatwg/fetch/pull/1593.
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5192003450568704
>
> Links to previous Intent discussionsIntent to prototype:
> https://groups.google.com/a/chromium.org/g/blink-dev/c/Iyt6Ca9PiJQ/m/s_D7A0YwCgAJ
>
> --
> 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/CAMZNYANt%2BwCoAYOfh1Bj7EJrdTz3jkd%3D%3DAyeBv9f8P2Ccu1wkg%40mail.gmail.com
> 
> 

[blink-dev] Re: Intent to Ship: HTTPS Upgrades

['Mike West' via blink-dev]

On Fri, May 26, 2023 at 1:32 AM Chris Thompson  wrote:

> On Thu, May 25, 2023 at 3:36 AM Mike West  wrote:
>
>> I am enthusiastic about this (and not just because it should allow us to
>> deprecate/remove `Upgrade-Insecure-Requests`). A few comments inline:
>>
>> On Thu, May 25, 2023 at 1:13 AM Chris Thompson 
>> wrote:
>>
>>> Contact emailscth...@chromium.org, dadr...@google.com
>>>
>>> Explainerhttps://github.com/dadrian/https-upgrade/blob/main/explainer.md
>>>
>>> Specificationhttps://github.com/whatwg/fetch/pull/1655
>>>
>>
>> Thanks for putting this together! I'll leave some comments on the PR.
>> Given that we haven't gotten any feedback from Fetch editors, it might be
>> prudent to let them take a pass before locking in our current behavior.
>>
>
>  Yes, hopefully we can get some feedback, but I'm optimistic that we won't
> be locking in behavior if we ship this as it should hopefully be not site
> or user visible, so if we need to change the behavior to align
> cross-browser we can iterate.
>

I left a few comments last week. I think the PR needs some work before we
can reasonably expect it to land in Fetch.

Do we have tests in place for this behavior in Web Platform Tests?
>> https://wpt.fyi/results/mixed-content/tentative/autoupgrades?label=experimental=master
>> holds some tests for subresources, but I didn't see any around
>> navigation or fallback behavior (which seems like it might need some WPT
>> infrastructure change to produce a domain that's only served over HTTP).
>>
>
> We do not have Web Platform Tests but we can look into adding them.
> Currently this is implemented in //chrome which I think might make this
> more difficult (my understanding is that the WPT suite is run against
> content_shell rather than chrome).  We are currently relying on browser
> tests for our integration testing.
>

WPT is a pretty important part of shipping features that affect the
platform. It would be ideal if we could share these tests with our friends
at other vendors (and update existing tests that might be expecting
different behavior). Shifting the implementation to //content to make that
possible would also have the advantage of helping other Chromium embedders
ship this feature, which would be excellent for consistency in the project.


>
>
>> Summary
>>>
>>> Automatically and optimistically upgrade all main-frame navigations to
>>> HTTPS, with fast fallback to HTTP.
>>>
>>>
>>> Blink componentInternals>Network>SSL
>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3ENetwork%3ESSL>
>>>
>>> TAG reviewFetch change process does not mention a TAG review, therefore
>>> this is N/A (https://github.com/whatwg/fetch#pull-requests)
>>>
>>
>> Blink's process does mention a TAG review. I think it would be a good
>> idea to put this in front of them. I also think they will appreciate it,
>> since it's directly in line with their previous guidance (e.g.
>> https://www.w3.org/2001/tag/doc/web-https).
>>
>>
>
> Sure, we can file a TAG review. I'll update this thread once that's done.
>
>
>> TAG review statusNot applicable
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>>
>>>
>>> *Gecko*: Positive (
>>> https://github.com/mozilla/standards-positions/issues/800) Firefox is
>>> offering a similar feature already in their private browsing mode by default
>>>
>>> *WebKit*: No signal (
>>> https://github.com/WebKit/standards-positions/issues/185)
>>>
>>> *Web developers*: No signals. This feature is not exposed directly to
>>> web developers or users. However, HTTPS adoption is now standard practice
>>> (>90% of page loads in Chrome use HTTPS), and automatically upgrading
>>> navigations to HTTPS would avoid unnecessary redirects from HTTP to HTTPS
>>> for site owners. The `upgrade-insecure-requests` header has some similar
>>> functionality, and according to HTTP-Archive is found on ~6% of all
>>> requests.
>>>
>>> *Other signals*:
>>>
>>> WebView application risks
>>>
>>> Does this intent deprecate or change behavior of existing APIs, such
>>> that it has potentially high risk for Android WebView-based applications?
>>>
>>>
>>>
>>> Debuggability
>>>
>>> Chrome will upgrade these navigations to HTTPS using a 307 internal
>>> redirect, which will be visible in the Network panel of D

Re: [blink-dev] Intent to Ship: AbortSignal.any()

[Mike West]

LGTM1.

The risks you point to seem minor, and following along with Safari's
implementation makes it more likely that we can land the feature in a way
that sticks. Do you have insight into Mozilla's implementation progress?

-mike


On Fri, May 26, 2023 at 12:47 AM Scott Haseley 
wrote:

> Contact emailsshase...@chromium.org
>
> Explainerhttps://github.com/shaseley/abort-signal-any/blob/main/README.md
>
> Specificationhttps://dom.spec.whatwg.org/#dom-abortsignal-any
> https://wicg.github.io/scheduling-apis/#dom-tasksignal-any (TaskSignal
> specialization)
>
> Design docs
> https://docs.google.com/document/d/1LvmsBLV85p-PhSGvTH-YwgD6onuhh1VXLg8jPlH32H4/edit#heading=h.xp6e50wyimb4
>
> Summary
>
> AbortSignal.any(signals) returns a signal that is aborted when any of the
> source signals are aborted. Developers can use this to combine independent
> abort sources, e.g. timeouts specified with AbortSignal.timeout() and
> signals associated with user input, and pass them to async APIs like
> fetch().
>
> Comments
> This intent also includes TaskSignal.any(), which is a specialization of
> AbortSignal.any() (TaskSignal inherits from AbortSignal) for
> https://wicg.github.io/scheduling-apis/. The specialization behaves the
> same for abort, but returns a TaskSignal with the priority bit initialized
> from the additional optional parameter. TaskSignal is only implemented in
> Chromium, and this is a small addition to keep the API in sync with the
> base class.
>
> Blink componentBlink>DOM
> 
>
> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/737
>
> TAG review statusIssues addressed
>
> Risks
>
>
> Interoperability and Compatibility
>
> There's a slight compat risk resulting from spec changes associated with
> the new feature.
>
>
> Signals could previously be combined (in specs) similarly using the
> "follow" algorithm, which was replaced with a new algorithm for creating a
> dependent signal. The new algorithm changes the order the abort event is
> propagated between source and dependent signals, which was done to optimize
> memory management (one of the API goals) and limit complexity. This is
> observable in two ways: 1. In fetch, `new Request(url, {signal})` and
> `request.clone()` made a "copy" of the input signal using "follow", so the
> relative order of 'abort' events between 'signal' and `request.signal` can
> change. For example: ``` // Previously, handler2 ran before handler1, if
> the signal is aborted. signal.addEventListener('abort', handler1); const r
> = new Request(url, {signal}); r.signal.addEventListener('abort', handler2);
> ``` `clone()` is similar (one WPT test was changed for the new
> expectation). 2. Our cache.addAll() implementation had an unspecced use of
> "follow" that could result in 'abort' events firing when they shouldn't
> have. This was fixed. The risk seems low here, and we didn't think changing
> the API implementation to ensure this order was worth the
> complexity/optimization limitations. The feature can be disabled via kill
> switch (AbortSignalAny) if necessary.
>
>
> *Gecko*: Positive (
> https://github.com/mozilla/standards-positions/issues/774)
>
> *WebKit*: Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=256176
> )
>
> *Web developers*: No signals
>
> Probably "mildly positive":
>  - 4 stars on implementation bug (crbug.com/13233910)
>  - Discussion/motivation on DOM issue (
> https://github.com/whatwg/dom/issues/920
>  - A couple libraries implement something similar (
> https://www.reddit.com/r/javascript/comments/ve96pn/abortcontroller_is_your_friend/
> )
>
> *Other signals*:
> Implemented in Node.js: https://github.com/nodejs/node/pull/47821
>
> Ergonomics
>
> This is designed to be used with other AbortSignal APIs (AbortController
> and AbortSignal.timeout), and improves ergonomics of handling multiple
> signals.
>
>
> Activation
>
> The feature would benefit from a polyfill.
>
>
> Security
>
> None.
> https://github.com/shaseley/abort-signal-any/blob/main/tag-questionnaire.md
>
>
> 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?
>
> See compat section.
>
>
> Debuggability
>
> Basic support only.
>
>
> 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
> 
> ?Yes
>
> Flag name--enable-blink-features=AbortSignalAny
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1323391
>
> Estimated milestones
> Shipping on desktop 116
> Shipping on Android 116
> Shipping on WebView 116
>
> Anticipated spec changes
>
> Open questions about a feature may be a source of future web compat or
> 

[blink-dev] Re: Intent to Ship: HTTPS Upgrades

[Mike West]

I am enthusiastic about this (and not just because it should allow us to
deprecate/remove `Upgrade-Insecure-Requests`). A few comments inline:

On Thu, May 25, 2023 at 1:13 AM Chris Thompson  wrote:

> Contact emailscth...@chromium.org, dadr...@google.com
>
> Explainerhttps://github.com/dadrian/https-upgrade/blob/main/explainer.md
>
> Specificationhttps://github.com/whatwg/fetch/pull/1655
>

Thanks for putting this together! I'll leave some comments on the PR. Given
that we haven't gotten any feedback from Fetch editors, it might be prudent
to let them take a pass before locking in our current behavior.

Do we have tests in place for this behavior in Web Platform Tests?
https://wpt.fyi/results/mixed-content/tentative/autoupgrades?label=experimental=master
holds some tests for subresources, but I didn't see any around
navigation or fallback behavior (which seems like it might need some WPT
infrastructure change to produce a domain that's only served over HTTP).

Summary
>
> Automatically and optimistically upgrade all main-frame navigations to
> HTTPS, with fast fallback to HTTP.
>
>
> Blink componentInternals>Network>SSL
> 
>
> TAG reviewFetch change process does not mention a TAG review, therefore
> this is N/A (https://github.com/whatwg/fetch#pull-requests)
>

Blink's process does mention a TAG review. I think it would be a good idea
to put this in front of them. I also think they will appreciate it, since
it's directly in line with their previous guidance (e.g.
https://www.w3.org/2001/tag/doc/web-https).


> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
>
>
> *Gecko*: Positive (
> https://github.com/mozilla/standards-positions/issues/800) Firefox is
> offering a similar feature already in their private browsing mode by default
>
> *WebKit*: No signal (
> https://github.com/WebKit/standards-positions/issues/185)
>
> *Web developers*: No signals. This feature is not exposed directly to web
> developers or users. However, HTTPS adoption is now standard practice (>90%
> of page loads in Chrome use HTTPS), and automatically upgrading navigations
> to HTTPS would avoid unnecessary redirects from HTTP to HTTPS for site
> owners. The `upgrade-insecure-requests` header has some similar
> functionality, and according to HTTP-Archive is found on ~6% of all
> requests.
>
> *Other signals*:
>
> WebView application risks
>
> Does this intent deprecate or change behavior of existing APIs, such that
> it has potentially high risk for Android WebView-based applications?
>
>
>
> Debuggability
>
> Chrome will upgrade these navigations to HTTPS using a 307 internal
> redirect, which will be visible in the Network panel of Developer Tools.
>

For HSTS, we synthesize a `Non-Authoritative-Reason` header on the
synthetic redirect that tells developers why the redirect happened. Is that
a pattern y'all will follow here as well? If so, it's probably a good idea
to document it somewhere; I don't think we've explained that header well. :)


> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?No
>
> Currently not available on Android WebView. We are implementing this first
> for Chrome and will consider bringing this to WebView (likely as an
> embedder opt-in) as follow up work.
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?No
>
> Flag namehttps-upgrades
>
> Requires code in //chrome?True
>

Can you spell out what's required here? Just enterprise policy work, or are
there other things embedders would need to implement to make this
functionality work?


> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1394910
>
> Launch bughttps://launch.corp.google.com/launch/4235192
>
> Sample links
> http://example.com will upgrade to https://example.com.
> http://www.alwayshttp.com will upgrade to https://www.alwayshttp.com but
> fall back to http://www.alwayshttp.com because the site doesn't support
> HTTPS.
>
> Estimated milestones
> Shipping on desktop 115
> Shipping on Android 115
>
> We are planning to do a field trial to gradually roll out this feature to
> Chrome clients in Chrome 115.
>

Over what time period do you expect to ramp up to 100%? If you expect it to
push beyond the M115 timeframe, it might be reasonable to frame this as an
intent to experiment to give folks a little more time to weigh in on the
Fetch PR.

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

Re: [blink-dev] Intent to Ship: CSS overlay property

[Mike West]

I agree that https://github.com/w3c/csswg-drafts/issues/6429 which the TAG
pointed to seems tangential to `overlay`. It's somewhat unfortunate,
though, that we don't seem to have responded to their feedback in the month
since they gave it.

The conversation in https://github.com/w3c/csswg-drafts/issues/8730 seems
to be converging, and the open question remaining seems to be one that we
could ~easily reverse if we were convinced that we needed to post-shipping.

LGTM2.

-mike


On Wed, May 24, 2023 at 4:57 PM Rick Byers  wrote:

> Looking over the discussion that's happened over the past month it seems
> some confusion has been resolved and some improvements made to the spec. I
> don't see evidence of outstanding concrete points of disagreement. That, of
> course, doesn't mean others feel it's ready to ship (would be nice to see
> #8730  resolved for
> that). But as far as I can see, it's not blocked on us doing anything
> specific.
>
> So LGTM1 to ship
>
>
> On Wed, May 3, 2023 at 12:08 PM Joey Arhar  wrote:
>
>> The CSSWG issue hasn't received any actionable feedback yet, and the TAG
>> feedback wasn't about overlay but about @initial and display animation.
>>
>> On Tue, Apr 25, 2023 at 7:50 AM Rick Byers  wrote:
>>
>>> Hi Joey,
>>> I'm excited for this to ship. I see that there's some feedback from the
>>> TAG  and concern
>>> from the WG  about at
>>> least one open spec issue. Please let us know here when you feel that
>>> either the feedback has been resolved or that a good faith effort to reach
>>> consensus has been made but we're at an impasse and should ship despite the
>>> disagreements.
>>>
>>> Thanks,
>>>Rick
>>>
>>> On Mon, Apr 17, 2023 at 7:12 PM Joey Arhar  wrote:
>>>
 Contact emailsfuth...@chromium.org, mas...@chromium.org,
 jar...@chromium.org

 Explainer
 https://github.com/chrishtr/rendering/blob/master/entry-exit-animations.md

 Specificationhttps://drafts.csswg.org/css-position-4/#overlay

 Summary

 Introduce a overlay property to allow authors to keep elements in the
 top layer for an exit transition. The overlay property is added to indicate
 if an element is in the top layer or not. It can take two values: 'none',
 'browser'. User agent stylesheets add !important rules to control whether
 elements are rendered in the top layer or not, and not let author styles
 override. However, authors can add overlay to the list of
 transition-properties for an element to defer the removal from the
 top-layer for the duration of the transition. That way the author can do
 exit transitions for elements like dialogs: transition-property: overlay
 transition-duration: 0.4s


 Blink componentBlink>CSS
 

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

 TAG review statusPending

 Risks


 Interoperability and Compatibility



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

 *WebKit*: No signal (
 https://github.com/WebKit/standards-positions/issues/169)

 *Web developers*: No signals

 *Other signals*:

 Ergonomics

 This will be used in tandem with CSSTransitionDiscrete,
 CSSDisplayAnimation, the dialog element, and the popover attribute as
 described here:
 https://github.com/chrishtr/rendering/blob/master/entry-exit-animations.md
 Usage of this API will not make it hard for Chrome to maintain good
 performance.


 Activation

 I'm not sure if this and the other new animations features are
 polyfillable. Documentation will definitely be helpful.


 Security

 This CSS feature does not pose any security or privacy risks.


 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?

 This feature does not deprecate or change any APIs and does not have
 any WebView risk.


 Debuggability

 DevTools now has special support for the top layer. I don't think this
 CSS property will change or impose on how that works in DevTools.


 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
 
 ?Yes

 Flag nameCSSTopLayerForTransitions

 Requires code in //chrome?False

 Tracking bughttps://crbug.com/1411264

 Availability 

Re: [blink-dev] Intent to Deprecate and Remove: “uuid-in-package” navigation with Web Bundles

[Mike West]

LGTM2.

-mike


On Tue, May 23, 2023 at 12:38 PM Yoav Weiss  wrote:

> LGTM1 to remove, given the extremely low usage
>
> On Tue, May 16, 2023 at 3:50 AM Hayato Ito  wrote:
>
>> Primary eng (and PM) emails
>>
>> hay...@chromium.org, ksakam...@chromium.org, denom...@chromium.org
>>
>> Summary
>>
>> Deprecate and remove the “uuid-in-package” navigation support with Web
>> Bundles, which is an extension
>> 
>> to Subresource loading with Web Bundles
>> .
>> This extension allows a bundle to include “uuid-in-package:” URL resources,
>> which will be used to create an opaque origin iframe.
>>
>> Subresource Loading with Web Bundles is still supported; only the
>> extension part is being removed.
>>
>>
>> Motivation
>>
>> The usage of this extension feature is very low. The Chrome team has
>> contacted the primary customer, Google Ads team, and confirmed they have
>> already stopped using it. With no other customers, there is no reason to
>> keep this feature in Chrome.
>>
>> Interoperability and Compatibility Risk
>>
>> This is a Chrome/Edge only feature. There is no interoperability risk.
>>
>> Firefox: Not supported
>>
>> Safari: Not supported
>>
>> Alternative implementation suggestion for web developers
>>
>> There is no alternative.
>>
>> Usage information from UseCounter
>>
>> 0.0001% (link
>> )
>>
>>
>> Entry on the feature dashboard
>>
>> https://chromestatus.com/feature/5710618575241216
>>
>> The feature status page will be updated to mention the removal of the
>> extension part.
>>
>>
>> --
>> Hayato
>>
>> --
>> 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/CAFpjS_0QcR-8Fsfgn%3DXCP5MObkni2ZLyFSFGYHy1fF_YMhk%3DLA%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/CAL5BFfWJGoLAV1d2O_FfKaN81_i9o1-Ywjvab4uGX9Uz9uZfJQ%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/CAKXHy%3DdqOLxpKkiDZ35t%2BFbYS34oioQ3OE_M3yFnLfxPGvmVzQ%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Ship: WebAuthn PRF extension

[Mike West]

LGTM1, with the suggestion that following up on Caleb's comments about the
spec's privacy section would be appreciated.

-mike


On Fri, May 12, 2023 at 9:16 AM Morgaine (de la faye) 
wrote:

> Hello. I don't have any present use cases as a web developer here, but I'm
> very excited & thrilled to see this extension. Giving users ways to secure
> their data is a very significant win & this seems like a straightforward
> low-level capability to enable that. Thanks.
>
> --
> 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/605d0dee-68a5-4b09-9483-23d6f887a4f4n%40chromium.org
> 
> .
>

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

Re: [blink-dev] Intent to Ship: Private State Tokens API

[Mike West]

LGTM2, with the understanding that cleaning up the developer-facing story
around this work is important. I think the unenrolled case probably falls
into step ~8  of https://wicg.github.io/trust-token-api/#issue-request, in
which case I think the web-facing behavior is clearly-enough specified. I'd
like y'all to make sure that that failure mode is debuggable, which I'm
happy for you to wrap into a larger story around enrollment in devtools if
that's what you land on when working with that team.

Thanks!

-mike


On Mon, May 15, 2023 at 5:06 PM Steven Valdez  wrote:

> Thanks, we'll work on fixing those two issues.
>
> I'm not sure what the general flow for enrollment in DevTools will look
> like, but if there's a general flow to detect when enrollment is missing
> for other APIs that check at runtime, we can try to integrate with that
> when PST calls are made with an unregistered issuer.
>
> On Fri, May 12, 2023 at 7:05 PM Mike Taylor 
> wrote:
>
>> LGTM1 % resolving the following spec issues:
>>
>> https://github.com/WICG/trust-token-api/issues/232
>>
>> https://github.com/WICG/trust-token-api/issues/230
>>
>> On Wed, May 10, 2023 at 5:52 AM Mike West  wrote:
>>
>>> Will devtools help guide developers towards enrollment?
>>>
>> Also I think Mike's question on devtools support is worth answering.
>>
>
>
> --
>
>  Steven Valdez |  Chrome Privacy Sandbox |  sval...@google.com |  Cambridge,
> MA
>

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

Re: [blink-dev] Re: Intent to Experiment: Compute Pressure

[Mike West]

Extending from M117 to M118 LGTM.

-mike


On Fri, May 12, 2023 at 7:14 AM 'Ajay Rahatekar' via blink-dev <
blink-dev@chromium.org> wrote:

> Hello API Owners,
>
> The Intent to Experiment mentions Origin Trial duration of M115 - M117. We
> would like approval to have the Origin Trial for M115 - M118 based on the
> current 4 week Chrome release cycle.
>
> Thanks in advance.
>
> -Ajay
>
> On Tuesday, May 2, 2023 at 10:28:08 PM UTC-7 arnaud...@intel.com wrote:
>
>> Great! Thank you!
>>
>> Arno
>>
>> --
>> *From:* Ajay Rahatekar 
>> *Sent:* Tuesday, May 2, 2023 20:52
>> *To:* blink-dev 
>> *Cc:* mike...@chromium.org ; Mandy, Arnaud <
>> arnaud...@intel.com>; Christiansen, Kenneth R ;
>> Wang, Wei4 ; Ajay Rahatekar 
>> *Subject:* Re: [blink-dev] Re: Intent to Experiment: Compute Pressure
>>
>> Ty, Mike.
>>
>> On Tuesday, May 2, 2023 at 10:51:55 AM UTC-7 mike...@chromium.org wrote:
>>
>> Apologies for this slipping through the cracks.
>>
>> LGTM to experiment from M115 to M117.
>> On 5/1/23 6:15 PM, 'Ajay Rahatekar' via blink-dev wrote:
>>
>> +ajayra...@google.com
>>
>> Friendly ping for review.
>>
>> On Thursday, April 20, 2023 at 3:20:21 AM UTC-7 arnaud...@intel.com
>> wrote:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> * Contact emails kenneth.r.c...@intel.com, arnaud...@intel.com,
>> wei4...@intel.com Explainer
>> https://github.com/w3c/compute-pressure/blob/main/README.md
>>  Specification
>> https://www.w3.org/TR/compute-pressure
>>  Design docs
>> https://developer.chrome.com/docs/web-platform/compute-pressure
>>  Summary
>> The Compute Pressure API offers high-level states that represent the
>> pressure on the system. It allows the implementation to use the right
>> underlying hardware metrics to ensure that users can take advantage of all
>> the processing power available to them as long as the system is not under
>> unmanageable stress. “Pressure” is a generic term by design – at the moment
>> it is calculated based on CPU load, but future plans include using signals
>> from temperature and battery status, for example. Blink component
>> Blink>PerformanceAPIs>ComputePressure Search tags compute pressure TAG
>> review spec review: https://github.com/w3ctag/design-reviews/issues/795
>>  wide review tracker:
>> https://github.com/w3c/compute-pressure/issues/177
>>  TAG review status
>> Issues addressed
>> https://github.com/w3ctag/design-reviews/issues/795#issuecomment-1513997968
>> 
>> Risks Interoperability and Compatibility Gecko: No signal
>> (https://github.com/mozilla/standards-positions/issues/521
>> ) WebKit:
>> Negative
>> (https://lists.webkit.org/pipermail/webkit-dev/2021-May/031845.html
>> ) This
>> issue has been taken into account:
>> https://github.com/w3c/compute-pressure/issues/24
>>  Web developers:
>> Positive (https://github.com/w3c/compute-pressure/issues/14
>> ) Security
>> https://github.com/w3c/compute-pressure/issues/79
>>  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 We want developer feedback around the feature's
>> performance and applicability in real usage scenarios.   The API shape has
>> changed significantly since the first Origin Trial (M92-M94), and we would
>> like to get additional developer feedback before shipping.
>> https://github.com/w3c/compute-pressure/blob/main/CHANGES.md
>>  Ongoing
>> technical constraints Debuggability Will this feature be supported on all
>> six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android
>> WebView)? No, supported for Windows, Mac, Linux, Chrome OS. Is this feature
>> fully tested by web-platform-tests? Yes
>> https://wpt.fyi/results/compute-pressure?label=master=experimental=subtest=compute-pressure
>> 
>> DevTrial instructions
>> https://github.com/w3c/compute-pressure/blob/main/HOWTO.md
>>  Flag name
>> --enable-features=ComputePressure see
>> https://github.com/w3c/compute-pressure/blob/main/HOWTO.md
>> 

Re: [blink-dev] Intent to Ship: Private State Tokens API

[Mike West]

On Fri, May 5, 2023 at 7:14 PM Steven Valdez  wrote:

> Rick: For the spec work, we've merged the type parameter removal into the
> spec and have a PR <https://github.com/WICG/trust-token-api/pull/239> to
> add the permission policy integration. We've already updated Chrome for
> both of those changes.
>
> Mike: We would be checking enrollment/attestation when the issuer
> update/re-register their key commitments rather than on the browser at
> run-time, so it wouldn't need defined user-agent behavior. Some mechanism
> for verifying attestations on an ongoing basis seems like it would add
> additional value, but that would be future work.
>

Hey Steven!

My question was about the developer-facing implications of registering or
not. That is, if a developer sends an issuance request to a server that
hasn't registered as an issuer, what can they expect to see after calling
`fetch(issueRequest)`? Will the request happen, just without additional
headers? Will the fetch reject with a network error? Will devtools help
guide developers towards enrollment?

>From your response, though, it sounds like there might not be any runtime
implications to enrollment? I'm not sure I understand why anyone would
enroll if that's the case. :)

-mike


>
>
> On Wed, May 3, 2023 at 11:45 AM Mike West  wrote:
>
>> I agree with Rick on the merits, but would point out one aspect of the
>> enrollment mechanism that I think does have interop considerations that
>> Chromium needs to consider. If embedders have a gate on issuance, we need
>> to ensure that both sides of that gate have defined developer-facing
>> behavior. It's not clear to me how enrollment status is represented in the
>> spec, whether relevant errors are surfaced to developers through devtools,
>> etc. Have y'all thought through that distinction from the platform
>> perspective?
>>
>> -mike
>>
>>
>> On Wed, May 3, 2023 at 4:15 AM Rick Byers  wrote:
>>
>>> Looking through the open issues and Martin's great feedback, it seems
>>> pretty clear that there are some significant interoperability risks here
>>> still. That said, Chrome's inability to remove 3PCs until we can
>>> demonstrate adequate replacements is also an ongoing interop (and privacy)
>>> cost for the web. As with most things privacy sandbox related, I'm
>>> personally leaning more towards a ship-and-iterate model being less bad
>>> than risking delaying the 3PCD timeline
>>> <https://privacysandbox.com/open-web/#the-privacy-sandbox-timeline>.
>>>
>>> That said, it looks like there's at least a little low hanging fruit
>>> remaining in spec work. Eg. this issue
>>> <https://github.com/WICG/trust-token-api/issues/226> suggests we've
>>> implemented an API (permissions policy integration) in chromium that isn't
>>> spec'd out, is that right? Permissions policy is usually pretty straight
>>> forward to integrate these days, right? Any reason we can't just get that
>>> landed in the spec now before shipping? Also there's a few discussions of 
>>> removing
>>> the type parameter <https://github.com/WICG/trust-token-api/issues/222>,
>>> can we just do that now to reduce the need for a breaking change analysis
>>> in the future? If we can get these spec fixes landed quickly, then I'm
>>> personally willing to approve this I2S with the expectation of continued
>>> spec investment and cross-browser alignment.
>>>
>>> There's clearly also a lot to discuss about the enrollment mechanism
>>> <https://developer.chrome.com/blog/announce-enrollment-privacy-sandbox/#attestations>
>>>  shared
>>> by a number of privacy sandbox APIs, but I see that as a Chrome
>>> implementation detail, not something necessarily subject to the web
>>> standards process (though certainly still open to public scrutiny and
>>> debate).
>>>
>>> Rick
>>>
>>>
>>>
>>> On Fri, Apr 28, 2023 at 1:23 PM Steven Valdez 
>>> wrote:
>>>
>>>> Thanks for the feedback, I've replied on Github with the reasoning and
>>>> to continue the conversation. There's definitely some spec work to make
>>>> the  registration behavior clearer.
>>>>
>>>> -Steven
>>>>
>>>> On Wed, Apr 26, 2023 at 9:59 PM Martin Thomson  wrote:
>>>>
>>>>> I just raised https://github.com/WICG/trust-token-api/issues/240
>>>>> based on this.  I had missed that you were planning to register issuers.
>>>>> See the issue for more.
>>>>>
>&

Re: [blink-dev] Re: Intent to Ship: WGSLLanguageFeatures for WebGPU

[Mike West]

LGTM2.

-mike


On Wed, May 10, 2023 at 1:10 AM 'Loko Kung' via blink-dev <
blink-dev@chromium.org> wrote:

> Thanks Yoav for taking a look! Bumping this again since M115 branch point
> is coming soon (May 23) and we still need 2 more LGTMs before I can land
> the changes!
>
> On Tuesday, May 9, 2023 at 7:31:33 AM UTC-7 Yoav Weiss wrote:
>
>> LGTM1
>>
>> On Wed, May 3, 2023 at 9:52 PM Loko Kung  wrote:
>>
>>> Thanks Kai for replying! To add on top of that:
>>>
>>> For the signals: Positive
>>> https://github.com/WebKit/standards-positions/issues/107
>>> https://mozilla.github.io/standards-positions/#webgpu
>>>
>>
>> \o/
>>
>>
>>>
>>>
>>> For the web-platform-tests, on top of the CTS Kai mentioned, the change
>>> in https://chromium-review.googlesource.com/c/chromium/src/+/4471680
>>> already adds the bare-bones testing for the new field.
>>>
>>> On Wed, May 3, 2023 at 12:22 PM Kai Ninomiya 
>>> wrote:
>>>
 Thank you for the questions, replies inline!

 I actually ran into the same problem when I filed an I2S recently with
 a lot of gaps in the generated email. The chromestatus tool hides most of
 the fields used to generate emails behind various stages of shipment, which
 makes it hard to set them correctly for I2E/I2S (I had to use "edit all
 fields" to find them). It also defaults to rarely-correct values like "no
 signals" and "no tests".

>>>
>> +Jason Robbins - FYI
>>
>>
>>>
 On Tue, May 2, 2023 at 10:42 PM Yoav Weiss 
 wrote:

>
>
> On Wed, May 3, 2023 at 12:04 AM Ken Russell  wrote:
>
>> Could more Blink owners please provide their input? This is a feature
>> the WebGPU CG has standardized, and we would like to get it in our
>> implementation ASAP so the associated tests can start running correctly 
>> in
>> Chrome.
>>
>> Thanks,
>>
>> -Ken
>>
>>
>>
>> On Tue, May 2, 2023 at 9:56 AM Caleb Raitto 
>> wrote:
>>
>>> Thanks, I thought so, but wanted to confirm :)
>>>
>>> -Caleb
>>>
>>> On Tue, May 2, 2023 at 12:54 PM Ken Russell 
>>> wrote:
>>>
 These are essentially GPU-independent, syntactic-sugar-like,
 language extensions that it's expected all browsers will eventually
 implement. Since browser updates roll out at different times, it's
 important that the application be able to query their support status so
 they can know which versions of shaders to serve up to clients - or to
 generate at run time.

 -Ken



 On Tue, May 2, 2023 at 8:33 AM Caleb Raitto 
 wrote:

> Are these language extensions specific to certain GPUs (could this
> be used to fingerprint the GPU)? Or are the language extensions 
> something
> that some browsers will implement, but others won't?
>
> Thanks,
> -Caleb
>
> On Wednesday, April 26, 2023 at 3:36:27 PM UTC-4 Mike Taylor wrote:
>
>> All good - I've flagged it in our chromestatus tool so it doesn't
>> fall off our radar.
>>
>> (and updating the email title just in case)
>> On 4/26/23 2:42 PM, 'Loko Kung' via blink-dev wrote:
>>
>> Ah, sorry for the misleading title. This is actually an Intent to
>> Ship! Let me know if I should resend with the Intent to Ship 
>> template!
>>
>> On Tue, Apr 25, 2023 at 8:07 PM Loko Kung 
>> wrote:
>>
>>> Contact emails loko...@google.com
>>>
>>> Explainer None
>>>
>>
> An explainer (even a short, inline one) would be extremely helpful
> when reviewing this. As is, it's not immediately clear to me what are we
> adding here, what are the use cases this addresses and how are developers
> supposed to use it?
>

 We're adding a mechanism for feature detection of new language features
 added to WGSL (WebGPU Shading Language). Since that's a language and not a
 JS API, we needed a feature detection mechanism better than "try to compile
 a shader and (asynchronously) find out if it failed".

 At this time no such language features have been added yet (but we know
 they will be).

>>>
>> Thanks! That helps significantly :)
>>
>>>
>>>
>>> Specification
>>> https://www.w3.org/TR/webgpu/#gpuwgsllanguagefeatures
>>>
>>> Summary
>>>
>>> Adds the `wgslLanguageFeatures` getter on the GPU object for
>>> WebGPU, and its corresponding `WGSLLanguageFeatures` type.
>>>
>>>
>>> Blink component Blink>WebGPU
>>> 
>>>
>>> Motivation
>>>
>>> None
>>>
>>>
>>> Initial public proposal None
>>>

Re: [blink-dev] Intent to Experiment: "is-cross-site" bit in the HTTP Cache Partitioning Key

[Mike West]

Hey Andrew!

On Tue, May 2, 2023 at 4:41 PM Andrew Williams  wrote:

> Contact emails
>
> awil...@chromium.org
>
> Explainer
>
> This change is not covered by an explainer, but the following are related:
>
> https://github.com/shivanigithub/http-cache-partitioning
>
>
> https://github.com/MattMenke2/Explainer---Partition-Network-State/blob/main/README.md
>
> Spec
>
> https://fetch.spec.whatwg.org/#http-cache-partitions
>
> https://fetch.spec.whatwg.org/#network-partition-keys
>
> Summary
>
> To protect users from multiple types of cross-site data leak attacks, the
> HTTP cache was partitioned
>  based on the
> top-level site and the frame site. In other words, cache entries for a
> given URL created from third-party contexts (e.g., a ‘b.com’ iframe
> embedded on ‘a.com’) are stored separately from those from first-party
> contexts (‘a.com’, or an ‘a.com’ iframe embedded on ‘a.com’) and other
> third-party contexts (a ‘c.com’ iframe embedded on ‘a.com’).
>
> Other shared network state was recently partitioned
>  as well, but using a
> different partitioning scheme - instead of using the top-level site and the
> frame site, network state in third-party contexts is partitioned by the
> top-level site and whether the frame site is cross-site from the top-level
> site. Using this "is-cross-site" bit instead of the frame site was chosen
> as a balance between security and performance after running experiments and
> measuring the results.
>
> The change proposed here is to replace the frame site in the HTTP cache
> partitioning scheme with an "is-cross-site" bit to perform similar
> experimentation. Using the examples above, this change means that a ‘b.com’
> iframe embedded on ‘a.com’ would now share an HTTP cache partition with a
> ‘c.com’ iframe embedded on ‘a.com’, since the “is-cross-site” bit for
> both would be set to true (and since the top-level site for both is ‘a.com
> ’).
>
> Blink component
>
> Internals>Network>Cache
> 
>
> TAG review
>
> Not requested at this time
>
> TAG review status
>
> N/A
>
> RisksInteroperability and Compatibility
>
> No interoperability / compatibility risks are expected, since the caching
> behavior generally only affects site performance , and in this case the
> change should result in performance improvements
>
> Gecko: N/A, but their implementation doesn’t partition by frame site or
> “is-cross-site”;
>
> WebKit: N/A, but their implementation doesn’t partition by frame site or
> “is-cross-site”;
>
> Web developers: No signals
>
> Other signals: N/A
>
> WebView application risks
>
> None, since HTTP cache partitioning is not enabled for WebView
>
> Security
>
> One side effect of this change is that a malicious cross-site iframe will
> now share an HTTP cache partition with other cross-site iframes under the
> same top-level site. This allows the malicious cross-site iframe to perform
> data leak attacks against the other cross-site iframes via HTTP cache
> probing. It’s unclear how useful this attack primitive would be in
> practice, since the data available to the attacker would still be
> partitioned by the top-level site, and since construction of a page to take
> advantage of this weakness (for instance, a phishing page where a victim
> site is in one cross-site iframe) could be thwarted by X-Frame-Options /
> CSP’s frame-ancestors option.
>

I'm not sure I agree. There are plenty of interesting frames that are happy
with being embedded in a wide variety of sites (YouTube, Maps, Ads, payment
providers like Stripe, single-sign on login forms, etc), and it seems
reasonable to assume that being able to gain insight into their state would
be a risk they'd rather avoid. The current partitioning scheme does that,
changing the model seems like a regression.

I don't object to the experiment, but I'd like to see a little more
analysis of risk here so that we can take that into account when making
decisions about performance deltas.

-mike


>
> Goals for experimentation
>
> This experiment aims to identify what effect the new partitioning scheme
> has on the Chrome guiding metrics/vital metrics, and on other metrics that
> are influenced by the performance of the HTTP cache.
>
> Also, one specific side-effect of this change is that iframes with opaque
> origins (for instance, those created using data: URLs) may now be eligible
> to have their resources added to the HTTP cache. We aim to measure what
> changes in performance result from this.
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?
>
> This feature will be supported on all six Blink platforms, but note that
> HTTP cache partitioning is only enabled-by-default for Chrome desktop and
> mobile platforms (but not WebView).
>
> Flag name
>
> 

Re: [blink-dev] Intent to Ship: Private State Tokens API

[Mike West]

I agree with Rick on the merits, but would point out one aspect of the
enrollment mechanism that I think does have interop considerations that
Chromium needs to consider. If embedders have a gate on issuance, we need
to ensure that both sides of that gate have defined developer-facing
behavior. It's not clear to me how enrollment status is represented in the
spec, whether relevant errors are surfaced to developers through devtools,
etc. Have y'all thought through that distinction from the platform
perspective?

-mike


On Wed, May 3, 2023 at 4:15 AM Rick Byers  wrote:

> Looking through the open issues and Martin's great feedback, it seems
> pretty clear that there are some significant interoperability risks here
> still. That said, Chrome's inability to remove 3PCs until we can
> demonstrate adequate replacements is also an ongoing interop (and privacy)
> cost for the web. As with most things privacy sandbox related, I'm
> personally leaning more towards a ship-and-iterate model being less bad
> than risking delaying the 3PCD timeline
> .
>
> That said, it looks like there's at least a little low hanging fruit
> remaining in spec work. Eg. this issue
>  suggests we've
> implemented an API (permissions policy integration) in chromium that isn't
> spec'd out, is that right? Permissions policy is usually pretty straight
> forward to integrate these days, right? Any reason we can't just get that
> landed in the spec now before shipping? Also there's a few discussions of 
> removing
> the type parameter ,
> can we just do that now to reduce the need for a breaking change analysis
> in the future? If we can get these spec fixes landed quickly, then I'm
> personally willing to approve this I2S with the expectation of continued
> spec investment and cross-browser alignment.
>
> There's clearly also a lot to discuss about the enrollment mechanism
> 
>  shared
> by a number of privacy sandbox APIs, but I see that as a Chrome
> implementation detail, not something necessarily subject to the web
> standards process (though certainly still open to public scrutiny and
> debate).
>
> Rick
>
>
>
> On Fri, Apr 28, 2023 at 1:23 PM Steven Valdez  wrote:
>
>> Thanks for the feedback, I've replied on Github with the reasoning and to
>> continue the conversation. There's definitely some spec work to make the
>> registration behavior clearer.
>>
>> -Steven
>>
>> On Wed, Apr 26, 2023 at 9:59 PM Martin Thomson  wrote:
>>
>>> I just raised https://github.com/WICG/trust-token-api/issues/240 based
>>> on this.  I had missed that you were planning to register issuers.  See the
>>> issue for more.
>>>
>>> On Thu, Apr 27, 2023 at 6:31 AM Steven Valdez 
>>> wrote:
>>>
 We've added this as a WIP document in the repository:
 https://github.com/WICG/trust-token-api/blob/main/REGISTRATION.md.

 While the WICG repo won't be the final resting place for the
 policy/registration hopefully that works as an interim until we've got the
 final repo/policy published.

 On Wed, Apr 26, 2023 at 3:51 PM Rick Byers  wrote:

> Thanks Steven, sorry I missed that. +1 to getting it on GitHub and
> links updated.
>
> Rick
>
> On Wed, Apr 26, 2023 at 3:09 PM Mike Taylor 
> wrote:
>
>> On 4/26/23 12:07 PM, Steven Valdez wrote:
>>
>> From higher in the thread:
>>
>> The WIP registration document is at
>> https://docs.google.com/document/d/1oB_YdRMvQWWAsqXsvxMr4FJCngcSBj2rLJzW15l8a_A/edit?usp=sharing
>> .
>>
>> We're planning on hosting it on a Github repo and using that as the
>> source of truth for issuer registrations.
>>
>> We have a slightly chicken and egg problem where setting up the
>> Github repo is reliant on the launch process for this feature.
>>
>> Even if the feature isn't shipping yet, having the docs/process on
>> GitHub (even with a disclaimer as the first line that can be deleted as
>> soon as you get approvals) seems like a better immediate outcome than
>> having the info in a google doc which doesn't seem to be linked from
>> https://github.com/WICG/trust-token-api,
>> https://wicg.github.io/trust-token-api/, or
>> https://developer.chrome.com/en/docs/privacy-sandbox/trust-tokens/.
>>
>> Would that be possible?
>>
>> -Steven
>>
>> On Wed, Apr 26, 2023 at 11:57 AM Rick Byers 
>> wrote:
>>
>>> Hey folks,
>>> Thanks for driving these improvements and taking Mozilla's feedback
>>> seriously. This seems almost ready to ship a V1 to me, modulo
>>> Yoav's last comment.
>>>
>>> Are there current docs somewhere for issuer registration? The
>>> chromestatus entry points to this google doc

Re: [blink-dev] Re: Intent to Deprecate and Remove Web SQL

[Mike West]

LGTM3. Good luck with the launch, I've been excited about this for a while
and I'm looking forward to reducing our attack surface.

-mike


On Wed, May 3, 2023 at 3:21 PM Mike Taylor  wrote:

> LGTM2 - kudos to the team for the very detailed compat and risk analysis,
> as well as proactively engaging in outreach. Good luck. :)
> On 5/3/23 6:59 AM, Yoav Weiss wrote:
>
> LGTM1
>
> Thanks for the details analysis. The rollout plan seems reasonable, and
> the low effective breakage gives me hope that this would stick.
>
> On Friday, April 28, 2023 at 10:26:20 PM UTC+2 Ayu Ishii wrote:
>
>> Contact emails a...@chromium.org, mo...@chromium.org
>> Specification https://www.w3.org/TR/webdatabase
>> Design docs
>> https://developer.chrome.com/blog/deprecating-web-sql
>>
>> [Google Internal]
>> https://docs.google.com/document/d/1bTj_nDqbdvE102sCm3KuwvN5c_HneLNPl9mmPeUjG4M/edit?usp=sharing
>> [Google Internal]
>> https://docs.google.com/document/d/1CDdEO65pCIo60NM8CWHNNN7EunJ-wd8v1dGUxTOBJrM/edit?resourcekey=0-R0fxP199QQ-8gnMqzmQyrw
>>
>> Summary The Web SQL Database standard was first proposed in April 2009
>> and abandoned in November 2010. It was implemented in WebKit in 2008 and
>> shipped in Chrome and Safari, on both desktop and mobile. Gecko and
>> EdgeHTML never implemented this feature and WebKit unshipped it in 2019.
>> The W3C encouraged those needing web databases to adopt Indexed Database.
>> Since its release, it has been incredibly difficult to keep our users
>> secure. SQLite was not designed to run untrusted SQL statements, and yet
>> with Web SQL we have to do exactly this. Keeping up with security and
>> stability fixes dictates updating SQLite in Chromium and impacts the
>> feature’s stability. In 2022 alone, we updated SQLite 11 times. This comes
>> in direct conflict with Web SQL’s requirement of behaving exactly as SQLite
>> 3.6.19, and with the lack of a SQL specification in Web SQL, we cannot make
>> any such compatibility guarantees.
>> With SQLite WASM
>> 
>> as an effective replacement for web developers requiring a relational
>> database, we would like to remove Web SQL entirely.
>>
>> Target timeline
>>
>> M101 - 123 - Enterprise Policy
>> 
>>
>> M115 - Add deprecation message
>>
>> M118-123  - Deprecation trial
>>
>> M119 - Ship removal
>>
>> Usage and Risk
>>
>> Overall usage still shows a high percentage of 0.34% of page loads
>> ,
>> however our analysis has concluded that very little usage is for actual
>> storage.
>>
>> Through analyzing sites from HTTPArchives, we found a majority of its
>> usage is from outdated incognito detection
>> 
>> (e.g. Criteo , Reddit
>> ),
>> and fingerprinting (e.g. Fingerprintjs
>> , evercookie
>> ).
>>
>> There are JS storage libraries that became popular around the time that
>> Web SQL was introduced which use the feature. Oftentimes their usage is
>> part of a fallback chain, where on modern browsers other storage
>> technologies like localStorage or IndexedDB would be chosen before Web SQL.
>> Examples of such libraries are localForage
>> , cordova-sqlite-storage
>> , Sencha Touch
>> .
>> Many, like localForage and cordova-sqlite-storage, gate its usage on
>> feature detection due to its availability only on Chromium browsers.
>> However older versions of Sencha Touch look as though they may not have
>> been gated. Sencha Touch has since removed its SQL feature which depends on
>> Web SQL in their version released in 2015
>> 
>> .
>>
>> Our conclusion from our HTTPArchives analysis
>> 
>> is that we were only able to identify one site that is not gated by feature
>> detection, and one site with significant breakage. We’ve notified open
>> source libraries of Web SQL deprecation, and plan to reach out to site
>> owners we’ve classified as breakage.
>>
>> Analyzing extensions usage, we’ve identified 74% of extensions that use
>> Web SQL
>> 
>> are from JS 

Re: [blink-dev] Intent to Implement and Ship: Update of "xml" prefix handling in lookupNamespaceURI() and createNSResolver()

[Mike West]

LGTM1.

Testing looks good, and skipping the TAG review for features specified and
shipped in other browsers is pretty reasonable. The flat UseCounter also
gives me confidence. :)

-mike


On Wed, Apr 26, 2023 at 12:50 AM TAMURA, Kent  wrote:

> Contact emailstk...@chromium.org
>
> ExplainerNone
>
> Specificationhttps://dom.spec.whatwg.org/#locate-a-namespace
> https://dom.spec.whatwg.org/#dom-xpathevaluatorbase-creatensresolver
>
> Summary
>
> Node.lookupNamespceURI() supports "xml" and "xmlns" prefixes by default.
> The function returns fixed namespace strings for them.
> Document.createNSResolver() and XPathEvaluator.createNSResolver() stops to
> wrap the specified node to add "xml" prefix handling. They return the
> specified node as is. Web developers can use an element as an
> XPathNSResolver without wrapping it with createNSResolver().
>
>
> Blink componentBlink>DOM
> 
>
> TAG reviewNone.  Two other browsers already shipped this.
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> The risk is low. Firefox has had this behavior for a long time, and Safari
> has adopted the behavior. This feature has an incompatible change on
> createNSResolver(). If a disconnected non-element node is specified to
> createNSResolver(), the resultant object has no "xml" prefix support any
> longer. We have a UseCounter for such a case, and the counter value is 0.0.
> https://chromestatus.com/metrics/feature/timeline/popularity/4475
>
>
> *Gecko*: Shipped/Shipping
>
> *WebKit*: Shipped/Shipping (https://commits.webkit.org/260848@main)
>
> *Web developers*: No signals
>
> *Other signals*:
>
> WebView application risks
>
> None
>
>
>
> Debuggability
>
>
>
> 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
> 
> ?Yes
> https://wpt.fyi/results/domxpath/xpathevaluatorbase-creatensresolver.html
> https://wpt.fyi/results/dom/nodes/Node-lookupNamespaceURI.html
>
> Flag name
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1418215
>
> Estimated milestones
> Shipping on desktop 115
> Shipping on Android 115
> Shipping on WebView 115
>
> Anticipated spec changes
>
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5143218561220608
>
> Links to previous Intent discussions
>
> This intent message was generated by Chrome Platform Status
> .
>
> --
> TAMURA Kent
> Software Engineer, Google
>
>
> --
> 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/CAGH7WqGqrLAR9_dhH0XPiC0T57xBHuRcqTf7934Ap4vbNB5Ngw%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/CAKXHy%3Dfmb5s_ygcEc5qyPSHuwpg%3DQTqyqWvGhwUUN16dNGgBpw%40mail.gmail.com.

Re: [blink-dev] Intent to Deprecate and Remove: data: URL in SVGUseElement

[Mike West]

LGTM3.

-mike


On Fri, Apr 21, 2023 at 7:42 PM 'Jun Kokatsu' via blink-dev <
blink-dev@chromium.org> wrote:

> Hi Brandon!
>
> I'll make sure to do that! I'll ping you next week when I start to work
> on it!
>
> Thanks,
>
> Jun
>
>
> On Fri, Apr 21, 2023 at 7:55 AM Brandon Heenan  wrote:
>
>> One addition please: work with me and the enterprise team to also add a
>> paragraph to the enterprise release notes before the deprecation warning is
>> switched to on-by-default
>>
>> On Fri, Apr 21, 2023 at 3:13 AM Yoav Weiss 
>> wrote:
>>
>>> LGTM2 for the above plan. Good luck!!
>>>
>>> On Thu, Apr 20, 2023 at 11:37 PM Rick Byers  wrote:
>>>
 Jun and I have been talking about this offline and I think we've got a
 reasonable plan to attempt to proceed with this breaking change:

- Add Enterprise policy knob

- Disable in WebView by default (or add targetSdk quirk) - in
discussion with WebView team
- Publish a blog post explaining the change and how to adapt to it,
linked from chromestatus entry
- Add deprecation warning (console + deprecation report) linking to
chromestatus entry
- Try flipping the flag on with Finch in canary and dev builds,
maybe beta 50%, watch for reports of bugs and engage on any to see if
they're similarly easy to get sites fixed
- Once 3 milestones have passed with the deprecation warning and
there's aren't major known issues, flip the flag on by default (with
killswitch in place)
- As the change makes its way to stable, keep an eye on any
reports. Be prepared to hit the killswitch and iterate if there is
significant breakage that can't be immediately addressed.

 With this plan, I'm LGTM1 to give this a shot.

 On Tue, Jan 24, 2023 at 10:22 AM Rick Byers 
 wrote:

>
> On Mon, Jan 23, 2023 at 3:00 PM Jun Kokatsu 
> wrote:
>
>> Hi All,
>>
>> I wanted to provide some updates on outreach I've done last week.
>>
>> I manually went through a list of sample sites in the use counter
>> ,
>> and contacted ~10 sites which will be impacted. Among those sites, 3 
>> sites
>> responded so far.
>>
>>1. onsetapp.com has successfully migrated away from data: URLs in
>>SVGUseElement.
>>   - Reason for the usage:
>>
>>
>> *"We used them to import elements from SVG sprites, basically an SVG
>>   file containing every icons loaded once at page load as an attempt 
>> to
>>   improve performance of the app."*
>>2. jobs.nzz.ch are testing the fix in the development pipeline,
>>and hope to migrate away from data: URLs in SVGUseElement soon.
>>- Reason for the usage is unsure as it was done a long time ago.
>>3. We've reached out to Salesforce contact (thanks Rick!) for
>>appexchange.salesforce.com. They are trying to find a responsible
>>team for that subdomain to understand why it was used, and if it can 
>> be
>>migrated away.
>>
>> Thanks Jun, that's some good anecdotal evidence that adapting to this
> breaking change likely isn't too hard for most folks. Despite it being 
> only
> a couple anecdotes, this increases my confidence.
>
>
>> I've also identified faucet.okp4.network as a false positive,
>> because they use svgxuse  as a 
>> fallback
>> mechanism .
>>
>
> Fascinating.
>
> I will wait for sometime so that UKM will reach Beta or Stable, to
>> further identify impacted origins with high volume of access.
>>
>
> Yeah I think this is the most important next step. With luck we'll
> find that there's not too much of a long tail and we can succeed in 
> getting
> a significant drop in usage through outreach.
>
> BTW, thank you Daniel for creating a page
>>  with easy to read
>> alternatives! This was very helpful in the outreach process!
>>
>
> Thanks Daniel! If we proceed with deprecation then perhaps this page
> should form the basis of a chromium.org blog post on the topic that
> we can link to from the chromestatus entry that will be referenced in the
> deprecation warning message.
>
>
>>
>> Thanks,
>>
>> Jun
>>
>>
>> On Thu, Jan 19, 2023 at 3:23 PM Jun Kokatsu 
>> wrote:
>>
>>> On Thu, Jan 19, 2023 at 2:14 PM Rick Byers 
>>> wrote:
>>>
 On Thu, Jan 19, 2023 at 1:17 PM Jun Kokatsu 
 wrote:

> On Thu, Jan 19, 2023 at 9:29 AM Rick Byers 
> wrote:
>
>> Thanks Daniel. I also looked at this 

Re: [blink-dev] Intent to Ship: 'display' property with multiple values

[Mike West]

LGTM2. Skipping TAG review seems reasonable given that we're simply
catching up to existing implementation and spec.

-mike


On Wed, Apr 26, 2023 at 12:36 PM Yoav Weiss  wrote:

> LGTM1
>
> Thanks for catching us up here!
>
> On Wed, Apr 26, 2023 at 12:13 AM TAMURA, Kent  wrote:
>
>> Contact emailstk...@chromium.org
>>
>> ExplainerNone
>>
>> Specification
>> https://w3c.github.io/csswg-drafts/css-display/#the-display-properties
>>
>> Design docs
>> Summary
>>
>> CSS 'display' property supports two or three keywords. Web authors can
>> specify - How the box and its neighbor boxes are located; inline or block -
>> How children of the box are laid out; flow, flex, grid, etc. separately.
>> For example, `display: inline flow` instead of `display: inline-block`
>> `display: block flex` instead of `display: flex`
>>
>>
>> Blink componentBlink>CSS
>> 
>>
>> Search tagscss , display
>> 
>>
>> TAG reviewNone
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> Risks are very low. Two other browsers already shipped the feature.
>>
>>
>> *Gecko*: Shipped/Shipping
>>
>> *WebKit*: Shipped/Shipping
>>
>> *Web developers*: Positive (
>> https://bugs.chromium.org/p/chromium/issues/detail?id=995106) The bug
>> has 16 stars.
>>
>> *Other signals*:
>>
>> WebView application risks
>>
>> None.
>>
>>
>>
>> Debuggability
>>
>>
>>
>> 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
>> 
>> ?Yes
>>
>> https://wpt.fyi/results/css/css-display/parsing
>> Note: Here is the latest result:
>> https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/css/css-display/parsing/display-valid-expected.txt
>>
>>
>> Flag nameCSSDisplayMultipleValues
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=995106
>>
>> Estimated milestones
>> Shipping on desktop 115
>> Shipping on Android 115
>> Shipping on WebView 115
>>
>> Anticipated spec changes
>>
>> None
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5091238937624576
>>
>> Links to previous Intent discussionsIntent to prototype:
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/GYdHdU6MoaU/m/dTYXlP4vMAAJ
>>
>> This intent message was generated by Chrome Platform Status
>> .
>>
>> --
>> TAMURA Kent
>> Software Engineer, Google
>>
>>
>> --
>> 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/CAGH7WqGtug1xy1Bkhs5DDM%2B%2Bg3UvHRH2Lgrw9AJHJE9%3Dc4SVXA%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/CAL5BFfUwx50rPT1fnrCn-nZ323dA2QDddp-67%3DmRrWCRtWm3FQ%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/CAKXHy%3DcL31y7REv-MWB9PkwKMET_Jmbk4j7ns_9Zf1CaTigtZQ%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Ship: Private State Tokens API

[Mike West]

Thanks.

https://github.com/WICG/trust-token-api/blob/main/PST_VS_PAT.md#privacypass-version
suggests that the privacypass versioning concern that Apple raised in
https://github.com/WebKit/standards-positions/issues/72#issuecomment-1279177030
will be mitigated through the protocol solidifying nowish, followed by
y'all updating the private state tokens to match. Given
https://datatracker.ietf.org/wg/privacypass/documents/, it looks like
things are generally stable and proceeding to WG last call. Have y'all
considered adopting the final version of the protocol prior to shipping?
That would avoid the necessity of a future migration, and remove one avenue
of objection others might have.

Regarding Mozilla, they deferred judgement on both this API and privacypass
(https://github.com/mozilla/standards-positions/issues/261) in 2020.
Pinging those threads might be helpful in soliciting an opinion that takes
the last 2+ years into account. :)

-mike


On Fri, Mar 17, 2023 at 8:29 PM Steven Valdez  wrote:

> Folks from Mozilla have done some recent analysis on the privacypass
> protocol and some supportive of the general protocol, however we haven't
> gotten any newer signals on whether the PST system where some sites are
> issuers and other sites redeem tokens is of interest to them. Apple has
> been pursuing Private Access Tokens, which is a version of privacypass with
> the device vendor acting as the issuing party.
>
> On Fri, Mar 17, 2023 at 12:46 PM 'Mike West' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> I'm quite excited to see this ready to ship, thanks for the work you've
>> put into it over the years.
>>
>> Both Mozilla and Apple's positions seem dependent upon analysis of the
>> underlying Privacy Pass protocol. Have you had additional communication
>> with them about how things are going, since it's been a while since the
>> initial request in both cases?
>>
>> -mike
>>
>> On Friday, March 17, 2023 at 5:35:06 PM UTC+1 Steven Valdez wrote:
>>
>>> Contact emails
>>>
>>> ayk...@google.com, sva...@chromium.org, kaust...@chromium.org
>>>
>>> Explainer
>>>
>>> https://github.com/WICG/trust-token-api
>>>
>>> NB: We'll rename the repository to private-state-token-api when it's
>>> adopted by the antifraud CG.
>>>
>>> Specification
>>>
>>> https://wicg.github.io/trust-token-api
>>>
>>> Design docs
>>>
>>>
>>> https://docs.google.com/document/d/1TNnya6B8pyomDK2F1R9CL3dY10OAmqWlnCxsWyOBDVQ/edit
>>>
>>> Summary
>>>
>>> The Private State Token API is a new API for propagating user signals
>>> across sites, without using cross-site persistent identifiers like third
>>> party cookies for anti-fraud purposes. Anti-fraud methods that rely on
>>> third party cookies will not work once third party cookies are deprecated.
>>> The motivation of this API is to provide a means to fight fraud in a world
>>> with no third party cookies. The API prevents cross-site identification by
>>> limiting the amount of information stored in a token. Blind signatures
>>> prevent the issuer from linking a token redemption to the identity of the
>>> user in the issuance context.
>>>
>>> Private State Token API does not generate or define anti-fraud signals.
>>> This is up to the corresponding first party and the token issuers. The API
>>> enforces limits on the information transferred in these signals for privacy
>>> concerns. Private State Token API is based on the Privacy Pass protocol
>>> from the IETF working group
>>> <https://datatracker.ietf.org/wg/privacypass/about/>. It can be
>>> considered as a web-exposed form of the Privacy Pass protocols.
>>>
>>> The Private State Token API was formerly known as the Trust Token API.
>>> It is renamed to more accurately reflect its functionality.
>>>
>>> Blink component
>>>
>>> Internals>Network>TrustTokens
>>>
>>> NB: As a part of the process of renaming the Trust Token API to the
>>> Private State Token API, the blink component will also be renamed.
>>>
>>>
>>> TAG review
>>>
>>> https://github.com/w3ctag/design-reviews/issues/414
>>> https://github.com/w3ctag/design-reviews/issues/780
>>>
>>> TAG review status
>>>
>>> No concerns, aside from lack of clear interest from other browsers
>>>
>>> Risks
>>>
>>> Interoperability and Compatibility
>>>
>>> We intend to update the underlying cr

[blink-dev] Re: Intent to Ship: Private State Tokens API

['Mike West' via blink-dev]

I'm quite excited to see this ready to ship, thanks for the work you've put 
into it over the years.

Both Mozilla and Apple's positions seem dependent upon analysis of the 
underlying Privacy Pass protocol. Have you had additional communication 
with them about how things are going, since it's been a while since the 
initial request in both cases?

-mike

On Friday, March 17, 2023 at 5:35:06 PM UTC+1 Steven Valdez wrote:

> Contact emails
>
> ayk...@google.com, sva...@chromium.org, kaust...@chromium.org
>
> Explainer
>
> https://github.com/WICG/trust-token-api
>
> NB: We'll rename the repository to private-state-token-api when it's 
> adopted by the antifraud CG.
>
> Specification
>
> https://wicg.github.io/trust-token-api
>
> Design docs
>
>
> https://docs.google.com/document/d/1TNnya6B8pyomDK2F1R9CL3dY10OAmqWlnCxsWyOBDVQ/edit
>
> Summary
>
> The Private State Token API is a new API for propagating user signals 
> across sites, without using cross-site persistent identifiers like third 
> party cookies for anti-fraud purposes. Anti-fraud methods that rely on 
> third party cookies will not work once third party cookies are deprecated. 
> The motivation of this API is to provide a means to fight fraud in a world 
> with no third party cookies. The API prevents cross-site identification by 
> limiting the amount of information stored in a token. Blind signatures 
> prevent the issuer from linking a token redemption to the identity of the 
> user in the issuance context.
>
> Private State Token API does not generate or define anti-fraud signals. 
> This is up to the corresponding first party and the token issuers. The API 
> enforces limits on the information transferred in these signals for privacy 
> concerns. Private State Token API is based on the Privacy Pass protocol 
> from the IETF working group 
> . It can be 
> considered as a web-exposed form of the Privacy Pass protocols. 
>
> The Private State Token API was formerly known as the Trust Token API. It 
> is renamed to more accurately reflect its functionality.
>
> Blink component
>
> Internals>Network>TrustTokens
>
> NB: As a part of the process of renaming the Trust Token API to the 
> Private State Token API, the blink component will also be renamed.
>
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/414 
> https://github.com/w3ctag/design-reviews/issues/780
>
> TAG review status
>
> No concerns, aside from lack of clear interest from other browsers
>
> Risks
>
> Interoperability and Compatibility
>
> We intend to update the underlying cryptographic and token issuance 
> protocols to align with the eventual Privacy Pass standard. This will 
> affect compatibility with the small number of token issuers. Private State 
> Token API fetch requests include a token type and version field that 
> enables backward compatibility while allowing possible extensions for 
> future token types and versions. While we will have a standard 
> deprecation path of supporting multiple versions, we expect this to be 
> easier with this API as each issuer using this API will need to register to 
> become an issuer and will provide contact information as part of that 
> process. 
>
>
> Gecko: Defer 
>
> WebKit: Pending (https://github.com/WebKit/standards-positions/issues/72), 
> already shipping similar technology 
> https://developer.apple.com/news/?id=huqjyh7k (see PST vs. PAT 
>  for 
> more information about the differences in the technologies).
>
> Web developers: Positive 
>
> A limited set of developers provided feedback on Private State Tokens, 
> indicating that the tool was valuable for anti-fraud capabilities while 
> also acknowledging some utility challenges (1). Other developers also found 
> that Private State Tokens provided ability for authentication purposes (as 
> illustrated by its use in the Privacy Sandbox k-Anonymity Server) (2). 
>
> 1: 
> https://github.com/antifraudcg/meetings/blob/main/2022/yahoo-trust-token.pdf
>
> 2: 
> https://github.com/WICG/turtledove/blob/main/FLEDGE_k_anonymity_server.md#abuse-and-invalid-traffic
>
>
> Other signals:
>
> Ergonomics
>
> N/A
>
>
> Activation
>
> Using this feature requires spinning up a (or partner with an existing) 
> Private State Token issuer that can issue and verify trust tokens, which is 
> non-trivial. Verifying properties of the Signed Redemption Record or the 
> client signature requires additional cryptographic operations. It would be 
> beneficial to have server-side libraries that developers can use to help 
> make using this API easier. Sample code can be found at 
> https://github.com/google/libtrusttoken.
>
>
>
> Security
>
> N/A
>
>
> WebView application risks
>
> Does this intent deprecate or change behavior of existing APIs, such that 
> it has potentially high risk for Android WebView-based 

Re: [blink-dev] Intent to Implement and Ship: URLSearchParams.size

[Mike West]

LGTM3.

-mike


On Fri, Feb 24, 2023 at 6:40 AM Yoav Weiss  wrote:

> LGTM2
>
> On Thu, Feb 23, 2023 at 6:49 PM Mike Taylor 
> wrote:
>
>> LGTM1, simple ergonomic addition.
>> On 2/23/23 7:07 AM, Kenichi Ishibashi wrote:
>>
>> Contact emails ba...@chromium.org
>>
>> Explainer This is a small extension to URLSearchParams. Web developers
>> can use the `size` attribute to check whether there are any query
>> parameters in a URLSearchParams object.
>>
>> Specification https://url.spec.whatwg.org/#dom-urlsearchparams-size
>>
>> Summary
>>
>> Add a size getter to URLSearchParams. It's useful to check whether there
>> are any query parameters in a URLSearchParams object.
>>
>>
>> Blink component Blink
>> 
>>
>> TAG review Not applicable. The URL Standard is already updated.
>>
>> FYI, this isn't really a justification why TAG review shouldn't happen -
>> the TAG does review additions to existing specs. But no review is needed
>> because this is such a simple change, IMHO.
>>
>>
>> TAG review status Not applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> *Gecko*: No signal
>>
>> Not an official signal, but there is a patch up at
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1818269. But this is such a
>> small change, we don't need to request an official position.
>>
>>
>> *WebKit*: Positive (https://github.com/whatwg/url/pull/734)
>>
>> WebKit bug is here, https://bugs.webkit.org/show_bug.cgi?id=252749#c1
>> for anyone who is curious.
>>
>>
>> *Web developers*: Positive (https://github.com/whatwg/url/issues/163)
>>
>> *Other signals*:
>>
>> WebView application risks
>>
>> Debuggability An attribute can be suspected by DevTools and other tools.
>>
>> 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
>> 
>> ? Yes
>>
>> https://wpt.fyi/results/url/urlsearchparams-size.any.html?label=experimental
>> (to appear)
>>
>> Flag name N/A
>>
>> Requires code in //chrome? False
>>
>> Tracking bug
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1418374
>>
>> Estimated milestones
>>
>> M113
>>
>>
>> Anticipated spec changes
>> No.
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5197222754385920
>>
>> This intent message was generated by Chrome Platform Status
>> .
>> --
>> You received this message because you are subscribed to the Google Groups
>> "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to blink-dev+unsubscr...@chromium.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPLXX-_OFPuEo8etovj4_HdWgtwvy3QOxOm6XS1e75EVueVgEQ%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/6de08e84-36f1-ffbc-81f9-438f30761b5d%40chromium.org
>> 
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfUzr_CYqyHmbbAw7KEspe1ifM0pecj0%3DkTRv_hO%2Byo4Yw%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/CAKXHy%3Df6jpR3Z-enM44z-xBZ42aiZCQswUi01S%2B3OYV_6RLo8A%40mail.gmail.com.

Re: [blink-dev] Intent to remove: prefetch-src

[Mike West]

LGTM0 (I'm recused, as this has my name on it).

For a little more color, we accidentally shipped `prefetch-src` in M92 when
moving CSP parsing out of the renderer. The check in
https://chromium-review.googlesource.com/c/chromium/src/+/2839603/8/third_party/blink/renderer/core/frame/csp/csp_directive_list.cc#b402
wasn't replicated in the network stack, and none of our tests covered it
(since the flag was set to "experimental", so passing was expected).

We've since aligned with other vendors on an alternate approach
 that Noam aims to ship
separately. This approach should completely cover developers' current usage
of `prefetch-src` to gate outgoing request destinations, and do so
cross-browser, which would be nice.

Skimming through HTTP Archive results, my suspicion is that the 0.02%
number Noam quotes would be much lower if taken as a percentage of page
views. But even if they aren't, there's no user-visible breakage that
removing the `prefetch-src` directive would create. The impact of removal
is that pages using `prefetch-src` to prevent certain prefetch requests
would fail to do so. That impact will be mitigated when Noam ships the
other thing mentioned above (which, ideally, would happen in the same
release :) ).

 As Noam notes, we have positive feedback on that proposal from other
vendors, and it doesn't seem necessary to me to ask TAG whether we should
remove something that's been removed from the relevant spec after
discussion and agreement on an alternative.

Thanks!

-mike


On Wed, Feb 8, 2023 at 10:26 AM Noam Rosenthal 
wrote:

> (sending this again, previous email was lacking template & details)
>
>
> Primary eng (and PM) emails
>
> nrosent...@chromium.org
>
> mk...@chromium.org
>
>
> Summary
>
> Prefetch-src was never fully adopted, but was shipped by mistake in 2021
> (the flag was removed, Oops)
>
> We’ve since changed the spec, and the replacement is in development.
>
> Motivation
>
> See https://github.com/w3c/webappsec-csp/issues/563
>
> The motivation is to clean up CSP directives that are not in consensus/use.
>
> The new least-restrictive-directive method for prefetch-src requires less
> churn from developers and is accepted by other vendors.
>
> Interoperability and Compatibility Risk
>
> There are some pages (0.02%) out there that use prefetch-src, even though
> it was never officially shipped in any browser (but, as said before, was
> mistakenly shipped by Chrome in 2021). Those pages would not get the
> (partial) protection that prefetch-src gives: blocking a prefetch under
> certain conditions. When we ship Least Restrictive Directive
> , which had gained
> consensus,
>
> Firefox: Never implemented prefetch-src, positive on prefetch behavior
> alignment 
>
> Safari: positive to removal and prefetch behavior alignment
> 
>
> Note that webkit has recently implemented prefetch-src into their CSP
> parser, but they did not implement prefetch yet so that is hypothetical.
> They have confirmed that they are aligned with this change.
>
> Alternative implementation suggestion for web developers
>
> See https://chromestatus.com/feature/5553640629075968. Prefetch will by
> default be protected by default-src, and other directives can allow it
> (“least restrictive directive”). This would make protecting against
> exfiltration more transparent, not requiring a new directive for each type
> of way to fetch.
>
> Usage information from UseCounter
> 
>
> There is no UseCounter for prefetch-src. HTTP-Archive shows that responses
> that included prefetch-src in their CSP header amounted to 0.02% of all
> document requests.
>
> Entry on the feature dashboard 
>
> https://chromestatus.com/guide/edit/4607623783514112
>
> --
> 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/CAJn%3DMYZf5ZRWhsD1pnQBoN3Leq0WSt0nW1sTXp3mveR5ojWaNw%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 

Re: [blink-dev] Intent to Ship: View Transitions: single-page apps

[Mike West]

LGTM2.

That said, I'd note Mozilla's desire in the standards position thread to
couple this with the multi-page transition work. I agree with your position
that the two can be decoupled, and I don't see anything that screams
back-compat risk skimming through the followup issues that the TAG created.
I likewise don't see anything that jumps out at me as locking us into any
particular design for a declarative version of this mechanism as our
friends in the TAG have pointed towards.

Shipping this as an iterative step sounds like it satisfies some developer
interest, and give us valuable implementation experience that can inform
further development. Good luck landing it!

-mike


On Mon, Jan 23, 2023 at 10:19 PM Mike Taylor  wrote:

> LGTM1
>
> On 1/23/23 2:26 PM, Khushal Sagar wrote:
>
>
>
> On Mon, Jan 23, 2023 at 1:55 PM Mike Taylor 
> wrote:
>
>> Hi Khushal,
>>
>> On 1/19/23 3:12 PM, Khushal Sagar wrote:
>>
>> Contact emails
>> bo...@chromium.org, hvanops...@chromium.org,  jakearchib...@chromium.org,
>> khushalsa...@chromium.org, vmp...@chromium.org
>>
>> Explainer
>>
>> https://github.com/WICG/view-transitions/blob/main/explainer.md
>> 
>>
>> Specification
>>
>> https://www.w3.org/TR/css-view-transitions-1
>>
>> Summary
>>
>> View Transitions
>>  is an
>> API that enables the creation of polished transitions. Web developers only
>> need minimal effort to make transitions look nice. They can choose to use
>> some default animation properties, or they can customize their own
>> transition effects to achieve a desired transition experience.
>>
>> This is accomplished by leveraging user-agents’ ability to persist visual
>> representations of rendered output (i.e. snapshots) and blend them with the
>> live DOM state’s rendered output. The API also allows these animations to
>> be customized via standard CSS animation properties.
>>
>> Note that while this intent is limited to shipping an API for
>> same-document transitions (i.e. by using document.startViewTransition, as
>> outlined in the spec), there is ongoing work to provide this feature for
>> same-origin, cross-document navigations (MPA). MPA support will be added as
>> a follow up via a separate intent to ship.
>>
>> Blink component
>>
>> Blink>ViewTransitions
>> 
>>
>> TAG review
>>
>> https://github.com/w3ctag/design-reviews/issues/748
>>
>> Can you confirm that all the follow-up issues
>> 
>> filed in response to feedback in this review are backwards-compatible with
>> what you propose to ship now?
>>
>
> Yes, most follow-up issues filed based on TAG feedback are about
> transitions initiated from navigations. This is part of the MPA work which
> we plan to ship as a follow up and it can be shipped independently of the
> same-document transitions covered by this intent.
>
> The only issue on that review which concerns same-document transitions is
> #8319 , a syntax which
> would allow selecting a subset of generated pseudo-elements. This syntax
> addition can be made in a backwards-compatible way.
>
> Thanks, SGTM.
>
>
>> TAG review status
>>
>> Pending
>>
>> Risks
>> Interoperability and Compatibility
>>
>> Low. As a new feature, the primary risk is that other browsers do not
>> implement it. But since this is a progressive enhancement, sites should be
>> able to feature-detect and drop usage of the feature easily in browsers
>> where it is not supported without breaking any site functionality.
>>
>> This feature can be feature-detected by checking the existence of the
>> document.startViewTransition function:
>>
>> ```js
>>
>> if (!document.startViewTransition) {
>>
>>   /* feature is not available */
>>
>> } else {
>>
>>   /* start transition */
>>
>> }
>>
>> ```
>>
>> Gecko: Under consideration (
>> https://github.com/mozilla/standards-positions/issues/677)
>>
>> WebKit: No signal (
>> https://github.com/WebKit/standards-positions/issues/48)
>>
>> Web developers: Strongly positive interest in and developer
>> experimentation with the API:
>>
>>-
>>
>>Updated developer.chrome article (Twitter)
>>
>>-
>>
>>News about the new SET API (Twitter)
>>
>>-
>>
>>Dev-built demo using SET (Twitter)
>>
>>-
>>
>>I/O Session (Youtube )
>>-
>>
>>Dev-built demo using SET (Reddit)
>>
>> 
>>
>>-
>>
>>Dev-built demo using SET (Twitter)

Re: [blink-dev] Intent to Ship: Network State Partitioning

[Mike West]

LGTM3.

Thanks for your close collaboration with the security team here; I think
the compromise you landed on is both reasonable and good.

-mike


On Mon, Dec 12, 2022 at 8:13 PM Chris Harrelson 
wrote:

> LGTM2
>
> On Fri, Dec 2, 2022 at 1:33 AM Yoav Weiss  wrote:
>
>> LGTM1
>>
>> Thanks for working on this compromise between our security/privacy needs
>> and our performance goals!!
>>
>> On Thu, Dec 1, 2022 at 9:38 PM 'Brianna Goldstein' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> Contact emails
>>>
>>> brgoldst...@chromium.org, mme...@chromium.org, a...@google.com,
>>> miketa...@chromium.org
>>>
>>> Explainer
>>>
>>>
>>> https://github.com/MattMenke2/Explainer---Partition-Network-State/blob/main/README.md
>>>
>>> Specification
>>>
>>> https://fetch.spec.whatwg.org/#connections
>>>
>>> Summary
>>>
>>> Partition network state by the network partition key to protect against
>>> cross-site tracking through the use of side channels. The network partition
>>> key consists of the schemeful site of the top level frame and a boolean
>>> indicating if the request is coming from a cross-site iframe. "Network
>>> State" here includes connections (H1, H2, H3, websocket), the DNS cache,
>>> ALPN/H2 support data, TLS/H3 resumption information, Reporting/NEL
>>> configuration and uploads.
>>>
>>> Unpartitioned network state allows for side-channel timing attacks,
>>> where one site can figure out if another has been visited recently. For
>>> example, if the connection is made quickly, it may be assumed that a
>>> connected socket exists. It also allows for third parties to track users
>>> across first party contexts they are loaded in using a variety of
>>> techniques (tracking socket reuse, using per-user alternative service
>>> advertisements, etc).
>>>
>>> Our initial attempt to partition the network state re-used the triple
>>> key partition scheme that was shipped for the HTTP cache
>>> . This included the
>>> schemeful sites of the top-level frame and the iframe. However, in an
>>> attempt to land a favorable balance between (1) the performance benefits of
>>> shared resources, and (2) the privacy promises of ensuring sites are safely
>>> prevented from gaining information about a user’s browsing habits, this new
>>> partition key consists of the top level site and a boolean indicating if
>>> the request is coming from a cross-site iframe.
>>>
>>> Partitioning may reduce Chromium’s ability to reuse network resources.
>>> We’ve enabled network state partitioning in a 1% experiment on Stable. From
>>> our experiments, Android navigation times to first contentful paint are
>>> increased by around 0.35% at the 50th percentile and 0.17% at the 99th
>>> percentile. Cross-site iframe navigation time to first contentful paints is
>>> increased by 2.85% at the 50th percentile and 1.35% at the 99th percentile.
>>> This represents about a 40 ms increase at the 50th percentile. On desktop,
>>> navigation times to first contentful paint are increased by around 1.00% at
>>> the 50th percentile (approximately a 10 ms increase) and have no impact on
>>> the 99th percentile. For cross-site iframes, the navigation times to first
>>> contentful paint are increased by 1.84% at the 50th percentile and 2.05% at
>>> the 99th percentile.
>>>
>>
>> The numbers still don't make me leap of joy, but they are
>> significantly more reasonable than the previous iteration.
>> I'm curious about the p75 numbers, but assuming they are somewhere in
>> between, that probably won't change the outcome.
>>
>> I wonder if speculative preconnection using the right key could have
>> bought back some of this. I similarly wonder if it could've been safe to
>> somehow publish speculative congestion windows to get rid of slow start in
>> those cases.
>> But obviously, none of this is a blocker to shipping this. Just ideas for
>> winning back some of the losses (that may enable stricter partitioning if
>> they actually work)
>>
>> +Kenji Baheux  - FYI
>>
>>
>>>
>>> Explainer:
>>> https://github.com/MattMenke2/Explainer---Partition-Network-State/blob/main/README.md
>>>
>>> Review of partitioning design options:
>>> https://docs.google.com/document/d/1UPjO44CMekDDXIKlih570Z6SOvKQnWzKoDe7APN_GHg/edit
>>>
>>> Blink component
>>>
>>> Internals>Network
>>> 
>>>
>>> TAG review
>>>
>>> https://github.com/w3ctag/design-reviews/issues/596
>>>
>>> TAG review status
>>>
>>> Issues addressed
>>>
>>> Risks
>>> Interoperability and compatibility
>>>
>>> This proposal partitions the DNS cache and connections, which could
>>> result in longer load times when previously reusable resources can no
>>> longer be reused. The performance impact will likely be most visible in
>>> cross-site iframes.
>>>
>>> Chromium's implementation partitions state by top-level site and a
>>> boolean flag indicating if the frame site is cross-site to the 

Re: [blink-dev] Intent to Implement and Ship: CSS pseudo-class ":picture-in-picture"

[Mike West]

LGTM2, for the same reason.

That said, there are a number of open bugs against the repository. Have you
done any triage against them to see whether any might be compatibility
issues in the future?

-mike


On Wed, Dec 7, 2022 at 9:51 AM Yoav Weiss  wrote:

> I think that reviving this 3.5 years later warrants getting LGTMs again,
> as the landscape may have changed.
>
> With that said, *LGTM1*, as it seems this would now be catching up with
> Safari.
>
> On Wed, Dec 7, 2022 at 8:00 AM 'François Beaufort' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Originally planned[1] to be shipped in Chrome 76, the
>> ":picture-in-picture" CSS pseudo-class was disabled[2] in the same
>> milestone as we thought we may need to revisit the design based on new
>> features coming into the Picture-in-Picture API.
>>
>> This is not the case anymore. For this reason we'll ship it in Chrome 110.
>>
>> Note that the ":picture-in-picture" CSS pseudo-class has been implemented
>> by Safari[3] since.
>>
>> [1]
>> https://chromiumdash.appspot.com/commits?commit=eb334058998fda433c4c910bf36d665082b30434
>> [2]
>> https://chromiumdash.appspot.com/commits?commit=ac1159c89f4a93414d477fc47548afa563b0c612
>> [3]
>> https://wpt.fyi/results/picture-in-picture/css-selector.html?label=experimental=master
>>
>> On Thursday, May 2, 2019 at 4:29:47 PM UTC+2 Chris Harrelson wrote:
>>
>>> On Thu, May 2, 2019 at 12:38 AM  wrote:
>>>
 Thank you. See answer inline.

 On Friday, April 26, 2019 at 10:25:10 PM UTC+2, Daniel Bratell wrote:
>
> LGTM3
>
> /Daniel
>
> On Fri, 26 Apr 2019 20:57:25 +0200, Yoav Weiss  wrote:
>
> LGTM2
>
> On Fri, Apr 26, 2019 at 8:37 PM Chris Harrelson 
> wrote:
>
>> Great!
>>
>> LGTM1
>>
>> Would be good to also have a WPT test exercising the absence of
>> retargeting, if there isn't already.
>>
>
 I've added one.

>>>
>>> Thanks!
>>>
>>>


>
>> On Fri, Apr 26, 2019 at 9:53 AM 'Mounir Lamouri' via blink-dev <
>> blin...@chromium.org> wrote:
>>
>>> The Picture-in-Picture spec has been updated.
>>>
>>> On Thu, 25 Apr 2019 at 07:46, Daniel Bratell 
>>> wrote:
>>>
 Looks like nobody responded. Maybe mlamouri can take a look?

 /Daniel

 On Thu, 18 Apr 2019 10:32:49 +0200, François Beaufort <
 beaufort...@gmail.com> wrote:

 Thank you everyone for your feedback and answers!

 I'm sending a spec PR at
 https://github.com/WICG/picture-in-picture/pull/126 that removes
 retargeting.
 I'll also pinging fullscreen spec owners at
 https://github.com/whatwg/fullscreen/issues/149.

 On Wed, Apr 17, 2019 at 7:03 PM Chris Harrelson <
 chri...@chromium.org> wrote:

> (API owner hat off in this response)
>
> I don't think that :picture-in-picture should automatically apply
> to the shadow host chain (*). I suggest removing retargeting from 
> that spec
> and also for the spec definition of :fullscreen.
>
> Rune's suggestion about using :part also makes sense to me.
>
> Chris
>
> (*) Posted some thoughts at
> https://github.com/w3c/webcomponents/issues/804
>
> On Wed, Apr 17, 2019 at 2:45 AM Rune Lillesveen <
> fut...@chromium.org> wrote:
>
>> On Thu, Mar 28, 2019 at 3:22 PM Emilio Cobos Álvarez <
>> emi...@mozilla.com> wrote:
>>
>>> I don't think such behavior makes sense for :fullscreen (nor for
>>> :picture-in-picture). For example, the fullscreen spec defines an
>>> user-agent stylesheet[1] that would break the layout of any
>>> shadow host
>>> containing the fullscreen element if such a thing was
>>> implemented. I
>>> don't think that's desirable nor makes much sense.
>>>
>>> Also, it doesn't seem to make much sense to me to match
>>> :fullscreen for
>>> some shadow host that has arbitrary content apart of the
>>> fullscreen
>>> element, but maybe I could be convinced otherwise?
>>
>>
>> Yes, wouldn't that be targeted more naturally with ::part?
>>
>> E.g.:  movie-app::part(video):fullscreen {}
>>
>> Note: Apparently, :fullscreen doesn't work with ::part() in
>> Blink. Reported https://crbug.com/953648
>>
>> --
>> 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 blin...@chromium.org.
>> To view this discussion on the web visit
>> 

Re: [blink-dev] Intent to Ship: Resizable ArrayBuffer and growable SharedArrayBuffer

[Mike West]

LGTM2.

-mike


On Wed, Nov 23, 2022 at 4:06 AM Yoav Weiss  wrote:

>
>
> On Tue, Nov 22, 2022 at 6:54 PM Marja Hölttä  wrote:
>
>> Thanks for the LGTM!
>>
>> Re: "wouldn't the userland name win" - typically the situation is more
>> complicated than that. E.g., one part of the user code marks objects by
>> adding a property 'foo' and another part checks whether my_object.foo !=
>> undefined. If we now add 'foo' somewhere in the prototype chain, this logic
>> breaks: it will think that an unmarked object is actually marked. -> Adding
>> properties like this can break user code in arbitrary ways.
>>
>
> Yeah, makes sense!
>
>
>>
>>
>> On Tue, Nov 22, 2022 at 2:37 PM Yoav Weiss 
>> wrote:
>>
>>> LGTM1
>>>
>>> On Tue, Nov 22, 2022 at 2:14 PM Marja Hölttä  wrote:
>>>
 Other engines: At least Apple has started implementing this feature,
 but this is a big feature, so it'll take some time. We've pushed for
 test262 coverage, so hopefully getting the feature into production will
 take less time for them than it did for us.

 Web sites can feature-detect this feature, e.g., by checking the
 existence of ArrayBuffer.prototype.resize and
 SharedArrayBuffer.prototype.grow.

 The potential backwards compatibility problem is the names 'resize' and
 'grow' colliding. This can always happen when adding new methods, although
 the risk here is lower than w/ adding methods to Array.prototype. Based on
 the past, we won't find out about such problems until we ship.

>>>
>>> In case of such a collision, wouldn't the userland name win?
>>> I guess we could run e.g. ClusterTelemetry with that change and see if
>>> the usecounters are hit (or something similar), just to be extra cautious.
>>>
>>>


 On Mon, Nov 21, 2022 at 1:56 PM Yoav Weiss 
 wrote:

>
>
> On Fri, Nov 18, 2022 at 1:59 PM Marja Hölttä 
> wrote:
>
>> Contact emailsma...@chromium.org, s...@chromium.org
>>
>> Explainer
>> https://github.com/tc39/proposal-resizablearraybuffer/blob/master/README.md
>>
>> Specificationhttps://tc39.es/proposal-resizablearraybuffer/
>>
>> Summary
>>
>> Extend the ArrayBuffer constructors to take an additional maximum
>> length that allows in-place growth and shrinking of buffers. Similarly,
>> SharedArrayBuffer is extended to take an additional maximum length that
>> allows in-place growth.
>>
>>
>> Blink componentBlink>JavaScript>Language
>> 
>>
>> TAG review
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> Interop risk exists in that resizing and growing the backing store,
>> as well as reserving the initial virtual memory, are platform and
>> OS-dependent. To that end the spec draft recommends implementation
>> guidelines:
>> https://tc39.es/proposal-resizablearraybuffer/#sec-maxbytelength-guidelines
>>
>>
>> *Gecko*: Positive (
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1670026) Assumed
>> positive because this proposal is Stage 3 in TC39.
>>
>> *WebKit*: Positive Assumed positive because this proposal is Stage 3
>> in TC39.
>>
>
> Do you know what their shipping plans are? Otherwise, what's the
> backwards compat story? Is there feature detection for this new 
> capability?
>
>
>>
>> *Web developers*: No signals
>>
>> *Other signals*: -
>>
>> Security
>>
>> ArrayBuffers and TypedArrays are a leading vector of attack. The
>> feature has been designed to be implementable with a fixed data pointer 
>> to
>> the backing store. See
>> https://github.com/tc39/proposal-resizablearraybuffer#security The
>> security review has been done by the V8 Security team.
>>
>>
>> WebView application risks
>>
>> -
>>
>>
>>
>> Debuggability
>>
>> DevTools can already debug ArrayBuffers and SharedArrayBuffers.
>>
>>
>> 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
>> 
>> ?Tested by test262
>>
>> Flag name--harmony-rab-gsab
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://bugs.chromium.org/p/v8/issues/detail?id=1
>>
>> Estimated milestones
>>
>> M110
>>
>>
>> Anticipated spec changes
>>
>> Included in the proposal's spec
>>
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/4668361878274048
>>
>> This intent message was generated by Chrome 

Re: [blink-dev] Intent to Ship: TLS ClientHello extension permutation

[Mike West]

LGTM1, modulo surprises in the standards positions feedback.

This is clearly a security-positive change, insofar as it preserves our 
ability to make changes to TLS over time. I expect you'll need a careful 
rollout (and that middleboxes will cause problems), but I also expect you 
know that already. :)

Good luck!

-mike

On Friday, November 18, 2022 at 10:12:21 PM UTC+1 Yoav Weiss wrote:

> No worries :) thanks for filling out those requests for positions
>
> On Fri, Nov 18, 2022, 21:04 David Adrian  wrote:
>
>> Apologies---this is my first time going through the Blink process, but I 
>> should have caught the formal signal step.
>>
>> I've filed requests for positions from Mozilla [1] and WebKit [2].
>>
>> [1] https://github.com/mozilla/standards-positions/issues/709
>> [2] https://github.com/WebKit/standards-positions/issues/92
>>
>> On Thu, Nov 17, 2022 at 7:15 PM Yoav Weiss  
>> wrote:
>>
>>>
>>>
>>> On Fri, Nov 18, 2022 at 1:28 AM Martin Thomson  wrote:
>>>


 On Fri, Nov 18, 2022 at 10:15 AM 'David Adrian' via blink-dev <
 blink-dev@chromium.org> wrote:

>
> *Gecko*: Positive (
> https://groups.google.com/a/chromium.org/g/blink-dev/c/zdmNs2rTyVI/m/MAiQwQkwCAAJ
> ) https://bugzilla.mozilla.org/show_bug.cgi?id=1789436
>

 To be clear, though we are supportive of this change, we ask that you 
 ask using https://github.com/mozilla/standards-positions rather than 
 use inferences (even obvious ones) based on mailing list posts.  Dennis is 
 the authority here, so no big deal, but this process exists to avoid 
 miscommunication.

>>>
>>> What Martin said + can you ask for a signal from WebKit folks? 
>>>
 -- 
 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/CAPLxc%3DVRR-R%2B1tDJELZvqDPENxcT%2Bi-OZntifmqsZOHkyGzHOg%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/bb1178e8-4eeb-44e7-8851-c5389eefd280n%40chromium.org.

Re: [blink-dev] Re: Intent to Ship: Cookies Having Independent Partitioned State (CHIPS)

[Mike West]

LGTM1.

I think the loss of the domain restriction is quite unfortunate, but I 
understand why you landed on that as the simplest path for deployment. My 
feeling is that folks are going to have to rework things in any event, and 
this would be an opportune time to revisit same-site-but-cross-origin 
cookie access within partitions to make the eventual work to align cookies 
with the origin model easier in the future. At the same time, I recognize 
that that's a problem that's not made any worse by shipping this feature, 
and I'll defer to y'all on the short-term deployment tradeoffs.

On the issues, I'd appreciate y'all taking another pass through to make 
sure there aren't any decisions lurking in the tracker that will be hard to 
revisit once we ship. I'd also appreciate you finalizing the resolution to 
https://github.com/privacycg/CHIPS/issues/40, which looks like there's 
still some ongoing discussion. That's the only issue I saw in a very quick 
pass that looked like it clearly required resolution before shipping, but 
y'all are more familiar with the conversations on the topic than I am. :)

Thanks!

-mike

On Friday, November 11, 2022 at 6:12:10 PM UTC+1 Mike Taylor wrote:

> On Friday, November 11, 2022 at 10:22:41 AM UTC-5 Mike Taylor wrote:
>
>> Unless we consider Cookie Store to be a normative requirement of CHIPS 
>> (and I don't think we do), that doesn't seem like a great outcome. Can I 
>> ask what WPT is missing to be able to write these tests in a cross-browser 
>> fashion? A better outcome would be to add the missing functionality to WPT 
>> itself.
>>
>
> After looking at the failing test in question, I see that you're testing 
> that CookieStore can correctly handle a partitioned cookie. Maybe that test 
> should live in the cookie-store directory as follow-up work, but a quick 
> workaround to feature-detect like you described seems fine for now.
>

-- 
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/c54a9e36-2a77-4a13-8453-3a0aeb1f316an%40chromium.org.

Re: [blink-dev] Intent to Ship: web-share permission policy

[Mike West]

LGTM3.

-mike

On Friday, November 18, 2022 at 4:24:43 PM UTC+1 Mike Taylor wrote:

> LGTM2. I think we should expect some compat issues with this change, but 
> they're currently the ones experienced by Safari and Firefox:
>
> https://github.com/jsbin/jsbin/issues/3485
> https://github.com/webcompat/web-bugs/issues/105859
> https://bugzilla.mozilla.org/show_bug.cgi?id=1737541 (see bugs in "See 
> also")
>
> Do we have any plans to make the developer community aware of the need to 
> delegate web-share permission to iframes now? Maybe a blog post in the 
> works?
>
> On 11/18/22 4:25 AM, Yoav Weiss wrote:
>
> LGTM1
>
> Thanks for catching us up here! :)
>
> On Thu, Nov 17, 2022 at 11:18 PM Eric Willigers <
> ericwillig...@chromium.org> wrote:
>
>> Contact emails
>> ericwillig...@chromium.org, fin...@chromium.org
>>
>> Explainer
>> https://github.com/w3c/web-share/blob/master/docs/explainer.md
>>
>> Specification
>> https://w3c.github.io/web-share/#permissions-policy
>>
>> Summary
>> A new permission policy, "web-share", controls access to 
>> navigator.share().
>>
>> The default allowlist is 'self', avoiding possible abuse by third party 
>> iframes.
>> Link to blink-dev discussion
>>
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/fgme9KOd8CU/m/TCYPKQAXAwAJ
>>
>> Blink component
>> Blink>WebShare 
>> 
>>
>> TAG review
>> Not needed, trivial change to existing spec
>>
>
> A better reasoning would be that we're aligning to shipped behavior in 
> other engines.
>  
>
>>
>> TAG review status
>> Not applicable
>>
>>
>> Risks
>>
>> Interoperability and Compatibility 
>>
>> navigator.share() is called by embedded iframes. These may expect share() 
>> calls to succeed, when now they will fail if permission has not been 
>> granted.
>>
>> Firefox has successfully shipped the feature.
>>
>> Failures were observed with YouTube, these have now been addressed. 
>>
>>
>>
>> Gecko: Shipped/Shipping (https://github.com/w3c/web-share/pull/252)
>>
>> WebKit: Shipped/Shipping (https://github.com/w3c/web-share/issues/169) 
>> CL recently merged: 
>> https://github.com/WebKit/WebKit/commit/ded7a6094a6ca38833e63a7915b7b6a2832f5734
>>
>> Web developers: No signals
>>
>> Other signals:
>>
>> WebView application risks 
>>
>> Does this intent deprecate or change behavior of existing APIs, such that 
>> it has potentially high risk for Android WebView-based applications?
>>
>> N/A - Web Share API is not enabled in WebView.
>>
>>
>> Debuggability
>> No DevTools changes needed.
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac, 
>> Linux, Chrome OS, Android, and Android WebView)?
>>
>> No
>>
>> The Permissions Policy will be supported on all platforms that support 
>> Web Share API. Currently, this is Android, Chrome OS, Windows.
>>
>> Is this feature fully tested by web-platform-tests 
>> 
>> ?
>> Yes
>>
>> Flag name
>>
>> Requires code in //chrome?
>> False
>>
>>
>> Tracking bug
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1079104
>>
>> Sample links
>> https://scrawny-bottlenose-somersault.glitch.me/share-from-iframes.html
>>
>> Estimated milestones
>> M110
>>
>> Anticipated spec changes
>>
>> -
>>
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/6362499966304256
>>
>>
>> This intent message was generated by Chrome Platform Status 
>> .
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to blink-dev+unsubscr...@chromium.org.
>> To view this discussion on the web visit 
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e4303ef1-c709-4f90-b97b-e2fc4b0f2e2bn%40chromium.org
>>  
>> 
>> .
>>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to blink-dev+unsubscr...@chromium.org.
>
> To view this discussion on the web visit 
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfV%3DC7ac0_gk89v7sG8X3kyOSxN%3DFH0i2DpCQ2iYrweDzw%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 

Re: [blink-dev] Intent to Prototype: Incoming Call Notifications

[Mike West]

The explainer mentions some security/privacy concerns, but I think it
underestimates the risk. Notifications are widely abused today, and various
teams are involved in cleaning up various bits of the ecosystem. This seems
like it could be a step back if we're not careful about the way we build
it, so I'd encourage you to work with folks in this space to mitigate
abuse. Perhaps this is a good conversation to have at the upcoming
Permissions Workshop (
https://www.w3.org/Privacy/permissions-ws-2022/schedule)?

-mike


On Thu, Nov 17, 2022 at 10:49 AM Peter Beverloo  wrote:

> +Rayan Kanso  and @Peter Conn 
>
> We've been working with Gabriel & team on the proposal and are supportive
> of prototyping this functionality :)
>
> Thanks,
> Peter
>
>
> On Wed, Nov 16, 2022 at 8:20 PM Rick Byers  wrote:
>
>> Sounds cool to me from a web API perspective!
>>
>> You'll of course need approval from relevant code OWNERS to land patches
>> in this space, looks
>> 
>> like that's probably mainly +Peter Beverloo ? Any
>> concerns Peter?
>>
>> Thanks,
>>Rick
>>
>> On Tue, Nov 15, 2022 at 8:12 PM 'Gabriel Brito' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> Contact emails
>>>
>>> gabrielbr...@microsoft.com, stev...@microsoft.com
>>>
>>> Explainer
>>>
>>>
>>> https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Notifications/notifications_actions_customization.md
>>>
>>> Summary
>>>
>>> Extend the Notifications API to allow installed PWA's to send incoming
>>> call notifications - i.e., notifications with call-styled buttons and a
>>> ringtone. This extension will help VoIP web apps to create more engaging
>>> experiences by making it easier for users to easily recognize a calling
>>> notification and answer it. Besides that, this feature will help bridge the
>>> gap between native and web implementations of apps that have them both.
>>>
>>>
>>> Blink component
>>>
>>> UI>Notifications
>>> 
>>>
>>> Motivation
>>>
>>> Incoming calls are events that require an immediate response. However,
>>> VoIP web applications that need to notify the user about an incoming call
>>> via the Notifications API, can only issue a regular notification that will
>>> show up in the action/notification center without any clear
>>> differentiation. Other options include each application implementing its
>>> own in-app notification system, which will only issue notifications inside
>>> the app window. This extension to the Notifications API standard for
>>> incoming call scenarios will allow web applications to send notifications
>>> with colored action buttons and a ringtone, which should have increased
>>> priority if allowed by the platform.
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>>
>>> *Gecko*: No signal
>>>
>>> *WebKit*: No signal
>>>
>>> *Web developers*: No signals
>>>
>>> *Other signals*:
>>>
>>> WebView application risks
>>>
>>> *Does this intent deprecate or change behavior of existing APIs, such
>>> that it has potentially high risk for Android WebView-based applications?*
>>>
>>> The Notification API is not supported in WebView. Therefore, there are
>>> no WebView risks.
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?
>>>
>>> No
>>>
>>>
>>> Requires code in //chrome?
>>>
>>> True
>>>
>>> Tracking bug
>>>
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1383570
>>>
>>> Estimated milestones
>>>
>>> M111
>>>
>>>
>>> Link to entry on the Chrome Platform Status
>>>
>>> https://chromestatus.com/feature/5110990717321216
>>>
>>> This intent message was generated by Chrome Platform Status
>>> .
>>>
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "blink-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to blink-dev+unsubscr...@chromium.org.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/BY5PR00MB0824B2CEE0F7F1A4D4C65244D5079%40BY5PR00MB0824.namprd00.prod.outlook.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/CALt3x6nBiCQM5Xk8K4PWhXRf0an7WbGRaZgAm-_eqQ-RdFv4Hw%40mail.gmail.com
> 

Re: [blink-dev] Re: Ready for Trial: Quick intensive timer throttling of loaded background pages

[Mike West]

Hey Jiahe,

Can you summarize what you've learned from the 1% experiment? The design
doc isn't exactly clear on what y'all would consider "success" from an
experimental perspective, so I'd like to understand what you're evaluating.

I'm also curious about the hop from 1% to 50%. What do you expect to learn
from the 50:50 experiment that you're not learning from the 1%? We often do
incremental rollouts, ramping from 1% to 5% to 10% and so on, but I think
you could do that as part of an Intent to Ship, rather than extending this
experiment.

-mike


On Thu, Nov 3, 2022 at 11:57 AM Jiahe Zhang  wrote:

> We've been experimenting this on 1% Stable on M107 for weeks , and the
> results are quite encouraging.
> So I'd like to request a larger scope of experiments to 50% Stable. Please
> review.
>
> Best Regards,
> Jiahe
>
> On Tuesday, October 4, 2022 at 4:45:42 AM UTC+8 François Doray wrote:
>
>> Update: We ended up experimenting with M106+, because there was a bug in
>> the code in prior versions. The M106 Beta experiment has good results.
>> We'll start the 1% Stable experiment this week.
>>
>> On Tue, Aug 9, 2022 at 9:47 AM François Doray  wrote:
>>
>>> Thanks! I started the 1% Stable experiment. I will share an overview of
>>> the results in ~3 weeks.
>>>
>>> On Tue, Aug 9, 2022 at 4:21 AM Mike West  wrote:
>>>
>>>> IMO, this is somewhere on the border between a web-visible experiment
>>>> and a pure expression of user agent preference regarding flexibility
>>>> explicitly carved out in a standard.
>>>>
>>>> Rather than debating the feature's philosophical state, I'd simply
>>>> treat this email as an Intent to Experiment from M104 (current stable) to
>>>> M107, and give you an explicit LGTM.
>>>>
>>>> Additionally: it would be ideal for the experience you gather in this
>>>> experiment to fold back into the spec as an "Implementation Consideration"
>>>> that might help other implementers determine how to use the flexibility the
>>>> spec provides.
>>>>
>>>> -mike
>>>>
>>>>
>>>> On Fri, Aug 5, 2022 at 9:24 PM 'François Doray' via blink-dev <
>>>> blin...@chromium.org> wrote:
>>>>
>>>>> +Scott Haseley as an expert in this field.
>>>>>
>>>>> We would like to start experimenting with this intervention on 1%
>>>>> Stable very soon. We've been experimenting on 50% of Beta for almost 2
>>>>> months. The results are encouraging and we aren't aware of negative Web
>>>>> developer feedback. Do we need your LGTM to proceed?
>>>>>
>>>>> On Mon, Aug 1, 2022 at 3:45 AM Zhang, Jiahe 
>>>>> wrote:
>>>>>
>>>>>> Contact emails
>>>>>>
>>>>>> jiahe...@intel.com, fdo...@chromium.org
>>>>>>
>>>>>>
>>>>>> Specification
>>>>>>
>>>>>> https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html
>>>>>>
>>>>>>
>>>>>> Design docs
>>>>>>
>>>>>>
>>>>>>
>>>>>> https://docs.google.com/document/d/1WFyfKUUxqM7uKxKOGhLiOjyY6T7QRduVcuHN0f6vJkk/edit
>>>>>>
>>>>>>
>>>>>> Summary
>>>>>>
>>>>>> Enter Intensive Wake Up throttling after 10 seconds if the page is
>>>>>> fully loaded when it becomes hidden. Currently, wake ups from JS timers
>>>>>> with a nesting level >= 5 are throttled to 1 per minute after the page 
>>>>>> has
>>>>>> spent 5 minutes in the background [1], which is very conservative and was
>>>>>> chosen to allow a launch of Intensive Wake Up Throttling with minimal
>>>>>> regression risk. We're now planning to reduce this timeout to 10 seconds 
>>>>>> if
>>>>>> the page is fully loaded when hidden. [1]
>>>>>> https://chromestatus.com/feature/4718288976216064
>>>>>>
>>>>>>
>>>>>>
>>>>>> Blink component
>>>>>>
>>>>>> Blink>Scheduling
>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EScheduling>
>>>>>>
>>>>>>
>>>>>> TAG review
>>>>>>
>>>>>> Not applica

Re: [blink-dev] Intent to Ship: Send Mouse Events to Disabled Form Controls

[Mike West]

LGTM3

-mike


On Tue, Oct 25, 2022 at 3:32 PM Mike Taylor  wrote:

> LGTM2
>
> On 10/25/22 4:58 AM, Yoav Weiss wrote:
>
> LGTM1 for (almost) aligning with Gecko. Please file bugs to get us to full
> alignment.
>
> On Friday, October 21, 2022 at 12:22:16 AM UTC+2 Joey Arhar wrote:
>
>> > Is there a test that currently passes in Firefox which will start
>> passing in Chrome when we enable this?
>>
>> I just added a more specific and concise WPT for this change:
>> https://github.com/web-platform-tests/wpt/pull/36578
>> The test shows that the event propagation I'm proposing is almost
>> identical to firefox. The only exception is that firefox does not fire
>> pointerdown or pointerup on disabled form controls or their parents.
>> However, chrome already fires pointerup and pointerdown on those elements,
>> so I'm not worried about breaking anything there. You can see for yourself
>> by using jake's demo in chrome and firefox:
>> https://jakearchibald.com/2017/events-and-disabled-form-fields/
>> I believe that firefox would be ok with firing pointerup and pointerdown,
>> I'll ask them about that.
>>
>> > Also, can you ask for WebKit signals?
>>
>> https://github.com/WebKit/standards-positions/issues/78
>>
>> On Wed, Oct 19, 2022 at 9:00 AM Philip Jägenstedt 
>> wrote:
>>
>>> Will this match the behavior of Firefox exactly?
>>>
>>> Is there a test that currently passes in Firefox which will start
>>> passing in Chrome when we enable this?
>>> https://wpt.fyi/results/dom/events/Event-dispatch-click.html already
>>> passes and
>>> https://wpt.fyi/results/html/semantics/forms?label=pr_head=1=32381
>>> is a complex mix of pass/fail, is the expectation to match Firefox exactly?
>>>
>>> Also, can you ask for WebKit signals? A thumbs up on a HTML PR from the
>>> likely implementer would be a lightweight signal, and another option is
>>> https://github.com/WebKit/standards-positions.
>>>
>>> On Mon, Oct 17, 2022 at 6:15 PM Dave Tapuska 
>>> wrote:
>>>
 So the initial attempt was problematic for interop due to mouseup, and
 mousedown being displaced for the entire event path. I had removed my
 request to ship in order to address the concerns of other vendors (proposed
 another 3 milestones to collect more data). It appears this attempt does
 fix that by not dispatching them. I did not complete the analysis at the
 time due to changing priorities of projects. I am happy that Joey has
 spearheaded this work and do support this intent.

 dave.

 On Mon, Oct 17, 2022 at 8:33 AM Yoav Weiss 
 wrote:

>
>
> On Sun, Oct 16, 2022 at 12:08 AM Joey Arhar 
> wrote:
>
>> Contact emails jar...@chromium.org
>>
>> Specification https://github.com/whatwg/html/issues/2368
>> https://github.com/whatwg/html/issues/5886
>> No changes have been made to the spec yet, but if this launch goes
>> well then we will likely change the HTML spec to reflect this behavior.
>>
>> Summary
>>
>> This will make mouse events other than click, mouseup, and mousedown
>> become dispatched on disabled form controls instead of blocking them. It
>> will also stop propagating click, mouseup, and mousedown events to the
>> parents of disabled form controls when the event is targeted at a child 
>> of
>> a disabled form control, which is the same behavior that Firefox 
>> currently
>> has. A previous attempt at this was not shipped here:
>> https://chromestatus.com/feature/5685077795143680
>>
>
> Any details on why that past attempt didn't make it? Any compat issues
> encountered?
>
>
>> Here are the previous blink-dev threads:
>>
>>
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/rhNbsYDBJes/m/Jvmtv6IbBwAJ
>>
>>
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/KHXNJINUrj0/m/OAAh-sWuAwAJ
>>
>>
>> Blink component Blink>DOM
>> 
>>
>> TAG review None
>>
>> TAG review status Not applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> *Gecko*: Shipped/Shipping
>>
>> *WebKit*: No signal
>>
>> *Web developers*: Positive
>>
>> *Other signals*:
>>
>> Ergonomics
>>
>> This change will not be used in tandem with any other APIs. This
>> change will not affect Chrome's performance.
>>
>>
>> Activation
>>
>> This change will not be challenging for developers to take advantage
>> of.
>>
>>
>> Security
>>
>> I have no security concerns for this change.
>>
>>
>> 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
>>
>> I'm not aware of any 

Re: [blink-dev] Re: Intent to Ship: Cookies Having Independent Partitioned State (CHIPS)

[Mike West]

Thanks for the work you've put in through security and privacy review on
this feature. It's an important step towards our ability to remove
third-party cookie access, and I'm looking forward to seeing it used more
widely in the future as we continue down that path. That said, I have a few
thoughts:

1.  I'd be happier if we'd been able to keep the `__Host-`-like
restrictions on `Domain` and `Path` (even if not the prefix); that seems
like a missed opportunity, given that we're going to need to support CHIPS
into the indefinite future. The patch removing these requirements (
https://github.com/privacycg/CHIPS/pull/46) references discussion on a
PrivacyCG(?) call, but I wasn't able to find minutes. Could you help me
understand the rationale?

2. There are a few issues open against the spec that seem like they ought
to be resolved before shipping. https://github.com/privacycg/CHIPS/issues/58
, https://github.com/privacycg/CHIPS/issues/40, and
https://github.com/privacycg/CHIPS/issues/2 all seem like they would
benefit from explicit resolution. Do you think those ought to be considered
blockers?

-mike


On Thu, Oct 20, 2022 at 11:33 PM 'Dylan Cutler' via blink-dev <
blink-dev@chromium.org> wrote:

> *Estimated Milestone for Shipping:*
> 109
>
> Apologies, I included the OT milestones instead...
>
> On Thu, Oct 20, 2022 at 4:57 PM Dylan Cutler 
> wrote:
>
>> Contact emails:
>>
>> dylancut...@google.com, kaustub...@google.com
>>
>> Proposal repository:
>>
>> https://github.com/privacycg/CHIPS
>>
>> Design doc:
>>
>>
>> https://docs.google.com/document/d/1wL2lCXpaVOi0cWOn_ehfLFIZQxT3t0SH-ANnZYPEB0I/edit?usp=sharing
>>
>> Specification:
>>
>> https://datatracker.ietf.org/doc/draft-cutler-httpbis-partitioned-cookies/
>>
>> Summary:
>>
>> Given that Chrome plans to deprecate unpartitioned third-party cookies,
>> we want to give developers the ability to use cookies in cross-site
>> contexts that are partitioned by top-level site to meet use cases
>> 
>> that don't track users cross-site (e.g. SaaS embeds, headless CMS, sandbox
>> domains, etc.). Chrome will introduce a mechanism to opt into having
>> third-party cookies partitioned by top-level site using a new cookie
>> attribute, Partitioned.
>>
>> Since we announced our Intent to Experiment
>> 
>> with CHIPS, there have been some changes to the API:
>>
>>
>>-
>>
>>The Partitioned attribute no longer requires
>> the __Host- prefix or
>>its required attributes. The Secure requirement remains.
>>-
>>
>>We are changing the per-partition-per-domain limit to be based on the
>>total size (in bytes) of the cookies set by a domain in a particular
>>partition in addition to the number of cookies. We intend
>>
>>to impose a limit of 10 KB per-embedded-site, per-top-level-site and
>>increase the numeric limit from 10 to 180.
>>-
>>
>>For sites embedded in top-level domains that are in a First-Party Set
>>, their cookies' partition
>>key will no longer be the owner domain of that set. Rather, the partition
>>key will always be the top-level domain that the cookie was created on.
>>
>>
>> Blink component:
>>
>> Internals>Network>Cookies
>> 
>>
>> TAG review:
>>
>> https://github.com/w3ctag/design-reviews/issues/654 (Supportive early
>> review)
>>
>> https://github.com/w3ctag/design-reviews/issues/779 (Oct 19
>> specification review)
>>
>> Risks
>>
>> Interoperability and Compatibility
>>
>> Firefox: Positive 
>>
>> WebKit: Supported incubation
>> ,
>> Official position pending
>> 
>>
>> Web developers: Developers have indicated that CHIPS does solve for many
>> use cases that depend on access to cookies in cross-site contexts (1
>> , 2
>> , 3
>> ).
>> Through incubation, and the Origin Trial, we received feedback to improve
>> ease-of-use, particularly to allow for easier migration of existing systems
>> to use CHIPS. We believe we have satisfactorily resolved these concerns
>> (see changes made listed under Summary section).
>>
>> Other signals:
>>
>> Ergonomics
>>
>> N/A
>>
>>
>> Activation
>>
>> This feature introduces a new cookie attribute, Partitioned, which is
>> opt-in only. Sites which do not set 

Re: [blink-dev] Intent to Ship : HTTP response status code in Resource Timing

[Mike West]

LGTM1. Thanks for taking feedback around security concerns into account.

-mike


On Mon, Oct 24, 2022 at 4:55 AM Yoav Weiss  wrote:

> Amazing work!! Exciting stuff!
>
> (Recusing myself, as I was somewhat involved)
>
> On Fri, Oct 21, 2022 at 5:37 PM Abin Paul  wrote:
>
>> Contact emails
>>
>> abin.pa...@gmail.com
>>
>> Explainer
>>
>>
>> https://github.com/w3c/resource-timing/blob/gh-pages/Explainers/Response_Status_Code.md
>>
>> Specification
>>
>> Resource Timing PR : https://github.com/w3c/resource-timing/pull/335
>>
>> Fetch PR : https://github.com/whatwg/fetch/pull/1468
>>
>> HTML PR :https://github.com/whatwg/html/pull/8405
>>
>>
>> Summary
>>
>> Adds a field to PerformanceResourceTiming to indicate the HTTP response
>> status when the resource was fetched.
>>
>>
>> Blink component
>>
>> Blink>PerformanceAPIs>ResourceTiming
>> 
>>
>> TAG review
>>
>> https://github.com/w3ctag/design-reviews/issues/757
>>
>> TAG review status
>>
>> Issues addressed
>>
>> Risks
>>
>> Interoperability and Compatibility
>>
>> Gecko: Positive (
>> https://github.com/mozilla/standards-positions/issues/665)
>>
>> WebKit: No signal (
>> https://github.com/WebKit/standards-positions/issues/35)
>>
>> Web developers:
>>
>> Developer interest for the feature :
>> https://github.com/w3c/resource-timing/issues/90
>>
>> Other signals:
>>
>> Ergonomics
>>
>> No
>>
>>
>> Activation
>>
>> No risks
>>
>>
>> Security
>>
>> No risks
>>
>>
>> WebView application risks
>>
>> Does this intent deprecate or change behaviour of existing APIs, such
>> that it has potentially high risk for Android WebView-based applications?
>> No
>>
>>
>> Debuggability
>>
>> The new attribute shows up in Devtools. No implementation changes are
>> required.
>>
>> 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
>> 
>> ?
>>
>> Yes
>>
>>
>> https://wpt.fyi/results/resource-timing/response-status-code.html?label=experimental=master
>>
>> Flag name
>>
>> #enable-experimental-web-platform-features
>>
>> Requires code in //chrome?
>>
>> False
>>
>> Tracking bug
>>
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1337256
>>
>>
>> Non-OSS dependencies
>>
>> Does the feature depend on any code or APIs outside the Chromium open
>> source repository and its open-source dependencies to function?
>>
>> No
>>
>> Estimated milestones
>>
>> Chrome for desktop 109
>>
>> Chrome for Android 109
>>
>> Android Webview 109
>>
>>
>> Anticipated spec changes
>>
>> No ongoing discussion that could lead to future changes
>>
>>
>> Link to entry on the Chrome Platform Status
>>
>> https://chromestatus.com/feature/5163838794629120
>>
>> Links to previous Intent discussions
>>
>> Intent to prototype:
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM2ZH3ckNhJ%3DdQmoprkfVU%2Bt5akcUyK9f2%2Bi%3DMRis2TKx63Brg%40mail.gmail.com
>> 
>>
>>
>> This intent message was generated by Chrome Platform Status
>> .
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to blink-dev+unsubscr...@chromium.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM2ZH3dDHYs_m262dEUUWLkmSSip8N6AsuuXrVAW92R5xEJ71A%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/CAL5BFfV2YOmnqB1Lui61DqaQRKLfDPDpZvoWZmuJBQeqH_ZYKg%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/CAKXHy%3DfF8Kdn4beRnViyMOCnqPMMHXKja185ysB4_1Qr3GNLsg%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Align Timers (including DOM timers) at 125 Hz

[Mike West]

LGTM2.

-mike


On Mon, Oct 24, 2022 at 4:59 PM Mike Taylor  wrote:

> Thanks Etienne.
>
> LGTM1 to ship - good luck with the rollout.
>
> On 10/20/22 12:18 PM, Etienne Pierre-doray wrote:
>
> Have we asked Mozilla for a signal?
>
> I haven't asked for a signal. I can ask but this feels N/A; this change is
> Web facing but remains spec-compliant, and I don't think we want to change
> the spec or browsers need to align. Quoting a reply from Webkit "even if
> there were a web specification, and even if a browser faithfully tried to
> implement it, the web programmer would still not get the specified behavior
> on most hardware and operating systems most of the time."
> I should correct myself, asking for a position form WebKit actually
> yielded an invalid signal "The issue is not about a specification".
>
> On Thu, Oct 20, 2022 at 11:23 AM Mike Taylor 
> wrote:
>
>> On 10/19/22 8:05 PM, Etienne Pierre-doray wrote:
>>
>> Contact emails etien...@chromium.org
>>
>> Specification
>> https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html
>>
>> Design docs
>>
>> https://docs.google.com/document/d/1OjZoHNvn_vz6bhyww68B_KZBi6_s5arT8xMupuNEnDM/edit
>>
>> Summary
>>
>> Run all timers (with a few exceptions) with a non-zero delay on a regular
>> 8ms aligned wake up (125 Hz), instead of as soon as their delay has passed.
>> This affects DOM timers; On foreground pages, run DOM timers with a
>> non-zero delay on a regular 8ms aligned wake up, instead of as soon as
>> their delay has passed. On background pages, DOM timers already run on a
>> regular 1s aligned wake up (1 Hz), or even less frequently after 5 minutes.
>>
>>
>> Blink component Blink>Scheduling
>> 
>>
>> TAG review
>>
>> TAG review status Not applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> This feature changes the behavior of an existing API in a way that is
>> spec-compliant (the spec says "Optionally, wait a further
>> implementation-defined length of time", ref.:
>> https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#run-steps-after-a-timeout).
>> Content that relies on precise timing for DOM Timers may stop working
>> properly in Chromium with this feature. The risk is mitigated by delaying
>> DOM Timers by at most 8 ms. Content that cannot support a 8 ms delay would
>> probably be better served by alternative APIs described at
>> https://developer.chrome.com/blog/timer-throttling-in-chrome-88/#workarounds.
>> Due to the significant battery savings that come with this feature, we
>> expect that most browsers will decide to implement it after some time.
>>
>>
>> *Gecko*: No signal
>>
>> Have we asked Mozilla for a signal?
>>
>>
>> *WebKit*: Neutral (
>> https://github.com/WebKit/standards-positions/issues/44) Note that
>> WebKit already has some DOM timer alignment logic (see
>> Page::updateDOMTimerAlignmentInterval()), which depends on low power mode,
>> page visibility and user interaction. It's also possible that there's some
>> alignment logic at the platform level which is designed to reduce CPU
>> wakeups.
>>
>> *Web developers*: No signals
>>
>> *Other signals*:
>>
>> WebView application risks
>>
>> Does this intent deprecate or change behavior of existing APIs, such that
>> it has potentially high risk for Android WebView-based applications?
>>
>>
>> Debuggability
>>
>> This changes the behavior of an existing API. No new debugging support is
>> added.
>>
>>
>> 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
>>
>> DevTrial instructions
>> https://github.com/eti-p-doray/align-wakeups/blob/main/HOWTO.md
>>
>> Flag name align-wakeups
>>
>> Requires code in //chrome? False
>>
>> Tracking bug https://crbug.com/1153139
>>
>>
>> Estimated milestones
>> DevTrial on desktop 105
>> DevTrial on Android 105
>> Chrome on desktop 107
>> Chrome on Android 107
>>
>> 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).
>> This feature changes the behavior of an existing API in a way that is
>> spec-compliant
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5680188671655936
>>
>> Links to previous Intent discussions Intent to Experiment:
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALoDvsaQA8iqxdxNEh1PkBCzPFSsSSmZ72Jgmev-bdwenG6DrQ%40mail.gmail.com
>> 

Re: [blink-dev] Intent to Ship: Android OSK resizes visual viewport by default + opt-out

[Mike West]

LGTM3.

-mike


On Fri, Oct 7, 2022 at 4:56 AM Yoav Weiss  wrote:

> LGTM2 under the same conditions!
>
> On Fri, Oct 7, 2022 at 2:23 AM Mike Taylor  wrote:
>
>> I see that Emilio has approved
>> https://github.com/w3c/csswg-drafts/pull/7826, with a few suggestions.
>>
>> LGTM1 to ship w/ the review comments addressed and the PR landing (and
>> thanks for speccing it!).
>>
>> On 9/23/22 10:17 PM, David Bokan wrote:
>>
>> Contact emails
>>
>> bo...@chromium.org
>>
>> Explainer
>> https://github.com/bramus/viewport-resize-behavior/blob/main/explainer.md
>>
>> Specification
>> The resize behavior of the virtual keyboard is not specified.
>> The viewport meta tag is not yet fully specified
>> .
>> See also https://github.com/w3c/csswg-drafts/issues/7767.
>>
>> Summary
>> This intent:
>>
>>- Changes the Android virtual keyboard such that it resizes the visual
>>viewport only, rather than the current behavior of resizing the initial
>>containing block (ICB) and layout viewport (LVP).
>>- Ships support for a new meta-viewport key interactive-widgets which
>>can be used to opt-out of the above change, and instead retain the old
>>behavior.
>>
>>Example: >content=”interactive-widgets=resize-layout”>
>>
>>
>> *Motivation *Browsers do not currently agree on how the virtual keyboard
>> should interact with the viewport:
>>
>>-
>>
>>Chrome for Android and Firefox for Android both resize the initial
>>containing block and  layout viewport.
>>-
>>
>>Chrome for ChromeOS and Windows; and Safari/iOS both resize the visual
>>viewport only.
>>
>> This discrepancy is a source of frustration for authors [1]
>> 
>> [2]
>> 
>> [3]
>> 
>> [4] .
>> While both approaches have valid use-cases, we believe that resizing the
>> visual viewport is the best default, as it avoids any layout-jank from
>> opening the keyboard, and in general interferes with the page as little as
>> possible.
>>
>> Other vendors also have long-standing issues in this area:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1007286
>>
>> This intent improves interop for mobile viewports, a priority investigation
>> area for Interop 2022 . Mobile viewports
>> (especially the meta tag) are unfortunately not well specified, and we plan
>> to work on resolving CSSWG issue 7767
>>  in parallel with this
>> intent. In the meantime we plan to add this feature to the Compat spec
>> .
>>
>> Blink component
>> Blink>Scroll
>> 
>>
>> TAG review
>> N/A
>>
>> TAG review status
>> Not applicable
>>
>> Risks
>>
>> Interoperability and Compatibility
>>
>> The main risk with this change is web apps which critically depend on the
>> current LVP-resize behavior, e.g. a chat app with a message box fixed above
>> the keyboard.
>>
>> Those use-cases would no longer be possible with the default behavior,
>> and it was exactly this concern that stopped the previous attempt to
>> ship this behavior
>> 
>> at LGTM2.
>>
>> What makes this intent different:
>>
>>-
>>
>>The VirtualKeyboard API
>>
>>now exists, which exposes the geometry of the keyboard as CSS-reachable
>>environment variables allowing app full control over keyboard behavior.
>>-
>>
>>For an easier fix, a new  opt-out has been added which can be
>>used to maintain the current LVP-resize behavior. This is a trivial fix 
>> for
>>any affected web app.
>>
>> As there is no good way to detect the problematic cases with a
>> use-counter / HTTP Archive query, we must instead rely on developer
>> outreach to inform this change. That outreach will reference this intent,
>> and therefore the results of that will be provided in a follow-up e-mail.
>>
>> We expect this change to be a significant win for interop.
>>
>> *Signals:*
>>
>> Gecko: No response yet[standards position
>> ] (Some
>> non-official positive signals from Mozilla engineers from discussions at
>> TPAC and in 7767
>> 
>> that Firefox could make this change)
>>
>> WebKit: No response yet [standards position
>> 

Re: [blink-dev] Intent to Experiment: Network State Partitioning (once more, with feeling)

[Mike West]

You've got your LGTM already, but I'll double-LGTM it just to say that I
appreciate the care you're putting into gathering data to support the
decisions we make here. Thank you.

-mike


On Wed, Oct 5, 2022 at 10:01 AM Yoav Weiss  wrote:

> LGTM for a 1% stable experiment
>
> On Wed, Oct 5, 2022 at 12:20 AM Mike Taylor 
> wrote:
>
>> *Contact emails*
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> * brgoldst...@chromium.org ,
>> miketa...@chromium.org , mme...@chromium.org
>>   Summary We would like to run another experiment for
>> the Network State Partitioning effort to better understand the performance
>> impacts of an alternative partitioning scheme. To date we’ve run
>> experiments with a triple-keyed HTTP cache and triple-keyed network state,
>> and a double-keyed HTTP cache and double-keyed network state.  As a
>> possible compromise between security and performance tradeoffs, which were
>> discussed
>> 
>> at a recent WebAppSec session at TPAC, we want to measure a triple-keyed
>> HTTP cache with the following network state key configurations: -
>> Triple-keyed network state (this is the first experiment we ran, but the
>> data is quite old now) - Double-keyed network state - Double-key with an
>> is_cross_site bit (whether the iframe is cross-site from the top-level
>> parent frame). - (and a control group, with unpartitioned network state) As
>> a reminder, here’s a link to the (triple-key) I2E
>> ,
>> and the (double-key) I2E
>> .
>> This document only contains changes to previous intents. Blink component
>> Internals>Network
>> 
>> Goals for experimentation We want to roll this out to 1% of Stable traffic
>> (i.e., this is not an Origin Trial) to be able to compare to the previous
>> experiments. Estimated milestones We’d like to run at 1% on Stable for ~4
>> weeks, ideally beginning in M107 (but some chance of this slipping to M108
>> depending on timing). Tracking bug https://crbug.com/993801
>>  Launch bug https://crbug.com/1166303
>>  Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/6713488334389248
>>  *
>>
>> --
>> 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/2e1e2e27-514b-688b-6318-e029fa7bf08f%40chromium.org
>> 
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXWnY4jM9DDy9X3j75xafDA%3DQ79mQSnA6A4GRiDopP1Zg%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/CAKXHy%3DcFBC5exY6uHEunS0Nb_pQ5S8pu_Xx4w4iqVcgMB2pmcA%40mail.gmail.com.

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

[Mike West]

I agree with Rick's analysis here. Given the purely-negative nature of this
OT, there's little risk in this burning-in unless we ship it, in which case
we want it to burn in.  Dropping the usage limitation for this OT LGTM2.

-mike


On Fri, Sep 30, 2022 at 7:34 PM Mike Taylor  wrote:

> On 9/30/22 1:32 PM, Rick Byers wrote:
>
> As I understand it, this OT is entirely about taking away functionality
> (grants nothing new which a site might take a dependency on). Therefore I
> don't think the usage limits are providing much, if any, value. At the same
> time, I can see the value of being able to test this upcoming behavior at a
> large scale.
>
> So, with API owner hat on, I propose we just turn them off for this trial.
> Thoughts?
>
> My my API owner hat off (because my name is attached to this project), I
> agree. I think the larger testing benefits outweigh any possible risks (and
> can't really think of any, tbqh).
>
>
> Rick
>
> On Wed, Sep 14, 2022 at 3:03 PM Nir M  wrote:
>
>> Hi Mike,
>> Nir from Meta and Noah's peer.
>>
>> would it be possible to give an estimate or a guideline on the
>> permissible magnitude of usage for the Opt-In trial (the one that forces
>> the full reduction of the UserAgent) available?
>> As we would like to conduct an experiment on that, and not deviate from
>> the 0.5% restriction of global page loads, we need an idea of how many
>> users will be able to be getting this experimental behavior.
>> would love to hear more details on that if you could provide.
>>
>> Link to the limitation reference on Origin-Trial:
>>
>> https://github.com/GoogleChrome/OriginTrials/blob/gh-pages/developer-guide.md#6-is-there-any-restriction-on-which-websites-can-sign-up-to-use-experimental-features
>>
>>
>>
>> thanks,
>> Nir
>>
>>
>> On Tuesday, July 26, 2022 at 9:27:20 PM UTC+3 mike...@chromium.org wrote:
>>
>>> Hi Noah,
>>>
>>> Thanks for reaching out - we've received a request just yesterday from
>>> another partner who also expressed interest in an extension, so I will work
>>> on an Intent to Extend Experiment in the next few days and we'll see what
>>> the Blink API Owners think. :)
>>>
>>> thanks,
>>> Mike
>>>
>>> On 7/26/22 1:40 PM, Noah Lemen wrote:
>>>
>>> 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 
>>>>>>>>> a

Re: [blink-dev] Intent to Ship: AudioContext.setSinkId()

[Mike West]

Friendly ping. It looks like conversation died down ~2 weeks ago. Has there 
been movement in the meantime, or should we consider this intent on hold 
for a while?

-mike

On Tuesday, September 20, 2022 at 11:21:13 AM UTC+2 Yoav Weiss wrote:

> Once the PR lands, this seems fine to ship (IMO). Let us know when that 
> happens :)
>
> On Wed, Sep 14, 2022 at 5:56 PM Hongchan Choi  
> wrote:
>
>> The original proposal didn't work out well because of the type confusion 
>> in the union (DOMString or AudioSinkCategory) - they are both DOMString in 
>> the end. So we are considering two options:
>>
>> https://github.com/WebAudio/web-audio-api/issues/2400#issuecomment-1239704445
>>
>> There's no disagreement. We just need to make a decision, and that is 
>> planned during this TPAC.
>>
>> Let me know if you have any questions!
>>
>> Thanks,
>> Hongchan
>>
>>
>> On Wed, Sep 14, 2022 at 8:43 AM Yoav Weiss  
>> wrote:
>>
>>>
>>>
>>> On Tuesday, September 13, 2022 at 4:16:15 PM UTC+2 ajayra...@google.com 
>>> wrote:
>>>
 Please let us know of any other questions, concerns or observations. 

 Thanks in advance.

 -Ajay

 On Wednesday, August 31, 2022 at 2:54:14 PM UTC-7 Ajay Rahatekar wrote:

> We have filed requests for position. Please see below:
>
> Mozilla: https://github.com/mozilla/standards-positions/issues/683
> Webkit: https://github.com/WebKit/standards-positions/issues/53
>
> On Wed, Aug 31, 2022 at 8:54 AM Chris Harrelson  
> wrote:
>
 Thanks for filing the TAG review. Could you also file for official 
>> positions from Mozilla and Webkit also? Thanks. I'm sure you're right 
>> about 
>> Mozilla, but they've requested going through the process in the past for 
>> other intents.
>>
>> On Wed, Aug 31, 2022 at 8:08 AM Hongchan Choi  
>> wrote:
>>
> 1. Yes. The lack of implementation is one issue, but the relationship 
>>> between selectAudioOutput() and Web Audio API is not really specified 
>>> or 
>>> documented.
>>> 2. Since AudioElement.setSinkId() has been used for years, we 
>>> believe it makes more sense to use the same pattern for its low-level 
>>> counterpart - Web Audio API's AudioContext. This approach is more 
>>> specific 
>>> and focused.
>>>
>>>
>>> On Tue, Aug 30, 2022 at 10:46 PM Philipp Hancke <
>>> philipp...@googlemail.com> wrote:
>>>
>> the ID of the sink needs to be obtained from 
 navigator.mediaDevices.enumerateDevices because 
 https://developer.mozilla.org/en-US/docs/Web/API/MediaDevices/selectAudioOutput
  
 is not implemented anywhere?

 Am Di., 30. Aug. 2022 um 19:02 Uhr schrieb 'Ajay Rahatekar' via 
 blink-dev :

>>> Contact emails
>
> hong...@chromium.org, alv...@chromium.org, mjwi...@chromium.org 
>
> Explainer
>
> None
>
> Specification
>
> https://github.com/WebAudio/web-audio-api/pull/2498
>

>>> The PR hasn't landed yet, and Mozilla's (positive) position states that 
>>> there are some details to be determined still.
>>> Can you expand on that? What's holding the PR from landing?
>>>
>>>
> Summary
>
> AudioContext.setSinkId sets the ID of the audio device to use for 
> output. This allows the AudioElement to route audio to a connected 
> output 
> device of user's choosing.
>
>
> Blink component
>
> Blink>WebAudio 
> 
>
> TAG review
>
> This is a small API change within Web Audio API. The WG was 
> advised that this is too small for the TAG review.
>
> TAG review status
>
> Not applicable
>
> Risks
>
> Interoperability and Compatibility
>
> Gecko: Positive (
> https://github.com/WebAudio/web-audio-api/issues/2400) Mozilla is 
> co-developing the spec change.
>
> WebKit: No signal
>
> Web developers: Positive (
> https://github.com/WebAudio/web-audio-api/issues/2400) Many 
> developers chimed in the spec issue and the implementation crbug 
> entry (
> crbug.com/1216187). Also several partners expressed the need for 
> this API. We have not seen any negative feedback on this.
>
> Other signals:
>
> WebView application risks
>
> Does this intent deprecate or change behavior of existing APIs, 
> such that it has potentially high risk for Android WebView-based 
> applications?
>
>
> Debuggability
>
> This adds a new method to AudioContext; the WebIDL change will be 
> 

[blink-dev] Re: Intent to Ship: CSS Values and Units Module Level 4: Small/Large/Dynamic/Logical viewport units

[Mike West]

LGTM1.

It's great to see us following along with WebKit and Gecko's 
implementations of these viewport units. The coverage in WPT looks 
reasonably solid (
https://wpt.fyi/results/css/css-values?label=master=experimental=chrome=firefox=safari=interop=label%3Ainterop-2022-viewport),
 
and developer need is clearly demonstrated. Thanks for getting this out the 
door!

-mike

On Monday, September 26, 2022 at 12:41:28 PM UTC+2 Anders Hartvoll Ruud 
wrote:

>
> Contact emails
>
> andr...@chromium.org
>
> Explainer
>
> https://github.com/w3ctag/design-reviews/issues/706#issuecomment-108242
>
> https://www.bram.us/2021/07/08/the-large-small-and-dynamic-viewports/
>
> Specification
>
> https://drafts.csswg.org/css-values-4/#viewport-relative-lengths
>
> Summary
>
> Support for sv* units, lv* units, dv* units and the logical vi/vb units.
>
> Blink component
>
> Blink>CSS 
> 
>
> Motivation
>
> Mobile browsers today typically have UI elements which dynamically hide 
> themselves when the user scrolls the page (e.g. the top URL bar on 
> Android). This presents a challenge to authors wishing to size and position 
> something relative to “the viewport”, since there can be multiple 
> definitions of “the viewport” depending on the state of these dynamic UI 
> elements.
>
> The new viewport units allow authors to size/position elements according 
> to the viewport appropriate for their use-case:
>
>
>- 
>
>Small: the viewport as it would be with dynamic UI fully expanded.
>- 
>
>Large: the viewport as it would be with dynamic UI fully contracted.
>- 
>
>Dynamic: the viewport as it is according to the current state of the 
>dynamic UI.
>
>
> The new viewport units are also part of Interop 2022 
> .
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/706
>
> TAG review status
>
> Closed with no issues.
>
> Risks
>
> Interoperability and Compatibility
>
>- 
>
>The viewport units are sized relative to the initial containing block 
>, 
>and different browsers resize the initial containing block in different 
>situations. In particular, opening/closing the virtual keyboard will 
>resize the ICB in Chrome for Android and Firefox for Android, but not in 
>Safari for iOS nor in Chrome for ChromeOS.
>See also Intent to Ship: Android OSK resizes visual viewport by 
>default +  opt-out 
>
> 
>.
>
>
> Gecko: Shipped/Shipping (
> https://www.mozilla.org/en-US/firefox/101.0/releasenotes/)
>
> WebKit: Shipped/Shipping (
> https://webkit.org/blog/12669/new-webkit-features-in-safari-15-5)
>
> Web developers: “Difficulties dealing with viewport sizing are prominent 
> in both the MDN Browser Compatibility Report 2020 and the new State of CSS 
> 2021 survey.” [1] 
>
> Other signals:
>
> WebView application risks
>
> N/A
>
>
> Debuggability
>
> No special DevTools support is needed.
>
> Is this feature fully tested by web-platform-tests 
> 
> ?
>
> Everything that can be tested with WPTs is covered. However, it’s 
> impossible to control dynamic UI elements from a WPT.
>
> Flag name
>
> CSSViewportUnits4
>
> Requires code in //chrome?
>
> False
>
> Tracking bug
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=1093055
>
> Estimated milestones
>
> M108
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5170718078140416
>
>

-- 
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/dcc0f4aa-a1ca-4c24-a959-209dc8249f77n%40chromium.org.

Re: [blink-dev] Intent to Ship: Web Authentication Conditional UI

[Mike West]

LGTM1.

The internal privacy/security review concluded that the design of the 
developer flow's integration with an autofill prompt substantially 
mitigates privacy concerns around knowing whether the user has credentials. 
`isConditionalMediationAvailable` is tied to the underlying platform which 
we already reveal to the site through UA client hints and highly correlated 
with `isUserVerifyingPlatformAuthenticatorAvailable`, though it does allow 
marginal distinction between Win11+ and other Windows versions. Given that 
we're relying on the underlying platform authenticator, this is a leak 
we're unlikely to be able to address.

The benefits of driving more cross-browser usage of WebAuthn are 
substantially security-positive, however, and pushing the passkey story 
forward is a solid justification for shipping this mechanism IMO. Safari 
and Edge being on board mitigates to some extent the lack of engagement 
from Mozilla. Thank you for filing the standards position request anyway; 
I've poked some folks on the side to see if there's someone who might be 
interested in paying more attention.

In the meantime, good luck shipping this!

-mike

On Tuesday, September 20, 2022 at 12:03:08 AM UTC+2 Nina Satragno wrote:

> Filed https://github.com/mozilla/standards-positions/issues/692, thanks!
>
> On Mon, Sep 19, 2022 at 5:36 PM Jeffrey Yasskin  
> wrote:
>
>> On Mon, Sep 19, 2022 at 2:25 PM Nina Satragno  
>> wrote:
>>
>>> ...
>>> Interoperability and Compatibility
>>>
>>> Very low: this is a new feature that's already implemented by Safari on 
>>> their Technology Preview.
>>>
>>> Gecko: No signal
>>>
>>
>> It's probably worth filing a standards-position 
>>  request for 
>> significant WebAuthn changes, even though I see from 
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/Vfg2o0peyYg/m/Vp0h8i5VBQAJ
>>  
>> that we can't expect Mozilla to respond. 
>>
>> Other than that: Yay!
>>
>> Jeffrey
>>
>>
>
> -- 
>
> [image: Google Logo] 
> Nina Satragno
> Ingeniera en Informática
> she/her
> nsatra...@chromium.org
>
>

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

Re: [blink-dev] Intent to Ship: Sync methods for FileSystemSyncAccessHandle in File System Access API

[Mike West]

LGTM2, seconding Yoav's note to ensure that folks you know are using the 
API test their code earlier rather than later to shake out bugs this 
behavioral change might trigger.

-mike

On Saturday, September 24, 2022 at 7:00:17 AM UTC+2 Yoav Weiss wrote:

> LGTM1
> Seems good to make this change now, as usage is low, but rising.
>
> Please make sure you reach out to affected partners.
>
> On Fri, Sep 23, 2022 at 7:21 PM Daseul Lee  wrote:
>
>>
>>
>> On Fri, Sep 23, 2022 at 12:50 AM Yoav Weiss  
>> wrote:
>>
>>>
>>>
>>> On Thu, Sep 22, 2022 at 8:06 PM 'Daseul Lee' via blink-dev <
>>> blink-dev@chromium.org> wrote:
>>>
 Contact emails

 ds...@google.com

 Specification


 https://github.com/whatwg/fs/pull/53/commits/618b663ebdc0f9842d7db3091baed5f75aa87534

 Summary

 Updates the asynchronous methods (`flush()`, `getSize()`, `truncate()`) 
 in `FileSystemSyncAccessHandle` in the File System Access API to 
 synchronous methods. `FileSystemSyncAccessHandle` currently has a mix of 
 sync and async methods, hindering the performance and the usability, 
 especially for applications porting C/C++ to Wasm. This update will bring 
 consistency in the API usage and improve the performance for Wasm-based 
 libraries.


 Blink component

 Blink>Storage>FileSystem 
 

 TAG review

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

 TAG review status

 Pending


 Risks

 Interoperability and Compatibility

 Compatibility:

 Changing a return type from Promise to value can break, only if Promise 
 methods are directly used rather than `await`. However, we expect minimal 
 breakage due to very low usage (~0.2% page loads; zero usage queried 
 via HttpArchive).

>>>
>>> Do I understand correctly that this usage is a loose upper bound of 
>>> users of the API, and not necessarily sites that are not using `await`?
>>>
>> Yes, that's correct. It includes any usage, whether it is `await` or 
>> `Promise.then()`
>>  
>>
>>> Does it include all the APIs that are planned to stop returning Promises?
>>> Also, can you link the use counter?
>>>
>> For truncate() method as an example, here is the link for use counter: 
>> https://uma.googleplex.com/p/chrome/timeline_v2/?sid=33c4e21724eb85df0bdc19ff775d0018
>> Unfortunately, it times out for (unique) count clients, so the above link 
>> is filtered on Mac OX only. It is still very slow, though.
>>
>
> Thanks!
> Here are the public link for the same counters: 
> Truncate - 
> https://chromestatus.com/metrics/feature/timeline/popularity/4019
> Flush - https://chromestatus.com/metrics/feature/timeline/popularity/4017
> GetSize - 
> https://chromestatus.com/metrics/feature/timeline/popularity/4018
>  
>
>>
>> Some other links: 
>> Page load %: 
>> https://chromestatus.com/metrics/feature/timeline/popularity/4019
>> Additionally, we tried querying HttpArchive directly, and 0 usage has 
>> returned.
>>
>> As a side note, we have an enterprise policy set up to guard this change 
>> to prevent breakage.
>>
>>>  
>>>
 The original API was shipped in M102 and targeted for partner usage, to 
 which the changes may be communicated. In addition, all code snippets and 
 examples in public documents use `await`, which does not cause any 
 breakage.

 Interoperability: 

 There are no interoperability risks expected. The design change was 
 initially proposed and assessed from vendor feedback. 
 https://github.com/whatwg/fs/issues/7


 Gecko: Positive (
 https://github.com/whatwg/fs/issues/7#issuecomment-1226562961)

 WebKit: No signal

 Web developers: Strongly positive (
 https://github.com/whatwg/fs/issues/7)

 Other signals:

 Ergonomics

 Low ergonomics risks are expected. In fact, the goal of this change is 
 to improve the ergonomics of the API by making all methods to return 
 synchronously and make it easier to use on Wasm-ported applications.


 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

 Basic tooling: Autocomplete works as described in "New WebIDL/DOM 
 interfaces and attributes".


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

 No

 Desktop only now. Origin Private File System (including 
 `FileSystemSyncAccessHandle`) is planned to be shipped on Android in the 
 near future.

 Is this feature fully tested by web-platform-tests 
 

Re: [blink-dev] Intent to Ship: Origin Private File System (OPFS) on Android

[Mike West]

LGTM3.

-mike

On Friday, September 23, 2022 at 7:12:50 PM UTC+2 ds...@google.com wrote:

> Thanks for the review!
>
> WPT is no longer available 
> 
>  
> to run on Android.
>
> It looks like there is some coverage 
> 
>  
> for Drag-and-Drop, but as Marijn mentioned, it doesn't have full/good 
> coverage, especially if your original question was with respect to 
> file-system.
>
>
> On Thu, Sep 22, 2022 at 2:00 PM Marijn Kruisselbrink  
> wrote:
>
>>
>>
>> On Thu, Sep 22, 2022 at 5:34 AM Mike Taylor  
>> wrote:
>>
>>> LGTM2
>>>
>>> On 9/22/22 12:04 AM, Yoav Weiss wrote:
>>>
>>> LGTM1
>>>
>>> On Wed, Sep 21, 2022 at 9:10 PM 'Daseul Lee' via blink-dev <
>>> blink-dev@chromium.org> wrote:
>>>


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

 No

 Web Platform Tests are not available on Android.

 (The answer should probably be yes here, I think.) 
>>>
>>> Out of curiosity, do we have (manual?) tests that cover the DnD 
>>> functionality that this intent does not support, for Desktop? I see there 
>>> are some showPicker tests.
>>>
>> There are browser tests for the DnD functionality. Chrome's web platform 
>> test infrastructure bypasses so much of chrome's drag implementation 
>> that even if we would/could write a WPT that would try to exercise the DnD 
>> code (there are some for other file DnD features) we're not really testing 
>> the real implementation anymore.
>>
>>>
>>> https://wpt.fyi/results/file-system-access?label=master=experimental=subtest
>>>
>>> thanks,
>>> Mike
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "blink-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to blink-dev+unsubscr...@chromium.org.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8ee76bfb-45b8-f0bf-a3bf-82d9ea0d78c5%40chromium.org
>>>  
>>> 
>>> .
>>>
>>

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

[blink-dev] Re: Intent to Experiment: TLS Encrypted Client Hello (ECH)

[Mike West]

LGTM to experiment from M105 to M109 (inclusive). It'd be excellent to come
back to the group with initial results in the (likely?) case you need to
extend and revise.

Good luck!

-mike



On Tue, Aug 23, 2022 at 8:03 PM David Benjamin 
wrote:

> (Sorry for the late reply. Was out sick for a bit.)
>
> On Thu, Aug 11, 2022 at 4:06 PM Mike West  wrote:
>
>> I'm excited to see this! One question inline about timelines:
>>
>> On Thursday, August 11, 2022 at 9:55:48 PM UTC+2 David Benjamin wrote:
>>
>>> Contact emailsdavi...@chromium.org, dad...@google.com
>>>
>>> ExplainerNone
>>>
>>> Specificationhttps://datatracker.ietf.org/doc/html/draft-ietf-tls-esni
>>>
>>> Summary
>>>
>>> The TLS Encrypted ClientHello (ECH) extension enables clients to encrypt
>>> ClientHello messages, which are normally sent in cleartext, under a
>>> server’s public key. This allows websites to opt-in to avoid leaking
>>> sensitive fields, like the server name, to the network by hosting a special
>>> HTTPS RR DNS record. (Earlier iterations of this extension were called
>>> Encrypted Server Name Indication, or ESNI.)
>>>
>>>
>>> Blink componentInternals>Network>SSL
>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3ENetwork%3ESSL>
>>>
>>> Search tagsech <https://chromestatus.com/features#tags:ech>, esni
>>> <https://chromestatus.com/features#tags:esni>, tls
>>> <https://chromestatus.com/features#tags:tls>, ssl
>>> <https://chromestatus.com/features#tags:ssl>
>>>
>>> TAG reviewNot applicable; this is a protocol under IETF
>>>
>>> TAG review statusNot applicable
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> As a networking protocol, interoperability risks look different from a
>>> web platform API: This is a draft of a developing protocol, so the final
>>> standard will differ from what we ship now. We manage this as in other
>>> protocol work: the draft uses different codepoints in the DNS record and
>>> ClientHello, set up to not conflict with the final standard. There is also
>>> a risk of breaking buggy servers or network middleware. ECH is DNS-gated,
>>> so non-ECH servers won't be exposed to ECH itself. We do implement ECH's
>>> GREASE mechanism (section 6.2 of the draft), but this should appear as any
>>> normal unrecognized extension to non-ECH servers. Servers and network
>>> elements that are compliant with RFC 8446, section 9.3, should not be
>>> impacted. We will be monitoring for these issues as part of the experiment,
>>> comparing error rates and handshake times both for HTTPS servers as a
>>> whole, and the subset of those that advertise ECH in DNS.
>>>
>>>
>>> *Gecko*: In development (
>>> https://blog.mozilla.org/security/2021/01/07/encrypted-client-hello-the-future-of-esni-in-firefox
>>> )
>>>
>>> *WebKit*: No signal
>>>
>>
>> It would be reasonable to ask via
>> https://github.com/WebKit/standards-positions/issues.
>>
>
> Filed https://github.com/WebKit/standards-positions/issues/46
>
>
>>
>>> *Web developers*: Positive (
>>> https://blog.cloudflare.com/encrypted-client-hello)
>>>
>>> *Other signals*:
>>>
>>> Ergonomics
>>>
>>> ECH is part of TLS, so it is largely abstracted away from web platform
>>> APIs themselves.
>>>
>>>
>>> Activation
>>>
>>> This is a network protocol and thus inherently requires server software
>>> changes. It also requires keys deployed in the HTTPS DNS record. At this
>>> stage in the process, we do not expect ECH to be deployed beyond a few
>>> early adopters. Rather, this experiment is part of real-world testing for
>>> the developing protocol. The connection with the DNS record is of
>>> particular note. It is possible that, due to DNS caching, etc., that the
>>> DNS record we fetch is out of sync with the server instance we talk to. ECH
>>> has a built-in recovery mechanism to repair these mismatches. One of the
>>> aims of the experiment will be to validate this mechanism.
>>>
>>>
>>> Security
>>>
>>> See
>>> https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-14#section-10
>>> for security considerations in the specification
>>>
>>>
>>> WebView applicati

[blink-dev] Re: Intent to Prototype: FileSystemHandle Unique IDs

[Mike West]

Hi! I've skimmed through the explainer, but I feel like I'm missing 
something important. Can you help me understand the difference between the 
scheme proposed here on the one hand, and relying on something like 
Crypto.randomUUID() 
 on the 
other? I don't understand the requirements that would make the latter 
unworkable, but I'd like to before we add another identifier-generator to 
the platform. :)

Thanks!

-mike

On Friday, August 12, 2022 at 7:15:58 PM UTC+2 Austin Sullivan wrote:

> Contact emailsasu...@chromium.org
>
> Specificationhttps://github.com/whatwg/fs/pull/46
>
> Summary
>
> FileSystemHandle::getUniqueId() generates a uniquely identifying string 
> which can be used as a key, such as for IndexedDB or WebLocks. Currently, 
> FileSystemHandle objects can be serialized by the browser to be stored as 
> values in IndexedDB, but there is no way to generate a string which is 
> guaranteed to be uniquely identifying.
>
>
> Developers have complained that building rich experiences on top of the 
> File System Access API is challenging due to the inability to uniquely 
> identify (and index on) handles. Several partners have requested this.
>
>
> Blink componentBlink>Storage>FileSystem 
> 
>
> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/764
>
> TAG review statusPending
>
> Risks
>
>
> Interoperability and Compatibility
>
>
>
> *Gecko*: No signal
>
> *WebKit*: No signal
>
> *Web developers*: Positive (
> https://github.com/WICG/file-system-access/issues/295)
>
> *Other signals*:
>
> Debuggability
>
> N/A
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac, 
> Linux, Chrome OS, Android, and Android WebView)?This feature will be 
> supported on all platforms https://github.com/whatwg/fs/ is shipped 
> (currently only desktop platforms)
>
> Is this feature fully tested by web-platform-tests 
> 
> ?
>
> The feature will be fully testable with WPT. They'll be written as part of 
> the prototype
>
> Flag nameFileSystemAccessAPIExperimental
>
> Tracking bughttps://crbug.com/1342961
>
> Estimated milestones
>
> No milestones specified
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5190893263388672
>
> This intent message was generated by Chrome Platform Status 
> .
>

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

[blink-dev] Re: Intent to Experiment: TLS Encrypted Client Hello (ECH)

['Mike West' via blink-dev]

I'm excited to see this! One question inline about timelines:

On Thursday, August 11, 2022 at 9:55:48 PM UTC+2 David Benjamin wrote:

> Contact emailsdavi...@chromium.org, dad...@google.com
>
> ExplainerNone
>
> Specificationhttps://datatracker.ietf.org/doc/html/draft-ietf-tls-esni
>
> Summary
>
> The TLS Encrypted ClientHello (ECH) extension enables clients to encrypt 
> ClientHello messages, which are normally sent in cleartext, under a 
> server’s public key. This allows websites to opt-in to avoid leaking 
> sensitive fields, like the server name, to the network by hosting a special 
> HTTPS RR DNS record. (Earlier iterations of this extension were called 
> Encrypted Server Name Indication, or ESNI.)
>
>
> Blink componentInternals>Network>SSL 
> 
>
> Search tagsech , esni 
> , tls 
> , ssl 
> 
>
> TAG reviewNot applicable; this is a protocol under IETF
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> As a networking protocol, interoperability risks look different from a web 
> platform API: This is a draft of a developing protocol, so the final 
> standard will differ from what we ship now. We manage this as in other 
> protocol work: the draft uses different codepoints in the DNS record and 
> ClientHello, set up to not conflict with the final standard. There is also 
> a risk of breaking buggy servers or network middleware. ECH is DNS-gated, 
> so non-ECH servers won't be exposed to ECH itself. We do implement ECH's 
> GREASE mechanism (section 6.2 of the draft), but this should appear as any 
> normal unrecognized extension to non-ECH servers. Servers and network 
> elements that are compliant with RFC 8446, section 9.3, should not be 
> impacted. We will be monitoring for these issues as part of the experiment, 
> comparing error rates and handshake times both for HTTPS servers as a 
> whole, and the subset of those that advertise ECH in DNS.
>
>
> *Gecko*: In development (
> https://blog.mozilla.org/security/2021/01/07/encrypted-client-hello-the-future-of-esni-in-firefox
> )
>
> *WebKit*: No signal
>

It would be reasonable to ask via 
https://github.com/WebKit/standards-positions/issues.
 

>
> *Web developers*: Positive (
> https://blog.cloudflare.com/encrypted-client-hello)
>
> *Other signals*:
>
> Ergonomics
>
> ECH is part of TLS, so it is largely abstracted away from web platform 
> APIs themselves.
>
>
> Activation
>
> This is a network protocol and thus inherently requires server software 
> changes. It also requires keys deployed in the HTTPS DNS record. At this 
> stage in the process, we do not expect ECH to be deployed beyond a few 
> early adopters. Rather, this experiment is part of real-world testing for 
> the developing protocol. The connection with the DNS record is of 
> particular note. It is possible that, due to DNS caching, etc., that the 
> DNS record we fetch is out of sync with the server instance we talk to. ECH 
> has a built-in recovery mechanism to repair these mismatches. One of the 
> aims of the experiment will be to validate this mechanism.
>
>
> Security
>
> See 
> https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-14#section-10 
> for security considerations in the specification
>
>
> 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 WebView-specific risks
>
>
>
> Goals for experimentation
>
> This is a new extension to TLS. As part of the standardization process, we 
> wish to validate the design, and ensure it works, performs well, etc. This 
> is also the first time a TLS extension has been gated on DNS. This 
> introduces a new set of deployment risks. ECH includes mechanisms to 
> mitigate these risks, which we also aim to validate with this experiment. 
> We'll do this by A/B testing clients with and without ECH enabled, and 
> comparing error rates and latency across all TLS connections, and across 
> just connections to hostnames with ECH keys in DNS. We'll also be looking 
> at how often the recovery flow is used.
>
>
> Reason this experiment is being extended
>
> n/a
>
>
> Ongoing technical constraints
>
> None
>
>
> Debuggability
>
> Servers that use ECH are visible in the DevTools security panel.
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac, 
> Linux, Chrome OS, Android, and Android WebView)?Yes
>
> While supported on all platforms, ECH requires keys fetched via DNS in the 
> new HTTPS record. Chrome can currently fetch the HTTPS record over DoH and 
> over our built-in DNS resolver. As of writing, the built-in DNS resolver is 
> not yet enabled on Windows 

Re: [blink-dev] Intent to Prototype & Ship: Client Hints persistency in Android WebView

[Mike West]

LGTM1 to extend this already-approved feature to WebView.

Presumably you'll be chatting with WebView experts about any implications
this might have for the API WebView exposed to embedding apps?

-mike


On Wed, Aug 3, 2022 at 8:45 PM Ari Chivukula  wrote:

> Contact emails
>
> aric...@chromium.org, miketa...@chromium.org, yoavw...@chromium.org
> 
>
> Specification
>
> https://wicg.github.io/client-hints-infrastructure/
>
> Explainer
>
> When a page is loaded, the first response from an origin may include a
> signal (in HTTP headers) for Client Hints to be included in future requests
> to that origin. Without persisting this signal, Client Hints cannot be
> included in the next request to load a page from this Origin. Android
> WebView does not currently persist this signal.
>
> Design Doc
>
>
> https://docs.google.com/document/d/1r1AKHex1_UKh3wIp4ITkU4-J9-tdNZSOmUDeDVWw_AU/
>
> Summary
>
> We aim to add support for persistent Client Hints to Android Webview for
> parity with the rest of the platform. For more details on the Client Hints
> system see: https://developer.mozilla.org/en-US/docs/Web/HTTP/Client_hints
>
>
>
> Blink component
>
> Blink>Network>ClientHints
> 
>
>
>
> Motivation
>
> Without persisting the list of Client Hints a page requests the initial
> load of a website will never include Client Hints, only subresources on a
> given page can receive them. This undermines the use of the Client Hints
> system which is to empower websites to adapt content to the User Agent. We
> should add persistence in the interest of parity with the behavior of
> Chrome on Android so that WebView stays viable as a platform.
>
> TAG review
>
> N/A (this change enables a feature that we already ship on desktop and
> Android)
>
> Compatibility
>
> This expands persistent Client Hints to a platform that was missing it, no
> existing implementation will change. The persisted Client Hints can be
> cleared by clearing the Cookies for a given WebView, the same way that
> Client Hints are cleared in Chrome for Android.
>
>
> Interoperability
>
> Other engines haven’t shipped Client Hints so this doesn’t increase
> interoperability risk.
>
>
>
> Gecko: Client Hints
>  and User Agent
> Client Hints 
> considered non-harmful
>
>
>
> WebKit: Mildly positive support for User Agent Client Hints
> 
>
>
>
> Web developers: Vendor interest from Huawei
> ,
> interest from Cloudinary
>  in User
> Agent Client Hints
>
> Debuggability
>
> N/A (developers can use Chrome for Android to debug client hint requests,
> though the values for user-agent related strings will differ within the
> WebView context)
>
> Is this feature fully tested by web-platform-tests?
>
> Android WebView is not a WPT platform, so this will only have chrome
> internal tests
>
> Tracking bug
>
> https://crbug.com/921655
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/4936247663919104
>
> --
> 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/CAGpy5D%2BZnn79sLfnTBa84Q_aCmg%2BWsAeZBqLo9MCA335gYg_nw%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/CAKXHy%3Dd_6zWscYe_-dCSmbjze3PQCyKzDLUT06h5cb9A3gxWdA%40mail.gmail.com.

Re: [blink-dev] Re: Ready for Trial: Quick intensive timer throttling of loaded background pages

[Mike West]

IMO, this is somewhere on the border between a web-visible experiment and a
pure expression of user agent preference regarding flexibility explicitly
carved out in a standard.

Rather than debating the feature's philosophical state, I'd simply treat
this email as an Intent to Experiment from M104 (current stable) to M107,
and give you an explicit LGTM.

Additionally: it would be ideal for the experience you gather in this
experiment to fold back into the spec as an "Implementation Consideration"
that might help other implementers determine how to use the flexibility the
spec provides.

-mike


On Fri, Aug 5, 2022 at 9:24 PM 'François Doray' via blink-dev <
blink-dev@chromium.org> wrote:

> +Scott Haseley  as an expert in this field.
>
> We would like to start experimenting with this intervention on 1% Stable
> very soon. We've been experimenting on 50% of Beta for almost 2 months. The
> results are encouraging and we aren't aware of negative Web developer
> feedback. Do we need your LGTM to proceed?
>
> On Mon, Aug 1, 2022 at 3:45 AM Zhang, Jiahe  wrote:
>
>> Contact emails
>>
>> jiahe.zh...@intel.com, fdo...@chromium.org
>>
>>
>> Specification
>>
>> https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html
>>
>>
>> Design docs
>>
>>
>>
>> https://docs.google.com/document/d/1WFyfKUUxqM7uKxKOGhLiOjyY6T7QRduVcuHN0f6vJkk/edit
>>
>>
>> Summary
>>
>> Enter Intensive Wake Up throttling after 10 seconds if the page is fully
>> loaded when it becomes hidden. Currently, wake ups from JS timers with a
>> nesting level >= 5 are throttled to 1 per minute after the page has spent 5
>> minutes in the background [1], which is very conservative and was chosen to
>> allow a launch of Intensive Wake Up Throttling with minimal regression
>> risk. We're now planning to reduce this timeout to 10 seconds if the page
>> is fully loaded when hidden. [1]
>> https://chromestatus.com/feature/4718288976216064
>>
>>
>>
>> Blink component
>>
>> Blink>Scheduling
>> 
>>
>>
>> TAG review
>>
>> Not applicable. This feature changes the behavior of an existing API,
>> while remaining spec-compliant ("Optionally, wait a further
>> implementation-defined length of time.
>> 
>> ")
>>
>>   Risks
>>
>>
>>
>>
>> Interoperability and Compatibility
>>
>>
>> *Gecko*: No signal
>>
>> *WebKit*: No signal
>>
>> *Web developers*: No signals
>>
>> *Other signals*: The more conservative version of Intensive Wake Up
>> Throttling shipped smoothly to 100% Stable more than 1 year ago. A few bugs
>> were filed, but in all cases we've been able to propose workarounds which
>> made apps more efficient (example
>> ).
>>
>>
>> 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, this feature will only ship on desktop platforms.
>>
>>
>>
>>   Goals for experimentation
>>
>> We plan to experiment on 1% Stable to confirm whether we observe the same
>> memory and power improvements as in the lab and on lower channels. We will
>> decide whether this intervention ships based on the experiment data.
>>
>>
>>
>> Ongoing technical constraints
>>
>> None
>>
>>
>> Debuggability
>>
>> This is not a new Web Platform feature.
>>
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)?
>>
>> No
>>
>> This feature will only ship on desktop platforms. On Android, the system
>> severely limits resource consumption from background renderers, which makes
>> this feature unnecessary.
>>
>>
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?
>>
>> Yes
>>
>>
>> Flag name
>>
>> quick-intensive-throttling-after-loading
>>
>>
>> Requires code in //chrome?
>>
>> False
>>
>>
>> Tracking bug
>>
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1324656
>>
>>
>> Estimated milestones
>>
>> DevTrial on desktop
>>
>> 105
>>
>>
>>
>> Link to entry on the Chrome Platform Status
>>
>> https://chromestatus.com/feature/5580139453743104
>>
>> This intent message was generated by Chrome Platform Status
>> .
>>
>>
>>
>>
>>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGD3t5E9r%2BjOcMa5nR3ZgYjNykEyj8bUBmjvszgFYmiBJKP-dA%40mail.gmail.com
> 

Re: [blink-dev] Intent to Implement and Ship: WebCodecs dequeue event

[Mike West]

LGTM2. I agree with Philip's suggestion that this is a small change that
doesn't require running Web Codecs back through TAG review, and that the
continued support of an editor at Mozilla is sufficient to consider their
position on the underlying API unchanged.

-mike


On Sat, Aug 6, 2022 at 12:03 AM Philip Jägenstedt 
wrote:

> LGTM1, seems like a simple and useful addition!
>
> On Fri, 5 Aug 2022 at 22:38 Chris Cunningham 
> wrote:
>
>> Contact emailschcunning...@chromium.org
>>
>> Explainerhttps://github.com/w3c/webcodecs/blob/main/explainer.md
>>
>> Specificationhttps://w3c.github.io/webcodecs
>>
>> Summary
>>
>> This feature tracks adding a single event named "dequeue" and event
>> handler to the audio and video encoder and decoder interfaces (e.g.
>> AudioDecoder.ondequeue).
>>
>> Authors initially queue up encoding or decoding work by calling encode()
>> or decode() respectively. The new "dequeue" event is fired to indicate when
>> the underlying codec has ingested some/all of the queued work. The decrease
>> in the queue size is already reflected by a lower value of
>> encoder.encodeQueueSize and decoder.decodeQueueSize attributes. The new
>> event eliminates the need for authors to setTimeout() poll to determine
>> when the queue has decreased (i.e. when they should queue up more work).
>>
>> See mentions of "dequeue" in the WebCodecs specification
>> https://w3c.github.io/webcodecs/#audiodecoder-event-summary
>>
>>
>> Blink componentBlink>Media>WebCodecs
>> 
>>
>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/612
>> Note that TAG did not review this new "dequeue" event specifically.
>>
>> TAG review statusIssues addressed
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> Low risk. At present Chromium is the only implementer of WebCodecs
>> generally. This is a minor addition to WebCodecs APIs that should be
>> straightforward for future implementers to incorporate. The spec change to
>> add this event was approved by representatives from Edge and Firefox.
>> https://github.com/w3c/webcodecs/pull/439
>>
>>
>> *Gecko*: Positive (
>> https://github.com/mozilla/standards-positions/issues/209) Firefox is
>> helping co-edit spec (Paul Adenot)
>>
>> *WebKit*: No signal Expressed mixed interest/concerns.
>> https://lists.webkit.org/pipermail/webkit-dev/2020-May/031191.html
>> https://lists.webkit.org/pipermail/webkit-dev/2021-February/031691.html
>>
>> *Web developers*: Strongly positive
>> See blurbs from OT participants at the bottom of the I2S.
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/7UlTzFMbTFs
>>
>> *Other signals*: Edge: Positive, co-editing the spec (Bernard Aboba)
>>
>> Ergonomics
>>
>> No risks
>>
>>
>> Activation
>>
>> No risks
>>
>>
>> Security
>>
>> No risks
>>
>>
>> WebView application risks
>>
>> No risks.
>>
>>
>> Debuggability
>>
>> The event may be debugged in typical fashion by setting breakpoints or
>> logging in the event handler.
>>
>>
>> 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
>> 
>> ?Yes
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://crbug.com/1341116
>>
>> Non-OSS dependencies
>>
>> No dependencies.
>>
>> Estimated milestones
>>
>> 105
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5195706034290688
>>
>> This intent message was generated by Chrome Platform Status
>> .
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to blink-dev+unsubscr...@chromium.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6eSrkzPiW8tconoPnduyaY%3DZSPHSFE6djL6kcDWHsk%3DtnrA%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/CAARdPYeFcMV%3D2MQeCipAvYmZJZgg2nNk1Ytpavyks0qrPjKYWQ%40mail.gmail.com
> 
> .
>

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

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

[Mike West]

LGTM3.

-mike


On Wed, Jul 27, 2022 at 6:23 PM Mike Taylor  wrote:

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

Re: [blink-dev] Intent to Ship: fetch() upload streaming

[Mike West]

LGTM2, also assuming you handle Mozilla's concerns reasonably. I'm happy to
see y'all have thought through the CORS implications, and requiring `cors`
or `same-origin` requests alleviates my minor concerns about leaking a
server's support for HTTP/1 vs HTTP/2+.

-mike


On Wed, Jul 13, 2022 at 1:16 PM Yoav Weiss  wrote:

> LGTM1
>
> This seems like a useful addition, web developer signals look great, and
> it's great to have Mozilla on board with this. Please make sure to answer
> their questions on the position issue.
>
> On Wed, Jul 13, 2022 at 12:27 PM Yutaka Hirano 
> wrote:
>
>>
>>
>> On Wed, Jul 13, 2022 at 7:23 PM Yoav Weiss 
>> wrote:
>>
>>>
>>>
>>> On Monday, July 11, 2022 at 12:50:11 PM UTC+2 Yutaka Hirano wrote:
>>>
 On Mon, Jul 11, 2022 at 7:41 PM Yutaka Hirano 
 wrote:

>
>
> On Mon, Jul 11, 2022 at 5:41 PM Yoav Weiss 
> wrote:
>
>>
>>
>> On Mon, Jul 11, 2022 at 10:17 AM Yutaka Hirano 
>> wrote:
>>
>>> Contact emailsyhir...@chromium.org
>>>
>>> Explainerhttps://bit.ly/2SVvKbR
>>>
>>
>>> The explainer seems focused on the H1 Origin Trial use case, which IIUC
>>> we decided against.
>>> Is there a more up-to-date explainer on what y'all are actually planning
>>> to ship?
>>>
>>
>> Oops, sorry again, I thought I updated the URL but apparently I failed to
>> do so...
>> Here it is.
>> https://github.com/yutakahirano/fetch-with-streams/blob/master/streaming-upload.md
>>
>
> Thanks! :)
>
>>
>>
>>>
>>>

>>>
>>> Specificationhttps://fetch.spec.whatwg.org/#concept-body-stream
>>>
>>> Design docs
>>> http://bit.ly/3asqra2
>>>
>>> Summary
>>>
>>> Fetch upload streaming lets web developers make a fetch with a
>>> ReadableStream body. Fetch provides a generic definition of Request and
>>> Response objects (and other things involved with network requests).
>>>
>>>
>>> Blink componentBlink>Network>FetchAPI
>>> 
>>>
>>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/434
>>>
>>
>> Actual review never really happened :/ Seems worthwhile to at least
>> communicate that to the TAG.
>>
>
> Oh sorry I somehow chose a wrong URL.
> https://github.com/w3ctag/design-reviews/issues/754 is the correct
> one.
>
>
>>
>>
>>>
>>>
>>> TAG review statusIssues open
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> TBD
>>>
>>>
>>> *Gecko*: No signal (
>>> https://github.com/mozilla/standards-positions/issues/207)
>>>
>>
>> This seems like a position request for a different feature. I think
>> you meant https://github.com/mozilla/standards-positions/issues/663
>>
>
>>> Seems like Mozilla are positive on this! (% some questions)
>>>
>>>

 You're right, thank you.


>
>>
>>> No signals on the standards-position ticket. Annevk has been active
>>> on the standards discussions. Positive at TPAC 2019 [1].
>>>
>>> *WebKit*: No signal (
>>> https://github.com/WebKit/standards-positions/issues/24) No signals
>>> on the standards-position ticket. Positive at TPAC 2019 [1]. [1]
>>> https://docs.google.com/document/d/1q090ovJ4gd8wSfVtvuoZLMZ51YkiFDsEZ0Jiqi41Iys/edit#heading=h.85gziabhajhg
>>>
>>> *Web developers*: Positive
>>> https://github.com/whatwg/fetch/issues/1438#issuecomment-1150755587
>>> https://github.com/whatwg/fetch/issues/1438#issuecomment-1167984830
>>>
>>> *Other signals*:
>>>
>>> Security
>>>
>>> - Only 'cors' and 'same-origin' requests allow streaming upload. You
>>> can't use streaming upload with 'navigate' and 'no-cors' requests. - 
>>> This
>>> feature cannot be used with HTTP/1.x. If the server doesn't support 
>>> HTTP/2
>>> or HTTP/3, the request fails. This is for some compatibility concerns. 
>>> See
>>> whatwg/fetch#966 for the past discussions.
>>>
>>>
>>> WebView application risks
>>>
>>> Does this intent deprecate or change behavior of existing APIs, such
>>> that it has potentially high risk for Android WebView-based 
>>> applications?
>>>
>>> No
>>>
>>>
>>> Debuggability
>>>
>>> Same as usual fetch()
>>>
>>>
>>> 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
>>> 
>>> ?Yes
>>>
>>> Flag name
>>>
>>> Requires code in //chrome?False
>>>
>>> Tracking bug
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=688906
>>>
>>> Non-OSS dependencies
>>>

Re: [blink-dev] Intent to Prototype & Ship: Syntax changes to markup based Client Hints delegation

[Mike West]

LGTM3.

-mike


On Thu, Jul 7, 2022 at 9:03 PM Ari Chivukula  wrote:

> Combining the addition of the new syntax and the removal of the old one
> works. I'll update the language on the chrome status feature page. There
> won't be an issue getting the code in for M105 assuming we get the third
> LGTM within a week.
>
> ~ Ari Chivukula (Their/There/They're)
>
>
> On Wed, Jul 6, 2022 at 12:03 PM Daniel Bratell 
> wrote:
>
>> LGTM2 (including removing the old syntax which is not yet used enough to
>> be a compatibility problem)
>>
>> /Daniel
>> On 2022-07-06 17:38, Chris Harrelson wrote:
>>
>> LGTM1 to ship this *and* remove the old syntax at the same time. We/I
>> think it'd be better to do it all at once without having both syntaxes in
>> the while for a period.
>>
>> On Wed, Jun 29, 2022 at 12:15 PM Mike Taylor 
>> wrote:
>>
>>> To add some clarity to the proposed changes and the rationale (as this
>>> came up in the API OWNERS meeting today):
>>>
>>> In M100 we shipped the following syntax, thinking it was a good idea to
>>> get as close to Permissions-Policy syntax as possible:
>>>
>>> https://foo.bar
>>> https://baz.qux), sec-ch-width=(https://foo.bar)">
>>>
>>> But it’s not quite a valid Permissions Policy, as Cloudinary pointed out.
>>>
>>> One difference is the lack of quotes around origins  (which are required
>>> for sf-strings). But without changing HTML meta parsing entirely (no
>>> thanks), we would have to force devs to use a single quote for value=, so
>>> they could use double quotes inside. Or the inverse, but sf-strings don’t
>>> allow for beginning with single quotes.
>>>
>>> Another difference is the fact that client hints tokens begin with the
>>> `sec-` prefix, but the policy-controlled feature names do not.
>>>
>>> So the delta is far enough away from a Permissions-Policy header to
>>> declare that our attempt failed. :(
>>>
>>> Instead, this intent proposes adding new syntax (old syntax to be
>>> deprecated/removed if this is approved in a followup intent) that looks
>>> like so:
>>>
>>> https://foo.bar
>>> https://baz.qux; sec-ch-width https://foo.bar;>
>>>
>>> This format tracks more closely with iframe’s “allow” serialization (and
>>> other familiar meta http-equiv pragmas, like CSP).
>>>
>>> On 6/14/22 1:02 PM, Ari Chivukula wrote:
>>>
>>> Contact emails
>>>
>>> aric...@chromium.org, miketa...@chromium.org, yoavw...@chromium.org
>>> 
>>>
>>> Prior Intent
>>>
>>>
>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/JQ68cvYuiQU/m/S_33YSqxCwAJ
>>>
>>> Specification
>>>
>>> https://github.com/WICG/client-hints-infrastructure/pull/109
>>>
>>> Summary
>>>
>>> There is existing HTML syntax to delegate client hints to third-party
>>> content which requires client information lost by user agent reduction
>>> .
>>> Example:
>>>
>>> https://foo.bar
>>> https://baz.qux), sec-ch-width=(https://foo.bar)">
>>>
>>>
>>>
>>> We shipped this syntax in M100
>>>  and got belated
>>> developer feedback
>>>  that
>>> it’s confusing. We reached the conclusion it’s not too late to change
>>> course due to low adoption
>>>  so
>>> far.
>>>
>>>
>>>
>>> This intent proposes a replacement syntax with the same feature set.
>>> Example:
>>>
>>> https://foo.bar
>>> https://baz.qux; sec-ch-width https://foo.bar;>
>>>
>>>
>>>
>>> Blink component
>>>
>>> Blink>Network>ClientHints
>>> 
>>>
>>>
>>>
>>> Motivation
>>>
>>> We’re switching from `name="accept-ch"` to `http-equiv="delegate-ch"` on
>>> advice
>>> 
>>> that `http-equiv` should be used when the value is impacting the processing
>>> model. We’re switching from syntax close to HTTP Permissions-Policy
>>> 
>>> to use syntax closer to the iframe allow attribute
>>> 
>>> at the request of developers
>>> .
>>>
>>>
>>>
>>> Although this change is coming after a launch in M100, usage
>>>  of
>>> the prior syntax is low (currently 0.16%) and it seems worth taking the
>>> opportunity to reduce developer confusion and increase standards compliance.
>>>
>>> TAG review
>>>
>>> https://github.com/w3ctag/design-reviews/issues/702
>>>
>>> Compatibility
>>>
>>> We will not be removing either prior syntax, so there is no
>>> compatibility risk.
>>>
>>>
>>> Interoperability
>>>
>>> Other engines haven’t shipped the previous delegation syntax, so are
>>> unlikely 

Re: [blink-dev] Intent to Ship: Add onbeforeinput global event handler content attribute

[Mike West]

LGTM3.

+Daniel Vogelheim  to make sure any implications
for Trusted Types and/or the Sanitizer API are taken care of.

-mike


On Fri, Jul 8, 2022 at 6:28 PM Mason Freed  wrote:

>
>
> On Friday, July 8, 2022 at 9:25:25 AM UTC-7 Mason Freed wrote:
>
>> On Thursday, July 7, 2022 at 6:58:53 PM UTC-7 fw...@igalia.com wrote:
>>
>>> On 07/07/2022 22:17, Mason Freed wrote:
>>>
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ? Yes
>>>
>>> H Mason,
>>>
>>> Do you have any patch pending to update wpt/interfaces/html.idl?
>>>
>> Thanks for the question. My understanding of html.idl (see the top of the
>> file) is that it gets autogenerated based on landed specs. And I would have
>> thought that since the spec now contains `beforeinput` in this section
>> , that would be enough.
>> However, since that landed about a month ago, seems like not. Let me know
>> if you know the proper way to kick webref 
>> to do this, and I'm happy to do it.
>>
>
> Thanks to jarhar@ I found the answer to this question. Turns out there's
> something broken on that system, so no changes have landed for just over a
> month. Here's the latest PR which does include `beforeinput`
> .
> So seems like we just need a wait a bit for that to get resolved.
>
>
>> Thanks,
>> Mason
>>
>>
>>
>>
>>>
>>> This is used in some generic tests for global event handlers e.g.
>>>
>>> html/webappapis/scripting/events/event-handler-all-global-events.html
>>> mathml/relations/html5-tree/math-global-event-handlers.tentative.html
>>>
>>> --
>>> Frédéric Wang
>>>
>>> --
> 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/2e4dafbd-3438-464e-8874-407e0b9651d7n%40chromium.org
> 
> .
>

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

Re: [blink-dev] Intent to Deprecate and Remove: Expect-CT

[Mike West]

LTGM2. Good luck with the removal.

-mike


On Fri, Jul 8, 2022 at 6:44 PM Yoav Weiss  wrote:

> LGTM1 to deprecate and remove.
> Please roll out the removal carefully. I'd similarly be surprised if the
> removal causes breakage, but I have been surprised before, so.. :)
>
> On Fri, Jul 8, 2022 at 6:41 PM Emily Stark  wrote:
>
>>
>> On Fri, Jul 8, 2022 at 9:34 AM Yoav Weiss  wrote:
>>
>>> What deprecation/removal timelines did you have in mind?
>>>
>>
>> Since there's no user-visible impact, I was hoping to do a console
>> message in M105 and then remove in M106.
>>
>>>
>>> On Fri, Jul 8, 2022 at 6:31 PM Emily Stark  wrote:
>>>
 Contact emailsest...@chromium.org

 ExplainerNone

 Specificationhttps://datatracker.ietf.org/doc/rfc9163

 Summary

 Expect-CT is an HTTP header that allowed websites to opt in to
 Certificate Transparency enforcement before it was enforced by default. It
 also has reporting functionality to help developers discover CT
 misconfigurations.


 Blink componentInternals>Network>DomainSecurityPolicy
 

 Motivation

 Expect-CT was designed to help transition to universal Certificate
 Transparency (CT) enforcement, by allowing high-value websites to opt in to
 CT enforcement/reporting for better security before CT enforcement was
 required (by Chrome) on all public websites. However, Expect-CT has now
 outlived its usefulness. Chrome requires CT on all public websites now, so
 there is no security value to Expect-CT anymore. Expect-CT was also
 designed to help site owners discover CT-related misconfigurations;
 however, now that CT is universally required, CT is generally configured in
 websites' certificates by certificate authorities and virtually never
 configured by individual site owners, thus Expect-CT has very limited value
 as a misconfiguration/debugging tool anymore either. No other browser has
 implemented Expect-CT so removing it is not an interoperability concern.


 Initial public proposal
 https://groups.google.com/a/chromium.org/g/blink-dev/c/tgn5R-58iek/m/Q6YCnu0RFQAJ

 TAG reviewn/a

 TAG review statusNot applicable

 Risks


 Interoperability and Compatibility


 No other browser has implemented Expect-CT or given signals that they
 intend to (to my knowledge). Expect-CT is not user-visible so removing the
 feature has no compatibility risk. Developers who are currently sending the
 header should stop doing so just to save the bytes on the wire.

 While the header is served on a large percent of requests (~6%), this
 is likely due to a small number of large providers that can be informed of
 the deprecation via 1:1 outreach.

>>>
>>> Are you planning to wait for usage to drop as a result of this outreach?
>>> Or are you fairly confident that removing will not break content due to
>>> some weird server side reliance on the header?
>>>
>>
>> I would be very very surprised if the removal caused any breakage, so I
>> think we can go ahead with the removal without waiting for usage to drop.
>> The outreach is really just a heads-up to allow websites to save some bytes
>> on serving the header and turn down any infrastructure they have in place
>> for receiving reports, but the feature is essentially a no-op right now so
>> removing it shouldn't cause any breakage.
>>
>>
>>>
>>>
 As described above, the header serves no security value any longer,
 removing it will have no user-visible effects, and the header provides
 extremely minimal debugging value to developers since developers are no
 longer responsible for serving their own CT information (100.00% of
 requests serve CT information directly embedded in the certificate, which
 developers are not responsible for configuring).

 *Gecko*: No signal

 *WebKit*: No signal

 *Web developers*: No signals

 *Other signals*:

 WebView application risks

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



 Debuggability

 We'll add a console message informing developers that the header
 will/has no effect and they should remove it.

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

 Flag name

 Requires code in //chrome?False

 Estimated milestones

 No milestones specified


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

 This intent message was generated by Chrome Platform Status
 

Re: [blink-dev] Intent to Ship: MathML

[Mike West]

I'm excited about shipping MathML. I don't think it's necessary for us to 
wait O(months) for printing to work correctly, but I do think it's critical 
for us to give users who try to print some way of understanding that the 
rendering failure is not their fault. It would be unfortunate if folks go 
through debugging, uninstalling/reinstalling printer drivers, etc. for 
something that we know isn't going to work *a priori*.

I'd be happy LGTMing any reasonable compromise for the short term. A 
variety of approaches could be reasonable: a warning note in the print 
dialog, jamming some "Aw, snap!" rendering into the printed page, a 
pre-printing `alert()` dialog, basically anything our friendly UX experts 
will approve.

-mike

On Tuesday, June 28, 2022 at 11:23:37 PM UTC+2 Brian Kardell wrote:

> [snip]
> > More about compatibility: Do you have any idea (guess really) of how
> > much of existing MathML content will "work" with just MathML Core? Is
> > it 99%, 90%, 50%, 10%?
>
> In addition to what Fred said about counters investigation,  I can add 
> that the MathML Refresh group (that spent about 2 years working toward this 
> and getting it back on a W3C rec track) was very interested in and focused 
> on this question.  We did a bunch of research, and we also asked people 
> with significant pools of MathML already to dig into some of it.   I guess 
> I can assure you that much effort spent toward finding an interoperable 
> subset that can give us a baseline for rendering the vast majority of 
> content that was actually achievable and yielded acceptable results with 
> 0-little effort for authors. 
>
> However,  it is a somewhat tricky question because, what does it mean to 
> "work" can vary (or maybe better, how does it 'fail').  So, for example, L1 
> does not include "math links". This turns out to be kind of trickily nested 
> in a whole bunch of related questions that would take some real additional 
> time to answer. Without answering them, you can still put a regular link 
> inside a token element.  Given that, if. you load up some older MathML that 
> includes links on the token elements, it will render the math, but not the 
> link. The working group decided that this was the right tradeoff, 
> because for many things, that's the most important part and it wasn't 
> getting done at all - so this is a dramatic improvement already. It fails 
> better. However, with L1 we now also have the tools to include, with very 
> little additional author effort just a little bit of transform or js 
> handlers to make 'work' like a link too (for purposes they care about) 
> until we can move beyond that.
>
> So, basically: It's hard to say with authority but the working group 
> itself has been both very cautious and pragmatic here.  They definitely 
> understand that even complete interoperability of L1 can't just make all 
> MathML ever written work.  They focused on making "the vast majority of 
> stuff great" and  making sure things outside that had a decent story too - 
> be that it "failing" in a better way natively or just having a very simple 
> remediation story, etc.
>
>
>
> On Saturday, June 25, 2022 at 8:09:25 AM UTC-4 fw...@igalia.com wrote:
>
>> On 24/06/2022 11:14, Daniel Bratell wrote: 
>> > 
>> > I'm really happy to see this coming along! Awesome work by everyone 
>> > involved! 
>> > 
>> Thanks! 
>> > 
>> > You mentioned fuzzy testing. Do the fuzzing tools have support for 
>> > mathml elements? If not, you should probably add a to-do item to teach 
>> > them. 
>> > 
>> MathML has been there for several years so I do expect (naively?) that 
>> fuzzers have some kind of support already. My understanding is that 
>> fuzzing tools can either generate data or "shuffle" from existing input. 
>> For the latter, we have now a bunch of WPT tests with MathML to feed the 
>> fuzzers and I believe these are particularly interesting to cover edge 
>> cases with CSS, JS, etc. For the former, I thought that was the case for 
>> https://github.com/MozillaSecurity/ or https://github.com/renatahodovan/ 
>> but can't find any up-to-date repo for MathML currently, so I agree we 
>> need to work on that. 
>> > 
>> > What is the situation for developers that learn about this and want to 
>> > start using it? Are there good resources for learning how to write 
>> > MathML? I think a feature like this also deserves some attention when 
>> > it lands. Maybe that will happen by itself, or maybe someone needs to 
>> > initiate it. That info should probably also mention initial 
>> > limitations like printing, (multi-column?) and non-Core. 
>> > 
>> Similarly, MathML has been there for a while so there is already a bunch 
>> of resource available about MathML (e.g. MDN to mention the obvious one) 
>> as wellas editors & converters to generate it, polyfills to cover 
>> browser's limitations, etc but I agree they will probably need a refresh 
>> since (1) we implement a core subset (2) we are moving to an 

Re: [blink-dev] Intent to Ship: CSS :modal Pseudo Class

[Mike West]

LGTM3.

-mike


On Wed, Jun 29, 2022 at 5:50 PM Manuel Rego Casasnovas 
wrote:

> LGTM2 too with Philip's requests.
>
> On 29/06/2022 17:48, Philip Jägenstedt wrote:
> > LGTM1 to ship this with the latest spec changes applied, and WPT
> > written and passing for that.
> >
> > On Wed, Jun 29, 2022 at 5:27 PM Manuel Rego Casasnovas 
> wrote:
> >>
> >> Does Chromium implementation match the spec resolution, so :modal
> >> applies to fullscreen too?
> >>
> >> Are there tests checking that?
> >>
> >> Cheers,
> >>   Rego
> >>
> >> On 27/06/2022 15:20, Jihwan Kim wrote:
> >>> I have updated the I2S contents including explainer, vendor signals
> >>> those are commented.
> >>> We may now progress this I2S.
> >>> thanks.
> >>>
> >>> 2022년 6월 24일 금요일 오전 4시 2분 49초 UTC+9에 Chris Harrelson님이 작성:
> >>>
> >>> The CSSWG just resolved yesterday that :modal should apply to
> >>> fullscreen, and that fullscreen should be modal. So I think this
> >>> intent is unblocked.
> >>>
> >>> On Wed, Jun 8, 2022 at 4:50 PM Jihwan Kim 
> wrote:
> >>>
> >>> Thanks for Chris Harrelson.
> >>> Once "should fullscreen be modal?" is resolved, I'll keep
> >>> progress this.
> >>> thanks.
> >>>
> >>> 2022년 6월 9일 목요일 오전 3시 0분 58초 UTC+9에 Chris Harrelson
> >>> 님이 작성:
> >>>
> >>> I've also added "should fullscreen be modal?" to the CSSWG
> >>> agenda. Once that is resolved this intent is ready to ship,
> >>> in my view.
> >>>
> >>> On Wed, Jun 8, 2022 at 10:59 AM Chris Harrelson
> >>>  wrote:
> >>>
> >>>
> >>> On Tue, May 31, 2022 at 1:21 AM Arthur Sonzogni
> >>>  wrote:
> >>>
> >>> Hello,
> >>> It would be nice if there was some repository or
> >>> documents were we could fill some security/privacy
> >>> questions. I will do it here instead.
> >>> How does this interacts with iframes? Do you know
> >>> where it might be defined in the spec? I remember
> >>> for the modal dialog, there was some "inertness"
> >>> attribute propagated toward parent/iframes. It was
> >>> shown it can be used to leak cross-site data, or it
> >>> can be used to create new communication channel. It
> >>> was found and fixed here:
> https://crbug.com/1293191
> >>> . I guess the two
> >>> features relies on the same mechanism and Chrome
> >>> might immune as result. Anyway, could you please
> >>> make sure the behavior is specified and show how it
> >>> doesn't create a cross-site leak?
> >>>
> >>>
> >>> You are correct that the same mechanism
> >>> prevented cross-site information leaks for "both". In
> >>> other words, thet modal dialog feature doesn't
> >>> propagate, due to the fix for issue 1293191.
> >>>
> >>> :modal is a pseudoclass state that only changes style
> >>> for a  element in the same document as the
> style
> >>> sheet using :modal. Therefore a cross-origin iframe
> >>> won't be able to change its document's state based on
> >>> :modal. So I don't see a way that this feature will
> >>> introduce new security or privacy issues. Let me know
> if
> >>> this doesn't fully answer your questions.
> >>>
> >>>
> >>> Filling
> >>> the
> https://w3ctag.github.io/security-questionnaire/
> >>> 
> is often
> >>> helpful as well ;-)
> >>>
> >>> On Thursday, May 26, 2022 at 6:51:19 PM UTC+2 Mike
> >>> Taylor wrote:
> >>>
> >>> On 5/26/22 9:35 AM, Mike Taylor wrote:
>  On 5/26/22 2:42 AM, Jihwan Kim wrote:
> >
> > 4. Gecko vendor signal : I set gecko's signal
> > to 'Shipped/Shipping' as the
> > doc(bit.ly/blink-signals
> > ) defines
> > 'Shipped/Shipping' as 'Link to public
> > documentation or bug/issue'. I'm not sure
> > which signal would be right if there is an
> > open issue.
> 
>  Thank for this feedback - I can see how that
>  is confusing. I updated the language to say
>  "Link to public documentation or bug/issue
>  

Re: [blink-dev] Intent to Ship: Writable directory prompts for the File System Access API

[Mike West]

LGTM2. Thank you for working with the permissions and UX teams to hammer
out a reasonable approach here.

-mike


On Mon, Jun 27, 2022 at 4:40 PM 'Austin Sullivan' via blink-dev <
blink-dev@chromium.org> wrote:

> PR is landed
>
> On Fri, Jun 24, 2022 at 3:09 PM Austin Sullivan  wrote:
>
>> I was waiting for approval on this I2S before landing, but clearly I had
>> my order of operations inverted :)
>>
>> Also I could've sworn I was already in the WICG, but for some reason the
>> IPR bot doesn't think I am. I've submitted another request...
>>
>> On Fri, Jun 24, 2022 at 11:49 AM Yoav Weiss 
>> wrote:
>>
>>>
>>>
>>> On Mon, Jun 13, 2022 at 1:58 PM 'Austin Sullivan' via blink-dev <
>>> blink-dev@chromium.org> wrote:
>>>
 Contact emailsasu...@chromium.org

 ExplainerNone

 Specificationhttps://github.com/WICG/file-system-access/pull/300

>>>
>>> Anything preventing us from landing the PR?
>>>
>>>


 Summary

 Allow returning a directory with both read and write permissions in a
 single prompt for the File System Access API. Currently
 showDirectoryPicker() always returns a read-only directory (after showing a
 read access prompt), requiring a second permission prompt to get write
 access. This double-prompt is a poor user experience and contributes to
 confusion and permission fatigue among users.


 Adds an optional "mode" option to DirectoryPickerOptions which can be
 specified as "read" or "readwrite".


 Blink componentBlink>Storage>FileSystem
 

 TAG reviewWe did not seek a TAG review given the small scope of this
 feature. This launch does not add any new capabilities, but merely provides
 the browser with enough information to combine two permission prompts into
 one.

 TAG review statusN/A

 Risks


 Interoperability and Compatibility



 *Gecko*: No signal

 *WebKit*: No signal

 *Web developers*: Strongly positive (
 https://github.com/WICG/file-system-access/issues/89)

 *Other signals*:

 WebView application risks

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

 No



 Debuggability

 N/A


 Will this feature be supported on all six Blink platforms (Windows,
 Mac, Linux, Chrome OS, Android, and Android WebView)?No - The File
 System Access API is not supported on Android

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

 Flag name

 Requires code in //chrome?False

 Tracking bughttps://crbug.com/1115632

 Launch bughttps://crbug.com/1213159

 Estimated milestones

 105


 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/6383970247770112

 This intent message was generated by Chrome Platform Status
 .

 --
 You received this message because you are subscribed to the Google
 Groups "blink-dev" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to blink-dev+unsubscr...@chromium.org.
 To view this discussion on the web visit
 https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADs-7rHzNmDAE89ZmOEBR5CNCGprOVUBasCjijADr1LxvAd_Qg%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/CADs-7rEz2YSh35tGs_hq1ENBZsp-1Q3kVfEv19Chwbh8gjXTmw%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 

Re: [blink-dev] Intent to Ship: navigateEvent.intercept()

[Mike West]

LGTM3.

-mike


On Wed, Jun 22, 2022 at 6:57 PM Mike Taylor  wrote:

> LGTM2
>
> On 6/22/22 12:23 PM, Chris Harrelson wrote:
>
> LGTM1
>
> On Tue, Jun 14, 2022 at 11:25 AM Nate Chapin  wrote:
>
>> Contact emails
>>
>> jap...@chromium.org, dome...@chromium.org
>>
>> Specification
>>
>> https://github.com/WICG/navigation-api/pull/235
>>
>> Summary
>>
>> intercept() works very similarly to the already existing
>> navigateEvent.transitionWhile(), except that instead of taking a mandatory
>> Promise, it takes an optional handler function. If a function is provided
>> and it returns a promise, navigation finish will be delayed until the
>> Promise resolves, just as transitionWhile() delays navigation finish for
>> its Promise.
>>
>> This address design problems with transitionWhile(), detailed in
>> https://github.com/WICG/navigation-api/issues/230#issuecomment-1137891972
>>
>> We will send a separate Intent to Deprecate and Remove for
>> navigateEvent.transitionWhile().
>>
>>
>> Blink component
>>
>> Blink>History
>> 
>>
>> TAG review
>>
>> https://github.com/w3ctag/design-reviews/issues/717
>>
>> TAG review status
>>
>> Issues open
>>
>> Risks
>>
>> Interoperability and Compatibility
>>
>> Most of the compatibility risk comes from the removal of
>> transitionWhile(), and will be discussed in that separate Intent. For those
>> migrating to intercept(), the main risk is that web developer "handling"
>> logic will run at a subtly different time, but per the explainer that time
>> will actually be less buggy in the usual case.
>>
>>
>> Gecko: No signal.
>> https://github.com/mozilla/standards-positions/issues/543 remains open
>> as the positions request for the original API.
>>
>> WebKit: No signal.
>> https://www.mail-archive.com/webkit-dev@lists.webkit.org/msg30257.html
>> remains open as the positions request for the original API.
>>
>> Web developers: Positive. The problem this was solving was discovered by
>> a web developer in https://github.com/WICG/navigation-api/issues/230,
>> and has some engagement there. The bonus of no longer having to pass an
>> empty promise also addresses some feedback we've heard in the past.
>>
>> Activation
>>
>> Any developer able to use navigateEvent.transitionWhile() should find
>> intercept() a modestly more usable substitute.
>>
>>
>> Security
>>
>> None different than transitionWhile()
>>
>>
>> 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?
>>
>> None, this should work identically on all platforms.
>>
>>
>> Debuggability
>>
>> Debugging should be no different than debugging transitionWhile().
>>
>>
>> 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
>> 
>> ?
>>
>> The navigation-api/ directory makes extensive use of transitionWhile(),
>> and we're updating it to use intercept() instead alongside implementation
>> of intercept().
>>
>>
>> Requires code in //chrome?
>>
>> False
>>
>> Tracking bug
>>
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1336000
>>
>> Estimated milestones
>>
>> M105
>>
>>
>> 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/5194055716700160
>>
>> This intent message was generated by Chrome Platform Status
>> .
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to blink-dev+unsubscr...@chromium.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACf%3D2LL04%2B1%2B6Ap5%3D-SoocDJYA2M8BvYai1STObqt26tduHTuw%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
> 

Re: [blink-dev] Intent to Deprecate and Remote: navigateEvent.transitionWhile()

[Mike West]

LGTM3.

-mike


On Wed, Jun 22, 2022 at 6:57 PM Mike Taylor  wrote:

> LGTM2
>
> On 6/22/22 12:24 PM, Chris Harrelson wrote:
>
> LGTM1
>
> On Tue, Jun 14, 2022 at 11:25 AM Nate Chapin  wrote:
>
>> Contact emails
>>
>> jap...@chromium.org, dome...@chromium.org
>>
>> Specification
>>
>> https://github.com/WICG/navigation-api/pull/235
>>
>> Summary
>>
>> transitionWhile() is being replaced by navigateEvent.intercept() due to
>> design flaws reported by developers.
>>
>> The flaws in transitionWhile() were discussed in
>> https://github.com/WICG/navigation-api/issues/230,
>>
>> the spec update to replace transitionWhile() with intercept() is at
>> https://github.com/WICG/navigation-api/pull/235, and the introduction of
>> intercept() has its own chromestatus entry at
>> https://chromestatus.com/feature/5194055716700160.
>>
>>
>> Blink component
>>
>> Blink>History
>> 
>>
>> Motivation
>>
>> transitionWhile() has design issues that have meant developers have found
>> it difficult to use effectively, detailed in
>> https://github.com/WICG/navigation-api/issues/230#issuecomment-1137891972
>>
>> intercept() is being introduced to provide a more usable API for the same
>> basic functionality of transitionWhile().
>>
>>
>> Initial public proposal
>>
>> https://github.com/WICG/navigation-api/pull/235
>>
>> TAG review
>>
>> https://github.com/w3ctag/design-reviews/issues/717
>>
>> TAG review status
>>
>> Issues open
>>
>> Risks
>>
>> Interoperability and Compatibility
>>
>> For those migrating to intercept(), the main risk is that web developer
>> "handling" logic will run at a subtly different time, but per the explainer
>> that time will actually be less buggy in the usual case.
>>
>> Also, transitionWhile() only recently shipped (M102). There are few
>> consumers of the API, and we are in contact with most of them already, so
>> we believe we can guide them on any migration challenges they might have.
>>
>> The overall use counter for the navigation API (
>> https://chromestatus.com/metrics/feature/timeline/popularity/4056) shows
>> 0.97% of pages on the web using any portion of the API, which provides
>> an upper bound on the potential breakage here. (That use counter also
>> counts various other entry points to the API, which are not being changed.)
>>
>> We plan to support both intercept() and transitionWhile() for 3 releases
>> to provide a migration period (adding intercept() in M105, removing
>> transitionWhile() in M108).
>>
>>
>> Gecko: No signal
>> https://github.com/mozilla/standards-positions/issues/543 remains open
>> as the positions request for the original API.
>>
>> WebKit: No signal
>> https://www.mail-archive.com/webkit-dev@lists.webkit.org/msg30257.html
>> remains open as the positions request for the original API.
>>
>> Web developers: Positive The problem this was solving was discovered by
>> a web developer in https://github.com/WICG/navigation-api/issues/230,
>> and has some engagement there.
>>
>> 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
>>
>> N/A
>>
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?
>>
>> No
>>
>>
>> Requires code in //chrome?
>>
>> False
>>
>> Tracking bug
>>
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1336000
>>
>> Estimated milestones
>>
>> Deprecate: M105. Remove: M108.
>>
>>
>> Link to entry on the Chrome Platform Status
>>
>> https://chromestatus.com/feature/5169970311856128
>>
>> This intent message was generated by Chrome Platform Status
>> .
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to blink-dev+unsubscr...@chromium.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACf%3D2LJ2ErzDF1O8eo2BrsW3y9MWQ3XbcFQGJov%3Dcd5q7%3DPgCw%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/CAOMQ%2Bw94z3Tb%3DMPBiG9MUszWz7art3gX1jqn3YvefG_Xwo8bMg%40mail.gmail.com
> 
> .

Re: [blink-dev] Intent to Deprecate and Remove: WebSQL in non-secure contexts

[Mike West]

I'm happy to see this moving forward, thanks for pushing it ahead!

That said, this seems like the kind of thing that's likely-enough to impact
enterprise that we should include a temporary opt-out to give ourselves
some wiggle room if it turns out that we're undercounting usage. Have y'all
already put something like that together?

-mike


On Fri, May 27, 2022 at 2:18 AM Ayu Ishii  wrote:

>
> *Contact emails*a...@chromium.org, jsb...@chromium.org,
> ajayrahate...@google.com
>
>
> *Specification*https://www.w3.org/TR/webdatabase/
>
>
> *Summary*We intend to deprecate and remove usage of WebSQL in non-secure
> contexts. Deprecation is targeted for M105 and removal is targeted for M107.
>
>
> *Blink component*Blink>Storage>WebSQL
> 
>
>
> *Motivation*The Web SQL Database standard was first proposed in April
> 2009 and abandoned in November 2010. Gecko never implemented this feature
> and WebKit deprecated this feature in 2019
> .
> The W3C encouraged those needing web databases to adopt Web Storage
>  or Indexed Database
> .
>
> WebSQL has been deprecated and removed
>  for
> third-party contexts in M97.
>
> We hope to entirely deprecate and remove WebSQL at some future point when
> usage is low enough.
>
>
> *TAG review*N/A
>
> Risks
> Based on usage measurements
> 
> rolled out in M97, 0.005% of page loads use WebSQL in a non-secure
> context.  Less than 0.01% of top sites have adopted this feature.
>
> Out of the 20 top sites listed for the month of April 2022, 11 of the
> sites use a feature detection library Modernizr 1.5
> , on a version released in 2010.
> This would create a test database to check feature availability. I was
> unable to reproduce the creation of other WebSQL databases outside of the
> one created by Modernizr on these sites. 4 sites that seem to use an outdated
> private mode detection script 
> which was intended for older versions of iOS. All the scripts I have found
> checked if window.openDatabase existed before usage, likely due to the lack
> of support in Gecko and WebKit.
>
> Interoperability and Compatibility
>
> Gecko: Never implemented
>
> WebKit: Deprecation shipped in iOS 13 and Safari 13
> 
>
> Web developers: No signals
>
>
> *Debuggability*N/A
>
> Is this feature fully tested by web-platform-tests
> 
> ?
> Not fully, one test
> 
> checks the availability of the feature.
>
>
> *Tracking bug*https://crbug.com/1212492
>
> Link to related intents
> Intent to Deprecate and Remove: WebSQL in third-party contexts
> 
>
>
> *Link to entry on the Chrome Platform Status*
> https://chromestatus.com/feature/5175124599767040
>
>
> --
> 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/bc5f407d-e6fe-4743-ae46-84541d271a92n%40chromium.org
> 
> .
>

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

Re: [blink-dev] Re: Intent to Deprecate and Remove: U2F API (Cryptotoken)

[Mike West]

I think that's what Martin's email suggests ("We would still like to close
new trial registrations on July 26, and grant renewals beyond July 26 only
to existing participants that contact us directly."). Assuming that's the
case, a two milestone extension doesn't seem overly burdensome from a
burn-in perspective.

If y'all can communicate that deadline to your partners in a way that they
can accept, this extension LGTM.

-mike


On Thu, May 19, 2022 at 1:47 PM Yoav Weiss  wrote:

> Is it possible to keep the trial alive for 2 more milestones, but disable
> new registrations?
>
> On Thu, May 19, 2022 at 1:21 AM Martin Kreichgauer 
> wrote:
>
>> Greetings blink-dev,
>>
>> I would like to request a second extension of the U2FSecurityKeyAPI
>> deprecation trial. We are continuously gathering direct user feedback about
>> this deprecation, and virtually all trial participants we have been in
>> contact with have either migrated off of U2F already or are expecting to do
>> so ahead of the current July 26 deadline. However, one enterprise user with
>> a very sizable security key deployment across its workforce has told us
>> that they might not be able to fully migrate a number of stragglers by that
>> time, and asked whether we could extend the deadline by 8 weeks in order to
>> minimize disruptions for them.
>>
>> We're therefore asking to push back removal of the U2F API by two
>> milestones (M106 instead M104), and extend the deprecation trial until
>> September 20, 2022. We would still like to close new trial registrations on
>> July 26, and grant renewals beyond July 26 only to existing participants
>> that contact us directly.
>>
>> Since the upcoming removal of extensions manifest V2 from Chrome presents
>> a hard technical deadline for removing Cryptotoken, further extensions of
>> this trial would be extremely unlikely.
>>
>> Cheers,
>> Martin
>>
>> On Thursday, September 23, 2021 at 11:50:12 AM UTC-7 yoav...@chromium.org
>> wrote:
>>
>>> Thanks for clarifying!
>>>
>>> On Thu, Sep 23, 2021 at 7:45 PM Martin Kreichgauer 
>>> wrote:
>>>
 Thanks! Just to be clear, the deprecation trial is beginning with M95,
 but it would only be *required* by M98 when we disable the U2F API by
 default. M104 is where we plan to delete the API, so M103 would be the last
 release where the deprecation trial is functional.

 On Thu, Sep 23, 2021 at 5:18 AM Yoav Weiss 
 wrote:

> So IIUC, the deprecation trial would run from M98-M104. That seems
> like a reasonable time period to give to folks and enable them to adjust.
> Still LGTM.
>
> On Wed, Sep 22, 2021 at 10:32 PM 'Martin Kreichgauer' via blink-dev <
> blin...@chromium.org> wrote:
>
>> Dear blink-dev,
>>
>> I wanted to provide an update on our progress with the U2F API
>> deprecation effort and request a short extension for removal of the API 
>> and
>> the end date of the Reverse Origin Trial.
>>
>> First, the changes originally announced for Chrome 94 are now
>> scheduled to ship instead with Chrome 95. These changes include gating of
>> U2F API requests behind a permission prompt, deprecation warnings logged 
>> to
>> the developer console, and  a Reverse Origin Trial
>> 
>> .
>>
>> We still plan to disable the U2F API by default with Chrome 98.
>>
>> We also have been in close contact about this deprecation with
>> partners who still rely on the U2F API. In some of these conversations,
>> partners asked us to allow a little more time for them to migrate their
>> websites to the WebAuthn. We therefore would like to push back removal of
>> the U2F API to Chrome 104, and to extend the Reverse Origin Trial to the
>> same time period.
>>
>> Thanks,
>> Martin
>>
>>
>> On Friday, June 11, 2021 at 11:34:24 AM UTC-7 Martin Kreichgauer
>> wrote:
>>
>>> Primary eng (and PM) emails
>>>
>>> mart...@google.com, a...@chromium.org
>>>
>>> Summary
>>>
>>> We want to deprecate and remove the legacy U2F API for interacting
>>> with security keys. (But not U2F security keys themselves, which will
>>> continue to work.)
>>>
>>> Affected sites should migrate to the Web Authentication API
>>> (WebAuthn). Credentials that were originally registered via the U2F API 
>>> can
>>> be challenged via WebAuthn. USB security keys that are supported by the 
>>> U2F
>>> API are also supported by the WebAuthn API.
>>>
>>> Motivation
>>>
>>> U2F is Chrome’s original security key API. It allows sites to
>>> register public key credentials on USB security keys and challenge them 
>>> for
>>> building phishing-resistant two-factor authentication systems. U2F never
>>> became an Open Web standard and was subsumed by WebAuthn (launched
>>> in M67 

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

[Mike West]

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

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

-mike


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

>
>
> On Thu, May 12, 2022 at 12:12 AM Łukasz Anforowicz 
> wrote:
>
>>
>>
>> On Wed, May 11, 2022 at 12:24 AM Yoav Weiss 
>> wrote:
>>
>>>
>>>
>>> On Wed, May 11, 2022 at 2:56 AM Łukasz Anforowicz 
>>> wrote:
>>>
>>>> On Mon, May 9, 2022 at 11:35 PM Mike West  wrote:
>>>>
>>>>> Hey Łukasz,
>>>>>
>>>>> I'm in favor of shipping this change. It will harden our defenses
>>>>> against side-channel attacks at minimal web-visible cost, and clear a path
>>>>> for a WebKit implementation that some folks have expressed interest in 
>>>>> (see
>>>>> the CORB thread on webkit-dev@
>>>>> <https://lists.webkit.org/pipermail/webkit-dev/2022-March/032167.html>).
>>>>> That said, I have two questions:
>>>>>
>>>>>1. The ORB telemetry results - Mar 2022
>>>>>
>>>>> <https://docs.google.com/document/d/1MbYQbL4WQyZdCQcZcKyzxHA0UxbHTC0O4bQXFgm8o6A/edit?usp=sharing>
>>>>>  document
>>>>>suggests a substantially smaller impact than the 0.01% number you 
>>>>> mention a
>>>>>few times in this intent: 0.002% - 0.006% (it would be ideal if you 
>>>>> could
>>>>>create a public version of that document :) ). Can you help me 
>>>>> understand
>>>>>the distinctions between those measurements?
>>>>>
>>>>> 0.01% is just a conservative rounding of the 0.002%-0.006% numbers
>>>> from the other doc.  (Sorry about that... https://xkcd.com/2585/ seems
>>>> somewhat applicable I guess...)
>>>>
>>>
>>> Also, that number is presented as a percentage from HTTP requests. Do
>>> you have the data on how this presents itself as a percentage of page views?
>>>
>>
>> No, we don't have such a breakdown of the data.
>>
>> One reason is that ORB (and code gathering ORB's telemetry data) is
>> hosted inside the NetworkService process which is mostly unaware of pages
>> and page views (I think;  I guess UKM would require knowing about pages,
>> but I wasn't able to find UKM-related code under //services/network).  We
>> could try to count the various ORB outcomes per URLLoaderFactory (which
>> roughly corresponds to a single HTML frame;  I note that in the past
>> about:blank frame might have shared a URLLoaderFactory with their
>> opener/parent/initiator - that's probably ok), but getting this data would
>> take time...
>>
>
> OK, would it be fair to assume that at least for no-cors range requests
> (most likely video/audio requests), there would be more than one per page
> view, and hence we could expect page view based %ages to be significantly
> lower?
>
>
>>
>> If the majority of these requests are range requests, there's reason to
>>> believe there was more than one per page view.
>>>
>>
>> We can try to estimate how many responses report HTTP 206 status code.  I
>> looked at Net.HttpResponseCode and "206: Partial Content" accounts for
>> around 0.35% - 1.13% of all HTTP responses (depending on the platform I
>> looked at).  I've added more detailed data + links to a new section in the 
>> ORB
>> telemetry results - Mar 2022
>> <https://docs.google.com/document/d/1MbYQbL4WQyZdCQcZcKyzxHA0UxbHTC0O4bQXFgm8o6A/edit?usp=sharing>
>>  document.
>>
>>>
>>>
>>>>
>>>>
>>>>>
>>>>>1.
>>>>>2. The current specification situation is confusing.
>>>>>https://fetch.spec.whatwg.org/#corb doesn't match what Chrome
>>>>>does, and https

Re: [blink-dev] Intent to Ship: Container Queries

[Mike West]

LGTM3.

-mike


On Wed, May 11, 2022 at 11:04 AM Yoav Weiss  wrote:

> LGTM2
>
> It's great to see y'all working with the broader community on this!!
>
> On Wednesday, May 11, 2022 at 10:09:23 AM UTC+2 Kent Tamura wrote:
>
>> LGTM1. This has very strong signals!
>>
>>
>> On Tue, May 10, 2022 at 9:56 PM Anders Hartvoll Ruud <
>> andr...@chromium.org> wrote:
>>
>>> Contact emails
>>>
>>> andr...@chromium.org, futh...@chromium.org
>>>
>>> Explainer
>>>
>>> https://css.oddbird.net/rwd/query/explainer/
>>>
>>> Specification
>>>
>>> https://drafts.csswg.org/css-contain-3/#container-queries
>>>
>>> Scope
>>>
>>> This intent covers:
>>>
>>>
>>>-
>>>
>>>Size queries
>>>
>>>-
>>>
>>>Container query length units
>>>
>>>-
>>>
>>>Inline-size containment
>>>
>>>
>>>
>>> However, it does not cover:
>>>
>>>-
>>>
>>>Style queries
>>>. (More
>>>about style queries further down in the email).
>>>-
>>>
>>>Printing support. That means @container rules will always evaluate
>>>to “false” for printing. Printing will be supported when LayoutNGPrinting
>>>ships.
>>>
>>>
>>> Note that this intent depends on full LayoutNG support (minus printing).
>>>
>>> Summary
>>>
>>> Container queries are similar to @media queries, except that they
>>> evaluate against the size of an element instead of the size of the
>>> viewport. This allows authors to create components that respond to the
>>> available space within a layout.
>>>
>>> Example:
>>>
>>> /* Use display:block by default, but switch to
>>>
>>>display:flex if there’s enough space. */
>>>
>>> .component { container-type: inline-size; }
>>>
>>> .component > main { display: block; }
>>>
>>> @container (inline-size >= 800px) {
>>>
>>>   .component > main { display: flex; }
>>>
>>> }
>>>
>>> Blink component
>>>
>>> Blink>CSS
>>> 
>>>
>>> TAG review
>>>
>>> https://github.com/w3ctag/design-reviews/issues/592
>>>
>>> TAG review status
>>>
>>> Closed without any issues.
>>>
>>> Risks
>>>
>>> Interoperability and Compatibility
>>>
>>> Gecko: In development (
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1744221)
>>>
>>> See implementation activity reachable from that bug.
>>>
>>> WebKit: In development (
>>> https://developer.apple.com/safari/technology-preview/release-notes/#:~:text=Enabled%20CSS%20Container%20Queries%20by%20default
>>> )
>>>
>>> Web developers: Strongly positive (
>>> https://2021.stateofcss.com/en-US/opinions/currently_missing_from_css_wins
>>> )
>>>
>>> Other signals:
>>>
>>> WebView application risks
>>>
>>> Does this intent deprecate or change behavior of existing APIs, such
>>> that it has potentially high risk for Android WebView-based applications?
>>> N/A
>>>
>>>
>>> Debuggability
>>>
>>> Inspector support is implemented, and will be shipped at the same time.
>>>
>>> DevTools: Container Queries tooling
>>> 
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?
>>>
>>> Yes
>>>
>>> https://wpt.fyi/results/css/css-contain/container-queries
>>> 
>>>
>>> https://wpt.fyi/results/css/css-contain/contain-inline-size*
>>> 
>>>
>>> Some WPTs are currently failing in Blink.
>>>
>>> We plan to fix the following failures before shipping:
>>>
>>>
>>>-
>>>
>>>https://crbug.com/1273913 ::first-line dynamic update in outer
>>>container for container queries fail
>>>-
>>>
>>>https://crbug.com/1322881 Intrinsic sizing not working for replaced
>>>elements with contain:inline-size
>>>
>>>
>>> We do not plan to fix the following issues before shipping:
>>>
>>>
>>>-
>>>
>>>https://crbug.com/1302630 Support style() queries
>>>-
>>>
>>>   Will not be shipped now.
>>>   -
>>>
>>>https://crbug.com/882385 Style containment content quotes must be
>>>scoped to the element's sub-tree
>>>-
>>>
>>>   None of the engines support style containment for quotes, and we
>>>   have existing correctness issues.
>>>   -
>>>
>>>https://crbug.com/1281318 Changing border-box size of orthogonal
>>>flow with percentage padding does not re-layout correctly
>>>-
>>>
>>>   Layout bug independent from Container Queries.
>>>
>>>
>>> Legacy layout issues (will be fixed by fully 

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

[Mike West]

LGTM2.

-mike


On Tue, May 10, 2022 at 12:37 AM Mike Taylor  wrote:

> Hey Mustaq - welcome back. :)
>
> Thanks for the answers, and for requesting the missing WebKit position.
>
> LGTM1
>
> On 5/9/22 5:04 PM, Mustaq Ahmed wrote:
>
> Hi Mike:
>
> Sorry for the delay due to vacation etc!  Below are my answers to your
> queries.  Note that we are still asking for M103, so we will be prompt now
> :)
>
> > Does this only work for standard requestFullscreen, or will it work for
> webkitRequestFullscreen as well?
>
> This covers all forms: we are proposing changes in the core algorithm for
> request-fullscreen, regardless of the JS interface used to call it.
>
> >> Gecko: Positive (
> https://github.com/mozilla/standards-positions/issues/565, also see:
> https://github.com/WICG/capability-delegation/issues/10)
> > I don't think these quite count as official Positive signals (but yes,
> the comments from Anne are promising!). Can we ping the standards-position
> issue and ask for one?
>
> See the recent comments in the issue asking for Gecko's position, thanks.
> https://github.com/mozilla/standards-positions/issues/565
>
> >> WebKit: No signal
> > Have we asked? I looked at the Payment Request, and it seems like we
> didn't, but maybe I'm looking in the wrong spot. If not, can we?
>
> I missed this with the intent for payment, sorry!  Filed a single request
> to cover both payment and fullscreen capabilities:
> https://lists.webkit.org/pipermail/webkit-dev/2022-May/032221.html
>
> >> Is this feature fully tested by web-platform-tests?
> >> Not yet
> > Is there something missing to test this (or capability detection in
> general), or is it just that you haven't written the WPTs yet?
>
> We hadn't written a WPT at that time.  We have one under review now:
> https://github.com/web-platform-tests/wpt/pull/34004
>
> Mustaq
>
>
> On Sun, May 8, 2022 at 11:07 PM Ajay Rahatekar 
> wrote:
>
>> +Ajay Rahatekar
>>
>> On Monday, April 25, 2022 at 12:29:29 PM UTC-7 mike...@chromium.org
>> wrote:
>>
>>> Hi Mustaq,
>>>
>>> On 4/21/22 11:05 AM, Mustaq Ahmed wrote:
>>>
>>> Contact emails
>>>
>>> mus...@chromium.org, m...@chromium.org
>>> Explainer
>>>
>>> https://github.com/WICG/capability-delegation
>>> Specification
>>>
>>> https://wicg.github.io/capability-delegation/spec.html
>>>
>>> (Work in progress for fullscreen algorithm change:
>>> https://github.com/WICG/capability-delegation/pull/28)
>>> Design doc
>>>
>>>
>>> https://docs.google.com/document/d/1ax54Lf2W3_TovVOj35duKTbcOlXe-nJ-KQdWiy1Ye0c
>>> Summary
>>>
>>> This feature is based on the general delegation mechanism (
>>> https://chromestatus.com/feature/5708770829139968) shipped on M100.
>>>
>>> Fullscreen Capability Delegation allows a Window to transfer the ability
>>> to call requestFullscreen() to another Window it trusts after relinquishing
>>> the transient user activation at the sender Window.
>>>
>>> Does this only work for standard requestFullscreen, or will it work for
>>> webkitRequestFullscreen as well?
>>>
>>> Blink component
>>>
>>> Blink>Fullscreen
>>> 
>>> TAG review
>>>
>>> Covered by the review for the general delegation mechanism:
>>> https://github.com/w3ctag/design-reviews/issues/655
>>> TAG review status
>>>
>>> Covered by the approval for the general delegation mechanism:
>>> https://github.com/WICG/capability-delegation/pull/23
>>> Risks
>>>
>>> Interoperability and Compatibility risks remain unchanged from the
>>> general delegation mechanism; see that intent here:
>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/PHT_2X7oRBE/m/gR9UiZxBAQAJ
>>> External signals
>>>
>>> Gecko: Positive (
>>> https://github.com/mozilla/standards-positions/issues/565, also see:
>>> https://github.com/WICG/capability-delegation/issues/10)
>>>
>>> I don't think these quite count as official Positive signals (but yes,
>>> the comments from Anne are promising!). Can we ping the standards-position
>>> issue and ask for one?
>>>
>>> WebKit: No signal
>>>
>>> Have we asked? I looked at the Payment Request, and it seems like we
>>> didn't, but maybe I'm looking in the wrong spot. If not, can we?
>>>
>>> Web developers: Positive (https://crbug.com/931966#c5)
>>> Debuggability
>>>
>>> This remains unchanged from the general intent:
>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/PHT_2X7oRBE/m/gR9UiZxBAQAJ
>>> Ongoing technical constraints
>>>
>>> None.
>>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>>> Linux, Chrome OS, Android, and Android WebView)?
>>>
>>> Yes
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?
>>>
>>> Not yet
>>>
>>> Is there something missing to test this (or capability detection in
>>> general), or is it just that you haven't written the WPTs yet?
>>>
>>> Flag name
>>>
>>> 

Re: [blink-dev] Intent to Ship: "deflate-raw" on compression and decompression streams

[Mike West]

LGTM1. This seems like a logical extension of the existing compression
streams mechanism that was discussed at the time, delayed only due to
prioritization, not design considerations. It makes a common use case
simpler for developers, and does so in a way that's consistent with the
rest of the API. Good luck getting it out the door!

-mike


On Mon, May 9, 2022 at 4:46 AM Yutaka Hirano  wrote:

>
>
> On Sat, May 7, 2022 at 8:24 AM Mike Taylor  wrote:
>
>> On 5/6/22 8:10 AM, Yutaka Hirano wrote:
>>
>> Contact emails
>>
>> yhir...@chromium.org
>>
>> Explainer
>>
>> None
>>
>> Specification
>>
>> https://wicg.github.io/compression/
>>
>> https://github.com/wicg/compression/pull/43 (spec PR)
>>
>> https://chromium-review.googlesource.com/c/chromium/src/+/3586945 (impl
>> and tests)
>>
>> Summary
>>
>> Add a new compression format, "deflate-raw", to give web developers
>> access to the raw deflate stream without any headers or footers. This is
>> needed, for example, to read/write zip files.
>>
>>
>> Blink component
>>
>> Blink>Network>StreamsAPI
>> 
>>
>> TAG review
>>
>> This is subtle enough for a separate TAG review.
>>
>> Do you intend to file one? Or is the above missing a "not"?
>>
>
> Sorry for the unclearness, I wanted to say that we don't need a TAG review
> for this feature because this is a very small feature.
>
>>
>> TAG review status
>>
>> Not applicable
>>
>> Risks Interoperability and Compatibility
>>
>> This is a new addition and doesn’t change any existing behaviors.
>>
>> Gecko: No signal
>>
>> (See the bottom of
>> https://github.com/mozilla/standards-positions/issues/207)
>>
>> I pinged that thread to ask if they would prefer us to open a new issue -
>> Compression Streams was marked as "worth prototyping", but that was before
>> "deflaw-raw" existed in the spec.
>>
>>
>> WebKit: No signal
>>
>> (See https://lists.webkit.org/pipermail/webkit-dev/2022-May/032213.html)
>>
>> Web developers: Positive
>>
>> https://github.com/wicg/compression/issues/25
>>
>> Google Sheets 
>>
>> Google sheets team uses zipping for conversion (client side) of google
>> sheet into different formats such as xlsx. Browser native
>> compression/decompression stream apis have much better performance than
>> using any js library for zipping.
>>
>> With support for “deflate-raw” format, we are able to use
>> compression/decompression stream apis for compression of files during
>> zipping in a much simpler way compared to “gzip”, “deflate” format which
>> required workarounds on our side.
>>
>>
>> Other signals:
>>
>> WebView application risks
>>
>> None.
>>
>>
>> Debuggability
>>
>> None
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?
>>
>> Yes
>>
>> Flag name
>>
>> Requires code in //chrome?
>>
>> False
>>
>> Tracking bug
>>
>> https://crbug.com/1271220
>>
>> Estimated milestones
>>
>> 103
>>
>> Anticipated spec changes
>>
>> None
>>
>>
>> Link to entry on the Chrome Platform Status
>>
>> https://chromestatus.com/feature/5172771293233152
>>
>> Links to previous Intent discussions
>>
>> Intent to prototype:
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABihn6GYcF5VsvfgEDpYL0rCvxQV9phxwFtJ-FxbTEbqPtJxbg%40mail.gmail.com
>> 
>>
>>
>> This intent message was generated by Chrome Platform Status
>> .
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to blink-dev+unsubscr...@chromium.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABihn6FXZjL0X-j6_ckQfcbTWFDHoTWJkd0_cLE82juYrUkVpw%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/CABihn6F3bEt9b0U2BGgPrfs%2BetdtfYj-BQuKvHG%3D-CmDELyt-g%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 

Re: [blink-dev] Intent to Prototype + Ship: User Activation Requirement for SPC Credential Enrollment

[Mike West]

LGTM2.

-mike


On Tue, May 10, 2022 at 8:01 PM Mike Taylor  wrote:

> LGTM1 - this seems like a useful change. Thanks for involving partners.
>
> On 5/5/22 12:23 PM, Nick Burris wrote:
>
> Contact emails
>
> nbur...@chromium.org, rous...@chromium.org, smcgr...@chromium.org
>
> Explainer
>
> SPC explainer:
> https://github.com/w3c/secure-payment-confirmation/blob/main/explainer.md
>
> Specification
>
> SPC specification: https://w3c.github.io/secure-payment-confirmation/
>
> Design docs
>
> N/A
>
> Summary
>
> This intent is to add a user activation requirement for Secure Payment
> Confirmation (SPC) credential enrollment in a cross-origin iframe to help
> mitigate a privacy issue (see w3c/secure-payment-confirmation#128
>  for
> discussion of a potential identity tracking attack).
>
> Original feature summary: Secure payment confirmation augments the
> payment authentication experience on the web with the help of WebAuthn. The
> feature adds a new 'payment' extension to WebAuthn, which allows a relying
> party such as a bank to create a PublicKeyCredential that can be queried by
> any merchant origin as part of an online checkout via the Payment Request
> API using the 'secure-payment-confirmation' payment method.
>
> Blink component
>
> Blink>Payments
> 
>
> TAG review
>
> SPC TAG review: https://github.com/w3ctag/design-reviews/issues/675
>
> TAG review status
>
> Closed (Resolution: satisfied)
>
> Interoperability and Compatibility
>
> While adding a new requirement for user activation is technically a
> breaking change, we are confident in this change as the feature is expected
> to be used in a payment flow where the user has provided some form of input
> to continue. We have confirmed with the external partners who are using
> this feature that they do currently have a user activation.
>
> Gecko: No signal (
> https://github.com/mozilla/standards-positions/issues/570) Historically
> (>1 year old) positive signal from informal conversation in W3C Payment
> Handler meetings. However Firefox have since not been involved in the API
> development.
>
> WebKit: No signal (
> https://lists.webkit.org/pipermail/webkit-dev/2021-August/031956.html)
>
> Web developers: Positive (
> https://lists.w3.org/Archives/Public/public-payments-wg/2021Aug/0005.html)
> Support and involvement in API development from multiple web developers and
> payment industry partners. Both Stripe and AirBnB have publicly stated that
> they have either completed or are in the process of
> prototyping/experimenting with SPC
>
>
> Debuggability
>
> Existing devtools debugging features should cover SPC (e.g. breakpoints,
> console, etc)
>
> Is this feature fully tested by web-platform-tests
> 
> ?
>
> Yes, coverage for the user activation requirement will be added to the
> existing test suite:
>
>
> https://wpt.fyi/results/secure-payment-confirmation?label=master=experimental
>
> Flag name
>
> N/A
>
> Requires code in //chrome?
>
> No
>
> Tracking bug
>
> User activation bug: https://crbug.com/1322603
>
> Original feature bug: https://crbug.com/1124927
>
> Launch bug
>
> Original SPC launch bug:
> https://bugs.chromium.org/p/chromium/issues/detail?id=1236570
>
> We believe this is a small enough change to an existing feature that it
> doesn’t require its own launch bug.
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/guide/edit/5104475634139136
>
> Links to previous Intent discussions
>
> Intent to Prototype v1:
> https://groups.google.com/a/chromium.org/d/topic/blink-dev/myUR5gyd5Js/discussion
>
> Intent to Experiment v2:
> https://groups.google.com/a/chromium.org/g/blink-dev/c/6Dd00NJ-td8
>
> Intent to Ship v2:
> https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/U5K69fbA6SU
>
>
> This intent message was generated by Chrome Platform Status
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADvKJHND4_zciu4u2EyuXrfr%2Bk9TmUQyKbeYJy%2BsuUtH3UF7_w%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
> 

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

[Mike West]

Hey Łukasz,

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

   1. The ORB telemetry results - Mar 2022
   

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

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

Thanks!

-mike


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

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

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

[Mike West]

LGTM3.

-mike


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

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

Re: [blink-dev] Intent to Experiment: Fenced frames

[Mike West]

On Monday, May 2, 2022 at 8:48:53 PM UTC+2 Shivani Sharma wrote:

> Thanks Yoav!
>
> On Mon, May 2, 2022 at 7:27 AM Yoav Weiss  wrote:
>
>>
>>
>> On Sat, Apr 30, 2022 at 12:31 AM Shivani Sharma  
>> wrote:
>>
>>> Contact emails
>>>
>>> shivani...@chromium.org, d...@chromium.org, jkar...@chromium.org
>>>
>>> Explainer
>>>
>>> https://github.com/WICG/fenced-frame/tree/master/explainer
>>>
>>> Specification
>>>
>>> https://wicg.github.io/fenced-frame/ (a rough shell at this point)
>>>
>>> Summary
>>>
>>> In a web that has its cookies and storage partitioned by top-frame site, 
>>> there are occasions (such as Interest group based advertising 
>>>  or Conversion Lift Measurements 
>>> )
>>>  
>>> when it would be useful to display content from different partitions in the 
>>> same page. This can only be allowed if the documents that contain data from 
>>> different partitions are isolated from each other such that they're 
>>> visually composed on the page, but unable to communicate with each other. 
>>> Iframes do not suit this purpose since they have several communication 
>>> channels with their embedding frame (e.g., postMessage, URLs, size 
>>> attribute, etc.). We propose fenced frames, a new element to embed 
>>> documents on a page, that explicitly prevents communication between the 
>>> embedder and the frame.
>>>
>>>  
>>>
>>> This intent to experiment is scoped to the two initial modes of fenced 
>>> frames:
>>>
>>>- 
>>>
>>>Opaque-ads: 
>>>
>>> https://github.com/WICG/fenced-frame/blob/master/explainer/modes.md#opaque-ads
>>>- 
>>>
>>>Default:
>>>
>>>
>>> https://github.com/WICG/fenced-frame/blob/master/explainer/modes.md#default-mode
>>>
>>>  
>>> Blink component
>>>
>>> Blink>FencedFrames 
>>> 
>>>
>>> TAG review
>>>
>>> https://github.com/w3ctag/design-reviews/issues/735
>>>
>>> TAG review status
>>>
>>> Pending
>>>
>>> Risks
>>> Interoperability
>>>
>>> Gecko: No signal
>>>
>>> WebKit: No signal
>>>
>>
>> Might be good to ask for signals.
>>
>
> Sounds good. @Dominic Farolino  is planning to reach 
> out to the relevant mailing groups for both the browsers and will update 
> here once we have reached out.  
>
>>  
>>
>>>
>>> Edge: Edge is also exploring interest group based advertising, namely 
>>> with the PARAKEET proposal 
>>> .  
>>> PARAKEET, similar to TURTLEDOVE, relies on fenced frames for rendering the 
>>> ad in the opaque-ads mode and are interested in collaborating (comment 
>>> on WICG issue 
>>> ).
>>>
>>> Web developers: Fenced frames (specifically the opaque-ads mode) are 
>>> designed as a requirement for certain Privacy Sandbox APIs, like FLEDGE 
>>> .
>>>  
>>> There is significant interest in FLEDGE from many web advertising 
>>> technology developers. WICG FLEDGE calls 
>>>  are well attended and 
>>> fenced frames have sometimes been discussed with developers as part of 
>>> those calls.
>>>
>>> Compatibility risks
>>>
>>> Fenced frames do not deprecate or change existing web behavior, so there 
>>> should be no compatibility risk.
>>>
>>> From other browsers' perspective, there may be medium-term 
>>> interoperability risk with regards to having an architecture that enables 
>>> the separation of fenced frames from the embedding page. Chrome's fenced 
>>> frame design is based on a significant architecture project that makes this 
>>> possible (Multiple Page Architecture 
>>> 
>>> ).
>>>
>>> (Note that there have been discussions with other browsers for fenced 
>>> frames in the context of other use cases like unpartitioned storage access 
>>> e.g. this issue , 
>>> but that is not applicable to this fenced frame mode.)
>>>
>>>  
>>>
>>>   Security
>>>
>>> Security considerations 
>>> are
>>>  
>>> detailed here 
>>> 
>>> .
>>>
>>> Privacy
>>>
>>> Privacy considerations are detailed here 
>>> 
>>> .
>>>
>>> Browser Performance
>>>
>>> In the current implementation, there isn’t a significant performance 
>>> concern but we will be doing performance analysis when we do implement 
>>> enhanced process isolation for fenced 

Re: [blink-dev] Intent to Deprecate and Remove: Battery Status API in Insecure Origins

[Mike West]

Yes, I’m still ok with this plan. The risk exists, but seems both
reasonably researched and reasonably low. So, still LGTM.


-mike

On Fri 29. Apr 2022 at 13:23 Raphael Kubo da Costa <
raphael.kubo.da.co...@intel.com> wrote:

> Just one clarification: the spot-check covers ~80 websites still using the
> Battery Status API in insecure contexts (out of a total of 90-100 if you
> include those in chromestatus.com that no longer do).
>
>
> On 29-04-2022 12:52, Yoav Weiss wrote:
>
> So, to summarize:
>
>- Spot checking ~50 examples showed none that actually broke. Most
>seem to be coming from a small number of sources.
>- There's no way for us to remove the feature from non-secure contexts
>without breaking feature detection while also warning users about it going
>away.
>
> Given the first point, I'm fine with this being controlled by an
> on-by-default flag (due to the low risk).
>
> Mike - are you OK with the second point?
>
>
> On Thu, Apr 28, 2022 at 4:18 PM Raphael Kubo da Costa <
> raphael.kubo.da.co...@intel.com> wrote:
>
>> Back when I sent the original Intent to Deprecate and Remove email, I
>> checked the samples from the previous quarter listed in chromestatus.com
>> and surveyed some 50 websites.
>>
>> Some of them were no longer using the Battery Status API from an insecure
>> context (either because they had switched to HTTPS or because they had
>> stopped embedding whatever was using it before), but 43 had a match in the
>> form of trackers, embedded YouTube videos, Facebook widgets and, in 2
>> cases, other trackers that also performed feature detection.
>>
>> Today I surveyed another 40 from the previous quarter. All of them were
>> either using Yandex trackers and/or embedded YouTube videos; a single one
>> was using another tracker that also performed feature detection before
>> using the API.
>>
>> I ended up doing these checks manually; I can try to perform some larger
>> queries via HTTPArchive if preferred.
>>
>> On 28-04-2022 13:12, Yoav Weiss wrote:
>>
>> OK, if you ran through a sample of users and saw none of them break,
>> that's reassuring. How many users have you sampled?
>>
>> At the same time, I'm not aware of a real way in IDL today to indicate
>> that an API is not accessible in non-secure contexts and at the same time
>> to have such access trigger a warning.
>>
>>
>>
>>
>>
>> On Thu, Apr 28, 2022 at 12:04 PM Raphael Kubo da Costa <
>> raphael.kubo.da.co...@intel.com> wrote:
>>
>>> I tend to agree with Mike here; none of the users of
>>> navigator.getBattery() in insecure contexts I checked in the past (via
>>> chromestatus.com) would break with this change, as they're all checking
>>> if it's available first (including the largest user so far, YouTube), which
>>> makes sense since other engines don't ship this API.
>>>
>>> What I can do is write another CL that adds a new Blink runtime feature
>>> set to experimental and updates the current deprecation message and
>>> mentions the feature will be removed in M104, not M103. What's not clear is
>>> whether it would be possible to warn users if the feature flag is on and a
>>> website tries to use the Battery Status API in an http page, as adding
>>> something like [SecureContext=MyFeatureFlag] to the IDL files would prevent
>>> the code where the warning would go from even being reached if
>>> MyFeatureFlag is on.
>>>
>>> With that said, I guess it's up to the API owners to decide on the
>>> course here?
>>>
>>> On 26-04-2022 09:47, Mike West wrote:
>>>
>>> I'm less worried about this than Yoav is. Given the lack of support in
>>> any other browser, and the progressive-enhancement nature of this API, it's
>>> difficult for me to imagine embedded content visibly breaking at scale. If
>>> y'all do some spot-checking of the sites currently showing up through HTTP
>>> Archive, and have some evidence of the lack of user-visible breakage, I'd
>>> be comfortable without the additional complexity of percentage rollouts
>>> through Finch.
>>>
>>> If we do decide that that's necessary, we'll need to make sure that we
>>> have some sort of reasonable error message in the console so that the
>>> subset of developers who do experience some sort of breakage have a chance
>>> of understanding why.
>>>
>>> -mike
>>>
>>> On Monday, April 25, 2022 at 9:36:26 PM UTC+2 Yoav Weiss wrote:
>>>
>>>> I 

Re: [blink-dev] Intent to Deprecate and Remove: Battery Status API in Insecure Origins

[Mike West]

I'm less worried about this than Yoav is. Given the lack of support in any 
other browser, and the progressive-enhancement nature of this API, it's 
difficult for me to imagine embedded content visibly breaking at scale. If 
y'all do some spot-checking of the sites currently showing up through HTTP 
Archive, and have some evidence of the lack of user-visible breakage, I'd 
be comfortable without the additional complexity of percentage rollouts 
through Finch.

If we do decide that that's necessary, we'll need to make sure that we have 
some sort of reasonable error message in the console so that the subset of 
developers who do experience some sort of breakage have a chance of 
understanding why.

-mike

On Monday, April 25, 2022 at 9:36:26 PM UTC+2 Yoav Weiss wrote:

> I think it'd be better to add a feature flag disabled by default, and then 
> work with someone at Google to enable it on the server side for a release, 
> before enabling it in code.
> That way it'd be easy to revert this in case this unexpectedly breaks 
> things.
>
> On Mon, Apr 25, 2022 at 5:00 PM Raphael Kubo da Costa <
> raphael.kubo.da.co...@intel.com> wrote:
>
>> Thanks, Yoav. I've submitted 
>> https://chromium-review.googlesource.com/c/chromium/src/+/3605588 to 
>> implement this change. There's never been a feature flag for this though 
>> (in M99 we just added a deprecation warning), should I add one now?
>>
>> On 25-04-2022 16:40, Yoav Weiss wrote:
>>
>> The LGTMs you got on this thread should be enough. Please make sure to 
>> monitor any issues related to this, and revert if needed. (while keeping 
>> the feature flag around to enable urgent re-activation of this if breakage 
>> turns out to be untenable)
>>
>> On Thu, Apr 21, 2022 at 3:00 PM Raphael Kubo da Costa <
>> raphael.kubo.da.co...@intel.com> wrote:
>>
>>> Hi everyone,
>>>
>>> M103 is here, so I'd like to double-check if I can go ahead and stop 
>>> exposing the Battery Status API to insecure origins as described below. The 
>>> numbers in 
>>> https://chromestatus.com/metrics/feature/timeline/popularity/2199 
>>> remain flat (as explained, the percentage is pretty high but most of it 
>>> comes from embedded https YouTube videos, trackers and RUM (real user 
>>> monitoring) code in https pages.
>>>
>>> Do I start another thread and get new LGTMs for the actual removal?
>>>
>>> On 13-01-2022 16:09, Raphael Kubo Da Costa wrote:
>>>
>>> *Contact emails *raphael.kubo.da.co...@intel.com, reil...@chromium.org
>>>
>>> *Explainer*
>>> None
>>>
>>> *Specification *https://w3c.github.io/battery 
>>> *Summary *Deprecate and remove the Battery Status API on insecure 
>>> origins, such as HTTP pages or HTTPS iframes embedded in HTTP pages. 
>>> *Blink component *Blink>BatteryStatus 
>>> 
>>>  
>>> *Motivation *The Battery Status API allows web developers to have 
>>> access to, among other things, a system's battery charging level and 
>>> whether it is being charged. It is a powerful feature that has been around 
>>> for over a decade and, as such, was originally designed with different 
>>> security constraints. 
>>>
>>>
>>> https://www.chromium.org/Home/chromium-security/deprecating-powerful-features-on-insecure-origins
>>>  
>>> mentions how powerful features should not be exposed on insecure origins. 
>>> We would like to add the [SecureContext] attribute to the spec's Web 
>>> IDL so that navigator.getBattery() and the BatteryManager interface are 
>>> only available in secure contexts.
>>>
>>> This has also been discussed in W3C at the Devices and Sensors WG April 
>>> 2021 meeting, where we agreed to fix 
>>> https://github.com/w3c/battery/issues/15 by adjusting the Blink 
>>> implementation.
>>>
>>> Risks
>>> *Interoperability and Compatibility *Blink is the only engine 
>>> implementing the Battery Status API, so most/all users are already expected 
>>> to check for the presence of navigator.getBattery() before using it. 
>>>
>>> We've been measuring usage of navigator.getBattery() in insecure 
>>> contexts since M64. Per 
>>> https://chromestatus.com/metrics/feature/timeline/popularity/2199 the 
>>> counter sits at around 0.3% at the moment.
>>>
>>> However, none of the URLs listed there are using the Battery Status API 
>>> directly. The largest occurrence is embedded YouTube videos: embedded HTTPS 
>>> iframes on HTTP pages count as insecure contexts. Thomas Steiner reached 
>>> out to the YouTube team internally and they said this change would not 
>>> adversely impact them. Other usages of navigator.getBattery() in insecure 
>>> origins come from trackers and RUM (real user monitoring) code added to the 
>>> URLs listed in chromestatus.com. In all cases, feature detection is 
>>> already done so existing code would not break. Gecko: N/A Gecko does 
>>> not implement this API. WebKit: N/A Safari does not implement this API. Web 
>>> developers: No signals
>>>
>>> Is this feature 

Re: [blink-dev] Intent to Ship: Navigation API

[Mike West]

LGTM3.

-mike

On Wednesday, April 20, 2022 at 1:57:48 PM UTC+2 Yoav Weiss wrote:

> LGTM2
>
> I share MikeT's excitement about this API, and hopeful it can provide both 
> ergonomics wins for developers as well as predictability wins for browsers 
> when it comes to SPAs and navigations.
>
> On Monday, April 18, 2022 at 5:47:45 PM UTC+2 Mike Taylor wrote:
>
>> LGTM1 - I'm excited about this API, and hopeful we can smooth over the 
>> subtle interop issues that you've documented. But I see this as a huge 
>> ergonomics win over the status quo, and am encouraged by the careful work 
>> y'all have done.
>>
>> On 4/18/22 11:39 AM, Domenic Denicola wrote:
>>
>>
>>
>> On Mon, Apr 18, 2022 at 10:49 AM Mike Taylor  
>> wrote:
>>
>>> On 4/12/22 12:08 PM, Domenic Denicola wrote:
>>>
>>> Contact emails 
>>>
>>> dome...@chromium.org, jap...@chromium.org
>>>
>>> Explainer 
>>>
>>> https://github.com/WICG/navigation-api/blob/main/README.md
>>>
>>> (Aside: This explainer is a master-class in writing explainers. 
>>> Incredibly well done - I really appreciate the effort that went into this).
>>>
>>>
>>> Specification 
>>>
>>> https://wicg.github.io/navigation-api/
>>>
>>> Summary 
>>>
>>> The window.navigation API provides the ability to intercept and initiate 
>>> navigations, as well as introspect an application's history entries. This 
>>> provides a more useful alternative to window.history and window.location, 
>>> specifically aimed at the needs of single-page web applications.
>>>
>>> (Note: this API was formerly known as the app history API.)
>>>
>>> Blink component 
>>>
>>> Blink>History 
>>> 
>>>
>>> TAG review 
>>>
>>> https://github.com/w3ctag/design-reviews/issues/605
>>>
>>> https://github.com/w3ctag/design-reviews/issues/717
>>>
>>> TAG review status 
>>>
>>> Issues addressed
>>>
>>> Link to origin trial feedback summary 
>>>
>>>
>>> https://docs.google.com/document/d/1oDtVhNJaDyEAqsthe07wJaGNVpt-g4TLB4A0-lU2lr4/edit?usp=sharing
>>>
>>> Risks 
>>> Interoperability 
>>>
>>> The biggest interoperability risk with this API is that it is building 
>>> on a rocky foundation. The existing session history spec does not match 
>>> browsers very well, and browsers do not match each other. Since this new 
>>> API layers on top of the existing model, this could cause issues.
>>>
>>> We have attempted to address this via a solid and well-tested 
>>> specification for the new API, as well as ongoing efforts in whatwg/html 
>>> PR #6315  and elsewhere on 
>>> the HTML Standard issue tracker 
>>> 
>>>  
>>> to reform the foundational parts of the specification. For example, 
>>> although the navigation API's new events, such as currententrychange, are 
>>> fired at well-specified times, there is an existing interop problem 
>>>  regarding the timing of 
>>> popstate vs. hashchange events, which makes it difficult to write tests for 
>>> the ordering of currententrychange vs. hashchange/popstate. Working on such 
>>> existing interop issues and specification problems, and then expanding the 
>>> navigation API test suite to cover any such interactions, is our team's top 
>>> priority after this launch. See also this tracking issue 
>>> .
>>>
>>> I do have slight concerns 
>>>  
>>> over the popstate/hashchange event change - I fear that might result in 
>>> more back button traps for Chromium users (that sadly Gecko users 
>>> experience today). But I could be wrong - do you have any plans to measure 
>>> and monitor abuse? Or do we have existing metrics?
>>>
>>
>> To make sure we are on the same page: at this point we are discussing a 
>> future Intent to Ship about a separate behavior change, and we are not 
>> discussing the Navigation API.
>>
>> Correct - and to be extra clear, any potential future I2S is not 
>> influencing this I2S in my mind.
>>
>> Our plan for that future Intent to Ship does indeed involve careful 
>> monitoring. However I don't think it has any chance of increasing 
>> back-trapping. Deterministically firing the events in the order (sync 
>> popstate, async hashchange) like Gecko does, instead of Chrome's version 
>> where sometimes it's (async popstate, async hashchange) and sometimes it's 
>> (async hashchange, async popstate) depending on network conditions and page 
>> size, should not increase back-trapping. 
>>
>> OK, I'm very happy to be wrong here. :)
>>
>>
>>> Regarding whether this new API will be implemented in other browsers, we 
>>> have been encouraged by the consistent and positive collaboration with 
>>> Gecko engineers, which has led to several API 

Re: [blink-dev] Intent to Ship: Cookie Expires/Max-Age attribute upper limit

[Mike West]

LGTM2.

I recognize Yoav's concern, and I think it's reasonable, but I'm less 
concerned about it than he is. Still, adding the metrics under discussion 
here is a good step, and if they cause us to reevaluate the impact, we'll 
have plenty of time to do so.

-mike

On Wednesday, April 13, 2022 at 10:49:29 AM UTC+2 Yoav Weiss wrote:

> On Tue, Apr 12, 2022 at 9:10 PM Ari Chivukula  
> wrote:
>
>> Deal, but let's call metrics for M103 and the feature in M104.
>>
>
> Sure, I should've said N and N+1 
>
>
>> ~ Ari Chivukula (Their/There/They're)
>>
>>
>> On Mon, Apr 11, 2022 at 8:57 PM Yoav Weiss  
>> wrote:
>>
>>> LGTM1 conditional on:
>>>
>>>- Landing the metrics in M102 and the feature in M103
>>>- Coming back to this thread when the numbers start coming in on the 
>>>metrics
>>>- Having a flag in place that'd enable us to disable the feature in 
>>>case the numbers indicate that the loss of cookies due to lack of 
>>> updates 
>>>would be very high
>>>
>>>
>>> On Mon, Apr 11, 2022 at 10:58 PM Ari Chivukula  
>>> wrote:
>>>
 Here's a design doc for the additional data to be measured: 
 https://docs.google.com/document/d/1x7_2wVY2gSEfMlvpS4AoQtN5x7fHG_AsQ01V4CkSELI/edit

 The target ship date for this thread is now M103, but we're still 
 looking for LGTMs.

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


 On Mon, Apr 11, 2022 at 7:46 AM Ari Chivukula  
 wrote:

> Since we don't currently store the last date a cookie was updated in 
> chrome (just the original creation date) we wouldn't be able to get data 
> on 
> how many cookies would expire due to a lack of timely refreshes by the 
> site 
> (as opposed to a lack of site visits) for up to 400 days. The problem is 
> that sites might be tuned to refresh periodically (instead of on every 
> visit), which means we would have to wait for that unknown periodic 
> refresh 
> for a last update date to even be recorded.
>
> I think we should move forward with this change *and* add metrics so 
> we have an idea (before the 400 day mark) which sites risk expiration and 
> can alert them.
>
> I don't think there's an issue with sites taking 6 months to change 
> refresh behavior as the expires logic only affects sites with 
> less-than-annually active users. That is, affected users would login to 
> use 
> a site post-chrome expires change but pre-site refresh change, and then 
> wait 400 days to try to use the site again for their login to expire.
>
> ~ Ari Chivukula (Their/There/They're)
>
> On Mon, Apr 11, 2022, 05:18 Yoav Weiss  wrote:
>
>> IIUC from offline conversations, once we start changing the 
>> expiration dates of cookies, we won't have a way to avoid enforcing that 
>> expiration date 400 days from now. So we probably want to get this right 
>> and avoid breakage for sites that don't currently update their cookies 
>> every time (as even if they change their behavior ~6 months from now, 
>> they'd accumulate 6 months worth of users that visited their site but 
>> will 
>> have their cookies expired).
>>
>> Would it make sense to collect data on the cookie update dates (maybe 
>> even just data from beta), and only then ship the expiration max-age 
>> change?
>>
>>
>> On Mon, Apr 11, 2022 at 11:51 AM Ari Chivukula  
>> wrote:
>>
>>> We don't currently, but we know only 20% of cookies set in chrome 
>>> are over the limit (and that 20% will continue to work if not updated). 
>>> We're planning proactive communication about the change once it's 
>>> approved 
>>> since there's a 400 day window from the change going in until effects 
>>> are 
>>> first felt.
>>>
>>> ~ Ari Chivukula (Their/There/They're)
>>>
>>> On Mon, Apr 11, 2022, 02:03 Yoav Weiss  
>>> wrote:
>>>
 Thanks! It seems like we'd need to tell developers then that they 
 need to update their cookies on every site visit. I don't know if this 
 is a 
 big change from what they are already largely doing. Do we have data 
 on 
 that?

 On Fri, Apr 8, 2022 at 7:26 PM Ari Chivukula  
 wrote:

> The actual expiration date written to the cookie store is capped 
> at 400 days for any new/updated cookies.
>
> If a newly logged-in site doesn't refresh its cookies for 400 days 
> after they are set, the cookies expire and the user will be logged 
> out no 
> matter how often the user visits the site.
>
> ~ Ari Chivukula (Their/There/They're)
>
>
> On Fri, Apr 8, 2022 at 8:57 AM Yoav Weiss  
> wrote:
>
>> What happens if a newly logged-in site doesn't refresh its 
>> cookies on every visit, the user visits that site 

[blink-dev] Re: Intent to Ship: Origin Private File System extension: AccessHandle

[Mike West]

LGTM2.

-mike


On Tue, Apr 12, 2022 at 6:08 AM Yoav Weiss  wrote:

> LGTM1
>
> Thanks for pushing this through. Please make sure to follow-up on any
> feedback we'd get on the PR itself.
>
> On Mon, Apr 11, 2022 at 7:44 PM Emanuel Krivoy 
> wrote:
>
>> Hello!
>>
>> I've removed the options object from our implementation, and filed a new
>> PR against the WHATWG repo (https://github.com/whatwg/fs/pull/21) that
>> incorporates the previous feedback.
>>
>> Yoav:
>> Yes, we'd like to keep the current OT running and then ship on 102
>> without removing availability of the surface in between.
>>
>> On Thu, Apr 7, 2022 at 12:38 PM Yoav Weiss 
>> wrote:
>>
>>>
>>>
>>> On Mon, Apr 4, 2022 at 5:11 PM Emanuel Krivoy 
>>> wrote:
>>>
>>>> Hello,
>>>>
>>>> Replying to Mike inline:
>>>>
>>>> https://github.com/WICG/file-system-access/pull/344 doesn't seem to
>>>>> have moved in the last ~2 weeks, and I don't see a new PR against the
>>>>> WHATWG spec. What's y'all's timeline for finishing the specification of
>>>>> this feature?
>>>>
>>>>
>>>> The plan is to create the PR against the spec in WHATWG this week. It
>>>> should include the changes from the current feedback in the old PR.
>>>>
>>>>
>>>>
>>>>> Thanks for doing this investigation! It does sound like something we'd
>>>>> want to resolve before shipping, as it would be unfortunate for this to
>>>>> present a barrier to interop.
>>>>>
>>>>> I didn't see a bug filed against webkit in a quick search, can you
>>>>> follow up on that (or point it out if I missed it)?
>>>>
>>>>
>>>>
>>>> I directly followed up with WebKit and the Storage team. The result of
>>>> the discussions was that, to avoid compatibility issues with Safari and
>>>> leave the design of the options object fully open, we should temporarily
>>>> remove the options parameter from createSyncAccessHandle().
>>>>
>>>>
>>>>
>>>> Once there is consensus on how options should be handled, it should be
>>>> easy to add them back. We would end up in the desired final state, but with
>>>> an inverted default: the OPFS Access Handle behavior is the default one,
>>>> and specific options would be needed to use them in other file systems.
>>>> Since the OPFS use case is the one that has been proven with trials, and
>>>> the one that other browsers intend to implement for now, I think it makes
>>>> sense to leave it as the default.
>>>>
>>>>
>>>>
>>>> To all:
>>>>
>>>>
>>>>
>>>> Since we have to do code changes to remove the options object, and
>>>> since the spec still has to be rebased, I wanted to change this request
>>>> from shipment on 101 to a gapless shipment on 102. I’ll keep working on
>>>> those two pending items and ping this thread when they are done.
>>>>
>>>
>>> Just to clarify, you're planning to run the OT till the end of M101 and
>>> then gaplessly ship in M102?
>>>
>>>
>>>>
>>>> Thanks!
>>>> Emanuel
>>>>
>>>> On Wed, Mar 30, 2022 at 3:01 PM Mike West  wrote:
>>>>
>>>>> On Wed, Mar 23, 2022 at 5:48 PM Emanuel Krivoy 
>>>>> wrote:
>>>>>
>>>>>> Hey Yoav,
>>>>>>
>>>>>>
>>>>>>> So the plan is to land the PR in WICG, and then (immediately) move
>>>>>>> it over to https://fs.spec.whatwg.org/?
>>>>>>> What are the current blockers for the WICG PR from landing?
>>>>>>>
>>>>>>
>>>>>> My plan would be to act on the current round of feedback in the WICG
>>>>>> PR and then move the spec to its final home in WHATWG to finish the
>>>>>> review/merge there.
>>>>>> The situation is an artifact of me wanting to do a quick round of
>>>>>> feedback before investing time in the rebase, just to make sure the spec
>>>>>> was going in the right direction. Now I think it might have made things
>>>>>> more confusing than they should have been, sorry!
>>>>>>
>>>>>
>>>>> https:

[blink-dev] Re: Intent to Ship: Origin Private File System extension: AccessHandle

[Mike West]

On Wed, Mar 23, 2022 at 5:48 PM Emanuel Krivoy 
wrote:

> Hey Yoav,
>
>
>> So the plan is to land the PR in WICG, and then (immediately) move it
>> over to https://fs.spec.whatwg.org/?
>> What are the current blockers for the WICG PR from landing?
>>
>
> My plan would be to act on the current round of feedback in the WICG PR
> and then move the spec to its final home in WHATWG to finish the
> review/merge there.
> The situation is an artifact of me wanting to do a quick round of feedback
> before investing time in the rebase, just to make sure the spec was going
> in the right direction. Now I think it might have made things more
> confusing than they should have been, sorry!
>

https://github.com/WICG/file-system-access/pull/344 doesn't seem to have
moved in the last ~2 weeks, and I don't see a new PR against the WHATWG
spec. What's y'all's timeline for finishing the specification of this
feature?

Have you tried running STP against the WPT test suite? That could be
>> reassuring interop-wise
>>
>
> Thanks for the suggestion. After running the WPTs, there seems to be some
> divergence with the proposed spec. The most substantial one (beyond some
> issues around the type of error thrown) is that the implementation of
> createSyncAccessHandle in Safari TP does not take an options parameter.
>
> The options parameter is there to (eventually) allow using access handles
> on other filesystems (i.e., from outside OPFS, in particular on files
> hosted in the local file system). This feature has been requested by
> developers on various occasions, and would make the File System Access API
> more flexible. In our implementation, the options parameter is required (as
> in, has to be provided when calling createSyncAccessHandle) to avoid
> setting the default behavior of access handles to the particular one needed
> within OPFS. Further context can be found in
> https://github.com/whatwg/fs/issues/19.
>
> I will go ahead and file the appropriate bugs/contact the feature owner!
>

Thanks for doing this investigation! It does sound like something we'd want
to resolve before shipping, as it would be unfortunate for this to present
a barrier to interop.

I didn't see a bug filed against webkit in a quick search, can you follow
up on that (or point it out if I missed it)?

Thanks!

-mike


>
> On Wed, Mar 23, 2022 at 5:39 AM Yoav Weiss  wrote:
>
>> Thanks for working on this important capability!!
>>
>> On Tuesday, March 22, 2022 at 5:24:08 PM UTC+1 Emanuel Krivoy wrote:
>>
>>> Hello blink-dev, We'd like to request a review on our intent to ship
>>> Access Handles with Chrome 101. Since we don't envision changes to the
>>> surface and it is currently in use by Photoshop web, this request comes one
>>> release before our OT expires. Please find the details below:
>>> Contact emails
>>>
>>> fived...@chromium.org, r...@chromium.org
>>>
>>> Explainer
>>>
>>> https://github.com/WICG/file-system-access/blob/main/AccessHandle.md
>>>
>>> Specification
>>>
>>> Out for review.
>>>  Will be
>>> moved  to WHATWG
>>> after replying to pending comments.
>>>
>>
>> So the plan is to land the PR in WICG, and then (immediately) move it
>> over to https://fs.spec.whatwg.org/?
>> What are the current blockers for the WICG PR from landing?
>>
>>
>>> Summary
>>>
>>> The Origin Private File System (OPFS, part of the File System Access
>>> API) is augmented with a new surface that brings very performant access to
>>> data. This new surface differs from existing ones by offering in-place and
>>> exclusive write access to a file’s content. This change, along with the
>>> ability to consistently read unflushed modifications and the availability
>>> of a synchronous variant on dedicated workers, significantly improves
>>> performance and unblocks new use cases (especially for porting existing
>>> IO-heavy applications to WebAssembly).
>>>
>>> This Intent-to-Ship is only in reference to the sync variant of the API
>>> i.e., the createSyncAccessHandle() method and the SyncAccessHandle
>>> object (only exposed in worker contexts):
>>>
>>> const handle = await file.createSyncAccessHandle();
>>>
>>> var writtenBytes = handle.write(buffer);
>>>
>>> var readBytes = handle.read(buffer {at: 1});
>>>
>>> The sync variant is meant to be consumed by low-level entities like
>>> toolchains. We expect application developers to prefer the async API with
>>> its streaming interface which will be shipped later.
>>>
>>> AccessHandles is the new API shape for what was previously called
>>> Storage Foundation API (Intent-to-Experiment:
>>> http://groups.google.com/a/chromium.org/g/blink-dev/c/Jhirhnq3WbY).
>>>
>>> Blink component
>>>
>>> Blink>Storage>FileSystem
>>> 
>>>
>>> TAG review
>>>
>>> https://github.com/w3ctag/design-reviews/issues/664
>>>
>>> TAG review 

Re: [blink-dev] Intent to Ship: Omnibox Prerendering

[Mike West]

LGTM1.

The two issues I considered blocking were Alex's concerns around opt-out,
and the BroadcastChannel integration. It seems to me like there's still
discussion to be had on even better solutions than y'all have landed on for
both (headers in the one case, more explicit integration with
BroadcastChannel in the other), but if there's agreement on the current set
of approaches, then your current rollout plan looks reasonable.

Thanks!

-mike


On Wed, Mar 16, 2022 at 5:06 PM Noam Rosenthal 
wrote:

> Yes, there are plans for such a header, join the discussion here:
> https://github.com/WICG/nav-speculation/issues/138
> However so far fleshing out its details was not deemed a blocker for
> releasing prerender - a simple "all or nothing" opt-out seemed sufficient
> as a first step.
>
> On Wednesday, March 16, 2022 at 5:42:15 PM UTC+2 sligh...@chromium.org
> wrote:
>
>> Hey Kouhei,
>>
>> Thanks for highlighting that there's an opt-out option now. I'm a little
>> concerned that it requires servers to avoid sending a response at all,
>> forcing an early decision by the infrastructure rather than allowing pages
>> requested this way to be prefetched by not prerendered (by, e.g., sending a
>> response header that says "prefetch is fine, but please don't render me").
>>
>> Are there plans for such a header? It would go a long way to making me
>> comfortable with this feature.
>>
>> Regards
>>
>> On Tuesday, March 15, 2022 at 7:10:12 AM UTC-7 Kouhei Ueno wrote:
>>
>>> Hi,
>>>
>>> While we are discussing, we would like to continue the incremental roll
>>> out of the feature to non-Stable channels. As of now, we are testing out
>>> the feature on 60% of Dev/Canary channels, and 60% of Beta channels. The
>>> rollout is limited to Android Chrome (limitation of the current
>>> implementation).
>>>
>>> We expect the rollout to affect at most a tiny fraction of the Internet
>>> traffic generated by Chrome. The population of the Beta/Dev/Canary channels
>>> combined is less than a few percent of Stable population, and the
>>> navigation subject to prerendering on Prerendering-enabled Chrome is less
>>> than a percent.
>>>
>>> Let me try to summarize the state of the discussion here (including the
>>> questions we’ve received out-of-band).
>>>
>>> Q: Do you offer an opt-out mechanism to developers?
>>>
>>> A: Yes. The opt-out mechanism is now covered in this section
>>> 
>>> of the explainer.
>>>
>>> Q: What can we do about prerender breaking “switch to already open tab”
>>> on WhatsApp?
>>>
>>> A: We are updating the BroadcastChannel interaction [spec
>>> , implementation
>>> ].
>>> In addition, we are delaying ServiceWorker#postMessage too, to address a
>>> similar issue [crbug ]
>>>
>>> Q: Can Enterprise disable the feature by a policy?
>>>
>>> A: Yes - we respect the existing NetworkPredictionOptions
>>> 
>>> group policy.
>>>
>>> Q: What is the status of https://github.com/whatwg/html/issues/7533?
>>>
>>> A: The issue is a general “call for feedback” issue. Individual issues
>>> are tracked on wicg/nav-speculation issue tracker
>>> .
>>>
>>> Q: Since prerendering risks breaking certain websites, what are the
>>> mitigation measures planned?
>>>
>>> A:
>>>
>>> Prerendering is not entirely new. It used to be available in Chrome M13
>>> until M63 and has been available in many other browsers such as: Safari
>>> since at least 2014
>>> ,
>>> Opera from 2017
>>> ,
>>> and more recently launched in Edge. We assume that the risk of breakage is
>>> relatively low given these pre-existing conditions. That said, we will
>>> remain prudent while relaunching this feature.
>>>
>>>
>>>1.
>>>
>>>Take a slow and transparent approach to our rollout:
>>>1.
>>>
>>>   We’ll be careful around ramping up the experiment group
>>>   population that we will be monitoring the metrics and user reports 
>>> closely.
>>>   2.
>>>
>>>   We’ll also be transparent about the rollout config on this
>>>   blink-dev thread.
>>>   3.
>>>
>>>   We’ll be keeping in touch with various partners to ensure that
>>>   everything is good on their end.
>>>   2.
>>>
>>>Before going to Stable, we’ll publish a heads-up article on one of
>>>our blogs with the following content:
>>>1.
>>>
>>>   What’s being experimented with (e.g. prerendering on Chrome for
>>>   Android from the Omnibox)
>>>   2.

Re: [blink-dev] Intent to Prototype + Ship: Secure Payment Confirmation API V3

[Mike West]

LGTM3.

On Wednesday, March 16, 2022 at 11:08:29 AM UTC+1 Yoav Weiss wrote:

> LGTM2
>
> On Tue, Mar 15, 2022 at 9:52 PM Mike Taylor  
> wrote:
>
>> On 3/15/22 4:42 PM, Nick Burris wrote:
>>
>> On Tue, Mar 15, 2022 at 4:52 PM Mike Taylor  
>> wrote:
>>
>>> On 3/9/22 10:27 AM, Nick Burris wrote:
>>>
>>> Contact emails 
>>>
>>> nbur...@chromium.org, rous...@chromium.org, smcgr...@chromium.org, 
>>> ma...@chromium.org
>>>
>>> Explainer 
>>>
>>> https://github.com/w3c/secure-payment-confirmation/blob/main/explainer.md
>>>
>>> Specification 
>>>
>>> https://w3c.github.io/secure-payment-confirmation/
>>>
>>> Design docs 
>>>
>>> N/A
>>>
>>> Summary 
>>>
>>> Three changes to the Secure Payment Confirmation API, implemented and 
>>> flagged as “V3” of the API.
>>>
>>>- 
>>>
>>>Add Relying Party ID as a required input (issue 
>>>). 
>>>This is a breaking change, see issue and compatibility section.
>>>- 
>>>
>>>Add an optional boolean to allow failed instrument icon download (
>>>issue 
>>>).
>>>- 
>>>
>>>Add payeeName as an optional input (issue 
>>>).
>>>
>>>
>>> Original feature summary: Secure payment confirmation augments the 
>>> payment authentication experience on the web with the help of WebAuthn. The 
>>> feature adds a new 'payment' extension to WebAuthn, which allows a relying 
>>> party such as a bank to create a PublicKeyCredential that can be queried by 
>>> any merchant origin as part of an online checkout via the Payment Request 
>>> API using the 'secure-payment-confirmation' payment method.
>>>
>>> Blink component 
>>>
>>> Blink>Payments 
>>> 
>>>
>>> TAG review 
>>>
>>> https://github.com/w3ctag/design-reviews/issues/675
>>>
>>> TAG review status 
>>>
>>> Closed (Resolution: satisfied)
>>>
>>> Interoperability and Compatibility 
>>>
>>> One of the API changes, the relying party ID input, is a breaking change 
>>> as it is a new required field. We are confident in this change as the 
>>> feature is relatively new and has little usage, and we have discussed these 
>>> changes with the external partners who are using the feature. Adapting to 
>>> the change is also forwards-compatible, in that partners can add the new 
>>> input today without breaking their code, and then it will just continue 
>>> working after this ships.
>>>
>>> How confident are y'all that all SPC users will be aware of this 
>>> breaking change? Do we have UKM?
>>>
>> Our metrics show that SPC currently has near zero usage, so we are 
>> confident that there's at least no deployed usage of the feature that this 
>> will break. We are in contact with multiple partners working on products 
>> using SPC who are aware of the change. If it does break something that's in 
>> development that we're not aware of, the error message indicates 
>> what's missing, and such a developer would likely know where to get the 
>> latest info on SPC (the github repo, blink-dev) or can at least find us. :)
>>
>> Thanks Nick, that sounds reasonable. If you do hear back from sites who 
>> were broken by this, it may be useful to update the thread so we can learn 
>> from the experience.
>>
>> LGTM1.
>>
>>
>>>
>>> Gecko: No signal (
>>> https://github.com/mozilla/standards-positions/issues/570) Historically 
>>> (>1 year old) positive signal from informal conversation in W3C Payment 
>>> Handler meetings. However Firefox have since not been involved in the API 
>>> development.
>>>
>>> WebKit: No signal (
>>> https://lists.webkit.org/pipermail/webkit-dev/2021-August/031956.html)
>>>
>>> Web developers: Positive (
>>> https://lists.w3.org/Archives/Public/public-payments-wg/2021Aug/0005.html) 
>>> Support and involvement in API development from multiple web developers and 
>>> payment industry partners. Both Stripe and AirBnB have publicly stated that 
>>> they have either completed or are in the process of 
>>> prototyping/experimenting with SPC
>>>
>>>
>>>
>>> Debuggability 
>>>
>>> Existing devtools debugging features should cover SPC (e.g. breakpoints, 
>>> console, etc)
>>>
>>> Is this feature fully tested by web-platform-tests 
>>> 
>>> ? 
>>>
>>> Yes, coverage for the new input fields will be added to the existing 
>>> test suite:
>>>
>>>
>>> https://wpt.fyi/results/secure-payment-confirmation?label=master=experimental
>>>
>>> Flag name 
>>>
>>> SecurePaymentConfirmationAPIV3
>>>
>>> Requires code in //chrome? 
>>>
>>> Yes: minor changes to the chrome UI code, to possibly display a 
>>> placeholder card icon when the new ‘iconMustBeShown’ option is false, and 
>>> to render the optional payeeName alongside or instead of the 

Re: [blink-dev] Intent to Ship: Add Save Data Client Hint

[Mike West]

On Tue, Mar 15, 2022 at 7:57 PM Ari Chivukula  wrote:

> (1) Can we omit the header when the value would be `?0` (false)?
>
> I'm fine with that, and it would be worth updating the existing client
> hint standard to allow the conflation of empty/missing values in cases
> where headers are sent by default. It's not worth the bytes to clarify the
> header is empty, especially when it's about saving data :-P
>

SGTM. That seems like a reasonable pattern to document: I filed
https://github.com/WICG/client-hints-infrastructure/issues/99.

(2) Why add this new name if we have the existing header? Can't we just
> have the permission policy apply to the old name?
>
> Chrome on Android is removing 'lite mode', which is the only case I'm
> aware of which causes `Save-Data: on` to be sent. We have a chance here to
> add the new name and policy, then follow up with a removal of the old name
> while it's not even being sent. The removal isn't a part of this intent,
> but in any case where `Sec-CH-Save-Data` is explicitly requested or the
> `CH-Save-Data` policy is touched the old `Save-Data` header wouldn't be
> sent at all under this intent.
>

Hrm. This sounds quite different from what was in the original intent. :)
Two followups, if you don't mind:

1.  Does this intent also introduce a new triggering mechanism which would
cause the header to be sent? My assumption was that we'd be basing this on
the user's "lite mode" choice. If we're removing that, what's left?

2.  If you're additionally planning to change `Save-Data`'s behavior to
make it subject to the `CH-Save-Data` policy, then it seems like the only
advantage of introducing a new header is naming consistency with other
client hints. Have y'all done any analysis to determine how many sites rely
upon the current spelling of the header to change user-facing behavior? It
seems like there might be strong reliance interests here, given the
header's long tenure.

-mike


> ~ Ari Chivukula (Their/There/They're)
>
>
> On Tue, Mar 15, 2022 at 11:05 AM Mike West  wrote:
>
>> Hey Avi!
>>
>> Two questions, one small, one large:
>>
>> First, to reduce header bloat, the approach of not sending headers by
>> default whose value is `?0` seems reasonable. Fetch Metadata's 
>> `Sec-Fetch-User`
>> header <https://www.w3.org/TR/fetch-metadata/#abstract-opdef-set-user>
>> is a good example of this. Can you help me understand why that's not the
>> right thing to do here?
>>
>> Second, and more fundamentally, if we're not planning to remove
>> `Save-Data`, adding this header doesn't make much sense to me. We'll be
>> adding this new header to every request alongside `Save-Data`, with the
>> same value as `Save-Data`. That feels purely duplicative. Can you help me
>> understand the value? (If integration with permission policy is valuable
>> (and I can understand how it could be!), did you consider carving out a
>> naming exception for this header, and applying the policy control to the
>> `Save-Data` header? It seems like we'd have to do that anyway in order for
>> the policy control to have any meaning.)
>>
>> -mike
>>
>>
>> On Wed, Mar 9, 2022 at 8:26 PM Ari Chivukula 
>> wrote:
>>
>>> Sorry for not including timeline info. The plan is:
>>> M102 will include the new Sec-CH-Save-Data header.
>>> No plan to remove the legacy Save-Data header at this moment.
>>>
>>>
>>> On Mon, Mar 7, 2022 at 7:57 AM Ari Chivukula 
>>> wrote:
>>>
>>>> Fixing the subject prefix, apologies.
>>>>
>>>> On Mon, Mar 7, 2022 at 7:55 AM Ari Chivukula 
>>>> wrote:
>>>>
>>>>> Contact emails
>>>>>
>>>>> aric...@chromium.org, jadekess...@chromium.org, miketa...@chromium.org
>>>>>
>>>>> Design Doc
>>>>>
>>>>>
>>>>> https://docs.google.com/document/d/1sRYGWL2H_qFQamffUbojBiQdbJ1uAmptr3F_jjx5VSI/edit
>>>>>
>>>>> Specification
>>>>>
>>>>> https://wicg.github.io/savedata/
>>>>>
>>>>> https://wicg.github.io/client-hints-infrastructure/
>>>>>
>>>>> Summary
>>>>>
>>>>> The Sec-CH-Save-Data client hint
>>>>> <https://wicg.github.io/client-hints-infrastructure/> indicates
>>>>> whether the user agent intends to reduce data usage. It will be sent by
>>>>> default on all requests unless the permissions policy says otherwise.
>>>>>
>>>>>
>>>>>
>>>>> For example, one could limi

Re: [blink-dev] Re: Intent to Prototype and Ship: font-palette and custom @font-palette-values palettes

[Mike West]

LGTM3.

-mike


On Tue, Mar 15, 2022 at 5:12 PM Mike Taylor  wrote:

> LGTM2
>
> On 3/15/22 11:20 AM, Yoav Weiss wrote:
>
> LGTM1 - given the early positive signal and the fact it's already shipping
> in Safari. Please follow up on any feedback from others if it comes up on
> that thread.
>
> On Tue, Mar 15, 2022 at 3:27 PM Dominik Röttsches 
> wrote:
>
>> Hi again Yoav and others,
>>
>> On Mon, Mar 14, 2022 at 5:18 PM Dominik Röttsches 
>> wrote:
>>
>>> Hi Yoav,
>>>
>>> On Thursday, March 10, 2022 at 9:18:17 AM UTC+2 yoav...@chromium.org
>>> wrote:
>>>
 Thanks for working on this! Seems like a very cool feature!! :)

 On Tuesday, March 8, 2022 at 1:44:55 PM UTC+1 Dominik Röttsches wrote:

>>>
>
> Gecko: Under consideration (
> https://github.com/mozilla/standards-positions/issues/617) Position
> requested in above link, tracking bug exists:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1461588
>

 As this position request is very recent, might be worthwhile to let it
 bake for a week or two.

>>>
>>> FWIW, I pinged Jonathan Kew on the Mozilla side regarding this request
>>> as well.
>>>
>>
>> I have a small update, Jonathan preliminarily commented positively
>> 
>> :
>> "Speaking for myself, I think this is a useful and uncontroversial
>> addition, allowing authors greater flexibility and control when working
>> with multi-colored fonts (such as emoji and other symbol sets, as well as
>> decorative alphabets). [...] So I think we should classify this as "worth
>> prototyping". @tantek @annevk Any additional thoughts?"
>>
>> So, I'd be happy if this could be reviewed in this week's API owners
>> meeting round.
>>
>> Thanks,
>>
>> Dominik
>>
>>
>>
> --
> 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/CAL5BFfX8T%2BB%2BvkDDz2wcyXpDbTMctZPYz5MPHnKjuxSU2aY9uA%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/5488f955-a161-2a62-d4cb-7937085bd93f%40chromium.org
> 
> .
>

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

Re: [blink-dev] Intent to Ship: Add Save Data Client Hint

[Mike West]

Hey Avi!

Two questions, one small, one large:

First, to reduce header bloat, the approach of not sending headers by
default whose value is `?0` seems reasonable. Fetch Metadata's `Sec-Fetch-User`
header  is a
good example of this. Can you help me understand why that's not the right
thing to do here?

Second, and more fundamentally, if we're not planning to remove
`Save-Data`, adding this header doesn't make much sense to me. We'll be
adding this new header to every request alongside `Save-Data`, with the
same value as `Save-Data`. That feels purely duplicative. Can you help me
understand the value? (If integration with permission policy is valuable
(and I can understand how it could be!), did you consider carving out a
naming exception for this header, and applying the policy control to the
`Save-Data` header? It seems like we'd have to do that anyway in order for
the policy control to have any meaning.)

-mike


On Wed, Mar 9, 2022 at 8:26 PM Ari Chivukula  wrote:

> Sorry for not including timeline info. The plan is:
> M102 will include the new Sec-CH-Save-Data header.
> No plan to remove the legacy Save-Data header at this moment.
>
>
> On Mon, Mar 7, 2022 at 7:57 AM Ari Chivukula  wrote:
>
>> Fixing the subject prefix, apologies.
>>
>> On Mon, Mar 7, 2022 at 7:55 AM Ari Chivukula 
>> wrote:
>>
>>> Contact emails
>>>
>>> aric...@chromium.org, jadekess...@chromium.org, miketa...@chromium.org
>>>
>>> Design Doc
>>>
>>>
>>> https://docs.google.com/document/d/1sRYGWL2H_qFQamffUbojBiQdbJ1uAmptr3F_jjx5VSI/edit
>>>
>>> Specification
>>>
>>> https://wicg.github.io/savedata/
>>>
>>> https://wicg.github.io/client-hints-infrastructure/
>>>
>>> Summary
>>>
>>> The Sec-CH-Save-Data client hint
>>>  indicates whether
>>> the user agent intends to reduce data usage. It will be sent by default on
>>> all requests unless the permissions policy says otherwise.
>>>
>>>
>>>
>>> For example, one could limit delegation of this hint via HTTP headers:
>>>
>>> Permissions-Policy: ch-save-data=(self, https://bar.com/)
>>>
>>>
>>>
>>> Or, one could limit delegation of this hint via an HTML meta tag:
>>>
>>> https://bar.com/)">
>>>
>>>
>>>
>>> Example of new HTTP header when Data Saver is on:
>>>
>>> Sec-CH-Save-Data: ?1
>>>
>>>
>>>
>>> Example of new HTTP header when Data Saver is off:
>>>
>>> Sec-CH-Save-Data: ?0
>>>
>>>
>>>
>>> Explicitly requesting Sec-CH-Save-Data or modifying the CH-Save-Data
>>> permissions policy will prevent the old `Save-Data` header from being
>>> sent. Otherwise, the old header will not be affected.
>>>
>>>
>>>
>>> Blink component
>>>
>>> Blink>Network>ClientHints
>>> 
>>>
>>>
>>>
>>> Motivation
>>>
>>> The current `Save-Data` header is sent when a browser or operating
>>> system data saver setting is on (e.g., Lite mode
>>> )
>>> for all first and third party requests, lives outside the client hints
>>> system , and is named
>>> improperly
>>> .
>>> `Sec-CH-Save-Data` will be a proper client hint and its delegation to third
>>> parties could be prevented via permissions policies
>>> 
>>> .
>>>
>>> TAG review
>>>
>>> N/A (No new data is exposed that wasn't before)
>>>
>>> Compatibility
>>>
>>> The `Save-Data` header will not be removed, so adoption of
>>> `Sec-CH-Save-Data` is optional.
>>>
>>>
>>> Interoperability
>>>
>>> Gecko: Client Hints not yet implemented (considered non-harmful
>>> )
>>>
>>> WebKit: Client Hints not yet implemented
>>>
>>> Web developers: No feedback yet
>>>
>>> Debuggability
>>>
>>> N/A
>>>
>>> Is this feature fully tested by web-platform-tests?
>>>
>>> Not yet, but it will be. `Save-Data` tests are here
>>> .
>>>
>>> Tracking bug
>>>
>>> https://crbug.com/1293443
>>>
>>> Link to entry on the Chrome Platform Status
>>>
>>> https://chromestatus.com/feature/5645928215085056
>>>
>>> --
> 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/CAGpy5DLyhJURaZAKrogjcs0QEMV0-3JM0_onQOP-GjBVY2gkXQ%40mail.gmail.com
> 
> .
>

-- 
You 

Re: [blink-dev] Intent to Ship: Multi-Screen Window Placement

[Mike West]

LGTM3. Thanks for the work y'all have done with the security and privacy
teams to get this in the right place. I believe permissions folks want to
follow up about the shape of the final implementation from a UX
perspective, so please ensure that you chat with +Illia Klimov
 and/or +Balazs Engedy  before
flipping the flags, but I think you're good to go from a web platform
perspective.

Thanks!

-mike


On Wed, Feb 23, 2022 at 2:07 PM Yoav Weiss  wrote:

> LGTM2
>
> This seems like an important use-case to tackle!
>
> On Tue, Feb 22, 2022 at 9:37 PM 'Ajay Rahatekar' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Hello Blink APi owners,
>>
>> Please let us know if you need more details. The team is targeting
>> shipping the API in M100 and would be very appreciative of early
>> feedback/approval to meet the milestone timeline requirements.
>>
>> Thanks in advance.
>>
>> Ajay
>>
>> On Friday, February 18, 2022 at 7:28:50 AM UTC-8 mike...@chromium.org
>> wrote:
>>
>>> Hi Michael,
>>>
>>> I think you and team have done a great job incorporating TAG and API
>>> ergonomics feedback (hi Jake!) as well as privacy concerns. Nice work.
>>>
>>> LGTM1.
>>>
>>> On 2/14/22 8:28 PM, Michael Wasserman wrote:
>>>
>>> Contact emails
>>>
>>> m...@chromium.org
>>>
>>>
>>> Explainer
>>>
>>> https://github.com/webscreens/window-placement
>>>
>>>
> Great explainer! Thanks for that!!
>
>>
>>> Specification
>>>
>>> https://webscreens.github.io/window-placement/
>>>
>>> Design docs  https://web.dev/multi-screen-window-placement/
>>> Summary
>>>
>>> Adds new screen information APIs and makes incremental improvements to
>>> existing window placement APIs, allowing web applications to offer
>>> compelling multi-screen experiences.
>>>
>>> The existing singular window.screen offers a limited view of available
>>> screen space, and window placement functions generally clamp bounds to the
>>> current screen. This feature unlocks modern multi-screen workspaces for web
>>> applications.
>>>
>>> Blink component
>>>
>>> UI>Browser>WebAppInstalls>Desktop
>>> 
>>>
>>> Search tags
>>>
>>> window placement
>>> , screen
>>> enumeration
>>> , window
>>> , open
>>> , moveTo
>>> , moveBy
>>> , requestFullscreen
>>> , screen
>>> , display
>>> , monitor
>>> , multi-screen
>>> , multi-display
>>> , multi-monitor
>>> , cross-screen
>>> , cross-display
>>> , cross-monitor
>>> 
>>>
>>> TAG review
>>>
>>> https://github.com/w3ctag/design-reviews/issues/413
>>> https://github.com/w3ctag/design-reviews/issues/522
>>> https://github.com/w3ctag/design-reviews/issues/602
>>>
>>> TAG review status
>>>
>>> Issues addressed
>>>
>>> Risks
>>> Interoperability and Compatibility
>>>
>>> Feature detection of new screen information APIs and Permission API
>>> integration allows sites to handle different levels of feature support. The
>>> Screen IDL interface duplicates EventTarget members for RuntimeEnabled
>>> experimentation without changing the stable JS API; this will be rectified
>>> after launch approval.
>>>
>>> Existing window placement APIs generally use compatible multi-screen
>>> coordinates, but implementations often restrict bounds to the current
>>> screen. We expect low levels of risk in supporting permitted cross-screen
>>> placement requests, and falling back on legacy same-screen behavior
>>> otherwise.
>>>
>>> A detailed assessment of API design risks, including Wayland
>>> compatibility, multiple virtual workspaces/desktops, and more, can be found
>>> at: <
>>> https://docs.google.com/document/d/19u5fRKs8iWlpecKBSlfQ6JKrcP4emwK0M_6TNhfz0gs
>>> >
>>>
>>> API surface changes made during the second origin trial are limited to
>>> some minor renames, the removal of two unimplemented screen properties, and
>>> support for permission policy. An exploratory permission-gated capability
>>> to swap the screen of fullscreen windows without a user gesture was
>>> reverted to enhance usable security. See <
>>> https://github.com/webscreens/window-placement/blob/main/CHANGES.md>
>>>
>>> The spec is being incubated in the W3C Second Screen CG 

Re: [blink-dev] Re: Intent to Extend Experiment: Origin Private File System extension: AccessHandle

[Mike West]

Hey Emanuel,

With my comments on the storage foundation I2E

in mind, it looks like good, cross-vendor progress is being made on
refining Access Handles' implementation and specification. There's clear
engagement from partners who have begun using the feature in ways that give
us confidence around it's broad shape and performance characteristics, and
it seems reasonable to me to extend the trial out a bit to give folks time
to hammer out the remaining details together.

LGTM to extend the experiment to 101. Ideally, that will allow y'all to
bring the spec into shape, resolve any remaining disagreements about the
API's behavior, and ensure our implementation matches those decisions.

-mike


On Wed, Jan 26, 2022 at 3:47 PM Yoav Weiss  wrote:

> Would you be able to answer the questions Chris asked on the Storage
> Foundation I2E? They seem relevant here as well. Thanks! :)
>
> On Thursday, January 20, 2022 at 4:06:34 PM UTC+1 Emanuel Krivoy wrote:
>
>> We’d like to ask for an extension to our Origin Trial, from M99 to M101.
>> As mentioned in the Storage Foundation I2E
>> ,
>> our partner intended to run a final series of tests with the new surface,
>> giving us a chance for to measure the impact of some of the design
>> decisions (the effect of a mixed sync/async surface and of all filesystem
>> operations being async). The tests were postponed and should happen in the
>> near future, and so we’d like to extend the trial to be able to gather
>> feedback from them.
>>
>> Please find the Chrome Status template below:
>>
>> Contact emails
>>
>> fived...@chromium.org, r...@chromium.org
>>
>> Explainer
>>
>> https://github.com/WICG/file-system-access/blob/main/AccessHandle.md
>>
>> Specification
>>
>> WIP Draft: https://github.com/WICG/file-system-access/pull/344
>>
>> Summary
>>
>> The Origin Private File System (OPFS, part of the File System Access API)
>> is augmented with a new surface that brings very performant access to data.
>> This new surface differs from existing ones by offering in-place and
>> exclusive write access to a file’s content. This change, along with the
>> ability to consistently read unflushed modifications and the availability
>> of a synchronous variant on dedicated workers, significantly improves
>> performance and unblocks new use cases (especially for porting existing
>> IO-heavy applications to WebAssembly).
>>
>> This Intent-to-Experiment is only in reference to the sync variant of the
>> API i.e., the createSyncAccessHandle() method and the SyncAccessHandle
>> object (only exposed in worker contexts):
>>
>> const handle = await file.createSyncAccessHandle();
>>
>> var writtenBytes = handle.write(buffer);
>>
>> var readBytes = handle.read(buffer {at: 1});
>>
>> The sync variant is meant to be consumed by low-level entities like
>> toolchains. We expect application developers to prefer the async API with
>> its streaming interface which will be shipped later.
>>
>> AccessHandles is the new API shape for what was previously called Storage
>> Foundation API (Intent-to-Experiment:
>> http://groups.google.com/a/chromium.org/g/blink-dev/c/Jhirhnq3WbY.
>>
>>
>> Blink component
>>
>> Blink>Storage>FileSystem
>> 
>>
>> TAG review
>>
>> https://github.com/w3ctag/design-reviews/issues/664
>>
>> TAG review status
>>
>> Closed, positive feedback.
>>
>> Risks
>> Interoperability and Compatibility
>>
>> The feature has to be compatible with existing ways to access data on
>> OPFS i.e., createWritable() and getFile(). The use of write locks and
>> care for backwards compatibility should mean that the risk here is low. In
>> order to ease compatibility concerns in the future, we've added an optional
>> 'mode' parameter to createAccessHandle()/createSyncAccessHandle(). This
>> allows us to eventually extend AccessHandle functionality to non-OPFS
>> file systems without necessarily taking the OPFS behaviour as default (more
>> details here:
>> https://github.com/WICG/file-system-access/blob/main/AccessHandle.md#exposing-accesshandles-on-all-filesystems
>> ).
>>
>> There is a risk of interoperability between vendors, pending the position
>> on implementing this surface. This design is the result of feedback from
>> Gecko and WebKit, who reviewed previous iterations of this functionality
>> and gave feedback that it should integrate more strongly with OPFS. We
>> directly shared documents outlining alternatives considered
>> ,
>> and later our recommendation
>> 
>> towards this particular API shape.
>>
>>
>>
>> We believe that the new design, when paired with a separate streams-based
>> 

Re: [blink-dev] Intent to Extend Experiment: Storage Foundation API

[Mike West]

Hey Emanuel,

API owners discussed this intent this week and the week before, with a fair
amount of skepticism around the length of the experimentation (April 2021
(90) - May 2022 (101)), and the value of continuing this experiment in
light of what looks like reasonable alignment from our colleagues in WebKit
and Gecko on the Access Handles proposal which y'all are working through in
parallel. With that in mind, the best path forward would be to let this
experiment expire rather than extending it. Unfortunately, it appears that
some miscommunication led a partner to begin relying on this API in ways
that make it difficult for us to simply remove support. This puts us in a
bit of a pickle.

I'd like to ensure that we don't end up in this situation again in 3 months
if we extend this OT to give the partner time to migrate off of Storage
Foundation. I think we have solid commitments from them that they'll be
able to shift onto Access Handles in the timeframe we're discussing, and I
think we can strengthen that encouragement by allowing them to extend their
OT tokens once, and then disabling new signups for the OT to ensure that
new partners don't accidentally land on this instead of Access Handles.
That's a compromise that seems to me to minimize the incremental risk of
burn-in, while allowing us to remove this API from the platform without
user-visible breakage. But it's an unusual extension, so I don't think a
single LGTM is sufficient to approve it.

LGTM1 to extend the trial to 101 _and_ disable new signups or renewals.
Ideally, the partner can complete their migration before 101, in which case
we can end the trial earlier. I'd appreciate other API owners weighing in.

-mike


On Tue, Feb 1, 2022 at 4:55 PM Emanuel Krivoy  wrote:

> Hi Chris,
>
> Replies inline as well:
>
> Is it accurate to say then that there hasn't been substantial use on sites
>> recently? Or are they using it generally but just haven't run the set of
>> tests yet?
>>
>
> The latter, Photoshop Web used Storage Foundation generally, and is now
> using Access Handles. Another partner has started a set test on their
> project, which would include feedback on the difference between the APIs
> from the perspective of new use cases.
>
> Also, could you summarize the feedback from partners so far on this origin
>> trial?
>>
>
> Feedback from partners has been very positive: Photoshop Web reported that
> both APIs critically unblocked their site, and did not see significant
> impact after transitioning to Access Handles. They use the API as a general
> purpose storage backend that can be performantily/easily accessed from
> Wasm, as well as a way to manage memory consumption during image editing.
> The other partner is also relying on Storage Foundation for critical bits
> of their project, although we've gotten less detailed feedback so far.
>
> On Thu, Jan 20, 2022 at 6:44 PM Chris Harrelson 
> wrote:
>
>> Hi Emanuel,
>>
>> A question inline below.
>>
>> On Thu, Jan 20, 2022 at 7:02 AM Emanuel Krivoy 
>> wrote:
>>
>>> Hello blink-dev,
>>>
>>>
>>>
>>> We’d like to ask for an extension to our Origin Trial, from M99 to M101.
>>> As mentioned in our previous I2E
>>> ,
>>> our partner intended to run a final series of tests that would allow us to
>>> measure the impact of the changes between Storage Foundation and its
>>> successor Access Handles. The tests were postponed but should happen in the
>>> near future, therefore we’d like to continue having concurrent Access
>>> Handle/Storage Foundation trials.
>>>
>>
>> Is it accurate to say then that there hasn't been substantial use on
>> sites recently? Or are they using it generally but just haven't run the set
>> of tests yet?
>>
>> Also, could you summarize the feedback from partners so far on this
>> origin trial?
>>
>>
>>>
>>>
>>> Please find the Chrome Status template below:
>>>
>>>
>>>
>>> Contact emails
>>>
>>> fived...@chromium.org, r...@chromium.org
>>>
>>> Explainer
>>>
>>> https://github.com/WICG/storage-foundation-api-explainer
>>>
>>> Specification
>>>
>>> N/A
>>>
>>> Summary
>>>
>>> Storage Foundation API is a storage API that resembles a very basic
>>> filesystem, with direct access to stored data through buffers and offsets.
>>> Our goal is to give developers flexibility by providing generic, simple,
>>> and performant primitives upon which they can build higher-level
>>> components. It's particularly well suited for Wasm-based libraries and
>>> applications that want to use custom storage algorithms to fine-tune
>>> execution speed and memory usage.
>>>
>>>
>>> Blink component
>>>
>>> Blink>Storage
>>> 
>>>
>>> Search tags
>>>
>>> storage , nativeio
>>> , performance
>>> , 

Re: [blink-dev] Re: Intent to Ship: HIDDevice forget()

[Mike West]

LGTM3.

-mike


On Wed, Feb 9, 2022 at 11:44 AM Daniel Bratell  wrote:

> LGTM2
>
> About web tests, is there no method that behaves differently in an
> observable way when the permission isn't given?
>
> /Daniel
> On 2022-02-09 10:27, Yoav Weiss wrote:
>
> LGTM1. Seems like a small and useful addition.
>
> On Tuesday, February 8, 2022 at 9:42:23 AM UTC+1 François Beaufort wrote:
>
>> Contact emails
>>
>> fbeauf...@google.com
>>
>> mattreyno...@google.com
>>
>> Explainer
>>
>> https://github.com/WICG/webhid/blob/main/EXPLAINER.md
>>
>> Specification
>>
>> https://wicg.github.io/webhid/#forget-method
>>
>> https://github.com/WICG/webhid/pull/84
>>
>> Summary
>>
>> The HIDDevice forget() method allows web developers to voluntarily revoke
>> a permission to a HIDDevice that was granted by a user.
>>
>> Blink component
>>
>> Blink>HID
>> 
>>
>> Motivation
>>
>> Some sites may not be interested in retaining long-term permissions to
>> access a HID device. For example, for an educational web application used
>> on a shared computer with many devices, a large number of accumulated
>> user-generated permissions creates a poor user experience. In addition
>> to user agent mitigations to avoid this problem, such as defaulting to a
>> session scoped permission on the first request or expiring infrequently
>> used permissions, it should be possible for the site itself to clean up
>> user-generated permissions it is no longer interested in retaining.
>>
>> // Request a HID device.
>>
>> const [device] = await navigator.hid.requestDevice({ filters: [] });
>>
>> // Then later... revoke permission to the HID device.
>>
>> await device.forget();
>>
>> We expect similar functionality to Web Bluetooth, WebUSB, and the Serial
>> API to be added.
>>
>> TAG review
>>
>> https://github.com/w3ctag/design-reviews/issues/703
>>
>> TAG review status
>>
>> Pending
>>
>> Risks
>> Interoperability and Compatibility
>>
>> This small addition to the HIDDevice object does not change the overall
>> status of WebHID interoperability or compatibility.
>>
>> Signals from other implementations (Gecko, WebKit):
>>
>> Gecko: No Signal [1]
>>
>> WebKit: No Signal [1]
>>
>> Web / Framework developers: Positive
>> https://github.com/WICG/webhid/issues/39
>>
>> Other signals: Google Meet folks have tried it and strongly support this
>> addition.
>>
>> [1] Both Gecko and WebKit are unlikely to object to this feature
>> specifically, but object to the overall WebHID API as a whole, hence it
>> doesn't make sense to bug them with specific questions on this.
>>
>> Activation:
>>
>> This feature can't be polyfilled. It should be fairly trivial for
>> developers to adopt this new feature.
>>
>> Debuggability
>>
>> No specific DevTools changes are required. This feature is treated like
>> any other JS method.
>>
>> Note that exposing DevTools debugging support for device-access APIs
>> (WebHID included) is discussed at
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1142566.
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?
>>
>> No, because permission storage is implemented outside of Blink and so
>> isn’t testable by web-platform-tests. Some tests that only verify the
>> presence of interfaces and attributes will be available at
>> https://wpt.fyi/results/webhid though.
>>
>> Requires code in //chrome?
>>
>> Yes, permission storage is implemented in //chrome.
>>
>> Tracking bug
>>
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1279822
>>
>> Estimated milestones
>>
>> 100
>>
>> Link to entry on the Chrome Platform Status
>>
>> https://chromestatus.com/feature/5723581527883776
>>
>> Links to previous Intent discussions
>>
>> Intent to prototype:
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/c2vCYr-0dqk/m/3nSeViRLCgAJ
>>
> --
> 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/bbd12314-8ade-4a84-a31c-dea7964344dcn%40chromium.org
> 
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/810d856e-4ff3-b2d2-c3fd-598d08bdfb5b%40gmail.com
> 

Re: [blink-dev] Intent to Prototype and Ship: User-Agent Reduction Phase 4 (minor version reduction)

[Mike West]

LGTM3.

-mike

On Tuesday, February 1, 2022 at 10:37:59 PM UTC+1 Rick Byers wrote:

> LGTM2
>
> On Tue, Feb 1, 2022 at 1:27 PM Domenic Denicola  
> wrote:
>
>>
>>
>> On Tue, Feb 1, 2022 at 11:24 AM Mike Taylor  
>> wrote:
>>
>>> *Contact emails*
>>>
>>>
>>>
>>> * miketa...@chromium.org , abe...@chromium.org 
>>> , jadekess...@chromium.org  
>>> Explainer 
>>> https://github.com/WICG/ua-client-hints#explainer-reducing-user-agent-granularity
>>>  
>>> 
>>>  
>>> Specification https://www.chromium.org/updates/ua-reduction 
>>>  is the closest thing that 
>>> specifies Chrome’s UA Reduction plans today. As these changes land in 
>>> Chromium, the Compat Standard  will be 
>>> updated to reflect them (in the newly landed UA String section 
>>> ).*
>>>
>>
>> I want to call out that this is some really great work. For years specs 
>> have basically said "use an implementation-defined value", but we knew that 
>> was not sufficient for web compatibility, and it was not useful to web 
>> developers or implementers. Years ago we started to capture some 
>> interesting constraints in HTML's definition of navigator compatibility 
>> mode , 
>> but we knew there were many more.
>>
>> The work Mike has done has started to address this long-standing issue of 
>> spec tech debt, and it's really great that he's put in the extra work here 
>> instead of just taking advantage of the spec's historical looseness.
>>
>> I did a quick review on the spec and found some minor issues and clarity 
>> improvement suggestions 
>> , but 
>> overall this is a great foundation and gives me confidence others can both 
>> follow along with our plans, and implement compatible software based on 
>> them.
>>  
>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> * Summary As previously detailed on the Chromium Blog 
>>> ,
>>>  
>>> we intend to proceed with Phase 4 of the User-Agent Reduction plan. In 
>>> Phase 4, the MINOR.BUILD.PATCH version numbers are reduced to "0.0.0". For 
>>> use cases requiring high-entropy full version information, developers are 
>>> encouraged to migrate to the User Agent Client Hints API 
>>> , in particular the 
>>> Sec-CH-UA-Full-Version-List 
>>>  hint. 
>>> Blink component Blink 
>>>  TAG 
>>> review https://github.com/w3ctag/design-reviews/issues/640 
>>>  TAG review status 
>>> Issues addressed Risks Interoperability and Compatibility Any time you 
>>> modify the User-Agent string there is a risk of some content somewhere 
>>> depending on the previous format. There should not be interop risks, as 
>>> each browser sends its own User-Agent string. But there is a risk that 
>>> content somewhere is relying on “non-zero” MINOR, BUILD, or PATCH 
>>> information. My personal view is that the risk is low compared to the rest 
>>> of the changes to come in later phases. But in order to mitigate the risk 
>>> of this change, we intend to slowly roll it out via Finch and observe 
>>> health metrics (i.e., HTTP 4XX and 5XX error codes, etc.) and bug reports 
>>> from the community. We've surveyed dozens of User-Agent parsing libraries, 
>>> and as far as we know "0.0.0" will not create a problem syntactically. But 
>>> the web can get pretty weird in ways we don't anticipate, hence the slow 
>>> roll-out and incremental path towards User-Agent Reduction. Gecko: 
>>> Shipped/Shipping. Firefox has frozen (or capped) much of their UA string 
>>> already. WebKit: Shipped/Shipping. Safari has already frozen everything in 
>>> their UA string except for version number info. Web developers: Mixed 
>>> signals. Reactions have ranged from positive to indifferent to negative, 
>>> from various channels. Debuggability No special DevTools support needed. Is 
>>> this feature fully tested by web-platform-tests 
>>> ?
>>>  
>>> No Flag name reduce-user-agent Requires code in //chrome? False Tracking 
>>> bug https://bugs.chromium.org/p/chromium/issues/detail?id=1282229 
>>>  Launch bug 
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1282238 
>>>  Estimated 
>>> milestones We aim to start rollout in M101. We will update 

Re: [blink-dev] Intent to Deprecate and Remove: Support for filesystem URLs on Android media

[Mike West]

Thanks for the background, Victor! To your question: I don't think dropping 
`filesystem:` is more important than dropping WebSQL, but I share your 
excitement about deprecating the filesystem API.

Brianna, I'm still interested in understanding whether the numbers you 
posted for other platforms reflect usage in media elements or usage 
overall. If the numbers for media elements specifically on all platforms 
are as low as they are on Android, I'd prefer for us to remove usage 
through media elements everywhere. That seems more consistent and 
explainable if we can get away with it.

-mike

On Tuesday, February 1, 2022 at 10:47:45 PM UTC+1 Rick Byers wrote:

> Given the plan to deprecate this blink-only technology, it does seem silly 
> to do extra work to keep this one obscure case working. I agree though that 
> developer confusion is a potential concern. Perhaps an exception / 
> window.onerror explaining the reason for the failure to play media is 
> enough? +1 to having a deprecation plan we can point to for at least the 
> filesystem: URL, then perhaps this can just be the first step in that plan?
>
> Rick
>
> On Tue, Feb 1, 2022 at 12:17 PM Victor Costan  wrote:
>
>> Some background:
>>
>>- The *filesystem:* URL scheme was introduced to the *File API: 
>>Directories and System* specification 
>><https://dev.w3.org/2009/dap/file-system/file-dir-sys.html>, which I 
>>generally refer to as *the old FileSystem API*. This API is only 
>>implemented in Blink (maybe it was in the pre-fork WebKit?). To the best 
>> of 
>>my knowledge, it was never shipped in Safari, Firefox, IE, or EdgeHTML.
>>- The main benefit (for developers) of *filesystem:* URLs over *blob:* 
>>is their indefinite lifetime. Blob URLs only live as long as the frame 
>> that 
>>created them. This property made them very attractive for serving 
>>sub-resources stored locally, at a time when we didn't have Service 
>> Workers.
>>- We intentionally left the *filesystem:* URL scheme out of the File 
>>System Access API <https://wicg.github.io/file-system-access/>. 
>>Service Workers have a clear model that works well for both top-level 
>>navigation and sub-resources.
>>
>> We (the folks maintaining storage APIs in Chromium) would very much like 
>> to deprecate the entire old FileSystem API, beginning with the 
>> *filesystem:* URL scheme. We want to be cognizant of introducing too 
>> much stress on the ecosystem, though -- we just finished removing AppCache 
>> from Blink, and we're planning to focus on WebSQL next. Though, maybe 
>> you're saying that *filesystem:* URLs are worse, and we should tackle 
>> them first?
>>
>> I hope this helps!
>> Victor
>>
>>
>>
>>
>>
>> On Tue, Feb 1, 2022 at 1:32 AM Mike West  wrote:
>>
>>> I worry that removing `filesystem:` for media elements on Android, while 
>>> maintaining support for other platforms, will end up causing some developer 
>>> confusion without much value for the codebase as a whole (since we need to 
>>> maintain all the exciting bits and pieces of infrastructure). Are the 
>>> numbers you quoted for media elements on those other platforms, or all 
>>> element types? Perhaps we could remove support for media elements on all 
>>> platforms if there's substantial benefit to doing so.
>>>
>>> Honestly, I'd prefer that we outline a plan to fully remove 
>>> `filesystem:` if we're not going to support it going forward (+Josh and 
>>> +Victor). It has some pretty complicated effects on the security state of 
>>> navigations, and while we have a reasonable plan for PolicyContainer 
>>> integration with `blob:` URLs, we're still a ways away from doing the same 
>>> for `filesystem:`. Is there a path towards deprecating and dropping support 
>>> on other platforms? The large ChromeOS usage makes me somewhat suspicious 
>>> that this is wrapped up in one Google property or another... have y'all 
>>> done that analysis?
>>>
>>> -mike
>>> On Wednesday, January 26, 2022 at 7:48:54 PM UTC+1 Brianna Goldstein 
>>> wrote:
>>>
>>>> Additionally to follow up on @Chris Harrelson 's 
>>>> question on usage - Chrome OS usage is 1.38%, Mac OSX is at 0.12% and 
>>>> Windows is 0.05%. We propose to only remove support for Android here.
>>>>
>>>> On Tue, Jan 25, 2022 at 7:13 PM Chris Harrelson  
>>>> wrote:
>>>>
>>>>> Hi, could you outline the use counter values for other platforms? 
>&

[blink-dev] Re: Intent To Experiment: User-Agent Client Hints GREASE Update

[Mike West]

LGTM to experiment with this change on a small percentage of stable in M98 
and M99. Presumably you'll be keeping an eye on metrics and bug reports to 
roll it back in case unexpected incompatibility is discovered.

Out of curiosity, what is the new character set with which you'll be 
working? The spec link was fairly generic, describing a strategy rather 
than an algorithm.

-mike

On Wednesday, January 26, 2022 at 11:18:56 PM UTC+1 Matt Reichhoff wrote:

> Contact emails
>
> mreichh...@chromium.org, miketa...@chromium.org, jadekess...@chromium.org
>
> Explainer
>
> https://github.com/WICG/ua-client-hints#user-agent-client-hints
>
> Specification
>
> https://wicg.github.io/ua-client-hints/#grease
>
> Summary
>
> We seek to align our implementation of GREASE in User Agent Client Hints 
> with the current spec, which includes additional GREASE characters beyond 
> the current semicolon and space, and which recommends varying the arbitrary 
> version. This is to help prevent bad assumptions from being built on top of 
> User-Agent strings.
>
> This intent seeks approval to begin an experiment on stable at 1% with the 
> m98 release. Due to a clerical error, the experiment is already running on 
> m98 in beta. The goal is to determine whether the new spec is web 
> compatible via a controlled experiment before we ship to stable.
>
>
> Blink component
>
> Privacy>Fingerprinting 
> 
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/640
>
> TAG review status
>
> In progress, but all raised issues addressed.
>
> Risks
> Interoperability and Compatibility
>
> The prior inclusion (in 2020) of escaped ASCII 0x22 (double quote) and 
> 0x5C (backslash) proved to be web incompatible and was rolled back. While 
> we do not anticipate similar problems with the updated character list, we 
> have taken (or will take) the following actions to validate this assumption:
>
>- 
>
>Pre-launch testing of the new characters against known-common sites, 
>which will include tests against the components known to have been 
>incompatible with the prior implementation [COMPLETED].
>- 
>
>Addition of an enterprise policy escape hatch [COMPLETE].
>- 
>
>A phased rollout along with monitoring of HTTP 4XX response rates 
>[PROPOSED HERE].
>
>
> Gecko: Non-harmful (
> https://mozilla.github.io/standards-positions/#ua-client-hints)
>
> WebKit: No signal
>
> Web developers: No signals
>
> Other signals: N/A
>
>
> Goals for experimentation
>
> A phased rollout is desired to ensure the changes to the spec are 
> web-compatible. To that end, we will begin with 1% of users on stable, with 
> monitoring of HTTP response codes to ensure the change is non-breaking.
>
>
> Debuggability
>
> N/A; no change required
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac, 
> Linux, Chrome OS, Android, and Android WebView)?
>
> No (not on WebView or iOS)
>
> Is this feature fully tested by web-platform-tests 
> 
> ?
>
> Yes 
> 
>
> Flag name
>
> --enable-features="GreaseUACH:updated_algorithm/true"
>
> Tracking bug
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=1164423
>
> Estimated milestones
>
> We anticipate this experiment starting in M98 and running for 2 
> milestones, but it could extend if the data is inconclusive. We are most 
> concerned about website tail behavior with this change, which can make data 
> gathering slower than we’d like.
>
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5630916006248448
>
> Links to previous Intent discussionsIntent to prototype: 
> https://groups.google.com/a/chromium.org/g/blink-dev/c/ueudFsZzT1M
>

-- 
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/24ec02cd-4ccb-4b9a-b6fd-04dcec9eb5c5n%40chromium.org.

Re: [blink-dev] Intent to Deprecate and Remove: Support for filesystem URLs on Android media

[Mike West]

I worry that removing `filesystem:` for media elements on Android, while 
maintaining support for other platforms, will end up causing some developer 
confusion without much value for the codebase as a whole (since we need to 
maintain all the exciting bits and pieces of infrastructure). Are the 
numbers you quoted for media elements on those other platforms, or all 
element types? Perhaps we could remove support for media elements on all 
platforms if there's substantial benefit to doing so.

Honestly, I'd prefer that we outline a plan to fully remove `filesystem:` 
if we're not going to support it going forward (+Josh and +Victor). It has 
some pretty complicated effects on the security state of navigations, and 
while we have a reasonable plan for PolicyContainer integration with 
`blob:` URLs, we're still a ways away from doing the same for 
`filesystem:`. Is there a path towards deprecating and dropping support on 
other platforms? The large ChromeOS usage makes me somewhat suspicious that 
this is wrapped up in one Google property or another... have y'all done 
that analysis?

-mike
On Wednesday, January 26, 2022 at 7:48:54 PM UTC+1 Brianna Goldstein wrote:

> Additionally to follow up on @Chris Harrelson 's 
> question on usage - Chrome OS usage is 1.38%, Mac OSX is at 0.12% and 
> Windows is 0.05%. We propose to only remove support for Android here.
>
> On Tue, Jan 25, 2022 at 7:13 PM Chris Harrelson  
> wrote:
>
>> Hi, could you outline the use counter values for other platforms? Also, 
>> is there something special about Android that leads you to want to disable 
>> only there?
>>
>> On Tue, Jan 25, 2022 at 1:58 PM Brianna Goldstein <
>> brgoldst...@chromium.org> wrote:
>>
>>> Primary eng (and PM) emails
>>>
>>> brgoldst...@google.com, m...@chromium.com , 
>>> jadekess...@chromium.com
>>>
>>> Explainer
>>>
>>> Storage partitioning explainer 
>>> 
>>>
>>> Summary
>>>
>>> We propose to remove support for loading media via filesystem:// URLs on 
>>> Android.
>>>
>>>
>>> Motivation
>>>
>>> As part of our storage partitioning efforts, we will need to update 
>>> Filesystem URLs to be partitioned by StorageKey rather than by Origin. 
>>> Doing this will add complexity since the entire current codepath on Android 
>>> is not dependent on Blink where StorageKey currently lives. On Android only 
>>> 0.001% of URLs loaded by  or  use the filesystem:// URL 
>>> scheme and we consider this low enough usage to remove support, rather than 
>>> do the work of partitioning. Note that this removal is only for Android. On 
>>> other platforms there will be no effect and media playback of filesystem:// 
>>> URLs will continue to work.
>>>
>>> Blink component
>>>
>>> Blink>Storage 
>>> 
>>>
>>> Initial public proposal 
>>>
>>> None
>>>
>>> TAG review
>>>
>>> None
>>>
>>> TAG review status
>>>
>>> N/A
>>>
>>> Interoperability and Compatibility RiskInteroperability risk:
>>>
>>> The filesystem:// URL scheme was never widely adopted and is only 
>>> implemented by Chrome. Therefore there should be no interoperability risks 
>>> associated with this feature depreciation.
>>>
>>> Compatibility risk:
>>>
>>> This feature is very low usage as only 0.001% of URLs loaded by 
>>>  or  use the filesystem:// URL scheme. Therefore the expected 
>>> compatibility risk is very low.
>>>
>>> Alternative implementation suggestion for web developers
>>>
>>> Developers can continue to load media from other schemes (http, https, 
>>> blob, file, etc.).
>>>
>>> Usage information from UMA
>>>
>>> Android Chrome (Browser App): 0.001%
>>>
>>> Android Webview: 0.0%
>>>
>>> Tracking Bug
>>>
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1258029
>>>
>>> Entry on the feature dashboard
>>>
>>> https://chromestatus.com/feature/5632429577469952
>>>
>>> -- 
>>> 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/CALDP-vS2KA47PGLh3YkxqAr9z24nP1_u%2BtvY6eWzqSQgq987cQ%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/8670f31d-d4d2-443f-8757-250bb5611cdbn%40chromium.org.

Re: [blink-dev] Intent to Experiment: Conditional Focus

[Mike West]

Hey Elad!

Did anyone at all use this feature via the OT? If so, it would be helpful 
to understand whether you had any feedback that would inform this new 
experiment.

If no one used it at all, then this really would be a no-op, and I think 
we'd happily approve shifting the milestones.

-mike

On Thursday, January 20, 2022 at 12:04:58 PM UTC+1 Elad Alon wrote:

> The partner I had for this feature had a change of scheduling, and will 
> only be set to deploy their test use of it in about a month. I would 
> therefore like to reset this experiment, stopping it for 3 weeks and then 
> starting it afresh in m99-m102 (inclusive). Wdys?
> Relevant: Discussions about standardizing this feature are proceeding and 
> there seems to be interest from Mozilla and Apple. See here 
> .
>
> On Thursday, September 23, 2021 at 4:16:42 PM UTC+2 yoav...@chromium.org 
> wrote:
>
>> LGTM to experiment M96-M99 inclusive
>>
>> On Thu, Sep 23, 2021 at 4:04 PM Elad Alon  wrote:
>>
> m99, inclusive. So four milestones in total.
>>>
>>> On Thu, Sep 23, 2021 at 3:53 PM Yoav Weiss  wrote:
>>>
>>

 On Thu, Sep 23, 2021 at 3:00 PM Elad Alon  wrote:

> Might be good to move this to WICG to facilitate contributions (given 
>> support 
>> 
>> ).
>>
>
> WICG issue #37  asked 
> for this to be adopted by the WICG. (The same partner supported it there 
> too, btw.)
>
  Ping me and we'll move it over! :) 
>>   
>>
>>>  
>
>> https://github.com/WICG/proposals/issues/37#issuecomment-920673070 
>> seems like a positive signal (even if from a single partner).
>>
>
> Yes. And Mozilla and Apple also seemed interested in the use-case 
> during the WebRTC Working Group interim meeting of September 2021, 
> although 
> we're still discussing the specific details.
>  
>
>> What are the goals for the experiment?
>>
>
> Validate that the proposed API solves developers' issues in a 
> satisfactory manner.
>  
>
>> What are the timeframes for the experimentation? Do you have partners 
>> lined up?
>>
>
> Two internal (Google), one external (Tella).
>

 What's the end milestone you're targeting? 

>>>

-- 
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/5a12be9a-9df5-4d05-91de-3af01cd16489n%40chromium.org.

Re: [blink-dev] Intent to Prototype: Transferable MediaStreamTracks

[Mike West]

Hey Tony!

My understanding of the transfer mechanism is that the transferring context
loses control of the stream, handing it off to the receiving context. The
stream source remains with the original context, however, and I'm wondering
whether that provides an opportunity for replicating the timing attacks
that SharedArrayBuffers enabled
.
Given the ability to clone streams, it seems possible for a source in one
context to be writeable in one context, and readable from multiple contexts.

Have y'all thought about that potential threat? Is it actually a risk, or
have I missed things? :)

/cc +Artur Janc 

-mike


On Wed, Jan 19, 2022 at 5:07 PM 'Tony Herre' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emailshe...@google.com, h...@chromium.org
>
> ExplainerNone
>
> Specification
> https://w3c.github.io/mediacapture-extensions/#transferable-mediastreamtrack
>
> Summary
>
> Expose MediaStreamTracks in Workers and allow them to be transferred
> between contexts. Allowing this transfer makes it easier to access and
> process media in contexts other that where it was created, eg in Workers or
> other documents.
>
>
> Blink componentBlink>MediaStream
> 
>
> Motivation
>
> Having transferable MediaStreamTracks allows much more flexibility for
> architecting web applications which have multiple windows which each wish
> to contribute video or audio tracks to a single WebRTC conference, without
> having to have independent competing network connections via
> PeerConnection. This also allows transferring all media processing to a
> separate context eg a worker, rather than mediating control signals through
> the window.
>
>
> Initial public proposal
>
> TAG review
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
>
>
> Gecko: No signal
> Positive in WebRTC Working Group discussions
>
> WebKit: No signal
> Positive in WebRTC Working Group discussions
>
> Web developers: No signals
>
> Other signals:
>
>
>
> Debuggability
>
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?No
>
> Flag name
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1288839
>
> Estimated milestones
>
> No milestones specified
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5747241384935424
>
> This intent message was generated by Chrome Platform Status
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAArnMxEAdAdKs-T5o_TWCnvXpWEXiXDvpoxz_zpwADn%2BpyBwEA%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/CAKXHy%3DeJuNyf2P8EdtuUONouqCG6bL-7PKi_z2iBVqjxkvXqXg%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: TLS ALPN extension in wss-schemed WebSockets connections

[Mike West]

I see. Thanks for the additional detail!

This still LGTM2, though. As you note, this brings us closer to what other
vendors are doing, and a better solution is going to require some new
agreement between folks about how to handle the set of servers you're
pointing at. Implementing that sounds like it would reasonably be
considered a separate intent.

-mike


On Thu, Jan 20, 2022 at 4:58 PM David Benjamin 
wrote:

> Well, there is, alas, still a difference because HTTP/2 + WebSockets is
> complicated.  But less of one at least. :-)
>
> (WebSockets support wasn't part of HTTP/2, and HTTP/3 for that matter,
> from the beginning. That means we can't be sure an HTTP/2-supporting server
> doesn't also support WebSockets, yet predate RFC 8441, and thus expect us
> to drop HTTP/2 for wss requests. So while we implement RFC 8441, it only
> kicks in if we happen to already have a suitable HTTP/2 connection on-hand.
> If we have to make a new connection, we drop HTTP/2 and only offer
> HTTP/1.1. Possibly something fancier ought to be done here, be it
> out-of-band signaling, defining an "h2+wss" ALPN, some kind of fallback
> like Firefox does, racing two connections, or whatever else. This Intent
> would be a prerequisite to doing that, but leaves the question for later.)
>
> On Thu, Jan 20, 2022 at 5:49 AM Mike West  wrote:
>
>> LGTM2. From a Fetch perspective, there shouldn't be a difference between
>> the way we establish a Web Socket connection and regular ol' HTTP requests.
>> Aligning our behavior with other vendors in this respect is appreciated!
>>
>> -mike
>>
>>
>> On Thu, Jan 20, 2022 at 12:22 AM Mike Taylor 
>> wrote:
>>
>>> LGTM1, thanks for improving interop here.
>>>
>>> On 1/19/22 3:22 PM, David Benjamin wrote:
>>>
>>> Contact emails david...@chromium.org
>>>
>>> Specification https://datatracker.ietf.org/doc/html/rfc7301
>>>
>>> Summary
>>>
>>> This is a PSA about a small tweak to an existing feature. The change is
>>> to include the TLS ALPN extension when initiating a new connection for
>>> wss-schemed WebSockets, offering just the default "http/1.1" protocol.
>>> Currently, unlike HTTPS connections, such connections do not offer ALPN in
>>> Chrome at all. Changing this aligns with Firefox and Safari, hardens
>>> against cross-protocol attacks (see ALPACA), and makes wss eligible for the
>>> False Start optimization. It also simplifies work on the HTTPS DNS record.
>>>
>>>
>>> Blink component Internals>Network>SSL
>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3ENetwork%3ESSL>
>>>
>>> TAG review status Not applicable
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> Interoperability risk is low. Firefox and Safari are already both
>>> offering ALPN for WebSockets requests, as does Chrome for HTTPS requests.
>>> This change does not impact the HTTP version we use for WebSockets itself,
>>> nor does it require servers to implement ALPN. Whether the server accepts
>>> ALPN or not, we will continue to speak WebSockets over HTTP/1.1.
>>>
>>>
>>> Gecko: Shipped/Shipping (Firefox appears to actually initially offer
>>> both "h2" and "http/1.1". Then, if it finds an HTTP/2 server without RFC
>>> 8441 support, it retries, only offering "http/1.1". Either way, it always
>>> offers ALPN.)
>>>
>>> WebKit: Shipped/Shipping (Confirmed via Wireshark)
>>>
>>> Web developers: No signals
>>>
>>> Other signals:
>>>
>>>
>>> Debuggability
>>>
>>> Existing DevTools support for networking and WebSockets applies
>>>
>>>
>>> Is this feature fully tested by web-platform-tests
>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>
>>> ?
>>> n/a
>>>
>>> Requires code in //chrome? False
>>>
>>> Estimated milestones
>>>
>>> Chrome 100, as 99 is just about to branch
>>>
>>>
>>> Link to entry on the Chrome Platform Status
>>> https://chromestatus.com/feature/5687059162333184
>>>
>>> This intent message was generated by Chrome Platform Status
>>> <https://chromestatus.com/>.
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "blink-dev" group.
>>> To unsub

Re: [blink-dev] Intent to Ship: TLS ALPN extension in wss-schemed WebSockets connections

[Mike West]

LGTM2. From a Fetch perspective, there shouldn't be a difference between
the way we establish a Web Socket connection and regular ol' HTTP requests.
Aligning our behavior with other vendors in this respect is appreciated!

-mike


On Thu, Jan 20, 2022 at 12:22 AM Mike Taylor  wrote:

> LGTM1, thanks for improving interop here.
>
> On 1/19/22 3:22 PM, David Benjamin wrote:
>
> Contact emails david...@chromium.org
>
> Specification https://datatracker.ietf.org/doc/html/rfc7301
>
> Summary
>
> This is a PSA about a small tweak to an existing feature. The change is to
> include the TLS ALPN extension when initiating a new connection for
> wss-schemed WebSockets, offering just the default "http/1.1" protocol.
> Currently, unlike HTTPS connections, such connections do not offer ALPN in
> Chrome at all. Changing this aligns with Firefox and Safari, hardens
> against cross-protocol attacks (see ALPACA), and makes wss eligible for the
> False Start optimization. It also simplifies work on the HTTPS DNS record.
>
>
> Blink component Internals>Network>SSL
> 
>
> TAG review status Not applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> Interoperability risk is low. Firefox and Safari are already both offering
> ALPN for WebSockets requests, as does Chrome for HTTPS requests. This
> change does not impact the HTTP version we use for WebSockets itself, nor
> does it require servers to implement ALPN. Whether the server accepts ALPN
> or not, we will continue to speak WebSockets over HTTP/1.1.
>
>
> Gecko: Shipped/Shipping (Firefox appears to actually initially offer both
> "h2" and "http/1.1". Then, if it finds an HTTP/2 server without RFC 8441
> support, it retries, only offering "http/1.1". Either way, it always offers
> ALPN.)
>
> WebKit: Shipped/Shipping (Confirmed via Wireshark)
>
> Web developers: No signals
>
> Other signals:
>
>
> Debuggability
>
> Existing DevTools support for networking and WebSockets applies
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?
> n/a
>
> Requires code in //chrome? False
>
> Estimated milestones
>
> Chrome 100, as 99 is just about to branch
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5687059162333184
>
> This intent message was generated by Chrome Platform Status
> .
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAF8qwaA1Y_GZDk0qNc_%3DhVLhye%3DScEtxjPSdEPD-mM4zpVp50Q%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/26bac4d2-1d15-5ef5-d917-6ce7411ef6d3%40chromium.org
> 
> .
>

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

Re: [blink-dev] Intent to Deprecate and Remove: Battery Status API in Insecure Origins

[Mike West]

LGTM1 to restrict this API to secure contexts with a 3 milestone
deprecation window. If blockers come up in the meantime, we can reevaluate,
but I'm satisfied with the spot checks you've done against existing usage.

-mike


On Fri, Jan 14, 2022 at 11:28 AM 'Thomas Steiner' via blink-dev <
blink-dev@chromium.org> wrote:

> On Thu, Jan 13, 2022 at 6:29 PM Chris Harrelson 
> wrote:
>
>> This generally looks good to me, and probably safe to do. However, it'd
>> make me more confident if we could reduce the 0.3%. Is YouTube willing to
>> turn off their usage now? My guess is that will be most of the 0.3%. @Thomas
>> Steiner  is that doable?
>>
>
> YouTube have said in http://b/19428619#comment16 (sorry, Google-internal)
> that this would not be a problem for them.
>
> Cheers,
> 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/CALgRrLnow3GAvQEPW0BHOg8uzzyubzfZQxD0YWbhHrCJqMpy7g%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/CAKXHy%3DcLeMWvo4ifTMq6N49v%3D5d_5h9qwNYZC__T9Q-wZs8CkQ%40mail.gmail.com.

Re: [blink-dev] Intent to Extend Experiment: Same-origin prerendering triggered by the speculation rules API

[Mike West]

LGTM. Good luck with the extension!

-mike

On Thu 16. Dec 2021 at 02:50 Hiroki Nakagawa  wrote:

> Good point. I think actually they don't need 4 more milestones for
> starting the experiment, so extending to 100 should be enough. Let me
> change the requesting milestones as follows:
>
> Estimated milestones
>
> Previous experiment timeline: M94 to M98
>
> Requested extension timeline: *M99 to M100*
>
>
> On Thu, Dec 16, 2021 at 12:33 AM Mike West  wrote:
>
>> In that case, do you need 4 more milestones? We've set a cap of 9
>> milestones
>> <https://www.chromium.org/blink/origin-trials/running-an-origin-trial#:~:text=16%20weeks)%2C%20with%20a-,cap%20of%209%20milestones,-(~36%20weeks)%20absent>
>>  for
>> OTs generally; this would bring y'all to 8. Do you need that entire period
>> if folks are actively experimenting now? If folks started testing in 97,
>> extending to 100 would give them 4 milestones to work with, which might be
>> enough?
>>
>> -mike
>>
>>
>> On Wed, Dec 15, 2021 at 4:22 PM Hiroki Nakagawa 
>> wrote:
>>
>>> Hi Mike,
>>>
>>> We are aware that some sites are now running their experiments. In
>>> addition to that, another site has been preparing for the experiment. We
>>> are now actively helping them.
>>>
>>> On Thu, Dec 16, 2021 at 12:08 AM Mike West  wrote:
>>>
>>>> Was any site able to try this out during the initial experimental
>>>> period? Or is this really just a delayed start to the trial? I think it's
>>>> reasonable to extend out 4 additional milestones, but if you really didn't
>>>> see any usage at all, it might be reasonable to consider this as a new
>>>> starting date as opposed to an extension.
>>>>
>>>> -mike
>>>>
>>>>
>>>> On Wed, Dec 15, 2021 at 1:45 PM Hiroki Nakagawa 
>>>> wrote:
>>>>
>>>>> Hi Yoav,
>>>>> The requesting milestones are from M99 to M103 (The previous
>>>>> milestones were from M94 to M98).
>>>>>
>>>>>
>>>>> On Wed, Dec 15, 2021 at 6:02 PM Yoav Weiss 
>>>>> wrote:
>>>>>
>>>>>> What are the milestones for the continued experimentation?
>>>>>>
>>>>>> On Wed, Dec 15, 2021 at 2:12 AM Hiroki Nakagawa 
>>>>>> wrote:
>>>>>>
>>>>>>> Contact emails
>>>>>>>
>>>>>>> nhir...@chromium.org, navigation-...@chromium.org
>>>>>>>
>>>>>>> Explainer
>>>>>>>
>>>>>>> This feature:
>>>>>>> <https://chromestatus.com/admin/features/launch/5355965538893824/This%20feature:%20https://github.com/jeremyroman/alternate-loading-modes/blob/main/same-origin-explainer.md>
>>>>>>> https://github.com/WICG/nav-speculation/blob/main/same-origin-explainer.md
>>>>>>>
>>>>>>> This trial:
>>>>>>> https://github.com/WICG/nav-speculation/blob/main/same-origin-chrome-origin-trial.md
>>>>>>>
>>>>>>> Larger project:
>>>>>>> <https://chromestatus.com/admin/features/launch/5355965538893824/Larger%20project:%20https://github.com/jeremyroman/alternate-loading-modes/blob/main/README.md>
>>>>>>> https://github.com/WICG/nav-speculation/blob/main/README.md
>>>>>>>
>>>>>>> Specification
>>>>>>>
>>>>>>> https://wicg.github.io/nav-speculation/prerendering.html
>>>>>>>
>>>>>>> Design docs
>>>>>>>
>>>>>>>
>>>>>>> https://docs.google.com/document/d/1P2VKCLpmnNm_cRAjUeE-bqLL0bslL_zKqiNeCzNom_w/edit?usp=sharing
>>>>>>>
>>>>>>> Summary
>>>>>>>
>>>>>>> Prerendering loads a web page before it is needed, so that when the
>>>>>>> actual navigation to that page occurs, it can be shown instantly.
>>>>>>>
>>>>>>> This experiment is for the specific case of same-origin prerendering
>>>>>>> triggered by the Speculation Rules API. An earlier, related experiment
>>>>>>> supported prefetching
>>>>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/Cw-hOjT47qI/m/EObn9-4MAgAJ>
>>>>>>> using this API. This is a se