HTTP3/QUIC

[noellarkin]

There's a post from 2020 regarding this:
viewtopic.php?f=65&t=24685#p193072

Right now, http3 protocol used by Google, Facebook, Amazon etc etc - - and more importantly, in things like Cloudflare and Recaptcha, which are served on millions of websites. The consensus of the Pale Moon team in 2020 was that there was no immediate need to implement it. Is that still the case?

[RealityRipple]

This was always a concerning eventuality to me... There are numerous technical security-related caveats that make me worry about HTTP/3, and I have past trauma regarding the lossy mess that is UDP. That's my own opinion, though.

The real question is, will it ever actually become necessary? Are there any webserver projects or websites that actively only support HTTP/3? Or even any that only support 2? Or 1.1?

[noellarkin]

The real question is, will it ever actually become necessary? Are there any webserver projects or websites that actively only support HTTP/3? Or even any that only support 2? Or 1.1?

In the short term, It may become another one of those 'feature detection' nuisances that are the reason why I get so many more captchas and Cloudflare turnstile pages when I use a non-Chromium browser.

It may also be the case that HTTP3/QUIC is being implemented primarily to help ad-serving companies like Google and Facebook de-anonymize users. Found this online when reading up on the subject:

The QUIC protocol allows servers to identify the real IP address of a client through the "CID" (Connection ID) field in the QUIC packet. The CID field contains information about the client's IP address and helps the server determine the request's origin. Based on the CID field, the server can know the real IP address of the client, regardless of whether the client is using a proxy.
In the case of a client using a proxy, the proxy acts as an intermediary forwarding requests from the client to the server. However, through the CID field, the server can still identify the real IP address of the client without being affected by the proxy's IP address.
Additionally, QUIC integrates TLS (Transport Layer Security) to ensure data security during transmission. TLS provides authentication and client validation mechanisms, helping determine whether the client has access rights and linking IP address information to client authentication.

[Moonchild]

HTTP3/QUIC is a disaster of a spec I don't want to touch. The entire premise of it is totally flawed, and anyone with basic networking knowledge would see this. Why do i say this? Because HTTP transport by its very design is a stateful protocol, just like TCP is that it sits on top of. Shoving that through the network through the stateless UDP protocol is a terrible mistake.

Of course there are considerable privacy issues involved with it (because as already indicated UDP has deeper penetration into networks, does not separate network information from data (can of worms there) and can traverse network boundaries).
There is also the question of how beneficial it actually is in terms of performance, and it should draw attention that what was initially complained about regarding HTTP/1.1 pipelining (a head-of-line delay, which we with Pale Moon have actually never seen to be an issue!) was supposed to be "fixed" by design in HTTP/2, but it was brought up once again for QUIC. Did everyone forget that one of the design goals of HTTP/2 was exactly this head-of-line issue?

In all practicality, the advantages and disadvantages of this mean effectively nothing. Saving a round-trip in QUIC when setting up encryption has the same risks as HTTP/2 0-rtt. For that reason alone I would not want to use it. Packet roundtrips are very fast in 2024 and you'd be hard-pressed to notice <50 ms latency due to a longer handshake when loading a "modern" website, anyway.
Then there is the fact that it will, by design, perform flow-control at the application level, meaning several context switches removed from where dedicated networking hardware would normally handle connectivity setup and packet (re)transmission. Talk about massive overhead.
Why sideline dedicated, super-efficient networking hardware in favour of manually handling flow control in the application layer? That makes very little sense to me -- unless maybe you are Google or another large-scale internet data provider who would benefit from skimping on networking hardware and shaping the internet protocols to suit their own economic needs, of course.

As for compatibility -- HTTP protocols are extremely-long-lived protocols. Don't expect HTTP/3 to be forced or being used exclusively.

Ultimately my 2¢ is that Google can do Google things since they control both the client engine and the server engine, but that doesn't mean decades of other technology should or would be thrown out.

Of course it does open the door to further discrimination of browsers and packet routes that don't support this protocol (e.g. deliberately delaying HTTP 1.1 and 2 transports), but I'm not assuming conspiracies, here. It's likely just primarily an economic push for scale.

[jobbautista9]

Off-topic:
I will never understand why they won't just go for an elegant, very long-term replacement of HTTP/1.1 which is one that would eliminate and prohibit cookies and use SCTP instead of TCP or UDP... Just like HTTP/2 it's most likely that HTTP/3 is gonna be thrown to the bin when Google decides it's still "not fast enough". And HTTP/1 will live on 'til the heat death of the universe or the end of civilization, whichever comes first. I hate this since there is definitely significant rooms of improvement from HTTP/1.1, and both versions 2 and 3 are just disappointingly insufficient and introduce their own set of tricky problems.

[KLASS]

QUIC must never be allowed to spread.
If Google and the gang succeed in pushing this dirty project through, the last vestiges of privacy and anonymity for ordinary users will fall.