Hi Philip, On Wed, Sep 29, 2021 at 6:29 PM Philip Jägenstedt <foo...@chromium.org> wrote:
> Hi Yutaka, > > This is a big new feature and a lot to go over. When looking at the > spec+Blink IDL, I noticed the API didn't require secure contexts: > https://bugs.chromium.org/p/chromium/issues/detail?id=1253275 > > It looks like that's being fixed now, which is great! I'll reply again > when I've spent some more time reading here. > Thank you for pointing it out, and sorry for not fixing this earlier. > On Wed, Sep 29, 2021 at 12:08 AM Emily Stark <est...@chromium.org> wrote: > >> I want to note that there are some pretty big open questions in >> https://github.com/w3c/webtransport/issues/349. I think we might want to >> have more restrictions on the allowed types of certificates than the spec >> currently outlines, and introducing those restrictions after shipping the >> feature would carry compatibility risks. >> >> On Sun, Sep 26, 2021 at 9:55 PM Yutaka Hirano <yhir...@chromium.org> >> wrote: >> >>> Contact emails >>> >>> yhir...@chromium.org, vasi...@chromium.org >>> >>> Explainer >>> >>> https://github.com/w3c/webtransport/blob/main/explainer.md >>> >>> Specification >>> >>> https://w3c.github.io/webtransport >>> >>> https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3/ >>> >>> https://datatracker.ietf.org/doc/html/draft-ietf-quic-datagram/ >>> >>> Design docs >>> >>> https://web.dev/webtransport/ >>> >>> >>> https://docs.google.com/document/d/1UgviRBnZkMUq4OKcsAJvIQFX6UCXeCbOtX_wMgwD_es/edit >>> >>> 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. >>> >>> This time, we want to ship the core part. The following features are >>> excluded: >>> >>> - >>> >>> Connection sharing >>> - >>> >>> Stream Prioritization >>> - >>> >>> Statistics >>> - >>> >>> WebTransport over HTTP/2 >>> >>> >>> Blink component >>> >>> Blink>Network>WebTransport >>> >>> TAG review >>> >>> https://github.com/w3ctag/design-reviews/issues/669 >>> >>> TAG review status >>> >>> Pending >>> >>> Risks >>> >>> Interoperability and Compatibility >>> >>> This is a new API and doesn’t change any existing behaviors. >>> >>> Gecko: Worth Prototyping >>> <https://github.com/mozilla/standards-positions/issues/167>. They are >>> actively involved in the specification effort. >>> >>> WebKit: No signal >>> <https://lists.webkit.org/pipermail/webkit-dev/2021-September/031980.html> >>> . >>> >>> Web developers: Positive >>> >>> Twitch >>> >>> https://twitch.tv >>> >>> >>> >>> Twitch is using WebTransport to serve live video to our users with lower >>> latency and higher quality. We plan on rolling out our new playback >>> experience once it's fully available given our positive results. >>> >>> >>> >>> WebTransport offers all of the benefits of QUIC, but in a browser >>> environment and without the constraints of HTTP semantics. Most notably we >>> can push data over multiple streams, eliminating head-of-line blocking and >>> enabling new functionality during congestion. This is not possible with >>> existing browser standards such as WebSockets and WebRTC data channels. >>> >>> Google Stadia >>> >>> https://stadia.google.com/ >>> >>> “Google Stadia is using the WebTransport API in conjunction with the >>> WebCodecs API for several use cases, both internally and with partners. The >>> underlying WebTransport protocol, QUIC, has far greater throughput and >>> resiliency characteristics than other mechanisms available, which enables >>> use cases like webcams, and transmission of results of browser-based >>> processing to applications and games in the cloud. The capability to >>> transmit datagrams to cloud endpoints enables many new use cases for Stadia >>> including communication with custom hardware endpoints. In the future we >>> hope to explore using this API for other use cases.” >>> >>> Ergonomics >>> >>> The API is built around ReadableStream/WritableStream interfaces, which >>> means that its core I/O principles would be familiar to the developers who >>> had already used Streams via Fetch and other APIs. >>> >>> The API does not use cookies, HTTP authentication or socket pooling. >>> This would help us avoid unexpected interactions with the other elements of >>> the network stack. >>> >>> Activation >>> >>> Since UDP is often blocked on the network, the developers have to assume >>> that the API often would not work even in the situations when it is >>> implemented in the browser. >>> >>> Security >>> >>> See <https://wicg.github.io/web-transport/#privacy-security> for more >>> info. >>> >>> >>> >>> We allow web developers to use an alternative certification verification >>> method than the usual HTTPS way. We allow a web developer to connect to a >>> WebTransport over HTTP/3 server when its certificate’s fingerprint matches >>> with the developer provided fingerprint. This is discussed at >>> https://github.com/w3c/webtransport/issues/349 and we will update the >>> spec shortly. >>> >>> Debuggability >>> >>> Printing an error message with the reason when the opening handshake >>> fails. >>> >>> We show outgoing WebTransport sessions 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 >>> WebTransport sessions, thus avoiding the performance decrease that would >>> cause. >>> >>> Just like with regular HTTP/3-based QUIC traffic, detailed information >>> about the connection can be obtained via chrome://net-export interface. >>> >>> Is this feature fully tested by web-platform-tests? >>> >>> Yes >>> >>> We are writing WPTs (/webtransport >>> <https://wpt.fyi/results/webtransport?label=experimental&label=master&aligned>). >>> We expect the task to be completed by the branch point. The >>> WebTransport over HTTP/3 server for testing >>> <https://github.com/web-platform-tests/wpt/tree/master/tools/webtransport> >>> is running locally, but we need more time to run it on wpt.live or >>> Chromium CI. >>> >>> Requires code in //chrome? >>> >>> False >>> >>> Tracking bug >>> >>> https://crbug.com/10111392 >>> >>> Link to entry on the Chrome Platform Status >>> >>> https://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/CABihn6HZaCbG_q8wVv0ukaGRwir-%2BVr0yQTGy3nXH0Qwa1fe%3Dg%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABihn6HZaCbG_q8wVv0ukaGRwir-%2BVr0yQTGy3nXH0Qwa1fe%3Dg%40mail.gmail.com?utm_medium=email&utm_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/CAPP_2SYf_fTncwUqaO3oTvY-Vvv36xYTeiFC85Fo%2B90yVfFxvw%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPP_2SYf_fTncwUqaO3oTvY-Vvv36xYTeiFC85Fo%2B90yVfFxvw%40mail.gmail.com?utm_medium=email&utm_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/CABihn6HMf28dqNFEBf0Sppexm9Qn%3Dq5ePGsiK8o5cAe090H2Uw%40mail.gmail.com.
