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. 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/CAARdPYfxTXEOdV%3Der6H5T-Ck9xF8Lb9VHmtTTHLNwGFRC_63Ug%40mail.gmail.com.
