
QUIC in the wild, only for Google ad advantage - cpeterso
https://blog.brave.com/quic-in-the-wild-for-google-ad-advantage/
======
cotillion
Considering the QUIC source is available this article is a bit silly. It's not
Googles fault that other ad-networks have ignored QUIC.

[https://chromium.googlesource.com/chromium/src/net/+/master/...](https://chromium.googlesource.com/chromium/src/net/+/master/quic/)

~~~
saddlerustle
Seriously. QUIC was announced 4 years ago.

Also QUIC requests show up in devtools fine

------
comex
Well, this post makes some claims that are either false or at least extremely
misleading.

> QUIC runs on top of the UDP protocol. The Chrome webRequest API does not
> have permission to access the udp:// scheme, therefore extensions that rely
> on webRequest to block ad and tracking requests cannot see QUIC requests.
> There is no other API available to extensions that can detect and block
> QUIC.

QUIC requests are not logged as using the udp:// scheme. They're regular
[https://](https://) URLs; QUIC vs. TCP is a lower-level decision.

Since the explanation didn't make sense, I decided to test whether the claim
was true, i.e. the webRequest API cannot see QUIC requests. I randomly
searched the extension store for something that could log all requests, and
found this weird extension:

[https://chrome.google.com/webstore/detail/my-
webrequest/ojod...](https://chrome.google.com/webstore/detail/my-
webrequest/ojodgdaaholkmelbddlhnfdgamohijhk/related?hl=en)

I went to www.google.com, and the dev tools showed that all requests were
being made over QUIC; the extension dutifully logged a bunch of requests with
request headers, etc. (To https: URLs.)

So unless something changed recently, either the author is wrong, or they
meant that extensions can't detect /the fact that QUIC is being used/, as
opposed to being unable to detect the requests at all. But I don't think that
interpretation makes much sense - why would "extensions that rely on
webRequest to block ad and tracking requests" care about whether QUIC is being
used?

On the other hand, that's the only possible interpretation for this other
claim:

> QUIC requests are currently not visible in the Network tab of Chrome
> Developer Tools, with default Network settings. The user is required to
> right click and select the Protocol menu option in order to view.

All that right clicking and selecting Protocol does is toggle the Protocol
column in the list of requests. It doesn't show or hide any requests. Surely
the author knows that if they tried the option in question, so I guess they
must have meant, again, that /whether a request is QUIC/ is "not visible".
Unless you press the button to make it visible. I don't really see why the
author has a problem with that, since for most purposes it doesn't matter, and
it's easy to enable. And again, the wording makes it sound like something a
lot worse.

This really makes me question the technical competence of the Brave team...

------
jupp0r
The author seems to be strongly biased and is missing some important pieces of
information. Mainly:

QUIC is an open protocol, the spec and chromiums implementation are public.
The fact that work on an IETF RFC is currently being performed attests to
that.

As the author points out, QUIC has been announced in 2013. That's plenty of
time for Google's competitors to use QUIC in their own infrastructure.

There are also some misleading pieces of information in the article:

    
    
      Competitors are bound to using TCP requests that require extra round trips
    

That's not true, competitors can use QUIC or 0-RTT features in TLS 1.3.

------
grabcocque
The author is making it seem like Google is doing something sinister here.

But Google submitted the QUIC drafts and it's being developed in the open
under the aegis of the IETF.

[https://datatracker.ietf.org/wg/quic/](https://datatracker.ietf.org/wg/quic/)

QUIC seems to be following the playbook Google set with SPDY and its eventual
maturation into HTTP2. I think everyone is happy with how that process turned
out, so I think Google have earned the benefit of the doubt given they're
handling QUIC the exact same way.

------
bsclifton
While QUIC is an open protocol and the source is available, I personally
believe the issues here are:

\- Google has majority share of browsers with Chrome

\- Chrome has QUIC enabled by default (opt out via chrome://flags)

\- Google has a large amount of resourcing allocated to Chrome/Chromium. They
ultimately control whether or not code is accepted

\- Google also owns DoubleClick; ads are already being pushed using QUIC

\- Regular end users are likely not aware of QUIC. Sure, a more advanced user
can show it in the dev tools if you enable it and then look for it. But the
problem is more that people aren't aware this is something to look for and
they are opted into this

Showing a banner and trying to sell a product is one thing. But using a
protocol that the user is not explicitly approving of to track / advertise is
another thing. It seems to me (and maybe I'm wrong) that they are using their
borderline-monopoly position in the browser market to opt people into
questionable advertising technology

~~~
mbleigh
What effect does a transfer protocol have on the average user? If they knew,
why would they care? Genuinely curious.

~~~
bsclifton
How widely adopted is QUIC outside of Google? If Google (including
DoubleClick, etc) sites are the only ones using QUIC, it's a little unusual
IMO to enable an experimental protocol by default

For example: this technology looks cool. How can I take advantage of QUIC to
speed up my personal hosted content? Is there a module for nginx or an Apache
mod_quic I can install? The code is out there of course, but it seems prebuilt
options are limited

------
xuejie
This is slightly unrelated but just curious about this: is there any
documentations regarding why Brave is built using Chromium as the core browser
engine? Since Brendan Eich founded Brave, it should be quite natural to base
Brave on top of Gecko or maybe even Servo.

~~~
bbondy
I'm a co-founder on Brave. Brave was actually built on Graphene, which is
Gecko at the start, similar to Mozilla's browser.html project which was
created by paulrouget, Gozala, and gordonbrander.

We switched to Chromium within the first few months for various reasons
including performance and HTML JS based APIs being ready across platforms.

We do want to move to Servo once it's in a more complete state, it just has a
lot of years until it is ready.

~~~
xuejie
That makes total sense, thanks a lot!

