Hacker News Reader

Comment by legulere | Hacker News Reader

> in which case this might as well be a paper saying the iPhone is vulnerable to an attack but it turns out it means a 1980s device named "iPhone" not the Apple product.

More like it means the iPhone X instead of the newer iPhone 11

View on HN

A more accurate analogy based on the relationship between gQUIC and IETF QUIC would be that an early non-released version of the iPhone is vulnerable to an attack.

Do any user agents still use gquic? People still use old phones but pretty rarely old versions of chrome.

Pretty sure Chromium/Chrome/derivatives still support gQUIC.

There hasn't been any Intent to Remove, and it was mentioned in https://groups.google.com/a/chromium.org/g/blink-dev/c/K3rYL..., so yes I think it still supported.

On the other hand, since this set of vulnerabilities seems to be about passive fingerprinting by intermediaries, what actually matters is how much traffic is still running gquic, right? And I think most servers have moved over to HTTP/3?

(Disclosure: I work for Google, speaking only for myself)

Given gQUIC was never _that_ broadly deployed (mostly Google and a few CDNs, IIRC), I can't imagine it would be overly significant to disable. Last I knew there were some Google properties still using gQUIC, but that was a while ago.

Current versions of Chrome still use gQUIC for most instances when talking with gQUIC-capable servers such as Google and Youtube.

Just checked, mine used version Q050 just now.

Of course, there are many versions of gQUIC, some more like IETF QUIC than others as they are transitioning parts of the protocol in stages. Version Q050 is the pre-TLS version.

As it's used between Chrome and Youtube, a lot of the world's internet traffic is over gQUIC at the moment.

But this can indeed might make a difference if you're talking vulnerabilities and support - for example, iPhone 10 is vulnerable to checkm8 while models 11 and newer aren't.

Reply on news.ycombinator.com