Spec should define how the feature interacts with blocking tools (filterlists etc.)

[pes10k]

Blocking tools (uBlock Origin, AdBlock Plus, Disconnect, etc) are important parts of privacy on the web. The proposal has several aspects that make it not obvious how blocking tools would interact with this functionality. Partial list:

• If I'm mulitplexing over the existing HTTP3 connection, how can I block the Web Transport request (since no new request is happening)
• Most blocking tools focus on blocking the initial request. The spec seems to envision connections that require no additional request, just receiving server push messages (for example, layering over HTTP3 and just listening). How can I block these?
• Can blocking tools see into the communication, and block some messages but not others?

The above is just a partial list, but meant as motivating ambiguous (or, at least to an outsider, unclear) cases. Having the spec more clearly define how, and with what decision, blocking tools can make decisions, would be very useful in understanding the spec's privacy properties.

[ricea]

Extensions are technically not part of the web platform, and so are not normally covered by standards.

I would expect each browser would define their own blocking semantics. My expectation is that blocking would happen immediately after the creation of the QuicTransport or Http3Transport object.

Blocking on a per-message basis would likely incur considerable overhead, and so would be less likely to be implemented.

[pes10k]

Generally how this has been done in the past is to define (in normative text) how the communication interacts with the Fetch API, which has well expected interactions with WebRequest API. You could then (semi-redundantly) describe how extensions could interact with the new functionality in non-normative text.

So, I appreciate that there isn't a WebExtensions W3C spec, but adding new ways of pages communicating w/ hosts, w/o describing and setting expectations for how clients and extensions can mediate that communication is scary from a privacy perspective (since, for most people, extensions are the main way people claw back any control over their privacy)

[ricea]

In general, it doesn't interact with the Fetch API. However, we can normatively describe how it interacts with CSP.

[martinthomson]

So this is a really interesting problem. On the one hand, Adam is right regarding the effect that this might have on the final specification that is built here. I agree that it isn't necessary to document what affordances are being made for content filtering and blocking.

However, I think that it is important to recognize the effect that design choices have on these techniques. Content filtering or blocking is very common for a variety of reasons. A protocol that uses stable identifiers (like domain names) provides these tools good handles on which it can operate. As the current design relies on URLs with domain names, it would seem that the needs of blockers are accounted for, with one exception.

Use of self-signed certificates, which can be authorized through the provision of a certificate fingerprint, makes it possible to avoid name-based blocking. I don't particularly like that feature for a range of reasons, including this. Though this is more of a problem for the IETF working group, which is responsible for concepts like resource identity, I believe that it is important to consider in the design. My current view is that if self-signed certificates are that important (I'd prefer not to keep them, honestly), maybe the only way to deal with that is make them trivially distinguishable as such.

[yutakahirano]

Chrome is planning to update https://developer.chrome.com/docs/extensions/reference/webRequest/ for the WebTransport over HTTP/3 support.

[yutakahirano]

I think we don't need to "resolve" this issue by the initial release.

[jan-ivar]

In general, it doesn't interact with the Fetch API.

Not the API, but we've recently integrated WebTransport more closely with fetch spec algorithms if that helps web extensions.

Chrome is planning to update https://developer.chrome.com/docs/extensions/reference/webRequest/ for the WebTransport over HTTP/3 support.

@yutakahirano This sounds promising! Would you anticipate this resolving all issues in the OP?

@mixedpuppy @martinthomson Would this solution satisfy needs from a Mozilla pov, or do we have input?

[yutakahirano]

Both of the API and protocol have changed much since this issue was filed.

If I'm mulitplexing over the existing HTTP3 connection, how can I block the Web Transport request (since no new request is happening)
Most blocking tools focus on blocking the initial request. The spec seems to envision connections that require no additional request, just receiving server push messages (for example, layering over HTTP3 and just listening). How can I block these?

Our implementation allows extensions to block WebTransport over HTTP/3 session establishment. A WebTransport over HTTP/3 session is started with an HTTP CONNECT request and response, and the handshake is exposed to extensions similar to usual HTTP request/response. I expect that won't change even when we support allowPooling. Extensions cannot observe or intervene after that - it cannot know when a stream is created, for example.

Can blocking tools see into the communication, and block some messages but not others?

No.

cc: @yoichio

[yutakahirano]

GoogleChrome/developer.chrome.com#1128

[jan-ivar]

The spec now uses fetch to connect using the obtain a connection algorithm.

See also @yutakahirano's comment directly about Chrome supporting webtransport in the Web Request api.

@pes10k can this be closed now?

[pes10k]

Hi @jan-ivar ; that change would address the issue for me. I don't see that change in the doc though. Can you link me to the PR or part in the spec? The only mention i see in the spec about fetch is about cert validation. Am i missing something?

[jan-ivar]

@pes10k it's here: "5. If should request be blocked by Content Security Policy? with request returns "Blocked", or if request should be blocked due to a bad port returns blocked, then abort the remaining steps ..." — The latter is fetch's block-list algorithm.