Re: [EXTERNAL] Re: [blink-dev] Re: Intent to Prototype: Confirmation of Action API

['Sara Tang' via blink-dev]

Good suggestion Yaov! I've opened one here: Review request for Confirmation of 
Action API * Issue #713 * w3ctag/design-reviews 
(github.com)

From: Yoav Weiss 
Sent: Monday, January 31, 2022 6:33 AM
To: Sara Tang 
Cc: blink-dev@chromium.org ; Daniel Libby 

Subject: [EXTERNAL] Re: [blink-dev] Re: Intent to Prototype: Confirmation of 
Action API



On Sat, Jan 29, 2022 at 1:27 AM 'Sara Tang' via blink-dev 
mailto:blink-dev@chromium.org>> wrote:
+Daniel Libby

From: Sara Tang
Sent: Friday, January 28, 2022 4:26 PM
To: blink-dev@chromium.org 
mailto:blink-dev@chromium.org>>
Subject: Intent to Prototype: Confirmation of Action API

Contact emails
sart...@microsoft.com

Explainer
https://github.com/WICG/aom/blob/gh-pages/notification-api.md

Specification


Summary

This effort aims to create a JavaScript API so that developers can better 
notify AT users of actions/changes to a webpage not necessarily tied to UI 
elements.


Blink component
Blink>Accessibility

Motivation

Currently the only mechanism available today that communicates content changes 
in a web app down to the accessibility layer is via ARIA live regions. One 
major limitation to ARIA live regions is that they assume the change to a 
webpage is tied to a DOM element. This leads to content authors employing 
various inefficient or inconsistent tricks and hacks to notify of changes that 
are not associated with the DOM. We propose a separate notification API to 
address these scenarios, called Confirmation of Action.


Initial public proposal
https://github.com/WICG/aom/blob/gh-pages/notification-api.md

TAG review


Just wanted to note that it seems worthwhile to file for an early TAG review.


TAG review status
Pending

Risks


Interoperability and Compatibility


Gecko: No signal

WebKit: No signal

Web developers: Positive 
(https://github.com/w3c/aria/issues/832)

Other signals:


Debuggability

TBD


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

Flag name
--enable-blink-features=ConfirmationOfAction

Requires code in //chrome?
False

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

Estimated milestones

No milestones specified


Link to entry on the Chrome Platform Status

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

[Rick Byers]

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
>, 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 .
>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? 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

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

[Rick Byers]

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 this thread once
>> the feature is shipping to 100% of the stable population. Link to entry on
>> the Chrome Platform Status
>> https://chromestatus.com/feature/6311349754789888
>>  *
>>
>> --
>> You received this message because 

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

[Chris Harrelson]

LGTM

On Tue, Feb 1, 2022 at 11:14 AM 'Dylan Cutler' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emails
>
> dylancut...@google.com, kaustub...@google.com
>
> Spec
>
> https://github.com/WICG/CHIPS
>
> Summary
>
> Given that Chrome plans on obsoleting 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 (or First-Party Set, where
> the site uses that feature) to meet use cases that are not cross-site
> tracking related (e.g. SaaS embeds, headless CMS, sandbox domains, etc.).
> In order to do so, we introduce a mechanism to opt-in to having their
> third-party cookies partitioned by top-level site using a new cookie
> attribute, Partitioned.
>
> Link to “Intent to Prototype” blink-dev discussion
>
> https://groups.google.com/a/chromium.org/g/blink-dev/c/hvMJ33kqHRo
>
> Goals for experimentation
>
> CHIPS is a new, opt-in technology meant to preserve a set of use cases
> (e.g. third-party embeds) that may break once third-party cookies are
> phased out while preventing cross-site tracking. We need to validate
> whether the proposed syntax and semantics solve these use cases prior to
> third-party cookie obsoletion by giving developers a way to test it in a
> scaled manner and provide early feedback. We hope to validate ergonomics,
> deployability, and backward compatibility.
>
> Experimental timeline
>
> The experiment will start in M100 and run from March 31st, 2022 until June
> 30, 2022.
>
> Any risks when the experiment finishes?
>
> Since Chrome will not send and may delete partitioned cookies when it is
> started with the feature disabled, sites that set cookies with the
> Partitioned attribute during the experiment will no longer have those
> cookies available on clients' machines.
>
> Reason this experiment is being extended
>
> N/A
>
> Ongoing technical constraints
>
> None.
>
> Debuggability
>
> We have coordinated with the DevTools team to surface cookie partition
> keys to developers in DevTools. We have added a new cookie inclusion reason
> with a debug string when sites set Partitioned cookies incorrectly. We may
> also support surfacing partitioned cookies that are not included in
> requests because their partition key did not match the top-level site in
> DevTools.
>
> Will this feature be supported on all five Blink platforms supported by
> Origin Trials (Windows, Mac, Linux, Chrome OS, and Android)?
>
> Yes.
>
> Link to entry on the feature dashboard 
>
> https://www.chromestatus.com/feature/5179189105786880
>
> --
> 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/CAMCNMFRxpqxLUXAEfFqcACt-S7A8Y_6Q9is%3DCZJskiYuby0qJA%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%2Bw8cBibgfzXa_r%2B_yfGG-sdnBba%3DyLO3NNEbKQ_JWEEBbA%40mail.gmail.com.

RE: [EXTERNAL] Re: [blink-dev] Intent to implement: Fluent Scrollbars.

['Rahul Arakeri' via blink-dev]

Re Steve: For Linux, we don't have a strong preference on the default scrollbar 
mode (and we don’t yet know the scope of work needed since we never tested this 
feature on Linux).
For Windows however, we recommend having minimal mode as the default as 
outlined in the visual 
spec.

Re all: Please let us know if we all have consensus on the visual 
styling
 of the scrollbars. If you want to see the feature in action, please feel free 
to check out Microsoft Edge 
Canary. 
(Experimental flag edge://flags/#edge-overlay-scrollbars-win-style).

From: Steve Kobes 
Sent: Monday, January 31, 2022 11:38 AM
To: Rahul Arakeri 
Cc: Chris Harrelson ; Ian Kilpatrick 
; Mike Taylor ; 
blink-dev@chromium.org; Robert Flack ; wangxianzhu 
; p...@chromium.org; input-...@chromium.org; Yaroslav 
Shalivskyy ; Olga Gerchikov 
; Sahir Vellani ; Ben 
Mathwig 
Subject: Re: [EXTERNAL] Re: [blink-dev] Intent to implement: Fluent Scrollbars.

Keeping non-overlay by default on Linux would be one way to mitigate the risk 
that Ian mentions, namely that bugs specific to non-overlay mode may creep in 
and not be noticed quickly.  (This concern applies to some degree both to bugs 
in websites, and bugs in Chrome.)

On Mon, Jan 31, 2022 at 2:23 PM 'Rahul Arakeri' via input-dev 
mailto:input-...@chromium.org>> wrote:
Thanks Ian :)

Re Chris:
There will be some OS wiring missing (like switching between dark/light modes, 
"Always show scrollbars”, etc) but most of the code should just work. Note that 
we've never really tested this feature on Linux so we do not have an exhaustive 
list of stuff that will not work on Linux.

From: Chris Harrelson mailto:chris...@chromium.org>>
Sent: Friday, January 28, 2022 3:45 PM
To: Ian Kilpatrick mailto:ikilpatr...@chromium.org>>
Cc: Rahul Arakeri mailto:arak...@microsoft.com>>; Mike 
Taylor mailto:miketa...@chromium.org>>; 
blink-dev@chromium.org; Robert Flack 
mailto:fla...@chromium.org>>; wangxianzhu 
mailto:wangxian...@chromium.org>>; 
p...@chromium.org; 
input-...@chromium.org; Yaroslav Shalivskyy 
mailto:yshalivs...@microsoft.com>>; Olga Gerchikov 
mailto:gerch...@microsoft.com>>; Sahir Vellani 
mailto:sahir.vell...@microsoft.com>>; Ben Mathwig 
mailto:benjamin.math...@microsoft.com>>
Subject: Re: [EXTERNAL] Re: [blink-dev] Intent to implement: Fluent Scrollbars.

Re Linux: I'm hoping we can just use the same code on Linux so that we have 
overlay scrollbars everywhere. Rahul, would that work code-wise?

On Fri, Jan 28, 2022 at 3:40 PM Ian Kilpatrick 
mailto:ikilpatr...@chromium.org>> wrote:
Exciting!

Adding onto Rahul's answer here a little - overlay scrollbars (or scrollbars 
which take to zero space) already exist on other platforms (e.g. they are the 
default on OSX). It won't/shouldn't be a web compat concern as most websites 
handle this already.

An interesting side effect of this will likely be that we'll see more sites 
(who are built after this change goes in) assume that scrollbars are always 
zero width (as this is now the default on all platforms except linux?) and as a 
result more content going forward being broken for those users who opt-out.
(To be clear there isn't much we can do about this - but an interesting side 
effect).

Ian

On Fri, Jan 28, 2022 at 2:51 PM 'Rahul Arakeri' via blink-dev 
mailto:blink-dev@chromium.org>> wrote:
Hi Mike,

Sure, I’ve created a chromestatus entry here: 
https://chromestatus.com/feature/5693137379917824
And yes, this proposed change is expected to have an impact on the page’s 
layout. In it’s default state, the scrollbars will be in “minimal mode” (aka 
overlay scrollbars). These will not take up any layout space (whereas, today in 
Chromium, the default scrollbars take up 17px AFAIK).
The users will however still have an option to “Always show scrollbars” via an 
OS setting. These will take up layout space (similar to what Chromium 
scrollbars do today).

Thanks,
Rahul

From: Mike Taylor mailto:miketa...@chromium.org>>
Sent: Friday, January 28, 2022 12:20 PM
To: Rahul Arakeri mailto:arak...@microsoft.com>>
Cc: blink-dev@chromium.org; Robert Flack 
mailto:fla...@chromium.org>>; wangxianzhu 
mailto:wangxian...@chromium.org>>; 
p...@chromium.org; 

Re: [blink-dev] Intent to Ship: Digital Goods API v2.0

[Yoav Weiss]

LGTM2

On Tue, Feb 1, 2022 at 8:00 PM Chris Harrelson 
wrote:

>
> LGTM1
>
> On Tue, Feb 1, 2022 at 6:16 AM Rouslan Solomakhin 
> wrote:
>
>> Contact emails
>>
>> mgi...@chromium.org, rous...@chromium.org, glen...@chromium.org
>>
>> Explainer
>>
>> https://github.com/WICG/digital-goods/blob/main/explainer.md
>>
>> Spec
>>
>> https://wicg.github.io/digital-goods/ - Currently being reviewed by a
>> spec mentor, so some details may change (hopefully, only formatting).
>>
>> Summary
>>
>> An API for querying and managing digital products to facilitate in-app
>> purchases from web applications, in conjunction with the Payment Request
>> API (which is used to make the actual purchases). The API would be linked
>> to a digital distribution service connected to via the user agent. In
>> Chrome, this is specifically a web API wrapper around the Android Play
>> Billing API.
>>
>> Origin trial analysis
>>
>> DGAPI v2.0 is currently in an origin trial with M99 being the last
>> milestone. So far, 40 people have responded to the origin trial survey.
>> Notable data points:
>>
>> How easy was it to use the feature: 4.1 out of 6.
>>
>> (0 - extremely difficult … 6 - extremely easy.)
>>
>> How likely are you to keep using this feature: 5.5 out of 6.
>>
>> (0 - extremely unlikely … 6 - extremely likely.)
>>
>> The most common comments were about improving feature documentation and
>> debuggability. That is being tracked in
>> https://github.com/WICG/digital-goods/issues/33.
>>
>> Blink component
>>
>> Blink>Payments
>> 
>>
>> Search tags
>>
>> payments , billing
>> 
>>
>> TAG review
>>
>> https://github.com/w3ctag/design-reviews/issues/571 TAG recommends
>> making a Chrome-specific API. Other issues addressed.
>>
>> TAG review status
>>
>> Issues addressed
>>
>> Risks
>>
>> Interoperability and Compatibility
>>
>> Similar to Payment Request: this API is used to talk to specific store
>> backends, and so its usage is tailored to the specific store. The reason
>> it's a proposed web standard is so that the same code (which is specific to
>> one store) is portable across browsers.
>>
>> Gecko: No signal (
>> https://github.com/mozilla/standards-positions/issues/349) Requested
>> 2020-05-27.
>>
>> WebKit: No signal (
>> https://lists.webkit.org/pipermail/webkit-dev/2021-October/032001.html)
>> Requested 2021-10-08.
>>
>> Web developers: Positive (
>> https://discourse.wicg.io/t/proposal-web-payments-digital-product-management-api/4350
>> ).
>>
>> Other signals: rouslan@ presented DGAPI at 2021 TPAC
>>  (meeting notes
>> ) and at a recent PWA
>> Dev Sync
>> 
>> (meeting notes
>> ).
>> Other browser implementers and app stores do not appear to have immediate
>> plans to engage with DGAPI. There were some questions, no objections.
>>
>> Ergonomics
>>
>> Digital Goods API is used in tandem with the Payment Request API.
>>
>> In order for another browser to implement Digital Goods API for Play
>> Billing in the same way as Chrome, they would need to implement something
>> like the Trusted Web Activity
>>  (TWA)
>> feature and then invoke the TWA shell methods for communicating with Play
>> Billing. The android-browser-helper
>>  is a TWA
>> template code that we have been recommending app developers to use for the
>> Play Billing integration.
>>
>>
>> Debuggability
>>
>> We have had several requests from developers to make the API easier to
>> debug, but it is difficult due to the interaction with a backing service
>> based in an app/store context. We are looking for suggestions (
>> https://github.com/WICG/digital-goods/issues/33) on how we might improve
>> the debuggability of the API.
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?
>>
>> The tests are in //third_party/blink/web_tests/wpt_internal/digital-goods
>> .
>>
>
> I think these could move to WPT proper with .tentative file names?
>
>
>>
>> Flag name
>>
>> DigitalGoods
>>
>> Requires code in //chrome?
>>
>> False
>>
>> Tracking bug
>>
>> https://crbug.com/1248319
>>
>> Launch bug
>>
>> https://crbug.com/1250123 - There are no code changes from the current
>> origin trial to what we intend to ship to stable. Therefore, there is no
>> new tracking bug or launch bug being filed.
>>
>> Estimated milestones
>>
>> Origin trial end: 99
>>
>> Ship to stable begin: 100
>>
>> Link to entry on the 

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

['Dylan Cutler' via blink-dev]

Contact emails

dylancut...@google.com, kaustub...@google.com

Spec

https://github.com/WICG/CHIPS

Summary

Given that Chrome plans on obsoleting 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 (or First-Party Set, where the site
uses that feature) to meet use cases that are not cross-site tracking
related (e.g. SaaS embeds, headless CMS, sandbox domains, etc.). In order
to do so, we introduce a mechanism to opt-in to having their third-party
cookies partitioned by top-level site using a new cookie attribute,
Partitioned.

Link to “Intent to Prototype” blink-dev discussion

https://groups.google.com/a/chromium.org/g/blink-dev/c/hvMJ33kqHRo

Goals for experimentation

CHIPS is a new, opt-in technology meant to preserve a set of use cases
(e.g. third-party embeds) that may break once third-party cookies are
phased out while preventing cross-site tracking. We need to validate
whether the proposed syntax and semantics solve these use cases prior to
third-party cookie obsoletion by giving developers a way to test it in a
scaled manner and provide early feedback. We hope to validate ergonomics,
deployability, and backward compatibility.

Experimental timeline

The experiment will start in M100 and run from March 31st, 2022 until June
30, 2022.

Any risks when the experiment finishes?

Since Chrome will not send and may delete partitioned cookies when it is
started with the feature disabled, sites that set cookies with the
Partitioned attribute during the experiment will no longer have those
cookies available on clients' machines.

Reason this experiment is being extended

N/A

Ongoing technical constraints

None.

Debuggability

We have coordinated with the DevTools team to surface cookie partition keys
to developers in DevTools. We have added a new cookie inclusion reason with
a debug string when sites set Partitioned cookies incorrectly. We may also
support surfacing partitioned cookies that are not included in requests
because their partition key did not match the top-level site in DevTools.

Will this feature be supported on all five Blink platforms supported by
Origin Trials (Windows, Mac, Linux, Chrome OS, and Android)?

Yes.

Link to entry on the feature dashboard 

https://www.chromestatus.com/feature/5179189105786880

-- 
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/CAMCNMFRxpqxLUXAEfFqcACt-S7A8Y_6Q9is%3DCZJskiYuby0qJA%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Digital Goods API v2.0

[Chris Harrelson]

LGTM1

On Tue, Feb 1, 2022 at 6:16 AM Rouslan Solomakhin 
wrote:

> Contact emails
>
> mgi...@chromium.org, rous...@chromium.org, glen...@chromium.org
>
> Explainer
>
> https://github.com/WICG/digital-goods/blob/main/explainer.md
>
> Spec
>
> https://wicg.github.io/digital-goods/ - Currently being reviewed by a
> spec mentor, so some details may change (hopefully, only formatting).
>
> Summary
>
> An API for querying and managing digital products to facilitate in-app
> purchases from web applications, in conjunction with the Payment Request
> API (which is used to make the actual purchases). The API would be linked
> to a digital distribution service connected to via the user agent. In
> Chrome, this is specifically a web API wrapper around the Android Play
> Billing API.
>
> Origin trial analysis
>
> DGAPI v2.0 is currently in an origin trial with M99 being the last
> milestone. So far, 40 people have responded to the origin trial survey.
> Notable data points:
>
> How easy was it to use the feature: 4.1 out of 6.
>
> (0 - extremely difficult … 6 - extremely easy.)
>
> How likely are you to keep using this feature: 5.5 out of 6.
>
> (0 - extremely unlikely … 6 - extremely likely.)
>
> The most common comments were about improving feature documentation and
> debuggability. That is being tracked in
> https://github.com/WICG/digital-goods/issues/33.
>
> Blink component
>
> Blink>Payments
> 
>
> Search tags
>
> payments , billing
> 
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/571 TAG recommends making
> a Chrome-specific API. Other issues addressed.
>
> TAG review status
>
> Issues addressed
>
> Risks
>
> Interoperability and Compatibility
>
> Similar to Payment Request: this API is used to talk to specific store
> backends, and so its usage is tailored to the specific store. The reason
> it's a proposed web standard is so that the same code (which is specific to
> one store) is portable across browsers.
>
> Gecko: No signal (
> https://github.com/mozilla/standards-positions/issues/349) Requested
> 2020-05-27.
>
> WebKit: No signal (
> https://lists.webkit.org/pipermail/webkit-dev/2021-October/032001.html)
> Requested 2021-10-08.
>
> Web developers: Positive (
> https://discourse.wicg.io/t/proposal-web-payments-digital-product-management-api/4350
> ).
>
> Other signals: rouslan@ presented DGAPI at 2021 TPAC
>  (meeting notes
> ) and at a recent PWA
> Dev Sync
>  
> (meeting
> notes
> ).
> Other browser implementers and app stores do not appear to have immediate
> plans to engage with DGAPI. There were some questions, no objections.
>
> Ergonomics
>
> Digital Goods API is used in tandem with the Payment Request API.
>
> In order for another browser to implement Digital Goods API for Play
> Billing in the same way as Chrome, they would need to implement something
> like the Trusted Web Activity
>  (TWA)
> feature and then invoke the TWA shell methods for communicating with Play
> Billing. The android-browser-helper
>  is a TWA
> template code that we have been recommending app developers to use for the
> Play Billing integration.
>
>
> Debuggability
>
> We have had several requests from developers to make the API easier to
> debug, but it is difficult due to the interaction with a backing service
> based in an app/store context. We are looking for suggestions (
> https://github.com/WICG/digital-goods/issues/33) on how we might improve
> the debuggability of the API.
>
> Is this feature fully tested by web-platform-tests
> 
> ?
>
> The tests are in //third_party/blink/web_tests/wpt_internal/digital-goods.
>

I think these could move to WPT proper with .tentative file names?


>
> Flag name
>
> DigitalGoods
>
> Requires code in //chrome?
>
> False
>
> Tracking bug
>
> https://crbug.com/1248319
>
> Launch bug
>
> https://crbug.com/1250123 - There are no code changes from the current
> origin trial to what we intend to ship to stable. Therefore, there is no
> new tracking bug or launch bug being filed.
>
> Estimated milestones
>
> Origin trial end: 99
>
> Ship to stable begin: 100
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5339955595313152
>
> Links to previous Intent discussions
>
> Intent to prototype 1.0:
>
> https://groups.google.com/a/chromium.org/g/blink-dev/c/vkS3k30lWNs.
>
> 

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

[Domenic Denicola]

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 this thread once
> the feature is shipping to 100% of the stable population. Link to entry on
> the Chrome Platform Status
> https://chromestatus.com/feature/6311349754789888
>  *
>
> --
> 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 

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

[Chris Harrelson]

LGTM1

On Tue, Feb 1, 2022 at 8: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
> ). 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 this thread once
> the feature is shipping to 100% of the stable population. Link to entry on
> the Chrome Platform Status
> https://chromestatus.com/feature/6311349754789888
>  *
>
> --
> 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/05b6cf46-7bce-bd03-8a93-0db496a3a26e%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%2Bw-_UKAgfawwCKrok5t5vtyNEWFwXSZgO8wYfCXB7PzeWQ%40mail.gmail.com.

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

['Matt Menke' via blink-dev]

Contact emails

mme...@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 (which consists of top
frame site and frame site), to protect against cross-site tracking through
the use of side channels.  "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, and Expect-CT
information.

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 the socket was
warm. 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).

Partitioning storage may reduce Chromium’s ability to reuse network
resources.  We’ve enabled network state partitioning in a 5% experiment on
Stable.  It slows time to first contentful paint by about 0.5%, and slows
cross-site iframe time to first contentful paint by about 5%.  These are
very rough averages that vary across platforms and users.

Explainer:
https://github.com/MattMenke2/Explainer---Partition-Network-State/blob/main/README.md


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, innermost
frame site), unlike the implementation shipped by other browser vendors,
which just uses top-level site.

This will also potentially increase the number of connections made to
sites, both because connections can't be reused as often, and because
Chromium is less likely to know in advance if H2 or H3 can be used with a
site.  When that isn't known, up to six connections are created to a site,
instead of one or two.

NEL, Reporting, and Expect-CT: Report-To headers tell Chromium how and when
to inform a site of certain errors.  Partitioning this information means
that Chromium potentially won't know where to report errors, particularly
the first time it issues a request to a site in a particular context.  The
latest version of the Reporting API (Reporting V1, to replace Reporting V0)
is scoped to frames, anyways, so is already subject to a more restrictive
limitation.

None of these changes is expected to visibly break sites.


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

WebKit: Shipped/Shipping (
https://webkit.org/status/#?search=client-side%20storage%20partitioning)

Web developers: No signals

Other signals:

Ergonomics

The only risk here is decreased performance, particularly in cross-site
iframes.


Debuggability

DevTools won't display the network partition key, but will continue to
display the results of network requests accurately.


Is this feature fully tested by web-platform-tests

?

No, though it does have partial coverage. web-platform-tests can't test
some features like, e.g., DNS cache partitioning.

Flag name

SplitHostCacheByNetworkIsolationKey,
PartitionConnectionsByNetworkIsolationKey,
PartitionHttpServerPropertiesByNetworkIsolationKey,
PartitionSSLSessionsByNetworkIsolationKey,
PartitionExpectCTStateByNetworkIsolationKey,
PartitionNelAndReportingByNetworkIsolationKey

Requires code in //chrome?

False

Tracking bug

https://crbug.com/993801

Launch bug

https://crbug.com/1166303

Estimated milestones

Plan to roll out in M97/M98 over the course of February


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6713488334389248

Links to previous Intent discussionsIntent to prototype:
https://groups.google.com/a/chromium.org/g/blink-dev/c/6KKXv1PqPZ0/m/nm2z5I_MBAAJ
Intent to Extend Experiment:
https://groups.google.com/a/chromium.org/g/blink-dev/c/sLC_W6B8big/m/5sk787RQBAAJ

-- 
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/CAEK7mvrYvoXcc%2B28rFrHbb1tEJN6HPf1y%3DHdE%2BcGe3tuJwsAnA%40mail.gmail.com.

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

[Victor Costan]

Some background:

   - The *filesystem:* URL scheme was introduced to the *File API:
   Directories and System* specification
   , 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 . 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? 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. 

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

[Mike Taylor]

**


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



   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 this thread once the 
feature is shipping to 100% of the stable population.




   Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6311349754789888 



*

--
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/05b6cf46-7bce-bd03-8a93-0db496a3a26e%40chromium.org.

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

[Emanuel Krivoy]

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
>> , low-level
>> , generic
>> , foundation
>> 
>>
>> TAG review
>>
>> https://github.com/w3ctag/design-reviews/issues/566
>>
>> TAG review status
>>
>> Closed
>>
>> Risks
>>
>> Interoperability and Compatibility
>>
>> This new feature has some potential interoperability risks due to its
>> nature as a novel and low-level API. Currently, there are no web features
>> that expose such a generic interface and that focus on WebAssembly ports as
>> one of it's main consumers.
>>
>> We've also received feedback from other vendors that the functionality
>> added in Storage Foundation API seems duplicative of File System Access
>> API. We are exploring a merged design (details here:
>> https://docs.google.com/document/d/121OZpRk7bKSF7qU3kQLqAEUVSNxqREnE98malHYwWec)
>> while collecting feedback and validating design choices with this
>> independent API.
>>
>>
>> Gecko: Negative (
>> https://github.com/mozilla/standards-positions/issues/481) Supportive of
>> a low-level storage API, opposed to minting a new API instead of taking a
>> holistic approach to file access
>>
>> WebKit: Negative (
>> https://lists.webkit.org/pipermail/webkit-dev/2021-February/031687.html)
>> No opposition to offering efficient access to files, strongly opposed to
>> minting a new API instead of augmenting an existing one.
>>
>> Web developers: No signals
>>
>>
>> Goals for experimentation
>>
>> In general, we would like to validate the whole surface of our API
>> against developer expectations and more diverse use cases. In particular,
>> we are interested in confirming that we provide the required performance to
>> allow new uses, and to shed light on developer preference between a
>> synchronous and asynchronous surface.
>>
>> Reason 

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

[Mike Taylor]

And in case anyone wonders: why those ones in particular? It's 
everything that's allowed inside an sf-string 
, except 
escaped "\" and escaped DQUOTE (because we know those make WAFs very, 
very sad).


On 2/1/22 10:00 AM, Matt Reichhoff wrote:
Thanks for the response! Yes, we will be keeping an eye on metrics and 
bug reports.


In terms of the character set, it is defined here: 
https://wicg.github.io/ua-client-hints/#create-arbitrary-brands-section
It includes: 0x20 (SP), 0x28 (left parenthesis), 0x29 (right 
parenthesis), 0x2D (-), 0x2E (.), 0x2F (/), 0x3A (:), 0x3B (;), 0x3D 
(=), 0x3F (?), 0x5F (_). The prior implementation included only space 
(0x20) and semicolon (0x3B).




On Tue, Feb 1, 2022 at 4:45 AM Mike West  wrote:

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

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

[Matt Reichhoff]

Thanks for the response! Yes, we will be keeping an eye on metrics and bug
reports.

In terms of the character set, it is defined here:
https://wicg.github.io/ua-client-hints/#create-arbitrary-brands-section
It includes: 0x20 (SP), 0x28 (left parenthesis), 0x29 (right parenthesis),
0x2D (-), 0x2E (.), 0x2F (/), 0x3A (:), 0x3B (;), 0x3D (=), 0x3F (?), 0x5F
(_). The prior implementation included only space (0x20) and semicolon
(0x3B).



On Tue, Feb 1, 2022 at 4:45 AM Mike West  wrote:

> 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 

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