WebTransport

[vasilvv]

おはようTAG!

I'm requesting a TAG review of:

• Name: WebTransport
• Specification URL (WICG): https://wicg.github.io/web-transport/
• Specification URL (IETF): https://tools.ietf.org/html/draft-vvv-webtransport-overview-00
• Explainer (containing user needs and example code): https://github.com/wicg/web-transport/blob/master/explainer.md
• Primary contacts (and their relationship to the specification): @aboba @pthatcherg (WICG editors) @vasilvv (IETF draft author)

Further details:

• Relevant time constraints or deadlines: a review of at least the general concept before IETF 105 (July 20) would be helpful.
• I have read and filled out the Self-Review Questionnare on Security and Privacy. The assessment is here.
• I have reviewed the TAG's API Design Principles
• The group where the work on this specification is: WICG in W3C; TBD in IETF.

You should also know that...

• This is a successor to RTCQuicTransport #303, but it is fairly different in scope, so we are requesting it being reviewed de novo.
• The spec currently doesn't use the Streams API, however, a refactor for that is in progress.
• Some good discussion on motivations behind this API on WICG Discourse: https://discourse.wicg.io/t/webtransport-proposal/3508
• Some extra motivation described in this email: https://mailarchive.ietf.org/arch/msg/dispatch/sIih9gBhJ4_faoN0GrQ9Xweue2w

We'd prefer the TAG provide feedback as (please select one):

• open issues in our GitHub repo for each point of feedback
• open a single issue in our GitHub repo for the entire review
• leave review feedback as a comment in this issue and @-notify @vasilvv

[dbaron]

A few very preliminary comments from spending an hour or two starting to look over the various documents:

From looking at the explainer, it seems like the "Detailed design discussion" and "Alternative designs considered" sections could perhaps be fleshed out a little bit more. One example of something I'd have liked to learn from those sections that I didn't would be how this proposal differs in scope from the previous RtcQuicTransport proposal; I think there are probably a bunch of other big picture things that are in your head, aren't obvious, and would be useful for the TAG to understand while reviewing.

It would likely also be useful for the explainer to explain how this spec relates to the WHATWG Streams specification.

It would also be useful to understand why the spec currently doesn't expose these in workers, and whether there's a future plan to do so.

Is there a section somewhere, either in the explainer or one of the two specs, that explains how the two specs (the one in WICG and the one in IETF) fit together?

---

A few very detailed comments on bits that I noticed while jumping around to look at some examples of things:

I'd note that the if (!!chunk) in one of the examples is a C++-ism and the !! is not idiomatic in JS (although not really needed in C++ either).

receiveDatagrams() may only be called once at a time. If a promised returned from a previous call is still unresolved, the user agent MUST return a new promise rejected with an InvalidStateError.

This seems a little bit odd, and likely to be a bit of a programming hazard (producing rejections in unexpected ways, depending on timing/races). Would it make more sense to return an empty sequence? That said... in the context of understanding why this method is asynchronous -- would it even be guaranteed to be empty? If it's asynchronous because the datagrams are on their way over from another thread or process... might asking for more not yield more?

Also, it seems like the type of receiveDatagrams is slightly wrong, since the prose says that it allows nulls in the result. It seems like it should be Promise<Sequence<Uint8Array?>>.

[dbaron]

(I realize those detailed comments may quickly become irrelevant if there's a big refactor to integrate with the streams spec, as one of the other links suggested.)

[pthatcherg]

Responses to dbaron's comments from 10 days ago:

RTCQuicTransport is the p2p impl of a WebTransport. I made w3c/webtransport#41 to track making that more clear.

The explainer has now been updated to use WHATWG streams. We plan to update the spec to use them as well after some more discussion on how WHATWG streams should work (in particular for creating send streams and bidirectional streams).

We definitely want WebTransports to work in WebWorkers, we simply didn't think to say that explicitly.

The W3C spec references the IETF specs. Victor made w3c/webtransport#37 to track that.

I can't find any example of "!!". Perhaps that went away when we moved to WHATWG streams in the explainer.

On the nullability of receiveDatagrams(): you're right, that's a mistake. But we decided on a different approach that doesn't return null (see w3c/p2p-webtransport#124). We just need a PR for it.

On the goofiness of receiveDatagrams() only being called once at a time: that will probably go away with
the switch to WHATWG streams.

[dbaron]

@cynthia and I are currently looking at this in a breakout.

So far I'd note that we found that there are additional documents that seem critical to understanding this, in particular:

• https://tools.ietf.org/html/draft-vvv-webtransport-quic-00
• https://tools.ietf.org/html/draft-vvv-webtransport-http3-00

[plinss]

dbaron to invite Martin Thomson to a future call

[cynthia]

@ylafon and I discussed during our Wellington F2F.

We think this proposal is extremely interesting, and will bring a whole new set of capabilities to the web. However, we also consider this a pretty powerful feature - and was wondering about the implications of the constructor magically connecting, hence not being able to be a promise. (which would allow gating it behind a permission) We also had some concerns about port scanning through this mechanism (e.g. through timing based testing, albeit it would only work on UDP ports for now) but it does feel like gating this behind a permission would be good enough as a mitigation.

[cynthia]

@plinss @dbaron ping on the Martin Thomson call issue noted above.

[aboba]

@cynthia The WebTransport constructor was modeled after the WebSockets constructor which also immediately establishes a connection.

To address the port-scanning issue we could prevent WebTransport from connecting to ports on the "bad ports" list.

[cynthia]

@aboba WebSockets is less powerful, and hence was never gated. This is a significantly more powerful API, so I think different considerations has to apply. As for the bad port blacklisting, those I believe are TCP ports; not sure if that blacklist would apply here.

[vasilvv]

What are the specific ways in which WebTransport is more powerful than WebSocket that are of security concern here?

[annevk]

w3c/webtransport#110 seems somewhat relevant for the TAG review. (Also applies to some of the other class names I realized, e.g., QuicTransport.)

At least from Mozilla's review of this I don't think we found reason to permission-gate this and even "bad ports" might not be needed due to the specifics of the networking handshake. @martinthomson might recall this better. Having said that, I believe @ricea still plans on doing a stream-based version of WebSocket and it seems this should be more analogous to that than to WebSocket itself.

[martinthomson]

Yes, I think that we can avoid the port list and the permissions. Port scanning can be addressed by having the connection fail with a minimum timeout and no error codes that expose how it failed (maybe with some exceptions that we can carefully vet). After that, you leak no information until the server consents to communicate with this origin.

The big concerns are that we keep this and the new WebSocket stuff in sync so that they share what they need to (and that we don't do the same work twice). I'm assured that there is good coordination with Google between the teams, so that much is good.

[aboba]

@martinthomson Are you referring to WebSocketStream? There are some differences, but they were closed as "won't fix":
w3c/webtransport#50
w3c/webtransport#51

[annevk]

In light of https://docs.google.com/document/d/1La1ehXw76HP6n1uUeks-WJGFgAnpX2tCjKts7QFJ57Y/edit those make sense I think, w3c/webtransport#54 appears unaddressed still.

[martinthomson]

Not sure that "Peter talked to Adam" is sufficient for a decision, though I appreciate that this is a personal submission, so it does have a different standard.

Now sure how the WebSocketStream API is necessarily distinct based on the proposal.

[ylafon]

Sangwhan and just discussed this and we are fine with not gating with a permission to avoid port scanning as long as there is no way to infer what is happening by doing time-based analysis (connecting to a filtered port takes far more time than a blocked one or one responding with another protocol).

[cynthia]

@dbaron and I discussed this during a breakout today, and concluded that given the above port scanning mitigations are in place we are happy to see this proposal move forward. Thanks for bringing this to our attention, and we plan to close this after discussing with the group.

We'd like the group to actively engage in review with relevant experts while development progresses. (In particular, networking is one of our weak points, so we might have missed something important.)