Re: [blink-dev] Intent to Extend Origin Trial: QuicTransport

['Yutaka Hirano' via blink-dev]

Sure, we're working on it: https://crbug.com/1201118.


On Mon, Feb 7, 2022 at 6:49 PM Frédéric Wang  wrote:

> Hi,
>
> Among items 1-3 it seems only the first one had already landed (and
> without runtime flag).
>
> I'm not sure it's web-exposed, since chrome probably can't load a page
> with a quic-transport: scheme anyway, but since you don't plan to ship the
> quic-transport: scheme anymore, can you please remove it from the
> secure_schemes list:
>
>
> https://source.chromium.org/chromium/chromium/src/+/main:url/url_util.cc;l=66;drc=ae97629737a9f0935c79337f5adb9b75e6edb84b
> Thanks,
>
> Le 08/02/2021 à 14:38, 'Yutaka Hirano' via blink-dev a écrit :
>
> Please see
> https://groups.google.com/a/chromium.org/g/blink-api-owners-discuss/c/uoQG64TjVcU
> for the previous discussion.
>
> As mentioned in the original e-mail, we are planning to remove the
> WebTransport over QUIC implementation, and we will not need the
> "quic-transport" scheme in the future.
>
> Thanks,
>
> On Mon, Feb 8, 2021 at 8:57 PM Frédéric Wang  wrote:
>
>> Le 08/02/2021 à 12:22, Yutaka Hirano a écrit :
>>
>> Is this feature fully tested by web-platform-tests
>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>
>> ?
>> No We have browser tests, but we are going to port them to WPT shortly.
>>
>> Hi,
>>
>> As part of my work in [1], I noticed that quic-transport was added in the
>> SchemeRegistry's standard_schemes and secure_schemes [2]. This implies
>> web-exposed changes for which it would be good to update the spec and add
>> web platform tests. Below are some things I'm aware.
>>
>> 1. URL using the quic-transport schemes are treated as "potentially
>> trustworthy" per [3]. I think it makes sense to add it to step 3 of [3]
>> together with "https" and "wss".
>>
>> 2. Origin with the quic-transport schemes are not treated as opaque, [4]
>> should probably be updated accordingly.
>>
>> Additionally,
>>
>> 3. I suspect you want quic-transport to be a "special scheme" so that its
>> URL parsing is handled consistently with https etc [5]. This can be easily
>> tested e.g. compare the result of new URL("https:/a/b" ) vs
>> new URL("notspecial:/a/b")
>>
>> Note that I already added internal tests for the two first items while
>> working on [1].
>>
>> Hope that helps,
>>
>> [1] https://bugs.chromium.org/p/chromium/issues/detail?id=1153336
>> [2]
>> https://source.chromium.org/chromium/chromium/src/+/master:url/url_util.cc;l=31;drc=09c1e54f4ca8bf35de6b5e67fead82274ef7
>> [3]
>> https://w3c.github.io/webappsec-secure-contexts/#is-origin-trustworthy
>> [4] https://url.spec.whatwg.org/#concept-url-origin
>> [5] https://url.spec.whatwg.org/#special-scheme
>> https://url.spec.whatwg.org/#url-parsing
>>
>> --
>> Frédéric Wang
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to blink-dev+unsubscr...@chromium.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d9446a5d-a786-3fd1-7068-0d92fccf3473%40igalia.com
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d9446a5d-a786-3fd1-7068-0d92fccf3473%40igalia.com?utm_medium=email_source=footer>
>> .
>>
> --
> 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/CABihn6FOBhR%2BXxL6Rt04bgsYo_stfZcHCNxewBx0UK0Zp3QL9w%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABihn6FOBhR%2BXxL6Rt04bgsYo_stfZcHCNxewBx0UK0Zp3QL9w%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
>
> --
> Frédéric Wang
>
>

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

Re: [blink-dev] Re: Intent to extend the origin trial: WebTransport over HTTP/3

['Yutaka Hirano' via blink-dev]

bcc: blink-dev
cc: web-transport-dev

Hi, web-transport-...@chromium.org is a better place for this kind of
discussion.

On Thu, Jan 20, 2022 at 3:47 PM kk as  wrote:

> Hi
>   Can you please let me know  what transport protocol  do the Streams API
> use in WebTransport over http3/quic.
> I am assuming the datagram API uses the UDP protocol for transport .   Can
> you also please let me know what is the difference in latency
> when you send data using Streams API vs Datagram API ?
>
> Reg: protocol, we use WebTransport over HTTP/3
.
We expect Datagrams is better than Streams in terms of latency, but actual
number depends on the network environment, server and client implementation.
Our client implementation is not (at all) perfect, so we'll appreciate your
performance feedback!



>
> thanks
>
> On Wednesday, October 27, 2021 at 10:34:56 PM UTC-7 Yutaka Hirano wrote:
>
>> On Thu, Oct 28, 2021 at 2:38 AM Joe Medley  wrote:
>>
>>> Hi,
>>>
>>> Can I get some clarification?
>>>
>>> So this extends the origin trial through 96, but you don't know yet
>>> whether it will ship in 97? Is this correct?
>>>
>> We're shipping WebTransport over HTTP/3 in 97.
>>
>>
>>> Joe
>>> Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com |
>>> 816-678-7195 <(816)%20678-7195>
>>> *If an API's not documented it doesn't exist.*
>>>
>>>
>>> On Mon, Oct 25, 2021 at 1:00 AM Mike West  wrote:
>>>
 LGTM3.

 -mike


 On Thu, Oct 21, 2021 at 9:58 PM Daniel Bratell 
 wrote:

> For a gapless origin trial->shipping it is important to be sure we
> don't overlook any feedback in the race to shipping. The normal process 
> has
> gaps built in which form natural points to do that final polish based on
> received feedback and that will be missing here.
>
> It does sound like the feedback has been positive though and that
> there are no known problems that can't be fixed after shipping, and with
> that in mind:
>
> LGTM2
> On 2021-10-21 21:53, Yoav Weiss wrote:
>
> Discussing amongst the API owners (Alex, Daniel, Rego and myself),
> this is essentially a request for a gapless OT, only that the would-be-gap
> is slightly longer than usual. Given the evidence
> 
>  of
> developer feedback presented in the I2S, that seems like a reasonable
> request.
>
> LGTM1 (as gapless OT requests require 3 LGTMs)
>
> On Monday, October 18, 2021 at 10:39:14 AM UTC+2 Yutaka Hirano wrote:
>
>> Contact emails
>>
>> yhi...@chromium.org,vas...@chromium.org
>>
>> Explainer
>>
>> https://github.com/w3c/webtransport/blob/main/explainer.md
>>
>> Design docs/spec
>>
>> Specification: https://w3c.github.io/webtransport/#web-transport
>>
>>
>> https://docs.google.com/document/d/1UgviRBnZkMUq4OKcsAJvIQFX6UCXeCbOtX_wMgwD_es/edit
>>
>> TAG review
>>
>> https://github.com/w3ctag/design-reviews/issues/669
>>
>>
>> Summary
>>
>> WebTransport is an interface representing a set of
>> reliable/unreliable streams to a server. The interface potentially 
>> supports
>> multiple protocols, but based on discussions on the IETF webtrans working
>> group, we are developing WebTransport over HTTP/3 which uses HTTP3 as the
>> underlying protocol.
>>
>> Note that we were developing QuicTransport a.k.a. WebTransport over
>> QUIC and we ran an origin trial M84 through M90. It uses the same 
>> interface
>> WebTransport, but because of the protocol difference ("quic-transport" 
>> vs.
>> "https") it is difficult for web developers to be confused by them.
>>
>> new WebTransport("quic-transport://example.com:9922")
>>
>> represents a WebTransport over QUIC connection, and
>>
>> new WebTransport("https://example.com:9922;)
>>
>> represents a WebTransport over HTTP/3 connection.
>>
>> Goals for experimentation
>>
>> We're shipping the API in M97
>> .
>> Twitch, one of our partners, wants to continue their experiment until the
>> API is fully shipped. I think this is a reasonable request given we
>> originally aimed to ship the feature in M96 but we missed the branch 
>> point.
>>
>> The original goals follow:
>>
>> To see whether the API (and the implementation) is useful in various
>> circumstances.
>>
>> Our partners want to evaluate this API on various network
>> circumstances (i.e., lab environments are not enough) to see its
>> effectiveness.
>>
>> We also expect feedback for performance.
>>
>> Experimental timeline
>>
>> M95 and M96

Re: [blink-dev] Re: Intent to extend the origin trial: WebTransport over HTTP/3

['Yutaka Hirano' via blink-dev]

On Thu, Oct 28, 2021 at 2:38 AM Joe Medley  wrote:

> Hi,
>
> Can I get some clarification?
>
> So this extends the origin trial through 96, but you don't know yet
> whether it will ship in 97? Is this correct?
>
We're shipping WebTransport over HTTP/3 in 97.


> Joe
> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
> 816-678-7195 <(816)%20678-7195>
> *If an API's not documented it doesn't exist.*
>
>
> On Mon, Oct 25, 2021 at 1:00 AM Mike West  wrote:
>
>> LGTM3.
>>
>> -mike
>>
>>
>> On Thu, Oct 21, 2021 at 9:58 PM Daniel Bratell 
>> wrote:
>>
>>> For a gapless origin trial->shipping it is important to be sure we don't
>>> overlook any feedback in the race to shipping. The normal process has gaps
>>> built in which form natural points to do that final polish based on
>>> received feedback and that will be missing here.
>>>
>>> It does sound like the feedback has been positive though and that there
>>> are no known problems that can't be fixed after shipping, and with that in
>>> mind:
>>>
>>> LGTM2
>>> On 2021-10-21 21:53, Yoav Weiss wrote:
>>>
>>> Discussing amongst the API owners (Alex, Daniel, Rego and myself), this
>>> is essentially a request for a gapless OT, only that the would-be-gap is
>>> slightly longer than usual. Given the evidence
>>> 
>>>  of
>>> developer feedback presented in the I2S, that seems like a reasonable
>>> request.
>>>
>>> LGTM1 (as gapless OT requests require 3 LGTMs)
>>>
>>> On Monday, October 18, 2021 at 10:39:14 AM UTC+2 Yutaka Hirano wrote:
>>>
 Contact emails

 yhir...@chromium.org,vasi...@chromium.org

 Explainer

 https://github.com/w3c/webtransport/blob/main/explainer.md

 Design docs/spec

 Specification: https://w3c.github.io/webtransport/#web-transport


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

 TAG review

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


 Summary

 WebTransport is an interface representing a set of reliable/unreliable
 streams to a server. The interface potentially supports multiple protocols,
 but based on discussions on the IETF webtrans working group, we are
 developing WebTransport over HTTP/3 which uses HTTP3 as the underlying
 protocol.

 Note that we were developing QuicTransport a.k.a. WebTransport over
 QUIC and we ran an origin trial M84 through M90. It uses the same interface
 WebTransport, but because of the protocol difference ("quic-transport" vs.
 "https") it is difficult for web developers to be confused by them.

 new WebTransport("quic-transport://example.com:9922")

 represents a WebTransport over QUIC connection, and

 new WebTransport("https://example.com:9922;)

 represents a WebTransport over HTTP/3 connection.

 Goals for experimentation

 We're shipping the API in M97
 .
 Twitch, one of our partners, wants to continue their experiment until the
 API is fully shipped. I think this is a reasonable request given we
 originally aimed to ship the feature in M96 but we missed the branch point.

 The original goals follow:

 To see whether the API (and the implementation) is useful in various
 circumstances.

 Our partners want to evaluate this API on various network circumstances
 (i.e., lab environments are not enough) to see its effectiveness.

 We also expect feedback for performance.

 Experimental timeline

 M95 and M96

 Ongoing technical constraints

 None

 Debuggability

 The devtools support is under development.

 Just like with regular HTTP/3 traffic, the detailed information about
 the connection can be obtained via chrome://net-export interface.

 Will this feature be supported on all six Blink platforms (Windows,
 Mac, Linux,

 Chrome OS, Android, and Android WebView)?

 Yes

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

 No

 We have browser tests, but we are going to port them to WPT.

 Link to entry on the Chrome Platform Status

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

 --
>>> 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/9ffa05b8-fbbf-4f2a-975d-be72a1089ebcn%40chromium.org
>>> 

[blink-dev] Intent to extend the origin trial: WebTransport over HTTP/3

['Yutaka Hirano' via blink-dev]

Contact emails

yhir...@chromium.org,vasi...@chromium.org

Explainer

https://github.com/w3c/webtransport/blob/main/explainer.md

Design docs/spec

Specification: https://w3c.github.io/webtransport/#web-transport

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

TAG review

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


Summary

WebTransport is an interface representing a set of reliable/unreliable
streams to a server. The interface potentially supports multiple protocols,
but based on discussions on the IETF webtrans working group, we are
developing WebTransport over HTTP/3 which uses HTTP3 as the underlying
protocol.

Note that we were developing QuicTransport a.k.a. WebTransport over QUIC
and we ran an origin trial M84 through M90. It uses the same interface
WebTransport, but because of the protocol difference ("quic-transport" vs.
"https") it is difficult for web developers to be confused by them.

new WebTransport("quic-transport://example.com:9922")

represents a WebTransport over QUIC connection, and

new WebTransport("https://example.com:9922;)

represents a WebTransport over HTTP/3 connection.

Goals for experimentation

We're shipping the API in M97
.
Twitch, one of our partners, wants to continue their experiment until the
API is fully shipped. I think this is a reasonable request given we
originally aimed to ship the feature in M96 but we missed the branch point.


The original goals follow:


To see whether the API (and the implementation) is useful in various
circumstances.

Our partners want to evaluate this API on various network circumstances
(i.e., lab environments are not enough) to see its effectiveness.

We also expect feedback for performance.

Experimental timeline

M95 and M96

Ongoing technical constraints

None

Debuggability

The devtools support is under development.

Just like with regular HTTP/3 traffic, the detailed information about the
connection can be obtained via chrome://net-export interface.

Will this feature be supported on all six Blink platforms (Windows, Mac,
Linux,

Chrome OS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests

?

No

We have browser tests, but we are going to port them to WPT.

Link to entry on the Chrome Platform Status

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

-- 
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/CABihn6E%3Dt9x7isiuzyfCkCQ8QEu47U%2Bp18UnHxHgqOLVaOQzmg%40mail.gmail.com.

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
>