HTTP3/QUIC

Talk about code development, features, specific bugs, enhancements, patches, and similar things.
Forum rules
Please keep everything here strictly on-topic.
This board is meant for Pale Moon source code development related subjects only like code snippets, patches, specific bugs, git, the repositories, etc.

This is not for tech support! Please do not post tech support questions in the "Development" board!
Please make sure not to use this board for support questions. Please post issues with specific websites, extensions, etc. in the relevant boards for those topics.

Please keep things on-topic as this forum will be used for reference for Pale Moon development. Expect topics that aren't relevant as such to be moved or deleted.
User avatar
noellarkin
Fanatic
Fanatic
Posts: 120
Joined: 2021-07-27, 04:20

HTTP3/QUIC

Post by noellarkin » 2024-06-28, 19:25

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?

User avatar
RealityRipple
Keeps coming back
Keeps coming back
Posts: 863
Joined: 2018-05-17, 02:34
Location: Los Berros Canyon, California

Re: HTTP3/QUIC

Post by RealityRipple » 2024-06-28, 19:37

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?

User avatar
noellarkin
Fanatic
Fanatic
Posts: 120
Joined: 2021-07-27, 04:20

Re: HTTP3/QUIC

Post by noellarkin » 2024-06-28, 19:55

RealityRipple wrote:
2024-06-28, 19:37
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.

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 37776
Joined: 2011-08-28, 17:27
Location: Motala, SE

Re: HTTP3/QUIC

Post by Moonchild » 2024-06-28, 20:30

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.

User avatar
jobbautista9
Keeps coming back
Keeps coming back
Posts: 957
Joined: 2020-11-03, 06:47
Location: Philippines

Re: HTTP3/QUIC

Post by jobbautista9 » 2024-06-29, 07:21

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. :coffee:

User avatar
KLASS
New to the forum
New to the forum
Posts: 1
Joined: 2022-06-08, 23:34

Re: HTTP3/QUIC

Post by KLASS » 2024-08-14, 20:45

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.

Lucio Chiappetti
Keeps coming back
Keeps coming back
Posts: 775
Joined: 2014-09-01, 15:11
Location: Milan Italy

Re: HTTP3/QUIC

Post by Lucio Chiappetti » 2024-11-05, 19:09

I missed this thread probably because it loOked unappealing to me as I did not know anything about QUIC.
Today I attended remotely the yearly GARR conference (GARR is the Italian academic network) and saw a presentation about statistics of QUIC usage by a CISCO person. And some (rightfully?) concerned comments by the audience.
The reasonable man adapts himself to the world: the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. (G.B. Shaw)

User avatar
athenian200
Contributing developer
Contributing developer
Posts: 1612
Joined: 2018-10-28, 19:56
Location: Georgia

Re: HTTP3/QUIC

Post by athenian200 » 2024-11-06, 00:44

My position is that I'd rather we don't implement this, unless it becomes necessary and websites start breaking without it, because I see a lot of potential privacy concerns here.

To me it seems a lot like the whole WebRTC thing, which also has a lot of privacy implications. There's a reason we don't ship that in Pale Moon despite a lot of websites using it.
"The Athenians, however, represent the unity of these opposites; in them, mind or spirit has emerged from the Theban subjectivity without losing itself in the Spartan objectivity of ethical life. With the Athenians, the rights of the State and of the individual found as perfect a union as was possible at all at the level of the Greek spirit." -- Hegel's philosophy of Mind

Walter Dnes
Astronaut
Astronaut
Posts: 701
Joined: 2015-07-30, 20:29
Location: Vaughan, ON, Canada

Re: HTTP3/QUIC

Post by Walter Dnes » 2024-11-06, 06:49

athenian200 wrote:
2024-11-06, 00:44
My position is that I'd rather we don't implement this, unless it becomes necessary and websites start breaking without it, because I see a lot of potential privacy concerns here.
If Google gets devious about privacy, can Pale Moon get devious too? Pale Moon already changes user-agents. Is it possible to re-write the IP address in the CID data? Maybe a tri-state option in "about:config"...

0 ==> "normal behaviour"
1 ==> a user-specified IP address
2 ==> random, but valid, IP addresses

The last one may require a 4th item, i.e. how long between new random IP addresses.
There are 2 kinds of people in this world...
1) Those who can extrapolate from incomplete data

User avatar
moonbat
Knows the dark side
Knows the dark side
Posts: 5606
Joined: 2015-12-09, 15:45

Re: HTTP3/QUIC

Post by moonbat » 2024-11-06, 06:54

Walter Dnes wrote:
2024-11-06, 06:49
2 ==> random, but valid, IP addresses
That would amount to forgery and/or fraud on your part, impersonating some other IP address. Or it may backfire on you if said IP was being used for nefarious purposes. This isn't like a VPN after all that you're directing all your traffic through.
"One hosts to look them up, one DNS to find them and in the darkness BIND them."

Image
KDE Neon on a Slimbook Excalibur (Ryzen 7 8845HS, 64 GB RAM)
AutoPageColor|PermissionsPlus|PMPlayer|Pure URL|RecordRewind|TextFX
Jabber: moonbat@hot-chili.net

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 37776
Joined: 2011-08-28, 17:27
Location: Motala, SE

Re: HTTP3/QUIC

Post by Moonchild » 2024-11-06, 09:29

Walter Dnes wrote:
2024-11-06, 06:49
0 ==> "normal behaviour"
1 ==> a user-specified IP address
2 ==> random, but valid, IP addresses
What a daft idea. Well, if you don't care about your traffic never getting a response, then sure, but spoofing that is net abuse at the very least.
"A dead end street is a place to turn around and go into a new direction" - Anonymous
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

Walter Dnes
Astronaut
Astronaut
Posts: 701
Joined: 2015-07-30, 20:29
Location: Vaughan, ON, Canada

Re: HTTP3/QUIC

Post by Walter Dnes » 2024-11-07, 12:35

Moonchild wrote:
2024-11-06, 09:29
What a daft idea. Well, if you don't care about your traffic never getting a response, then sure,
If HTTP3/QUIC absolutely INSISTS on replying direct to "the real IP address", then a LOT of users would have broken web browsing WITHOUT spoofing.

1) Apparently HTTP3/QUIC can figure out "real IP addresses" behind portals. Adresses behind portals may not be directly reachable from outside the portal. I.e. responses have to go via the portal IP address.

2) This post is coming to you from a desktop PC with a "real IP address" of 192.168.1.252
I hope no web sites try replying to that IP address.
Moonchild wrote:
2024-11-06, 09:29
but spoofing that is net abuse at the very least.
If you're concerned about innocent addresses getting DDOS'd, then restrict spoofing to RFC 1918 address ranges.
There are 2 kinds of people in this world...
1) Those who can extrapolate from incomplete data

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 37776
Joined: 2011-08-28, 17:27
Location: Motala, SE

Re: HTTP3/QUIC

Post by Moonchild » 2024-11-07, 14:24

Please take a networking 101 class.
"A dead end street is a place to turn around and go into a new direction" - Anonymous
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

User avatar
pale guru
Moonbather
Moonbather
Posts: 68
Joined: 2021-11-06, 11:10
Location: Tyskland

Re: HTTP3/QUIC

Post by pale guru » 2024-11-08, 10:40

So far every web server I know of still is HTTP/1.1-capable. Even that standard can use keep-alive to use the same connection for multiple requests.

Netscape Communicator 4.x was one the last one to open network connection, do a request and wait fpr response, then close connection. And that precedure over and over for each and every file.

Google’s “standards” make it only unnecessarily difficult to filter and route HTTP requests within a company’s network. For instance, HTTP was once TCP-only.
… tanning in dimmed LCD light. – Evry 1′s a beginner, baby, that's the truth…

User avatar
Nuck-TH
Project Contributor
Project Contributor
Posts: 313
Joined: 2020-03-02, 16:04

Re: HTTP3/QUIC

Post by Nuck-TH » 2024-11-08, 11:24

pale guru wrote:
2024-11-08, 10:40
Netscape Communicator 4.x was one the last one to open network connection, do a request and wait fpr response, then close connection. And that precedure over and over for each and every file.
It isn't gone anywhere. Pipelining(both from HTTP 1.1 and /2) really didn't took off - it creates additional load on servers without providing much benefit.

User avatar
jobbautista9
Keeps coming back
Keeps coming back
Posts: 957
Joined: 2020-11-03, 06:47
Location: Philippines

Re: HTTP3/QUIC

Post by jobbautista9 » 2024-11-09, 05:46

Nuck-TH wrote:
2024-11-08, 11:24
Pipelining(both from HTTP 1.1 and /2) really didn't took off - it creates additional load on servers without providing much benefit.
Pipelining doesn't "create additional load". It sends the same number of requests as a single non-pipelined connection would do. And it was beneficial for high-latency connections (e.g. mobile) and websites which have a lot of subresources where there are pretty significant RTT savings.

What creates "additional load" would be the opening of multiple parallel connections in HTTP/1 that all browsers do even to this day. But as long as your number of regular visitors is as expected it's not really a big deal imo. If you're a CDN like Cloudflare or a big corporation like Google which handles multiple popular services however, which handles millions if not billions of user-agents every hour...

This is why HTTP/2 was pushed heavily by such corporations, because it got rid of multiple parallel connections (or at least the need for it, but the HTTP/2 authors discourages this pretty hard), as well as pipelining in favor of multiplexing (because pipelining is order-dependent). HTTP/1 is unsustainable for them.
Image

"Destroying things, smartly!" - IJN Samidare, probably

Avatar artwork by ebifurya: https://www.pixiv.net/artworks/85379109

XUL add-ons developer. You can find a list of add-ons I manage at http://rw.rs/~job/software.html.