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

['Sasha Tokarev' via blink-dev]

As @Owen Min said, IDP registered in OS.

 - Is there at most one IDP for a profile? /
In one Windows logon session there can be multiple IDP urls associated with 
different clouds, global cloud, China cloud, and also consumer cloud.

Per Profile there can be multiple IDPs.

Thank you,
Sasha

From: Owen Min 
Sent: Friday, September 24, 2021 3:24 PM
To: Yutaka Hirano 
Cc: blink-dev ; Sasha Tokarev ; 
Greg Thompson ; Matt Menke ; Ryan 
Sleevi ; Adam Langley 
Subject: [EXTERNAL] Re: [blink-dev] Re: Native support of Windows SSO in Chrome

You don't often get email from z...@chromium.org. 
Learn why this is important
Answer inline. Sasha and Greg, feel free to correct me or add more things if 
you want.

On Fri, Sep 24, 2021 at 1:27 AM Yutaka Hirano 
mailto:yhir...@google.com>> wrote:
I have some questions.

 - Is the proposal that Chrome detects such a redirect and sends an 
authentication request to IDP?
Browser detects the access of IDP 
URL(https://login.microsoftonline.com)
 and appends a cookie which gets from the OS to that request.
 - Is there at most one IDP for a profile? /
 - How is IDP registered to Chrome?
IDPs are registered with the OS. And the browser gets both IDP urls (see 
CloudApPlatformWin::ReadOrigins)
 and cookies from the OS.

Thanks,

On Fri, Sep 24, 2021 at 6:18 AM Owen Min 
mailto:z...@chromium.org>> 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

Re: [blink-dev] Intent to Experiment: App history API

[Yoav Weiss]

LGTM to experiment M96-M99

On Sat, Sep 25, 2021 at 12:03 AM Domenic Denicola 
wrote:

> Contact emailsdome...@chromium.org, jap...@chromium.org
>
> Explainerhttps://github.com/WICG/app-history/blob/main/README.md
>
> Specificationhttps://wicg.github.io/app-history/
>
> Summary
>
> The window.appHistory API provides the ability to intercept navigations as
> well as introspect an application's history entries. This provides a more
> useful alternative to window.history, specifically aimed at the needs of
> single-page web applications.
>
> Blink componentBlink>History
> 
>
> TAG review
> https://github.com/w3ctag/design-reviews/issues/605
>

I noticed that feedback from both the TAG and Mozilla mentioned the API's
name as confusing. It might be worthwhile to consider alternatives.


>
> TAG review statusIssues addressed
>
> Risks
>
> Interoperability and Compatibility
>
> 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 plan
> to address this by having solid and well-tested specifications for all
> aspects of the new API, as well as every way the new API integrates with
> window.history. Additionally, we're working in parallel to improve
> interoperability on the base model through spec updates, writing web
> platform tests, and fixing browser bugs.
>
>
> Gecko: No signal (
> https://github.com/mozilla/standards-positions/issues/543) Initial
> positive opinions on the issue, but not yet an official position
>
> WebKit: No signal (
> https://lists.webkit.org/pipermail/webkit-dev/2021-September/031987.html)
>
> Web developers: Strongly positive (
> https://github.com/WICG/proposals/issues/20) The initial public proposal,
> as well as the issue tracker and Twitter, has had great engagement and
> enthusiasm from developers. In addition, we have several conversations
> going on with frameworks, libraries, and larger websites to ensure that
> we're solving the problems they see with today's history API.
>
> Ergonomics
>
> Although this API layers onto the same underlying model as window.history,
> and will have well-specified interactions with it, the exact integrations
> may be confusing. (For example, appHistory.navigate() will behave
> differently from history.pushState().) We'll do our best to smooth over
> these rough edges where possible, but will favor making the app history API
> pleasant to use over making it perfectly align with window.history. From a
> performance standpoint, there are some potential challenges regarding
> exposing information and intercepting navigations that are usually handled
> in the browser process to the renderer process, and ensuring everything
> stays synchronized. We will explore this further as we prototype.
>
>
> Activation
>
> This feature is hard to polyfill, but developers have managed to produce
> something that works in many cases: https://github.com/frehner/appHistory
> We've also seen a pattern where developers have existing history wrappers
> (e.g. router libraries or app-specific history code) which they can adapt
> with a new app history-based backend for browsers that support it.
>
>
> Security
>
> We believe the security risks of this feature are minimal because of how
> it is scoped to same-origin contiguous history entries, and similarly only
> allows interception of same-origin navigations. We also need to ensure that
> we don't allow "trapping" the user by preventing them from using their back
> button; the API is designed to prevent this.
>
>
> Goals for experimentation
>
> We have much of the core API developed
> ,
> and want to validate that it helps developers in production. At least one
> large site is interested in swapping out their existing history API wrapper
> for one based on app history, and we want to validate that doing so
> produces the expected code simplifications and opportunities for new
> capabilities like loading spinner control. And, we want to validate that
> running it in production does not expose any new bugs that we have missed
> during dev trials.
>
> Debuggability
>
> This feature mostly has no need for extended tooling.
> https://bugs.chromium.org/p/chromium/issues/detail?id=1252940 tracks
> adding the newly-introduced events to the Event Listener Breakpoints panel.
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?Yes
>
> Is this feature fully tested by web-platform-tests
> 
> ?Yes
> .
>

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

[Owen Min]

Answer inline. Sasha and Greg, feel free to correct me or add more things
if you want.

On Fri, Sep 24, 2021 at 1:27 AM Yutaka Hirano  wrote:

> I have some questions.
>
>  - Is the proposal that Chrome detects such a redirect and sends an
> authentication request to IDP?
>
Browser detects the access of IDP URL(https://login.microsoftonline.com)
and appends a cookie which gets from the OS to that request.

>  - Is there at most one IDP for a profile? /
>
 - How is IDP registered to Chrome?
>
IDPs are registered with the OS. And the browser gets both IDP urls (see
CloudApPlatformWin::ReadOrigins
)
and cookies from the OS.

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

[blink-dev] Intent to Experiment: App history API

[Domenic Denicola]

Contact emailsdome...@chromium.org, jap...@chromium.org

Explainerhttps://github.com/WICG/app-history/blob/main/README.md

Specificationhttps://wicg.github.io/app-history/

Summary

The window.appHistory API provides the ability to intercept navigations as
well as introspect an application's history entries. This provides a more
useful alternative to window.history, specifically aimed at the needs of
single-page web applications.

Blink componentBlink>History


TAG review
https://github.com/w3ctag/design-reviews/issues/605

TAG review statusIssues addressed

Risks

Interoperability and Compatibility

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 plan to address
this by having solid and well-tested specifications for all aspects of the
new API, as well as every way the new API integrates with window.history.
Additionally, we're working in parallel to improve interoperability on the
base model through spec updates, writing web platform tests, and fixing
browser bugs.


Gecko: No signal (https://github.com/mozilla/standards-positions/issues/543)
Initial positive opinions on the issue, but not yet an official position

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

Web developers: Strongly positive (
https://github.com/WICG/proposals/issues/20) The initial public proposal,
as well as the issue tracker and Twitter, has had great engagement and
enthusiasm from developers. In addition, we have several conversations
going on with frameworks, libraries, and larger websites to ensure that
we're solving the problems they see with today's history API.

Ergonomics

Although this API layers onto the same underlying model as window.history,
and will have well-specified interactions with it, the exact integrations
may be confusing. (For example, appHistory.navigate() will behave
differently from history.pushState().) We'll do our best to smooth over
these rough edges where possible, but will favor making the app history API
pleasant to use over making it perfectly align with window.history. From a
performance standpoint, there are some potential challenges regarding
exposing information and intercepting navigations that are usually handled
in the browser process to the renderer process, and ensuring everything
stays synchronized. We will explore this further as we prototype.


Activation

This feature is hard to polyfill, but developers have managed to produce
something that works in many cases: https://github.com/frehner/appHistory
We've also seen a pattern where developers have existing history wrappers
(e.g. router libraries or app-specific history code) which they can adapt
with a new app history-based backend for browsers that support it.


Security

We believe the security risks of this feature are minimal because of how it
is scoped to same-origin contiguous history entries, and similarly only
allows interception of same-origin navigations. We also need to ensure that
we don't allow "trapping" the user by preventing them from using their back
button; the API is designed to prevent this.


Goals for experimentation

We have much of the core API developed
,
and want to validate that it helps developers in production. At least one
large site is interested in swapping out their existing history API wrapper
for one based on app history, and we want to validate that doing so
produces the expected code simplifications and opportunities for new
capabilities like loading spinner control. And, we want to validate that
running it in production does not expose any new bugs that we have missed
during dev trials.

Debuggability

This feature mostly has no need for extended tooling.
https://bugs.chromium.org/p/chromium/issues/detail?id=1252940 tracks adding
the newly-introduced events to the Event Listener Breakpoints panel.

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

Is this feature fully tested by web-platform-tests

?Yes
.
(As of this writing, the Chromium results look bad because we landed a big
API change that hasn't yet made its way to the wpt.fyi bots.)

Flag nameAppHistory

Requires code in //chrome?False

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

Launch bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1252954

Estimated milestones
M96-M99

Link to entry on the Chrome Platform Status
https:/

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

[Nick Bond]

Great news! Excellent work to you and your team on this one. You're helping 
to bring the native experience to the web.

On Friday, September 24, 2021 at 1:26:20 PM UTC-5 rei...@chromium.org wrote:

> Yes, this API is ready for production use. The specification may change 
> but only in ways that align with our principles 
> , 
> which 
> focus on maintaining compatibility with existing web content. The folks on 
> this thread who gave me the original LGTMs to ship this API will hold me to 
> that.
>
> Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome 
> 
>
>
> On Thu, Sep 23, 2021 at 11:41 AM Nick Bond  wrote:
>
>> 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 
>>

Re: [blink-dev] Request for Deprecation Trial: Remove alert(), confirm(), and prompt for cross origin iframes

[Emmanuel Law]

What is the latest status of this? Ideally we would like more information 
on when this deprecation will take place so that we can strategize on a 
longer term solution vs a short term solution depending on the date.

On Friday, August 20, 2021 at 12:16:59 PM UTC-7 carl...@chromium.org wrote:

> Re: Stilll seeing the breakage, this was indeed disabled via Chrome 
> Variations, so if something is interfering with variations (like an 
> enterprise policy), that could be the reason you still see this. This was 
> also disabled in code starting in 92.0.4515.146.
>
> Re: A message in DevTools, we are planning to add a note in DevTools about 
> this API being deprecated.
>
> Re: Testing while this is disabled by default, you can do so by running 
> chrome with 
> the --enable-features="SuppressDifferentOriginSubframeJSDialogs" command 
> line flag
>
> -Carlos
>
> On Fri, Aug 20, 2021 at 12:11 AM Pritpal Singh <
> psi...@watermarkinsights.com> wrote:
>
>> How can we re-enable this deprecation on latest version of chrome, we 
>> need it to test the alternatives. Please guide.
>>
>> On Friday, August 20, 2021 at 12:05:24 PM UTC+5:30 Yang Guo wrote:
>>
>>> Is there plans for a soft deprecation through DevTools?
>>>
>>> Instead of removing right away,  you could raise issues in DevTools when 
>>> these APIs are used to warn developers of upcoming deprecation.
>>>
>>> On Thursday, August 19, 2021 at 8:36:16 PM UTC+2 wande...@chromium.org 
>>> wrote:
>>>
 Is the tested chrome browser managed using enterprise policies?  It's 
 possible an enterprise policy could be interfering with the finch fill 
 switch.

 On Thu, Aug 19, 2021 at 2:31 PM Daniel Bratell  
 wrote:

> I'm not in that engineering team but as far as I understand, the 
> change was done through the Finch system, which is settings your Chrome 
> client will regularly download from Google server. That might not happen 
> immediately which could possibly explain what you see. But maybe the team 
> can follow up with more information.
>
> /Daniel
> On 2021-08-19 16:33, Pierce McGeough wrote:
>
> What is the current state of play with this?  
>
> I thought *92.0.4515.157* was the most version of Chrome where the 
> issue was reverted. I downloaded *92.0.4515.107 *with it looking like 
> it was the most recent version to still have the blocker in place.
> I also have 91.0.4472.144 on another machine. 
>
> I tested no attribute, "sandbox", "sandbox='allow-scripts'" and 
> "sandbox='allow-scripts allow-modals''. I tested against running a 
> script, 
> alert, confirm, print and prompt. All versions gave the same results.
>
> On Thursday, August 5, 2021 at 11:02:46 AM UTC+1 Daniel Bratell wrote:
>
>> Technically those are two different domains, even though they are 
>> likely controlled by the same party. There are ways to "join" different 
>> domains (like setting the document.domain 
>>  
>> property), or identify which second level domains have only one 
>> controller  and which 
>> has more, but they are unreliable and are being phased out 
>> .
>>
>> You are right that this is a common setup in enterprises and that has 
>> to be considered when discussing how possibly malicious cross-origin 
>> alerts 
>> and prompts can be prevented.
>>
>> /Daniel
>> On 2021-08-04 15:38, Hugo Leitao wrote:
>>
>> Why do you block for the same domain? Sample: 
>> https://123.mydomain.com and subframe https://abc.mydomain.com
>> Too many corporate applications will be affected. Regards
>> Em sexta-feira, 30 de julho de 2021 às 21:06:14 UTC-3, 
>> carl...@chromium.org escreveu:
>>
>>> We decided to disable this deprecation temporarily (for 2 weeks, 
>>> until August 15, 2021) to provide more time for websites to address the 
>>> issues caused by this change, or enroll affected origins in the origin 
>>> trial. 
>>> If neither the origin trial or the enterprise policy address your 
>>> concerns, please comment in the implementation bug at 
>>> crbug.com/1065085.
>>>
>>> The configuration to disable the deprecation should reach most 
>>> Chrome instances in a few hours, but in some cases might take longer. 
>>> Chrome needs to be restarted for the change to take effect.
>>>
>>> Thanks,
>>> -Carlos
>>>
>>> On Fri, Jul 30, 2021 at 5:24 AM Pritpal Singh <
>>> psi...@watermarkinsights.com> wrote:
>>>
 If we use the document.domain='example.com' on the pages of our 
 site under same domain, will the opening in iframe will be excluded 
 from 
 this impact?

 On Thursday, July 29, 2021 at 11:39:18 

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

[Reilly Grant]

Yes, this API is ready for production use. The specification may change but
only in ways that align with our principles
,
which
focus on maintaining compatibility with existing web content. The folks on
this thread who gave me the original LGTMs to ship this API will hold me to
that.
Reilly Grant | Software Engineer | reil...@chromium.org | Google Chrome



On Thu, Sep 23, 2021 at 11:41 AM Nick Bond  wrote:

> 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