Global QUIC over UDP protocol crimping for ad & privacy protection

[lukemulks]

• Did you search for similar issues before submitting this one?
  Yes

• Describe the issue you encountered:
  Quic over UDP used by Google to make ads and tracking requests, evades TCP

• Platform (Win7, 8, 10? macOS? Linux distro?):
  Windows 10 (observed), global (likely)

• Brave Version (revision SHA):
  0.12.5

• Steps to reproduce:
  1.wireshark || chrome://net-internals
  2. YouTube
  3.wait for ads

• Actual result:
  Shows ads and tracking

• Expected result:
  Blocked ads and tracking

• Will the steps above reproduce in a fresh profile? If not what other info can be added?
  Y

• Is this an issue in the currently released version?
  Y

• Can this issue be consistently reproduced?
  Y

• Extra QA steps:
  1.
  2.
  3.

• Screenshot if needed:
  

• Any related issues:

[diracdeltas]

just to clarify, is this issue for the adblock/tracking-protection components to block QUIC connections to tracking domains or is it to disable QUIC?

[lukemulks]

It's for disabling Quic. Google is using Quic for ads & tracking. Are there any concerns with blocking Quic?

…

On Jan 24, 2017 5:50 AM, "yan" ***@***.***> wrote: just to clarify, is this issue for the adblock/tracking-protection components to block QUIC connections to tracking domains or is it to disable QUIC? — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#6831 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIkDKEYtohBs12Xu9ak31oZds_cOwU8Kks5rVgGKgaJpZM4Lr_Ii> .

[lukemulks]

@diracdeltas updated the issue name to clarify. If there are any concerns regarding blocking QUIC globally please let us know. We don't want to cause any issues by blocking QUIC that we may be unaware of, but so far there appears to be little QUIC adoption and use outside of Google, and limited-low QUIC browser support by default outside of Chromium that doesn't include TCP failover.

FWIW, we were discussing globally blocking QUIC as a potential short term option, while we investigate other methods for specific QUIC blacklisting/whitelisting exceptions.

[bridiver]

we should add a second issue to filter quic connections. @lukemulks is the same thing happening with spdy?

[lukemulks]

@bridiver: - Hadn't checked SPDY, but double checked and Chrome v51 and FF v50 ended support for SPDY to replace w/ HTTP/2.0 over TCP (which I can see in Network Traffic in Dev Tools) - To be safe, I checked two session captures for NPN and ALPN traffic, and am not seeing any. I think we're safe there. - Will file a separate ticket for QUIC filtering. On Jan 24, 2017 11:58 AM, "Brian Johnson" <notifications@github.com> wrote: we should add a second issue to filter quic connections. @lukemulks <https://github.com/lukemulks> is the same thing happening with spdy? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6831 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIkDKJYUQd4GdgjNERODdl4v25PNs9soks5rVlfhgaJpZM4Lr_Ii> .

[diracdeltas]

If there are any concerns regarding blocking QUIC globally please let us know.

As you mention, QUIC has low adoption outside of Google, so I don't see any concrete downsides to disabling it. But it seems that we should generally be preventing webRequest bypasses, not disabling the protocols that bypass blocking.

[bridiver]

@diracdeltas that's why I wanted to open up a separate ticket to filter the requests, but in the short term blocking is fine I think

[bbondy]

Great find @lukemulks

[luixxiul]

Will this be included in 0.13.0?

[luixxiul]

@lukemulks would you let us know how to use wireshark for QA process?

[lukemulks]

@suguru *Re: **Will this be included in 0.13.0?* Yea, @bridriver was able to get this into the RC, and I was able to run QA against the previous Wireshark capture with 0.12.5 and confirm that the issue was resolved. *Re: QA w/Wireshark* Happy to help walkthru the process. Assuming that wireshark is installed and running, navigate to youtube.com or any other URL where QUIC is suspected to be running (it shouldn't be though, with the update @bridriver made, we should no longer see QUIC over the wire) Make sure that Wireshark is using domain name resolution, as it will help with spotting Google domains. Wireshark allows for sorting by protocol type (with the protocol column visible in the traffic capture), sort by protocol type and hunt for UDP or QUIC (wireshark treats UDP and QUIC as separate protocols in traffic captures). When QA'ing today, I was able to confirm that no UDP or QUIC protocol requests or responses were made in the session that I was comparing against, for the same URLs from 0.12.5. Happy to provide screenshots or a demo, anything at all to help. Like I mentioned, I don't think this will be an issue any longer in the short term, and longer term we have a separate issue filed for investigating similar filtering methods with QUIC/UDP that are currently in place w/AdBlocking and Tracking Protection lists over TCP. Let me know if there are any questions. :-) On Jan 25, 2017 11:12 PM, "Suguru Hirahara" <notifications@github.com> wrote: @lukemulks <https://github.com/lukemulks> would you let us know how to use wireshark for QA process? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6831 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIkDKLmN7C9_VGiLsEvtq9rvWUzJeG5rks5rWEdDgaJpZM4Lr_Ii> .

[bridiver]

@luixxiul I don't think we need further QA for this since @lukemulks has already checked it