from:"Mike Taylor"

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

2022-06-01 Thread Mike Taylor


On 6/1/22 3:52 PM, Yoav Weiss wrote:

LGTM3

On Wed, Jun 1, 2022 at 8:58 PM Mike Taylor  wrote:

On 6/1/22 1:34 PM, Chris Harrelson wrote:


On Tue, May 31, 2022 at 8:26 PM Ayu Ishii  wrote:

Hi Mike!

With the current usage measurements we see, we hadn't
considered any enterprise policy for opt-out.
But certainly can follow the process to do so if you feel
that there may be risk of undercounting.
Deprecation of WebSQL in third-party contexts added a policy
that lasted 3 milestones after deprecation before full
removal as an example.
Although the usages were quite different from that
deprecation, we can follow the same process if this sounds
reasonable.


I think this plan sounds good. LGTM1 once you have an enterprise
opt-out in place that will remain for 3 milestones. Also please
make sure to communicate this change in the enterprise notes and
other communication channels.


A couple of notes I took last Friday and forgot to post:

I dumped the list of sites from HTTPArchive (query below) and
after de-duping them, ended up with 835 sites.

I then ran a script which naively looks at response codes, and got
the following results:

2XX count: 685/835
3XX to HTTP endpoint count: 74/835
4XX count: 3/835
5XX count: 2/835

So, from this dataset, roughly 9% of those redirect to an HTTP
endpoint.


This should say HTTPS, not HTTP. I am bad at typing.


That said, I think reducing risk of breakage for enterprise
environments is a useful and friendly thing to do. LGTM2 w/ that done.

SELECT
  rank,
  url,
FROM
  `httparchive.blink_features.features`
WHERE feature = 'OpenWebDatabaseInsecureContext'
ORDER BY rank ASC



- Ayu

On Monday, May 30, 2022 at 10:57:01 PM UTC-7 Mike West wrote:

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 <mailto:a...@chromium.org>,
jsb...@chromium.org <mailto:jsb...@chromium.org>,
ajayrahate...@google.com
<mailto: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

<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EStorage%3EWebSQL>

*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

<https://github.com/WebKit/WebKit/commit/761bce943c0696a6bb93116eb0576ed07dbfdc65>.
The W3C encouraged those needing web databases to
adopt Web Storage <https://www.w3.org/TR/webstorage/>
or Indexed Database <https://www.w3.org/TR/IndexedDB/>.

WebSQL has been deprecated and removed

<https://groups.google.com/a/chromium.org/g/blink-dev/c/TM6YDx1Hh08>
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

<https://chromestatus.com/metrics/feature/timeline/popularity/4073>
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
<https://modernizr.com/news/modernizr-15>, 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

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

2022-06-01 Thread Mike Taylor


On 6/1/22 1:34 PM, Chris Harrelson wrote:


On Tue, May 31, 2022 at 8:26 PM Ayu Ishii  wrote:

Hi Mike!

With the current usage measurements we see, we hadn't considered
any enterprise policy for opt-out.
But certainly can follow the process to do so if you feel that
there may be risk of undercounting.
Deprecation of WebSQL in third-party contexts added a policy that
lasted 3 milestones after deprecation before full removal as an
example.
Although the usages were quite different from that deprecation, we
can follow the same process if this sounds reasonable.


I think this plan sounds good. LGTM1 once you have an enterprise 
opt-out in place that will remain for 3 milestones. Also please make 
sure to communicate this change in the enterprise notes and other 
communication channels.


A couple of notes I took last Friday and forgot to post:

I dumped the list of sites from HTTPArchive (query below) and after 
de-duping them, ended up with 835 sites.


I then ran a script which naively looks at response codes, and got the 
following results:


2XX count: 685/835
3XX to HTTP endpoint count: 74/835
4XX count: 3/835
5XX count: 2/835

So, from this dataset, roughly 9% of those redirect to an HTTP endpoint.

That said, I think reducing risk of breakage for enterprise environments 
is a useful and friendly thing to do. LGTM2 w/ that done.


SELECT
  rank,
  url,
FROM
  `httparchive.blink_features.features`
WHERE feature = 'OpenWebDatabaseInsecureContext'
ORDER BY rank ASC



- Ayu

On Monday, May 30, 2022 at 10:57:01 PM UTC-7 Mike West wrote:

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

Re: [blink-dev] Re: Intent to Experiment: Federated Credentials Management (was WebID)

2022-05-31 Thread Mike Taylor


Hi Kaan,

No need for another I2E - you have the LGTM to experiment without any 
conditions on platforms (and I see you had Desktop listed as 102 to 105. 
The fact that it slipped a milestone is fine).


On 5/31/22 9:42 AM, 'Kaan Icer' via blink-dev wrote:

Hello,
FedCM has been in the origin trial since M101 only on the Android 
platform. As part of the ongoing origin trial, we expand FedCM to 
desktop as well with M103.
Could you please help us understand if we need a new I2E for desktop 
support?

Thank you,
Kaan
On Wednesday, March 23, 2022 at 1:20:38 AM UTC-4 yoav...@chromium.org 
wrote:


LGTM to experiment till M105 (inclusive)

On Monday, March 21, 2022 at 5:06:17 PM UTC+1 Sam Goto wrote:


Contact emails


go...@google.com


Explainer


https://github.com/fedidcg/FedCM/blob/main/explainer.md


Specification


https://fedidcg.github.io/FedCM/



Summary


A Web Platform API that allows users to login to websites with
their federated accounts in a manner compatible with
improvements to browser privacy.


In this origin trial, we are interested in experimenting with
an account chooser for federated accounts, which we expect to
be a foundational infrastructure for the Web going forward.


Blink component


Blink > Identity > FedCM




TAG review


Spec review:
https://github.com/w3ctag/design-reviews/issues/718


Early review:
https://github.com/w3ctag/design-reviews/issues/622



TAG review status


Pending


Risks


Interoperability and Compatibility


Zero compatibility risk (new API)


Interoperability risk not yet known, currently working on
getting formal signals.


Gecko: No Signals. standards position filed



WebKit: No Signals. standards position filed



Web developers: No signals. We have been proactively working
with Identity Providers and expect much of the origin trial
experimentation to be a determining factor on their position.


Other signals: No signals. This API is being developed within
the FedID CG with attendance of identity providers, browser
vendors and standards experts. We are working on a community
report https://github.com/fedidcg .


Activation


  We made a deliberate and concerted effort to make as many
backwards

compatible changes as we possibly could to facilitate the
adoption of FedCM.

When it wasn’t possible, we favored changes impacting Browsers
and Identity

Providers and reduced changes impacting websites and users.


  So far, we think we maintained backwards compatibility with
website’s server-

side Infrastructure, which we expect to be a meaningful
activation lever.


We believe we found a structure that would make it easy for
websites to adopt, but that's one of the risks that we are
trying to mitigate as soon as we possibly can as part of the
origin trial.


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 API does not deprecate or change behavior of existing APIs.



Goals for experimentation


To learn about:


 *

requirements: what aspects of federated identity are going
to be affected by phasing out third party cookies?

 *

demand: who is going to be affected? and how important is
it for them?

 *

deployment viability: is it a practical solution?

 *

user acceptance: does our implementation perform well with
users?


Ongoing technical constraints


The following are current technical constraints that we expect
to resolve as we go along (i.e. we are actively working on
these known constraints):


 *

Android only implementation (here
is
the desktop implementation tracking bug)

 *

Only ID tokens provided, no access or refresh token

Re: [blink-dev] Intent to Ship: Default SVG cursor size set from OS settings

2022-05-31 Thread Mike Taylor

Hi Sahir,

On 5/26/22 4:44 PM, 'Sahir Vellani' via blink-dev wrote:

Contact emails
sahir.vell...@microsoft.com, gerch...@microsoft.com,
bemat...@microsoft.com

Specification
https://drafts.csswg.org/css-ui-3/#cursor

Summary

Platform cursor size used as default for custom SVG cursors if no
specified size. SVG cursors can scale based on the platform
accessibility/cursor settings. This can be overridden if the cursor
has any specified dimensions. This feature is initially available on
Windows only.

It's not 100% clear to me what you're proposing shipping here (this may
be due to my lack of expertise in this area), and the spec link doesn't
help much I'm afraid. A short explainer with use cases and mockups or
screenshots would be helpful, if you could post one. Or is this just a
bugfix, rather than a new feature?

Blink component
Blink>SVG

TAG review

TAG review status
Not applicable

Risks

Interoperability and CompatibilityWeb developers will need to
reexamine the way they handle SVG cursors with no specified sizes. A
custom cursor may be rendered where it was previously just the default
cursor image.
Could you explain why a different (presumably fallback) cursor would be
rendered?

/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

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

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

Flag name

Requires code in //chrome?
False

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

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

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/b87b0ab4-836d-45f0-af04-2ce26b3e718an%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/9896aeab-b760-824e-7c0a-d3c8cd1e945a%40chromium.org.

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

2022-05-26 Thread Mike Taylor


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 <https://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 that 
demonstrates the issue has shipped (i.e., an issue that links to 
patches that have been merged, or a comment that a previously disabled 
feature is not enabled by default)."



(this should read "now enabled by default", rather than "not"). 🙈

--
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/16c5b7c2-cf75-5847-677f-2793c4f28fb6%40chromium.org.

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

2022-05-26 Thread Mike Taylor

LGTM to extend to M104 inclusive.

(That brings out the trial to just 5 milestones in total, which is under
the 6 milestone limit before renewal requirements kick in:
https://www.chromium.org/blink/launching-features/#step-3-optional-origin-trial)

On 5/25/22 6:52 PM, 'Dylan Cutler' via blink-dev wrote:

Contact emails

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

Spec (Copied from I2E)

https://github.com/WICG/CHIPS

Summary (Copied from I2E)

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 (Copied from I2E)

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

Goals for experimentation (Copied from I2E)

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 (Modified)

The experiment started in M100 and started on March 29th, 2022 and is
currently scheduled to run until June 14, 2022.

We would like to extend the experiment through M104; or in other
words, until the release of M105, which is August 30th, 2022.

Any risks when the experiment finishes? (Copied from I2E)

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.

Reasons this experiment is being extended (New)

We are talking to multiple interested testing partners, with
different use cases, who have requested additional time to prepare
for the origin trial, and test the feature. Extending the trial
would allow us to gather more feedback across more use cases.

We discovered a bug
that
prevents Origin Trial opt-in from third-party contexts, which is
the typical configuration to use the feature. This bug has been
fixed in M103.

We have received feedback

that
the current origin trial opt-in mechanism is difficult to deploy
for large organizations. We have proposed an update to the design

of
this mechanism, which we aim to release in M103.

Ongoing technical constraints (Copied from I2E)

None.

Debuggability (Copied from I2E)

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)?
(Copied from I2E)

Yes.

Link to entry on the feature dashboard
(Copied from I2E)

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/CAMCNMFSx%3DLnTJGOGt0S5GnefQGGEhtea5tUxFkix%3DKYFDxZbyQ%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 f

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

2022-05-26 Thread Mike Taylor

On 5/26/22 2:42 AM, Jihwan Kim wrote:

Thanks for feedbacks!

1. Explainer : I added an csswg-drafts issue
link(https://github.com/w3c/csswg-drafts/issues/6965) into
explainer. It has been re-opened due to the fullscreen spec.

2. fullscreen spec : As mentioned, issue has been re-opened due to
this. Further discussion is needed.

3. TAG review : I think it would not needed since it's an existing
spec discussed. If not, please let me know :)

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 that
demonstrates the issue has shipped (i.e., an issue that links to patches
that have been merged, or a comment that a previously disabled feature
is not enabled by default)."

In this case, the better choice is probably "No signal", and we should
ask for an official position via the Mozilla standards position repo
(the fact that Emilio tagged it as "good-first-bug" is encouraging!).

5. WPT link :There were some differences between what was written in
chromestatus and I2S. I added WPT test links but on I2S that is not
shown.

As Emillo mentioned, WPT links are as follows.
http://wpt.live//css/selectors/modal-pseudo-class.html
https://wpt.fyi/results/css/selectors/modal-pseudo-class.html

Thanks again!

2022년 5월 26일 목요일 오전 1시 0분 45초 UTC+9에 sligh...@chromium.org님이
작성:

I'd like to see an explainer and completed TAG review before
moving forward. Could this perhaps be going to OT instead?

On Wednesday, May 25, 2022 at 3:44:22 AM UTC-7 Emilio Cobos
Alvarez wrote:

On 5/25/22 09:38, Manuel Rego Casasnovas wrote:
> There are these tests for ":modal":
> * http://http://wpt.live//css/selectors/modal-pseudo-class.html
> *
>

http://http://wpt.live//css/selectors/invalidation/modal-pseudo-class-in-has.html

>
> They are for , but it looks there are no tests for the
> fullscreen case.

It isn't clear from the resolution[1] that this should apply to
fullscreen, and it doesn't seem like WebKit's implementation
does that
(it seems a bit weird that it would since fullscreen at least
in Gecko
isn't modal / doesn't make the rest of the page inert...).

I commented on the spec issue about this.

-- Emilio

[1]:
https://github.com/w3c/csswg-drafts/issues/6965#issuecomment-1118033655

--
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/d44d8453-865b-4d6b-8e59-be09570aa8ean%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/1f45f214-0e5b-7b7f-306e-fe11098998e5%40chromium.org.

Re: [blink-dev] Intent to Prototype and Ship: Multi-Screen Window Placement: Fullscreen Companion Window

2022-05-23 Thread Mike Taylor

Hi Mike, can you help me understand the relationship of this work to 
Fullscreen capability delegation? Is the difference just 1 vs many screens?


https://github.com/WICG/capability-delegation#allowing-fullscreen-from-opener-window-click

On 5/9/22 8:35 PM, Mike Wasserman wrote:



Contact emails

m...@chromium.org 


Explainer

https://github.com/w3c/window-placement/blob/main/EXPLAINER_initiating_multi_screen_experiences.md 




Specification

https://github.com/w3c/window-placement/blob/main/EXPLAINER_initiating_multi_screen_experiences.md#spec-changes 




Design docs

https://docs.google.com/document/d/1RRlGQharWVnmxKTomfKhNiaeE31L7iXHeXVfifOvwJA 




Summary

Fullscreen Companion Window allows sites to place fullscreen content 
and a popup window on separate screens from a single user activation.



This is a small requested enhancement of the Multi-Screen Window 
Placement feature:https://chromestatus.com/feature/5252960583942144 




Blink component

Blink>Screen>MultiScreen 




TAG review

https://github.com/w3ctag/design-reviews/issues/602#issuecomment-1121694034 




TAG review status

Pending


Risks


Interoperability and Compatibility

The main risk is that this feature fails to become an interoperable 
part of the web platform if other browsers do not implement it. 
Scripted attempts to open a popup window after requesting fullscreen 
would likely be blocked by user agents that do not implement this 
feature, even if they implement the basic Multi-Screen Window 
Placement API.



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



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



Web developers: Positive 
(https://bugs.chromium.org/p/chromium/issues/detail?id=1233970 
) This 
functionality is requested by a prominent API partner



Ergonomics

There is currently no way to detect feature support before attempted 
usage; 
seehttps://docs.google.com/document/d/1RRlGQharWVnmxKTomfKhNiaeE31L7iXHeXVfifOvwJA/edit?pli=1#heading=h.vu2lz7aeddz6 




Activation

Developers can make immediate use of this API enhancement.


Security

This feature was designed from the ground-up to adhere to the 
strictest usable security measures possible, as an incremental 
enhancement of existing web platform APIs. See the design document for 
details.



WebView application risks

None


Debuggability

Existing mechanisms support debugging fullscreen and popup window open 
requests.



Is this feature fully tested by web-platform-tests

?

No. An existing automated/manual WPT covers the ability to open 
cross-screen popups >. We aim to extend test coverage 
for this specific scenario soon >.



DevTrial instructions

https://github.com/w3c/window-placement/blob/main/HOWTO.md 




Flag name

--enable-blink-features=WindowPlacement


Requires code in //chrome?

True - 
https://docs.google.com/spreadsheets/d/1QV4SW4JBG3IyLzaonohUhim7nzncwK4ioop2cgUYevw/edit#gid=0&range=34:34 




Tracking bug

https://crbug.com/1233970 


Launch bug

https://crbug.com/1315615 


Sample links

https://michaelwasserman.github.io/window-placement-demo/ 



(See DevTrial instructions)


Estimated milestones

DevTrial on desktop: 102

Shipping on desktop: 103


Anticipated spec changes

No changes anticipated that would introduce web compat/interop risk


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/517316243724697

Re: [blink-dev] Re: Intent to Ship: Element.isVisible method

2022-05-19 Thread Mike Taylor

Given the CSSWG resolution in
https://github.com/w3c/csswg-drafts/issues/7274#issuecomment-1130214343,
LGTM1 to ship assuming we're not shipping `checkInert` with the rest.

Thanks for addressing Mozilla's feedback.

On 5/5/22 4:26 PM, Joey Arhar wrote:

> Can you ask for signals?

https://github.com/mozilla/standards-positions/issues/634
https://lists.webkit.org/pipermail/webkit-dev/2022-May/032218.html

On Wed, May 4, 2022 at 3:02 AM Yoav Weiss wrote:

On Wednesday, May 4, 2022 at 1:08:11 AM UTC+2 Joey Arhar wrote:

Contact emails

jar...@chromium.org

Explainer

https://github.com/WICG/display-locking/blob/main/explainers/isvisible.md

Specification

https://drafts.csswg.org/cssom-view/#dom-element-isvisible

Summary

Element.isVisible() returns true if the element is visible,
and false if it is not. It checks a variety of factors that
would make an element invisible, including display:none,
visibility, content-visibility, and opacity.

Blink component

Blink>DOM

TAG review

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

TAG review status

Pending

Risks

Interoperability and Compatibility

This feature is not particularly contentious or complicated,
but is mostly useful in the presence of content-visibility.

Gecko: No signal

WebKit: No signal

Can you ask for signals?

Web developers: No signals

Would be good to gather signals here as well.

Other signals:

Ergonomics

This feature could be used in tandem with content-visibility
or details elements. Usage of this API will not make it hard
for Chrome to maintain good performance.

Activation

This feature is easy to feature detect and polyfill.

Security

I have no security risks/considerations for this feature.

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 does not deprecate or change any existing APIs and does
not have any risk for WebView.

Debuggability

This feature does not need any new debugging features.

Is this feature fully tested by web-platform-tests

Yes

Flag name

--enable-blink-features=isVisible

Requires code in //chrome?

False

Tracking bug

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

Estimated milestones

103

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

https://github.com/w3c/csswg-drafts/issues/7232

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5163102852087808

Links to previous Intent discussions

Intent to prototype:

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwK01yGZ0LVb6M_8WdeC5OM0qfUv5T1TUO%3D1if1G%2BKogRw%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/CAK6btwKkoRBHUja0MePoXLRq0vN_WVeF%3Dr2se34ThXo5Tr%2BdtQ%40mail.gmail.com
.

Re: [blink-dev] Intent to Ship: WebGL canvas color management

2022-05-19 Thread Mike Taylor

LGTM3

On 5/19/22 10:08 AM, Yoav Weiss wrote:

LGTM2

On Thursday, May 19, 2022 at 1:41:32 AM UTC+2 Chris Harrelson wrote:

I've updated bit.ly/blink-signals to
include an exception for Khronos (see the document for details).

Thanks for the developer signal.

LGTM1 for this intent!

On Wed, May 18, 2022 at 4:19 PM Chris Harrelson
wrote:

On Wed, May 18, 2022 at 4:18 PM Chris Harrelson
wrote:

On Wed, May 18, 2022 at 4:04 PM Ken Russell
wrote:

On Wed, May 18, 2022 at 3:40 PM Chris Harrelson
wrote:

Hi, comments below.

On Wed, May 18, 2022 at 11:48 AM Ken Russell
wrote:

On Tue, May 17, 2022 at 3:40 PM
'Christopher Cameron' via blink-dev
wrote:

TAG review status

N/A. Canvas 2D color managment API
already TAG reviewed at

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

Should this intent reuse issue 646 then? Are the
considerations and API almost exactly the same as
in 2D canvas? Another option is to comment on that
issue describing the WebGL variant of the same
feature, and calling out the notable differences
the TAG needs to be aware of to provide useful
feedback.

This specification change was
developed in Khronos and followed
the processes there.

Risks

Interoperability and
Compatibility

Gecko: Positive Developed in close
collaboration with Mozilla, spec
changes reviewed by Mozilla.

WebKit: Positive Discussed in
ColorWeb CG with WebKit
representatives

Please file for official signals. Participating in
discussions is not the same as officially supporting.

I'd like to respectfully point out that this API was
agreed upon by all major browser implementers in
Khronos' WebGL working group, whose processes have
been well established over the last decade. The WebGL
working group owns the responsibility for evolving
this portion of this web API, and the requirement in
Blink's processes to fetch signals is causing
duplicate work to be done in this context.

I would like to respectfully request that Blink's
processes be changed to not require implementation
signals for WebGL specification changes. Any such
changes are already only made with full agreement
among Gecko, WebKit and Blink engineers.

Got it, ok. We already have an exception in two cases,
let's work together on adding it to bit.ly/blink-intents
.

...make that bit.ly/blink-signals .

Web developers: Strongly positive

Could you give examples of developer support?

Not to speak for Chris Cameron, but this support was
requested, with urgency, by Adobe.

-Ken

--
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/CAMYvS2dk0%2B1MM8pG6kfLEVQSx_yNEoh6-cF80mmOuv_JenxQeA%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, se

Re: [blink-dev] Re: Intent to Prototype and Ship: Support visual-box on overflow-clip-margin

2022-05-18 Thread Mike Taylor

LGTM2

On 5/18/22 9:16 AM, Daniel Bratell wrote:

LGTM1

It is a bit confusing with the TAG review mostly being negative, but I
think they didn't object to this particular part. Furthermore, it
seems useful, it's been reviewed and approved by the CSS working group
and though Mozilla's position is not official yet, they seem to agree
that this is a useful addition.

/Daniel

On 2022-05-04 17:22, Khushal Sagar wrote:

Thanks for the review Yoav. Responses inline.

On Wed, May 4, 2022 at 6:12 AM Yoav Weiss wrote:

On Monday, May 2, 2022 at 11:52:56 PM UTC+2 Khushal Sagar wrote:

Contact emails

khushalsa...@chromium.org

Explainer

https://github.com/WICG/shared-element-transitions/blob/main/overflow_on_replaced_elements.md

Specification

https://drafts.csswg.org/css-overflow/#overflow-clip-margin

Summary

overflow-clip-margin specifies how far an element's
content is allowed to paint before being clipped.
This feature allows using visual-box

values to configure the reference box that defines
the overflow clip edge the content is clipped to.

Blink component

Blink>CSS

TAG review

The TAG review for the overflow-clip-margin property
is here:
https://github.com/w3ctag/design-reviews/issues/579

TAG review status

Issues addressed

The TAG seem unhappy with this

,
and it doesn't seem like their concerns were addressed.

The remaining concerns raised by TAG on that thread were about
overflow:clip (which already shipped in Chrome and Firefox) so I
wasn't sure if those are relevant for this intent.

Risks

Interoperability and Compatibility

The feature has been reviewed and accepted by the
cross-browser CSSWG.

Gecko: In development
(https://bugzilla.mozilla.org/show_bug.cgi?id=1661582)

WebKit: No signal

Can we ask for a signal?

Sure, I've sent an RFP for this here
.

Web developers: No signals

Similarly, can you try to get signals here?
https://goo.gle/developer-signals

The bug which motivated this addition is here
(referenced
in the CSSWG issue
). This bug is
starred by 12 users, could we use that as a positive signal?

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 feature supports a new keyword for an existing
CSS property. There is no high risk for WebView.

Debuggability

No additional changes needed. overflow-clip-margin
already surfaces in the devtools style panel.

Is this feature fully tested by web-platform-tests

Yes

Requires code in //chrome?

False

Tracking bug

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

Estimated milestones

M103

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

N/A

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5082351989161984

This intent message was generated by Chrome Platform
Status .

Re: [blink-dev] Intent to Prototype and Ship: User-Agent Client Hints API Updates

2022-05-17 Thread Mike Taylor

PSA: In https://chromium-review.googlesource.com/c/chromium/src/+/3646649 I 
landed a fix to navigator.userAgentData.toJSON() which has been missing the 
"platform" hint since it the toJSON method was added. 

This is a purely additive bugfix, but please let me know if anyone runs 
into any breakage or has any concerns as a result.

thx,
Mike

On Monday, June 21, 2021 at 10:17:50 AM UTC-4 Mathias Bynens wrote:

> Brilliant, thanks!
>
> On Mon, Jun 21, 2021 at 4:16 PM Mike Taylor  
> wrote:
>
>> Hey Mathias,
>>
>> On 6/21/21 6:46 AM, Mathias Bynens wrote:
>> > The Intent* email template includes a “Debuggability” section, which 
>> > is missing in this case. How would web developers debug this new 
>> > functionality through DevTools? Do we need anything beyond existing 
>> > DevTools functionality in the Network tab? See 
>> > https://goo.gle/devtools-checklist 
>> > <https://goo.gle/devtools-checklist> for context.
>>
>> The only DevTools task that needs to be taken care for these changes of 
>> is to ensure that the the new bitness hint is exposed in editable fields 
>> like the others, but that should be fairly mechanical. It's on our radar 
>> to make sure it gets taken care of. The rest should come "for free".
>>
>> Thanks for the question!
>>
>> 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/69110142-a365-495b-ab3a-086913e5e0e3n%40chromium.org.

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

2022-05-12 Thread Mike Taylor

LGTM3

On 5/12/22 12:23 PM, Daniel Bratell wrote:

LGTM2

/Daniel

On 2022-05-12 10:40, Yoav Weiss wrote:

LGTM1

Thanks for the extra details. These results look amazing, so in my
mind they significantly outweigh the risk of going first here.

On Thursday, May 12, 2022 at 4:12:19 AM UTC+2 Hiroki Nakagawa wrote:

Let me share more details of the feedback.

We worked directly with 11 external partners; 8 of them valued
the opportunity offered by Prerendering.

* Origin Trial results: One of the external partners, Ameba
News (https://news.ameba.jp/) has tested out same-origin
prerendering via the Origin Trial during April 11 - 17 (1
week testing / around selected navigations / 2-3% of the
traffic). While the site was already meeting CWV and good
LCP, by adopting prerendering, the median LCP improved 2.7x
(827ms to 302ms) and more importantly the P95 improved by 1.6
seconds [2843ms to 1195ms] (i.e. Prerendered pages have more
consistency in the performance).
* Key challenges:
o All participants identified "knowing what is safe to
prerender / adapting a page to be safe" as a key
challenge. We are exploring follow-ups to lower the bar.
o DevTools support. We are following up with the devtools team.
o 3P RUM tools to incorporate `activationStart` to
correctly measure FCP / LCP. We will be guiding the RUMs
for required changes.
o CrUX to incorporate the prerendering impact. We are
following up with the CrUX team.

In addition, we worked with one internal partner who got great
results (i.e. the 45% number shared earlier).

Finally, we received the following feedback from 6 OT participants:

* Difficulty: moderately easy (3), neither easy nor difficult
(2), Slightly difficult (1)
* Keep using: extremely likely (2), moderately likely (3),
can't say which way (1)
* Alternatives: none (2), fallback to prefetch (2)

Thanks,
Hiroki

On Tue, May 10, 2022 at 10:42 PM Hiroki Nakagawa
wrote:

Hi Yoav, thanks for your comments!

On Tue, May 10, 2022 at 9:48 PM Yoav Weiss
wrote:

On Fri, Apr 22, 2022 at 7:27 PM 'Angel Raposo' via
blink-dev wrote:

Contact emails

noam.j.rosenthal@gmail.comdome...@chromium.org,
jbro...@chromium.org, nhir...@chromium.org,
navigation-...@chromium.org

Explainer

This feature:

https://github.com/WICG/nav-speculation/blob/main/same-origin-explainer.md

Larger project:
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 is “pre”-rendering, it’s about
pre-loading and rendering a Web page before the user
actually navigates to it. The main goal of
prerendering is to make the next page navigation
faster, or ideally nearly instant.

Sites can tell the user agents about which pages the
user may likely visit, by asking to trigger a
‘prerendering’ for a particular URL (e.g. user is at
page A and will likely navigate to page B next). Once
the prerender is triggered, the browser pre-fetches
the main resource, instantiates a hidden page, and
processes the main resource to fetch and process more
subresources.

We would like to ship same-origin speculation rules
prerendering. With this feature, Chrome will start
prerendering high-confidence URL suggestions provided
by the page using speculation rules. During the
prerendering process, a page will process and
construct the full DOM tree, including the execution
of scripts (this differs from the prefetching
resources using No-state Prefetch

)

This prerendering affects how the prerendered pages
are

Re: [blink-dev] Intent to Ship: Speculation Rules (Prefetch)

2022-05-12 Thread Mike Taylor


LGTM3

On 5/12/22 12:29 PM, Yoav Weiss wrote:

LGTM2


On Thu, May 12, 2022 at 6:26 PM Daniel Bratell  
wrote:


LGTM1

/Daniel


On 2022-05-11 09:44, Yoav Weiss wrote:



On Tue, May 10, 2022 at 8:40 PM Jeremy Roman
 wrote:

On Tue, May 10, 2022 at 8:41 AM Yoav Weiss
 wrote:



On Thu, Apr 14, 2022 at 12:36 AM Jeremy Roman
 wrote:


Contact emails

jbro...@chromium.org ,
kenjibah...@chromium.org



Explainer

https://github.com/WICG/nav-speculation/blob/main/triggers.md



Specification

https://wicg.github.io/nav-speculation/speculation-rules.html


https://wicg.github.io/nav-speculation/prefetch.html



Summary

Flexible syntax for defining what outgoing links are
eligible to be prepared speculatively before
navigation. Enables access to additional
enhancements, such as use of a private prefetch
proxy, where applicable.


So IIUC, this intent is for shipping cross-origin
prefetch? Where have y'all landed on the question of
cache partitioning? Which partition is storing this
prefetched resource?


It is isolated from any existing cache partition, and if the
user does not then navigate to the prefetched resource it is
not stored further.


OK, thanks!


This is limited to the "prefetch" action, and does
not include "prerender". The Chrome setting (extended
preloading) which allows any site to request use of
the private prefetch proxy and was previously
mentioned on intents for this feature, is currently
disabled for policy reasons but can be exposed via
Finch as part of a launch, if approved.


Blink component

Internals>Preload




TAG review

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

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



https://github.com/WICG/nav-speculation/issues/160 which
seems like something we'd want to resolve before shipping.
Are y'all considering this new syntax?
Would it make sense to run this by your OT participants
and/or partners? Web developers in general?


The reason I don't think so is that this intent includes only
more basic rules which supply a list of URLs, and extending
the syntax to allow developers to select URLs from the links
in the page is a future enhancement, albeit one I'm
personally excited about. I don't expect that choices about
how to express such selectors to cause compatibility issues
with plain list-of-URLs rules.


Oh, OK. Good to know!



TAG review status

First is complete, second is pending.


Risks



Interoperability and Compatibility


Which of the 24 issues
 open on
the repo is relevant for this intent? Can you highlight
those that may impact future compat and interop?


It's intended that such issues be labelled with
speculation-rules or prefetch (indicating they affect one of
the two pieces this would ship) and affects-compat. At the
moment, the only such issue is this one
, which I
believe is resolved as to prefetch. Looking again, any
followup discussion (e.g. regarding subresources in
prerenders) fit better in another issue, so I've closed that one.

This issue
 is not
so labelled, though it's marginal and arguably could be.
There is some ongoing discussion (which might become a
whatwg/html issue shortly) connected to it about when user
agents should observe modification and removal. While I would
like to resolve this shortly, I expect the practical change
to be relatively small and if anything

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

2022-05-10 Thread Mike Taylor


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&label=experimental&aligned 




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

Re: [blink-dev] Re: Intent to Deprecate: RTCPeerConnection's googIPv6 constraint

2022-05-10 Thread Mike Taylor

LGTM2 - this seems pretty safe and good for interop. Thanks for working
on it.

On 5/10/22 1:06 PM, Daniel Bratell wrote:

LGTM1

I agree that usage is low enough and use-cases not compelling enough
to keep it. I've gone through a couple of hundred uses of googIPv6 on
GitHub and there are a couple of "false" that you may want to take a
look at, but nothing that causes concerns for me (you may know
better). The timeline is also conservative.

Make sure you you add the removal date to the deprecation message if
it's not already there.

/Daniel

On 2022-05-10 15:22, Henrik Boström wrote:
I'm already displaying a deprecation warning when "googIPv6: false"
is used. The warning was added in M102 (currently Beta).
In terms of deprecation timeline, I'd like to remove this in ~6
months. M108 is released on November 29, 2022. I suggest we target
that milestone.

On Tuesday, May 10, 2022 at 3:15:32 PM UTC+2 Henrik Boström wrote:

Primary eng (and PM) emails
h...@chromium.org, h...@chromium.org

Summary
WebRTC allows sending and receiving audio, video and arbitrary
data between two endpoints using the RTCPeerConnection API.

The googIPv6 constraint was originally added to opt-in to IPv6
support while that was in development, but IPv6 support has
subsequently been enabled-by-default for many years. While
setting googIPv6 to true is a NO-OP, some users make use of this
non-standard API to disable IPv6 by setting it to false.

Motivation
A spec-compliant WebRTC implementation supports IPv6 and has no
way to disable IPv6. Non-chromium browsers does not have an
ability to disable IPv6, so this constraint is not good for interop.

We want to remove googIPv6 because a) it's non-standard, and b)
it resides in a dictionary argument of the RTCPeerConnection
called mediaConstraints that is also non-standard. The existence
of googIPv6 prevents us from removing mediaConstraints.

Interoperability and Compatibility Risk
The other browser vendors have been very supportive of removing
non-standard WebRTC APIs in the past, but I have not reached out
to any browser vendor specifically about googIPv6.

Alternative implementation suggestion for web developers
N/A.

Usage information from UseCounter
The LegacyConstraintGoogIPv6 use counter

suggests 0.000112%
of page loads use this feature by setting it to false (setting it
to true is a NO-OP and not counted here).

Entry on the feature dashboard
https://chromestatus.com/feature/5184046454800384

--
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/ac2ba002-b13a-4c17-b26c-ea38f8ae33b1n%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/99c75909-ded0-9d17-3cc4-3c0b1e1904c6%40chromium.org.

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

2022-05-09 Thread Mike Taylor

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?

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

2022-05-06 Thread Mike Taylor


Hi there,

While we review this, can we ask WebKit for a signal? 
(bit.ly/blink-signals). Also, 
https://github.com/w3ctag/design-reviews/issues/618 is the TAG review 
for this, correct?


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

_*
*_
_*
*_
_*
*_Motivation for ORB v0.1
_*

At this point, there remain open questions about the feasibility of 
the JS detection heuristics required by full ORB.  Still, the 
incremental benefits of adopting even a subset of ORB are definitely 
desirable.  We call this subset ORBv0.1 - the main difference from 
full ORB is replacing JS sniffing/parsing with CORB’s more limited 
HTML, JSON, and XML sniffers. In other words, ORBv0.1 still fails open 
and only blocks a subset of known response types, but it blocks more 
than CORB.


*ORBv0.1 offers incremental security benefits compared to CORB*.  
ORBv0.1 blocks the following kinds of HTTP responses that CORB 
wouldn’t block:


  * CORB blocks responses that contain HTML and XML only if they are
labeled with HTML mime type
 or XML mime
type .  ORBv0.1
blocks responses that contain HTML and XML even if they are
mislabeled (e.g. HTML served as application/octet-stream, or XML
served as text/html).
  * CORB blocks range request responses only if they are labeled with
HTML, JSON, or XML mime type.  ORBv0.1 blocks all range request
responses, unless they come from a URL that ORBv0.1 has earlier
recognized (via sniffing, or via mime type) as audio or video.

Note that both CORB and ORBv0.1 would block responses that contain 
JSON or JS-parser-breakers.  OTOH, this CORB protection can be 
bypassed if the victim’s server allows range requests (which are not 
blocked by CORB, except for HTML, JSON, or XML mime type). ORBv0.1 
closes that gap.


ORBv0.1 is also an incremental step toward full ORB compliance.  At 
the very least ORBv0.1 makes it easier to experiment with JS detection 
heuristics (including full Javascript parsing if necessary and 
acceptable from performance perspective).



*_Shipping ORBv0.1 in Chrome 103_*

Implementing ORB in Chromium is tracked in https://crbug.com/1178928 - 
*we plan to ship ORBv0.1 in Chrome M103*. Chrome’s implementation of 
CORB and ORBv0.1 covers all platforms except iOS.  This also includes 
Android WebView.  Chrome’s implementation is hosted in the NetworkService.



*_Backcompatibility risks of ORBv0.1_*

*The backcompatibility risk of shipping ORB seems low: less than 0.01% 
of all HTTP requests are at risk* because they are blocked by ORB and 
not by CORB.  Note that this is an *upper* bound for the amount of 
possible breakage:


  * This number includes responses with payload that is *not* valid in
no-cors contexts.  For example - https://example.com/document.html”> will not work regardless
of whether ORB blocks such a response or not.
  * This number is based on older telemetry results.  Recent CLs
should

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

2022-05-06 Thread Mike Taylor

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

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/3e7e8e6f-4366-5c24-5b2d-56b35a716614%40chromium.org.

Re: [blink-dev] Re: Intent to Ship: Region Capture

2022-05-02 Thread Mike Taylor

LGTM2

On 5/2/22 7:15 AM, Yoav Weiss wrote:

LGTM1

Thanks for initiating those discussions. My read of the minutes is
that they consider the async approach to be fine, and don't arbitrate
on the naming questions, other than saying that none of the proposals
seem better than where this API has landed. (and some may add confusion)
As such it seems that going with the API as currently defined doesn't
bear significant interoperability risk.

On Mon, May 2, 2022 at 1:03 PM Elad Alon wrote:

The discussions around Region Capture have been brought up with
TAG again (after their original approval

of the design). Here are the minutes from that second meeting:

https://github.com/w3ctag/meetings/blob/gh-pages/2022/telcons/04-25-minutes.md#media-capture-region

On Wednesday, April 20, 2022 at 6:33:52 PM UTC+2
yoav...@chromium.org wrote:

Just to (belatedly) update this thread: Following a discussion
with the API owners and the intent owner a few weeks back,
they are planning to try and get more folks to weigh in on the
open issues, and hopefully break the tie.

On Wednesday, March 23, 2022 at 6:28:30 PM UTC+1 Elad Alon wrote:

It may be better to ask actual web developers
regarding the least confusing option amongst those
proposed.

The Web-developers I am in contact with are happiest with
CropTarget. One of them has mentioned that on issue #18
.
Other Web-developers have not shown up with a preference
one way or another.

It bears mentioning that we have been discussing the API
in the WebRTC Working Group for approximately 14

months

.
The initial name for this part of the API was CropID. It
was changed

to
CropTarget ~4 months ago, following discussions in the
WG. Youenn filed issue #18
~2
months ago. During those two months, no WG member,
browser-implementer or Web-developer voiced concerns about
the "CropTarget" name. Youenn has made several suggestions
(Viewport, LayoutBox). I believe I have addressed these
suggestions. I do not think there is interest in the WG
for changing the name. I think the name CropTarget will
end up sticking, and not produce a compat risk.

Sync vs. async cropTarget creation seems like
something you'd want to decide on before shipping.

It is something we have tried reaching consensus on. But I
am not observing convergence. I proposed the following:

* For Chrome, it is important to use a Promise.
* For any browser that does not feel a Promise is
necessary, they can immediately return a pre-resolved
Promise.
* Web-developers would be virtually unaffected by the
addition of a Promise even - for the sake of argument
- if it isn't strictly necessary. (I still think it is
necessary.)

You mentioned on the thread that the browser can
refuse to mint new cropTargets in some cases. What
happens then? Is it specified? How are developers
supposed to defensively program their API use against
that?

Failure to mint additional tokens happens if excessive
tokens are minted. (Defends against memory-overuse in the
browser process.)
Failure is reflected by a Promise being rejected rather
than fulfilled - which is an established pattern and
well-understood by Web-developers.

If minting couldn't fail, then (naively) writing the
process/origin<->token mapping in the browser process
could've been done async, while the creation of the
token could be sync.

That is an interesting alternative; thank you for
suggesting it. I have given it thought, and I see some
issues with it. To start with, an application could be
given a "dead" token. Such a token will never be useful,
but the application would not be able detect that until it
calls cropTo(token), and that call

Re: [blink-dev] Intent to Extend Origin Trial: Trial for SharedArrayBuffers in non-isolated pages on Desktop platforms

2022-04-28 Thread Mike Taylor

On 4/27/22 12:26 PM, Lutz Vahl wrote:

On Wed, Apr 27, 2022 at 5:14 PM Chris Harrelson
wrote:

On Wed, Apr 27, 2022 at 6:04 AM Lutz Vahl wrote:

Contact emails

v...@chromium.org cl...@chromium.org

Explainer

https://docs.google.com/document/d/1zDlfvfTJ_9e8Jdc8ehuV4zMEu9ySMCiTGMS9y0GU92k

Specification

https://tc39.github.io/ecma262/#sec-sharedarraybuffer-objects

Design docs Including the new security requirements

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer

Discussion how and what to gate

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

Summary

‘SharedArrayBuffers’ (SABs) on desktop platforms are
restricted to cross-origin isolated environments, matching the
behavior we've recently shipped on Android and Firefox. We've
performed that change in Chrome 92. A reverse OT was started
to give developers the option to use SABs in case they are not
able to adopt cross origin isolation yet.

We’ve received lot’s of feedback that adopting COOP/COEP is
hard (details below). Therefore I’m asking for your approval
to extend the SAB reverse OT again from M103untilM113(branch
point 2023-03-23). This is an estimation - Can we come back to
y'all in 6 months with a report on progress and usage to
justify that extension and agree on the final milestone?

Experimental timeline / plan for all new capabilities needed
to replace the OT

The SAB restriction in M92 went smoothly without any major
issues in the wild because we offered the reverse OT. We’ve
received lots of feedback that adopting COOP/COEP is hard and
sometimes impossible. Therefore the reverse OT is currently
the only way to enable SABs for some sites within Chromium.
Chromestatus is showing that SABs in none COI context are
being used on ~0.36%

page
loads.

This seems off by a factor of 10. The real number seems to be
0.036% or so
,
right? Can you highlight why it's important to extend for 10 more
milestones for such a small percentage of traffic? Will the sites
in question completely break for some reason, or just behave the
same as in non-chromium browsers?

That's on me: 0.036%
is
correct!
Some sites use SAB to gain extra performance on chromium based
browsers in some cases 3P content is using SABs. Some might work
without the OT others will break based on how they identify their code
path to be used.

The list of OT registrations is ~500 and most of them mentioned to be
blocked by 3Ps to deploy COOP+COEP broadly.
We're happy to extend the OT to give them time to adopt. Do you
(and/or other API owners) think this is not required based on the low
usage?

Looking at the use counter data, usage was around 0.17% when the last
request to extend this deprecation trial was made (in Sept of '21).
Since then, it seems like usage decreased quite a lot but has been
basically flat since November of '21 when it was at 0.031% (it's looks
to have grown a tiny bit to 0.037% as of April).

Do we know who the 3Ps are who are holding back migration for the rest,
and what their plans are?

To overcome this limitation and make adoption possible more
broadly (public feedback
), we’re working
on multiple solutions

(all
shared timelines are WIP):

COEP:credentialless
-
https://crbug.com/1218896

COEP:credentialless causes no-cors cross-origin requests not
to include

credentials (cookies, client certificates, etc...). Similarly
to require-corp, it can be used to enable
cross-origin-isolation. Some developers are blocked on a set
of dependencies which don't yet assert that they're safe to
embed in cross-origin isolated environments.

This mechanism was shipped in M96. (Adoption is already at
0.02%

Re: [blink-dev] Re: Intent to Ship: Allow popstate to fire before load

2022-04-27 Thread Mike Taylor

LGTM3 - thanks for adding a killswitch just in case™.

On 4/27/22 7:30 AM, Daniel Bratell wrote:

LGTM2

/Daniel

On 2022-04-27 11:17, Yoav Weiss wrote:

LGTM1

While this can be statistically web-observable (by origins noticing
that they no-longer see hashchange followed by popstate), it seems
safe to assume that it's hard for them to rely on this in some way.
Thanks for improving interop here. Let's hope WebKit follows.

On Monday, April 25, 2022 at 7:00:11 PM UTC+2 Domenic Denicola wrote:

Contact emails

dome...@chromium.org, jap...@chromium.org

Specification

https://github.com/whatwg/html/pull/7815

Summary

Before this change, Chromium would fire hashchange asynchronously
(after a task), and delay popstate until the load event. This
means the event ordering could be either [hashchange, popstate],
or [popstate, hashchange], depending on how long the document
took to load. After this change, Chromium will match Firefox and
always fire popstate immediately upon URL changes, i.e. the order
will always be [popstate, hashchange].

Blink component

Blink>History

Search tags

popstate ,
hashchange ,
load

TAG review

This is a small bugfix to increase interop and so should not need
a TAG review.

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Currently Chromium and Safari both have the nondeterministic
delay-until-load behavior, whereas Firefox has the proposed
deterministic behavior. We hope Safari will follow and adopt the
deterministic behavior, since deterministic behavior is generally
better for interop. We believe the compatibility risk here is
minimal. Firefox has no reports of compat issues due to their
timing. And sites can already observe both [popstate, hashchange]
and [hashchange, popstate] orderings depending on network
conditions; thus it should be quite hard for any sites to depend
on the [hashchange, popstate] ordering which we are eliminating.
We plan to launch this with a feature flag so that it can be
remotely disabled using a Finch killswitch, just in case. And we
will keep careful eye on any bug reports as this naturally makes
its way through Canary/Dev/Beta channels.

Gecko: Shipped/Shipping

WebKit: No signal (https://bugs.webkit.org/show_bug.cgi?id=239729
) I don't think
this is worth emailing webkit-dev about, so I just filed a bug. I
am happy to email them if the API owners prefer.

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?

As noted in the compat section, there is some risk here, although
we believe it is small. We are using a base::Feature killswitch
just in case this causes particular problems on Android WebView
or elsewhere.

Debuggability

The usual DevTools ability to observe events is the only
applicable thing here, and already exists.

Is this feature fully tested by web-platform-tests

Yes

Flag name

DispatchPopstateSync

Requires code in //chrome?

False

Tracking bug

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

Estimated milestones

DevTrial on desktop 103

DevTrial on Android 103

Anticipated spec changes

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5080172872073216

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/fb7c5349-9ad8-4bce-bafc-764055e18f37n%40chromium.org

Re: [blink-dev] Intent to Experiment: Load common payloads from privacy-preserving single-keyed cache

2022-04-27 Thread Mike Taylor

Thanks Daisuke - sounds good. I don't think we'll need to extend beyond 
M102 (but I probably just jinxed it...).


On 4/26/22 8:50 PM, Daisuke Enomoto wrote:

Hi Mike,

Thank you for your question! We're targeting M103 to start the 
experiment. So, IIUC, it would not interact with the double-key 
experiment running through M102 unless it's extended.



On Wed, Apr 27, 2022 at 5:55 AM Mike Taylor  
wrote:


Hi Daisuke,

Can you clarify the timeline of the experiment? Would it begin in
M103? I have concerns about interactions with the current
double-key experiment
<https://groups.google.com/a/chromium.org/g/blink-dev/c/WQtp7Ixd1RU>
we're running for Network State Partitioning in M101 and M102.

On 4/26/22 7:59 AM, Daisuke Enomoto wrote:



Contact emails

ri...@chromium.org, nidhij...@chromium.org, denom...@chromium.org


Explainer


https://docs.google.com/document/d/1pvaMg7J5beBXD7trzHJH_MDULc_wRHLx40MFYAmjknE/edit

<https://docs.google.com/document/d/1pvaMg7J5beBXD7trzHJH_MDULc_wRHLx40MFYAmjknE/edit>


Specification

N/A (because there are no web-exposed changes)


Summary

This limited experiment measures how much "pervasive payloads"
contribute to the performance impact of the split HTTP cache in
each Chrome channel over a three-week period. Pervasive payloads
are those third-party payloads included on at least 500 sites and
fetched at least 10M times in a month, based on Chrome's analysis
(payload list included below). This experiment further measures
the impact on Core Web Vitals metrics of restoring pervasive
payloads (and only pervasive payloads) to a single-keyed cache
regime. The privacy benefits of the split HTTP cache are preserved.


Blink component

Blink>Network

<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ENetwork>


Motivation

Browsers split HTTP caches based on the top-frame visited origin
(“double-keyed” or "triple-keyed" caching) to prevent sites from
tracking users via a timing attack on a cross-site client cache.


Chrome’s analysis estimates that split caching results in a 3%
increase in cache misses, i.e. fetches for which a payload exists
in the cache of the user's device, but is unavailable to the page
because it was fetched by the user while loading a page from a
different origin. This results in approximately 4% more total
bytes being fetched over the network.


Our analysis further revealed that many of the redundant fetches
caused by split caching were for common payloads associated with
displaying user content (libraries, fonts, widgets, ads) or
common payloads that assist in operating online businesses
(analytics). The delayed arrival of these common payloads
resulted in visible "jank" for users, impacting performance
metrics like LCP <https://web.dev/lcp>, FCP
<https://web.dev/fcp>and CLS <https://web.dev/cls/>. This jank
has been associated with negative effects to online business'
engagement and conversion rates. Furthermore, delayed loads of
analytics and ads payloads can result in missed ads impressions
and dropped analytics hits.


Initial public proposal

This experiment sends a list to Chrome of 100  pairs
whose payloads are considered pervasive (the "pervasive payloads
list"). During the three-week experiment period, if Chrome
fetches a payload that matches both the URL and its hash on the
pervasive payloads list, it is inserted into a local single-keyed
cache. This payload is then available for use by Chrome when
loading pages on other sites that include the matching URL. All
other fetches for URLs not on the pervasive payloads list are
cached according to the existing split HTTP cache.


The hash covers the payload body and most response headers,
except for those which change on every response.


To ensure we do not degrade the privacy profile of any users
during this experiment, only users with third-party cookies
currently enabled will be eligible for the experiment. We will
compare the experience of users in experiment and control arms
according to total bytes loaded and page performance metrics like
the Core Web Vitals <https://web.dev/vitals>.


The pervasive payloads list was produced by crawling the web and
aggregating the most commonly referenced third-party resource
URLs included in HTML content. We then used pseudonymous
URL-keyed metrics from Chrome to estimate the traffic to sites
and the number of impressions of third-party resources.
Individually identifiable browsing or search histories were not
used in the creation of the pervasive payload list (for mo

Re: [blink-dev] Intent to Ship: Early Hints preload/preconnect during Navigation

2022-04-27 Thread Mike Taylor

LGTM2

On 4/27/22 2:33 AM, Yoav Weiss wrote:

LGTM1

I'm excited about this work as it unlocks many potential wins in terms
of loading performance. Interest from Mozilla as well as support from
leading CDNs is also promising in terms of activation and usage.
Thanks for working on this!!

On Wed, Apr 27, 2022 at 7:49 AM Daisuke Enomoto
wrote:

Any other questions or concerns?

Thanks!

On Thu, Apr 21, 2022 at 5:23 PM Kenichi Ishibashi
wrote:

Hi Yoav,

On Thu, Apr 21, 2022 at 3:26 PM Yoav Weiss
wrote:

On Thu, Apr 21, 2022 at 4:13 AM Kenichi Ishibashi
wrote:

Contact emails

ba...@chromium.org, denom...@chromium.org

Explainer

https://github.com/bashi/early-hints-explainer/blob/main/explainer.md

Specification

https://tools.ietf.org/html/rfc8297

https://html.spec.whatwg.org/#early-hints

Design docs

https://docs.google.com/document/d/1gCh_CnfrJq_VL7aGoq6skc7sn4yn5pKsM0gkHe5B9go/edit?usp=sharing

Summary

Support 103 Early Hints informational responses during
top-level frame navigation. When a 103 response
includes link headers Chromium tries to preload
specified resources (including modulepreload) or
preconnect to specified origins before the final
response is received. This gives Web developers a way
to optimize Core Web Vitals such as Largest Contentful
Paint (LCP).

Blink component

Internals>Preload

TAG review

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

TAG review status

Issues addressed

Risks

Interoperability and Compatibility

Browsers may not understand a 103 response but they
are expected

to
ignore 1xx responses if they don’t understand 1xx
responses. Firefox is implementing 103 support.

Proxies may not understand a 103 response. They may
treat the 103 response as a part of the final response
when the response is sent over HTTP/1.1. The problem
is less likely to happen over HTTP/2 and HTTP/3 thanks
to their frame format. Chromium only handles 103
responses over HTTP/2 and HTTP/3.

The HTML and Fetch standards have been updated to
handle preload link headers in 103 responses for
navigations (whatwg/html#7675
,
whatwg/fetch#1404
). For
preconnect there are ongoing efforts to specify the
behavior. See “Anticipated spec changes” section below
for more information.

Gecko: In development
.

Can you ask for an official position?
https://bit.ly/blink-signals

I should have put the link to the official position. They said
it's worth prototyping
and
IIUC it's under development.

WebKit: No signal

Web developers: Positive. Positive interest and intent
of support by popular CDNs (Fastly

,
Cloudflare
). We've
been collaborating with partners to evaluate the
impact of Early Hints and we observed significant
improvements on page loading metrics such as FCP.

Ergonomics

The primary usage of this feature is to send link
headers to preload resources or preconnect to servers
to improve page load perfor

Re: [blink-dev] Intent to Experiment: Load common payloads from privacy-preserving single-keyed cache

2022-04-26 Thread Mike Taylor


Hi Daisuke,

Can you clarify the timeline of the experiment? Would it begin in M103? 
I have concerns about interactions with the current double-key 
experiment 
 
we're running for Network State Partitioning in M101 and M102.


On 4/26/22 7:59 AM, Daisuke Enomoto wrote:



Contact emails

ri...@chromium.org, nidhij...@chromium.org, denom...@chromium.org


Explainer

https://docs.google.com/document/d/1pvaMg7J5beBXD7trzHJH_MDULc_wRHLx40MFYAmjknE/edit 




Specification

N/A (because there are no web-exposed changes)


Summary

This limited experiment measures how much "pervasive payloads" 
contribute to the performance impact of the split HTTP cache in each 
Chrome channel over a three-week period. Pervasive payloads are those 
third-party payloads included on at least 500 sites and fetched at 
least 10M times in a month, based on Chrome's analysis (payload list 
included below). This experiment further measures the impact on Core 
Web Vitals metrics of restoring pervasive payloads (and only pervasive 
payloads) to a single-keyed cache regime. The privacy benefits of the 
split HTTP cache are preserved.



Blink component

Blink>Network 




Motivation

Browsers split HTTP caches based on the top-frame visited origin 
(“double-keyed” or "triple-keyed" caching) to prevent sites from 
tracking users via a timing attack on a cross-site client cache.



Chrome’s analysis estimates that split caching results in a 3% 
increase in cache misses, i.e. fetches for which a payload exists in 
the cache of the user's device, but is unavailable to the page because 
it was fetched by the user while loading a page from a different 
origin. This results in approximately 4% more total bytes being 
fetched over the network.



Our analysis further revealed that many of the redundant fetches 
caused by split caching were for common payloads associated with 
displaying user content (libraries, fonts, widgets, ads) or common 
payloads that assist in operating online businesses (analytics). The 
delayed arrival of these common payloads resulted in visible "jank" 
for users, impacting performance metrics like LCP 
, FCP and CLS 
. This jank has been associated with negative 
effects to online business' engagement and conversion rates. 
Furthermore, delayed loads of analytics and ads payloads can result in 
missed ads impressions and dropped analytics hits.



Initial public proposal

This experiment sends a list to Chrome of 100  pairs whose 
payloads are considered pervasive (the "pervasive payloads list"). 
During the three-week experiment period, if Chrome fetches a payload 
that matches both the URL and its hash on the pervasive payloads list, 
it is inserted into a local single-keyed cache. This payload is then 
available for use by Chrome when loading pages on other sites that 
include the matching URL. All other fetches for URLs not on the 
pervasive payloads list are cached according to the existing split 
HTTP cache.



The hash covers the payload body and most response headers, except for 
those which change on every response.



To ensure we do not degrade the privacy profile of any users during 
this experiment, only users with third-party cookies currently enabled 
will be eligible for the experiment. We will compare the experience of 
users in experiment and control arms according to total bytes loaded 
and page performance metrics like the Core Web Vitals 
.



The pervasive payloads list was produced by crawling the web and 
aggregating the most commonly referenced third-party resource URLs 
included in HTML content. We then used pseudonymous URL-keyed metrics 
from Chrome to estimate the traffic to sites and the number of 
impressions of third-party resources. Individually identifiable 
browsing or search histories were not used in the creation of the 
pervasive payload list (for more information about Chrome's data 
collection policies and privacy policies, see 
google.com/chrome/privacy ). The 
resulting list was further filtered for any URLs that might contain 
PII (e.g. URLs with extensive or opaque query parameters). The list 
was also manually reviewed to ensure it included only payloads 
reasonably expected to be pervasive; the manual review did not result 
in any payloads being removed.



The privacy properties of the split HTTP cache are considered 
essential to users and this proposal intends to maintain those 
properties, specifically by maintaining split HTTP caching for all 
payloads not on the pervasive payloads list.



API semantics are unchanged. User-facing functionality is unchanged 
(thou

Re: [blink-dev] Intent to Experiment: Load common payloads from privacy-preserving single-keyed cache

2022-04-26 Thread Mike Taylor


On 4/26/22 8:14 AM, Anne van Kesteren wrote:

On Tue, Apr 26, 2022 at 1:59 PM Daisuke Enomoto  wrote:

Explainer

https://docs.google.com/document/d/1pvaMg7J5beBXD7trzHJH_MDULc_wRHLx40MFYAmjknE/edit

This document isn't public.


I just checked the settings, and it should be public now.


This particular technique has been discussed before, but there's a
flaw which wasn't mentioned in this email. The idea assumes that all
end users can access the same websites and also that all end users
visit similar websites. Neither of those is a given and as such end
users that for one reason or another only end up visiting one or two
websites that use a "pervasive payload" could be vulnerable to attack.



--
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/b55ad061-d351-2def-602c-b857193c944c%40chromium.org.

Re: [blink-dev] Intent to Ship: AbortSignal.timeout() Static Method

2022-04-26 Thread Mike Taylor

LGTM1

On 4/22/22 6:49 PM, Scott Haseley wrote:

Contact emails

shase...@chromium.org

Explainer

https://github.com/whatwg/dom/pull/1032#issue-1058779111

Specification

https://dom.spec.whatwg.org/#dom-abortsignal-timeout

Summary

Returns a new AbortSignal object that is automatically aborted after a
given number of milliseconds. This method can be used by developers to
easily implement timeouts for signal-accepting async APIs, e.g. fetch().

Blink component

Blink>DOM

TAG review

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

Note: the TAG review is still pending (we replied to their initial set
of questions and are awaiting response). Since filing the issue,
however, the DOM spec PR has been merged and Safari and Firefox have
implemented the feature, meaning this should be exempt from TAG review.

TAG review status

Pending

Risks

Interoperability and Compatibility

Low risk. This feature is already part of the DOM standard, has web
platform tests, and is implemented by Safari and Firefox. We'll
improve eventual interop by shipping this feature.

Gecko: Shipped/Shipping
(https://bugzilla.mozilla.org/show_bug.cgi?id=1753309). Available in
FF 100

WebKit: Shipped/Shipping
(https://bugs.webkit.org/show_bug.cgi?id=236039). Available in Safari
TP Release 141:
https://developer.apple.com/safari/technology-preview/release-notes/

Web developers: Positive. Positive reception to Chrome, Safari, and
Node tweets:

- https://twitter.com/tomayac/status/1494575885785174016
- https://twitter.com/chris_dumez/status/1489297763082772481
- https://twitter.com/simonplend/status/1494309000824954882

Other signals: This has also shipped in Node and Deno.

Ergonomics

We think this API is useful on its own, but also think it will benefit
from an API to combine AbortSignals, e.g. combining a timeout with
user cancellation, which we're currently working on:
https://github.com/shaseley/abort-signal-any/blob/main/README.md.

Activation

The feature has already been implemented in both Safari and Firefox,
but it would benefit from a polyfill for use in older browser versions.

Security

None.

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 change is strictly additive.

Debuggability

Basic tooling only, i.e. autocomplete support for the new AbortSignal
method will be provided.

Is this feature fully tested by web-platform-tests

Yes

Flag name

--enable-blink-features=AbortSignalTimeout

Requires code in //chrome?

False

Tracking bug

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

Launch bug

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

Measurement

https://chromestatus.com/metrics/feature/popularity#AbortSignalTimeout

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.

Sample links

https://developer.mozilla.org/en-US/docs/Web/API/AbortSignal/timeout

Estimated milestones

103

Anticipated spec changes

None.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5768400507764736

Links to previous Intent discussions

Intent to prototype:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXGoJ21UGV-atHU38es8AtFC4tYX7PQrMCoq-zObxo36z4ELQ%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/CAKXGoJ3TAcMOMsYtEVbDubh5NLVT%3Dm6TANkvAWYAZO8Mhn-15A%40mail.gmail.com
.

--
You received

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

2022-04-25 Thread Mike Taylor


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

--enable-blink-features=CapabilityDelegationFullscreenRequest


Requires code in //chrome?

Yes, work in progress


Tracking bug

https://crbug.com/1293083 


Estimated milestone

103


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6441688242323456 




Links to previous Intent discussions

Intents for the general delegation mechanism:

 *

I2P:

https://groups.google.com/a/chromium.org/g/blink-dev/c/9CeLYndESPE/m/AhEttheMBQAJ



 *

I2E (with Payment Request):

https://groups.google.com/a/chromium.org/g/blink-dev/c/i6pAWsjU7zg/m/UK0lGnKuAAAJ



I2S (with Payment Request): 
https://groups.google.com/a/chromium.org/g/blink-dev/c/PHT_2X7oRBE/m/gR9UiZxBAQAJ 


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

Re: [blink-dev] Re: Intent to Prototype and Ship: Permissions Policy for Web Bluetooth API

2022-04-25 Thread Mike Taylor

LGTM2

On 4/21/22 1:36 AM, Yoav Weiss wrote:

LGTM1

On Monday, April 18, 2022 at 5:47:47 PM UTC+2 Gabriel Brito wrote:

Hi,

Hope you are doing well. We would like to request approval
for this feature. Thank you in advance!

Contact emails

gabrielbr...@microsoft.com

Explainer

https://webbluetoothcg.github.io/web-bluetooth/#permissions-policy

Specification

https://webbluetoothcg.github.io/web-bluetooth/#permissions-policy

Worth mentioning the processing model

which uses that new keyword.

Also seems worth mentioning the TAG review requirement and why it's
not applicable in this case. I tend to agree that it's an overkill, as
adding a permission policy gate here is a well-known pattern.

Summary

Integrates the Web Bluetooth API with Permissions Policy, which
should be identified by the "bluetooth" token. The Web Bluetooth
API allows webpages to communicate with devices over Bluetooth.
However, this API is not allowed to be used from cross-origin
iframes. This integration enables this scenario while providing
protection against unwanted access to Bluetooth capabilities,
which requires the top-level document to explicitly allow a
cross-origin iframe to use the API's methods.

Blink component

Blink>Bluetooth

Risks

Interoperability and Compatibility

Low interoperability risks, since it is an integration of the Web
Bluetooth API with Permissions Policy, which is already widely
adopted. Also not explicitly allowing an iframe to use bluetooth
with allow="bluetooth" won't affect the current behavior.

/Gecko/: No signal

Negative is
more accurate:

/WebKit/: No signal

Similarly, a negative
signal is
more appropriate.

/Web developers/: Positive
(https://bugs.chromium.org/p/chromium/issues/detail?id=518042
)

/Other signals/:

Ergonomics

No anticipated ergonomic risks.

Activation

If developers would like to provide access to Web Bluetooth to
cross-origin trusted iframes, they just need to add
allow="bluetooth" to it.

Security

This integration makes the Web Bluetooth API more secure while
keeping the current behavior and adding more capabilities to it.

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. Web Bluetooth is not available in WebView.

Debuggability

N/A (No DevTools support needed)

Is this feature fully tested by web-platform-tests

Yes

Flag name

No flag.

Requires code in //chrome?

False

Tracking bug

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

Estimated milestones

No milestones specified

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

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

Re: [blink-dev] Intent to Prototype: CSS toggles

2022-04-19 Thread Mike Taylor

On 4/19/22 1:06 PM, David Baron wrote:
On Tue, Apr 19, 2022 at 10:32 AM Mike Taylor
wrote:

Specification

https://tabatkins.github.io/css-toggle/

A question came up in Security & Privacy review today. Can you
clarify what "persistent state" means in
https://tabatkins.github.io/css-toggle/#toggles? I suspect we're
not re-inventing cookies in CSS here, but can you help me
understand what that means in the context of CSS toggles? Does it
just mean that once set, other CSS properties can't influence the
state? Or "persistent state (for the lifetime of the page)"?

I think what the "persistent state" bit is saying is that once a
toggle is created on an element (by the toggle-root property), the
toggle doesn't go away even if the toggle-root property changes. It's
definitely not something like cookies, since the state doesn't get
transferred to other pages or to fresh loads of the same page.

(I haven't thought much about the question yet, but it's
/possible/ that it might be something like form control state that
gets persisted specially during back/forward navigation even when the
entire page isn't cached. I suspect that may cause more problems than
it fixes, though.)

Thanks David - that's helpful.

--
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/873d29e0-fe67-5b3f-0e21-a3a39d572719%40chromium.org.

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

2022-04-19 Thread Mike Taylor


Yep, that's the plan.

On 4/19/22 12:22 PM, 'Joe Medley' via blink-dev wrote:

Is this shipping in 101? That's the rumor.

On Wednesday, February 2, 2022 at 8:59:39 AM UTC-8 mk...@chromium.org 
wrote:


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*

*

mike...@chromium.org, abe...@chromium.org,
jadek...@chromium.org


Explainer


https://github.com/WICG/ua-client-hints#explainer-reducing-user-agent-granularity

<https://github.com/WICG/ua-client-hints#explainer-reducing-user-agent-granularity>


Specification

https://www.chromium.org/updates/ua-reduction
<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 <https://compat.spec.whatwg.org/>will
be updated to reflect them (in the newly landed UA
String section
<https://compat.spec.whatwg.org/#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

<https://html.spec.whatwg.org/#concept-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
<https://github.com/whatwg/compat/issues/created_by/domenic>,
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

<https://blog.chromium.org/2021/09/user-agent-reduction-origin-trial-and-dates.html>,
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 <https://web.dev/migrate-to-ua-ch/>, in particular
the Sec-CH-UA-Full-Version-List

<https://wicg.github.io/ua-client-hints/#sec-ch-ua-full-version-list>hint.



Blink component

Blink

<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink>


TAG review

https://github.com/w3ctag/design-reviews/issues/640
<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

Re: [blink-dev] Intent to Prototype: CSS toggles

2022-04-19 Thread Mike Taylor

Hi David,

On 4/15/22 10:19 AM, David Baron wrote:

Contact emails

dba...@chromium.org, ns...@google.com

Explainer

https://css.oddbird.net/toggles/explainer/

Specification

https://tabatkins.github.io/css-toggle/

A question came up in Security & Privacy review today. Can you clarify
what "persistent state" means in
https://tabatkins.github.io/css-toggle/#toggles? I suspect we're not
re-inventing cookies in CSS here, but can you help me understand what
that means in the context of CSS toggles? Does it just mean that once
set, other CSS properties can't influence the state? Or "persistent
state (for the lifetime of the page)"?

Summary

CSS toggles are a mechanism for associating toggleable state with a
DOM element. This state can be defined and connected to activations
through CSS properties, and can be queried in CSS selectors. This
provides a declarative mechanism for specifying state that describes
behaviors like the existing HTML behaviors for checkboxes or radio
buttons.

Blink component

Blink>DOM

Motivation

There are many cases where a user interaction (such as a click)
toggles state that styles depend on. These cases include popups, tabs,
carousels, accordions, and toggles controlling light/dark mode.
Building these today requires Javascript. We would like to build a
declarative way of doing this that, if we do it right, will be easier
for developers to use, faster, and more accessible than the solutions
that are used today.

Additional context

I'd like to emphasize that this intent to prototype really is an
intent to /prototype/. The goal here is to build an implementation
that can be used to guide the design of this feature (by giving those
involved an implementation to test), not to build something that we'd
like to ship quickly.

Before we would consider shipping something in this space, we would
(among other things) want to do further testing to validate that the
result /is/ more accessible than what people use today (or learn that
we need to build in more distinctions that can be reflected into
accessibility roles), and do additional development of the things that
we hope can be built on top of toggles to validate that it works as a
primitive.

Initial public proposal

https://github.com/w3c/csswg-drafts/issues/6991

TAG review

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

TAG review status

Pending (just filed)

Risks

Interoperability and Compatibility

Gecko: No signal

WebKit: No signal

Web developers: No direct signals, but what kicked off the original
designs here was OpenUI work around tabs (see, e.g.,
https://open-ui.org/components/tabs.research ).

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

New CSS properties and CSS selectors should be debuggable in the same
way that all existing properties and selectors are. If this turns into
something that we want to ship, we will probably want to add
additional devtools support for understanding the underlying toggle
states, but we don't want to do so this early in the prototyping process.

Is this feature fully tested by web-platform-tests

No, though I plan to add tests as I write the code

Flag name

CSSToggles

Requires code in //chrome?

False

Tracking bug

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

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5072281125519360

This intent message was generated by Chrome Platform Status
and then edited by hand.

--
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/CAG0MU3hE3gnQQNHTD7hT-jukBYFgwTXbYZQWSS1iJVXn9J7iyg%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/c2efb86f-ca8d-4773-af24-a7460bde0

Re: [blink-dev] Intent to Ship: ARIA Attribute Reflection for role attribute

2022-04-19 Thread Mike Taylor

LGTM2

On 4/19/22 8:33 AM, Yoav Weiss wrote:

LGTM1

On Sun, Apr 17, 2022 at 10:38 PM Manuel Rego Casasnovas
wrote:

**Contact emails**

r...@igalia.com

**Specification**

https://w3c.github.io/aria/#idl-interface

**Summary**

This is a kind of oversight from
https://chromestatus.com/feature/6643371200217088, at that time all
other ARIA attributes from the IDL
(https://w3c.github.io/aria/#idl-interface) were shipped, but this one
was missing.

This is a small change that will also include the role attribute
as one
more of the reflection ARIA properties available.

**Motivation**

This should have shipped in M81

(https://groups.google.com/a/chromium.org/g/blink-dev/c/882iPcdnNQs/m/UP-PI8H2DwAJ)
together with the rest of attributes, by for some reason this wasn't
done (probably because it was originally developed under a different
runtime flag).

**Blink component**

Blink>Accessibility

**TAG review**

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

**TAG review status**

Complete

**Risks**

**Interoperability and Compatibility**

This is just one more property that should had shipped originally.

This has been shipped in Safari
(https://trac.webkit.org/changeset/234482/webkit) long time ago.

And there's an implementation in Firefox behind a flag.

**Gecko**: Under consideration
(https://github.com/mozilla/standards-positions/issues/211) Mozilla
position is still under consideration, but Firefox has an
implementation
behind a runtime flag
(https://bugzilla.mozilla.org/show_bug.cgi?id=1628418). Last comment
from Anne on the bug, points to some spec issues but those are generic
issues for the whole feature (not particular issues with "role"
property
itself).

**WebKit**: Shipped/Shipping
(https://trac.webkit.org/changeset/234482/webkit)

**Debuggability**

This will work the same than the rest of properties already shipped.

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

Yes

**Tracking bug**

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

**Link to entry on the Chrome Platform Status**

https://chromestatus.com/feature/5188935855636480

--
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/e0cb6f12-027f-e83e-e08e-8a35ff44642b%40igalia.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/CAL5BFfVAv638VTX6Ezpxa678Mx%3DiDBxhREcUKmP48CSv7AEQEw%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/d8d7edc0-3e28-5a8d-b29b-6a85d48ff009%40chromium.org.

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

2022-04-18 Thread Mike Taylor

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

<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EHistory>

TAG review

https://github.com/w3ctag/design-reviews/issues/605
<https://github.com/w3ctag/design-reviews/issues/605>

https://github.com/w3ctag/design-reviews/issues/717
<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

<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
<https://github.com/whatwg/html/pull/6315>and elsewhere on the
HTML Standard issue tracker

<https://github.com/whatwg/html/issues?q=is%3Aopen+is%3Aissue+label%3A%22topic%3A+navigation%22%2C%22topic%3A+history%22%2C%22topic%3A+browsing+context%22>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
<https://github.com/whatwg/html/issues/1792>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
<https://github.com/WICG/navigation-api/issues/221>.

I do have slight concerns
<https://github.com/whatwg/html/issues/1792#issuecomment-1101459682>
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 le

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

2022-04-18 Thread Mike Taylor

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?

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 changes and a good
amount of review. (We have no signal from WebKit.)

Compatibility

This has been the team's main focus for the last few months, as we
burned through the list of potentially-compat-impacting issues
. In collaboration
with Gecko this led to several improvements, such as the API rename
(from app history), a change
in how replacement
navigations are requested, and the addition
of an indicator for
when a download is requested. We believe the remaining issues (3 at
the time of writing) are manageable:

#72 : this will
result in firing an event more often during extreme edge case
scenarios involving replacement navigations, or in
less-rare-but-still-rare scenarios involving the user clearing
their history. Neither case should prove problematic.

#207 : the most
likely solution will either be leaving things as they are, or
changing the timing of an event in a way that will not disturb
"normal" usage of the API. Although such a timing change could be
risky if this API had wide deployment, we believe that changing
the timing within a milestone or three would not be problematic if
it ends up being desirable.

#202

Re: [blink-dev] Intent to Deprecate and Remove: Deprecate element's functionality

2022-04-15 Thread Mike Taylor

Fantastic - nice work on the compat analysis. LGTM.

On 4/15/22 5:02 PM, Mason Freed wrote:
No problem! So here too, I think I have an answer for you. As part of
the discussion around deprecating this functionality, I did exactly
that: an HTTP Archive search for containing . See this
comment
<https://github.com/whatwg/html/issues/387#issuecomment-961271400>,
which links to this spreadsheet
<https://docs.google.com/spreadsheets/d/1Fo3F6IIOMFbXH116Y22950CSSksvuRLLwO3c5Kn8E90/edit?resourcekey=0-U-u5Uecsr9aK2S-CWSwPDg#gid=1743741361> with
results. Also, importantly, see this reply comment
<https://github.com/whatwg/html/issues/387#issuecomment-961362808>
with more analysis.

The TL;DR is that in the end, we did not find any issues with the top
~20 sites we found. And while we were looking only for PDF-related
params, that's all that Chromium currently supports anyway, so that
should be all we're capable of breaking.

LMK if the above satisfies your desire to do more spot checking, or if
you'd prefer I look deeper.

Thanks,
Mason

On Fri, Apr 15, 2022 at 1:52 PM Mike Taylor
wrote:

Oh cool, I didn't notice the fallback iframe or embed, thanks for
pointing that out! I think just to be on the safe side, searching
HTTP Archive for a list of sites that have an with
non-swf values would be nice to look at, and we could spot
check a small pile to ensure this fallback pattern holds and we're
not breaking video playback on sites that may not be maintained.

On 4/15/22 2:31 PM, Mason Freed wrote:

Thanks for digging into the example sites there! So I looked
further into the two examples you gave, and I think what's
actually going on in both cases is that the also
contains fallback content which is what you're seeing:

For http://sextherapy.ru/, the full looks like this:

http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,40,0";>
http://www.youtube.com/v/7wQYLXBX2RQ?version=3&hl=ru_RU&rel=0>"
/>
http://www.youtube.com/v/7wQYLXBX2RQ?version=3&hl=ru_RU&rel=0>"
allowFullScreen="true" allowscriptaccess="always"
allowfullscreen="true" />

The s in this example aren't actually doing anything - you
can remove them and still see the video, since it's provided by
the fallback . It looks like those params were maybe meant
to talk to an SWF object?

Similarly, for https://jackrussell.forumattivo.com/, the
is this:
https://www.youtube.com/v/_ikcScPyKUQ&hl=it&fs=1&;
<https://www.youtube.com/v/_ikcScPyKUQ&hl=it&fs=1&;>">
https://www.youtube.com/embed/_ikcScPyKUQ";
frameborder="0" allowfullscreen="">

Again, the s aren't doing anything here, and the fallback
contains the "real" content.

I also confirmed that with the proposed behavior disabled (i.e.
s can't provide URLs), both example sites still work.

I'm happy to look further into other such examples if you like,
but I think these two examples should be "ok".

Again, thanks for taking a look!

Thanks,
Mason

On Fri, Apr 15, 2022 at 11:06 AM Mike Taylor
wrote:

On 4/13/22 12:48 PM, Mason Freed wrote:

Contact emails

mas...@chromium.org

Explainer

https://github.com/whatwg/html/pull/7816
https://github.com/whatwg/html/issues/6003

Specification

https://github.com/whatwg/html/pull/7816

Summary

The element can be used to specify parameters such
as a URL (via params named "movie", "src", "code", "data",
or "url") to a containing element. Given the
removal of plugins from the web platform, and the relative
lack of use of this particular functionality, we would like
to deprecate and remove it.

Blink component

Blink
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink>

Motivation

Given that plugins are gone from the web platform (with
their full removal from the spec being tracked in
https://github.com/whatwg/html/issues/6003), it is not
useful. In some browsers it can be used to figure out the
URL of an , even when that is not being
used for a plugin, via params named "movie", "src", "code",
"data", or "url". But we decided to remove this behavior
from browsers instead of specifying it. This retains the
HTMLParamElement interfa

Re: [blink-dev] Intent to Deprecate and Remove: Deprecate element's functionality

2022-04-15 Thread Mike Taylor

Oh cool, I didn't notice the fallback iframe or embed, thanks for 
pointing that out! I think just to be on the safe side, searching HTTP 
Archive for a list of sites that have an  with non-swf  
values would be nice to look at, and we could spot check a small pile to 
ensure this fallback pattern holds and we're not breaking video playback 
on sites that may not be maintained.


On 4/15/22 2:31 PM, Mason Freed wrote:
Thanks for digging into the example sites there! So I looked further 
into the two examples you gave, and I think what's actually going on 
in both cases is that the  also contains fallback content 
which is what you're seeing:


For http://sextherapy.ru/, the full  looks like this:

            
codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,40,0";>

    
    
    value="//www.youtube.com/v/7wQYLXBX2RQ?version=3&hl=ru_RU&rel=0 
<http://www.youtube.com/v/7wQYLXBX2RQ?version=3&hl=ru_RU&rel=0>" 
/>

    
              
 src="//www.youtube.com/v/7wQYLXBX2RQ?version=3&hl=ru_RU&rel=0 
<http://www.youtube.com/v/7wQYLXBX2RQ?version=3&hl=ru_RU&rel=0>"
           allowFullScreen="true" allowscriptaccess="always" 
allowfullscreen="true" />

  

The s in this example aren't actually doing anything - you can 
remove them and still see the video, since it's provided by the 
fallback . It looks like those params were maybe meant to talk 
to an SWF object?


Similarly, for https://jackrussell.forumattivo.com/, the  is this:
  
    value="https://www.youtube.com/v/_ikcScPyKUQ&hl=it&fs=1&; 
<https://www.youtube.com/v/_ikcScPyKUQ&hl=it&fs=1&;>">

    
    
    src="https://www.youtube.com/embed/_ikcScPyKUQ";

           frameborder="0" allowfullscreen="">
  

Again, the s aren't doing anything here, and the fallback 
 contains the "real" content.


I also confirmed that with the proposed behavior disabled (i.e. 
s can't provide URLs), both example sites still work.


I'm happy to look further into other such examples if you like, but I 
think these two examples should be "ok".


Again, thanks for taking a look!

Thanks,
Mason



On Fri, Apr 15, 2022 at 11:06 AM Mike Taylor  
wrote:


On 4/13/22 12:48 PM, Mason Freed wrote:



Contact emails

mas...@chromium.org


Explainer

https://github.com/whatwg/html/pull/7816
https://github.com/whatwg/html/issues/6003


Specification

https://github.com/whatwg/html/pull/7816


Summary

The  element can be used to specify parameters such as a
URL (via params named "movie", "src", "code", "data", or "url")
to a containing  element. Given the removal of plugins
from the web platform, and the relative lack of use of this
particular functionality, we would like to deprecate and remove it.



Blink component

Blink
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink>


Motivation

Given that plugins are gone from the web platform (with their
full removal from the spec being tracked in
https://github.com/whatwg/html/issues/6003), it is not useful. In
some browsers it can be used to figure out the URL of an
, even when that  is not being used for a plugin,
via params named "movie", "src", "code", "data", or "url". But we
decided to remove this behavior from browsers instead of
specifying it. This retains the HTMLParamElement interface, as
well as the parser behavior of .



Initial public proposal



Search tags

 <https://chromestatus.com/features#tags:%3Cparam%3E>,
 <https://chromestatus.com/features#tags:%3Cobject%3E>


TAG review



TAG review status

Not applicable


Risks



Interoperability and Compatibility



Gecko: Shipped/Shipping
(https://github.com/whatwg/html/issues/387#issuecomment-1088331300)
Issue was initially raised by Mozilla, and Gecko already does not
process param at all.

WebKit: No signal
(https://bugs.webkit.org/show_bug.cgi?id=239188) No response on
the bug yet.

Web developers: No signals

Other signals:


Ergonomics

Since this is a deprecation, there is a Web Compat risk. I added
use counters for the situations that will be affected: - 
that specifies a URL, inside an  that doesn't: 0.04%,
https://chromestatus.com/metrics/feature/timeline/popularity/4010
- As above, but URL successfully resolves to a (supported) PDF
resource: 0.2%,
https://chromestatus.com/metrics/feature/timeline/popularity/4110
- As a

Re: [blink-dev] Intent to Deprecate and Remove: Deprecate element's functionality

2022-04-15 Thread Mike Taylor


On 4/13/22 12:48 PM, Mason Freed wrote:



Contact emails

mas...@chromium.org


Explainer

https://github.com/whatwg/html/pull/7816
https://github.com/whatwg/html/issues/6003


Specification

https://github.com/whatwg/html/pull/7816


Summary

The  element can be used to specify parameters such as a URL 
(via params named "movie", "src", "code", "data", or "url") to a 
containing  element. Given the removal of plugins from the web 
platform, and the relative lack of use of this particular 
functionality, we would like to deprecate and remove it.




Blink component

Blink 


Motivation

Given that plugins are gone from the web platform (with their full 
removal from the spec being tracked in 
https://github.com/whatwg/html/issues/6003), it is not useful. In some 
browsers it can be used to figure out the URL of an , even 
when that  is not being used for a plugin, via params named 
"movie", "src", "code", "data", or "url". But we decided to remove 
this behavior from browsers instead of specifying it. This retains the 
HTMLParamElement interface, as well as the parser behavior of .




Initial public proposal



Search tags

 ,  




TAG review



TAG review status

Not applicable


Risks



Interoperability and Compatibility



Gecko: Shipped/Shipping 
(https://github.com/whatwg/html/issues/387#issuecomment-1088331300) 
Issue was initially raised by Mozilla, and Gecko already does not 
process param at all.


WebKit: No signal (https://bugs.webkit.org/show_bug.cgi?id=239188) No 
response on the bug yet.


Web developers: No signals

Other signals:


Ergonomics

Since this is a deprecation, there is a Web Compat risk. I added use 
counters for the situations that will be affected: -  that 
specifies a URL, inside an  that doesn't: 0.04%, 
https://chromestatus.com/metrics/feature/timeline/popularity/4010 - As 
above, but URL successfully resolves to a (supported) PDF resource: 
0.2%, 
https://chromestatus.com/metrics/feature/timeline/popularity/4110 - As 
above, but URL successfully resolves to an (unsupported) non-PDF 
resource: not measurable, 
https://chromestatus.com/metrics/feature/timeline/popularity/4111 So 
the vast majority (99.95%) of  URL usage appears to point to 
invalid resources - likely mostly Flash. A very small percentage 
(0.05% of -with-URL usage, 0.2% of web page loads) are 
likely to break when we deprecate this functionality.


I clicked on the first 20 results from 
https://chromestatus.com/metrics/feature/timeline/popularity/4010 
(careful, 1 is NSFW), and 18 contain busted SWFs. But two of them are 
embedding youtube videos via :


https://jackrussell.forumattivo.com/ has an  that has a child 
param name="movie" 
value="https://www.youtube.com/v/_ikcScPyKUQ&hl=it&fs=1&";>.


http://sextherapy.ru/ (SFW-ish, at least on the homepage)name="src" 
value="//www.youtube.com/v/7wQYLXBX2RQ?version=3&hl=ru_RU&rel=0" />


I had no idea that was possible - can we dig in some more to see how 
many params have a value with "youtube.com", to see if I got lucky and 
found the only 2, or if a lot of sites are relying on this behavior?





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

Deprecation.



Is this feature fully tested by web-platform-tests

?

Yes


Flag name



Requires code in //chrome?

False


Tracking bug

https://crbug.com/1315717


Estimated milestones

No milestones specified



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6283184588193792

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/CAM%3DNeDhXTo%3Dg3scg7KF8g%3Dn5a4rA%3D6UD5cAxTBn9HetnAO%2BJ-A%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.

Re: [blink-dev] Intent to Ship: Digital Goods API 2.1

2022-04-15 Thread Mike Taylor


On 4/15/22 12:31 AM, Yoav Weiss wrote:
On Mon, Apr 11, 2022 at 4:45 PM Rouslan Solomakhin 
 wrote:



Contact emails

glen...@chromium.org, rous...@chromium.org


Explainer

https://github.com/WICG/digital-goods/blob/main/explainer.md#api-v21


Specification

https://wicg.github.io/digital-goods/


Difference between 2.0 and 2.1




Design docs

https://github.com/WICG/digital-goods/blob/master/explainer.md



https://docs.google.com/document/d/1Jbt2Mzt-xg1cWVlFScBQsoX_pE8Kg1gYpulxUSV8FM0/edit




Summary

We would like to ship a non-breaking addition to the existing
Digital Goods API. This change:

 *

Adds to DigitalGoodsService:

 o

Promise> listPurchaseHistory();

 *

Adds to ItemDetails:

 o

ItemType type;

 o

sequence iconUrls;

 o

unsigned short introductoryPriceCycles;

 *

Adds enum ItemType.


Use of the new methods/fields will require developers to update
supporting code in their apps, such asAndroid Browser Helper
.


Am I correct to assume that if developers don't update their code, 
nothing will break?


AFAICT from reading the spec diff, these changes are purely additive. 
LGTM2 assuming Rouslan can verify our understanding. :)




Blink component

Blink>Payments




Search tags

payments ,
billing 


TAG review

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



TAG review status

TAG continues to think of DGAPI as a “product-specific API within
one company.”

Other 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 at2021 TPAC
(meeting
notes ) and
at a 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

Used in tandem with the Payment Request API.


WebView Application Risks

This API is disabled in WebView.



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.


Flag name

DigitalGoodsV2_1


Requires code in //chrome?

Yes


Tracking bug

https://crbug.com/1250604 


Launch bug

https://crbug.com/1288420 


Estimated milestones

We would like to shi

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

2022-04-13 Thread Mike Taylor

The good news is sites can continue to use max-age to reset the 
expiration 400 days in the future, every time the user visits (assuming 
that's desired behavior), for example in JS:


document.cookie = `lol=ok; max-age=${60 * 60 * 24 * 400}`;

We'll work with DevRel to make sure this is properly documented so there 
are fewer surprises some ~400 days ahead of this landing.


On 4/13/22 11:58 AM, Daniel Bratell wrote:


LGTM3

I am slightly concerned with cookies used daily unexpectedly 
disappearing every 400 days. If there was a way to refresh them when 
used, maybe that would make this smoother for web developers, but that 
is a followup feature. If the metrics show that it is a common scenario.


/Daniel

On 2022-04-13 15:53, Mike West wrote:

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

Re: [blink-dev] Intent to Ship: Media Queries Level 4 Syntax & Evaluation

2022-04-13 Thread Mike Taylor

Bonus LGTM4 (Mike just beat me before I hit send).

On 4/13/22 8:23 AM, Yoav Weiss wrote:

LGTM2

Since the Yandex scripts are metrics scripts, there's little chance 
that their use would result in breakage, and the script is most likely 
doing some sort of "browser fingerprinting" and trying to see if the 
browser is indeed the one it claims to be. As such, I think that the 
risk here is low. It'd still make sense to watch out for incoming 
issues as Daniel suggested.

On Wed, Apr 13, 2022 at 2:17 PM Anders Hartvoll Ruud 
 wrote:

Yoav asked if I could do another HTTP Archive query to look for
sites that hit the counters, contain "not all" and contain at
least one media feature that's known to be unsupported in Chrome.
The idea would be to then look at what those sites do, check if
they break, etc.

Looking at a relevant table in MDN

,
I then queried
for 
r'(inverted\-colors)|(overflow\-block)|(overflow\-inline)|(prefers\-reduced\-data)|(scripting)'.
I found only a single interesting (non-Yandex-metrics) hit, which
was
https://marselshoes.by/assets/js/ym.js?hash=e427de0e11f74a8a57a8 .
The code was obfuscated/minimized, so it was a bit hard to see if
something would break from just reading the code. But at least
nothing appeared to be broken if I tried to shop for shoes with
the feature enabled.

Looking a bit closer today though, I think this is actually the
yandex metrics script as well, under a different name. (ym.js =
"yandex metrics"?). So maybe there are actually zero interesting
results.

Yeah, this is just an older version of 
https://mc.yandex.ru/metrika/tag.js (version: "4uzkmd4e35bv9wjiv", 
instead of "a8mjecangl5v275zywhk", which Yandex is currently serving. 
From what I can tell, (most of?) this script is just creating a 
fingerprint, so I'm less concerned about older versions returning a 
different result.

On Wed, Apr 13, 2022 at 11:59 AM Daniel Bratell
 wrote:

LGTM1, with a careful launch (as usual, but even more so).

The usage counter indicates that the ceiling of breakage is
quite high (in the 0.1% magnitude range) but I believe that
your analysis of is likely accurate and the real amount of
affected sites is likely to be much lower. Furthermore, any
breakage has a fair chance of not affecting a sites functionality.

/Daniel

On 2022-04-12 16:28, 'Joe Medley' via blink-dev wrote:

Please ping me if it ends up being 103. I don't like missing
things in the beta release post.

On Tuesday, April 12, 2022 at 12:23:37 AM UTC-7
and...@chromium.org wrote:

On Mon, Apr 11, 2022 at 7:45 PM Joe Medley
 wrote:

Are you aiming for 102?

That's branching very soon, so definitely not. I'm not
really aiming for any particular release. But if you want
a prediction anyway, then likely 104.

On Monday, April 11, 2022 at 7:17:45 AM UTC-7 Emilio
Cobos Alvarez wrote:

On 4/11/22 15:02, Anders Hartvoll Ruud wrote:
> Ah, I'm not familiar with that way of doing
compat research. What would
> we gain from doing that vs. regular
use-counter + HTTP Archive?
>
> Do we expect those 0.1% to visibly break? (I
guess that depends on
> what they're feature testing for..)
>
>
> I would not expect that at all based on the
HTTP Archive query. If
> testing against "not all" was commonplace, I'd
expect more results
> beyond the two Yandex scripts. Or, perhaps it
is commonplace, but it
> happens mostly on features that actually *are*
supported at the moment.
>
> Just as an example (and to show that "not all"
testing isn't a myth),
> one of the few (non-Yandex-script) sites that
did show up was
> https://ww.sapo.pt , which
does the following:
>
> if(rule.mediaText.includes("not all") || ...)
>
> By the looks of it, it's an early-out related
to the theme switching,
> which prevents the code from amending the query
if prefers-color-scheme
> is not supported. Had we not
supported prefers-color-scheme, then I
> think the worst that

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

2022-04-12 Thread Mike Taylor


LGTM3

On 4/12/22 2:04 AM, Mike West wrote:

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://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 ST

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

2022-04-11 Thread Mike Taylor

LGTM1 % https://github.com/WICG/serial/pull/161 landing.

On 4/11/22 4:58 AM, 'François Beaufort 🇫🇷' via blink-dev wrote:

Contact emails

fbeauf...@google.com

reil...@google.com

Explainer

N/A

Specification

https://github.com/WICG/serial/pull/161

https://wicg.github.io/serial/#forget-method

Summary

Following the recent HIDDevice[1] and USBDevice[2] forget() additions
to the web platform, the SerialPort forget() method allows web
developers to voluntarily revoke a permission to a SerialPort that was
granted by a user.

[1] https://groups.google.com/a/chromium.org/g/blink-dev/c/Fk-IJF63UWc

[2]
https://groups.google.com/a/chromium.org/g/blink-dev/c/pSM2W0TtKEI/

Blink component

Blink>Serial

Motivation

Some sites may not be interested in retaining long-term permissions to
access a serial port. 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 serial port.

constport = awaitnavigator.serial.requestPort();

// Then later... revoke permission to the serial port.

awaitport.forget();

TAG review

Following recent HIDDevice forget() approval [1], a new TAG review
does not seem necessary.

[1] https://github.com/w3ctag/design-reviews/issues/703

TAG review status

N/A

Risks

Interoperability and Compatibility

This small addition to the SerialPort object does not change the
overall status of Serial API 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/serial/issues/132

[1] Both Gecko and WebKit are unlikely to object to this feature
specifically, but object to the overall Serial 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
(Serial API 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/serial though.
I’ll also add manual tests.

Requires code in //chrome?

Yes, permission storage is implemented in //chrome.

Tracking bug

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

Estimated milestones

102

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5145811414417408

--
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/CAPpwU5KJD9m-XjbbYx1_CXHiu_WeLLkeaPGQ%3DxD5usm4yP_b%2BQ%40mail.gmail.com
.

[blink-dev] Intent to Experiment: Network State Partitioning (again)

2022-04-04 Thread Mike Taylor


*


   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 
double-keying (top frame site) vs triple-keying (top frame site and 
frame site).



I’ve omitted all of the information contained in previous intents that 
hasn’t changed. Here’s a link to the last (triple-key) I2E 
.



   Links to previous Intent discussions

Intent 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 



Intent to Ship: 
https://groups.google.com/a/chromium.org/g/blink-dev/c/tJa6uzXu_IA/m/IN6UhwKtAwAJ 




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



   Estimated milestones

We’d like to run at 1% on Stable for ~1 milestone (ideally in M101 or 
perhaps 102 depending the timing of a bug fix 
).



   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/0a0b0cae-5fe5-185d-f164-685e46a5ff3e%40chromium.org.

Re: [blink-dev] Intent to Experiment: Attribution Reporting API

2022-03-31 Thread Mike Taylor


Thanks John. LGTM to experiment in M101-104 inclusive.

On 3/30/22 3:27 PM, John Delaney wrote:

Hi Mike & Yoav,

It would be good to request officials signals from Mozilla and
Apple now to give them plenty of time to respond, should this ship
in the future. See bit.ly/blink-signals <http://bit.ly/blink-signals>.


Thanks for calling this out, I will follow-up to ensure these are 
requested and tracked in our chromestatus.


Was there any feedback from participants?


Yes! Here is one example of some detailed feedback we received on the 
API: https://github.com/WICG/conversion-measurement-api/issues/201


There has been engagement on a number of different issues in our repo 
(https://github.com/WICG/conversion-measurement-api/issues) and in our 
bi-weekly meetings 
(https://github.com/WICG/conversion-measurement-api/tree/main/meetings).


Summarizing a few major points of feedback/gaps while the initial OT 
was ongoing:
The API is difficult to debug/integrate with due to to the delayed 
reporting and coarse data

The ability to register non-clicked ads
Supporting more detailed reporting on conversion side information 
through the aggregate API
How does user-initiated data deletion impact the API? 
https://developer.chrome.com/docs/privacy-sandbox/attribution-reporting-data-clearing/


As noted in the "Goals for experimentation" section above, we have 
addressed a number of these with this iteration of the API.


Will attribution reporting also be disabled if 3rd Party Cookies
are disabled, similar to FLEDGE? (Maybe Topics too?)


Yes.

(Aside: It would be nice to have some boilerplate feature
detection to point devs at for all 3 APIs in this OT)


Agreed, we intend to have detailed developer documentation on this 
prior to the OT starting.


So, is the request here to experiment M101-M104 inclusive?
Can you clarify that last bit? Are you planning to start by
running the OT on the beta channel only? 



We're planning to start in M101 beta. We plan to progress to stable in 
M101 or later, if issues arise, and to continue the origin trial 
through M104, inclusive.


On Wed, Mar 30, 2022 at 5:49 AM Yoav Weiss  wrote:

Thanks for working on this!

On Monday, March 28, 2022 at 8:36:50 PM UTC+2 Mike Taylor wrote:

Hi John,

On 3/25/22 5:49 PM, John Delaney wrote:



Contact emails

johni...@chromium.org <mailto:johni...@chromium.org>,
apaselti...@chromium.org <mailto:apaselti...@chromium.org>,
lin...@chromium.org <mailto:lin...@chromium.org>


Developers interested in the Attribution Reporting API can
also join the attribution-reporting-api-...@chromium.org
<mailto:attributio-reporting-api-...@chromium.org>group for
updates and announcements.


Explainer

https://github.com/WICG/conversion-measurement-api/blob/main/EVENT.md
<https://github.com/WICG/conversion-measurement-api/blob/main/EVENT.md>


https://github.com/WICG/conversion-measurement-api/blob/main/AGGREGATE.md

<https://github.com/WICG/conversion-measurement-api/blob/main/AGGREGATE.md>


https://github.com/WICG/conversion-measurement-api/blob/main/AGGREGATION_SERVICE_TEE.md


Out of scope for this intent, but I'm excited about potential uses
of aggregated reporting for e.g. performance or network error
reporting which are currently not being sent for security or
privacy reasons.




Specification

https://wicg.github.io/conversion-measurement-api/ (WIP)


Summary

This API measures ad conversions (e.g. purchases) and
attributes them to ad interactions without using cross-site
persistent identifiers like third-party cookies.


The API allows measurement through both event-level reports
sent directly from the browser, and aggregatable reports
which can be processed through a trusted service to create
summary reports of attribution data.


An earlier version of this API was in Origin Trial from
Chrome 86 through Chrome 97 which only supported
click-through event-level reports.


Blink component

A-N/A


TAG review

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


TAG review status

Pending


Risks


Interoperability and Compatibility

There are several other different attribution measurement
proposals from a variety of browser vendors

 and companies, each offering different forms
of privacy and utility:


Safari has proposed and implemented Private Click Measurement
<https://github.com/privacycg/private-click-measurement>.

Mozilla has proposed Interoperable Private At

Re: [blink-dev] Intent to Experiment: Attribution Reporting API

2022-03-28 Thread Mike Taylor


Hi John,

On 3/25/22 5:49 PM, John Delaney wrote:



Contact emails

johni...@chromium.org , 
apaselti...@chromium.org , 
lin...@chromium.org 



Developers interested in the Attribution Reporting API can also join 
the attribution-reporting-api-...@chromium.org 
group for updates 
and announcements.



Explainer

https://github.com/WICG/conversion-measurement-api/blob/main/EVENT.md 



https://github.com/WICG/conversion-measurement-api/blob/main/AGGREGATE.md 



https://github.com/WICG/conversion-measurement-api/blob/main/AGGREGATION_SERVICE_TEE.md


Specification

https://wicg.github.io/conversion-measurement-api/ (WIP)


Summary

This API measures ad conversions (e.g. purchases) and attributes them 
to ad interactions without using cross-site persistent identifiers 
like third-party cookies.



The API allows measurement through both event-level reports sent 
directly from the browser, and aggregatable reports which can be 
processed through a trusted service to create summary reports of 
attribution data.



An earlier version of this API was in Origin Trial from Chrome 86 
through Chrome 97 which only supported click-through event-level reports.



Blink component

A-N/A


TAG review

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


TAG review status

Pending


Risks


Interoperability and Compatibility

There are several other different attribution measurement proposals 
from a variety of browser vendors


 and companies, each offering different forms of 
privacy and utility:



Safari has proposed and implemented Private Click Measurement 
.


Mozilla has proposed Interoperable Private Attribution 
.


Microsoft has proposed MaskedLark 
.



For general discussion and feedback see: 
https://github.com/patcg/meetings/tree/main/2022/02/09-telecon



Gecko: No official position, concerns raised in PATCG


WebKit: Negative 
(https://www.w3.org/2019/09/18-ad-privacy-minutes.html 
)


It would be good to request officials signals from Mozilla and Apple now 
to give them plenty of time to respond, should this ship in the future. 
See bit.ly/blink-signals.




Web developers: Engagement in previous origin trial


Was there any feedback from participants?



Ergonomics

N/A


Activation

A successful API flow involves registering multiple events across 
multiple different navigations/


pages. API reports contain either coarse or encrypted information that 
can be difficult to compare directly with cookie-based measurement. 
The current proposal includes a debugging mode to facilitate testing 
and integration.



WebView Application Risks

N/A



Goals for experimentation

For experimentation with the new iteration of the API, we hope to see 
that the measurement data made available through the API provides 
useful ad conversion data for existing use-cases.



Goals specific to this iteration of the API:

 *

We hope to see that support for measuring non-clicked ads in the
API provides better coverage of existing cookie based attribution
measurement solutions, compared to the earlier version of the API.

 *

We hope to see that aggregatable reports complement event-level
reports and support robust reporting of attributions.

 *

We would like to see if the flexibility by the new filtering
mechanisms allows more useful reporting compared to the earlier
version of the API.


Experiment Configuration

The origin trial for this experiment will be shared among various 
Privacy Sandbox APIs. Our goal is to allow for co-ordinated 
experiments to be run by multiple different sites, across multiple 
APIs in one OT.


Will attribution reporting also be disabled if 3rd Party Cookies are 
disabled, similar to FLEDGE? (Maybe Topics too?)


This shared origin trial, Privacy Sandbox Ads APIs, will be a 
third-party origin trial. To ensure that developers can run 
coordinated experiments without concern for exceeding page load usage 
thresholds, this Origin Trial will be available for a subset of users 
by default. Therefore, it will be necessary to feature test to ensure 
that the API surface you want to use is available after providing your 
OT token. A second advantage of this configuration is that different 
experimenters will experiment with the same users, which enables 
coordination for APIs like FLEDGE across third parties.


(Aside: It would be

Re: [blink-dev] Intent to Ship: WebHID exclusionFilters option in requestDevice()

2022-03-26 Thread Mike Taylor

LGTM1

On 3/24/22 11:51 PM, 'François Beaufort 🇫🇷' via blink-dev 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/#dom-hiddevicerequestoptions-exclusionfilters

https://github.com/WICG/webhid/pull/93

Summary

The "exclusionFilters" option in navigator.hid.requestDevice() allows
web developers to exclude some devices from the browser picker. It can
be used to exclude devices that are known to be malfunctioning.

Blink component

Blink>HID

Motivation

Allowing web developers, through the "exclusionFilters" option, to
exclude directly from the browser picker some devices that are known
to not function in a way that suits the site will improve user
experience. Without it, web developers let users pick a device, then
have to check against a custom JavaScript helper function (like
deviceIsBlocklisted()) whether device is known to be malfunctioning
and if that’s the case alert users the device they’ve picked is not
suitable, resulting in a poor user experience.

// Request access to a device with vendor ID 0xABCD. The device must
also have a

// collection with usage page Consumer (0x000C) and usage ID Consumer
Control

// (0x0001). The device with product ID 0x1234 has been reported as
malfunctioning.

constdevices = awaitnavigator.hid.requestDevice({

filters: [{ vendorId: 0xabcd, usagePage: 0x000c, usage: 0x0001}],

exclusionFilters: [{ vendorId: 0xabcd, productId: 0x1234}],

});

TAG review

This small addition to the WebHID API doesn’t seem to qualify for a
TAG review. I’m happy to file one if desired though.

TAG review status

Not Applicable

Risks

Interoperability and Compatibility

This small addition to the HIDDeviceRequestOptions dictionary 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/92

Other signals: Google Meet folks have asked for this addition and
strongly support this.

[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 browser picker implementation is implemented outside of
Blink and so isn’t testable by web-platform-tests.

Manual tests should be possible, right?

Requires code in //chrome?

Yes, browser picker implementation lives in //chrome.

Tracking bug

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

Estimated milestones

102

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5194022623641600

--
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/CAPpwU5JYJCYBgmg9Kr6G%2Bt7yH5iU_X_3QJhO-_8rk%3DjYW%2BLsYQ%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/e4daadc6-5574-32a5-ba00-

Re: [blink-dev] Re: Intent to Deprecate and Freeze: The User-Agent string

2022-03-24 Thread Mike Taylor


Hi James,

We are committed to achieving the purpose of the Privacy Sandbox 
commitments accepted by the CMA 
 
in February 2022. We encourage feedback on how to better achieve that 
purpose through our technical proposals, and we will report publicly on 
feedback we receive as set out in the commitments. We are in constant 
dialogue with the CMA on these issues, and members of the web ecosystem 
are also welcome to discuss these issues with the CMA. We therefore hope 
that everyone will understand when we decline to participate in public 
discussions on legal or internal aspects of compliance with the 
commitments, or to detail our direct exchanges with the CMA.


thanks,
Mike

On 3/17/22 10:53 AM, 'James Rosewell' via blink-dev wrote:


Google and CMA reached an agreement on 4th February 2022 concerning 
Privacy Sandbox and Topics. The agreement requires Google to train 
staff in Annex 3 
, 
and paragraph 4.119 
 
states, /“Google has committed to instruct its staff and agents not to 
make claims to other market players that contradict the commitments, 
and to provide training to its relevant staff and agents to ensure 
that they are aware of the requirements of the Final Commitments”/.


Paragraph 21 of the agreement states /“During the standstill period, 
the CMA may notify Google that competition law concerns remain such 
that the Purpose of the Commitments will not be achieved. Google will 
work with the CMA without delay to seek to resolve concerns raised and 
address comments made by the CMA with a view to achieving the Purpose 
of the Commitments. Google will inform the CMA of how it has responded 
to those comments”/.


The standstill period is defined in the agreement as is User-Agent 
reduction.


Will Google representatives confirm they have approval from the CMA to 
progress this proposal? If not then please can they confirm that the 
proposal is now delayed until such approval is provided?


On Tuesday, 14 January 2020 at 11:22:00 UTC yo...@yoav.ws wrote:

Contact emails

yoav...@chromium.org, aaro...@chromium.org


Summary

We want to freeze and unify(but not remove) the User Agent string
in HTTP requests as well as in `navigator.userAgent`


Motivation

The User-Agent string is an abundant source of passive
fingerprinting information about our users. It contains many
details about the user’s browser and device as well as many lies
("Mozilla/5.0", anyone?) that were or are needed for compatibility
purposes, as servers grew reliant on bad User Agent sniffing.


On top of those privacy issues, User-Agent sniffing is an abundant
source of compatibility issues, in particular for minority
browsers, resulting in browsers lying about themselves (generally

or
to specific sites

),
and sites (including Google properties) being broken

in
some browsers for no good reason.


The above abuse makes it desirable to freeze the UA string and
replace it with a better mechanism. There have been past attempts
at UA string freezing from the Safari team, but without an
alternative way to perform UA based content-negotiation, they had
to be partially reverted.

The User Agent Client Hints
(UA-CH) feature provides
an alternate source for the information the User-Agent string
provides, both in its request header form as well as its JS API one.

Its main advantages are:

 *

It provides the required information only when the server
requests it, over secure connections, making any
fingerprinting that relies on it be active fingerprinting,
which enables such use to be audited, as well as acted-upon by
the browser (e.g. in a future implementation of the Privacy
Budget ).

 *

It provides the information in small increments, so servers
are only exposed to the information they need and request,
rather than being exposed to the full gamut of the UA string
even if they are just trying to figure out one detail about
the browser. (e.g. brand and major version)

 *

Since it provides the information via dedicated fields, it
enables better ergonomics and makes it less likely for

Re: [blink-dev] Intent to Ship: hidden=until-found HTML attribute and beforematch event

2022-03-22 Thread Mike Taylor


LGTM1

On 3/17/22 3:10 PM, Joey Arhar wrote:



Contact emails

jar...@chromium.org


Explainer

https://github.com/WICG/display-locking/blob/master/explainers/hidden-content-explainer.md


Specification

https://github.com/whatwg/html/pull/7475


Design docs

https://github.com/WICG/display-locking/blob/master/explainers/hidden-content-explainer.md


Summary

This feature extends the existing hidden attribute with a new value, 
"until-found", which makes the element searchable by find-in-page, 
scroll to text fragment, and fragment navigation. When these 
search/navigation features want to scroll to something inside a 
hidden=until-found element, the browser removes the hidden attribute 
from the element and fires the "beforematch" event on it so that the 
newly revealed content can be scrolled into view.




Blink component

Blink>HTML 




TAG review

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


TAG review status

Issues addressed


Risks



Interoperability and Compatibility

Interoperability risks: This feature is built on content-visibility, 
which is gradually being implemented in other browsers. The way this 
feature extends the existing hidden attribute means that browsers 
which don't implement this feature will still render 
hidden=until-found content as expected, but without the new 
find-in-page and ScrollToTextFragment auto-revealing functionality. 
Mozilla says this feature is worth prototyping. Compatibility risks: 
This feature is unlikely to break existing websites because they must 
opt-in by setting the "hidden" attributes on elements to 
"until-found". In the unlikely event that existing websites use 
hidden=until-found, it will just replace their "display:none" with 
"content-visibility:hidden" which will likely render the same.




Gecko: Worth prototyping 
(https://github.com/mozilla/standards-positions/issues/612)


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


Web developers: No signals

Other signals:


Ergonomics

This feature can be used in tandem with scroll to text fragments. This 
feature will not make it hard for Chrome to maintain good performance.




Activation

This feature will benefit from having example code in the explainer 
repo to show developers how to use it.




Security

What the user types into the find-in-page box should not be visible to 
websites, and the beforematch event is a new way for websites to try 
to read this information on top of the existing scroll events. I 
created a privacy mitigation for all of these attack surfaces for 
find-in-page by adding a delay before find-in-page scrolls text into 
view when needed so websites are unlikely to be able to incrementally 
build what the user is typing into find-in-page.




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

There are no DevTools features for the scrolling, URL fragment, and 
event firing impacts that beforematch has.




Is this feature fully tested by web-platform-tests

?

The find-in-page portion of this feature can't be tested because 
find-in-page can't be tested in WPT yet: 
https://github.com/web-platform-tests/wpt/issues/29915
Here are some tests which I will try to move to WPT soon: 
https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/wpt_internal/display-lock/beforematch/


Please do. :)

Here are WPTs for the hidden IDL changes to allow "until-found": 
https://github.com/web-platform-tests/wpt/pull/32465



Flag name

--enable-blink-features=BeforeMatchEvent


Requires code in //chrome?

False


Tracking bug

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


Launch bug

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


Estimated milestones

102



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5400510406328320


Links to previous Intent discussions

Intent to prototype: 
https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/beforematch%7Csort:date/blink-dev/QKUZ_ALJdM8/j6daEdmUAgAJ
Intent to Experiment: 
https://groups.google.com/a/chromium.org/d/msg/blink-dev/aTrk7__Eiq4/BOGSzGHeAwAJ



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

Re: [blink-dev] Intent to Ship: Convert adoptedStyleSheets to use ObservableArray

2022-03-21 Thread Mike Taylor

Your site isn't using adoptedStyleSheets, so it seems unlikely. But we 
can continue conversation in the bug.


On 3/21/22 10:51 PM, 3D PRINTERS ONLINE STORE LTD wrote:
Possibly this change affects our website slider gallery images 
breaking on page load.


Please check this open bug : 
https://bugs.chromium.org/p/chromium/issues/detail?id=1291437


On Friday, December 24, 2021 at 12:11:57 PM UTC+5:30 
mas...@chromium.org wrote:


Right, M99. Thanks Yuki, and sorry for the delay.


On Thu, Dec 23, 2021 at 4:35 AM Yuki Shiino
 wrote:

2021年12月22日(水) 5:03 'Joe Medley' via blink-dev
:

Is this on 98?


No, not in M98.


https://storage.googleapis.com/chromium-find-releases-static/e5b.html#e5b482aff3e9e0031527108c7131861ed2640dcc
says
"Commit e5b482af... initially landed in 99.0.4761.0"
so, I think this is in M99.



On Tuesday, December 14, 2021 at 10:13:18 AM UTC-8
mas...@chromium.org wrote:

Thanks everyone!

On Tue, Dec 14, 2021 at 9:59 AM Yoav Weiss
 wrote:

LGTM3

On Tue, Dec 14, 2021 at 4:12 PM Mike Taylor
 wrote:

LGTM2

On 12/14/21 10:05 AM, Camille Lamy wrote:

Thanks Mason! I wasn't sure if it was
possible to share it cross-origin, hence my
question. If you can only get a non-shared
copied version, then this is fine from a
security POV.

On Tuesday, December 14, 2021 at 4:53:52 AM
UTC+1 Mason Freed wrote:

Thanks Alex! I did file a TAG review for
ObservableArray and this first use by
adoptedStyleSheets

<https://github.com/w3ctag/design-reviews/issues/693>.
No response yet.

On Mon, Dec 13, 2021 at 4:03 PM Alex
Russell  wrote:

Thanks Mason, that matches my
understanding of the situation too.

Can you please file an FYI with the
TAG to let them know this new type is
being put into use? It is often
helpful for them to stay informed of
new WebIDL primitives that they can
suggest to others to help drive
consistency.

Sending LGTM1 in the tool.

On Wednesday, December 8, 2021 at
3:49:55 PM UTC-8 Mason Freed wrote:

Hi Camille,

Thanks for the question. I guess
I have two points/questions:
1. That sounds like a general
question about adoptedStyleSheets
(which we shipped a few years
ago), and isn't at all particular
to the conversion from
FrozenArray to ObservableArray.
But did I miss something relevant
about this change?
2. Can you help me understand how
you'd go about sharing a single
CSSStyleSheet between
cross-origin documents? If you
passed it around via postMessage,
it'd be a (structured clone)
copy, so it would no longer be
shared. I agree that it'd be a
(huge) privacy concern if this
were possible, but I don't see
how it could be done. I'm sure
I'm missing something - perhaps
give me more specifics and I'm
happy to dig further.

Thanks,
Mason


On Tue, Dec 7, 2021 at 8:04 AM
Camille Lamy 
wrote:

H

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

2022-03-21 Thread Mike Taylor


LGTM2

On 3/21/22 8:12 AM, Mike West wrote:

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

Re: [blink-dev] Re: Intent to Ship: MediaCapabilities API for WebRTC

2022-03-16 Thread Mike Taylor


LGTM3

On 3/16/22 9:30 AM, mkwst via Chromestatus wrote:
LGTM2, but I'd second Yoav's request to pay attention to the 
discussion around fingerprinting. My understanding is that we're going 
to be bucketing things in our implementation so as to reduce the total 
surface exposed via different configurations. That feels like a 
reasonable place to start, but given the heterogeneity of devices upon 
which Chrome runs, it might not be the last thing we need to do as a 
mitigation.

--
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/b55afd05da55ead9%40google.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/58c249e1-ef93-249a-3e45-9c9e1ec3c9e1%40chromium.org.

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

2022-03-15 Thread Mike Taylor


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
<https://github.com/w3c/secure-payment-confirmation/blob/main/explainer.md>


Specification

https://w3c.github.io/secure-payment-confirmation/
<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
<https://github.com/w3c/secure-payment-confirmation/issues/164>).
This is a breaking change, see issue and compatibility section.

 *

Add an optional boolean to allow failed instrument icon
download (issue
<https://github.com/w3c/secure-payment-confirmation/issues/125>).

 *

Add payeeName as an optional input (issue
<https://github.com/w3c/secure-payment-confirmation/issues/163>).


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

<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EPayments>


TAG review

https://github.com/w3ctag/design-reviews/issues/675
<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
todaywithout 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
<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
<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
<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

<https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>?

Yes, coverage for the new input fields will be added to the
existing test suite:


https://wpt.fyi/results/secure-payment-confirmation?label=master&label=experimental&align

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

2022-03-15 Thread Mike Taylor


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





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&label=experimental&aligned 




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



Tracking bug

API V3 bug: https://crbug.com/1298505 

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/feature/5675682238562304 




Links to previous Intent discussions

Intent to Prototype v1: 
https://groups.google.com/a/chromium.org/d/topic/blink-dev/myUR5gyd5Js/discussion

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

2022-03-15 Thread Mike Taylor

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.

Re: [blink-dev] Intent to Ship: MediaCapabilities API for WebRTC

2022-03-14 Thread Mike Taylor


On 3/14/22 1:30 PM, 'Johannes Kron' via blink-dev wrote:



Contact emails

k...@google.com


Explainer

https://github.com/drkron/media-capabilities/blob/webrtc_examples/explainer.md#webrtc
https://github.com/w3c/media-capabilities/pull/191


Specification

https://w3c.github.io/media-capabilities/


Summary

Extends the MediaCapabilities API to support WebRTC streams. The 
MediaCapabilities API helps websites to make informed decisions on 
what codec, resolution, etc. to use for video playback by providing 
information about whether a configuration is supported and also 
whether the playback is expected to be smooth. This feature extends 
the MediaCapabilities API to also include WebRTC streams.




Blink component

Blink>Media>Capabilities 




TAG review

This is a straightforward extension of an existing API.


TAG review status

Not applicable


Risks



Interoperability and Compatibility



Gecko: Positive (https://www.w3.org/2011/04/webrtc/wiki/December_02_2020)


Could you please request a more formal position at 
https://github.com/mozilla/standards-positions?




WebKit: Shipped/Shipping 
(https://webkit.org/blog/12033/release-notes-for-safari-technology-preview-134/)


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?


No.



Debuggability

N/A



Is this feature fully tested by web-platform-tests

?

Yes


Flag name

MediaCapabilitiesWebRtc


Requires code in //chrome?

False


Tracking bug

https://crbug.com/1187565


Launch bug

https://crbug.com/1170306


Measurement

Two UseCounters have been added: 
WebFeature::kMediaCapabilitiesDecodingInfoWebrtc and 
WebFeature::kMediaCapabilitiesEncodingInfoWebrtc. See 
https://chromium-review.googlesource.com/c/chromium/src/+/3494617



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

No milestones specified



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6242376685191168


Links to previous Intent discussions

Intent to prototype: 
https://groups.google.com/a/chromium.org/g/blink-dev/c/lE1qySPAEMs/m/29OgzgyoAgAJ
Intent to Experiment: 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFJBoCR3marbZsVSOmeimizJY9Q%3DbTp0PCfaNawn3XZuXkmvNA%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/CAFJBoCT2deSuxdos%2BLX6_ZEwfsRngPhsELwRGCm%3DrXYgv4RH%3DQ%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/a2cef7fa-8359-4dd7-19e9-c4f284746c42%40chromium.org.

Re: [blink-dev] Intent to Extend Experiment: Declarative Link Capturing for PWAs

2022-03-14 Thread Mike Taylor


Yoav's reasoning sounds good to me. LGTM2.

On 3/14/22 3:50 AM, Yoav Weiss wrote:

Hey Alan,

As this is an exceptional request, I believe this requires 3 LGTMs.

The risk present here is that we'd be creating some breakage risk from 
terminating the OT ~3 months down the line. Weighing this risk 
compared to the inherent OT risk we're already exposed to, it doesn't 
seem like the 3 months extension would significantly increase it. The 
fact that the main users for this are in the education sector makes me 
speculate that an extension would reduce breakage risk, as many of 
those are likely to be on their (north hemisphere) summer break.


Therefore, I believe an extension is reasonable.

*LGTM1*

On Mon, Mar 14, 2022 at 5:20 AM Alan Cutter  
wrote:


Amendment: The lag of M97 clients for this API is predominately
seen in education rather than enterprise.

On Monday, 14 March 2022 at 1:24:26 pm UTC+11 Alan Cutter wrote:

Request to extend the M97 end date for this origin trial from
2022-03-31 by 3 months to 2022-06-30.
There are still clients running M97 (especially in enterprise
environments) that can't yet make use of the replacement
launch_handler API

 
(added
in M98). Our analysis suggest an additional 3 months is
sufficient for them to transition over smoothly.

API burn in risk: Low; the DLC API trial was removed in M98
and cannot be revived, its full removal is guaranteed as a
matter of time based on client populations updating to M98+.

On Friday, 19 November 2021 at 9:27:30 am UTC+11 Alan Cutter
wrote:

Brilliant, thanks!

On Friday, 19 November 2021 at 7:20:10 am UTC+11 Alex
Russell wrote:

API OWNERS just discussed, and we also decided that
this intent only needs a single vote (rather than 3).
You're good to go!

On Thursday, November 18, 2021 at 12:17:02 PM UTC-8
Alex Russell wrote:

LGTM1

On Wednesday, November 17, 2021 at 10:25:06 PM
UTC-8 Alan Cutter wrote:

Friendly ping.

On Thursday, 11 November 2021 at 7:11:49 pm
UTC+11 Alan Cutter wrote:

Request to extend M97 experiment end date
to avoid breaking sites while
transitioning to the new launch_handler

API.

 - The launch_handler experiment has been
approved

for
M97-M102 but due to implementation issues
will start in M98.

 - To allow clients to migrate over to
launch_handler

seamlessly
we need to keep the DLC behavior available
until existing users have had a chance to
update to M98.

 - To cover the February M98 Chrome OS
rollout this extension request is to go up
to 2022-03-31 (assuming ~1 month to roll
out to a majority of users).

 - To avoid burn-in risk we will remove
DLC from M98. This is the samestrategy

that
the Digital Goods API experiment took for
their v2 migration.

Previous experiment timeline

:
M90 to M93 Approved extension timeline

:
M94 to M97 Requested extension timeline:
Up to 2022-03-31 but only for M97 browsers
and earlier.


On Friday, 27 August 2021 at 4:45:25 pm
UTC+10 Yoav Weiss wrote:

On Thu, Aug 26, 2021 at 11:33 PM Jason
Chase  wrote:



On Thu, 26 Aug 2021 at 14:32, Yoav
Weiss  wrote:

Re: [blink-dev] Intent to Implement and Ship: CSS Values Level 4 Calc Simplification and Serialization

2022-03-09 Thread Mike Taylor


Thanks. LGTM1

(Aside: Are these are the right WPTs 
<https://wpt.fyi/results/css/css-values?label=master&label=experimental&aligned&q=serialization>? 
I'm excited for them to all be green if so).


On 3/9/22 6:14 PM, 박중헌 wrote:

Ok, I updated the links below and the chrome status entry.


Contact emails


pjh0...@gmail.com, jh718.p...@samsung.com


Explainer


None


Specification


https://drafts.csswg.org/css-values-4/#calc-simplification,
https://drafts.csswg.org/css-values-4/#calc-serialize


Summary


CSS math functions are simplified and serialized per spec. CSS
calc simplification is a kind of constant folding which
evaluates css calculation tree to the extent possible at parse
time, so that evaluation at computed/used-value time can be
reduced. The simplified result is serialized according to spec.



Blink component


Blink
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink>


Search tags


css <https://chromestatus.com/features#tags:css>,
simplification
<https://chromestatus.com/features#tags:simplification>,
serialization
<https://chromestatus.com/features#tags:serialization>


TAG review


None


TAG review status


Not applicable


Risks




Interoperability and Compatibility




Gecko: Shipped/Shipping
(https://phabricator.services.mozilla.com/D61739)

WebKit: Shipped/Shipping
(https://bugs.webkit.org/show_bug.cgi?id=203442)

Web developers: No signals


Ergonomics


None



Activation


None



Security


None



Debuggability


N/A



Is this feature fully tested by web-platform-tests

<https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>?


Yes




Requires code in //chrome?


False


Tracking bug


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



Link to entry on the Chrome Platform Status


https://chromestatus.com/feature/5730414630010880

This intent message was generated by Chrome Platform Status
<https://chromestatus.com/>.


2022년 3월 10일 (목) 오전 2:02, Mike Taylor 님이 
작성:


On 3/9/22 11:00 AM, 박중헌 wrote:



Contact emails


pjh0...@gmail.com, jh718.p...@samsung.com


Explainer


None


Specification


https://drafts.csswg.org/css-values-4/#calc-simplification,
https://drafts.csswg.org/css-values-4/#calc-serialize


Summary


CSS math functions are simplified and serialized per
spec. CSS calc simplification is a kind of constant
folding which evaluates css calculation tree to the
extent possible at parse time, so that evaluation at
computed/used-value time can be reduced. The simplified
result is serialized according to spec.



Blink component


Blink
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink>


Search tags


css <https://chromestatus.com/features#tags:css>,
simplification
<https://chromestatus.com/features#tags:simplification>,
serialization
<https://chromestatus.com/features#tags:serialization>


TAG review


None


TAG review status


Not applicable


Risks




Interoperability and Compatibility




Gecko: Shipped/Shipping

WebKit: Shipped/Shipping

Web developers: No signals


Could you provide some links to bugs where these shipped?





Ergonomics


None



Activation


None



Security


None



Debuggability


N/A



Is this feature fully tested by web-platform-tests

<https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>?


Yes




Requires code in //chrome?


False


Tracking bug


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



Link to entry on the Chrome Platform Status


https://chromestatus.com/feature/5730414630010880

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 unsubscribe from this group and stop receiving emails from it,
sen

Re: [blink-dev] Intent to Implement and Ship: CSS Values Level 4 Calc Simplification and Serialization

2022-03-09 Thread Mike Taylor


On 3/9/22 11:00 AM, 박중헌 wrote:



Contact emails


pjh0...@gmail.com, jh718.p...@samsung.com


Explainer


None


Specification


https://drafts.csswg.org/css-values-4/#calc-simplification,
https://drafts.csswg.org/css-values-4/#calc-serialize


Summary


CSS math functions are simplified and serialized per spec. CSS
calc simplification is a kind of constant folding which
evaluates css calculation tree to the extent possible at parse
time, so that evaluation at computed/used-value time can be
reduced. The simplified result is serialized according to spec.



Blink component


Blink



Search tags


css ,
simplification
,
serialization



TAG review


None


TAG review status


Not applicable


Risks




Interoperability and Compatibility




Gecko: Shipped/Shipping

WebKit: Shipped/Shipping

Web developers: No signals


Could you provide some links to bugs where these shipped?





Ergonomics


None



Activation


None



Security


None



Debuggability


N/A



Is this feature fully tested by web-platform-tests

?


Yes




Requires code in //chrome?


False


Tracking bug


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



Link to entry on the Chrome Platform Status


https://chromestatus.com/feature/5730414630010880

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/CAEmFqRckRAY%3DhvUSp08jV7ZBRinZ2XDfS3UN_9EewQjQh8T_eQ%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/8c67fb8f-262f-592c-2cd4-219997960953%40chromium.org.

Re: [blink-dev] Intent to Ship: Block external protocol in sandboxed iframe.

2022-03-07 Thread Mike Taylor

On 3/7/22 10:37 AM, Arthur Sonzogni wrote:

On Monday, March 7, 2022 at 3:47:11 PM UTC+1 Mike Taylor wrote:

On 3/7/22 8:45 AM, Yoav Weiss wrote:

On Mon, Mar 7, 2022 at 2:35 PM Arthur Sonzogni
wrote:

We contacted several websites. Some confirmed they
will be positively impacted.

Microsoft Teams, the #1 requested adding
"allow-top-navigation-to-custom-scheme" to opt-out
from this feature individually.

It's reassuring to hear they'd be willing to use an opt-out.
Have you reached out to others on that list? It seems
like tackling the top ~3 would significantly reduce the risk.

I confirm I sent an email for every website we see: the top 8
on Windows and a few others on Android. I asked them to
confirm reception.

Thanks - looking at the list, some of them seem to have obvious
"open a native app" use-cases, like Microsoft Teams. Others... not
so obvious.

If the primary motivation is to break malicious ads, would it make
sense to further require a secure context for the sandboxed
iframe? (Maybe this question is nonsense, I'm not a security
expert). Do we know what the breakdown is between http/non-secure
and https/secure for iframes causing these kinds of external app
navigations?

Yes, this is probably worth doing. However, this would be a different
topic, spec & impacted users. I think this would be more of an
additional project, and ideally we would do both if possible.

There are no metrics about security/non-secure context that I am aware of.
OK, thanks for confirming (not trying to blow up your scope in this
intent, I promise).

Please make sure you use CountDeprecation

<https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/platform/instrumentation/use_counter.h;l=45?q=Deprecation%20UseCounter&ss=chromium>,
to get deprecation reports sent automatically. (unless
there are particular technical reasons that make this
more complex than it should be. If that's the case, let's
discuss more)

This can't only be used in blink unfortunately. This is about
navigation, and happens when we are out of handlers, before
calling external applications. I can't make use of
CountDeprecation here. It is not impossible to create new
IPCs and get it plumbed to the renderer process, but that's
probably more complex than what it deserves.

That's probably true when considering only this particular
intent, but might be worthwhile to create the infra to enable
this as this seems to be a recurrent pattern.

Agree it sounds like a useful tool to have down the road. I can't
speak for Yoav, but can we at least get a bug on file with enough
context for someone else to pick up?

That's the reasonable thing to do. Here is the bug:
https://bugs.chromium.org/p/chromium/issues/detail?id=1303603

Thanks, LGTM2.

--
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/82e3afc3-05c0-087b-61a8-98161d1cc98c%40chromium.org.

Re: [blink-dev] Intent to Ship: Block external protocol in sandboxed iframe.

2022-03-07 Thread Mike Taylor

On 3/7/22 8:45 AM, Yoav Weiss wrote:
On Mon, Mar 7, 2022 at 2:35 PM Arthur Sonzogni
wrote:

We contacted several websites. Some confirmed they will be
positively impacted.

Microsoft Teams, the #1 requested adding
"allow-top-navigation-to-custom-scheme" to opt-out from
this feature individually.

It's reassuring to hear they'd be willing to use an opt-out.
Have you reached out to others on that list? It seems like
tackling the top ~3 would significantly reduce the risk.

I confirm I sent an email for every website we see: the top 8 on
Windows and a few others on Android. I asked them to confirm
reception.

Thanks - looking at the list, some of them seem to have obvious "open a
native app" use-cases, like Microsoft Teams. Others... not so obvious.

If the primary motivation is to break malicious ads, would it make sense
to further require a secure context for the sandboxed iframe? (Maybe
this question is nonsense, I'm not a security expert). Do we know what
the breakdown is between http/non-secure and https/secure for iframes
causing these kinds of external app navigations?

Please make sure you use CountDeprecation

,
to get deprecation reports sent automatically. (unless there
are particular technical reasons that make this more complex
than it should be. If that's the case, let's discuss more)

This can't only be used in blink unfortunately. This is about
navigation, and happens when we are out of handlers, before
calling external applications. I can't make use of
CountDeprecation here. It is not impossible to create new IPCs and
get it plumbed to the renderer process, but that's probably more
complex than what it deserves.

That's probably true when considering only this particular intent, but
might be worthwhile to create the infra to enable this as this seems
to be a recurrent pattern.

Agree it sounds like a useful tool to have down the road. I can't speak
for Yoav, but can we at least get a bug on file with enough context for
someone else to pick up?

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/9a992e16-70c1-ab4f-1eb4-9a3978ef81cd%40chromium.org.

Re: [blink-dev] Re: Intent to Ship: Priority Hints

2022-03-04 Thread Mike Taylor

Thanks - agree we don't need to block here, but glad to see it's on your
radar as a future improvement.

LGTM2.

On 3/4/22 5:39 PM, Patrick Meenan wrote:
Here's the crbug for the priority property on Request if you'd like to
follow along: https://crbug.com/1301942

The only use case that comes to mind is for a service worker to behave
differently based on the requested priority (though if the same
resource is requested multiple times on the page they will only see
the first one so I'm not sure it's much help even in that case since
priority changes aren't plumbed through worker callbacks).

On Fri, Mar 4, 2022 at 5:35 PM Patrick Meenan
wrote:

I'm plumbing the support for the read-only priority property on
Request now.

It's a fair bit more complicated than I had hoped and requires
plumbing through to net and the internal urlrequest but I'm making
good progress.

I don't think we want to hold shipping on that though. It's a
nice-to-have addition but isn't needed for the vast majority of
use cases.

On Fri, Mar 4, 2022 at 5:25 PM Mike Taylor
wrote:

This seems genuinely useful, thanks for working on it.

What's the current thinking on exposing `priority` on Request,
i.e.
https://github.com/WICG/priority-hints/issues/11#issuecomment-396610469?

On 3/3/22 4:54 PM, Addy Osmani wrote:

> Priority Hints introduces a developer-set "fetchpriority"
HTML attribute and "priority" fetch property allowing
developers to influence the computed priority of a resource
fetch. Supported priority values are auto, low, and high.
Non-owner LGTM. Thanks once again for all of your work taking
this feature through a reboot, Pat! The adjustment in
attribute name adds some needed clarity to the expected
behavior for web developers. I would be excited to see this
feature ship.

On Thursday, March 3, 2022 at 10:20:40 AM UTC-8 Patrick
Meenan wrote:

Contact emails

ad...@chromium.org, kenjibah...@chromium.org,
pmee...@chromium.org

Explainer

https://github.com/WICG/priority-hints/blob/main/EXPLAINER.md

Specification

https://wicg.github.io/priority-hints/

Summary

Priority Hints provide developers a way to indicate a
resource's relative fetch priority to the browser,
allowing more control over the order resources are
loaded. Many factors influence a resource's priority in
browsers. These include type, visibility, and preload
status of a resource. Priority Hints introduces a
developer-set "fetchpriority" HTML attribute and
"priority" fetch property allowing developers to
influence the computed priority of a resource fetch.
Supported priority values are auto, low, and high.

By far, the biggest win during Origin Trials was for
sites to be able to tag important images as high-priority
so they could be fetched earlier without having to wait
for layout (leading to substantial improvements in LCP).
Details are in the linked OT feedback summary.

The only change during the spec process was a name change
of the HTML/fetch attributes from "importance" to
"fetchpriority" and "priority".

Web-dev article: https://web.dev/priority-hints/

Blink component

Blink>Loader

<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ELoader>

Search tags

priority-hints
<https://chromestatus.com/features#tags:priority-hints>,
priority hints
<https://chromestatus.com/features#tags:priority%20hints>

TAG review

https://github.com/w3ctag/des ign-reviews/issues/704
<https://github.com/w3ctag/design-reviews/issues/704>

TAG review status

Issues addressed

Link to origin trial feedback summary

https://docs.google.com/document/d/162dym7j0PbpoMvle58gO9DDqpQFOvvmqwu1OIJ1IEzQ/edit?usp=sharing

Risks

Interoperability and Compatibility

Gecko: worth prototyping
<https://mozilla.github.io/standards-positions/#priority-hints>
WebKit: No signal

<https://www.mail-archive.com/webkit-dev@lists.webkit.org/msg30357.html>
Web developers: Strongly positive

<https://docs.google.com/document/d

Re: [blink-dev] Re: Intent to Ship: Priority Hints

2022-03-04 Thread Mike Taylor

This seems genuinely useful, thanks for working on it.

What's the current thinking on exposing `priority` on Request, i.e.
https://github.com/WICG/priority-hints/issues/11#issuecomment-396610469?

On 3/3/22 4:54 PM, Addy Osmani wrote:
> Priority Hints introduces a developer-set "fetchpriority" HTML
attribute and "priority" fetch property allowing developers to
influence the computed priority of a resource fetch. Supported
priority values are auto, low, and high.
Non-owner LGTM. Thanks once again for all of your work taking this
feature through a reboot, Pat! The adjustment in attribute name adds
some needed clarity to the expected behavior for web developers. I
would be excited to see this feature ship.

On Thursday, March 3, 2022 at 10:20:40 AM UTC-8 Patrick Meenan wrote:

Contact emails

ad...@chromium.org, kenjibah...@chromium.org
, pmee...@chromium.org

Explainer

https://github.com/WICG/priority-hints/blob/main/EXPLAINER.md

Specification

https://wicg.github.io/priority-hints/

Summary

Priority Hints provide developers a way to indicate a resource's
relative fetch priority to the browser, allowing more control over
the order resources are loaded. Many factors influence a
resource's priority in browsers. These include type, visibility,
and preload status of a resource. Priority Hints introduces a
developer-set "fetchpriority" HTML attribute and "priority" fetch
property allowing developers to influence the computed priority of
a resource fetch. Supported priority values are auto, low, and high.

By far, the biggest win during Origin Trials was for sites to be
able to tag important images as high-priority so they could be
fetched earlier without having to wait for layout (leading to
substantial improvements in LCP). Details are in the linked OT
feedback summary.

The only change during the spec process was a name change of the
HTML/fetch attributes from "importance" to "fetchpriority" and
"priority".

Web-dev article: https://web.dev/priority-hints/

Blink component

Blink>Loader

Search tags

priority-hints
, priority
hints

TAG review

https://github.com/w3ctag/des ign-reviews/issues/704

TAG review status

Issues addressed

Link to origin trial feedback summary

https://docs.google.com/document/d/162dym7j0PbpoMvle58gO9DDqpQFOvvmqwu1OIJ1IEzQ/edit?usp=sharing

Risks

Interoperability and Compatibility

Gecko: worth prototyping

WebKit: No signal

Web developers: Strongly positive

Other signals:

Debuggability

Resource fetch priority is exposed in dev tools as part of the
network panel, in the netlog, in traces and in tools like
WebPageTest.

Is this feature fully tested by web-platform-tests

Yes

Flag name

Experimental Runtime Feature Flag: PriorityHints
Origin Trial: PriorityHintsAPI

Requires code in //chrome?

False

Tracking bug

https://crbug.com/821464

Estimated milestones

OriginTrial desktop last99
OriginTrial desktop first 96

OriginTrial android last99
OriginTrial android first 96

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5273474901737472

Links to previous Intent discussions

Intent to Experiment:
https://groups.google.com/a/chromium.org/g/blink-dev/c/CkRq2zY-t6c

This intent message was generated by Chrome Platform Status
.

Re: [blink-dev] Intent to Ship: Make 'true' a truthy value for window.open boolean features

2022-03-04 Thread Mike Taylor

LGTM3 - if anything I would expect things to unbreak (might be
interesting to look at histograms for the number of popups opened before
and after).

On 3/4/22 10:27 AM, Rick Byers wrote:

Make true truthy, who could object to that? :-) LGTM2

Seriously though, I agree on the sentiment of the low compat risk.
This feels arguably bugfix-level to me. But I agree with Daniel that
stranger things have happened in the world of web compat, so as always
please keep an ear open for any regressions and revert / measure at
the sign of any issues.

Rick

On Fri, Mar 4, 2022 at 9:46 AM Daniel Bratell wrote:

LGTM1.

The feedback from Mozilla and WebKit is not of the 100% official
kind, but I agree that this is a small enough change to not
request more formal feedback than the feedback that already is there.

(Also, "exceedingly unlikely", if I've learned anything about the
web, it is that there is nothing that is too strange to exist on it).

/Daniel

On 2022-03-03 22:23, Mason Freed wrote:

Contact emails

mas...@chromium.org

Explainer

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

Specification

https://github.com/whatwg/html/pull/7425

Summary

This is a recent change [1] to the spec for parsing the
windowFeatures argument to window.open(). Previous to this
change, window.open(url,'','popup=true') interpreted the
'popup=true' to mean popup is false. With this change, 'true'
counts as a truthy value. [1]
https://github.com/whatwg/html/pull/7425

Blink component

Blink

Search tags

window.open ,
windowFeatures

TAG review

Extremely small change, and this was peripherally discussed on
the TAG review for the recent addition of the popup
windowFeature: https://github.com/w3ctag/design-reviews/issues/691

TAG review status

Not applicable

Risks

Interoperability and Compatibility

It is possible, though extremely unlikely, that a site currently
uses `window.open(url,'','feature=true')` and expects feature to
be false. In that case, this change will change behavior.
However, this seems exceedingly unlikely.

Gecko: In development
(https://github.com/whatwg/html/pull/7425#issuecomment-1058350502)

WebKit: Positive
(https://github.com/whatwg/html/issues/7399#issuecomment-989971808)

Web developers: No signals

Other signals:

Ergonomics

No risks

Activation

No risks.

Security

No risks

Debuggability

Fully debuggable using existing DevTools support.

Is this feature fully tested by web-platform-tests

Yes

Flag name

Requires code in //chrome?

False

Tracking bug

https://crbug.com/1277613

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5669245760307200

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/CAM%3DNeDhYZ9nu-JdWdMS93E8AO8R39wqOWDo3pn3m6NFWqnjb6A%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/6c7f2dd3-cb27-e064-d4ca-c30865d8c324%40gmail.com

Re: [blink-dev] Intent to Prototype and Ship: WebUSB SameObject

2022-02-28 Thread Mike Taylor

This seems like a useful ergonomics addition. LGTM1.

On 2/25/22 8:09 PM, 'Jack Hsieh' via blink-dev wrote:

Contact emails

chengw...@chromium.com

Explainer

None

Specification

https://wicg.github.io/webusb/#device-usage

https://github.com/WICG/webusb/pull/212

Summary

Make USBConfiguration, USBInterface, USBAlternateInterface, and
USBEndpoint instances returned by the accessors on USBDevice ===
comparable.

Blink component

Blink>USB

Motivation

It is helpful for WebUSB to have USBConfiguration, USBInterface,
USBAlternateInterface, and USBEndpoint instances returned by the
accessors on USBDevice === comparable. We have seen this requirement
reported by developers fromhttps://crbug.com/1274922
and a positive signal from a Node.js
polyfill (https://github.com/thegecko/webusb
).

TAG review

The change is trivial enough to waive a TAG review requirement.

TAG review status

Not applicable

Risks

Interoperability and Compatibility

This change only adds the `===` compatibility to related objects and
data structures while behaviors of the existing WebUSB APIs remain the
same. Developers who don't rely on this `===` compatibility wouldn’t
notice a thing with this feature rolling out behind the scenes, and so
we believe the compatibility risk to be minimal.

Signals from other implementations (Gecko, WebKit):

Gecko: No signal

WebKit: No signal

Web developers: https://crbug.com/1274922 .

Other signals: The Node.js polyfill for WebUSB
(https://github.com/thegecko/webusb
) already implements these
accessors this way.

Debuggability

No specific DevTools changes are required. This feature only changes
the internal behavior of existing WebUSB JS methods.

Note that exposing DevTools debugging support for device-access APIs
(WebUSB included) is discussed
athttps://bugs.chromium.org/p/chromium/issues/detail?id=1142566
.

Is this feature fully tested by web-platform-tests

Yes. This feature will be fully tested at
https://wpt.fyi/results/webusb

Flag name

None

Requires code in //chrome?

False

Tracking Bug

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

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5769668454252544

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/CADQ2FkQK7ZWqUJ3PrVSKPPoxemNoORHM5aT2ymGU6qurOaJ%2B0g%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/625131fd-1996-6113-e877-0c55771d7ad9%40chromium.org.

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

2022-02-18 Thread Mike Taylor

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 

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.screenoffers 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: 
>

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 
>

The spec is being incubated in the W3C Second Screen CG 
> and is pending adoption by 
the W3C Second Screen WG >

Gecko: No signal 
(https://github.com/mozilla/standards-positions/issues/542 
) We 
requested a position and are waiting for feedback. Firefox supports 
cross-screen window.open/move*()requests. This work partly pursues 
compatibility with that behavior.

WebKit: No signal 
(https://lists.webkit.org/pipermail/webkit-dev/2021-June/031903.html 
) 
We requested a posit

Re: [blink-dev] Intent to Ship: Private Network Access preflight requests for subresources

2022-02-17 Thread Mike Taylor


Thanks for the update Titouan. Looking forward to reading your doc.

On 2/17/22 9:25 AM, Titouan Rigoudy wrote:

Hi all,

Just to let you know that due to a couple issues, chief among which a 
renderer crash (crbug.com/1279376 <http://crbug.com/1279376>), we are 
rolling this feature back from Chrome 98.


A few issues have been identified and will block our next attempt at 
shipping this. In the meantime, we gathered some useful information 
about impact and notified developers of the upcoming change. I'll 
write a doc summarizing the timeline and lessons learned, then share 
as appropriate here.


Cheers,
Titouan

On Mon, Dec 6, 2021 at 5:26 PM Chris Harrelson  
wrote:


LGTM3 for step 1.

On Mon, Dec 6, 2021 at 6:11 AM Mike Taylor
 wrote:

LGTM2 for step 1.

On 12/6/21 5:31 AM, Titouan Rigoudy wrote:

*assuming I get 2 more LGTMs, that is.

On Mon, Dec 6, 2021 at 11:31 AM Titouan Rigoudy
 wrote:

Thanks! I'll come back for further discussion with UKM
data in hand.

Cheers,
Titouan

On Mon, Dec 6, 2021 at 10:58 AM Yoav Weiss
 wrote:

I agree UKM analysis should not block step 1, as it
holds little risk. (There's still some risks that
servers will choke in the face of preflights, but
that seems minor compared to the enforcement risk)

Therefore,*LGTM1 for step 1* (preflights with no
enforcement), but not further (yet). Please come back
to this thread with any data you may have as a result
of adding UKMs.

On Fri, Dec 3, 2021 at 6:44 PM 'Titouan Rigoudy' via
blink-dev  wrote:

Yoav, do you think UKM analysis should block
sending preflights without enforcing their
success? I believe sending these will allow us to
get more precise information on the affected
websites through the usecounter recorded in
crrev.com/c/3310846 <http://crrev.com/c/3310846>.
I can then analyze UKM data and use the results
to inform the decision whether and when to
switch enforcement on?

Cheers,
Titouan

On Thu, Dec 2, 2021 at 5:19 PM Titouan Rigoudy
 wrote:

I agree!

Cheers,
Titouan

On Thu, Dec 2, 2021 at 5:17 PM Mike West
 wrote:

_I_ don't think we should do that, but
I'd defer to Titouan's preference. :)

-mike


    On Thu, Dec 2, 2021 at 5:14 PM Mike
Taylor  wrote:

Thanks - I also don't think there's a
lot of value in this particular
header being the odd-one-out, just
wanted to confirm we're not going to
ship "true" first and try to change
that to ?1 later (which is always
challenging).

On 12/2/21 11:11 AM, Mike West wrote:

I'm not sure it makes sense to
introduce a structured header here,
given that it's layering on top of
CORS headers that I don't think
there's substantial interest in
changing.

-mike


On Thu, Dec 2, 2021 at 4:55 PM
'Titouan Rigoudy' via blink-dev
 wrote:

Hi Mike,

There is no support for
structured headers so far, for
consistency reasons, and there
has been no movement to
deprecate the "true" value for
Access-Control-Allow-Credentials.
The value of such a deprecation
seems minimal.

I could pretty easily add
support for the structured "?1"
value on top of the "

Re: [blink-dev] Intent to Prototype and Ship: SerialPort integration with WritableStream controller AbortSignal

2022-02-14 Thread Mike Taylor

LGTM1

On 2/10/22 3:25 PM, Reilly Grant wrote:

Contact emails

reil...@chromium.org

Specification

https://wicg.github.io/serial/#writable-attribute

https://github.com/WICG/serial/pull/160

Summary

This integration prevents a situation in which aborting a SerialPort's
WritableStream can be blocked waiting for a partially-written chunk of
data to be written to the port. If the port is waiting for the peer
device to provide a flow control signal it could be blocked
indefinitely. The intent of aborting a WritableStream is to
immediately stop trying to write data to the underlying sink. The
introduction of an AbortSignal to the controller was done to fix bugs
like this.

Blink component

Blink>Serial

TAG review

The Web Serial API and WritableStream controller AbortSignal have both
been reviewed by the TAG.

TAG review status

Not applicable

Risks

Interoperability and Compatibility

This integration introduces a minor change to the behavior of a
SerialPort's WritableStream because it means that it no longer waits
for the current write() operation to complete. However, since the
intention of abort() is to discard queued writes and the exact timing
for when the current write() operation completes depends on how
quickly data is being transmitted by the port, the current behavior is
more appropriately classified as a bug than a feature. It would be
very hard for developers to rely on the previous buggy behavior, and
so we believe the compat risk to be minimal.

Gecko: No signal

Firefox is opposed to the Web Serial API in general.

WebKit: No signal

Safari is opposed to the Web Serial API in general.

Web developers: No signals

I don't believe any developers have noticed this particular quirk. I
noticed because I was debugging a test of the abort() behavior that
passed even though there was a write() pending and without this
integration it shouldn't have. Fixing the bug in the test exposed the
need for this integration.

Other signals:

Debuggability

SerialPort and WritableStream are JavaScript APIs which can be
debugged using DevTools.

Is this feature fully tested by web-platform-tests

Yes

Flag name

None

Requires code in //chrome?

False

Tracking bug

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

Estimated milestones

M-100

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4778232531386368

This intent message was generated by Chrome Platform Status
.
Reilly Grant | Software Engineer |reil...@chromium.org |Google Chrome

--
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/CAEmk%3DMYv0pu_WEXE6EAoZvVkh7W-ck_Gu5Qf52eFUuiwYhcW4A%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/a25f97f6-4213-adc8-8151-9f4e472d4dad%40chromium.org.

Re: [blink-dev] Intent to Deprecate and Remove: Calling PaymentRequest.show without user activation

2022-02-14 Thread Mike Taylor

Thanks for the thoughtful answers!

LGTM1. I'll trust you to file bugs / feature requests for those 3 items 
(and yeah, 3 sounds like a useful, but hard problem to solve).

On 2/14/22 9:44 AM, Stephen Mcgruer wrote:
> Is there anything we can learn about their challenges that might 
apply to the broader ecosystem?

A little, though largely it appears to be a bug in either 
their application or in Chrome (we're still trying to figure out 
which!). Simplifying, the problem is that they seem to be losing the 
Capability Delegation between click and (in a different iframe) the 
call to PR.show(), and it's quite tricky to debug this in a large 
async application. I can think of a few things that might help:

1. Adding capability delegation support to navigator.userActivation 
<https://github.com/dtapuska/useractivation> would likely be useful, 
e.g. exposing an array of capabilities currently active. This would 
make it much easier to quickly debug 'do I have a CD right here'. I 
hope the Capability Delegation folks might consider adding this! :)
2. Pausing user activation timeout when code execution in devtools is 
paused would be useful.
3. More generally (and more hand-wavingly), being able to more easily 
trace flows through async iframes 'somehow'. Devtools has some support 
for this, and it might just be user error that we and the partner are 
struggling, but when we're trying to answer questions like "Is it 
possible that this event flowed through an intermediary iframe that 
was created and destroyed again before this line of code executed", it 
can be tricky.

On Mon, 14 Feb 2022 at 09:27, Mike Taylor  wrote:

Hi Stephen,

Is there anything we can learn about their challenges that might
apply to the broader ecosystem?

On 2/14/22 9:22 AM, Stephen McGruer wrote:

Hey all,

Unfortunately we've hit a snag in our deprecation; a partner has
been having trouble integrating this change into their system,
and though we are engaged in helping them we haven't made much
progress yet.

As such, I'm currently requesting that we delay this deprecation
*until M102*, to give us more time to help solve their problem
before we require user activation. (I'm not sure how many LGTMs
delaying a deprecation requires?)

Thanks,
Stephen

On Tuesday, January 4, 2022 at 10:29:01 AM UTC-5 Stephen McGruer
wrote:

Hey folks,

Following up here - we have determined that the remaining
uses *do* necessitate making Capability Delegation available
for web developers (see our Intent to Experiment

<https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/i6pAWsjU7zg/m/CzqgcGAXAwAJ>
 -
unfortunately our partner didn't engage at that time or we
would have caught this earlier :(. )

We expect an Intent to Ship to be sent for Capability
Delegation 'soon', targeting M100, and so are planning to
push this deprecation out to M100 as well to align with that.

Thanks,
Stephen
On Wednesday, December 1, 2021 at 3:25:01 PM UTC-5 Mike
Taylor wrote:

LGTM3

On 12/1/21 12:34 PM, Chris Harrelson wrote:

LGTM2

On Wed, Dec 1, 2021 at 9:33 AM Yoav Weiss
 wrote:

LGTM1 to deprecate in M98 and remove in M99,
assuming no surprises come up on the usage front.

On Wed, Dec 1, 2021 at 6:31 PM Stephen Mcgruer
 wrote:

To be clear; I think we have a good enough shot
of that remaining site fixing their code 'soon'
(I expect O(weeks)) that we both:

1. Shouldn't do the removal till they have, and
2. Don't need to provide an alternative in the
form of capability delegation.

But the code change to at least start this
deprecation would have to land by December 9th
(or we punt for 1.5 months), hence why we're
filing this ahead of them fixing their site :).

On Wed, 1 Dec 2021 at 12:22, Stephen Mcgruer
 wrote:

> Does the primary remaining site have
fallback code, or will it be broken?

Yes and no :). It doesn't have automatic
fallback for the specific payment method the
user has selected (Google Pay), but the user
could then select one of the other payment
methods that the site supports (either a
credit card flow or I think PayPal IIRC).

On Wed, 1 Dec 2021 at 11:05, Yoav Weiss

Re: [blink-dev] Intent to Deprecate and Remove: Calling PaymentRequest.show without user activation

2022-02-14 Thread Mike Taylor


Hi Stephen,

Is there anything we can learn about their challenges that might apply 
to the broader ecosystem?


On 2/14/22 9:22 AM, Stephen McGruer wrote:

Hey all,

Unfortunately we've hit a snag in our deprecation; a partner has been 
having trouble integrating this change into their system, and though 
we are engaged in helping them we haven't made much progress yet.


As such, I'm currently requesting that we delay this deprecation 
*until M102*, to give us more time to help solve their problem before 
we require user activation. (I'm not sure how many LGTMs delaying a 
deprecation requires?)


Thanks,
Stephen

On Tuesday, January 4, 2022 at 10:29:01 AM UTC-5 Stephen McGruer wrote:

Hey folks,

Following up here - we have determined that the remaining uses
*do* necessitate making Capability Delegation available for web
developers (see our Intent to Experiment

<https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/i6pAWsjU7zg/m/CzqgcGAXAwAJ>
 -
unfortunately our partner didn't engage at that time or we would
have caught this earlier :(. )

We expect an Intent to Ship to be sent for Capability Delegation
'soon', targeting M100, and so are planning to push this
deprecation out to M100 as well to align with that.

Thanks,
Stephen
On Wednesday, December 1, 2021 at 3:25:01 PM UTC-5 Mike Taylor wrote:

LGTM3

On 12/1/21 12:34 PM, Chris Harrelson wrote:

LGTM2

On Wed, Dec 1, 2021 at 9:33 AM Yoav Weiss
 wrote:

LGTM1 to deprecate in M98 and remove in M99, assuming no
surprises come up on the usage front.

On Wed, Dec 1, 2021 at 6:31 PM Stephen Mcgruer
 wrote:

To be clear; I think we have a good enough shot of
that remaining site fixing their code 'soon' (I
expect O(weeks)) that we both:

1. Shouldn't do the removal till they have, and
2. Don't need to provide an alternative in the form
of capability delegation.

But the code change to at least start this
deprecation would have to land by December 9th (or we
punt for 1.5 months), hence why we're filing this
ahead of them fixing their site :).

On Wed, 1 Dec 2021 at 12:22, Stephen Mcgruer
 wrote:

> Does the primary remaining site have fallback
code, or will it be broken?

Yes and no :). It doesn't have automatic fallback
for the specific payment method the user has
selected (Google Pay), but the user could then
select one of the other payment methods that the
site supports (either a credit card flow or I
think PayPal IIRC).

On Wed, 1 Dec 2021 at 11:05, Yoav Weiss
 wrote:



On Wed, Dec 1, 2021 at 4:43 PM Stephen
Mcgruer  wrote:


Contact emails

smcgr...@chromium.org


Specification

https://www.w3.org/TR/payment-request/#show-method
<https://www.w3.org/TR/payment-request/#show-method>


Summary

Allowing PaymentRequest.show() to be
triggered without a user activation could
be abused by malicious websites. To
protect users, the spec was changed to
require user activation, and we are now
following through in the Chrome
implementation.

Plan is to deprecate in M98 and remove in
M99. We may push the M99 date to M100
based on compat risk; see below.


Blink component

Blink>Payments

<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EPayments>


TAG review

N/A - enforcement of feature from an
already-reviewed specification


TAG review status

Pending


Risks


Interoperability and Compatibility

Interoperability: no risk. Firefox has
not shipped PaymentRequest at all, whilst
Safari'

Re: [blink-dev] Intent to Ship: AbortSignal.prototype.throwIfAborted

2022-02-11 Thread Mike Taylor

LGTM1 - seems like a useful feature and good to see that Gecko and
WebKit have already shipped.

On 2/10/22 5:54 PM, Scott Haseley wrote:

Contact emails

shase...@chromium.org

Explainer

Discussion: https://github.com/whatwg/dom/issues/927
Examples:
https://developer.mozilla.org/en-US/docs/Web/API/AbortSignal/throwIfAborted

Specification

https://dom.spec.whatwg.org/#dom-abortsignal-throwifaborted

Summary

Throws an AbortSignal's reason if the signal is aborted. This
convenience method can be used by signal-handling functions to check a
signal's abort status and propagate the abort reason, e.g. after async
operations that might change a signal's state.

Blink component

Blink>DOM

TAG review

N/A: the feature has been merged into the DOM standard and has been
shipped in at least one other browser, in line with the criteria in
https://groups.google.com/a/chromium.org/g/blink-dev/c/naqmDmy1iM8/m/lQAJ17CRAQAJ.

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Low risk. This feature is already part of the DOM standard, has web
platform tests, and is implemented by Safari and Firefox. We'll
improve eventual interop by shipping this feature.

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

WebKit: Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=234127)

Web developers: Positive. Minor positive feedback (likes) from
announcement tweets:

- Safari: https://twitter.com/chris_dumez/status/1469566206516424704
- Node: https://twitter.com/simonplend/status/1487053107720859648 and
https://twitter.com/jasnell/status/1466093594129756166

Other signals:

Ergonomics

None; this feature is an ergonomic improvement for AbortSignal users.

Activation

The feature has already been implemented in both Safari and Firefox,
but it would benefit from a polyfill for use in older browser versions.

Security

None.

Debuggability

Basic tooling only, i.e. autocomplete support for the new AbortSignal
method will be provided.

Is this feature fully tested by web-platform-tests

Yes
(https://wpt.fyi/results/dom/abort/event.any.html?label=master&label=experimental&aligned&q=dom%2Fabort
)

Flag name

--enable-blink-features=AbortSignalThrowIfAborted

Requires code in //chrome?

False

Tracking bug

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

Launch bug

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

Measurement

UseCounter: AbortSignalThrowIfAborted

Sample links

https://developer.mozilla.org/en-US/docs/Web/API/AbortSignal/throwIfAborted#examples

Estimated milestones

DevTrial on desktop 100

DevTrial on android 100

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5029737100476416

Links to previous Intent discussions

Intent to prototype:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXGoJ3tUkTGZ1VBQm4139zL0n%3De-DO5emVpZE3ukya4Akyu2w%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/CAKXGoJ1w2WYK4X6fA7V4C0xNJBetNb%3D%2BCMywobhzzc9q9xSRxg%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/469859d1-1f5a-b3f9-f725-26563c112bb7%40chromium.org.

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

2022-02-11 Thread Mike Taylor


LGTM3 - agree with Mike

On 2/11/22 5:17 AM, Yoav Weiss wrote:

LGTM2 under the same conditions, for one last extension here.



On Fri, Feb 11, 2022 at 11:14 AM Mike West  wrote:

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 Founda

Re: [blink-dev] Intent to Deprecate and Remove: Event.path

2022-02-09 Thread Mike Taylor

Thanks for digging into this Philip! Agree that HTTPArchive analysis 
will be pretty helpful to help us make a decision.


Thinking again about the lack of (many) Firefox and Safari bugs - that 
gives me some hope that it might be safe to remove from Chromium 
(assuming we don't find that sites are UA-sniffing to only use 
event.path for Chromium browsers).


On 2/9/22 11:46 AM, Philip Jägenstedt wrote:

Here's a first cut at httparchive analysis:

SELECT page, url
FROM `httparchive.latest.response_bodies_desktop`
WHERE STRPOS(body, 'event.path') > 0
  AND STRPOS(body, 'event.composedPath()') = 0;

That finds over 32k cases. Categorizing these based on context and 
analyzing how each case would break would really help here.


The very first case I looked at was like this:

function getRealEventTarget(event, ELEMENT) {
    var path = []
    if (event.path) {
        path = event.path
    }
    if (event.originalEvent && event.originalEvent.path) {
        path = event.originalEvent.path
    }
    if (path && path.length > 0) {
        if (ELEMENT && path.indexOf(ELEMENT) >= 0) {
            return ELEMENT
        } else {
            return path[0]
        }
    }
    return event.target
}

At first glance this seems like a problem and that things could break, 
but then we need to look at if it's already broken in Firefox and 
Safari. It may well turn out that as actually used, it's harmless.


Best regards,
Philip

On Wed, Feb 9, 2022 at 5:37 PM Philip Jägenstedt  
wrote:


On Wed, Feb 9, 2022 at 10:50 AM Yoav Weiss
 wrote:



On Wednesday, February 9, 2022 at 2:49:55 AM UTC+1 Mike Taylor
wrote:

Hey Xiaocheng,

Thanks for working on improving interop! A few thoughts
and questions below.

On 2/8/22 7:25 PM, Xiaocheng Hu wrote:



Contact emails

xiaoche...@chromium.org


Explainer

None


Specification

None. Not a standard feature.


Summary

Event.path is a non-standard API that returns the event's
path, which is an array of the objects on which listeners
will be invoked. It is supported by Blink only, causing
web compatibility issues. Web developers should switch to
the equivalent standard API Event.composedPath(), which
returns the same result.



Blink component

Blink>DOM

<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EDOM>


TAG review



TAG review status

Not applicable


Risks



Interoperability and Compatibility

The removal of this API should improve interoperability,
as it's supported by Blink only. It still has 18% usage
as of Feb 2022
(https://chromestatus.com/metrics/feature/timeline/popularity/345),
so we will only deprecate it for now, and will not remove
it before the usage drops low enough. We expect low
compatibility risks, since there is an equivalent
standard API (Event.composedPath()) by all browsers, and
the following polyfill should also keep existing sites
functioning with minimum changes:


18% is a _lot_ of usage. So much that I'm surprised there
aren't dozens of compat bugs reported against Firefox. In
https://bugzilla.mozilla.org/show_bug.cgi?id=1697590#c0
there are only 2 linked site bugs. And there's only 3 in

https://github.com/webcompat/web-bugs/issues?q=is%3Aissue+composedPath
(the last one being from 2019).

I wonder how much of that 18% is feature detection and
fallback codepaths

<https://github.com/search?l=JavaScript&q=composedPath+event.path&type=Code>.


Yeah, that 18% is unreasonably high...
I think it'd be good to add a non-IDL based counter that
counts when both Event::path

<https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/dom/events/event.cc;l=287;bpv=1;bpt=0>
 and
Event::composedPath

<https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/dom/events/event.cc;l=293;bpv=1;bpt=0>
 are
accessed. (e.g. by adding 2 booleans or a bitmask on Event
indicating when any of them was touched and triggering the
counter when both have been)
Then we can assume that counts feature-detection/fallback and
subtract that counter from the 18%.


Based on past cases, I'm pretty sure most of the usage here is due
to event copying, wh

Re: [blink-dev] Intent to Ship: hwb() color notation

2022-02-08 Thread Mike Taylor


LGTM1

(Super cool first contribution, Jan)

On 2/8/22 5:40 AM, Anders Hartvoll Ruud wrote:



Contact emails

andr...@chromium.org, on behalf of: 
jan.kei...@gmail.com 


Explainer

None


Specification

https://drafts.csswg.org/css-color/#the-hwb-notation


Summary

HWB (short for Hue-Whiteness-Blackness) is another method of 
specifying sRGB colors, similar to HSL, but often even easier for 
humans to work with. It describes colors with a starting hue, then a 
degree of whiteness and blackness to mix into that base hue.


Example CSS declaration: color:hwb(194 0% 0%);

Since hwb() resolves to RGB, it's a relatively straightforward 
addition that doesn't add complexity or performance concerns.


CL: https://chromium-review.googlesource.com/c/chromium/src/+/3404291


Blink component

Blink>CSS 




TAG review

Didn't file one.


Risks


Interoperability and Compatibility


Gecko: Shipped/Shipping 
(https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/96)


WebKit: Shipped/Shipping 
(https://webkit.org/blog/11989/new-webkit-features-in-safari-15/)


Web developers: No signals

Other signals:


Debuggability

Inspector support will be shipped at the same time.


Is this feature fully tested by web-platform-tests

?

Yes:
https://wpt.fyi/results/css/css-color?label=master&label=experimental&aligned&q=hwb 




Requires code in //chrome?

False


Tracking bug

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


Estimated milestones

No milestones specified



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5637256860663808

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/CAKFBnUoZTq_4U9-ocMkOPDczeZ6DSfdCLZGkY8Crbp0tT68OxA%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/7e4f5aa6-099f-720c-b7ee-a585696ab82c%40chromium.org.

Re: [blink-dev] Intent to Deprecate and Remove: Event.path

2022-02-08 Thread Mike Taylor

Hey Xiaocheng,

Thanks for working on improving interop! A few thoughts and questions below.

On 2/8/22 7:25 PM, Xiaocheng Hu wrote:

Contact emails

xiaoche...@chromium.org

Explainer

None

Specification

None. Not a standard feature.

Summary

Event.path is a non-standard API that returns the event's path, which
is an array of the objects on which listeners will be invoked. It is
supported by Blink only, causing web compatibility issues. Web
developers should switch to the equivalent standard API
Event.composedPath(), which returns the same result.

Blink component

Blink>DOM

TAG review

TAG review status

Not applicable

Risks

Interoperability and Compatibility

The removal of this API should improve interoperability, as it's
supported by Blink only. It still has 18% usage as of Feb 2022
(https://chromestatus.com/metrics/feature/timeline/popularity/345), so
we will only deprecate it for now, and will not remove it before the
usage drops low enough. We expect low compatibility risks, since there
is an equivalent standard API (Event.composedPath()) by all browsers,
and the following polyfill should also keep existing sites functioning
with minimum changes:

18% is a _lot_ of usage. So much that I'm surprised there aren't dozens
of compat bugs reported against Firefox. In
https://bugzilla.mozilla.org/show_bug.cgi?id=1697590#c0 there are only 2
linked site bugs. And there's only 3 in
https://github.com/webcompat/web-bugs/issues?q=is%3Aissue+composedPath
(the last one being from 2019).

I wonder how much of that 18% is feature detection and fallback
codepaths
.

Are we aware of bug reports from Apple caused by event.path? I'm not
able to find any on bugs.webkit.org, but I could be doing it wrong.

Have you thought of ways to measure when event.path is called, and
event.composedPath isn't (not sure if that's even possible)? Maybe that
would show it's actually safe to remove.

if (!Event.prototype.path) { Object.defineProperty(Event.prototype,
'path', { get() { return this.composedPath(); } }); }

Given how simple this appears to be, I wonder if a better approach would
be to ask Mozilla and Apple if they would be willing to accept patches
to make event.path a legacy alias to event.composedPath - and then we
can spec it in DOM or Compat. The alternative is to send deprecation
messages for possibly a very long time, which doesn't really improve the
compat situation for a very long time. Or, we can figure out how to
measure the actual non-fallback usage of event.path and go from there.

Gecko: No signal Firefox does not support Event.path

WebKit: No signal Safari does not support Event.path

Web developers: Positive
(https://github.com/web-platform-tests/interop-2022/issues/26)
That should probably be counted as positive support from Mozilla, rather
than webdev support (no offense to James).

Other signals:

Debuggability

Usage of this deprecated feature will be reported to the DevTools
Issues Tab.

Is this feature fully tested by web-platform-tests

Flag name

Requires code in //chrome?

False

Tracking bug

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

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5726124632965120

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/CAFqEGha_iNax9r8%2BXVQK%2Bf3hEdu5z-MDAh44FbKMOuAnrHL2Ew%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/37184c99-a5ca-0dbd-1a19-5e15934c2bc5%40chromium.org.

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

2022-02-07 Thread Mike Taylor

FYI, we're going to run some other experiments to see how to improve 
performance here.


(And we'll send a new I2S after that, rather than revive this thread.)

Thanks everyone.

On 2/2/22 1:05 PM, 'Matt Menke' via blink-dev wrote:

Thanks for the feedback!  Responses inline.

On Wed, Feb 2, 2022 at 12:03 PM Alex Russell 
 wrote:


A 0.5%-5% regression on FCP is massive, particularly if this is at
the median. Are y'all able to publish more data about the
histograms these numbers came from?


A 0.5% for main frames is similar to what we saw on HTTP cache 
partitioning, not sure about cross-site iframes.  Look at the latest 
metrics, 0.7% for main frames is probably a more accurate summary.


The metrics in question specifically are 
PageLoad.PaintTiming.NavigationToFirstContentfulPaint and 
PageLoad.Clients.ThirdParty.Frames.NavigationToFirstContentfulPaint3.


We have details about percentiles and platforms, though I'm not quite 
sure how useful those are.  For general frame loads, the greatest 
regressions are on slower page loads. For iframes, the largest 
regression is at the 50th percentile and below of page loads, with the 
regression dropping to around 1% at the 99th percentile of load times. 
Regressions are similar across platforms, though Android seems to see 
the greatest regression for general frame loads.


I'm unaware of any histograms that would let us better delve into what 
sorts of cases the regressions affect most.


Thanks.

On Wednesday, February 2, 2022 at 1:25:41 AM UTC-8 Yoav Weiss wrote:

Thanks for working on this important partitioning!

On Tue, Feb 1, 2022 at 7:01 PM 'Matt Menke' via blink-dev
 wrote:


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.


Can't say that I'm excited about a 5% slowdown here..
Have y'all worked with the webperf community to try and find
mitigations to that? (e.g. adding preconnects for resources
that typically already had warm connections)


I'm unaware of any process for this.  We can't allow arbitrary 
preconnects for cross-site navs, since they potentially leak 
information, though I believe another team is looking / has looked 
into fancier cross-site prefetch (which may allow only the root 
document to be prefetched, though doesn't allow connection reuse).  
Also worth noting that Chrome throws away never used sockets after 10 
seconds, since sites tend to close unused sockets quickly, which would 
also make cross-site preconnects potentially less useful, unless they 
happen exactly at the time navigation starts.


Preconnects for cross-site iframes seems potentially more viable, 
since the concerns there are largely around cross-site attacks, so 
leaking data due to preconnects are less a use privacy concern, and, 
to the extent of my knowledge, are less useful for spying on 
cross-site iframes as well.


Any research on the implications in other browsers that we
could use as developer advice? Have y'all looked at the
implications on overall LCP?


I'm unaware of any research here.  We have not looked into the 
implica

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

2022-02-03 Thread Mike Taylor


On 2/3/22 8:37 PM, Nigel Tao wrote:

On Thu, Jan 27, 2022 at 3:23 AM Brianna Goldstein
 wrote:

On Thu, Jan 27, 2022 at 2:49 AM Yoav Weiss  wrote:

At the risk of piling on with another question: are these URLs different from 
`file://` scheme URLs?

@Yoav Weiss yes these are from the `filesystem://` scheme which is different 
from `file://`. Here's some information about where this scheme comes from.

I'll ask another naive question...

I understand "file://" URLs. "file:///home/user/bar.txt" is an example.

Can you give some examples of "filesystem://" URLs? Do they look like
"filesystem:///home/user/bar.txt" or
"filesystem://example.domain/foo/bar.txt" or something else? Do these
URLs look different for Android versus Desktop? Do they look different
for Browser App versus Web View?


Here's some sample code to illustrate how to get a filesystem URL: 
https://gist.github.com/miketaylr/df58ae669abc4eec1b514f4cfc71fc21 - 
pasted below as well


```

function writeFile(fs) {
  fs.root.getFile("coolguy.txt", {create: true}, fileEntry => {
    fileEntry.createWriter(fileWriter => {
  fileWriter.onwriteend = e => {
    window.webkitRequestFileSystem(window.TEMPORARY, 1024, readFile);
  };
  fileWriter.write(new Blob(["😎😎😎"], {type: "text/plain"}));
    });
  });
}

function readFile(fs) {
  fs.root.getFile("coolguy.txt", {}, fileEntry => {
    fileEntry.file(file => {
  const reader = new FileReader();
  reader.onloadend = e => {
    console.log(e, fileEntry.toURL());
  };
  reader.readAsText(file);
    });
  });
}

navigator.webkitTemporaryStorage.requestQuota(1024, granted => {
  window.webkitRequestFileSystem(window.TEMPORARY, granted, writeFile);
});

```

--
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/35b0b3cc-26bd-b44e-8e1e-0e05d7ac11dd%40chromium.org.

Re: [blink-dev] testing CH-UA

2022-02-02 Thread Mike Taylor

Привет Ян!

If using the devtools mobile emulation, you can add a custom device and
there is a toggle to open the "User agent client hints" section where
you can add header values: https://i.imgur.com/9vazymM.png. We should
probably add sensible defaults to the mobile emulation options, I filed
https://bugs.chromium.org/p/chromium/issues/detail?id=1293477 to track
that work.

thanks,
Mike

On 2/2/22 2:41 PM, Ali Beyad wrote:

Hello:

On Wed, Feb 2, 2022 at 1:21 PM Ян Стахеев wrote:

Hi!
I'm looking for a way to test Client Hints and to understand how
CH will work on my site before UA will be reduced. For now I use
#reduce-user-agent flag disabling UA. Is blocking UA by the flag
is enought to see the impact of UA reduction?

Yes, if you enable chrome://flags#reduce-user-agent, your browser will
send the reduced UA string to all sites it visits. Another option if
you're a site developer is to participate in our UA reduction origin
trial:
https://developer.chrome.com/blog/user-agent-reduction-origin-trial/

Also I can't fully model the situation in ChromeDev tools. When
emulating the mobile version in ChromeDev tools, CH-UA are not
displayed at all. Could you advise me, please, the reliable way I
could test disabling the User-Agent and using CH on my site in
order to understand that all ads, blocks, etc. will work correctly
after disabling UA? Or just using the flag is pretty enought?

If you just want to test your site from your browser, enabling
chrome://flags#reduce-user-agent and changing your site to send
Accept-CH headers with the client hints you want should be enough. If
you want to test your site with others who visit it, you can
participate in the origin trial linked to above.

Hope this helps!

Thank you! :)
--
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/b5da6ca4-752a-40fc-908c-bc902abe12b7n%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/CA%2BWdJ_6wt-J72dSCSXAakfiT4wDrUjqm6dsGd%2BC-ZEiAT_n2%3DA%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/c17d7633-d619-211e-c38c-c53cd11bc01a%40chromium.org.

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

2022-02-01 Thread 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

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.

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

2022-02-01 Thread 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

--enable-features="GreaseUACH:updated

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

2022-01-28 Thread Mike Taylor

Hi Rahul,

Would you mind creating a chromestatus entry for this intent? (See "Step
0" at http://dev.chromium.org/blink/launching-features for a link).

Also, out of curiosity (because I don't know much about scrollbars) -
will this proposed change have an impact on a page's layout?

thanks,
Mike

On 1/28/22 2:50 PM, 'Rahul Arakeri' via blink-dev wrote:

*_Intent to implement: Fluent Scrollbars._*

*_Contact emails_*

Rahul Arakeri: arak...@microsoft.com

Yaroslav Shalivskyy: yshalivs...@microsoft.com

Sahir Vellani: sahir.vell...@microsoft.com

Olga Gerchikov: gerch...@microsoft.com

Ben Mathwig: benjamin.math...@microsoft.com

*_Visual Spec_*

https://docs.google.com/document/d/1EpJnWAcPCxBQo6zPGR1Tg1NACiIJ-6dk7cYyK1DhBWw/edit

*_Summary_*

This proposal is to modernize the Chromium scrollbars (both overlay
and non-overlay) to fit the Windows 11 Fluent design language. As a
part of this effort, we are proposing to update the visual appearance
along with some changes to how users interact with overlay scrollbars.

*_Motivation_*

As the rest of Windows has been embracing WinUI and native Fluent
controls, certain non-XAML apps like Chromium-based browsers still use
the traditional (Win32 looking) scrollbars. As such, we believe that
the visual appearance of scrollbars could use an update in the
interest of maintaining homogeneity with the rest of Windows.

In a nutshell, we’re proposing that the default scrollbars should act
more like overlay scrollbars, be thinner, have insets and rounded
edges. Users will still have an option to select non overlay
scrollbars via the "Always show scrollbars" OS setting. Non overlay
scrollbars will also be restyled to match Windows theme. For details
on scrollbar styling and state transitions, please see the visual spec
linked above.

Also, please note that since some HTML controls (like and
) depend on the ScrollbarThemes(s) that are being refreshed,
they too will also get the new scrollbars.

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

No, this is aimed at Windows for now. However, it can be made
available on Linux too.

*_Ongoing technical constraints_*

None.

*_Tracking bug_*

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

--
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/SJ0PR00MB1144A4EB417B9D55D9C4D079A6229%40SJ0PR00MB1144.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/a8b056ed-b1bb-ab26-0b29-a4cd72599f4f%40chromium.org.

Re: [blink-dev] Intent to Ship: Capability Delegation with Payment Request

2022-01-27 Thread Mike Taylor


Appreciate the replies, Mustaq.

This seems like a useful addition to the platform, thanks for working on 
it. LGTM1.


On 1/27/22 12:35 PM, Mustaq Ahmed wrote:

Hi Mike:

Appreciate your feedback.  My answers are inline.

Mustaq


On Wed, Jan 26, 2022 at 6:03 PM Mike Taylor  
wrote:


Hi Mustaq,

On 1/25/22 4:45 PM, Mustaq Ahmed wrote:



Contact emails

mus...@chromium.org, smcgr...@chromium.org


Explainer

https://github.com/WICG/capability-delegation
<https://github.com/WICG/capability-delegation>


Specification

https://wicg.github.io/capability-delegation/spec.html
<https://wicg.github.io/capability-delegation/spec.html>


Design doc


https://docs.google.com/document/d/1IYN0mVy7yi4Afnm2Y0uda0JH8L2KwLgaBqsMVLMYXtk/edit?usp=sharing

<https://docs.google.com/document/d/1IYN0mVy7yi4Afnm2Y0uda0JH8L2KwLgaBqsMVLMYXtk/edit?usp=sharing>


Summary

Capability delegation means allowing a frame to relinquish its
ability to call a restricted API and transfer the ability to
another (sub)frame it trusts.


Can you expand more on the relinquishing aspect and how regaining
the capability happens? I can't find any normative text in
https://wicg.github.io/capability-delegation/spec.html that
explains how it happens. Do we look for expired timestamps in
DELEGATED_CAPABILITY_TIMESTAMPS["feature"] of all frames?
Something else?

(maybe I'm looking in the wrong place!)

You got it right: our proposal missed the normative text around the 
relinquishing, yikes!  I opened this spec issue 
<https://github.com/WICG/capability-delegation/issues/24>, we will 
send out a PR to fix this when we get a chance.  In the meantime here 
is what we wanted to mean: access to activation-gated APIs 
<https://html.spec.whatwg.org/multipage/interaction.html#user-activation-gated-apis> is 
lost from the sender frame through consumption, and the receiver frame 
checks its own DELEGATED_CAPABILITY_TIMESTAMPS["feature"] only.



If an app wants to delegate its ability to call a restricted JS
capability (e.g. popups, fullscreen, etc) to a known+trusted
third-party frame, the app would utilize a Capability Delegation
API to "transfer" the ability to the target frame in a
time-constrained manner (unlike static mechanisms like attributes).


What happens if the delegation is refused (or fails) by the
browser for some reason? As a developer, how do I know that I
shouldn't fire off a PaymentRequest that's going to fail? Do we
signal anything in the message event, if not, should we?

(From the PaymentRequest side, I guess I can handle the failure if
PaymentRequest.show() is rejected.)

Yes, just trying PaymentRequest.show() works on the receiver side 
today.  As we get more use-cases around delegation, we can explore 
signaling on the received message event.  I would suggest starting a 
new issue to discuss this.


That's fair - I'll file an issue, but I don't consider this to be a 
blocking concern.




As for error handling on the sender side, we have a few synchronous 
failure conditions in our postMessage 
<https://wicg.github.io/capability-delegation/spec.html#monkey-patch-to-html-tracking-delegation> algorithm 
<https://wicg.github.io/capability-delegation/spec.html#monkey-patch-to-html-tracking-delegation> already, 
can easily new ones as needed.  However, if you are thinking about an 
asynchronous failure (e.g. detected later when the browser decided to 
run the posted task), it seems like an existing problem with 
postMessage unless we change it to return a Promise 
<https://github.com/whatwg/html/issues/3458> (a separate problem).




Blink component

Blink>Input
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EInput>


TAG review

https://github.com/w3ctag/design-reviews/issues/655
<https://github.com/w3ctag/design-reviews/issues/655>


TAG review status

Approved subject to minor changes.

(Work in progress, see
https://github.com/WICG/capability-delegation/pull/23
<https://github.com/WICG/capability-delegation/pull/23>).


Risks


  Interoperability

Interop risk here like any new API: new use-cases relying on
delegation will fail in a browser that hasn't implemented this
feature.  In such a browser, the new API (postMessage()call with
an additional option) will silently get ignored while preserving
the legacy behavior.  More precisely, the postMessage()call will
be treated as if it was meant to send the message object only,
and the delegated capability will behave in the target Windowas
if no delegation has taken place.


  Compatibility

There is no compat

Re: [blink-dev] Intent to Ship: Capability Delegation with Payment Request

2022-01-26 Thread Mike Taylor


Hi Mustaq,

On 1/25/22 4:45 PM, Mustaq Ahmed wrote:



Contact emails

mus...@chromium.org, smcgr...@chromium.org


Explainer

https://github.com/WICG/capability-delegation 




Specification

https://wicg.github.io/capability-delegation/spec.html 




Design doc

https://docs.google.com/document/d/1IYN0mVy7yi4Afnm2Y0uda0JH8L2KwLgaBqsMVLMYXtk/edit?usp=sharing 




Summary

Capability delegation means allowing a frame to relinquish its ability 
to call a restricted API and transfer the ability to another 
(sub)frame it trusts.


Can you expand more on the relinquishing aspect and how regaining the 
capability happens? I can't find any normative text in 
https://wicg.github.io/capability-delegation/spec.html that explains how 
it happens. Do we look for expired timestamps in 
DELEGATED_CAPABILITY_TIMESTAMPS["feature"] of all frames? Something else?


(maybe I'm looking in the wrong place!)

If an app wants to delegate its ability to call a restricted JS 
capability (e.g. popups, fullscreen, etc) to a known+trusted 
third-party frame, the app would utilize a Capability Delegation API 
to "transfer" the ability to the target frame in a time-constrained 
manner (unlike static mechanisms like attributes).


What happens if the delegation is refused (or fails) by the browser for 
some reason? As a developer, how do I know that I shouldn't fire off a 
PaymentRequest that's going to fail? Do we signal anything in the 
message event, if not, should we?


(From the PaymentRequest side, I guess I can handle the failure if 
PaymentRequest.show() is rejected.)




Blink component

Blink>Input 




TAG review

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




TAG review status

Approved subject to minor changes.

(Work in progress, see 
https://github.com/WICG/capability-delegation/pull/23 
).



Risks


  Interoperability

Interop risk here like any new API: new use-cases relying on 
delegation will fail in a browser that hasn't implemented this 
feature.  In such a browser, the new API (postMessage()call with an 
additional option) will silently get ignored while preserving the 
legacy behavior.  More precisely, the postMessage()call will be 
treated as if it was meant to send the message object only, and the 
delegated capability will behave in the target Windowas if no 
delegation has taken place.



  Compatibility

There is no compat risk because this is a new feature.


External signals


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


  WebKit:No signal


  Web developers:Positive
  (https://discourse.wicg.io/t/capability-delegation/4821/3
  )


Debuggability

Developers can test the delegated API by calling it from the console 
of postMessage-target Window.  Additionally, on the console of the 
sender Window, navigator.userActivation.isActiveAPI can be utilized to 
check the consumption of user activation as a side-effect of delegation.



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

?

Work in progress: 
https://chromium-review.googlesource.com/c/chromium/src/+/3413851 




Flag name

--enable-blink-features=CapabilityDelegationPaymentRequest


Requires code in //chrome?

False


Tracking bug

https://crbug.com/1130558 


Estimated milestone

M100


Link to entry on the Chrome Platform Status

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




Links to previous Intent discussions

Intent to prototype: 
https://groups.google.com/a/chromium.org/g/blink-dev/c/9CeLYndESPE/m/AhEttheMBQAJ 



Intent to Experiment: 
https://groups.google.com/a/chromium.org/g/blink-dev/c/i6pAWsjU7zg/m/UK0lGnKuAAAJ 






This intent message was generated by Chrome Platform Statu

[blink-dev] Re: Request for deprecation trial (I2E): Sending the full User-Agent string after User-Agent reduction

2022-01-26 Thread Mike Taylor

Thanks Ali. It's also useful to have a look at 
https://groups.google.com/a/chromium.org/g/blink-dev/c/e3pZJu96g6c/m/X9HcrSkVAgAJ 
for the high-level plan, in addition to the timelines post 
 
which has timelines attached to it.


A 13 milestone timeline is pretty long, but our intention is to give the 
ecosystem sufficient time for migration work. The breakdown looks like 
so (summarizing the above links):


M100: launch deprecation trial 1 milestone ahead of first "reduction" 
phase, in case a site needs minor version and hasn't migrated to UA-CH yet.

M101: reduce MINOR.BUILD.PATCH to "0.0.0"
M107: reduce rest of Desktop UA
M110: reduce rest of Mobile UA
M113: end deprecation trial, giving an extra buffer of 3 months in case 
it's needed.


I believe most sites won't need 13 milestones to be ready, but we know 
some large sites have very long release cycles and it seems worthwhile 
to offer the extra time given the scope of the proposed changes.


On 1/26/22 10:37 AM, Ali Beyad wrote:
The timelines 
 
post contains more details, but in summary:


We will start offering the deprecation OT in M100, to give at least 
one release of integration time with the deprecation OT before the 
initial phase of UA reduction commences in M101 (reducing the minor 
version part of the UA string).  And it would last until M113 (see 
Phase 7 in the timelines post).


On Wed, Jan 26, 2022 at 10:26 AM Yoav Weiss  
wrote:


This seems like a good thing to do, thanks!
What are the requested timelines for the deprecation trial?

On Tuesday, January 25, 2022 at 3:40:15 PM UTC+1 Ali Beyad wrote:

Contact emails

abe...@chromium.org ,
victor...@chromium.org ,
jadekess...@chromium.org, miketa...@chromium.org


Explainer

None


Specification

None


Summary

Before we proceed with User-Agent (UA) reduction, we want to
allow sites that are not yet ready for the reduced UA string
to get the full UA string, exposed in HTTP requests and in
navigator.userAgent, navigator.appVersion, and
navigator.platform, through a deprecation origin trial.


Design Doc


https://docs.google.com/document/d/1d-K43rzfDGxNM4H6Yzh5lV08KJwLsae06i4Q0A8snME




Blink component

Privacy>Fingerprinting




TAG review

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



TAG review status

TBD, but we have positive signals

thus
far.


Risks


Interoperability and Compatibility

The compatibility risk is low, as we’re planning to send the
full UA string in the deprecation origin trial, which is an
existing behavior before UA reduction that sites already know
how to parse. The deprecation origin trial is there simply to
allow sites that aren’t yet prepared for the new behavior (the
reduced UA string) to continue to receive the old behavior
(the full UA string) for some time period.


As for interoperability, the concern is again low because the
deprecation origin trial is simply enabling
previously-existing behavior to continue to operate for the
sites that are enrolled.


Experiment Summary

The prerequisite of this trial is that developers know the
deprecation origin trial is a temporary measure to allow more
time to migrate off of the full UA string, and move to using
User-Agent Client Hints (UA-CH) instead.  By the end of the
deprecation origin trial date, the Chrome browser will
exclusively send the reduced UA string.


The goal is to enable developers to ensure stability with our
proposed changes.


As for engaging with the trial itself, there will be two
components controlled by the same origin trial:

1.

Provide the full UA string in the associated Javascript
APIs, if the deprecation origin trial is enabled.

2.

A client hint that gets set when the deprecation origin
trial is enabled, where the client hint indicates to the
origin that the User-Agent request header contains the
full user agent value. Because of the experimental nature
of this client hint, a valid o

Re: [blink-dev] Re: Intent to Ship: NDEFReader makeReadOnly()

2022-01-26 Thread Mike Taylor


LGTM2

On 1/26/22 11:43 AM, Yoav Weiss wrote:

LGTM1



On Monday, January 24, 2022 at 9:52:26 AM UTC+1 François Beaufort wrote:


Contact emails

fbeauf...@google.com 


Explainer

https://github.com/w3c/web-nfc/blob/gh-pages/EXPLAINER.md


https://github.com/w3c/web-nfc/pull/636



Specification

https://w3c.github.io/web-nfc/#dom-ndefreader-makereadonly


https://github.com/w3c/web-nfc/pull/632



Summary

The NDEFReader makeReadOnly() method allows web developers to make
NFC tags permanently read-only with Web NFC.


Blink component

Blink>NFC



Motivation

Since we’ve shipped Web NFC in Chrome 89, developers have been
asking for a way to “lock” NFC tags to prevent malicious users
from overwriting their content. See
https://github.com/w3c/web-nfc/issues/558



This seems like a needed use case from the issue comments. Thanks for 
tackling it!


This operation is a
one-way process and cannot be reversed. Once an NFC tag has been
made read-only, it can't be written anymore.


Existing Web NFC restrictions apply to makeReadOnly(): It is only
available to top-level frames and secure browsing contexts (HTTPS
only). Origins must first request the "nfc" permission while
handling a user gesture (e.g. a button click). To then make the
NFC tag read-only, the web page must be visible when the user
touches an NFC tag with their device, while still handling a user
gesture. The browser uses haptic feedback to indicate a tap.
Access to the NFC radio is blocked if the display is off or the
device is locked. When a page is placed in the background,
receiving and pushing NFC content is suspended.


TAG review

This small addition to the Web NFC API doesn’t seem to qualify for
a TAG review. Note that the Security and Privacy section was
updated based on last TAG review feedback at
https://github.com/w3ctag/design-reviews/issues/461



TAG review status

Not Applicable


Risks


Interoperability and Compatibility


This small addition to the NDEFReader object does not change the
overall status of Web NFC interoperability or compatibility.


Signals from other implementations (Gecko, WebKit):


Gecko: No Signal [1]

WebKit: No Signal [1]

Web / Framework developers: Positive
https://twitter.com/quicksave2k/status/1465615447806681090



[1] Both Gecko and Webkit are unlikely to object to this feature
specifically, but object to the overall Web NFC 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

Exposing DevTools debugging support for device-access APIs (Web
NFC included) is discussed at
https://bugs.chromium.org/p/chromium/issues/detail?id=1142566
.
For now, affordable NFC tags are required to debug Web NFC.


Is this feature fully tested by web-platform-tests

?

Yes. This feature will be fully tested at
https://wpt.fyi/results/web-nfc 


Requires code in //chrome?

True. The permission prompt text will be updated and current NFC
permissions reset so that users clearly know which permission
they’re granting to websites.


Tracking bug

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



Estimated milestones

M100


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5700853265596416



Links to previous Intent discussions

Intent to prototype:

https://groups.google.com/a/chromium.org/g/blink-dev/c/iyljeGnIct8/m/tonTVszmCAAJ



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

[blink-dev] Re: Request for deprecation trial (I2E): Sending the full User-Agent string after User-Agent reduction

2022-01-26 Thread Mike Taylor

Admittedly it's a very long timeline, but we're trying provide plenty of 
time for sites to migrate to reduce the burden on the ecosystem.


On 1/26/22 10:37 AM, Ali Beyad wrote:
The timelines 
 
post contains more details, but in summary:


We will start offering the deprecation OT in M100, to give at least 
one release of integration time with the deprecation OT before the 
initial phase of UA reduction commences in M101 (reducing the minor 
version part of the UA string).  And it would last until M113 (see 
Phase 7 in the timelines post).


On Wed, Jan 26, 2022 at 10:26 AM Yoav Weiss  
wrote:


This seems like a good thing to do, thanks!
What are the requested timelines for the deprecation trial?

On Tuesday, January 25, 2022 at 3:40:15 PM UTC+1 Ali Beyad wrote:

Contact emails

abe...@chromium.org ,
victor...@chromium.org ,
jadekess...@chromium.org, miketa...@chromium.org


Explainer

None


Specification

None


Summary

Before we proceed with User-Agent (UA) reduction, we want to
allow sites that are not yet ready for the reduced UA string
to get the full UA string, exposed in HTTP requests and in
navigator.userAgent, navigator.appVersion, and
navigator.platform, through a deprecation origin trial.


Design Doc


https://docs.google.com/document/d/1d-K43rzfDGxNM4H6Yzh5lV08KJwLsae06i4Q0A8snME




Blink component

Privacy>Fingerprinting




TAG review

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



TAG review status

TBD, but we have positive signals

thus
far.


Risks


Interoperability and Compatibility

The compatibility risk is low, as we’re planning to send the
full UA string in the deprecation origin trial, which is an
existing behavior before UA reduction that sites already know
how to parse. The deprecation origin trial is there simply to
allow sites that aren’t yet prepared for the new behavior (the
reduced UA string) to continue to receive the old behavior
(the full UA string) for some time period.


As for interoperability, the concern is again low because the
deprecation origin trial is simply enabling
previously-existing behavior to continue to operate for the
sites that are enrolled.


Experiment Summary

The prerequisite of this trial is that developers know the
deprecation origin trial is a temporary measure to allow more
time to migrate off of the full UA string, and move to using
User-Agent Client Hints (UA-CH) instead.  By the end of the
deprecation origin trial date, the Chrome browser will
exclusively send the reduced UA string.


The goal is to enable developers to ensure stability with our
proposed changes.


As for engaging with the trial itself, there will be two
components controlled by the same origin trial:

1.

Provide the full UA string in the associated Javascript
APIs, if the deprecation origin trial is enabled.

2.

A client hint that gets set when the deprecation origin
trial is enabled, where the client hint indicates to the
origin that the User-Agent request header contains the
full user agent value. Because of the experimental nature
of this client hint, a valid origin trial token must be
sent in the response header by the origin for the client
hint to take effect or be stored (in order to prevent
platform burn-in for this temporary client hint).


During the process of conducting the origin trial, we may find
that we need to request an exception to the per-site (and
possibly global) limits imposed by origin trials. In practice,
origin trials rarely exceed their quota limits, but if
necessary, there is time between when the limits have been
exceeded and the origin trial is turned off, where we can work
with the users on reducing their usage and/or lifting the limits.


Please see the design document describing the experiment for
more information.


Experiment Goals

The goal of this trial is to enable developers more time to

Re: [blink-dev] Re: Intent to Ship: mix-blend-mode: plus-lighter

2022-01-26 Thread Mike Taylor

LGTM2, thanks for the very well written explainer-slash-blog-post.

On 1/26/22 9:42 AM, Yoav Weiss wrote:

LGTM1

This seems like a useful small addition! Following WebKit here makes
sense.

On Wednesday, January 19, 2022 at 5:40:45 PM UTC+1 Vladimir Levin wrote:

Contact emails

vmp...@chromium.org, khushalsa...@chromium.org
, jakearchib...@chromium.org

Explainer

https://jakearchibald.com/2021/dom-cross-fade/

Specification

https://drafts.fxtf.org/compositing-2/#mix-blend-mode

Summary

This proposal adds a plus-lighter value to the mix-blend-mode
property. Plus-lighter adds the source and destination colors
multiplied by their respective alphas. This operation is useful
when cross fading between two elements that may contain common
pixels. In that case, plus-lighter ensures that the common pixels
do not change in appearance as opacity changes from 0 to 1 on one
element and from 1 to 0 on the other.

Blink component

Blink>CSS

Search tags

plus-lighter

TAG review

N/A: this is a single value addition to an existing property, and
this value already exists in a canvas context, so the TAG review
seemed not necessary

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Gecko: No signal

WebKit: Shipped/Shipping
(https://github.com/w3c/fxtf-drafts/issues/445#issuecomment-995022125
)

Web developers: No signals

Other signals:

Ergonomics

This adds a new value to an existing CSS property. The ergonomics
risk is minimal.

Activation

This adds a new value to an existing CSS property. The activation
risk is minimal. This property is straight-forward to use.

Security

There are no security risks associated with this property.

Debuggability

This relies on existing debuggability of CSS mix-blend-mode.

Is this feature fully tested by web-platform-tests

Yes

Requires code in //chrome?

False

Tracking bug

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

Estimated milestones

M100

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5677338286096384

Links to previous Intent discussions

Intent to prototype:

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2MsbYsCV57vZ-eVQem4WUudVTGT%3Djzpib0NzezYEAMP-g%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/1c4ffaa4-38dd-4dca-b60c-ec0393147f2an%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/e7c669a2-0896-9a19-948b-a8248bd9df11%40chromium.org.

[blink-dev] Intent to Prototype & Ship: Sec-CH-UA-WoW64 Client Hint

2022-01-25 Thread Mike Taylor

Contact emails
miketa...@chromium.org, jadekess...@chromium.org

Explainer
https://github.com/WICG/ua-client-hints#explainer-reducing-user-agent-granularity

Specification
https://wicg.github.io/ua-client-hints/#sec-ch-ua-wow64

Summary
The Sec-CH-UA-WoW64 Client Hint is a backwards compatible shim for sites
relying on "WoW64-ness" (32-bit app running in 64-bit Windows) as they
transition from the User-Agent string to UA-CH. It returns a boolean value.

Blink component
Blink>Network>ClientHints

Motivation
We would like to provide a seamless transition from User-Agent-based use
cases to UA-CH. The "WoW64" bit is the last missing piece to accomplish
this goal.

Initial public proposal
https://github.com/WICG/ua-client-hints/issues/217

Search tags
wow, wow64, ua-ch, uach

TAG review
https://github.com/w3ctag/design-reviews/issues/640 - still open, but
issues have been addressed. I'll ping the existing issue with this
addition so folks are aware, but I don't expect it to change TAG's
stance of UA-CH as a feature.

TAG review status
Issues addressed

Risks
We don’t anticipate any risk here, we’re just moving this bit from one
API to another as a shim.

Interoperability and Compatibility
Interop: Not all browsers expose wow64-ness in the UA string today, so
sites should not treat a false value as meaningful (the spec allows for
always returning false).

Compat: This hint can be thought of as a compatibility shim for sites
migrating from User-Agent to UA-CH, otherwise N/A.

Gecko: Non-harmful on UA-CH, but were they to implement UA-CH I would
not expect them to add this hint (as they don’t expose this bit in their
UA string anymore).

WebKit: No signal. I would also not expect Apple to implement this one,
were they to implmement UA-CH.

Web developers: Mixed signals
(https://github.com/WICG/ua-client-hints/issues/217) We know of at least
one site (Meet) that uses wow64 to prevent sending a 7MB wasm binary to
users were performance is known to be lousy .

Debuggability
Nothing special needed.

Is this feature fully tested by web-platform-tests?
We'll add some.

Flag name
None.

Requires code in //chrome?
False

Estimated milestones
M100

Tracking Bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1288837

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

--
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/cfdb6441-7c65-4b63-a266-2dea85b25f23%40chromium.org.

Re: [blink-dev] Re: Intent to Ship: Remove Battery Status API on Insecure Origins

2022-01-25 Thread Mike Taylor

I think it's fine to keep the warning CL in M99 as long as we stick to 
the original timeline of removal.


On 1/25/22 7:39 AM, Raphael Kubo Da Costa wrote:

Thanks everyone for the LGTMs.

Due to an oversight I ended up landing the CL that adds a deprecation 
warning 
 
before M99 branched, so compared to what I originally wrote the 
deprecation has started in M99 instead of M100. The plan to keep the 
deprecation message until M102 and stop exposing the API in insecure 
origins in M103 remains.


If you prefer, I can revert the CL in the M99 branch and return to the 
plan I'd announced.


On Wednesday, 19 January 2022 at 17:24:11 UTC+1 bratell.d via 
Chromestatus wrote:


LGTM4 (also testing new intent tracking UI)

--
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/b89dca3f-3e44-47ba-9f79-8e7616912aaen%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/ca4f28df-6cb9-b27c-6432-cb7b8441a901%40chromium.org.

Re: [EXTERNAL] Re: [blink-dev] Intent to Prototype: CSS Subgrid

2022-01-20 Thread Mike Taylor


(I'm not Mathias, but...)

You can just respond to this thread with the debug info, and update the 
Chromestatus entry as well - thanks!


On 1/20/22 3:57 PM, 'Ethan Jimenez' via blink-dev wrote:


Hi everyone!

Philip, thanks for the encouragement, I’m super excited to deliver 
subgrid knowing that it’s going to make so many devs happy.


@Mathias Bynens  quick question, should I 
re-send the intent to prototype or just edit it here?


Thanks in advance,

Ethan

*From:* Philip Jägenstedt 
*Sent:* Wednesday, January 19, 2022 9:03 AM
*To:* Mathias Bynens 
*Cc:* Ethan Jimenez ; blink-dev@chromium.org
*Subject:* [EXTERNAL] Re: [blink-dev] Intent to Prototype: CSS Subgrid

Hi Ethan,

It's great to see this Intent to Prototype. Subgrid tends to come up 
as important in web developer surveys, the latest being State of CSS 2021:


https://2021.stateofcss.com/en-US/opinions/#browser_interoperability_features 



https://2021.stateofcss.com/en-US/opinions/#currently_missing_from_css_wins 



It's a part of Interop 2022 
 
for this reason


So I hope this all goes well :D

Best regards,

Philip

On Wed, Jan 19, 2022 at 8:09 AM Mathias Bynens  
wrote:


The required “Debuggability” section was left empty. Please follow
https://goo.gle/devtools-checklist


and elaborate on how developers would inspect & debug this new
feature. Per the guide, we need to ensure DevTools supports basic
editing of the new CSS properties and values — which would likely
work out-of-the-box anyhow. Please elaborate.

On Tue, Jan 18, 2022 at 6:42 PM 'Ethan Jimenez' via blink-dev
 wrote:

*Contact emails*

etha...@microsoft.com 

*Explainer*

None

*Specification*

https://drafts.csswg.org/css-grid-2



*Design docs*

https://docs.google.com/document/d/1cpsCmzdDlXUKtMxOUKIoJFyLH54mLVhZnam_z0PriO0/edit?usp=sharing



*Summary*

Implements the CSS Grid Layout Module Level 2 specification,
which introduces the concept of a "subgrid" to nested grid
containers.

*Blink component*

Blink>CSS

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

2022-01-19 Thread Mike Taylor

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.

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

2022-01-14 Thread Mike Taylor

LGTM2 - can you please file a bug to explicitly remove usage by YouTube?

On 1/14/22 8:00 AM, Mike West wrote:
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
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
.

--
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/fc5a5538-bdeb-fd98-1035-07e417f418fc%40chromium.org.

Re: [blink-dev] Intent to Deprecate and Remove: Minor WebCodecs spec violations

2021-12-20 Thread Mike Taylor

On 12/19/21 7:03 PM, Chris Cunningham wrote:

Hi Mike,

> And the proposed change here is to remove temporalLayderId as a 
top-level key on EncodedVideoChunkMetadata, right?

That's right.

> The proposed change here is to start throwing without a timestamp 
key in the VideoFrameInit dictionary, for all "image" types except 
VideoFrame and HTMLVideoElement, correct?

That's also right.

> Can you clarify the timing of the proposed removal? Do you intend to 
send deprecation messages in M99, and if so, for how long? Or do you 
intend to deprecate and remove all at once in M99?

My ideal timing would be to remove in 99. We've just landed a flag 
(--enable-features=RemoveWebCodecsSpecViolations 
<https://chromium-review.googlesource.com/c/chromium/src/+/3347023>) 
to simulate the removal, which I should be able to merge back to 98. 
We landed a "may deprecate" message for the VideoFrame constructor in 
97. I could merge a change to 98 that hardens language to "is 
deprecated". I'm not sure we can add a message for the 
metadata.temporalLayerId deprecation since it's just an output 
dictionary member.

Happy to be flexible if this timeline is problematic. At this point I 
think the usage of the bad paths is actually near zero, so a faster 
timeline has advantages too.

Given that usage is around .00015% right now, I agree that moving faster 
on this change is probably smart. *LGTM1* if we can change the 
deprecation message to "is deprecated".

Merging back the flag back to M98 seems useful if we can make developers 
aware it exists, perhaps by updating https://web.dev/webcodecs/ with an 
"update" blurb up to mentioning the changes and the flag?

(Before I hit send, I went and searched for `temporalLayerId` in the 
httparchive.latest.requests_desktop dataset and got zero results - that 
makes me feel better about hitting send).

Best,
Chris

On Sat, Dec 18, 2021 at 12:30 PM Mike Taylor  
wrote:

Hi Chris,

On 12/17/21 3:24 PM, Chris Cunningham wrote:

Contact emails

*

chcunning...@chromium.org

*

Explainer

*

https://github.com/w3c/webcodecs/blob/main/explainer.md

*

Specification

*

https://w3c.github.io/webcodecs/
<https://w3c.github.io/webcodecs/>

*

Summary

*

We've identified two areas where our implementation
violates the specification. We've implemented parallel
correct paths for authors to use and would like to
deprecate the original bad paths. The issues affect
VideoFrame construction and the EncodedVideoChunkMetadata
dictionary.

*

Blink component

*

Blink>Media>WebCodecs

<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EMedia%3EWebCodecs>

*

Motivation

*

We've identified two areas where our implementation of
WebCodecs violates the specification. We've considered
changing the spec, but prefer to instead fix the
implementation. The specified behavior is cleaner and
less error prone. The changes are breaking, but the
workarounds are trivial and WebCodecs usage is currently
very low (we just shipped in Chrome 94, only engine to
ship so far).
https://chromestatus.com/metrics/feature/timeline/popularity/3464
<https://chromestatus.com/metrics/feature/timeline/popularity/3464>

Details:

1. The spec defines the temporalLayerId attribute as a
member of the SvcOutputMetadata dictionary which is
nested under the EncodedVideoChunkMetadata dictionary
(metadata.svc.temporalLayerId). But Chrome places the
temporalLayerId directly on the top level
EncodedVideoChunkMetadata dictionary
(metadata.temporalLayerId). As of Chrome 98, either
option is available.

*

And the proposed change here is to remove temporalLayderId as a
top-level key on EncodedVideoChunkMetadata, right?

*

2. The spec requires that the
VideoFrame(CanvasImageSource, ...) constructor include a
timestamp argument (VideoFrameInit.timestamp) for
CanvasImageSource types that don't implicitly have a
timestamp (e.g. HTMLCanvasElement). Failing to include
the timestamp should result in a TypeError, but Chrome
currently defaults the timestamp to zero. Chrome will
respect the timestamp if one is given.

*

The proposed cha

Re: [blink-dev] Re: Intent to Deprecate and Freeze: The User-Agent string

2021-12-20 Thread Mike Taylor


Hi Chris,

Could you please file a bug at crbug.com/new, with the exact website you 
had an issue on? I'm happy to follow up once that's done.


thanks,
Mike

On 12/20/21 9:11 AM, Chris Bloggs wrote:
Can someone please contact sony, when I reduced these headers I was 
unable to auth on their website, it seems they specifically probably 
have whitelisted portions of the removed headers to allow 
authentication, it needs a google/chrome rep rather than a end user 
like myself.


On Friday, 11 June 2021 at 18:34:14 UTC+1 James Rosewell wrote:

Please could you publish information concerning this proposals
compliance with the draft commitments Google

<https://assets.publishing.service.gov.uk/media/60c21e54d3bf7f4bcc0652cd/Notice_of_intention_to_accept_binding_commitments_offered_by_Google_publication.pdf>
made to the Competition and Markets Authority which were published
today?
On Wednesday, 19 May 2021 at 21:49:10 UTC+1 Mike Taylor wrote:

Hi Par (and others),

Today we published an update on our UA Reduction plans, in a
new thread:
https://groups.google.com/a/chromium.org/g/blink-dev/c/e3pZJu96g6c


Happy to answer any questions over there (rather than engage
in multiple
threads on the topic).

Thanks,
Mike

On 5/6/21 10:33 AM, Mike Taylor wrote:
> Hi Par,
>
> Yep, this is the right mailing list to follow for announcements
> related to these proposed changes.
>
> We don't have anything to share right now, but hope to soon
(not a
> super satisfying answer, I know).
>
> thanks,
> Mike
>
> On 5/6/21 9:22 AM, 'par.andersson%neten...@gtempaccount.com'
via
> blink-dev wrote:
>> Any update on this? Where can I follow progress on this
topic, is
>> this the right place? (sorry if this has been
asked/answered before,
>> I have not seen such comment)
>> Thanks,
>> Par
>>
>> On Thursday, February 25, 2021 at 5:20:34 AM UTC+1 Aaron
Tagliaboschi
>> wrote:
>>
>>
>>
>>     On Wed, Feb 24, 2021, 22:41 James Nghiem

>> wrote:
>>
>>
>>     Ah I see it in the release now. A few more questions:
>>     As part of the Chrome 89 rollout, I'm assuming that
the UA will
>>     also be frozen, correct?
>>
>>
>>     No, the UA string will *not* be frozen in Chrome 89.
We've yet to
>>     release a firm timeline.
>>
>>     If so, will the UA still be up-to-date for Chrome
89 or should
>>     we expect it to be frozen at Chrome 88's value?
>>     On Wednesday, February 24, 2021 at 11:16:43 AM
UTC-8 Aaron
>>     Tagliaboschi wrote:
>>
>>     The User Agent Client Hints feature will be
fully rolled in
>>     Chrome 89
>>
>>
>>     Aaron Tagliaboschi | Software Engineer, Chrome
Trust &
>> Safety
>>
>>
>>     On Wed, Feb 24, 2021 at 1:36 PM James Nghiem
>>      wrote:
>>
>>     Just wanted to follow up on this since I
haven't seen or
>>     been able to find any updates to the
timeline! Do we
>>     have any specific dates on when we're
expecting UACH to
>>     roll out?
>>
>>
>>
>>     On Friday, January 29, 2021 at 9:16:39 AM
UTC-8 Thomas
>>     Ziegelbecker wrote:
>>
>>     +1 ?
>>
>>     On Thursday, December 17, 2020 at
9:31:48 PM UTC+1
>>     Saurav Kumar wrote:
>>
>>     Hi James,
>>
>>     Now that we are nearing 2021, do we
have an
>>     approximate date when Chrome would
start to roll
>>     out frozen UA strings?
>>
>>     Thanks
>>     Saurav
>>
>>     On Monday, 27 July

Re: [blink-dev] Intent to Ship: Origin Isolation By Default / Deprecate document.domain

2021-12-18 Thread Mike Taylor


On 12/16/21 5:52 PM, Charlie Reis wrote:



On Thu, Dec 16, 2021 at 7:28 AM 'Daniel Vogelheim' via blink-dev 
 wrote:


On Tue, Dec 14, 2021 at 11:51 PM Mike Taylor
 wrote:

On 12/14/21 11:35 AM, Daniel Bratell wrote:


It seems more or less everyone agrees on this being a good
thing, so it mainly comes down to web compatibility.

How much of the web will break, and how badly. The numbers
mentioned, 0.5% of sites set document.domain, 0.05% seem to
depend on document.domain, are quite high. One thing I didn't
quite pick up is what happens if you try to set
document.domain when it's not settable. Will it silently
pretend to work, or will that also be a possible break point?


I would be surprised if it didn't behave the same as setting
an arbitrary expando on `document` - we should be safe there.


Almost. The error handling is mostly the same. But while a foreign
attribute on document would return the new value, document.domain
(when in an origin-keyed agent cluster) does not.

So:
  document.foo = "bla"
  document.foo  // Returns "bla".

  document.domain = "bla"  // Throws SecurityException.

  // On a domain www.host.com <http://www.host.com>, site-keyed
agent cluster (current default)
  document.domain = "host.com <http://host.com>" // Succeeds.
  document.domain;  // returns "host.com <http://host.com>".

  // On a domain www.host.com <http://www.host.com>, origin-keyed
agent cluster (future default)
  document.domain = "host.com <http://host.com>" // Doesn't throw.
Doesn't do anything else either.
  document.domain;  // Still returns www.host.com
<http://www.host.com>.



Risks: Interoperability and Compatibility


*

No interoperability risks.

*


Compatibility risk exists, but is fairly small as
document.domain is an already deprecated feature. We’ve
detailed UKM metrics in place and are planning to reach out
to top users as soon as we’ve LGTMs for the plan.

As Daniel mentioned, I think the compat risk should be
considered to be higher, despite this being deprecated for a
long time.


Yes, agreed.



*

*

Current usage of the document.domain: 0.05%
<https://chromestatus.com/metrics/feature/timeline/popularity/2544>of
page views rely upon document.domain to enable some
cross-origin access that wasn't otherwise possible. 0.24%
<https://chromestatus.com/metrics/feature/timeline/popularity/2543>of
page views block same-origin access because only one side
sets document.domain. Both counters can be found
onhttps://deprecate.it/#document-domain
<https://deprecate.it/#document-domain>, too.

(cool site, btw)

We’ve reached out in advance to 4 of the top current users -
TL;DR Most of their use cases could be achieved already by
different APIs e.g. Audio/video autoplay in iframes by
adding the ‘autoplay’ attribute, support chat deployed
across subdomains.

Out of curiosity, did any of them mention what couldn't be
achieved via existing APIs?


I checked back, and nothing particular came up. It seems that
migrating off of document.domain isn't blocked by a lack of options.


Activation - Deprecation plan
M98 - Add the devtools issue and warning incl. a web.dev
<http://web.dev> blog post to guide adoption


*

M98-M100 - Monitor use counters and reach out to
current users

*


What's the plan if the use counters don't move? Do you have a
minimum page view % in mind you would want before proceeding
to the next step (even if it meant delaying the timeline)?


We don't have a dead-set plan. The primary idea is a combination
of delay-ing until usage is low enough, and outreach to offending
sites to educate about the problem & available alternatives.



*

M101 - Deprecate the feature by default. No
reverse-origin trial is planned as the
‘Origin-Agent-Cluster’ http header can be used to
gain access to the feature.

*


Would this disabled-by-default change ride the trains, or have
you considered finching it out to assess compat risk?


My original plan was to enable it by default in the 101 release,
and have a Finch switch as an emergency-off. Reading the feedback
here, maybe it's better to incrementally enable it

Re: [blink-dev] Intent to Deprecate and Remove: Minor WebCodecs spec violations

2021-12-18 Thread Mike Taylor


Hi Chris,

On 12/17/21 3:24 PM, Chris Cunningham wrote:



Contact emails


*

chcunning...@chromium.org


*


Explainer


*

https://github.com/w3c/webcodecs/blob/main/explainer.md


*


Specification


*

https://w3c.github.io/webcodecs/



*


Summary


*

We've identified two areas where our implementation violates
the specification. We've implemented parallel correct paths
for authors to use and would like to deprecate the original
bad paths. The issues affect VideoFrame construction and the
EncodedVideoChunkMetadata dictionary.


*


Blink component


*

Blink>Media>WebCodecs




*


Motivation


*

We've identified two areas where our implementation of
WebCodecs violates the specification. We've considered
changing the spec, but prefer to instead fix the
implementation. The specified behavior is cleaner and less
error prone. The changes are breaking, but the workarounds are
trivial and WebCodecs usage is currently very low (we just
shipped in Chrome 94, only engine to ship so far).
https://chromestatus.com/metrics/feature/timeline/popularity/3464



Details:


1. The spec defines the temporalLayerId attribute as a member
of the SvcOutputMetadata dictionary which is nested under the
EncodedVideoChunkMetadata dictionary
(metadata.svc.temporalLayerId). But Chrome places the
temporalLayerId directly on the top level
EncodedVideoChunkMetadata dictionary
(metadata.temporalLayerId). As of Chrome 98, either option is
available.

*

And the proposed change here is to remove temporalLayderId as a 
top-level key on EncodedVideoChunkMetadata, right?



*

2. The spec requires that the VideoFrame(CanvasImageSource,
...) constructor include a timestamp argument
(VideoFrameInit.timestamp) for CanvasImageSource types that
don't implicitly have a timestamp (e.g. HTMLCanvasElement).
Failing to include the timestamp should result in a TypeError,
but Chrome currently defaults the timestamp to zero. Chrome
will respect the timestamp if one is given.

*

The proposed change here is to start throwing without a timestamp key in 
the VideoFrameInit dictionary, for all "image" types except VideoFrame 
and HTMLVideoElement, correct?



Initial public proposal


*


https://groups.google.com/a/chromium.org/g/blink-dev/c/7UlTzFMbTFs/m/Rib4ca4-BQAJ




*


TAG review


*

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



*


TAG review status


*

Complete


*


Risks


*
*


Site breakage


*

Both changes can break sites.


For temporalLayerId, we're not able to add metrics for it's
usage (dictionary member), but we have a reasonable sense for
which sites may be affected and will reach out directly.


For the VideoFrame constructor, we added UKM metrics to count
usage of the bad path and a "may deprecate" warning. These
metrics landed in M97 (beta). So far, no usage of the bad path.


*


Interoperability and Compatibility


*

Gecko: Supportive. Paul Adenot approved the PRs that defined
the specified behavior. We discussed changing the behavior of
the VideoFrame constructor but both prefer to fix the
implementation if that can be done without huge developer pain.


WebKit: No signal


Web developers: No signals.


*


Debuggability


*

Fixing the VideoFrame constructor may reduce the need for
author debugging. The current defaulting behavior (timestamp =
0) may at first seem helpful, but is problematic if you then
send the VideoFrame to a VideoEncoder, where timestamps are
used to guide bitrate control.


*


Is this feature fully tested by web-platform-tests

?


*

Yes.
https://github.com/web-platform-tests/wpt/tree/master/webcodecs



*


Flag name


*

None yet. We'll implement a

Re: [blink-dev] Intent to Ship: AudioContext.outputLatency

2021-12-15 Thread Mike Taylor


LGTM2 w/ same condition.

On 12/15/21 11:47 AM, Yoav Weiss wrote:
LGTM1 conditional on those metrics landing (but no need to wait for 
data from the metrics to come in).


On Monday, December 6, 2021 at 3:22:26 PM UTC+1 Mike Taylor wrote:

To circle back - last week we (myself + some other
privacy/anti-covert tracking reviewers) met with some folks
working on this feature. We ended up with an AI for Hongchan to
land metrics on the values that getOutputTimestamp would produce
(if called, when a new AudioContext is created, IIRC) as a way to
get some data on the utility for using either of these APIs for
device fingerprinting.

On 12/1/21 11:27 AM, Hongchan Choi wrote:

So far we have not discussed the deprecation plan, but I believe
that's reasonable as well.

I registered myself to the webkit-dev list to post a question,
but somehow I am getting 403 forbidden. The email is sent to the
list, I am not seeing the message is getting posted on the list.
Not sure what to do there.

On Wed, Dec 1, 2021 at 3:18 AM Yoav Weiss
 wrote:

So are y'all planning to deprecate and remove
`getOutputTimestamp` once this ships? If so, that sounds
reasonable.

I note Chris asked y'all to file for a webkit signal
upthread. Did that happen?

On Tuesday, November 30, 2021 at 12:54:17 AM UTC+1 hongchan
wrote:

I agree that outputLatency is better in terms of both
usability and interoperability.

FYI, the counter shows getOutputTimestamp is about 0.001%
and there are no partners who are using this API:

https://chromestatus.com/metrics/feature/popularity#AudioContextGetOutputTimestamp

<https://chromestatus.com/metrics/feature/popularity#AudioContextGetOutputTimestamp>


On Mon, Nov 22, 2021 at 3:00 PM Chris Cunningham
 wrote:

Re: privacy discussion, Hongchan and I scheduled to
meet with Paul Jensen next week.

Also, I recently determined that this new WebAudio
API (outputLatency) is largely redundant with an
existing API (getOutputTimestamp()).
https://github.com/WebAudio/web-audio-api/issues/2461
<https://github.com/WebAudio/web-audio-api/issues/2461>

Chrome has already shipped the latter API, so I
believe this new API doesn't add potential for
additional fingerprinting. Shipping both APIs is
still a good idea for the sake of inter-op.

On Friday, November 19, 2021 at 8:45:28 AM UTC-8
hongchan wrote:

Thanks for the clarification, Yoav!

I hope the mitigation approach in the previous
comment makes sense from the privacy perspective,
but it will hurt the usability/value of this API
significantly.
For the privacy-focused discussion, should I use
other venues rather than this I2S thread?

Cheers,
Hongchan


On Thu, Nov 18, 2021 at 10:35 PM Yoav Weiss
 wrote:

Apologies, I misread the discussion. A spec
issue is indeed not needed, as this is
already covered.

From my perspective, since this exposes
active entropy, the fact that it exposes more
data than the (passively exposed) platform is
not prohibitive on its own.
At the same time, it'd be good to work with
privacy-focused folks to make sure we expose
as little information as needed to maintain
the API's functionality, but not more.

On Fri, Nov 19, 2021 at 4:57 AM Chris
Cunningham  wrote:

> If the reported value is incorrect, the
A/V synchronization won't be possible.
(Perhaps chcunningham@ can say more about
this use case.)

The typical video player design drives
the clock with audio. In short, you send
buffers of audio to the OS, use the
latency value to know when those buffers
actually reach the user's ears, and
choose a video frame accordingly. Apps
using WebCodecs will design apps this way
(example here

<https

Re: [blink-dev] Intent to Ship: Remove font-family -webkit-standard

2021-12-15 Thread Mike Taylor


Awesome - appreciate the extra due diligence here.

LGTM2

On 12/15/21 9:18 AM, Yoav Weiss wrote:

*LGTM1*
*
*
Thanks for doing the work of verifying this is not a breaking change!

On Wed, Dec 15, 2021 at 3:17 PM Yoav Weiss  wrote:

The public equivalent is

https://docs.google.com/spreadsheets/d/1WZTRBujaaFrtUaRnBOoVYzJkZuColXFN-GgToF6nR5Q/edit#gid=73457229

On Wed, Dec 15, 2021 at 2:46 PM Mike Taylor
 wrote:

Hi Sonia,

Could you please make this spreadsheet public?

thanks,
Mike

On 12/15/21 7:38 AM, Sonia Singla wrote:

Link to spreadsheet[0]


[0]

https://docs.google.com/spreadsheets/d/1lChXA87u2r7yuBdfJu283UDsGhRGqT9ol2rVwVOQw0o/edit?resourcekey=0-yCKFjRfFk0RYeNm-d6DvFw#gid=1758573992

On Wednesday, December 15, 2021 at 2:37:19 PM UTC+2 Sonia
Singla wrote:

Hi Everyone,

So I tested some pages on mac and did not find any visual
changes or anything is breaking for the links I tested. I
updated the sheet[0]. Once we get the approvals to remove
the property, I will be working on patches

Sonia
CE Intern
Igalia


On Thursday, December 9, 2021 at 2:44:01 PM UTC+2
fw...@igalia.com wrote:

Sorry for the delay to come back to you. I had
started to check a few pages provided by Yoav
manually and it seems similar pattern shows up: the
counter is hit when the page specifies "font-family:
-webkit-standard;" or (more rarely) "font-family:
-webkit-standard, serif;" on some elements (*). This
is similar to what Mike found on github and the same
remarks apply, in particular:

- that may theorically change the rendering, but more
investigation is needed to be sure.
- -webkit-standard would internally be used as a
fallback anyway so there is no risk of missing glyphs
if we ignore user-specified one.

I discussed with Sonia Singla (coding experience
student at Igalia) and she was interested in
double-checking a few pages visually on macOS (since
that's where the main concern is) to see if anything
is broken, as well as finishing the work of landing
this patch. We will comment further when this is done.

(*) For completeness, see the attached output of the
following bash command:

for url in `cat $TEXT_FILE_WITH_THE_LIST_OF_URLS`; do
    echo $url
    $CONTENT_SHELL --run-web-tests $url 2>&1 | grep
FamilyNameFromSettings | sed
's/.*FontSelector::FamilyNameFromSettings /  /'
    echo
done

with the following patch logging the font-family when
the counter is hit:

---
a/third_party/blink/renderer/platform/fonts/font_selector.cc
+++
b/third_party/blink/renderer/platform/fonts/font_selector.cc
@@ -49,6 +49,7 @@ AtomicString
FontSelector::FamilyNameFromSettings(
 UseCounter::Count(
 use_counter,
WebFeature::kFontSelectorCSSFontFamilyWebKitPrefixStandard);
+    LOG(INFO) <<
"FontSelector::FamilyNameFromSettings " <<
font_description.Family().ToString().Utf8().data();
   }


Le 08/12/2021 à 17:56, Mike West a écrit :

Friendly-pinging Mike's ping of Rick's suggestion.
Is that analysis something you can spend some time
on before we ship this?

-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/d597b804-a96d-1405-b840-82ca22197b9a%40chromium.org.

Re: [blink-dev] Intent to Ship: Remove font-family -webkit-standard

2021-12-15 Thread Mike Taylor


Hi Sonia,

Could you please make this spreadsheet public?

thanks,
Mike

On 12/15/21 7:38 AM, Sonia Singla wrote:

Link to spreadsheet[0]


[0] 
https://docs.google.com/spreadsheets/d/1lChXA87u2r7yuBdfJu283UDsGhRGqT9ol2rVwVOQw0o/edit?resourcekey=0-yCKFjRfFk0RYeNm-d6DvFw#gid=1758573992


On Wednesday, December 15, 2021 at 2:37:19 PM UTC+2 Sonia Singla wrote:

Hi Everyone,

So I tested some pages on mac and did not find any visual changes
or anything is breaking for the links I tested. I updated the
sheet[0]. Once we get the approvals to remove the property, I will
be working on patches

Sonia
CE Intern
Igalia


On Thursday, December 9, 2021 at 2:44:01 PM UTC+2 fw...@igalia.com
wrote:

Sorry for the delay to come back to you. I had started to
check a few pages provided by Yoav manually and it seems
similar pattern shows up: the counter is hit when the page
specifies "font-family: -webkit-standard;" or (more rarely)
"font-family: -webkit-standard, serif;" on some elements (*).
This is similar to what Mike found on github and the same
remarks apply, in particular:

- that may theorically change the rendering, but more
investigation is needed to be sure.
- -webkit-standard would internally be used as a fallback
anyway so there is no risk of missing glyphs if we ignore
user-specified one.

I discussed with Sonia Singla (coding experience student at
Igalia) and she was interested in double-checking a few pages
visually on macOS (since that's where the main concern is) to
see if anything is broken, as well as finishing the work of
landing this patch. We will comment further when this is done.

(*) For completeness, see the attached output of the following
bash command:

for url in `cat $TEXT_FILE_WITH_THE_LIST_OF_URLS`; do
    echo $url
    $CONTENT_SHELL --run-web-tests $url 2>&1 | grep
FamilyNameFromSettings | sed
's/.*FontSelector::FamilyNameFromSettings /  /'
    echo
done

with the following patch logging the font-family when the
counter is hit:

--- a/third_party/blink/renderer/platform/fonts/font_selector.cc
+++ b/third_party/blink/renderer/platform/fonts/font_selector.cc
@@ -49,6 +49,7 @@ AtomicString
FontSelector::FamilyNameFromSettings(
 UseCounter::Count(
 use_counter,
WebFeature::kFontSelectorCSSFontFamilyWebKitPrefixStandard);
+    LOG(INFO) << "FontSelector::FamilyNameFromSettings " <<
font_description.Family().ToString().Utf8().data();
   }


Le 08/12/2021 à 17:56, Mike West a écrit :

Friendly-pinging Mike's ping of Rick's suggestion. Is that
analysis something you can spend some time on before we ship
this?

-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/0a980b69-6586-330a-a273-07d611d12cf5%40chromium.org.

Re: [blink-dev] Intent to Ship: Origin Isolation By Default / Deprecate document.domain

2021-12-14 Thread Mike Taylor

On 12/14/21 11:35 AM, Daniel Bratell wrote:

It seems more or less everyone agrees on this being a good thing, so
it mainly comes down to web compatibility.

How much of the web will break, and how badly. The numbers mentioned,
0.5% of sites set document.domain, 0.05% seem to depend on
document.domain, are quite high. One thing I didn't quite pick up is
what happens if you try to set document.domain when it's not settable.
Will it silently pretend to work, or will that also be a possible
break point?

I would be surprised if it didn't behave the same as setting an
arbitrary expando on `document` - we should be safe there.

There is also the question of reverse origin trial and enterprise
flags. If Origin-Agent-Cluster can be set with http-equiv="">, then I don't see any use for an origin trial since
that would be activated the same way. An enterprise flag might still
be needed though, since that covers installations where the client can
be configured, but applications can not be changed.

/Daniel

On 2021-12-14 15:06, Daniel Vogelheim wrote:

Contact emails

v...@chromium.org ,
vogelh...@chromium.org

Specification

Explainer:
https://github.com/mikewest/deprecating-document-domain

HTML Spec draft:
https://github.com/whatwg/html/compare/main...otherdaniel:dd

API spec

Yes

Summary

Change the default behavior of the Origin-Agent-Cluster:
header / document.domain settability.

Presently, pages within Chromium have site-keyed agent
clusters by default, unless the Origin-Agent-Cluster: header
is explicitly set to true. This accommodates pages or frames
which want to access each other's state, despite being on
different origins (but within a site). This is fine for any
pages that wish to do so, but because a page *might* set
document.domain later on, Chromium currently must use
site-keyed agent clusters for *all* pages by default even
though the overwhelming majority of pages do not ever make
use of this (mis-)feature. In turn, this requires Chromium to
use sites as the basis for renderer process isolation (via
Site Isolation), which exposes origins to same-site but
cross-origin attacks involving compromised renderer processes
or the "Spectre" family of side-channel attacks.

This proposal changes the default behaviour of
Origin-Agent-Cluster. From a developer's point of view, the
new default matches "Origin-Agent-Cluster: ?1". The initial
implementation will use origin-keyed agent clusters for all
(non-opted out) origins, without changing how many processes
Chromium creates. Over time, we can then adapt Chromium's
isolation strategy towards origin-keyed processes without
further affecting web-visible behaviour.

The developer-visible aspect of this is that for pages with
origin-keyed agent clusters, document.domain is no longer
settable. Thus, we have marked this intent as a deprecation.

Note that this proposal is about the default. Both modes -
site-keyed or origin-keyed agent clusters - remain available
to any site, but origin-keyed agent clusters change from
opt-in to opt-out. The current behaviour remains available by
setting "Origin-Agent-Cluster: ?0".

Blink component

Blink>SecurityFeature

TAG review

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

(The thread is a bit unwieldy, but there do not seem to be
open issues.)

Risks: Interoperability and Compatibility

No interoperability risks.

Compatibility risk exists, but is fairly small as document.domain is
an already deprecated feature. We’ve detailed UKM metrics in place
and are planning to reach out to top users as soon as we’ve LGTMs for
the plan.
As Daniel mentioned, I think the compat risk should be considered to be
higher, despite this being deprecated for a long time.

Current usage of the document.domain: 0.05%
of
page views rely upon document.domain to enable some cross-origin
access that wasn't otherwise possible. 0.24%
of
page views block same-origin access because only one side sets
document.domain. Both counters can be found
onhttps://deprecate.it/#document-domain

< 4 5 6 7 8 9 10 >

801 - 900 of 936 matches

Mail list logo