Intent to Experiment: QuicTransport

339 views
Skip to first unread message

Yutaka Hirano

unread,
May 14, 2020, 2:52:01 AM5/14/20
to blink-dev
yhi...@chromium.org,vas...@chromium.org https://github.com/WICG/web-transport/blob/master/explainer.md Specification: https://wicg.github.io/web-transport/#quic-transport https://docs.google.com/document/d/1UgviRBnZkMUq4OKcsAJvIQFX6UCXeCbOtX_wMgwD_es/edit https://github.com/w3ctag/design-reviews/issues/389 QuicTransport is an API that allows Web applications to connect directly to remote servers using QUIC. It is a part of the WebTransport framework; Http3Transport and FallbackTransport are not covered by this enhancement. 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. Note: We are planning to add a feature which allows web developers to connect to a server which doesn't have a valid certificate (https://github.com/WICG/web-transport/pull/100). The feature is not included in M84 but will be in M85. M84-M86 None Printing an error message with the reason when the opening handshake fails. We're planning the following but they are not available during the origin-trial period. The current plan is to show outgoing QuicTransport connections in the “Network” section of DevTools, the same place where WebSocket connections are shown. Unlike WebSockets, we do not intend to show the actual contents of the QuicTransport sessions, thus avoiding the performance decrease that would cause. Just like with regular HTTP/3-based QUIC traffic, the detailed information about the connection can be obtained via chrome://net-export interface. Yes No We have browser tests, but we are going to port them to WPT shortly. https://www.chromestatus.com/feature/4854144902889472  

Yutaka Hirano

unread,
May 14, 2020, 5:00:12 AM5/14/20
to blink-dev
We've just created a public mailing list for WebTransport: https://groups.google.com/a/chromium.org/forum/#!forum/web-transport-dev/. Feel free to join the list if you're interested in this API.

Thanks,

Mike West

unread,
May 14, 2020, 3:29:40 PM5/14/20
to blink-dev
After a conversation with the team earlier in the week, I'm comfortable with this shipping as an origin trial to get some feedback from the wild about how it works and whether it solves the problems the team is aiming to solve.

That said, I have a few thoughts about things that we should revisit before moving from OT to stable:

1.  The integration with exfiltration mitigation tools like CSP, extensions, etc. needs to be spelled out and implemented. It would be Bad™ if this communication channel wasn't visible to (and blockable by) extensions, and similarly bad if developers weren't able to constrain it via something like `connect-src`.

2.  I remain a bit skeptical about departing from the web PKI (https://github.com/WICG/web-transport/pull/100), for a few reasons:

  a. We're in the process of strengthening the promise we make to use around mixed content, and the confidentiality of user data on pages that aren't positively marked as "Not Secure". Delegating the ability to decide what's trustworthy-enough to the page, as opposed to keeping that responsibility in the browser, feels very odd, and I suspect we're going to find out that it enables more bad things than we know about today. vasilvv@, et al. rightfully point out that we're already shipping this mechanism via WebRTC's data channels. That means there's no incremental risk in moving to OT, but it's something I'm uncomfortable with. The team suggested that there were ways of making the carveout from the web PKI somehow costly to the implementer, such that it couldn't be used for bad purposes. I'd like to hear more about those mitigations before shipping. vasilvv@ noted that there's a lifetime limit on certs accepted by the fingerprinting mechanism. I'd like to hear how that works out, and whether there are other forcing functions we can put into place for the future.

  b. It's not clear how we know whether or not to trust any URL-based filtering mechanism if that mechanism can't rely upon the assertions of actual ownership that would be provided by gathering a publicly trusted cert for a given hostname. vasilvv@ suggested that embedding the fingerprint in the `quic-transport:` URL scheme might give us the ability to perform that kind of filtering, and prevent folks from abusing this mechanism to avoid extensions. I'm interested in hearing more about what that might look like.

So. LGTM to origin trial, with the understanding that we'll continue the conversations around the questions above.

-mike


On Thursday, May 14, 2020 at 11:00:12 AM UTC+2, Yutaka Hirano wrote:
We've just created a public mailing list for WebTransport: https://groups.google.com/a/chromium.org/forum/#!forum/web-transport-dev/. Feel free to join the list if you're interested in this API.

Thanks,

On Thu, May 14, 2020 at 3:51 PM Yutaka Hirano <yhi...@chromium.org> wrote:
yhi...@chromium.org,vasilvv@chromium.org https://github.com/WICG/web-transport/blob/master/explainer.md Specification: https://wicg.github.io/web-transport/#quic-transport https://docs.google.com/document/d/1UgviRBnZkMUq4OKcsAJvIQFX6UCXeCbOtX_wMgwD_es/edit https://github.com/w3ctag/design-reviews/issues/389 QuicTransport is an API that allows Web applications to connect directly to remote servers using QUIC. It is a part of the WebTransport framework; Http3Transport and FallbackTransport are not covered by this enhancement. 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. Note: We are planning to add a feature which allows web developers to connect to a server which doesn't have a valid certificate (https://github.com/WICG/web-transport/pull/100). The feature is not included in M84 but will be in M85. M84-M86 None Printing an error message with the reason when the opening handshake fails. We're planning the following but they are not available during the origin-trial period. The current plan is to show outgoing QuicTransport connections in the “Network” section of DevTools, the same place where WebSocket connections are shown. Unlike WebSockets, we do not intend to show the actual contents of the QuicTransport sessions, thus avoiding the performance decrease that would cause. Just like with regular HTTP/3-based QUIC traffic, the detailed information about the connection can be obtained via chrome://net-export interface. Yes No We have browser tests, but we are going to port them to WPT shortly. https://www.chromestatus.com/feature/4854144902889472  
Reply all
Reply to author
Forward
0 new messages