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.
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:// 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:
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...
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.
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.
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.
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
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
12 comments
[ 1.7 ms ] story [ 43.4 ms ] threadhttps://chromium.googlesource.com/chromium/src/net/+/master/...
Also QUIC requests show up in devtools fine
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:
That's not true, competitors can use QUIC or 0-RTT features in TLS 1.3.> 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:// 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...
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...
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/
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.
I don't have any insights re: Gecko vs Blink.
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.
- 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
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