Re: [blink-dev] Re: Native support of Windows SSO in Chrome

['Yutaka Hirano' via blink-dev]

I have some questions.

 - Is the proposal that Chrome detects such a redirect and sends an
authentication request to IDP?
 - Is there at most one IDP for a profile?
 - How is IDP registered to Chrome?

Thanks,

On Fri, Sep 24, 2021 at 6:18 AM Owen Min  wrote:

> +people who may be interested in this.
>
> On Thursday, September 23, 2021 at 12:21:51 PM UTC-4 Sasha Tokarev wrote:
>
>> Hi all,
>>
>> I have a proposal to integration with Windows SSO in Chrome.
>>
>> Currently Windows has ability to join device to cloud identity, like AAD,
>> MSA. When a device is joined to a cloud identity provider (IDP), it would
>> be great if I’m as a user do not need enter credentials, when I’m using a
>> service, which uses IDP where my device is joined to. I’m consented to have
>> single sign on (SSO) when I joined the device, and trust IDP to protect my
>> identity and do not allow an authorized access. If I do not trust, I should
>> not join my device. Additionally, sometimes web resources, that I’m
>> accessing to as a user, are owned by organization where I work or study.
>> Hence, an organization administrator should be able to manage access to
>> such resources based on the quality of my device, e.g., prevent access if
>> the device doesn’t make malware scans or doesn’t have latest security
>> patches etc.
>>
>> Edge has this feature built in, in Chrome we must use a special extension
>> https://chrome.google.com/webstore/detail/windows-10-accounts/ppnbnpeolgkicgegkbkbjmhlideopiji
>>
>> While using extension works, the built-in experience is better, as we
>> have with Windows Integrated authentication.
>>
>> In high level it should work like this, if I’m accessing to a resource,
>> from a joined device.
>>
>>1. *Resource* (e.g., www.mywork.com) will redirect me for the
>>authentication to the cloud identity provider(
>>https://login.microsoftonline.com). The request will have a redirect
>>URI that IDP will use to return a token.
>>2. *User agent* (Chrome) will detect this navigation and call an OS
>>API for producing a crypto-protected SSO cookies, which has device and 
>> user
>>information. This cookie will be appended to the request as a header or
>>cookie.
>>3. *Cloud identity provider* ( https://login.microsoftonline.com ):
>>   1. Detects presence of the SSO cookies, validates them by checking
>>   signature, and authenticates the user and device.
>>   2. Validates that the supplied redirect uri is registered for this
>>   application.
>>   3. Validates if the resource owner (enterprise admin or user)
>>   authorizes access to the resource.
>>   4. Applies consent policy and ask consent if needed, for example
>>   enterprises, when they own the resource can pre-consent access by their
>>   employees. Note, It is responsibility of IDP to ensure that only 
>> authorized
>>   and consented applications can access users’ identity.
>>   5. Read device identity, and checks the state of device, that
>>   reported out of band by device management system.
>>   6. If all checks are fine, the IDP redirect back to the resource
>>   with a token.
>>4. *User agent* (Chrome) should not do much, just to make sure it
>>will not include SSO headers (as in case of some HTTP Redirects user-agent
>>repeats the same headers) and cookies to the resource, to prevent its
>>disclosure.
>>5. *Resource* gets the token and provides service to the user.
>>
>>
>>
>> Note, a malicious web site will not be able to access user identity
>> without explicit user consent, and if it is an enterprise account, then it
>> should check admin authorization for this application. One may think that
>> if we have SSO, now we need to think about protection from malicious web
>> sites. However, this issue is not relevant to SSO, as if a user has either
>> MSA or AAD, most likely she or he will enter credentials at some moment,
>> and IDP will store persistent cookie. As a result, IDP still needs to
>> protect from a malicious web site, that is why all protocols that use
>> redirection has special handling for such cases, i.e. the IDP must redirect
>> on initially pre-registered for this client redirect URI
>> https://datatracker.ietf.org/doc/html/rfc6749#section-3.1.2
>>
>> SSO itself reduces number of prompts, OS cookies are hardware crypto
>> protected and short-lived, while protection of web-cookies is lower.
>> Integration with OS SSO not just a convenience feature but increases users’
>> security.
>>
>>
>>
>> Thank you,
>> Aleksandr
>>
> --
> 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/bc1fb9ba-2951-4d59-aec1-aed2e88fd584n%40chromium.org
> 

Re: [blink-dev] Intent to Ship: HTMLScriptElement.supports(type) method

[Yoav Weiss]

On Fri, Sep 24, 2021 at 5:42 AM Tsuyoshi Horo  wrote:

> Thank you very much for LGTMs!
>
>
>
>> RisksInteroperability and Compatibility
>>>
>>> This method provides a synchronous way of feature detections. But for
>>> unsupported browsers, developers need to use an asynchronous way as
>>> discussed at https://github.com/WICG/import-maps/issues/171.
>>>
>>
>> Is it worthwhile to document the desired code patterns we want developers
>> to use? (e.g. test is `supports()` exists and fallback to the async method
>> otherwise)
>>
>
> Yes. Sure. I  updated this doc
> 
> to explain how to detect the importmap support
> without HTMLScriptElement.supports(type) method.
>

That's great! It would be similarly great if that finds itself into
developer-facing documentation (MDN, web.dev, etc). Searching around, I
can't find any for neither this nor import maps :/


>
>
>
> On Fri, Sep 24, 2021 at 4:24 AM Domenic Denicola 
> wrote:
>
>>
>>
>> On Thu, Sep 23, 2021 at 3:15 PM Alex Russell 
>> wrote:
>>
>>> LGTM3
>>>
>>> Would like to see a concrete plan for expanding this method to other
>>> media-loading elements (, 

Re: [blink-dev] Intent to Ship: HTMLScriptElement.supports(type) method

['Tsuyoshi Horo' via blink-dev]

Thank you very much for LGTMs!



> RisksInteroperability and Compatibility
>>
>> This method provides a synchronous way of feature detections. But for
>> unsupported browsers, developers need to use an asynchronous way as
>> discussed at https://github.com/WICG/import-maps/issues/171.
>>
>
> Is it worthwhile to document the desired code patterns we want developers
> to use? (e.g. test is `supports()` exists and fallback to the async method
> otherwise)
>

Yes. Sure. I  updated this doc

to explain how to detect the importmap support
without HTMLScriptElement.supports(type) method.



On Fri, Sep 24, 2021 at 4:24 AM Domenic Denicola 
wrote:

>
>
> On Thu, Sep 23, 2021 at 3:15 PM Alex Russell 
> wrote:
>
>> LGTM3
>>
>> Would like to see a concrete plan for expanding this method to other
>> media-loading elements (, 

[blink-dev] Intent to Ship: WebAssembly Content Security Policy

[Francis McCabe]

Contact emailsad...@chromium.org
f...@chromium.org

Explainer
https://github.com/WebAssembly/content-security-policy/blob/master/proposals/CSP.md

Specificationhttps://github.com/w3c/webappsec-csp/pull/293

Design docs
https://github.com/WebAssembly/content-security-policy/blob/master/proposals/CSP.md

Summary

Enhancements to Content Security Policy to improve interoperability with
WebAssembly.
The change involves adding a new CSP source keyword: wasm-unsafe-eval that
would allow a web page to compile and execute WebAssembly modules.

Blink componentBlink


Search tagswasm ,
webassembly , csp


TAG reviewNot needed in our view, as this is a very small change to
existing CSP functionality.

TAG review status

Risks


Interoperability and Compatibility



Gecko: https://github.com/mozilla/standards-positions/issues/580

WebKit:
https://lists.webkit.org/pipermail/webkit-dev/2021-August/031974.html

Web developers: There has been a considerable amount of discussion of this
within the WebAppSec WG and there is some pressure from developers to adopt
this (see https://bugs.chromium.org/p/chromium/issues/detail?id=841404 and
https://bugs.chromium.org/p/chromium/issues/detail?id=948834 and
https://bugs.chromium.org/p/chromium/issues/detail?id=915648)


Debuggability



Is this feature fully tested by web-platform-tests

?Yes * CL https://chromium-review.googlesource.com/c/chromium/src/+/3171519
under
review

Flag nameBlink feature flag WebAssemblyCSP

Requires code in //chrome?False

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

Estimated milestones

M96

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

-- 
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/CAE65UWAc3Y07YDx%2B%3DiKRboZZGFGXzE5FbufUnY__0_w8nsXSRA%40mail.gmail.com.

[blink-dev] Re: Native support of Windows SSO in Chrome

[Owen Min]

+people who may be interested in this.

On Thursday, September 23, 2021 at 12:21:51 PM UTC-4 Sasha Tokarev wrote:

> Hi all,
>
> I have a proposal to integration with Windows SSO in Chrome.
>
> Currently Windows has ability to join device to cloud identity, like AAD, 
> MSA. When a device is joined to a cloud identity provider (IDP), it would 
> be great if I’m as a user do not need enter credentials, when I’m using a 
> service, which uses IDP where my device is joined to. I’m consented to have 
> single sign on (SSO) when I joined the device, and trust IDP to protect my 
> identity and do not allow an authorized access. If I do not trust, I should 
> not join my device. Additionally, sometimes web resources, that I’m 
> accessing to as a user, are owned by organization where I work or study. 
> Hence, an organization administrator should be able to manage access to 
> such resources based on the quality of my device, e.g., prevent access if 
> the device doesn’t make malware scans or doesn’t have latest security 
> patches etc.
>
> Edge has this feature built in, in Chrome we must use a special extension 
> https://chrome.google.com/webstore/detail/windows-10-accounts/ppnbnpeolgkicgegkbkbjmhlideopiji
>
> While using extension works, the built-in experience is better, as we have 
> with Windows Integrated authentication.
>
> In high level it should work like this, if I’m accessing to a resource, 
> from a joined device.
>
>1. *Resource* (e.g., www.mywork.com) will redirect me for the 
>authentication to the cloud identity provider(
>https://login.microsoftonline.com). The request will have a redirect 
>URI that IDP will use to return a token.
>2. *User agent* (Chrome) will detect this navigation and call an OS 
>API for producing a crypto-protected SSO cookies, which has device and 
> user 
>information. This cookie will be appended to the request as a header or 
>cookie.
>3. *Cloud identity provider* ( https://login.microsoftonline.com ): 
>   1. Detects presence of the SSO cookies, validates them by checking 
>   signature, and authenticates the user and device. 
>   2. Validates that the supplied redirect uri is registered for this 
>   application.
>   3. Validates if the resource owner (enterprise admin or user) 
>   authorizes access to the resource.
>   4. Applies consent policy and ask consent if needed, for example 
>   enterprises, when they own the resource can pre-consent access by their 
>   employees. Note, It is responsibility of IDP to ensure that only 
> authorized 
>   and consented applications can access users’ identity.
>   5. Read device identity, and checks the state of device, that 
>   reported out of band by device management system.
>   6. If all checks are fine, the IDP redirect back to the resource 
>   with a token.
>4. *User agent* (Chrome) should not do much, just to make sure it will 
>not include SSO headers (as in case of some HTTP Redirects user-agent 
>repeats the same headers) and cookies to the resource, to prevent its 
>disclosure.
>5. *Resource* gets the token and provides service to the user.
>
>  
>
> Note, a malicious web site will not be able to access user identity 
> without explicit user consent, and if it is an enterprise account, then it 
> should check admin authorization for this application. One may think that 
> if we have SSO, now we need to think about protection from malicious web 
> sites. However, this issue is not relevant to SSO, as if a user has either 
> MSA or AAD, most likely she or he will enter credentials at some moment, 
> and IDP will store persistent cookie. As a result, IDP still needs to 
> protect from a malicious web site, that is why all protocols that use 
> redirection has special handling for such cases, i.e. the IDP must redirect 
> on initially pre-registered for this client redirect URI 
> https://datatracker.ietf.org/doc/html/rfc6749#section-3.1.2 
>
> SSO itself reduces number of prompts, OS cookies are hardware crypto 
> protected and short-lived, while protection of web-cookies is lower. 
> Integration with OS SSO not just a convenience feature but increases users’ 
> security.
>
>  
>
> Thank you,
> Aleksandr
>

-- 
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/bc1fb9ba-2951-4d59-aec1-aed2e88fd584n%40chromium.org.

[blink-dev] Intent to Ship: HTTP->HTTPS redirect for HTTPS DNS records

[Eric Orth]

Contact emails

erico...@chromium.org

Explainer

None

Specification

https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-07

Summary

Query DNS for HTTPS records (alongside traditional A and  queries).
When a website has deployed an HTTPS DNS record and Chrome receives it,
Chrome will always connect to the website via HTTPS.

Design doc for all Chrome DNS HTTPS plans:
https://docs.google.com/document/d/1k461sRbddjDGj7Q8f-ZKHZvmB-ENUWSdX_3Fpp2dmXQ

This feature covers just the basic query and HTTP->HTTPS upgrade part of
those plans, and only for simpler cases that do not require followup DNS
queries by the Chrome DNS stack.


Blink component

Internals>Network>DNS


TAG review

Not applicable. No direct changes to web platform APIs. Change is to
underlying DNS infrastructure, following an IETF spec, with only indirect
web-facing side effects.

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Not directly part of the web API surface; only has indirect behavior
implications on the web platform in the form of the HTTP->HTTPS redirect
triggered by DNS signals.

HTTPS DNS records are a feature of DNS.  The spec is a draft of the IETF
DNSOP working group, and while not yet a published RFC, it is widely
considered stable and ready for implementation.  IANA has designated HTTPS
as DNS resource record type 65.


Gecko: No signal

WebKit: Safari has been querying HTTPS DNS records since late 2020. Unclear
if Safari has yet implemented HTTP->HTTPS redirect behavior of such records.

Web developers: No signals


Debuggability

No specific DevTools support.  Changes not directly part of the web API
surface.  Chrome is not generally used as a development tool for changing
DNS records besides testing/developing the indirect behavior effects on
visiting websites.


Is this feature fully tested by web-platform-tests

?

No

Flag name

None

Requires code in //chrome?

False

Tracking bug

https://crbug.com/1206455

Launch bug

https://crbug.com/1206460

Estimated milestones

Desktop 96

Android 96

Link to entry on the Chrome Platform Status

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

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/CAMOjQcEJF4%3D7zU16oki_m0vYqfX2_%2BXgH2Fxf51RnMv9ipx63w%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: HTMLScriptElement.supports(type) method

[Domenic Denicola]

On Thu, Sep 23, 2021 at 3:15 PM Alex Russell 
wrote:

> LGTM3
>
> Would like to see a concrete plan for expanding this method to other
> media-loading elements (, 

Re: [blink-dev] Intent to Ship: HTMLScriptElement.supports(type) method

[Alex Russell]

LGTM3

Would like to see a concrete plan for expanding this method to other 
media-loading elements (, 

Re: [blink-dev] Intent to Extend Origin Trial: Conversion Measurement API (Attribution Reporting API)

[Alex Russell]

LGTM3 to extend to 95

On Tuesday, September 21, 2021 at 7:26:16 AM UTC-7 Chris Harrelson wrote:

> LGTM2
>
> On Mon, Sep 20, 2021, 10:38 PM Yoav Weiss  wrote:
>
>> O(10) sounds manageable in case we want to change course, so that reduces 
>> the burn-in risk.
>> Since this is an atypical OT extension, approving it would require 3 
>> LGTMs.
>>
>> *LGTM1* to extend experimentation till M95.
>>
>> On Mon, Sep 20, 2021 at 7:09 PM John Delaney  
>> wrote:
>>
>>> Hi Alex,
>>>
>>> Given that this is an x-origin OT, relatively high use might not be the 
 whole picture, so it would be great to know in addition how many 
 individual 
 teams have signed up to use the OT. Is dozens? Hundreds? Thousands?
>>>
>>> There are O(10) teams experimenting with the API.
>>>
>>> On Thu, Sep 16, 2021 at 3:25 PM Alex Russell  
>>> wrote:
>>>
 Discussed at today's API OWNERS, the relatively high use plus the 
 length of the ongoing trial adds a level of concern. Given that this is an 
 x-origin OT, relatively high use might not be the whole picture, so it 
 would be great to know in addition how many individual teams have signed 
 up 
 to use the OT. Is dozens? Hundreds? Thousands?

 Thanks.

 Best Regards,

 Alex

 On Wednesday, September 15, 2021 at 9:10:55 AM UTC-7 John Delaney wrote:

> Can you link to previous extension requests?
>>
> First extension: 
> https://groups.google.com/a/chromium.org/g/blink-dev/c/C0P7ePjITJQ/m/ZYFmn30SDQAJ
>   
> 
> Second extension: 
> https://groups.google.com/a/chromium.org/g/blink-dev/c/xCWP1ltlAgw/m/acwN0GIRBQAJ
>
> M86 went to stable almost a year ago. What's the plan beyond M94? 
>> Assuming that the bug is fixed, will the experiment end there? Would you 
>> be 
>> able to share learnings from the trial? Are you planning to ship the API 
>> in 
>> its current form?
>
>
> We intend to end the experiment in 95. We are currently working on a 
> number of significant extensions/changes to the API including: aggregate 
> reports [1], support for views [2], and others. These support use-cases 
> which are not covered in the currently implemented "Event-level Click" 
> API. 
> We plan to start a "V2" experiment when this new functionality is 
> available 
> which we believe will produce new, different insights from developers. We 
> are not currently planning to ship Attribution Reporting without first 
> experimenting with those extensions.
>
> We can certainly share learnings with respect to the "Event-level 
> Click" API when this initial experiment concludes. 
>
> [1] 
> https://groups.google.com/a/chromium.org/g/blink-dev/c/2zA5-TuVSkA/m/GVqUUkhfAwAJ
> [2] 
> https://github.com/WICG/conversion-measurement-api/blob/main/event_attribution_reporting_views.md
>
> On Tue, Sep 14, 2021 at 12:06 AM Yoav Weiss  
> wrote:
>
>>
>>
>> On Sat, Sep 11, 2021 at 12:01 AM John Delaney  
>> wrote:
>>
>>> *Contact emails*
>>> johni...@chromium.org, csharri...@chromium.org
>>>
>>> *Explainer*
>>>
>>> https://github.com/WICG/conversion-measurement-api/blob/main/event_attribution_reporting_clicks.md
>>>
>>> *Design docs/spec*
>>> https://wicg.github.io/conversion-measurement-api/
>>>
>>> *Summary*
>>> This is a new API for measuring conversions (e.g. purchases) and 
>>> attributing them to clicked ads, without using cross-site persistent 
>>> identifiers like third party cookies.
>>>
>>> *Link to “Intent to Prototype” blink-dev discussion*
>>>
>>> https://groups.google.com/a/chromium.org/d/msg/blink-dev/7B0ldtZR_68/GjLBu0n4DgAJ
>>>  
>>> *Link to “Intent to Experiment” blink-dev discussion*
>>>
>>> https://groups.google.com/a/chromium.org/d/msg/blink-dev/Ib9-tDFitns/Sm9RXTNaBwAJ
>>>
>>
>> Can you link to previous extension requests?
>>  
>>
>>>
>>> *Goals for experimentation*
>>> For a continuation of the trial, we still hope to see that the 
>>> measurement data made available through the API produces comparable 
>>> results 
>>> to existing click through measurement solutions on the web.
>>>
>>> We would like to see that Chrome 94 addresses the reporting issue 
>>> documented here:
>>>
>>> https://groups.google.com/a/chromium.org/g/attribution-reporting-api-dev/c/2KKqWG70w7U/m/7M8fWEbmAgAJ
>>>
>>
>> That seems reasonable.
>>  
>>
>>>
>>> *Experimental timeline*
>>> We'd like to extend the origin trial for one additional milestone, 
>>> continuing through M94. The experiment has been running since M86.
>>>
>>  
>> M86 went to stable almost a year ago. What's the plan beyond M94? 
>> Ass

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

[Yoav Weiss]

Thanks for clarifying!

On Thu, Sep 23, 2021 at 7:45 PM Martin Kreichgauer 
wrote:

> Thanks! Just to be clear, the deprecation trial is beginning with M95, but
> it would only be *required* by M98 when we disable the U2F API by
> default. M104 is where we plan to delete the API, so M103 would be the last
> release where the deprecation trial is functional.
>
> On Thu, Sep 23, 2021 at 5:18 AM Yoav Weiss  wrote:
>
>> So IIUC, the deprecation trial would run from M98-M104. That seems like a
>> reasonable time period to give to folks and enable them to adjust.
>> Still LGTM.
>>
>> On Wed, Sep 22, 2021 at 10:32 PM 'Martin Kreichgauer' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> Dear blink-dev,
>>>
>>> I wanted to provide an update on our progress with the U2F API
>>> deprecation effort and request a short extension for removal of the API and
>>> the end date of the Reverse Origin Trial.
>>>
>>> First, the changes originally announced for Chrome 94 are now scheduled
>>> to ship instead with Chrome 95. These changes include gating of U2F API
>>> requests behind a permission prompt, deprecation warnings logged to the
>>> developer console, and  a Reverse Origin Trial
>>> 
>>> .
>>>
>>> We still plan to disable the U2F API by default with Chrome 98.
>>>
>>> We also have been in close contact about this deprecation with partners
>>> who still rely on the U2F API. In some of these conversations, partners
>>> asked us to allow a little more time for them to migrate their websites to
>>> the WebAuthn. We therefore would like to push back removal of the U2F API
>>> to Chrome 104, and to extend the Reverse Origin Trial to the same time
>>> period.
>>>
>>> Thanks,
>>> Martin
>>>
>>>
>>> On Friday, June 11, 2021 at 11:34:24 AM UTC-7 Martin Kreichgauer wrote:
>>>
 Primary eng (and PM) emails

 mart...@google.com, a...@chromium.org

 Summary

 We want to deprecate and remove the legacy U2F API for interacting with
 security keys. (But not U2F security keys themselves, which will continue
 to work.)

 Affected sites should migrate to the Web Authentication API (WebAuthn).
 Credentials that were originally registered via the U2F API can be
 challenged via WebAuthn. USB security keys that are supported by the U2F
 API are also supported by the WebAuthn API.

 Motivation

 U2F is Chrome’s original security key API. It allows sites to register
 public key credentials on USB security keys and challenge them for building
 phishing-resistant two-factor authentication systems. U2F never became an
 Open Web standard and was subsumed by WebAuthn (launched in M67
 ). Chrome never
 directly supported the FIDO U2F JavaScript API in Blink, but rather shipped
 a component extension called cryptotoken, which exposes an equivalent
 chrome.runtime.sendMessage API. U2F and Cryptotoken are firmly in
 maintenance mode and we encouraged sites to migrate to WebAuthn
 
 two years ago.

 U2F’s continued existence presents several issues:

-

Cryptotoken requests don’t trigger a permission prompt or any UI
indicating that the website is interacting with a special type of USB
device. Instead we rely on the website to handle UI for the requested
security key interaction. We believe this isn’t ideal from a secure UX
perspective. WebAuthn presents either a tab-modal dialog or UI provided 
 by
the operating system for every request.
-

Sites can unconditionally query U2F credentials when embedded in
cross-origin iframes. WebAuthn guards this behavior behind a feature 
 policy.


-

Because Cryptotoken is a component extension and externally
connectable from any URL, it effectively exposes the chrome.runtime APIs
unconditionally to the entire web. Removing cryptotoken will allow us to
make these APIs unavailable to websites that are not explicitly listed 
 as
connectable by an extension.
-

WebAuthn has subsumed U2F and we don’t want to encourage new use of
an old API.


 googleLegacyAppIdSupport extension

 The factory image on some Android devices predates WebAuthn’s existence
 and therefore only supports the U2F API. Because credentials registered via
 WebAuthn cannot be challenged via U2F, Google continues to require a
 mechanism for registering U2F-compatible security key credentials even
 after the U2F API has been removed from Chrome, or else users that register
 a security key on their desktop would be unable to sign into their affected
 Android devices with that security key

Re: [blink-dev] Re: Intent to Ship: Web Serial API

[Nick Bond]

Is this ready for production use now or is it still experimental? Will the 
Spec change?

Thanks!

Nick

On Wednesday, January 13, 2021 at 8:40:09 PM UTC-6 rei...@chromium.org 
wrote:

> Thanks. Over the holidays I forgot that he'd already approved it.
>
> Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome 
> 
>
>
> On Fri, Jan 8, 2021 at 2:58 PM Chris Harrelson  
> wrote:
>
>> Yes, gapless LGTM, per what Mike said.
>>
>> On Fri, Jan 8, 2021 at 2:44 PM Reilly Grant  wrote:
>>
>>> Do API OWNERS approve the requested gapless transition from Origin Trial 
>>> to stable?
>>> Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome 
>>> 
>>>
>>>
>>> On Thu, Dec 17, 2020 at 12:21 PM Chris Harrelson  
>>> wrote:
>>>
 LGTM3

 On Thu, Dec 17, 2020 at 12:00 PM Mike West  wrote:

> LGTM2.
>
> Similar to the WebHID API, I'm happy with the work the team has done 
> to address security and privacy concerns. The interaction model has 
> proven 
> effective, there's a good story around user-facing indicators, and we 
> have 
> the ability to cut off access to devices when that proves to be 
> particularly dangerous. The implementation puts the user in control, and 
> I'm excited to see it launch.
>
> With regard to the gapless OT, there's good evidence of developer 
> feedback, and equally good evidence that the API has changed in response. 
> Given that we have confidence in the shape of the API, it seems 
> reasonable 
> to me to move it directly from OT to stable without enforcing a gap in 
> availability. So, that bit specifically LGTM.
>
> -mike
>
>
>
> On Thursday, December 17, 2020 at 8:23:35 PM UTC+1 yo...@yoav.ws 
> wrote:
>
>>
>> *LGTM1*
>>
>> This seems like an important addition to the web platform, that 
>> enables unique use-cases 
>> 
>>  
>> that were previously reserved to native apps, with their associated 
>> deployment pain. Thanks for working on this!!
>>
>> On Friday, December 11, 2020 at 5:34:51 AM UTC+1 Fergal Daly wrote:
>>
>>> Thanks!
>>>
>>> F
>>>
>>> On Thu, 10 Dec 2020 at 07:07, Reilly Grant  
>>> wrote:
>>>
 I've met with the BFCache team to figure out how to support BFCache 
 with WebUSB, and supporting it with Web Serial will have similar 
 challenges. I've filed https://github.com/WICG/serial/issues/109 
 to track defining the integration points so that we can avoid 
 continuing to 
 blocklist all pages that are using Web Serial as we currently do.
 Reilly Grant | Software Engineer | rei...@chromium.org | Google 
 Chrome 


 On Wed, Dec 9, 2020 at 1:32 AM Fergal Daly  
 wrote:

> [+bfcache-dev]
>
> Hi Reilly,
>
> how does WebSerial interact with Chrome's BFCache 
> ? Can we make it so that a page that 
> has an open serial connection can safely be put into BFCache and will 
> work 
> when it comes out without breaking user expectations (that they had 
> navigated away from the page)? If not, we need to ensure that pages 
> using 
> WebSerial do not go into BFCache when it would be a problem.
>
> We have put together a doc 
> 
>  that 
> hopefully provides enough information for feature teams to figure 
> this out. 
> Could you take a look and figure out what issues there may be? It's a 
> new 
> doc so feedback on the doc itself is also appreciated. 
>
> The simplest course of action is to blocklist all pages that use 
> WebSerial but ideally we can ensure that they work well together. 
> Thanks,
>
> F
> On Saturday, December 5, 2020 at 10:16:03 AM UTC+9 Reilly Grant 
> wrote:
>
>> Contact emails
>>
>> rei...@chromium.org
>>
>> Explainer
>>
>> https://github.com/WICG/serial/blob/gh-pages/EXPLAINER.md
>>
>> Specification
>>
>> https://wicg.github.io/serial/
>>
>> API spec
>>
>> Yes.
>>
>> Design docs
>>
>> https://web.dev/serial/
>>
>> Summary
>>
>> The Serial API provides an interface for connecting to serial 
>> devices, either through a serial port on the user’s system or 
>> removable USB 
>> and Bluetoo

Re: [blink-dev] Intent to Extend Origin Trial: Trust Token API

[Daniel Bratell]

With a gap, LGTM2

/Daniel

On 2021-09-23 14:14, Yoav Weiss wrote:

As this is an atypical OT, this requires 3 LGTMs.

*LGTM1* to extend to M101, conditional on a 2 weeks gap to demonstrate 
that there's no premature reliance on the API.


On Wed, Sep 22, 2021 at 10:26 PM Steven Valdez > wrote:


Contact emails

sval...@chromium.org ,
privacy-sand...@chromium.org 


Spec


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



https://github.com/WICG/trust-token-api


Summary

This is a new API for propagating a notion of user authenticity
across sites, without using cross-site persistent identifiers like
third party cookies. Trust Token is built onPrivacy Pass
for anonymous tokens that can't be
tracked between issuance and redemption.

An Origin Trial for Trust Token started in M84 and is scheduled to
end in M94. Due to the shift in the API from a primarily
first-party issuance model to a third-party issuance model, we've
gotten feedback from partners that spinning up the complex
infrastructure and models for third-party issuance is taking
longer than anticipated, in order to give issuers more time to
experiment with this model, we'd like to extend the Origin Trial
to M101 (April 2022).


Link to “Intent to Prototype” blink-dev discussion

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



Previous Intent to Extend:


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




Goals for experimentation

For the continuation of the origin trial, we hope to continue to
get more experimental data on the value of these token-derived
signals from issuance schemes that take place in the third-party
context, rather than where a strong first-party signal is
available. Additionally, we are continuing to iterate on the API
shape and modes to bring it more in line with the underlying
Privacy Pass work being standardized in the IETF.

Experimental timeline

We'd like to extend the Origin Trial again to run to the end of
M101 (April 2022).


Any risks when the experiment finishes?

As this feature is only available via Origin Trials and doesn't
affect any existing state, we don't believe there will be any
risks once the experiment concludes. As we don't maintain
backwards compatibility between different versions of Trust Token

(https://github.com/WICG/trust-token-api/blob/main/ISSUER_PROTOCOL.md#version-history

),
as we update it based on ecosystem feedback, we don't expect there
to be ecosystem burn-in as the issuers and redeemers are still
required to update their implementations to continue functioning
in the latest version of Chrome (and the server-side components of
the API provided by the component updater maintains minimal
compatibility so that older versions of the API will cease to
function within a version release or so). As an extra measure of
safety, we can also disable the API for a couple weeks to ensure
that the ecosystem is not burning in the availability of the API.


Reason this experiment is being extended


https://groups.google.com/a/chromium.org/forum/?oldui=1#!msg/blink-dev/UIvia1WwIhk/DuXLKdF7AgAJ




Due to the complexities of issuance strategies involving purely
third-party based issuance, we've seen that issuers are needing a
longer time to spin up their infrastructure and experiment logic
in order to verify the usefulness of the API. Due to the scope and
shape of this API, we'd like to get data from issuers who are
using this API before trying to launch it, to help understand the
efficacy of the API and the parameters that the shipped version of
the API should be using/allowing.


Ongoing technical constraints

None.


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

Yes.


Link to entry on the feature dashboard 

https://chromestatus.com/feature/5078049450098688



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

Groups "blink-dev" group.

Re: [blink-dev] Intent to Ship: HTMLScriptElement.supports(type) method

[Daniel Bratell]

LGTM2

/Daniel

On 2021-09-23 12:06, Yoav Weiss wrote:

LGTM1

On Wed, Sep 22, 2021 at 5:21 AM Tsuyoshi Horo > wrote:



Contact emails

h...@chromium.org 


Explainer

https://github.com/horo-t/explainers/blob/main/script_element_supports.md



Specification

https://html.spec.whatwg.org/multipage/scripting.html#dom-script-supports



Design docs

https://github.com/horo-t/explainers/blob/main/script_element_supports.md



Summary

Provides a unified way to detect new features that use script
elements.


Blink component

Blink>HTML>Script




TAG review

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



TAG review status

Issues addressed


It should be noted that there was disagreement 
 
between the TAG and the spec authors on the naming.
While I lean towards the call the spec authors made, the need for 
better JS feature detection is something I repeatedly hear both from 
the TAG and 
 
others . Orthogonal to 
this intent, this seems like something we should eventually tackle.



Risks


Interoperability and Compatibility

This method provides a synchronous way of feature detections. But
for unsupported browsers, developers need to use an asynchronous
way as discussed athttps://github.com/WICG/import-maps/issues/171
.


Is it worthwhile to document the desired code patterns we want 
developers to use? (e.g. test is `supports()` exists and fallback to 
the async method otherwise)


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

WebKit: No signal
(https://lists.webkit.org/pipermail/webkit-dev/2021-September/031979.html
)

Web developers: Positive The developer feedback on the spec issue
(https://github.com/whatwg/html/issues/6472
) was positive.


Ergonomics

No known ergonomics risks.


Activation

No known activation risks. This method is easy to use.


Security

No known security risks.


Debuggability

Developers can call this method from DevTools's console.


Is this feature fully tested by web-platform-tests

?

Yes


DevTrial instructions


https://github.com/horo-t/explainers/blob/main/script_element_supports_how_to.md




Flag name

ScriptElementSupports


Requires code in //chrome?

False


Tracking bug

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



Sample links

https://horo-t.github.io/explainers/script_element_supports_sample.html



Estimated milestones


DevTrial on desktop95


DevTrial on android95


DevTrial on Webview95


Link to entry on the Chrome Platform Status

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



Links to previous Intent discussions

Intent to prototype:

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



Ready for Trial:

https://groups.google.com/a/chromium.org/g/blink-dev/c/-sE2GpCrG6Y/m/UsHXyVW-CAAJ



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 an

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

['Martin Kreichgauer' via blink-dev]

Thanks! Just to be clear, the deprecation trial is beginning with M95, but
it would only be *required* by M98 when we disable the U2F API by default.
M104 is where we plan to delete the API, so M103 would be the last release
where the deprecation trial is functional.

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

> So IIUC, the deprecation trial would run from M98-M104. That seems like a
> reasonable time period to give to folks and enable them to adjust.
> Still LGTM.
>
> On Wed, Sep 22, 2021 at 10:32 PM 'Martin Kreichgauer' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Dear blink-dev,
>>
>> I wanted to provide an update on our progress with the U2F API
>> deprecation effort and request a short extension for removal of the API and
>> the end date of the Reverse Origin Trial.
>>
>> First, the changes originally announced for Chrome 94 are now scheduled
>> to ship instead with Chrome 95. These changes include gating of U2F API
>> requests behind a permission prompt, deprecation warnings logged to the
>> developer console, and  a Reverse Origin Trial
>> 
>> .
>>
>> We still plan to disable the U2F API by default with Chrome 98.
>>
>> We also have been in close contact about this deprecation with partners
>> who still rely on the U2F API. In some of these conversations, partners
>> asked us to allow a little more time for them to migrate their websites to
>> the WebAuthn. We therefore would like to push back removal of the U2F API
>> to Chrome 104, and to extend the Reverse Origin Trial to the same time
>> period.
>>
>> Thanks,
>> Martin
>>
>>
>> On Friday, June 11, 2021 at 11:34:24 AM UTC-7 Martin Kreichgauer wrote:
>>
>>> Primary eng (and PM) emails
>>>
>>> mart...@google.com, a...@chromium.org
>>>
>>> Summary
>>>
>>> We want to deprecate and remove the legacy U2F API for interacting with
>>> security keys. (But not U2F security keys themselves, which will continue
>>> to work.)
>>>
>>> Affected sites should migrate to the Web Authentication API (WebAuthn).
>>> Credentials that were originally registered via the U2F API can be
>>> challenged via WebAuthn. USB security keys that are supported by the U2F
>>> API are also supported by the WebAuthn API.
>>>
>>> Motivation
>>>
>>> U2F is Chrome’s original security key API. It allows sites to register
>>> public key credentials on USB security keys and challenge them for building
>>> phishing-resistant two-factor authentication systems. U2F never became an
>>> Open Web standard and was subsumed by WebAuthn (launched in M67
>>> ). Chrome never
>>> directly supported the FIDO U2F JavaScript API in Blink, but rather shipped
>>> a component extension called cryptotoken, which exposes an equivalent
>>> chrome.runtime.sendMessage API. U2F and Cryptotoken are firmly in
>>> maintenance mode and we encouraged sites to migrate to WebAuthn
>>> 
>>> two years ago.
>>>
>>> U2F’s continued existence presents several issues:
>>>
>>>-
>>>
>>>Cryptotoken requests don’t trigger a permission prompt or any UI
>>>indicating that the website is interacting with a special type of USB
>>>device. Instead we rely on the website to handle UI for the requested
>>>security key interaction. We believe this isn’t ideal from a secure UX
>>>perspective. WebAuthn presents either a tab-modal dialog or UI provided 
>>> by
>>>the operating system for every request.
>>>-
>>>
>>>Sites can unconditionally query U2F credentials when embedded in
>>>cross-origin iframes. WebAuthn guards this behavior behind a feature 
>>> policy.
>>>
>>>
>>>-
>>>
>>>Because Cryptotoken is a component extension and externally
>>>connectable from any URL, it effectively exposes the chrome.runtime APIs
>>>unconditionally to the entire web. Removing cryptotoken will allow us to
>>>make these APIs unavailable to websites that are not explicitly listed as
>>>connectable by an extension.
>>>-
>>>
>>>WebAuthn has subsumed U2F and we don’t want to encourage new use of
>>>an old API.
>>>
>>>
>>> googleLegacyAppIdSupport extension
>>>
>>> The factory image on some Android devices predates WebAuthn’s existence
>>> and therefore only supports the U2F API. Because credentials registered via
>>> WebAuthn cannot be challenged via U2F, Google continues to require a
>>> mechanism for registering U2F-compatible security key credentials even
>>> after the U2F API has been removed from Chrome, or else users that register
>>> a security key on their desktop would be unable to sign into their affected
>>> Android devices with that security key. We would like to implement support
>>> for the goolgeLegacyAppId WebAuthn request extension
>>> 
>>> in Chromium to al

Re: [blink-dev] Why is h264 encoding on Windows is limited to 1920x1088px?

[Chris Cunningham]

bcc:blink-dev
cc: media-dev
+chunbo@intel.com
 +eug...@chromium.org 

GPU accelerated encode will use platform specific libraries (Mac:
VideoToolbox, Windows: MediaFoundation).

The windows limit was introduced back in 2017 in this change
. When that was written, the
limit was soft, with higher options where supported. But in 2020 the higher
resolutions were removed to workaround a bug.
 I'm not
sure exactly what the issue was (either a driver crash or start up time) -
Chunbo, can you say more?

Chris

On Thu, Sep 23, 2021 at 9:22 AM Ivan Čurić  wrote:

> I was trying out WebCodecs in v94 and noticed in chrome://gpu that on
> Windows the h264 encoding is limited to 1920x1088px:
>
> Encode h264 baseline0x0 to 1920x1088 pixels, and/or 30.000 fps
>
> On MacOS it goes to 4096x2160. Why is that?
> I thought that the underlying implementation was using ffmpeg on both
> platforms.
>
> Not sure this is the best group to post this — if not, I'd love if you
> could forward me somewhere else.
>
>
> --
> 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/aacdc975-6ea4-4b34-8aca-98bf021fced1n%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/CALG6eSq3hwOCLA5ZMmMqf5EG%2BfAzCZjr%3D3_7Y5eYj9H-UStcjw%40mail.gmail.com.

[blink-dev] Why is h264 encoding on Windows is limited to 1920x1088px?

[Ivan Čurić]

I was trying out WebCodecs in v94 and noticed in chrome://gpu that on 
Windows the h264 encoding is limited to 1920x1088px:

Encode h264 baseline0x0 to 1920x1088 pixels, and/or 30.000 fps

On MacOS it goes to 4096x2160. Why is that?
I thought that the underlying implementation was using ffmpeg on both 
platforms.

Not sure this is the best group to post this — if not, I'd love if you 
could forward me somewhere else.


-- 
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/aacdc975-6ea4-4b34-8aca-98bf021fced1n%40chromium.org.

[blink-dev] Native support of Windows SSO in Chrome

['Sasha Tokarev' via blink-dev]

Hi all,
I have a proposal to integration with Windows SSO in Chrome.
Currently Windows has ability to join device to cloud identity, like AAD, MSA. 
When a device is joined to a cloud identity provider (IDP), it would be great 
if I'm as a user do not need enter credentials, when I'm using a service, which 
uses IDP where my device is joined to. I'm consented to have single sign on 
(SSO) when I joined the device, and trust IDP to protect my identity and do not 
allow an authorized access. If I do not trust, I should not join my device. 
Additionally, sometimes web resources, that I'm accessing to as a user, are 
owned by organization where I work or study. Hence, an organization 
administrator should be able to manage access to such resources based on the 
quality of my device, e.g., prevent access if the device doesn't make malware 
scans or doesn't have latest security patches etc.
Edge has this feature built in, in Chrome we must use a special extension 
https://chrome.google.com/webstore/detail/windows-10-accounts/ppnbnpeolgkicgegkbkbjmhlideopiji
While using extension works, the built-in experience is better, as we have with 
Windows Integrated authentication.
In high level it should work like this, if I'm accessing to a resource, from a 
joined device.

  1.  Resource (e.g., www.mywork.com) will redirect me 
for the authentication to the cloud identity 
provider(https://login.microsoftonline.com). The request will have a redirect 
URI that IDP will use to return a token.
  2.  User agent (Chrome) will detect this navigation and call an OS API for 
producing a crypto-protected SSO cookies, which has device and user 
information. This cookie will be appended to the request as a header or cookie.
  3.  Cloud identity provider ( https://login.microsoftonline.com ):
 *   Detects presence of the SSO cookies, validates them by checking 
signature, and authenticates the user and device.
 *   Validates that the supplied redirect uri is registered for this 
application.
 *   Validates if the resource owner (enterprise admin or user) authorizes 
access to the resource.
 *   Applies consent policy and ask consent if needed, for example 
enterprises, when they own the resource can pre-consent access by their 
employees. Note, It is responsibility of IDP to ensure that only authorized and 
consented applications can access users' identity.
 *   Read device identity, and checks the state of device, that reported 
out of band by device management system.
 *   If all checks are fine, the IDP redirect back to the resource with a 
token.
  4.  User agent (Chrome) should not do much, just to make sure it will not 
include SSO headers (as in case of some HTTP Redirects user-agent repeats the 
same headers) and cookies to the resource, to prevent its disclosure.
  5.  Resource gets the token and provides service to the user.

Note, a malicious web site will not be able to access user identity without 
explicit user consent, and if it is an enterprise account, then it should check 
admin authorization for this application. One may think that if we have SSO, 
now we need to think about protection from malicious web sites. However, this 
issue is not relevant to SSO, as if a user has either MSA or AAD, most likely 
she or he will enter credentials at some moment, and IDP will store persistent 
cookie. As a result, IDP still needs to protect from a malicious web site, that 
is why all protocols that use redirection has special handling for such cases, 
i.e. the IDP must redirect on initially pre-registered for this client redirect 
URI https://datatracker.ietf.org/doc/html/rfc6749#section-3.1.2
SSO itself reduces number of prompts, OS cookies are hardware crypto protected 
and short-lived, while protection of web-cookies is lower. Integration with OS 
SSO not just a convenience feature but increases users' security.

Thank you,
Aleksandr

-- 
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/SN6PR00MB0381D4A37BC4FBF2CB3927A1A1A39%40SN6PR00MB0381.namprd00.prod.outlook.com.

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

[Yoav Weiss]

LGTM to experiment M96-M99 inclusive

On Thu, Sep 23, 2021 at 4:04 PM Elad Alon  wrote:

> m99, inclusive. So four milestones in total.
>
> On Thu, Sep 23, 2021 at 3:53 PM Yoav Weiss  wrote:
>
>>
>>
>> On Thu, Sep 23, 2021 at 3:00 PM Elad Alon  wrote:
>>
>>> Might be good to move this to WICG to facilitate contributions (given
 support
 ).

>>>
>>> WICG issue #37  asked for
>>> this to be adopted by the WICG. (The same partner supported it there too,
>>> btw.)
>>>
>>
 Ping me and we'll move it over! :) 


>
>>>
 https://github.com/WICG/proposals/issues/37#issuecomment-920673070
 seems like a positive signal (even if from a single partner).

>>>
>>> Yes. And Mozilla and Apple also seemed interested in the use-case during
>>> the WebRTC Working Group interim meeting of September 2021, although we're
>>> still discussing the specific details.
>>>
>>>
 What are the goals for the experiment?

>>>
>>> Validate that the proposed API solves developers' issues in a
>>> satisfactory manner.
>>>
>>>
 What are the timeframes for the experimentation? Do you have partners
 lined up?

>>>
>>> Two internal (Google), one external (Tella).
>>>
>>
>> What's the end milestone you're targeting?
>>
>

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

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

['Elad Alon' via blink-dev]

m99, inclusive. So four milestones in total.

On Thu, Sep 23, 2021 at 3:53 PM Yoav Weiss  wrote:

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

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

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

[Yoav Weiss]

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

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

What's the end milestone you're targeting?

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

Re: [blink-dev] Intent to Ship: Auto-expand details elements

[Mike Taylor]

On 9/23/21 8:19 AM, Yoav Weiss wrote:
On Thu, Sep 23, 2021 at 9:25 AM Thomas Steiner > wrote:


Not sure this was discussed before, but could a new boolean
attribute that opts the element in to the new behavior be the answer?



At the risk of jinxing UseCounter metrics 
, 
another option would be to spec the `search` event such that 
`preventDefault()` provides an opt-out here.


--
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/32f6d7ac-0a08-8411-c485-2d26d578f6b5%40chromium.org.

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

['Elad Alon' via blink-dev]

>
> Might be good to move this to WICG to facilitate contributions (given 
> support 
> ).
>

WICG issue #37  asked for this 
to be adopted by the WICG. (The same partner supported it there too, btw.)
 

> https://github.com/WICG/proposals/issues/37#issuecomment-920673070 seems 
> like a positive signal (even if from a single partner).
>

Yes. And Mozilla and Apple also seemed interested in the use-case during 
the WebRTC Working Group interim meeting of September 2021, although we're 
still discussing the specific details.
 

> What are the goals for the experiment?
>

Validate that the proposed API solves developers' issues in a satisfactory 
manner.
 

> What are the timeframes for the experimentation? Do you have partners 
> lined up?
>

Two internal (Google), one external (Tella).

-- 
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/26bc6012-5939-4065-ad46-f2b4a3e507ddn%40chromium.org.

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

[Yoav Weiss]

On Wed, Sep 22, 2021 at 2:16 PM 'Elad Alon' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emailselada...@chromium.org
>
> Explainer
> https://github.com/eladalon1983/conditional-focus/blob/main/README.md
>
> Specificationhttps://eladalon1983.github.io/conditional-focus/
>

Might be good to move this to WICG to facilitate contributions (given
support 
).


>
>
> Design docs
>
> https://docs.google.com/document/d/1LHJRt-ry9hwzFTbPxKrmD0VvtEFEU6lvqsD7k6wwGKM/
>
> Summary
>
> Extend the getDisplayMedia APIs to ensure that tab-capture and
> window-capture return a new subclass of MediaStreamTrack called
> FocusableMediaStreamTrack. This new subclass exposes the focus() method.
> This new method allows Web-applications, when capture starts, to decide
> whether the captured tab/window should be immediately focused, or whether
> the capturing tab+window should remain the focused one.
>
>
> Blink componentBlink
> 
>
> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/679
>
> TAG review statusPending
>
> Risks
>
>
> Interoperability and Compatibility
>
>
>
> Gecko: No signal
>
> WebKit: No signal
>
> Web developers: No signals
>

https://github.com/WICG/proposals/issues/37#issuecomment-920673070 seems
like a positive signal (even if from a single partner).


>
> Ergonomics
>
> N/A
>
>
> Activation
>
> Not challenging - just feature-detect: // Pre-existing functionality: let
> mediaStream = await navigator.mediaDevices.getDisplayMedia(); let [track] =
> mediaStream.getVideoTracks(); // New functionality behind
> feature-detection: if (!!track.focus) { track.focus(...); }
>
>
> Security
>
> See design-doc.
>
>
> Goals for experimentation
>

What are the goals for the experiment?


>
>
> Reason this experiment is being extended
>
>
>
> Ongoing technical constraints
>
>
>
> Debuggability
>
> N/A
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?No
>
> Supported on all Desktop platforms.
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?No
>
> Flag nameConditionalFocus
>
> Requires code in //chrome?True
>
> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1215480
>
> Launch bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1214483
>
> Estimated milestones
>
> m96
>
>
What are the timeframes for the experimentation? Do you have partners lined
up?


>
> Link to entry on the Chrome Platform Status
> https://www.chromestatus.com/feature/5646614535340032
>
> Links to previous Intent discussionsIntent to prototype:
> https://groups.google.com/a/chromium.org/g/blink-dev/c/lbuqOGx07xY
>
>
> 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/CAMO6jDNKs_83QYuU9NreUPqimVodVSMuigofhOdy32jVf0nLiA%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/CAL5BFfXZaV71duAph8QfjTh%2BMg03ejyvFKNDuFDQmwE3BzRAJQ%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Auto-expand details elements

[Yoav Weiss]

LGTM1

On Thu, Sep 23, 2021 at 12:03 AM PhistucK  wrote:

> Not sure I completely agree, so, not so "right". :)
> Using / for "accordions" is kind of the prescribed way
> to do this. I do not think encouraging other, maybe less accessible,
> semantic or simple ways is so "right".
> And this is breaking/changing an existing behaviour. You would not say
> this ("they could just not use the details element, right?") so casually
> about other platform changes, I think.
> This is why I think a way to opt-out is fair.
>

I'm sympathetic to the semantic element argument. I suspect that the need
for such an opt-out is not huge (as it seems fairly niche for content to
want to be hidden), so I wouldn't consider this a blocker, but it seems
worthwhile to keep close tabs of the developer ecosystem and see if such a
need arises.
If it does, adding an opt-out seems worthwhile.


> I would not say this is a huge use case or that it must block shipping
> this, but it is worth a thoughtful consideration, anyway.
>
> ☆*PhistucK*
>
>
> On Wed, Sep 22, 2021 at 10:28 PM Joey Arhar  wrote:
>
>> > I imagine it could break a little some pages that hide the answer to a
>> question (in a quiz type of thing) via this element...
>>
>> If a site doesn't like this behavior, they could just not use the details
>> element, right? There are plenty of other ways to implement an accordion
>> like this.
>> I think it's more important for the user to be able to find content in
>> the page than it is for the page to hide content from the user by default,
>> right?
>>
>> On Sat, Sep 18, 2021 at 10:58 AM PhistucK  wrote:
>>
>>> I imagine it could break a little some pages that hide the answer to a
>>> question (in a quiz type of thing) via this element...
>>>
>>> ☆*PhistucK*
>>>
>>>
>>> On Sat, Sep 18, 2021 at 6:55 PM Joey Arhar  wrote:
>>>
 > Will there be an opt out (without resorting to using other elements)?

 No, there is no plan to add an opt-out for this feature.

 On Sat, Sep 18, 2021 at 10:54 AM PhistucK  wrote:

> Will there be an opt out (without resorting to using other elements)?
>
> ☆*PhistucK*
>
>
> On Fri, Sep 17, 2021 at 4:55 PM Joey Arhar 
> wrote:
>
>> > I think it's fair to say "positive", given the like and retweet
>> signals on https://twitter.com/tomayac/status/1403119516922662913
>> and https://twitter.com/tomayac/status/1293696281370669057 where
>> this behavior is described.
>>
>> Thanks Thomas!
>>
>> > Do I understand correctly and developers don't need to do anything
>> for their users to benefit from this? (and just need not to break their
>> content when many toggle events are fired)
>>
>> That's correct! Details elements will be opened and toggle events
>> will be fired when the browser actually scrolls to the content inside a
>> closed details element.
>>
>> > I think I'd describe all these put together as "slightly positive".
>> > At the same time, if I'm assuming correctly and developer opt-in is
>> not required, then luke-warm developer reception and happy users sounds
>> like a win.
>>
>> Great! I agree.
>> You are assuming correctly that developer opt-in is not required.
>>
>> On Fri, Sep 17, 2021 at 1:56 AM Yoav Weiss 
>> wrote:
>>
>>>
>>>
>>> On Fri, Sep 17, 2021 at 8:41 AM 'Thomas Steiner' via blink-dev <
>>> blink-dev@chromium.org> wrote:
>>>


 On Fri, Sep 17, 2021 at 3:56 AM Joey Arhar 
 wrote:

> Contact emailsjar...@chromium.org
>
> Explainer
> https://github.com/WICG/display-locking/blob/main/explainers/auto-expanding-details-explainer.md
>

>>> Do I understand correctly and developers don't need to do anything
>>> for their users to benefit from this? (and just need not to break their
>>> content when many toggle events are fired)
>>>
>>>

>
> Specificationhttps://github.com/whatwg/html/pull/6466
>
> Design docs
> https://github.com/WICG/display-locking/blob/main/privacy-assessments/auto-expanding-details-privacy.md
>
> Summary
>
> This feature will make closed details elements searchable and
> automatically expand when the browser tries to scroll to their hidden
> contents in response to find-in-page, ScrollToTextFragment, and 
> element
> fragment navigation.
>
> Blink componentBlink>HTML
> 
>
> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/677
>

>
> TAG review statusPending
>
> Risks
>
>
> Interoperability and Compatibility
>
> If other browsers don't implement this feature for element
>>

Re: [blink-dev] Intent to Ship: Auto-expand details elements

[Yoav Weiss]

On Thu, Sep 23, 2021 at 9:25 AM Thomas Steiner  wrote:

> Not sure this was discussed before, but could a new boolean attribute that
> opts the element in to the new behavior be the answer?
>
> 
>

It seems like an opt-in would significantly diminish the user value of this
feature, for all existing content.

-- 
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/CAL5BFfUT_Mp3q9weCAWcEF89LQkrnRHJarxx-4UR2fs7Hyz%3DUw%40mail.gmail.com.

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

[Yoav Weiss]

So IIUC, the deprecation trial would run from M98-M104. That seems like a
reasonable time period to give to folks and enable them to adjust.
Still LGTM.

On Wed, Sep 22, 2021 at 10:32 PM 'Martin Kreichgauer' via blink-dev <
blink-dev@chromium.org> wrote:

> Dear blink-dev,
>
> I wanted to provide an update on our progress with the U2F API deprecation
> effort and request a short extension for removal of the API and the end
> date of the Reverse Origin Trial.
>
> First, the changes originally announced for Chrome 94 are now scheduled to
> ship instead with Chrome 95. These changes include gating of U2F API
> requests behind a permission prompt, deprecation warnings logged to the
> developer console, and  a Reverse Origin Trial
> 
> .
>
> We still plan to disable the U2F API by default with Chrome 98.
>
> We also have been in close contact about this deprecation with partners
> who still rely on the U2F API. In some of these conversations, partners
> asked us to allow a little more time for them to migrate their websites to
> the WebAuthn. We therefore would like to push back removal of the U2F API
> to Chrome 104, and to extend the Reverse Origin Trial to the same time
> period.
>
> Thanks,
> Martin
>
>
> On Friday, June 11, 2021 at 11:34:24 AM UTC-7 Martin Kreichgauer wrote:
>
>> Primary eng (and PM) emails
>>
>> mart...@google.com, a...@chromium.org
>>
>> Summary
>>
>> We want to deprecate and remove the legacy U2F API for interacting with
>> security keys. (But not U2F security keys themselves, which will continue
>> to work.)
>>
>> Affected sites should migrate to the Web Authentication API (WebAuthn).
>> Credentials that were originally registered via the U2F API can be
>> challenged via WebAuthn. USB security keys that are supported by the U2F
>> API are also supported by the WebAuthn API.
>>
>> Motivation
>>
>> U2F is Chrome’s original security key API. It allows sites to register
>> public key credentials on USB security keys and challenge them for building
>> phishing-resistant two-factor authentication systems. U2F never became an
>> Open Web standard and was subsumed by WebAuthn (launched in M67
>> ). Chrome never
>> directly supported the FIDO U2F JavaScript API in Blink, but rather shipped
>> a component extension called cryptotoken, which exposes an equivalent
>> chrome.runtime.sendMessage API. U2F and Cryptotoken are firmly in
>> maintenance mode and we encouraged sites to migrate to WebAuthn
>> 
>> two years ago.
>>
>> U2F’s continued existence presents several issues:
>>
>>-
>>
>>Cryptotoken requests don’t trigger a permission prompt or any UI
>>indicating that the website is interacting with a special type of USB
>>device. Instead we rely on the website to handle UI for the requested
>>security key interaction. We believe this isn’t ideal from a secure UX
>>perspective. WebAuthn presents either a tab-modal dialog or UI provided by
>>the operating system for every request.
>>-
>>
>>Sites can unconditionally query U2F credentials when embedded in
>>cross-origin iframes. WebAuthn guards this behavior behind a feature 
>> policy.
>>
>>
>>-
>>
>>Because Cryptotoken is a component extension and externally
>>connectable from any URL, it effectively exposes the chrome.runtime APIs
>>unconditionally to the entire web. Removing cryptotoken will allow us to
>>make these APIs unavailable to websites that are not explicitly listed as
>>connectable by an extension.
>>-
>>
>>WebAuthn has subsumed U2F and we don’t want to encourage new use of
>>an old API.
>>
>>
>> googleLegacyAppIdSupport extension
>>
>> The factory image on some Android devices predates WebAuthn’s existence
>> and therefore only supports the U2F API. Because credentials registered via
>> WebAuthn cannot be challenged via U2F, Google continues to require a
>> mechanism for registering U2F-compatible security key credentials even
>> after the U2F API has been removed from Chrome, or else users that register
>> a security key on their desktop would be unable to sign into their affected
>> Android devices with that security key. We would like to implement support
>> for the goolgeLegacyAppId WebAuthn request extension
>> 
>> in Chromium to allow Google’s accounts system to do this. The extension
>> would allow *.google.com origins to create WebAuthn credentials that can
>> be challenged via WebAuthn and U2F, so that it will be possible for
>> Android’s burned-in user account adding system to exercise them. While the
>> googleLegacyAppIdSupport extension has not been formally standardized, Safari
>> has already shipped it .

Re: [blink-dev] Intent to Extend Origin Trial: Trust Token API

[Yoav Weiss]

As this is an atypical OT, this requires 3 LGTMs.

*LGTM1* to extend to M101, conditional on a 2 weeks gap to demonstrate that
there's no premature reliance on the API.

On Wed, Sep 22, 2021 at 10:26 PM Steven Valdez  wrote:

> Contact emails
>
> sval...@chromium.org, privacy-sand...@chromium.org
>
> Spec
>
>
> https://docs.google.com/document/d/1TNnya6B8pyomDK2F1R9CL3dY10OAmqWlnCxsWyOBDVQ/edit
> 
>
> https://github.com/WICG/trust-token-api
>
> Summary
>
> This is a new API for propagating a notion of user authenticity across
> sites, without using cross-site persistent identifiers like third party
> cookies. Trust Token is built on Privacy Pass
>  for anonymous tokens that can't be
> tracked between issuance and redemption.
>
> An Origin Trial for Trust Token started in M84 and is scheduled to end in
> M94. Due to the shift in the API from a primarily first-party issuance
> model to a third-party issuance model, we've gotten feedback from partners
> that spinning up the complex infrastructure and models for third-party
> issuance is taking longer than anticipated, in order to give issuers more
> time to experiment with this model, we'd like to extend the Origin Trial to
> M101 (April 2022).
>
> Link to “Intent to Prototype” blink-dev discussion
>
> https://groups.google.com/a/chromium.org/g/blink-dev/c/X9sF2uLe9rA/
>
> Previous Intent to Extend:
>
>
> https://groups.google.com/a/chromium.org/g/blink-dev/c/-W90wVkS0Ks/m/HyICZtuuBAAJ
>
> Goals for experimentation
>
> For the continuation of the origin trial, we hope to continue to get more
> experimental data on the value of these token-derived signals from issuance
> schemes that take place in the third-party context, rather than where a
> strong first-party signal is available. Additionally, we are continuing to
> iterate on the API shape and modes to bring it more in line with the
> underlying Privacy Pass work being standardized in the IETF.
>
> Experimental timeline
>
> We'd like to extend the Origin Trial again to run to the end of M101
> (April 2022).
>
> Any risks when the experiment finishes?
>
> As this feature is only available via Origin Trials and doesn't affect any
> existing state, we don't believe there will be any risks once the
> experiment concludes. As we don't maintain backwards compatibility between
> different versions of Trust Token (
> https://github.com/WICG/trust-token-api/blob/main/ISSUER_PROTOCOL.md#version-history),
> as we update it based on ecosystem feedback, we don't expect there to be
> ecosystem burn-in as the issuers and redeemers are still required to update
> their implementations to continue functioning in the latest version of
> Chrome (and the server-side components of the API provided by the component
> updater maintains minimal compatibility so that older versions of the API
> will cease to function within a version release or so). As an extra measure
> of safety, we can also disable the API for a couple weeks to ensure that
> the ecosystem is not burning in the availability of the API.
>
> Reason this experiment is being extended
>
>
> https://groups.google.com/a/chromium.org/forum/?oldui=1#!msg/blink-dev/UIvia1WwIhk/DuXLKdF7AgAJ
>
> Due to the complexities of issuance strategies involving purely
> third-party based issuance, we've seen that issuers are needing a longer
> time to spin up their infrastructure and experiment logic in order to
> verify the usefulness of the API. Due to the scope and shape of this API,
> we'd like to get data from issuers who are using this API before trying to
> launch it, to help understand the efficacy of the API and the parameters
> that the shipped version of the API should be using/allowing.
>
> Ongoing technical constraints
>
> None.
>
> Will this feature be supported on all five Blink platforms supported by
> Origin Trials (Windows, Mac, Linux, Chrome OS, and Android)?
>
> Yes.
>
> Link to entry on the feature dashboard 
>
> https://chromestatus.com/feature/5078049450098688
>
> --
> 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/CANduzxCRQpheUxNs-o4YR_Z-9OoqjUhxMHWd3Lh01%2BTPyoZTgA%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/chrom

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

[Anne van Kesteren]

On Fri, Aug 13, 2021 at 7:04 PM 'Ionel Popescu' via blink-dev
 wrote:
> https://wicg.github.io/eyedropper-api/

It seems some security issues were opened against this document post
LGTMs. And after these issues were raised there hasn't been a lot of
activity on the repository which makes me wonder what is going on.
Does anyone know?

-- 
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/CADnb78jYKAh8%3Dpe859_PubwcBOoWW%2BHdQDJ8jcJmbOYeotodRg%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: HTMLScriptElement.supports(type) method

[Yoav Weiss]

LGTM1

On Wed, Sep 22, 2021 at 5:21 AM Tsuyoshi Horo  wrote:

> Contact emails
>
> h...@chromium.org
>
>
> Explainer
>
> https://github.com/horo-t/explainers/blob/main/script_element_supports.md
>
>
> Specification
>
> https://html.spec.whatwg.org/multipage/scripting.html#dom-script-supports
>

> Design docs
>
> https://github.com/horo-t/explainers/blob/main/script_element_supports.md
>
>
> Summary
>
> Provides a unified way to detect new features that use script elements.
>
>
>
>
> Blink component
>
> Blink>HTML>Script
> 
>
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/674
>
>
> TAG review status
>
> Issues addressed
>

It should be noted that there was disagreement

between the TAG and the spec authors on the naming.
While I lean towards the call the spec authors made, the need for better JS
feature detection is something I repeatedly hear both from the TAG and

others . Orthogonal to this
intent, this seems like something we should eventually tackle.


> RisksInteroperability and Compatibility
>
> This method provides a synchronous way of feature detections. But for
> unsupported browsers, developers need to use an asynchronous way as
> discussed at https://github.com/WICG/import-maps/issues/171.
>

Is it worthwhile to document the desired code patterns we want developers
to use? (e.g. test is `supports()` exists and fallback to the async method
otherwise)


>
>
>
>
> Gecko: Worth prototyping (
> https://github.com/mozilla/standards-positions/issues/576)
>
>
>
> WebKit: No signal (
> https://lists.webkit.org/pipermail/webkit-dev/2021-September/031979.html)
>
>
>
> Web developers: Positive The developer feedback on the spec issue (
> https://github.com/whatwg/html/issues/6472) was positive.
>
>
> Ergonomics
>
> No known ergonomics risks.
>
>
>
>
> Activation
>
> No known activation risks. This method is easy to use.
>
>
>
>
> Security
>
> No known security risks.
>
>
>
>
> Debuggability
>
> Developers can call this method from DevTools's console.
>
>
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?
>
> Yes
>
>
> DevTrial instructions
>
>
> https://github.com/horo-t/explainers/blob/main/script_element_supports_how_to.md
>
>
> Flag name
>
> ScriptElementSupports
>
>
> Requires code in //chrome?
>
> False
>
>
> Tracking bug
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=1245528
>
>
> Sample links
>
> https://horo-t.github.io/explainers/script_element_supports_sample.html
>
>
> Estimated milestones DevTrial on desktop 95DevTrial on android 95DevTrial
> on Webview 95
>
>
> Link to entry on the Chrome Platform Status
>
> https://www.chromestatus.com/feature/5712146835963904
>
>
> Links to previous Intent discussions
>
> Intent to prototype:
> https://groups.google.com/a/chromium.org/g/blink-dev/c/evk2qgsekYk/m/WtdE_XplBQAJ
>
> Ready for Trial:
> https://groups.google.com/a/chromium.org/g/blink-dev/c/-sE2GpCrG6Y/m/UsHXyVW-CAAJ
>
>
>
>
> 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/CADk0S-Vi%2BhCDOA2y0%2BfUU-dt60_ySvSY0-MjDyGTMi8oHcrm9A%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/CAL5BFfV1cuHkDVpSbirXFPc7Ej5cX4hcpQumcwkK39988%3DDRyg%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Ship: Reporting API: Isolate reports per-document and support the Reporting-Endpoints header

['Yoav Weiss' via blink-dev]

Still LGTM

On Tue, Sep 21, 2021 at 10:48 PM Ian Clelland 
wrote:

> In an exciting last minute turn of events, I've made progress on fixing
> one of the last outstanding bugs regarding our implementation of the new
> Reporting API spec, and I'd like to amend this intent to include that
> change, but I think I might need API owners to take another look at it.
>
> The original Reporting API specified that credentials should always be
> sent with the HTTP POST to reporting endpoints, like other requests. Chrome
> never implemented this, and until now, has never sent credentials with
> reports.
>
> This behaviour was changed with the new Reporting API, and the eventual
> outcome of https://github.com/w3c/reporting/issues/161 was that the spec
> restricted credentials to same-origin report uploads.
>
> Fixing https://crbug.com/1163645 now means that Chrome can send
> credentials with the reports, if and only if the reporting endpoint is
> same-origin with the document which generated the reports. I'd like to add
> that change to our initial release of the new header.
>
> To avoid introducing any backwards compatibility issues, and to try to
> avoid any unintended consequences of enabling credentials for existing
> deployments, I'd restrict this to only apply to the new Reporting-Endpoints
> header, and not to the older Report-To header. No existing behaviour should
> be changing as a result of this.
>
> I'd normally consider this a bug fix which aligns the initial release with
> the spec, but since it is an expansion of the scope of this intent, and
> since any mention of credentials should at least get the attention of
> privacy folks, I think this warrants getting folks to take a look again.
>
> Thanks,
> Ian
>
>
> On Mon, Sep 20, 2021 at 1:30 PM Ian Clelland 
> wrote:
>
>>
>>
>> On Thu, Sep 9, 2021 at 3:05 PM Mike West  wrote:
>>
>>> LGTM3.
>>>
>>> That said, we really need to stop renaming things that we've shipped. I
>>> think there's reasonable justification for doing so in this case, and given
>>> Mozilla's support for the `Reporting-Endpoints` model (and lack of support
>>> for the `Report-To` model), it seems reasonable to me to follow through
>>> with an eventual deprecation. But more generally, shipping creates some
>>> unavoidable ossification. I might be over-reacting a bit to a few intents
>>> I'm recalling, but I think we need to carefully consider the cost of
>>> renaming vs the cost of asking developers to internalize a shift in
>>> behavior.
>>>
>>
>> Agreed -- we certainly thought long and hard about whether we could keep
>> the existing naming; the fundamental problem we ran into was in being able
>> to ship this without breaking NEL, and eventually concluded that since it
>> was impossible to know, with the existing Report-To header whether the
>> intended usage was going to be ephemeral (like the new header) or
>> persistent (like with NEL), that we couldn't change the semantics of
>> Report-To and also keep backwards compatibility.
>>
>>
>>>
>>> What's the long-term plan for `Report-To`? Do you have a deprecation
>>> path you think is feasible, or are we going to end up trying to align it to
>>> `Reporting-Endpoints` as an alias at some point in the future?
>>>
>>
>> We do want to deprecate it; that needs to happen along two different
>> paths:
>>  - We need to remove support for having Report-To configure document
>> reporting; that is, Reporting-Endpoints should be the only mechanism for
>> those reports.
>>  - We need to ship a better configuration mechanism for NEL & co., one
>> which is correctly origin-scoped, and does not allow an arbitrary
>> misconfigured document to overwrite the persistent configuration for the
>> rest of the resources at that origin. Most recently, I had proposed using
>> Origin Policy as that mechanism, but the future of that spec is unclear.
>>
>> Once both of those have been done, we will be able to deprecate the
>> Report-To header.
>>
>>
>>> -mike
>>>
>>>
>>> On Thu, Sep 9, 2021 at 5:06 PM Daniel Bratell 
>>> wrote:
>>>
 LGTM2

 /Daniel
 On 2021-09-07 16:06, Ian Clelland wrote:



 On Mon., Sep. 6, 2021, 3:19 a.m. Yoav Weiss, 
 wrote:

>
>
> On Fri, Sep 3, 2021 at 12:31 PM Scott Helme 
> wrote:
>
>> Hey Yoav,
>>
>> Thanks for linking me in, I'm happy to provide my feedback here.
>>
>> Transparency: I'm Scott Helme, the founder of Report URI
>> , which is a commercial service for
>> allowing websites to collect reports sent via the Reporting API.
>>
>> We have a pretty strong position on the privacy concerns of websites
>> collecting reports and outline all of the efforts we take to mitigate 
>> those
>> concerns in our documentation. The change proposed here seems like a step
>> in the right direction and as, I believe, the largest service of our kind
>> in the world, we would like to show our support.
>>
>

Re: [blink-dev] Intent to Ship: Auto-expand details elements

['Thomas Steiner' via blink-dev]

Not sure this was discussed before, but could a new boolean attribute that
opts the element in to the new behavior be the answer?



-- 
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/CALgRrL%3DAL7xchm34A5_faVs0UmJBmvCvLivxXNVcdrkjpX836Q%40mail.gmail.com.