Having looked into it a bit, we should close this issue. While WebSockets and WebRTC are real privacy oversights, QUIC requests can be intercepted just fine (they look like regular https requests). The blog post above seems to overstate the case.

Or not? "Breakage can be intermittent depending upon whether QUIC or TCP is selected. http://Youtube.com  was where we originally found QUIC use"

https://twitter.com/lukemulks/status/856896086752886785

My understanding is that that blog post has some inaccuracies in it, but routing to the QUIC team for specific evaluation.

Agreed. Manual testing shows that ad blocking extensions do the right thing when QUIC is in use. Of course, software has bugs so please feel free to re-open if you find a repro.

I built a quic (pun intended) Chrome extension to see if I could repro the issue: https://github.com/diracdeltas/quic-request. It uses webRequest's onBeforeRequest listener to cancel all requests matching the filter '*://*.doubleclick.net/*'.

I loaded the extension into Chrome, enabled QUIC in chrome://flags, loaded up youtube.com, and still saw doubleclick QUIC requests in chrome://net-internals (screenshot attached).

Deleted: Screen Shot 2017-04-25 at 22.21.04.png 144 KB

	Screen Shot 2017-04-25 at 22.21.04.png 144 KB View Download

Re #5: Do you have the network log (https://dev.chromium.org/for-testers/providing-network-details) for this case and/or did you look at the Events tab in chrome://net-internals to see the flow of events?

With the extension in #5, I can repro the display of a googleads.g.doubleclick.net entry in the chrome://net-internals/#events&q=type:QUIC_SESSION%20is:active list.

However, I suspect this is an expected result where we believe the connection is going to be needed later so we preconnnect:

  205: HTTP_STREAM_JOB_CONTROLLER
  https://googleads.g.doubleclick.net/
  Start Time: 2017-04-25 17:53:42.816

  t=316 [st=  0] +HTTP_STREAM_JOB_CONTROLLER  [dt=160]
                --> is_preconnect = true                   
                --> url = "https://googleads.g.doubleclick.net/"
  t=316 [st=  0]    HTTP_STREAM_REQUEST_STARTED_JOB
                  --> source_dependency = 206 (HTTP_STREAM_JOB)
  t=476 [st=160] -HTTP_STREAM_JOB_CONTROLLER

... but ultimately by the time we get around to issuing the request, it's not, because the extension kills it:
  662: URL_REQUEST
  https://googleads.g.doubleclick.net/pagead/id
  Start Time: 2017-04-25 17:53:46.111

  t=3611 [st=0] +REQUEST_ALIVE  [dt=1]
               --> priority = "MEDIUM"
               --> url = "https://googleads.g.doubleclick.net/pagead/id"
  t=3611 [st=0]   +URL_REQUEST_DELEGATE  [dt=1]
  t=3611 [st=0]      DELEGATE_INFO  [dt=1]
                   --> delegate_blocked_by = "extension QUIC webRequest tester"
  t=3612 [st=1]      CHROME_EXTENSION_ABORTED_REQUEST
                   --> extension_id = "ejjcjbmlghojblfopokjfdfabplkhicc"

We do not, as far as I know, provide extensions with control over preconnections.

Re #6, here is a network log generated after restarting Chrome Stable and loading youtube.com

Deleted: chrome-net-export-log.json 1.3 MB

chrome-net-export-log.json 1.3 MB View Download

Re #8: Yes, the json you shared matches my findings. We see a few preconnections to the target servers, but all of the subsequent URL_REQUESTs are blocked with

  CHROME_EXTENSION_ABORTED_REQUEST
          --> extension_id = "dljphincejbibbfhepmphieaojbopkih"
  ERR_BLOCKED_BY_CLIENT

Re #9: thanks for looking at this. Indeed I see that the QUIC preconnection starts at t=29057, and the doubleclick ad request starts at t=31563 and is cancelled at t=31569 by the extension. The QUIC session stays open for a while after that and then is closed with:

t=58214 [st=29157]    QUIC_SESSION_CLOSED
                      --> from_peer = false
                      --> quic_error = 25 (QUIC_NETWORK_IDLE_TIMEOUT)
t=58214 [st=29157]    QUIC_SESSION_CLOSED
                      --> from_peer = false
                      --> quic_error = 25 (QUIC_NETWORK_IDLE_TIMEOUT)

Reopening this, and assigning to the privacy team to discuss the narrower question about whether or not extensions should control preconnects. My impression is that there's very little privacy implication to a socket connection in itself (and, honestly, I'm not even sure what a "preconnect" means in this context, given QUIC's 0-RTT mechanisms; are we doing a TLS handshake? Just warming up a socket?).

rdevlin.cronin@: FYI.

(Actually reopening/renaming)

 Issue 715249  has been merged into this issue.

> whether or not extensions should control preconnects

Maybe this could depends on whether the setting chrome.privacy.network.networkPredictionEnabled is false? (i.e. if false, extensions are called before preconnect).

Re #11: Yes, a cryptographic handshake is performed; you can see this in the chrome://net-internals log data, but I'm not convinced that this itself has a privacy implication.

It does seem to have some privacy implications. For instance a tracking domain can see the IP addresses of all clients that are running a tracker blocker that is preventing connections to them. Whether there are other implications beyond that deserves some thought.

Would the preconnections transmit TLS Channel IDs? SNI headers? If yes there's a bit more risk that these preconnections could be used for unblockable nefarious purposes.

RE #16: The "IP addresses of all clients" concern wouldn't be unique to QUIC, it would also apply to traditional HTTPS-over-TCP/IP. 

I'm not sure I understand the concern about SNI headers, since an "attacker" could simply name their host anything they like.

My involvement in privacy is reduced and in Web Request is null. I see this looping in more appropriate people, so removing myself.

Apologies for the delay in my reply.

I second mkwst@ and elawrence@ on their assessment that preconnect does not need to be controllable by the webRequest API, since there aren't privacy implications w.r.t. data being sent.

The only privacy implication, as peter.eckersley@ noted, is the pure fact that a connection is being made, i.e. that the client reveals its existence to a server.

However, this particular issue is independent of QUIC, and it's the reason why we have the "network prediction" setting. An ad blocker extension which cares about not revealing its presence to the web can simply use the chrome.privacy.network.networkPredictionEnabled API to disable it.

This should address rhill@'s suggestion above too - the preconnection should not happen in the first place if the setting is false.

And to double-check, +igrigorik@, can you please confirm that QUIC preconnect respects network prediction?

I discovered an issue today where chrome.webRequest.onBeforeRequest is not reliably capturing requests for httpVersion: http/2.0+quic/43

The handler detects Google Image Proxy requests (*://*.googleusercontent.com/*) containing tracking pixels in its hash fragment, blocking the proxied request, and issuing the de-proxied request.

For affected users, the handler does not detect any matching requests. Disabling the enable-quic flag allowed the handler to capture the request.

This is not consistent, however, as enabling the flag in my browser does not reproduce the bug. 

Both of our enable-quic flags were initially set to Default, and I confirmed that we were on the same extension version, so I suspect some users are on an experiment.

Is this related to this issue? 

Disabling enable-quic flag does not resolve the issue for all affected users. Some users report using Chrome Dev as a workaround. 
Attached is a HAR file where the extension failed to capture and cancel the request.

Deleted: mail.google.com-failure.har 6.2 KB

mail.google.com-failure.har 6.2 KB Download