Implementing QUIC is not trivial, so I suspect it will be years until it gets reasonable adoption in standard frameworks and languages that prefer not to interop with C.
I don't think HTTP/3 is even intended as a general-purpose HTTP replacement. Even HTTP/2 is overly complex, so HTTP/1 will most likely stay as a fallback for the foreseeable future.
Sure it is (though it depends a little what you mean).
I expect HTTP/2 usage to disappear, leaving HTTP/1.1 and HTTP/3 as the main versions in use. For HTTP traffic (as distinct from other upgraded protocols like WebSocket) HTTP/2 is mostly better for users than HTTP/1.1, but TCP head-of-line blocking is its one particularly serious problem. For users, I would characterise HTTP/3 as generally just the best of both worlds, and once you have it there there’s no reason at all for HTTP/2.
HTTP/1.1 will remain popular indefinitely for compatibility with older servers and clients that aren’t being updated to the latest stuff, and for HTTP upgrading mechanisms.
I'm excited about HTTP/3, but I sincerely hope HTTP/1.1 never goes away. There's something important about being able to write a compliant web server in a couple lines of code using nothing but a TCP socket.
Like, the final chapter of the Rust book does this. We implement a really minimal HTTP server.
Turns out that, even though what we do is spec compliant, some versions of Chrome don't properly deal with the responses we give, which has had to lead to errata. Implementing the web means knowing the implementation details of the major implementations, and following them, sadly. It's not actually that simple.
In a way, you're actually supporting my deeper point, which is that the web (and more particularly the internet) is bigger than google, even though they're dominant at the moment. If Chrome doesn't support my compliant minimal web server, that doesn't mean it isn't useful, or even that I should have to change it.
HTTP is the lingua franca of the internet. We need to keep a simple, text-based version of it around, so that the barrier to entry for competing with the big boys remains reasonable. We've already lost that fight with browsers, but HTTP is still in a pretty good place. Even HTTP/3 is reasonable for a small startup to implement. And if you can't manage that, you can implement HTTP/1.1 and sacrifice some performance for simplicity.
> If Chrome doesn't support my compliant minimal web server, that doesn't mean it isn't useful, or even that I should have to change it.
This is probably where we differ; I pretty much think that you do have to do this in this situation. Or at least, like, sure, you don't have to, but you lose a significant amount of audience, which is one of the major points of bothering with the web in the first place.
I mean I certainly take your point. If I want the biggest audience today, I need to support chrome. But if that's my goal I'm probably not writing my own server anyway.
In terms of building things today, I'm more saying that if you need an internet protocol for moving data around, HTTP is a pretty dang good choice. It has some cruft, but if you were to start making a replacement from scratch you would end up with a large subset of HTTP/1.1. That's not true of HTTP/3. You simply don't need the complexity for a large number of useful tasks.
Now, in terms of the future. I think that the internet will long outlive the web (at least as we currently conceive of the web), and I think HTTP as a transport layer will outlive it as well. In that future, I want HTTP/1.1 to still be a thing.
I’m curious what the problems are—because I can’t think of ever having run into compatibility problems in simple or complex HTTP servers that I’ve written.
There are like, three different QUIC implementations in Rust. And one of them is by (and being used by) Cloudflare, so it's going to have pretty significant production use. (The others may be as well but I am less familiar with where they're used)
There are multiple implementations and their interoperability is tested [1], with some implementations already having bindings to higher level languages (aioquic) or into existing servers (nginx).
Anyone know why there's no new URL scheme for HTTP/3? We didn't rely on Alt-Svc headers for switching to HTTPS. We gave it its own scheme. Why aren't we doing that for HTTP/3?
not sure about any details but i would guess its because for HTTPS there are security implications by doing negotiation in the clear whereas this probably doesn't have those.
Users don’t need to care about the difference between HTTP, HTTP2, and HTTP3. It’s relevant only to browser engineers and server operators.
There’s no reason to ask everyone on the planet to change “https:” to “http3:” when we still can’t even reliably complete the “http:” to “https:” transition. We’ve learned that users simply do not care at all about “http:” or “https:”. We shouldn’t have to ask people to update their QR codes for HTTP3 just because we updated the protocol.
Should we have introduced ftpp:// for passive FTP to distinguish it from classic FTP? No: it would only confuse users, cause frustration for pages linking to FTP urls, and both servers and clients are perfectly capable of negotiating this silently without surfacing it to the user.
In general the pushback with HTTP3 is that site operators would rather not have to do the extra work to enable it. But from a user’s perspective, there is no work to enable it. It’s just https:// like always and one day it gets faster. Sites that refuse to do the extra work to turn it on will be visibly slower than their peers once it’s widespread enough.
If you believe that HTTP3 should have had its own URI spec, you would have needed to make that case a few years ago to the committee implementing it; it’s not going to change now. I assume their discussion about that is in the archives, and I expect it boils down to “this is not relevant to users, they should not be expected to care”.
But users don't type or even see the URI scheme any more. It is also an implementation detail.
I just think it's weird that we've left ourselves without any way to send a client directly to an HTTP/3 site. Instead they _must_ establish a TCP connection to the site and be redirected via Alt-Svc headers to HTTP/3.
What's the backwards compatibility story for that? Links just don't work for older browsers? Why spend all the time making H3 work seamlessly with H2 if we're only going to introduce a new scheme that only works in new HTTP clients?
To restate my comment in more precise terms, users do not care which protocol of { HTTP/0, HTTP/1, HTTP/2, HTTP/3 } their browser selects and uses when communicating with the remote server at whatever URL they entered. They expect the URL to work, and they don't care how.
The Unifi issue you cite is due to a series of problems that are related to the http:// to https:// migration, most of which Unifi could have easily discovered and mitigated had they cared to. I'm really disappointed in Unifi here, but the browser is at fault, too.
First: Your browser's fallback process for handling "the user entered an invalid URI" is attempting http:// first, rather than https:// first.
Second: The Unifi is responding over http:// with a completely useless error page, rather than a redirect to https:// at the same port.
Third: The Unifi probably isn't setting a Strict-Transport-Security header on responses to https://:8443, which means that your browser can't learn a better default.
Fourth: If the Unifi's instructions tell you to enter "unifi.home.arpa:8443" rather than "https://unifi.home.arpa:8443", their instructions are clearly wrong. (If you're not following their instructions precisely as written, that would explain your discover of the prior three; I can't say I blame you — I would have left it off too.)
Elsewhere in the thread, it sounds like there's a DNS way to suggest http/3. If adoption is high, clients might end up doing something like happy eyeballs; send tcp syns as well as the udp equivalents, and use whichever comes back first or use them all but prefer the fastest one, etc.
According to Apple (I don't own an iPhone) if you have iOS 14 and go into the Experimental Features settings and turn on support for draft HTTP/3 then it will try to do SVCB (that's the "DNS way to suggest http/3") and if it concludes that HTTP/3 is possible and there's no contraindication it will race an HTTP/3 connection vs HTTP/2
If it notices that HTTP/3 always loses or fails, it will gradually stop trying on the rationale that your network is broken so it's a waste of time.
If your site uses Cloudflare, this Just Works™ since Cloudflare will answer HTTP/3 and emit DNS records saying it speaks HTTP/3 so there's no new work for you. Otherwise, to enable it you'd need to either create SVCB records in your DNS (your DNS server may need to be updated) or use the Alt-Svc: feature and give up on the performance improvement for first visits.
One of my biggest complaints is how https flags text based websites for being dangerous.
What danger could possibly happen if I'm reading about a Physical Therapy clinic?
They don't take credit cards, there's no information for me to enter on the website.
But unless the Physical Therapist knows how to manage the server, they get this scary warning.
Maybe it isn't a big deal to US healthcare because they make lots of money. But I imagine there are others that don't have the technical abilities to upgrade to https. Could your grandma do it for her sewing store?
The problem is you can't trust what you're reading to be from the source. Maybe the site doesn't take credit cards. But after a MITM it might suddenly start taking credit cards. And other things. Whatever the attacker wants! All in the seeming name of the origin.
MITM like that still works for most https websites because of the automatic domain validation by ACME-based certificate authorities. The only caveat is that now an attacker has to get a valid certificate, so first he has to do MITM on the route from the datacenters where CAs run validators to the datacenter where the website is hosted, which for most websites today is likely a long route crossing many countries, after that an attacker gets the exact capabilities as with MITMing http.
That's the thing, they don't seem to bother actually addressing the problem and assume no other interception capability than hacking BGP. But we are talking here about exactly that, i.e. if you can intercept traffic in any other way somewhere close to a website or its nameservers - you can get a valid certificate and use it to MITM its visitors anywhere in the world where you can intercept traffic too. And in case of using big cloud providers for validation to "improve" security, this still likely pushes traffic from all of them through some big IX before reaching a datacenter with a website and at worst only adds a couple more points an attacker has to intercept traffic at to get the certificate.
This is where all that centralization is really bad for security. It basically makes https a protection only against low effort MITM of last mile ISPs.
It doesn't. Pretty much no one monitors CT logs and for those who do there is no way to prove misissuance of domain-validated certificate and revoke it, they don't have private keys.
If you believe you have been successfully attacked this way you should report it, the logs would be part of your evidence. I spent some time looking for this sort of thing, and it does look like it happens sometimes, mostly to military or political targets, but it's rare. That work is owned by a previous employer, but let's say dozens of times across several years.
You are entitled to revocation of any unexpired certificates for names over which you can demonstrate control. For Let's Encrypt for example you can automate this, simply make the API calls to demonstrate control (as you would for issuance) and then present the certificate that is to be revoked (it's in the logs) and ask their API to revoke it.
But if an attacker can intercept domain validation to issue a certificate, there is little reason not to protect his own certificate from revocation by preventing subsequent validations until it is used on a target, if he can't hide this fact in some way of course. A report of that will look like someone is trying to revoke a certificate for a domain they don't control and won't actually solve the problem even if a human can be convinced by other method that you do control the domain.
Maybe DNSSEC could be used here to help if ACME added a way to force DNSSEC-only domain validation.
HTTPS is free (with let's encrypt) and useful for privacy.
For example:
No one is stopping someone from intercepting your request to your clinic and add a form asking for personal details - and then using those details to "restore password" - or simply ask for your CC number. You might not fall for it but are you as confident in all other patients?
It all sounds ageist and misogynystic to me. I work with a few grandmas who are right there on top of the newest technologies going. One is a scientist working on a hell of a cool cloud product. Old ladies aren't the model of stupidity, as this thread might lead someone to believe.
Yes, exactly. Grandma should be able to easily publish. Now grandma doesn't say anything because the unnecessary complication pushed by google (https and now http3 which might be enforced a few years later. These has little to do with security and performance;
mostly the google ad business has any revenue from all these complications)
Grandma also pays her registrar and ICANN for the domain every year too. Free was never the price of having a website, and it's not a reasonable standard of expectation today. As is with literally anything else that needs maintenance, if you can't maintain it yourself, you have to pay someone else to maintain it.
Not to run, just to keep running long-term. If Let’s Encrypt exploded you would have less than 30 days to get it running again. But that’s not such a short time.
Nope. https, hybrid crypto and pub->free CA's are the largest backdoor into internet traffic ever (accidentally) devised. The standardization on https for everything (including alt app protocols (dns,etc...)) is very apparently an info grab.
Sym crypto is the only answer (Schneier,DJB) people have been trumpeting this for years.
If I connect to a server via https and see it's certificate, I am confident that my communication is secure between me and the server hosting that certificate.
To validate the person holding that certificate is who they claim to be, how can I do that? By either getting their certificate out of band (impractical), or trusting an intermediate.
Lets encrypt doesn't make it any easier or harder to get an invalid certificate.
Now if the server wants me to authenticate, https has that built in. I can present my own client certificate, and if it's signed by somewhere the server trusts, it knows who I am. But how would a random server authenticate who I am? I'd personally rather use certificates or ssh keys or similar than usernames and passwords, but that's too complex for the average person.
Clearly I could have lost control over the key to my certificate, or the server could have lost theirs, there's not much you can do about that, no matter what type of authentication system you use.
A real danger of not going with TLS is MITM attacks. Specifically, injection of hostile JS, CSS or whatever that can be used to penetrate your browser and/or local system.
First, getting authentic data from the provider so that you know what they published is what you're reading.
But also links and embedded links/scripts. Since HTTP can be (relatively) trivially MITMd, it not only exposes end users to getting manipulated info, but also, having them running Javascript that's not what the site owner intended.
Your browser might flag a http server as dangerous (mine doesn't - it just has a padlock with a line through), but you're leaking information to your ISP that you are reading about a Physical Therapist.
If your site tries to do https and fails (self signed or invalid certificate) it will rightly flag up that it's a problem.
My grandma would not be able to manage a server on the internet, let alone responsibly manage it. If you can't set up a modern server with https then you shouldn't be running a server on the internet at all.
Assuming your physical therapist has their own website with its own doman, and not just, say, a Facebook page, you're leaking that information to your ISP with https, too. https doesn't hide the domain you're talking to, just the specific URLs within that domain.
SNI doesn't encrypt the desired hostname in the payload of the initial connection. It's still plainly visible to an eavesdropper. They can also observe un-encrypted DNS lookups.
Just because the original site was simple, doesn't mean that the thing an MITM replaces it with needs to be. Sites aren't apps; sites that do little don't "install" into the browser with an intentionally-limited set of permissions, such that an attacker would then be limited in their attack by those permissions. An MITM can replace the site with basically whatever they like.
I can't find the example (it was linked on HN a few years back), but a clear demonstration of this is a case where the MITM can serve a phishing page that initially appears to be the original site you've hijacked (so the user trusts it, and leaves it alone); but later, while the page is not visible (for example, when the user switches away from that tab), the page will switch over to showing a Facebook login screen or something.
Since the website isn't a known "malicious site" (so no alert from the browser), the user probably won't bother to look at the URL bar. They'll just think they left Facebook open in a tab, and it logged them out for inactivity. So they'll "log back in."
https doesn't care about the content, it's the browser that tells the user that his communication is in the clear, and there's no assurance as to who the user is talking to.
> What danger could possibly happen if I'm reading about a Physical Therapy clinic?
Depends what is a "danger" to you. Your insurance learning you're having issues and deciding to increase the amounts you owe them, because they saw that your back is aching, is definitely a problem.
> But unless the Physical Therapist knows how to manage the server, they get this scary warning.
Wrong. In 2020, if the Physical Therapist can have an http website, they can have an https website with a valid certificate.
It's the same for your grandma store. Going from no website to http is a much much bigger step than going from http to https.
Using the same logic, https://facebook.com is also a danger, since we know they routinely sell out our personal data to advertisers and probably anyone who is willing to pay for them. Or an aquitance could be an insurance agent... Not to mention NSA as a source of danger in this sense.
The real danger I see is the disappearance of lots of quality, not-for-profit content that reminds me of the good old Internet, swapping it with new shiny https publishers, of which 90% belong to the same owners. That's the real danger to the society. The long tail is disappearing, while commercial interests, and the manipulation that comes with that sneaks in everywhere.
Grandma’s sewing store would be hosted on a VPS or Squarespace, and will have a checkbox to provision “secure site encryption” for her without any further work required on her part. (They may charge her money for the certificate, if they’re a scummy VPS.)
This ship has sailed, though: “plaintext HTTP” is available only with HTTP/0 and HTTP/1. This article is discussing HTTP/3, which carries forward the requirement of wire encryption that HTTP/2 argued over for a long time and then incorporated into the standard.
(Incidentally, my grandmother was a Smalltalk and 6502 assembly programmer of educational software in the 80s. She let me read her technical books at age 5. Probably best to find another example, such as “non-technical site owners”.)
https:// is a scheme, not a protocol. In retrospect, it probably should have been called "www://" and "wwws://" rather than http:// and https://, because a single scheme can potentially be resolved via several different protocols. Consider that http:// does not necessarily imply unencrypted access, due to the opportunistic encryption specification (though this encryption is not MitM-secure).
Also note that because http:// and https:// are different schemes, there is no requirement that they serve the same website. http://example.com/foo and https://example.com/foo could be completely different resources, or completely different websites. An opportunistically encrypted load of an http:// URL still needs to load the http:// website, not the https:// one. Though opting in to HSTS eliminates this distinction.
For that matter, HTTP/1.1 allows full URLs to be specified in the request line, as an alternative to the traditional "Host" header. This is usually only used when using HTTP proxies:
GET https://example.com/foo HTTP/1.1
...
but what is interesting is since this also includes the scheme, it potentially allows you to do something very peculiar: theoretically you could access an https:// logical resource over an unencrypted HTTP/1.1 connection, e.g. by telnetting to example.com:80 and issuing "GET https://example.com/foo HTTP/1.1". It would of course be insane to support this, but if one disregards the fact that https:// is supposed to invariably imply secure communication, theoretically even https:// resources could be loaded unencrypted, just as http:// resources can be loaded encrypted using opportunistic encryption.
In short: scheme and protocol are different things, and for good reason.
URIs are resource identifiers. They exist to identify a resource, not how to access it. Tying those resource identifiers to a means of resolution would unnecessarily couple it to a resolution mechanism and thereby reduce the universality and permanence of URIs. URIs which are URLs are closer to describing a means of access but fundamentally there's still an interest in providing enough degrees of indirection that the longevity and permanence of an URL is maximised.
Can someone provide the tradeoffs and benefits of QUIC vs WebSockets vs WebRTC? I know websockets are tcp and WebRTC requires some special tunneling logic but aside from that I don't particularly know how quic is better or different aside from using udp.
Right, because all we ever need it is more complexity, no backwards compatibility, and more speed in all terms /s
Come on. Networks are extremely FAST by now, TCP or not. It's the silly amount of JS computation pushed to the client that is slow, both in download speed and on the client.
But we have backwards compatibility right now. That's, like, the whole point of the OSI model. Any device that supports UDP can handle QUIC with no fanfare like it was any other application-layer protocol because it is!
That was the case with HTTP2 as well though. The client can negotiate with the server about supported protocols but if a client only spoke HTTP1.1 and the server only spoke HTTP2 they simply couldn't talk. It's just that basically no servers were HTTP2 only.
The protocol stack is open to contributions on Linux, FreeBSD, OpenBSD and DragonflyBSD; while Microsoft and Apple don't take contributions, their developers do go to the same conferences and InterOps that everybody else goes to.
If there's a general tuning problem in TCP implementations, the cycle time for getting it fixed should be around 2 years from discovery to all regularly updated machines getting the fix. Given global impact, that seems pretty reasonable to me.
The actual history of "open" contributions to the Linux TCP stack is one of vehement opposition. Basic things like SYN retransmission remain hard-coded to constants that were (arguably) appropriate in the 1970s.
From what I understand, QUIC is a lower level protocol near TCP and UDP which uses UDP as it's base for transport. Currently, HTTP/2 can multiplex streams, but if one has an error, all must be stopped while TCP fixes it. In QUIC they use UDP, which doesn't do error checking, so QUIC implements the error checking itself. QUIC will handle the error checking while the UDP streams continue to deliver at the same time.
This is all based on my brief reading of the QUIC Wikipedia article, so take my knowledge with a grain of salt, but I think that my above summary fits.
Error in this context is a missing packet causing a delay and a request for a retransmit blocking the TCP connection at the OS/Kernel while it waits for the missing packet before sending it to the application.
UDP packets have checksums, its what network switches use to check before sending the packet on or dropping the packet.
Other benefit is UDP doesn't have a window size (buffer). Which is part of the design when computers had ram measured in K instead of GB (Hey my buffer is full, stop). The chatty nature of TCP reduces download speeds across larger physical distances. Its why download managers spin up multiple threads to download part of a file to work around it.
The difference is literally using UDP over TCP. The problem QUIC tries to solve is that many of TCP's design decisions were made in a different environment that the one we live today (eg. being able to switch between from 2 internet sources like Wi-Fi and mobile data while retaining connections).
Plus, it integrates TLS in it to reduce protocol overhead.
IIRC even UDP isn't ideal, the reason for choosing it over making a brand new protocol was to avoid network devices like routers dropping packets that they wouldn't recognize.
WebSockets is just an abstraction over a reliable protocol (TCP), therefore, WebSockets could theoretically work over QUIC too.
The internet is a large cluster of workarounds for design decisions made in the 1970s, a truly beautiful time. A time before anyone imagined the need for a system to authenticate who is sending mail or from what server. A time when a "network connection" was a big ass permanent wire into a deeply imperfect network. A time where someone intercepting the communications on that wire was an afterthought. A time where even when things were encrypted, DES was considered an acceptable cipher.
Unfortunately today's internet has needed to be a continuum of newer stuff that still has to work with the older stuff. Such is life.
This is a fairly drastic simplification. There are a bunch of different pieces of QUIC, (not least, sorry I'm not authoritative either)
- SSL and "TCP" handshake are collapsed into a single transaction
- That transaction is worst case 1 network roundtrip, best case (returning user) 0 roundtrips
- Anti-filtering baked in. Quic reveals almost nothing for middleboxes to filter on. There is not yet an accepted solution for encrypting the target server name (SSL SNI) but that's still being worked on AFAIK
- "Modern" congestion control approach, where "modern" means "fuck any TCP connections sharing the link"
QUIC is basically HTTP2 (bidi frames and keep-alive connections) over (TCP over UDP) with encryption builtin. The cool thing about QUIC also, is the ability to 'lower down' to the UDP layer and skip the control and encryption protocol if you need it. (I just dont know if they will extend this feature to the application level).
WebRTC is SRTP with UDP have hole punching et al. if you want so use UDP but with a whole problems of the UDP approach P2P world already taken care of.
WebSockets works over plain TCP.
QUIC is the more advanced of the protocols and it will probably "take over the world" with time, but it has yet to prove itself.
It probably can be a good fit to the cases where the WebRTC is being used for, but i dont now if Chrome will be ambitious enough to let developers mess with the building blocks of QUIC. If not, it will just become a sink to HTTP3 (a no small feat anyway).
Those are pretty modest gains for a layer 4 change. It's going to be much harder to tool/debug this stuff. Is it expected that servers pretty much always support all the HTTP protocols or is the goal to eventually replace the earlier forms?
I guess I'd have to see the metrics on it in production, but my intuition is that a 2% improvement to latency would be even less noticeable on low bandwidth connections where the download times are measured in whole seconds.
If you wanted reduced latency, I think you would stick with HTTP/2 with onload on a Solarflare card.
Until there is dedicated hardware NICs I think you would find HTTP/3 has worse latency. That is until dedicated NIC accelerators come out on the market.
Well good thing it's optional and really only useful for a small subset of very large websites. I still serve my simple static unminified websites, but that doesn't mean minification and other optimizations have no reason to exist.
Now you got my head all going, doing bad math.... As I simply wanted to write "That is not very 'green' of you" as in, compressed, minified, could be more efficient, better for the environment. But then I started thinking, is the saved traffic worth the compress (though once for static content) and decompress at all clients, increased cpu power, worth that trade off...
And I guess I am not the first person to wonder about this, any people wanting to share a bookmark/url, tia (so I don't have to use google... ;) )
I don't think _you_ (nor I in my personal capacity) would, but your provider definitely should, and then you get the benefit.
So if you're hosting via some accelerator like Cloudflare, AWS API Gateway, whatever Google has in this space, or app host like Heroku and friends, they'll happily do the work because they get the aggregate benefit. Your own site will become marginally faster or have happier roaming users, and so on, essentially for free.
When you're developing a generic website, I don't think you should care about this. When you're self-hosting, you can decide if it might be worth it or not. It probably won't be worth the effort unless you're doing something really intricate or special, in which case you'll be really happy that you have the option.
In regards to the gains, these results are without 0-RTT, so I expect the gains with 0-RTT to be substantially larger.
The numbers include total application latency, not just the latency introduced by the network, so the improvement to the network latency is larger. As such, applications that are more sensitive to network latency would show larger improvements.
If I understand the benefits of HTTP/3 correctly, this post also doesn't address one of the major ones: seamless connection handoff during client mobility. Earlier HTTP versions are TCP-based, so if the IP address of a mobile client changes, e.g. because of moving from one cell tower to another or from wifi to/from cell, then the application layer has to notice the lost connection, create a new connection, and move whatever application-level context there is to the new connection. Not all applications do this, and even when they do, it's slow. If my understanding is correct, with HTTP/3 that's no longer necessary — the same HTTP/3 connection can migrate from one IP address to a different one.
Another benefit that isn't measured in this post but has been mentioned elsewhere in the comments here is that the experience on flaky wireless connections (without changing IPs) should be much better. TCP was designed on the premise that packet loss almost never due to physical failure to transmit a packet, and almost always due to routers queues being full (i.e. network congestion). Wireless networks violate this assumption badly: physical-layer issues are the most likely cause of packet loss on a wireless connection. TCP reacts to wifi packet drops by backing off, assuming that some router is overloaded, but the routers are fine — it's just last hop signal that's bad. In those circumstances, the client should just try again instead of throttling the connection to nothing. Since HTTP/3 uses UDP, it can potentially handle dropped packets more appropriately.
On your first point, why is it necessary to switch IPs when switching between cell tower? Doesn't the cell ISP manage the IP anyway, thus making it easy to keep it from one tower to the next?
On your second point, it's configurable how TCP reacts to packet loss. For example, wasn't BBR congestion control made to address exactly that case?
I think at least a few network already make an attempt to maintain IPs, at least when the new cell tower goes to the same backbone, but the problem isn't that your IP address changes - it's that the TCP connection itself is no longer there. Transferring an IP is easier than transferring a TCP connection and ensuring all packets are received and ordered correctly between the two towers.
Every single mobile network will maintain IP addresses when migrating between cells. The IP address is not a property that the base stations care about at all, it's generally tied to the PDP context maintained by the GGSN/PGW, which will generally not be invalidated unless the connection is idle. Mobile operators will only have a handful of core networks even in large countries; having a subscriber move from the area covered by one core network to another would be quite rare.
Switching between cells will cause a latency spike, and a lot of correlated packet loss if the subscriber has a large queue of undelivered data, but that's all. But handling packet loss and ordering are what TCP is supposed to do.
I have no idea of what you mean by "the TCP connection is no longer there". The TCP connection is a distributed system living on the client and the server. It doesn't go away unless one of the endpoints decides so. (Modulo stateful middleboxes, like NATs. But nobody in their right mind would run a TCP state-aware middlebox on a cellular network base station).
IP changes are relevant when switching networks entirely, like going from WiFi to mobile.
One type of roaming that does trigger for smartphones and similar devices is WiFi->4G/5G->WiFi.
You're at home, obviously you don't want expensive mobile network data charges when you've got WiFi. So the connection is over WiFi. But as you walk out the door, currently your application software needs to spot that the WiFi is going away (not too hard), connect over the mobile network (unless your policies say to give up instead to save money) and keep going. QUIC would allow this to be done transparently at the transport layer, at least in some cases. When you reach a coffee shop/ friend's place/ work and there's WiFi again, the opposite transition saves you money and if you go indoors and signal is weaker may also be necessary to deliver a working network.
I remember a Hacker News post that many of the top Firewall vendors suggest disabling UDP over port 443. Apparently it's hard for packet inspection, restricted browsing etc in the enterprise space.
Have there been any leaps in Firewall tech, or will most companies still disable this?
> Have there been any leaps in Firewall tech, or will most companies still disable this?
QUIC is explicitly designed to frustrate this sort of thing, so the enterprise will just have to choose between having and not having it, or switch from MITM to endpoint backdoors.
If you do what the specification told you, in TLS 1.3 or in QUIC, you can build these products and they'll work as intended for web browsing. In TLS 1.3 there is even a whole section of the RFC (under "Invariants") that explains how to do this properly.
What you end up with is two connections. A connection from the browser to your product, and then a connection from your product to the web site. Your product is in the middle and can apply any policies whatsoever that it desires.
There are two things about this that vendors do not like, or which their customers do not like and the vendors would prefer somebody else take the blame for not them.
1. For this to work the browser needs to trust the product. The product will need to mint its own certificates for each site visited, and it can't make genuine ones, so it'll need to be explicitly trusted by the browser. This requires more honesty from your customer (the product's operator) in regard to their users (employees / students / visitors / whatever) where previously a product might try to snoop unobtrusively. That's no longer an option.
2. Actually doing all this heavy lifting costs money. More CPU power, more RAM, even more network bandwidth because you can't just snoop a few frames at the start of a connection you need to proxy decrypt/ re-encrypt every single byte even if you realised very quickly that it was actually fine. This makes the product more expensive, even though it's also worse because their users ask awkward questions now.
I’m not an expert but QUIC doesn’t seem like enough of an improvement over TCP to warrant replacing it, especially given that it’s even more complex.
- 0-RTT handshakes are great but there’s still the problem of slow start.
- QUIC’s congestion control mechanism is pretty much the same as TCP’s and doesn’t perform particularly well over e.g. mobile networks.
- Mandatory TLS means it’s going to be a huge PITA if you ever need to run a quic service locally (say, in a container).
- Having it in user space means there’a a good chance we’ll end up with 100s of implementations, all with their own quirks. It’s bad enough trying to optimise for the three big TCP stacks.
Let's Encrypt can generate certificates for your.domain. your.domain can in turn resolve to localhost. I've been using Let's Encrypt for websites behind a VPN for several years.
Yes, of course, and that might make sense in a production setting. Those certificates expire after 90 days though, do you really want to have to edit your dns records every 90 days? To run something locally?
In that case you’re using either HTTP or TLS verification, which only works if you have a public static ip/port that LE can access. You can’t do that from behind a NAT without port forwarding and you generally don’t want your local docker machines to be accessible to the internet.
Unless your cron script is doing some funky DNS altering, that is.
Oh, that’s cool, I hadn’t heard of lego before! But still, you shouldn’t need to buy a domain to do stuff locally on your own device and it adds quite a bit of complexity.
The only thing we care about is that there's just one authoritative name hierarchy, if somebody in the name hierarchy wants to give you a name without selling it, that would be totally fine.
I would totally be down with say, the US government issuing citizens with a DNS name under their ccTLD somewhere. Done your tax paperwork in reasonable time? Your name is guaranteed by law to keep working for another year. Maybe 1480219643.ny.citizen-names.us is ugly but it'd satisfy this problem for individuals. Maybe they could bolt on a checkbox, $50 extra to the IRS and you get to pick any as-yet unreserved legal name, or they have rules like for license plates.
Put the emphasis on the word "buy" instead, because they were describing a situation where you don't need to buy.
There are also free dynamic dns providers that let you set txt records and get certificates. But of course you can't depend on one of those to last forever.
1. have the domain in question resolve to a server with a public IP
2. have that server generate the certs with any ACME client with HTTP challenge
3. have that server ship the certs to the actual server hosting the service via intranet
4. in the intranet, have the domain resolve to the actual server via /etc/hosts override
All of that is not that hard to set up even at scale with proper config management tools. Having said that, I don't actually use it for that many services myself. The most significant one is LDAPS.
I have a wildcard certificate for *.local.example.com (and local.example.com), and a local DNS server which resolves all the subdomains of local.example.com.
All local servers share the same certificate and it gets refreshed automatically every 2 months. local.example.com has a public NS entry to a custom nameserver which only exists so that letsencrypt can perform the DNS validation for that domain (and its subdomains).
This way I can use server-1.local.example.com, server-2.local.example.com, workstation-1.local.example.com internally with TLS.
And we should be thankful that workflow is supported by LE. I just don’t think it’s a reasonable expectation that people will buy a domain and host a public nameserver so they can run QUIC on localhost.
ACME supports multiple challenge types. The most popular is the HTTP-01 challenge, but there is also the DNS-01 challenge (via TXT record) which allows validation without exposing your webserver to the internet.
You can point a CNAME somewhere, where you have e.g. https://github.com/joohoi/acme-dns
which is meant just for this.
There are even providers (listed later in the README linked), that you can use this with, without managing another software.
Yes, but in reality you don’t want your page to load until all above the fold assets are loaded anyway. We went through this a couple of years ago with increasingly complicated techniques to avoid the dreaded “flash of unstyled content”.
Head-of-line blocking is only a problem if you’re multiplexing connections. Just open one TCP socket per request and you’ll never have head of line blocking. There are issues with opening multiple TCP sockets of course (mainly Slow Start) but these aren’t insurmountable.
That’s not a fundamental limitation of TCP though. You can theoretically open 4294967296 sockets between two machines (with one IP address per machine) and a beefy machine can handle >1M concurrent connections.
They’ve already proposed adding HTTPS and SVCB DNS records for performance, it would be easy enough to implement a ICANTAKEIT record that lets the browser know it’s OK to open as many sockets as it needs.
A single (TCP) connection has a single SYN and SYN-ACK packet of startup overhead. N connections have N SYN packets and N SYN-ACKs. That might still not be very much overhead, but it is more.
The performance overhead will not be zero. You're spending more computational power and memory opening up and maintaining a larger number of connections, and you're sending more packets and bits over the network in total because each additional connection has non-zero overhead.
I think QUIC is motivated by Google's expansion into developing markets (China, India, etc). These areas are primarily mobile markets that would like to consume the same content we do. What might sound like small overhead (SYN->SYN-ACK) actually takes half a second. If your performance is measured in this way than N connections times half a second is a long time. And, on mobile networks, sometimes your TCP connection will drop even if there's still data being sent back and forth (some times you can see latency spikes up to 3sec on really bad networks which causes most software to timeout since it thinks no data came in because of head-of-line blocking).
It's a truely miserable experience that QUIC or HTTP/3 can easily solve. Imagine how slow an `apt update && apt upgrade` is and how much of that overhead can be dropped by connecting to 1 mirror a single time and bulk requesting 10 to 100 file transfers. This allows you to maximize your network throughput. Think instead of how slow this would be if you opened 10 to 100 connections each of which might take 500ms per startup. In the worst case that's a 500ms penalty versus a 5 second penalty.
Actually, that's not a problem with one reused connection versus N simultaneous connections (as coddle-hark said, the connections are made in parallel). It's a problem with how many round trips it takes to set up each connection.
When you open and depend on N connections, your total time is now linked to the worst performing of those N connections. As N increases, so does the latency, because it’s a long tail.
There are many things that use HTTP that are not web browsers. Things like S3, for example, can make use of no head of line blocking by allowing multiple file transfers, multiple pagination requests, etc. Even APIs can benefit from this by using bidirectional streaming.
Games can now also be built over a REST-like API using separate channels for different priority messages: movement, world state, chat, etc. Since you don't need to worry about blocking you get way better performance. Almost every game engine networking component essentially implements TCP-over-UDP just to get application level control over these functions.
You can do all of that, except for the application level control, by just opening multiple TCP sockets. QUIC is just basically TCP over UDP in that it shares the same semantics (guaranteed, in order delivery of a bidirectional data stream with congestion control). Sure, game engines don’t always want all those attributes - guaranteed delivery, for example - and will implement their own thing over UDP that makes more sense for them. QUIC is just as bad as TCP for those use cases though!
The benefit is that you can open up as many channels within a connection as you want so you obtain the same abilities as you'd normally implement in a game engine.
Sure, I can create a self-signed certificate and copy it to my docker container and update the app’s config to use it and add it to the system’s certificate store and then add it to every browser’s certificate store every time I need to run something over QUIC locally. And sure, maybe one day there will be a tool that can do a that automatically.
A lot of browsers already expect tls to enable specific features. I've had things break between dev and prod because of a lack of tls on the backend as well.
It's also one of those things that once you sort it out it's no longer a problem. Like "why do I need to setup all this complex stuff to manage a dependancy? Just give me your source code and let me `gcc -o binary a.c b.c ....`"
In reality once you solve a problem with an ergonomic solution and the solution improves your alignment with production and comes at no real cost it's a win/win/win.
Browsers have for some time behaveD quite differently when using HTTPS vs HTTP, particularly if you’re not navigating to precisely http://localhost (e.g. if your dev environment needs multiple domains). In particular a lot of newer browser features will refuse to work, and you won’t be able to see any HTTP/2 specific issues (e.g. header case) either.
And its not, its the IETF since whats being discussed here is the IETF version not Google's.
Is was their choice to adopt QUIC for HTTP/3 and standardized it.
If you don't like the IETF then its another matter. Just point you pitchfork the right way.
"The Internet Engineering Task Force is an open standards organization, which develops and promotes voluntary (my emphasis) Internet standards, in particular the standards that comprise the Internet protocol suite." No one is twisting the arms of Google or browser/tooling implementers. Did I miss a flag where this can be disabled on the browser? If so, that's my fault! But if not, that's my point.
To be fair the real problem is not mandatory TLS, it’s mandatory WebPKI certs: self-signed certs are not a problem in a local docker container, and is not worse than unencrypted.
Supposedly not (vs TCP/TLS), at least not in the Google implementation (haven't read anything about the IETF version).
And with 0-RTT, when it comes out, you gain some performance back anyway by not having to re-handshake on drops.
Some, but maybe less than you think if you're using OpenSSL and a computer less than ten years old (AES-NI and maybe PCLMULQDQ for GCM). Often something else (NIC, network) will be the bottleneck.
You still need to add those certs to a bunch of different places (browsers use their own certificate stores).
More importantly, I don’t think it’s a good idea to teach people to add self signed certs to their certificate stores willy-nilly. Seems like a good way to get pwned.
Well, there are other problems (even requiring encryption at all means some low-power clients can't use it because they lack the processing power), but X.509/WebPKI is the main one, followed by ciphersuite proliferation requiring dozens of times as much audited cryptographic code.
That’s not quite right. It greatly reduces the handshake time for new connections, but
it adds more network overhead (more bytes sent) than TCP. TCP doesn’t “block” any more than QUIC.
It also allows for multiple concurrent encrypted streams while just doing one handshake.
HTTP/2 also allowed this, but suffered from head-of-line blocking between those multiplexed connections. Quic streams are independent. One Stream can still make progress if datagrams which contained data for another stream got lost.
Multiple concurrent encrypted streams with a single handshake isn’t much of a win though. N concurrent TLS connections won’t be any slower than a single TLS connection since the requests can be done in parallel.
How can that remotely be true? It's easy to forget in a world where the internet has defacto concentrated into the hands of a select few CDNs, but behind each of those CDNs are origin servers, serving the content to those CDNs. Servers can be housed in different data centres, different countries, etc. Specific servers can have hardware issues or be congested, while others remain unaffected, etc.
Even if you can achieve comparable performance on N concurrent TLS connections (which I actually think you can), you have a high additional cost of establishing those N connections.
For a lot of systems the TLS handshake is the most expensive part of an operation. Reducing the amount of TLS handshakes by N can literally reduce cost by up to N in those systems.
As another user stated, the biggest advantage of QUIC is how much more sense it makes for wireless communications and mobile devices. Mobile networks break TCP connections all the time, it just violates too many useful assumptions of TCP.
HTTP/3's WebTransport (i.e. gRPC + sessions) defines a Session far more logically than a TCP Connection + your ad-hoc in-application Session does.
The predecessors of WebTransport already appear every everywhere in low-latency and realtime networked applications, like games, chat and video, on mobile devices. Typically that is achieved using UDP + an ad-hoc session management and authentication protocol. Or worse, undoing TCP connections and managing sessions on top of TCP connection breaks (as most dual web + native applications do).
Why reinvent that clumsy stuff over and over again instead of having it standardized? TCP is already dead on mobile, for many of the most popular applications people actually use.
My day job is providing internet connectivity to trains/busses/boats in remote areas over cellular modems. I couldn’t agree more that TCP over mobile networks is a non-starter, I just wish they’d done more than implement TCP over UDP. In terms of mobile performance, QUIC isn’t much better than TCP over a Wireguard VPN.
> QUIC isn’t much better than TCP over a Wireguard VPN.
Why? One of the main intends of QUIC is imho to be better in this scenarios. E.g. by handling retransmission and loss detection in a different fashion than TCP.
It handles congestion control slightly differently since it can estimate the Round Trip Time more accurately, but it’s essentially the same ACK based mechanism that TCP uses. The current draft [0] from the QUIC working group basically describes TCP NewReno (the authors say so themselves).
Yes, congestion control is based on New Reno. But I think there are some higher level pieces where Quic is more flexible, and which can lead to higher performance on lossy links. E.g. has the ability to repackage data that was assumed lost in previous datagrams, and combine it with new data - leading to less total transmitted data in that cases. It doesn't have to retransmit every packet in exactly the same fashion. Some Quic implementation make use of this ability - while others don't.
And it might also have a bit more flexibility when to retransmit (but I'm not an expert).
It’s not hard to make a transparent proxy talk over udp to a POP and avoid TCP issues altogether. I did this for a satellite based internet service I ran back in 09, mostly for fun and profit. Never thought it could be something worth selling because it was so simple.
Nope, that’s the easy part! You don’t avoid TCP issues altogether though, all the usual behaviours of TCP are still there with respect to packet loss, latency, jitter etc.
> - Having it in user space means there’a a good chance we’ll end up with 100s of implementations, all with their own quirks. It’s bad enough trying to optimise for the three big TCP stacks.
Big QUIC implementors have all used the interop runner, intended to prevent exactly that:
After my opinion around 4% performance improvement doesn't justify the introduction of this more complicated protocol (maybe google knows how this benefit their ad business, like forcing everyody to https so they can increase their control over the internet, since their scripts are already included by the majority of the websites, reporting them all the important metrics, regardless of HTTPS)
It adds to a number of other great reasons to break up Google and some other big tech companies. The fact that Google is so dominant (controlling both the discovery, browser and casual video content aspects) that they can unilaterally decide on fundamental internetworking protocols is obviviously a very important issue.
"U.S. House's antitrust report hints at break-up of big tech firms: lawmaker (reuters.com)"
This argument is false. Google contributed the protocol to IETF. Where the competitors introduced a lot of incompatible changes, which Google then implemented. The blog post is literally Google's announcement that they are moving to that public standard.
What other company could have done this? Was the fact that Google controls so much of the entire usage chain (chrome, google.com, youtube.com) irrelevant?
It might have worked if the majority of web servers had been Microsoft’s, but my recollection is they never got close to having the majority of the web server market.
The crown went from NCSA to Apache and then only recently to Nginx.
In this specific case only three other companies make web browsers with significant market share (Mozilla, Apple, Microsoft), so I guess you could argue only those three companies could have done this particular thing and you're correct that only Google owns Youtube.
But more generally companies have written up IETF paperwork for other protocols. Lots of Microsoft protocols have RFCs for example. But one thing that's less common is actually engaging with full-blown IETF working group standards development like Google did here, as opposed to just saying "Look here's the protocol we built, you can use that, or not". The IETF is totally happy to accept what I guess you could call a "donation" of that sort, and it's much less effort. Maybe you take some internal documents, you reassemble them into the rough shape of an RFC, you publish that draft, you get a bunch of feedback about that document, focused on clarifying the explanation, making sure you cover everything required, and so on rather than altering the protocol (which you've maybe already actually shipped in a product) and after maybe 6-12 months you've got a polished RFC ready to publish.
If you use a work VPN for example, or a corporate WiFi network that's not just a few home WiFi routers with a more professional SSID and password, you probably end up using protocols Microsoft "donated" in this way, like PEAPv0/EAP-MSCHAPv2 - these protocols are awful but there was no multi-step process where other vendors improve on it and then they eventually reach consensus and publish. Microsoft shipped products that do MSCHAPv1, then wrote it up so that other products could interoperate with Windows, and when they made MSCHAPv2 they followed the same path.
Nonwithstanding your argument, their size also makes them suspect by default. They would be able to push control much farther if it had separated interests.
Look at LetsEncrypt: A Google initiative. Yet 25% of the world’s websites use it.
> Look at LetsEncrypt: A Google initiative. Yet 25% of the world’s websites use it.
No. Let's Encrypt is a service of the Internet Security Research Group, a California Public Benefit Corporation, it isn't an "initiative" of Google except in the same sense that the Red Cross is an initiative of Google, or Sweden is a US state, to make it seem "true" you need to squint so hard you can't see anything properly at all.
It prevents ISPs from snooping. But personally I don't really buy the shadowy conspiracy theories. I think HTTPS makes the internet better (people want to be able to trust their connections are secret), and anything that makes the internet better is good for Google.
There is a trade off. Encryption everywhere protects the clients from the network. That's great for most usage but it's a negative if it's your local network and you want to have more control over clients using it.
Right now it's possible to selectively block client activity on your network (your smart TV snooping or showing ads) but that's going to get much harder in the future. You'll have to chose all or none when it comes to clients.
It takes away control from the user that no longer has full and relatively-easy control over the data flowing through their hardware. With Google controlling the browser, the web renderer, the HTTP protocols, the add-ons available in the browser and preventing data manipulation due to HTTPS, they have an encryption-protected pipe straight from their servers to the user's screen.
And it's all done under the guise and blessing of "privacy". It's really a bleak future for the web.
Sorry, I went on a bit of tangent. But to answer your question: HTTPS makes it incredibly difficult to introspect and alter content that is flowing through the web and your browser. Allowing a user (and his ISP if done correctly) to easily at the network level alter the content, one can do all sorts of magic that we haven't even begun to explore because it's effectively impossible.
The big usage of this would be ad-blocking and removal. At this point the two biggest ad-blocking mechanisms we easily have available are: DNS-blocking of ad servers, and add-ons/plugins that are allowing introspection of the data on the web pages visited. Both of those avenues are being attacked. Add-on APIs and capabilities are being neutered in little bits and pieces both on Firefox + Chrome. And DNS is being attacked with things such as DNS over HTTPS (again under the guise of privacy).
Not to mention that even SSL certificates that allow MITM for the user are being attacked by initiatives such as embedding SSL certificates into binaries, and certificate pinning (which luckily seems to have been abandoned).
We need FOSS/Stallman-level activism and wars against this stuff that is eating away at the rights we have over our own hardware. Whatever you call this issue, it should be right up there with "right to repair", "own our own data", "right to be forgotten", etc.
It used to be DRM, but privacy and security are the most prominent excuse under which freedoms are being attacked today, because "why would you argue against privacy and security?" --- just like drugs, terrorism, and child porn.
I have a MITM proxy on my network that strips ads, rewrites pages with custom stylesheets, and all that across every single device connected to it, and it's hard but not impossible to set everything up, and they are only trying to make that harder.
I agree with you completely, except for "right to be forgotten" --- which tends to become interpreted more as a "right to rewrite history".
"Those who give up freedom for security deserve neither."
I have trouble believing Google feels threatened by users choosing to MITM their own connections with self-signed certificates. There’s no way you’re going to see a noticeable percentage of consumers do that, so how would it affect their bottom line?
If you’re comparing it to HTTP/1.1, the performance improvements are generally a lot better than that. The latency improvements are commonly something around that, but the total page loading performance will tend to be better because you get proper multiplexing.
But then you may say, why do we need this instead of HTTP/2, which had proper multiplexing? Well, it improves things a bit further, commonly improving throughput and latency by 1–10% if I’m recalling the right figures; but more importantly, it fixes the TCP head-of-line blocking issue that made HTTP/2 often actually perform a lot worse than HTTP/1.1 on low-quality connections.
I know of sites that have held off on HTTP/2 or rolled it back because it made things measurably worse for some users, and of sites that split things across domains with some HTTP/1.1 and some HTTP/2, deliberately, purely because of the TCP HOLB issue. HTTP/3 fixes that, so that it should no longer be a question of whether you make things faster for some users at the cost of others—you can instead make it faster for everyone.
Every millisecond counts when loading JS backed features on websites too.
I'm curious with the multiplexing improvements if we'll see greater performance gains in the long-term as we changed how we package and bundle JS.
I've seen a significant improvement in general page performance using Webpack's chunking, where it automatically breaks up each of your components into smaller .js file and only loads them if the page uses them (basically on-demand async importing of JS files that were preprocessed with webpack).
It went from loading one giant blob of JS on every page into one primary JS file (about 25% smaller) + a bunch of tiny 1-10kb .js files that load async. A typical heavily interactive page would load 5-10 of these async files.
There's probably opportunities to go even further in breaking up the primary file (which handles the logic of which JS components to load + includes the Vue/whatever framework and other JS dependencies).
I understand the utility of "loading once and caching" stuff but for serious JS-heavy frontends the bundled JS files becoming extremely bulky (sometimes in multiple megabytes due to legacy dependencies) and ideally you'd minimize that always-cached part as much as possible.
It is optional, backwards compatible protocol. You can still use HTTP/1.1 as a server or client. Literally the only reason 1.0 isn’t still usable is IP exhaustion/vhosts, and that did not change with HTTP/2 or 3. Modern TLS is also a complicated protocol. (If you don’t believe me, I believe google.com will still load in IE 5.5+ with plain old HTTP, albeit in a legacy mode.)
Also very confused at how we’re spinning HTTPS as a bad thing now? Cloudflare and Lets Encrypt did significantly more for HTTPS adoption than Google anyways... and it is a bit preposterous that it is somehow being spun as a negative. It’s about security as much as it is about privacy...
(I am a Google employee but speaking entirely in a personal capacity. Additionally, I do not work on Chrome or QUIC.)
It's no longer possible to fetch some things over HTTP at all, because the server responds, not with the content requested, but with a demand to use a different, more complicated protocol.
The justification for having most internet services adopt this standardized, patent-unencumbered protocol with multiple free and open source implementations is well documented; it’s become a best practice for many reasons. Your reasoning for not using one of the aforementioned implementations isn’t documented and is hard to guess.
On the other hand, on a typical secured WiFi connection over TCP over an Ethernet connection, like 10 times more complicated stuff is going on in protocols and the software stack. It’s not as if we went from bit banging HTTP directly down an Ethernet cable to a hopelessly complex stack of software; we just added another element of complexity at the application layer in exchange for real security and privacy benefits. Example.com doesn’t need it but it has become a best practice for good reason so it is used on most of the net even when not strictly necessary.
Enforcing HTTPS is a best practice because an absurdly overwhelming majority of user agents, like 4 or 5 nines of them, support HTTPS and the redirect ensures they use HTTPS and makes downgrade attacks a little more involved.
From an engineering perspective https makes all the sense in the world, but the *pain-point I think they're getting at is that http/s is basically user-facing as well, and it is now both more difficult to set up and maintain, and less semantic, for hundreds of millions of people.
Over the past decade I've helped maybe 100 small businesses set up internet presence, and I promise you none of them understand https or set it up correctly at first, despite often paying for it from hosting providers like Godaddy.
This isn't the fault of the engineers behind implementing it; it was necessary of course. But if the web were a perfect authoritarian regime we could have just saved us all the headache and dropped http altogether, thus avoiding this bureaucratic protocol redirecting mess.
I would be very interested to read about why that was not done actually. (I'm sure there were reasons)
That's a very strange example to use, when example.com does support HTTP:
$ telnet example.com 80
Trying 2606:2800:220:1:248:1893:25c8:1946...
Connected to example.com.
Escape character is '^]'.
GET /index.html HTTP/1.1
Host: example.com
HTTP/1.1 200 OK
...
Content-Length: 1256
...
Please explain how it is more complicated. Also, QUIC is not just about the performance improvements offered today.
Existing protocols like TCP and TLS are not really simpler than QUIC, you just don't think about them because we have implementations of them already. However, _changing_ TCP and TLS is extremely difficult to impossible because middleboxes snoop on traffic and mess it up in various ways. As an example, multipath TCP has been engineered to look like regular TCP and automatically downgrade to regular TCP if middleboxes can't handle it. Making this work is hard and 100% a waste of time just to work around the fact that people deploy these boxes. I believe TLS 1.3 also had deployment challenges due to middleboxes.
QUIC encrypts ~everything so that middleboxes can't make broken assumptions and manipulate traffic. Adopting it is a one time pain that enable later improvements to be possible.
> I believe TLS 1.3 also had deployment challenges due to middleboxes.
There was about one year delay between the point where the protocol was initially "done" and experiments showed it could not be deployed partly because of middleboxes although also due to server intolerance (web servers that go "What? TLS 1.3? No, rather than negotiating TLS 1.2 I'll just ignore you and hope you go away you weirdo") - until the point where the revised TLS 1.3 wire spelling was finished and tested (about six months before it was published as RFC 8446)
The core idea in TLS 1.3 as shipped is that the initial setup phase looks outwardly very much like TLS 1.2 resumption. Interpreted as if it was TLS 1.2 the TLS 1.3 client claims to be trying to resume a previous connection, a TLS 1.3 server claims to accept that resumption, but really they actually just agreed a brand new connection. A TLS 1.2 server would see the resumption attempt, but it has no memory of any such prior connection (there wasn't one, the "connection ID" is just random bytes) so it offers a new one using TLS 1.2 and everything goes swimmingly.
This way of doing things allows TLS 1.3 to be as fast on first connection as TLS 1.2 was on resumption without causing problems with incompatible middleboxes or servers. It does make the "spelling" on the wire pretty weird looking though if you are used to looking at TLS 1.2.
The other essential goal was to never back off. A TLS 1.3 client will never go "Huh, TLS 1.3 didn't work, let's try again with TLS 1.2 instead". The design means if the remote server can speak TLS 1.2 (or 1.0 or 1.1) it will respond as such to your TLS 1.3 connection. This means adversaries can't try to "downgrade" you to a bad older version.
I can’t believe there are still people who are sour about the HTTPS push. Just people complaining that it makes their job harder when it clearly is a huge win for the end user. Do you know how many airport/business hotspots inject junk in your non-HTTPS pages? It’s totally worth spending 5 minute setting it up.
HTTP/2 and HTTP/3 don't require HTTPS because "it benefits Google" or whatever, but rather because it's the only way those protocols could be usable to begin with.
It is possible to use HTTP/2 without HTTPS, but the problem is that there were a lot of systems that modified unencrypted HTTP traffic and got confused by HTTP/2 protocol - it looked nothing like HTTP/1. The easiest workaround for this issue was to require HTTPS, so that's what was done.
Also when HTTPS is being used the server can say during TLS handshake that it supports HTTP/2 avoiding the cost in having to figure out whether the server supports HTTP/2 - this cannot be done with HTTP as there is no handshake. If a web browser were to assume the server supports HTTP/2 it would make initial HTTP/1 requests slower as it would have to try HTTP/2 first (and then you would have people complaining about Google making HTTP/1 slower to make HTTP/2 look more attractive). If a web browser would say that it supports HTTP/2 it would make HTTP/2 requests slower as it would have to try HTTP/1 first (which would slow down HTTP/2 when it was supposed to be fast).
With both a DNS-over-HTTP client and potentially a DNS-over-QUIC in the browser and serving advertisements over QUIC... there is a good chance that the world will see unblockable advertisements in our near future.
I don't think this is a good idea... about a decade ago... as a research project I ran honeypot farm of 13 machines to learn more about malware. The honeypot machines were autonomously surfing the net, parsing the DOM and choosing random links. I ran them in a sandbox and was getting weekly malware hits.
Much to my surprise... most of the malware was coming over advertisement networks on shady websites.
You can still define a custom HTTPS endpoint[0], you just need to trust (within Windows) the self-signed certificate your pihole/etc device has, in order to use it on Chrome; your endpoint setting isn't messed with when you select 'enhanced protection' or anything[1].
The only downside to this is that rogue IoT devices or hacked IoT devices can easily get around DNS filtering, but that was already possible before DoH by using or running some benign free public http api for dns lookups.
Why? The user agent will still be able to choose what to display, and protocol improvements don't prevent you choosing an agent that has your interests at heart.
Using secure transport means nobody else gets to decide, and I certainly have a long list of people I don't want deciding whether I see things, so that helps.
Chrome is also crippling adblockers, plenty of websites are already chrome only, and I'm guessing if you can ensure ad delivery, a whole lot more are going to jump on that train.
I'm not sure if this is true -- there was a dark time during the period where Google started to advertise Chrome on literally all google websites, but all of the internal refactors and engine improvements over the past 2-3 years have made an enormous impact on my user experience. And as far as I'm concerned, Firefox isn't dead as long as there isn't a viable replacement that:
- doesn't update via a sketchy background process (Google Updater, or whatever they've renamed it to this month to avoid scrutiny)
- allows me to customize the UI to fit my needs (tree style tabs are an absolute must for me)
- allows me to use a full ad blocker like uBlock Origin instead of arbitrarily limiting the ad blocker API to advance the interests of advertisers
Of course, Firefox's management is an enormous problem, from the way they've prioritized features to the recent layoffs to the enormously stupid decisions (letting a certificate expire that disabled almost all add-ons, the Mr. Robot tie-in "experiment", pushing pocket, default disabling userChrome.css, forcing auto-updates) they've made in the past 5 years. But the core of Firefox is good.
I would love a startup that builds an entire business off of a fork of Firefox that's completely based on privacy, perhaps with some non-invasive monetization like:
- a $5-20 one-time fee to use (with weak enforcement, a la Sublime Text's "annoy you every 5 saves" model)
- a paid vs. free split where the free version of the browser adblocks ads but replaces them with in-network, verified safe ads
- Linux kernel donation-style only model, with no parent corporation
Because of all of the Firefox devs floating around who just got laid off, you could even snatch up some guaranteed capable talent already familiar with the code base. And the best part? They're already vetted to not be part of the management-industrial complex that's taken over Firefox these days.
It's enough of a skew that when rendering errors crop up, product managers have to decide how many eng-hours it's worth to chase down the small implementation difference between Chromium and Gecko to snag 1 in 10 potential lost visitors, instead of throwing a UA-sniffing "best viewed in Chrome" banner on the page and calling it a day.
Being a rarely-used browser is a negative feedback loop for compatibility, regardless of what standards say (because standards are often too loose to guarantee full interoperability in all corner cases; they rarely give performance constraints and often don't consider all possible combinations of feature use).
Agree on all points. It's not quite as deadly as back in the old browser wars, because HTML5 is much better specified than its predecessors, but it's definitely a major problem.
> I would love a startup that builds an entire business off of a fork of Firefox that's completely based on privacy, perhaps with some non-invasive monetization like:
You probably meant "Tor Browser". Changes from there were backported, and last time I checked plan was to have it entirely backported within Mozilla Firefox.
Pretty much my vision. The largest reason I don't use Brave is because it's built on top of Chromium, and simply jumping on the Chromium train gives Google the ability to dictate the future of the internet. There needs to be a browser engine alternative, or alternatively, maybe we need to spin Chromium out of the Googleplex and let a free and open source group handle future development independent of the Ad overlords.
I understand your sentiment, but let's be clear. Chrome was itself a "spin out" from another engine. That engine still exists. But Google's investment into Chrome has been such that you yourself ignore the original. A new spinout from Chrome would face the same problems.
I'm trying Servo builds. Oof. Most of the web, even my own very thin no BS pages are not loading perfect. But! Servo is improving. Maybe my Rust skills can improve so I could even contribute.
How long before they rip out open source parts and make chrome closed source or a much more limited licensing and start sticking all their proprietary network protocols in it so that you can't fork Chrome any longer. I personally believe that's the endgame for google.
I don't think there a single instance of an application that Google did what you described. Why do you think it will start now? This doesn't make any sense.
Very interesting project. ungoogled-chromium seems to addressing many of the concerns that inhibit control and transparency. E.g Chromium even without a Google account cannot address those concerns.
As an early Linux user, I still remember running a Windows VM with IE installed, for years, just to do online banking. Heck, at my current corporate job all the Mac users (mostly the web designers) are given VMs to run IE11 to fill out their timecards, and use product management software. This is absurd, but real.
I'm no stranger to having to use VMs to do basic stuff online, but not everyone else is. And, to be honest, no one should have to set up a VM to use a browser they cannot trust, just to protect themselves from stupid drive-by malware.
> It’s just a matter of setting your user agent to say you’re running Chrome.
This is the real clincher - websites discriminating against Firefox often don't know why. I assume it's because they don't want to be liable for using their software on a browser they haven't tested on. Or it's just the good ol' Google search on Firefox mobile thing, i.e. "we'll gimp it for no particular reason!"
It may be now, but how long before everyone moves over to GoogleChromeNet rather than the internet and Firefox can't even read the webpage let alone render it.
I would pay for an ISP that can read my web traffic and alter it to remove ads, optimize images, filter out unwanted content, and a gazillion other things.
It will if your device speaks QUIC; you can configure your browser to talk to that device.
But I do think it makes much more sense to make the browser just do the job directly, rather than delegating that to a separate device.
Firefox continues to block ads just fine, and it'll keep doing so in a QUIC world, while protecting me even more from malicious local DNS servers. The average person is much more likely to encounter a hostile DNS server than a "helpful" one.
Then your problem is that you have a locked down device that isn't truly yours. App makers always had the ability to use a proprietary encrypted protocol to serve ads. DNS-over-HTTPS doesn't give them that ability. But it does provide a standard that people who do really own their own devices can use to preserve user choice. No one should protest that.
You mean like the customer loyalty card at your supermarket? That's all about making your life better, right?
Google only ever shows you ads you want, never "unwanted content". Are you suggesting Google could do even better if they just knew a little more about you?
I'm not sure what exactly you think I'm saying. My point was that this is a feature I would pay someone to provide me. Like adding: "Ad-Removal-Package - 5USD$" as an optional add-on.
I'm not saying I'll be giving them unfettered access to my browsing habits so that they can give me some perceived monetary benefit in return. But even if that were the case, so long as they didn't do anything fraudulent or violate my privacy by giving my personal data out, then I'm 100% fine with it. This is no different than Google having algorithmic access to all my personal emails. Once we figure out the two scenarios are the same, we'll quickly realize this whole "protect me from my ISP", "privacy" movement is just a front for taking away people's right to control their own hardware.
don't prevent you choosing an agent that has your interests at heart
I choose Dillo or Netsurf. Now how can I still use sites it can't even render because the developers have drunk the Google-aid and used some trendy framework that requires the latest version of Chrome and JS just to display some static text and images?
Fuck Google and its creeping control over the Internet.
Once these practices become sufficiently spread, the majority of developers and content producers will never understand that an alternative is possible.
Or maybe he will need it: those same developers can perfectly be contractors for a government agency whose site the user has to access.
Trends slowly creep everywhere, independently on technical merit.
When my brother got married his then fiance sent everyone in the wedding party this site with a form on it:
It's mostly radio buttons (with a loading screen and a pile of js/css to make it pretty of course.) You fill it out, click submit and a matching suit gets shipped to your house. I couldn't get some of the controls to work and sent the support people an email. It turns out the form they built uses some special chrome only API and doesn't work in Firefox.
Ditto when I submitted my rental application for my current apartment (how can you screw up a single page with a file form that badly?)
> It turns out the form they built uses some special chrome only API and doesn't work in Firefox.
history repeats itself (or more exactly we humans repeatedly step upon the same pile of stuff) Back then it was IE only APIs. Those APIs of course were for better and richer functionality and user experience. And we all know how it ended.
> The user agent will still be able to choose what to display,
Will it? Even on Mozilla Firefox (which fewer and fewer sites are tested against) you're pretty limited in controlling this. I have zero faith that google will keep that working in chrome
Can you clarify how you are limited? I can block anything I want using uBlock Origin today in Firefox.
Admittedly sites could switch to rendering everything in JavaScript using canvas or WebGL. But so far no one is resorting to this, because you have to effectively reimplement big chunks of the browser. Maybe one day there will be a JS framework that does this, but then it will be easy for adblockers to target that specific framework.
> The user agent will still be able to choose what to display
Isn't one of the biggest advantages of ad blocking that it can cut your bandwidth use? I mean, if you aren't going to show the ads, why download them in the first place?
Agreed to some extent, though not really sure the protocol matters here... As an alternative, limiting IFrame to 1-3 layers would do a LOT in terms of reducing the overhead/bloat/risk... you get a full ad network payload, that injects an iframe because of a buy miss, then another, another, etc and so on.
In the end, limiting IFrame depth would probably do more than many things for stopping some of the bad actors.
I use uBlock Origin and EFF Privacy Badger for most surfing, which does a decent enough job. I don't think that the enhancements to the protocol really do that much... though I also don't know that some of the tradeoffs are worth losing a human-readable protocol.
I think it's simply a case of this being the job of the user agent instead of middle-boxes that manipulate traffic.
Of course, this makes it more annoying to deal with user-hostile user agents such as some kinds of appliances and other locked-down devices; in which case I would suggest "don't buy user-hostile devices".
I genuinely don't see how DNS-over-http/quic is leading to unblockable advertisements. Adblocking extensions, which have got to account for at least 99% of all adblocking, don't work on DNS at all afaik - they work on already resolved hostnames?
You got it the wrong way around. Ad blocker extensions should be your first choice, this DNS blocking business is really for devices where that is not possible ("Smart" TV et al) and it's getting less effective by the day.
I assume DNS over Whatever will still respect the HOSTS file? I'd be really surprised to find otherwise, but would love to hear if that's the case! If you don't trust the browser you already have very little defense against ads, no? After all, the browser could always just resolve DNS itself.
HOSTS files may also be simplest (I totally disagree btw), but I can't imagine they're anywhere near the most common.
Chrome itself always requests HTTP first, except for HSTS and their own pinned certificates list which is actually shipped within the source code.
That's also a major difference to Ungoogled Chromium, where UC will request "https://..." by default if you just enter the domain.
So in the case of Enterprise Proxies that have no locally force-installed cert to sniff on internet traffic will likely end up with HTTP-everywhere being used. But usually employers that encourage such bad practices also install their snakeoil MITM certificates locally.
The ad data (text, layout, media) can still be hidden on the client, but AFAIK with QUIC you can push it to the browser regardless if it actually was requested.
No. QUIC is a transport protocol. Its purpose is roughly equivalent to TCP: provide a reliable byte stream transport over an unreliable datagram service (IP, though QUIC prepends a small UDP header mostly for compatibility with existing infrastructure).
You might be thinking of the HTTP server push functionality. That was introduced with HTTP/2 and has been deployed for years already over TCP transports (i.e. totally unrelated to QUIC).
Due to how advertising networks work, I'd be surprised if anyone used server push in the way you fear.
this thread is filled with some very very aggressive high level instigators, spouting wild outlandish grimdark fantasies that they in no way justify or explain.
there is such a poisonous mentality that has taken root, that is popular. no one at the ietf shares these delusional fears, & it's not because the ietf is a bought out shadow puppet. it's because in reality http3 brings what http2 brought but technically better which brought what http1 brought but technically better.
> spouting wild outlandish grimdark fantasies that they in no way justify or explain.
Did you have a good look at how the internet evolved in the last 15 years?
The IETF can invent HTTP/23 with DNS-over-whatever tomorrow, that doesn't change anything about the general state of the internet, which can best be summarized as a "burning pile of poop".
Do you really need any examples of how broken everything is? Do you really wonder that people have "grimdark fantasies" about what the "next cool web feature" will bring to us?
Most services can fallback to HTTP1.1 gracefully. You should be able to configure a proxy which hard drops HTTP2, HTTP3 and DNS tunnelling. You’re up to the mercy of the server to actually respect HTTP1.1 but I’ve not yet herd of a 2+ only service.
You will lose performance, but you’ll gain control.
If it's not happening already, I absolutely expect there to be API endpoints that only accept HTTP/2, esp. for APIs that only assume their own inhouse apps to be talking to them (esp. smartphone apps).
there is a good chance that the world will see unblockable advertisements in our near future
I don't think we'll ever have unblockable adverts. It would give users a huge incentive to change browser. Google get a great deal of value from people using Chrome and I don't see them giving that up just to serve ads to people that want to block them.
At this current date 10/08/2020 from what I see nobody is able to block youtube ads on a smart tv or through the youtube app on a non-rooted phone. You can set up a pihole or dns ad blocker but this will not block any of the ads due to sneaky use of dynamic video ID to serve ads.
Unblockable ads have always been and will always be possible. The host site just needs to resolve and inject the ad content on their side of the wire. For video they just need to interleave the ad content into the video stream. Good luck fighting that.
> With both a DNS-over-HTTP client and potentially a DNS-over-QUIC in the browser and serving advertisements over QUIC... there is a good chance that the world will see unblockable advertisements
And better tracking. In DoH RFC [0], 8. Privacy Considerations, 8.2. In the Server:
"HTTP's feature set can also be used for identification and tracking in a number of different ways. For example, Authentication request header fields explicitly identify profiles in use, and HTTP cookies are designed as an explicit state-tracking mechanism .."
"Determining whether or not a DoH implementation requires HTTP cookie support is particularly important because HTTP cookies are the primary state tracking mechanism in HTTP. HTTP cookies SHOULD NOT be accepted by DOH clients unless they are explicitly required by a use case."
There are valid uses for DoH, the most important being its counter against internet censorship. For DoT, a block on UDP/853 is all that's needed. Blocking DoH requires much more effort.
I'm sorry but this is very much going to happen since nearly 1B Androids are now DoT capable. ESNI may also be blocked for same reasons once it is widely deployed.
> Safari fixed similar thing that was using HSTS, but I bet they'll kill this one too.
Safari cannot cover for apps sending DNS requests.
The world already sees unblockable ads. They're called "Ads by Google" on the first page of Google search results depending on the search query.
DNS-over-HTTPS can actually be useful. I can do bulk DNS lookups from DOH servers using HTTP/1.1 pipelining, retrieving thousands of names at a time over a single TCP connection. I can look up every name for every HN item in one go, store this data in zone file served by a localhost DNS server and generally never have to use remote DNS when browsing HN. This makes for fast browsing with a text-only browser.
The issue I am surprised more people are not raising is the decision of Google to encourage Golang developers to use a "built-in" DNS resolver in their applications rather than relying the system resolver and submitting to traditional user controls like resolv.conf, nsswitch.conf and HOSTS. Regardless of the motivation behind this choice, IMO it tips the scales toward developers instead of (non-Windows) users in terms of ease of control over DNS lookups, not to mention the privacy issue (shared by DOH) of enabling a third party DNS provider to segregate lookups by device.
That's OP's point. Anyway DNS-based ad blocker can't block such ads (delivered from same host name as content) but browser extension can. I'm curious why DNS-based approach is such popular even for PC browser.
You are still requesting and receiving the ads as they are part of the results page. View source in your browser to verify. Your ad blocker is probably modifying the page after you receive it so the ads do not display. I can do the same thing without an ad blocker using something like curl and sed. I edit out the ads, then view the page. The parent commenter OTOH is referring to DNS-based "blocking". In that case, the ads come from another domain and because we control DNS the ads are never requested, never sent and thus never received. There is nothing to discard. The word "block" is really not the best term to describe what is happening.
Could you or someone else explain how QUIC as a transport protocol prevents the ability for things like browser extensions to do ad blocking? How did the research project you described support that assertion? That wasn't clear to me.
Unrelated: chromium 86 bring the backforward cache which make back navigation instantaneous in many cases, this was I believe, the biggest optimization that was Firefox only
Has the amplification attack been solved recently? Last I checked the spec still said "at most 3x amplification" (which I expect will be enough for attackers) and the server implementation that I was testing went well beyond that. If that's not solved and this gets deployed on a few big networks, I can already tell you what the next popular protocol will be for taking down websites.
No, it hasn’t been solved and it won’t be because it can’t be solved without adding more round trips to the handshake. It’ll be down to firewalls to stop this from happening.
It could use the STK (source address token), which it creates for 0RTT anyway, to identify which sessions to respond to. New sessions from a source IP which shows elevated rates could be dropped X-1/X times (e.g. X=5) because a legitimate client will retry and obtain an STK in, on average, X attempts. This would reduce the amplification factor to below one, assuming the client handshake is <X times smaller than the server handshake (which includes a cert).
Firewalls can't block this because then you introduce a denial of service vector. If I can block anyone on the Internet from accessing a service because the service's firewall blocks the source IP... this is why this isn't a solution for dns and other udp protocols' amplification attacks, either. Otherwise we'd block offenders and be done with the problem of amplified DDoS attacks really quickly. The problem is allowing legitimate clients to pass that look (nearly?) identical to what the attacker sends. The STK seems to solve this (in a similar way to TCP, while allowing for 0RTT after the client met the server once), so let's use it?
Edit: just noticed you posted another comment critical of QUIC. To be clear, this isn't "QUIC is amazing, let's use this STK and it'll be great". I don't know enough about it for that. Heck, I like the textual property of HTTP/1 and would be fine keeping that as well. I just noticed this security problem with HTTP/3 and would prefer to see it fixed before widespread deployment given how heavily similar services are abused.
Those incremental gains doesn't seems much better than what linux Tcp improvments get each year, especially if turning on state of the art congestion / bufferbloat algorithms.
Also Tcp fast open is ridiculously old and I can't see how mainstream equipment still wouldn't support it on average.
i would like to see peformance comparison with SRT for example or other udp-based protocol. i mean, it its good for video, it must be good for web too.
Does anyone else think it's weird/futile that they're building a protocol over UDP?
QUIC is disabled on our corporate network, simply because the network firewall/SSL inspector can't see what's going on, and can't regulate traffic, so it just blocks all UDP. our internet still works because sites see that QUIC doesn't work and fall back to TCP. Heaven forbid the entire web moves to QUIC or we'd be in trouble.
It's strangely common. As someone who has worked in a few IoT companies that ship devices that run on other people's networks the amount of enterprise gear that just drops all UDP as a default is astonishing. Every single IoT device I've worked on has had some custom, hand rolled, NTP-over-HTTP to get around RTC failures.
TCP+UDP will probably be the norm for a decade once it's rolled out, and with this being announced for Chrome, it'll only show the market that there's demand for UDP packet inspection - not that that's the best solution to DLP; endpoint security and MDM gives the most insight and solves the problem of middlemen [who might be a trusted local network operator, or might be a government-controlled ISP] being able to inspect/limit traffic.
My point is that it is a lot of people's problem. Mine isn't the only company using large-scale, off-the-shelf, really-very-normal firewall and network safety equipment and software. Just because you work at a start up, doesn't mean most people do. Lots of us work at banks, financial institutions, insurance companies. These companies make a lot more money than the average start up, and are risk averse and care a lot about compliance. They house a lot of "dark matter" developers and technology professionals.
The whole way this debate is going irks me. It's like there is two camps: those who think all the world is smart phones being used by people way out in the desert and everyone else. There are lots and lots of devices that have high speed, low latency connections. The people that use those devices are people, too. We should not over optimize for the remote smart phone user over everyone else.
Enterprises can still have all this stuff that is supposedly so important to them, like network interception and "compliance". But they might have to upgrade their software, insist that their vendors implement standards correctly, or maybe change the way they do some things. As you point out, these companies make more money than anyone else. That means change shouldn't be a problem for them. But of course they would prefer to externalize their costs onto less-resourced companies and individuals. It's everyone else's job to make sure they can't get away with that.
The biggest users of MITM technologies are companies but there are probably quite a few individual users too --- I have a proxy for network-wide adblocking and page rewriting/filtering.
I encourage you to reach out to your elected representatives and let them know you are opposed to things like banking regulations that require corporations to capture all employee communications.
Am I missing something? Aren‘t you supposed to do this via end point protection these days? In the same way that big corps should deploy zero trust models.
But I get it. Security and Privacy is really only about ‚compliance‘ and legal protection for large corps.
Does your company really need to do SSL inspection or are they doing it just because they can? My experience of working in places that do that is that it encourages poor security practices because people end up being too lazy to install the root certificates in their software or can't work out how and end up just disabling certificate checking entirely
I want to go out there and say that I hate SSL inspection. But in the case of our VDI workstations the way the company has it it's not something you can turn off. They're trying to put software on all our laptops which would make SSL inspection a reality on our laptops as well but I'm avoiding it like the plague. It's just too hard to teach all the applications that I use to use a certificate chain that they're not interested in using.
There's some efficiency gains from having streams at a lower level. E.g. if it's known that a transmission of a particular chunk of a stream failed, the next transmission can capture that chunks plus additional data from that stream instead of just blindly retransmitting a full datagram.
Besides that the crypto and handshake parts also need streams with guaranteed delivery and ordering, since they carry TLS stream data.
> E.g. if it's known that a transmission of a particular chunk of a stream failed, the next transmission can capture that chunks plus additional data from that stream instead of just blindly retransmitting a full datagram.
But QUIC Datagrams do have ACKs, and don't have retries. Maybe we don't want them to have ACKs, but as long as it's opt-in, is that not enough for the upper layers?
> Besides that the crypto and handshake parts also need streams with guaranteed delivery and ordering, since they carry TLS stream data.
QUIC packets are individually encrypted so more metadata can be encrypted too. And I don't think connection establishment uses any sort of stream abstraction either since people speak of n-packet handshakes?
> But QUIC Datagrams do have ACKs, and don't have retries. Maybe we don't want them to have ACKs, but as long as it's opt-in, is that not enough for the upper layers?
Imagine the following: The users writes a few bytes on a stream, those get immediately transmitted and lost. Before the retransmission, the user enqueues more data.
The Quic implementation has now the opportunity to merge everything into a single Quic "packet", and even a single Quic "frame", and send everything together. If those things were on top of datagrams, it might need to send the whole datagram again?
There are also other scenarios: E.g. the stream getting reset while transmission is in progress. If that happens none of those data chunks will ever have to be retransmitted. I feel like having an additional layer here will make this harder and less efficient.
> And I don't think connection establishment uses any sort of stream abstraction either since people speak of n-packet handshakes?
This is important for the handshake, since the TLS implementation will act on this ordered stream data and kind of treat it as a TLS data over TCP stream.
> The Quic implementation has now the opportunity to merge everything into a single Quic "packet", and even a single Quic "frame", and send everything together. If those things were on top of datagrams, it might need to send the whole datagram again?
QUIC doesn't resend datagrams; QUIC itself just uses datagram ACKs for congestion control. But if it notifies the next higher layer about ACKs, that layer is free to coalesce on retry, just like normal streaming.
> There are also other scenarios: E.g. the stream getting reset while transmission is in progress. If that happens none of those data chunks will ever have to be retransmitted. I feel like having an additional layer here will make this harder and less efficient.
STREAM_RESET would be entirely internal to the streaming layer, right? Again, the datagram layer doesn't re-transmit so no need to worry about that.
The level of complexity of this thing goes way beyond the HTTP over CORBA experiment that took place at the end of millennium.
The point is: despite CORBA's convoluted complexity, at least HTTP + CORBA experiment was somewhat sane as it allowed to use multiplexed connections right out of the box and relied upon standard network capabilities without reinventing the wheel. All that in 1999 or so.
DNS over HTTPS, QUIC et al look nothing less than a monopolistic attack on open web. Google really wants to own the Internet.
not sure why DNS over HTTPS or QUIC are monopolistic attacks, both already have several open-source options for clients and servers:
https://awesomeopensource.com/projects/quic
Microsoft Office has 'several open-source options' too. They're all nigh-unusable because the MS Office so-called "standards" are so convoluted and under-specified as to be practically useless.
“Today this changes. We've found that IETF QUIC significantly outperforms HTTP over TLS 1.3 over TCP. In particular, Google search latency decreases by over 2%. YouTube rebuffer time decreased by over 9%, while client throughput increased by over 3% on desktop and over 7% on mobile.“
This is the most sickening sentence for me. The myopic internal focus. ‘Look we’ve made our new thing a standard and look it makes our products run faster’. This is just blatant exploitation that’s occurring as there is too much centralised ownership. In my opinion this is predatory behaviour packaged up as open source good for all.
I don't have a well-defined solution, but I think the notion of companies selling shares to people in armchairs who neither necessarily use nor feel the side effects of the product is an issue. To a great degree I don't believe in 100% free market valuation of companies. Rather, I think the people most affected by the company (positively or negatively) should have the biggest say in its value.
There also needs to be some adjustment to that valuation based on greater good delivered by the company. If they killed off a bunch of smaller businesses, that's a negative. If they emitted a bunch of carbon, that's a negative. If they caused injuries or deaths, that's a negative. If they contributed to open source products that enabled other companies to exist, that's a positive.
Carbon taxes are one step at capturing one very small aspect of this "greater good" factor, but there need to be other adjustments as well.
Another vague idea I've had is a hypothetical economic system in which the government doesn't print money (or isn't the only one printing money) but rather money is brought to existence by certain good deeds. Money can also be traded for goods and services, of course, in addition. So while you could make money by selling food or selling phones, you could also literally print your own money (translate: government hands it to you, in a controlled fashion) by sucking carbon out of the environment and proving that you did that to claim your money.
> ...but I think the notion of companies selling shares to people in armchairs who neither necessarily use nor feel the side effects of the product is an issue.
Their function is to raise money, whether they use the product or not (you don’t invest in something unless you believe it will provide value to some group of people) they’ve done their job and the company can continue to advance and adapt due to the capital. Further if you set what a company can be worth you’ve limited their resources and limited their innovation as a result.
You’ve also turned human labor into currency in an attempt to get rid of currency. You cannot get rid of the concept of money. Without it you must trade resources (like labor), which history has shown is a very bad idea. The idea of a government being able to print money is a very deliberate feature, not a bug. I cannot do this justice, but read up on why we have money in the first place.
Increases performance by 3%, and complicates HTTP by 100%. I'm not sure I would like that. I would understand if it was 2x performance gain or at least 50%, but a mere 3%?
This is exactly why it's important that they publish their figures - so you can make a decision if it's works for you after weighing the tradeoffs. For high-traffic properties (Google, CDNs, Netflix), 3% can easily translate to millions of dollars saved - they could hire an entire team just to deal with the HTTP complications.
Most of it is garbage that doesn't need to be there and is shoved in people's faces because it makes other people money/power.
Ex: Why does clicking on a location link in google search load a big slow SPA to display a list of "cards" instead of just having a maps/web link in the search results?
I thought it's because Google isn't allowed to promote Google Maps in its search results, but a cursory search didn't yield any evidence.
Presumably if Search did link to Google Maps, other geographic information systems would have to be represented, just like various streaming platforms are represented in the video tab.
Don't forget the 7% throughput increase on mobile. That's a big deal, especially given that mobile users account for the majority of network traffic these days.
And 3% is still a lot if you're looking at global Internet traffic.
Although that is true, I agree with GP in the sense that the improvements in protocol and browser are motivated by what benefits their own products, rather than what benefits everyone.
this is such uneducated mean ness. real engineers from all over care about improving http a lot. you throw random conspiracy grade conjecture in, throw this uneducated disrespectful shade why? how much effort have you made to understand the improvements? you show no recognition that the concensus-based ietf working groups are in agreement that this is a worthy & good enhancement to http3. please do not degrade that work so coursely & with such empty hot air. be civil.
Nevertheless we should all be as clear as possible about Googles' motivation for pushing any new technology: Better data collection, more/better/fine-tuned ads.
I don’t think GP’s speculation is anywhere close to “random conspiracy grade” stuff. It’s predictable and plausible enough of a motive to be mentioned elsewhere in this thread, e.g. this top-level comment [1].
>>how much effort have you made to understand the improvements? you show no recognition that the concensus-based ietf working groups are in agreement that this is a worthy & good enhancement to http3.
Most network stacks in major operating systems enable Nagle's algorithm[1] which was designed in the mid 80's to improve the efficiency of TCP/IP networks. John Nagle, the parent you're responding to, likely understands the HTTP/3 improvements at a level beyond what most of us can comprehend given his deep experience in this area[2].
As the author of two foundational RFCs (RFC896[3] and RFC970[4]), I think the parent also has a fairly good recognition of and experience working with IETF working groups.
ok I didn't know that this was john nagle. that's intimidating.
i'm still highly alarmed, both by John & the general level of discourse going on all throughout this thread. i posted replies to a number of others too. there is wild unsubstantiated & mean-spirited speculation running rampant through this, imo, good news. no one talks to how or why they think this is going to help spy on us, or reduce our ability to block ads, yet it's a very popular & trendy opinion. it seems widely assumed that this is all for bad, and everyone seems to want to believe that mis-information.
i find it distressing that the world would be so paranoid & crazy as this. after years of IETF hard work & discussion, after countless engineers work tirelessly to maximize privacy & security, after countless points are raised & tackled, the world greets what we think is a real & significant improvement with disdain, distrust, & belittling. this feels like the kind of easy-to-spread paranoia & madness that is part & parcel to the disinformation that has grown a threat to civil order, a threat to reason. it's too easy to knock things down[1], done so casually, & people seem to want to hear it too much. i realize i haven't been helping, haven't been waging an effective campaign to try to promote a healthier course for us, better discourse, but i want to. i want to not be overwhelmed & saddened by unsupported unreason.
touching back to @animats' post:
> The real motivation is probably to merge ads into the same stream as the content,
i don't see any potential for how this would impact ad-blocking or other security measures on the web. HTTP3 offers no new features or capabilities over HTTP2. existing extensions & tools ought be unaffected.
> All that effort to get a tiny improvement.
imo QUIC+HTTP3 is a straightforward & sensible simplification over what we had, & was a natural route to enhancing the existing systems.
http2 wanted to share a connection, allow out of order serving of requests in a better way than the obsolete & complicated/painful & largely removed http1.1 pipelineing, so servers could start working on upcoming work before finishing the current request.
quic has been an attempt to take a lot of the good work already done on http2, & to drive it further down the stack, enabling a) others to use the transport/session layers now distilled into quic for their own uses, and b) radically simplifying the http specification's responsibilities by separating out quic transport/session concerns from http.
beyond making http3 much simpler, there are other benefits. a capable replacement for WebSockets is forming via WebTransport[2], and a lot of people are hoping the complex SCTP-based WebRTC stack can be re-designed to use WebTransport/quic, once webtransport advances[3].
overall, the greatest proof that this is a simpler, better, more natural path than what we had comes from a quick look a the QUIC active & related documents[4], where we can see a number of different frontiers of innovation for other ways QUIC might be improved & enhanced, including topics such as multicast, load balancing, unreliable connections, & more: quic is a flexible, interesting, compelling extraction of really neat & interesting http2 technology, & decoupled from http, we are seeing amazing innovation take root & allow all sorts of good frontiers to open. quic is itself a big improvement to what was available for transport & session protocols, and it is throwing open the doors to colossal levels of innovation that were not conceivable before.
> The real motivation is probably to merge ads into the same stream as the content.
I was thinking of Google-hosted content, with Google ads. About 25% of web traffic now comes from Google, although that includes YouTube. Google serves some (most?) ads from "doubleclick.com", which can be blocked at the domain level. But if they slip the ads into the same encrypted connection as the content, it's no longer possible to block them from outside the browser.
As for traffic issues, I've seen a few papers where people compare QUIC and TCP.[1][2] But nobody seems to be looking at what QUIC-type traffic is doing to other traffic on the same path. Not that I have, either. You can boost your throughput a bit by being more aggressive about sending packets. If the nodes in the middle are all FIFO queues (the cause of "bufferbloat"), the one who sends the most wins. This creates a perverse incentive and a way to game the results of such comparisons. Fair queuing can help.
Still, it's probably a win to speed up all the handshaking involved in setting up a TLS connection. The crypto setup is a big cost for small requests.
Glad others are starting to articulate this issue. HTTP/3 is derived from HTTP/2. Google's main argument for HTTP/2's existence, its selling point to users, is head-of-line blocking in HTTP/1.1 pipelining. They also complain about the size of repeated HTTP headers.
But no modern browsers actually use HTTP/1.1 pipelining. Interestingly, HTTP/1.1 pipelining works great for non-browser use. Most web servers enable it by default. After all, it works. For example requesting a series of pages from multi-page website, all under a single TCP connection. I have been using HTTP/1.1 pipeplining this way for decades. It is fast and reliable and enables the web to be used as a non-interactive, information retrieval source. It is also 100% ad-free. The user only gets what she requests, nothing more.
As for HTTP headers, privacy-conscious or minimalist users might not send many headers, only the minimum to retrieve the page. That's usually up to three extra lines of text per page for the request headers. (I rarely ever have to send a User-Agent header for HTTP/1.1 pipelining.)
GET /index.html HTTP/1.1
Host: example.com
Connection: keep-alive
Obviously, the web advertising/tracking industry, including companies like Google that serve this sector, use headers for their own purposes. Online advertising services. That's when presumably they could get big. However, as a user, I have no pressing need for the ability to send/receive larger headers.
Websites (IPs represented by domain names) to which users intentionally connect, i.e., the recognisable names that they type and click on, generally don't serve ads. The ads come from other domains, often other servers. Users generally do not intentionally try to connect to ad or tracking servers. HTTP/[01].x's automatic loading of resources, Javascript and other techniques may be used to make those requests, conveniently under the radar and outside the user's awareness.
Still, under HTTP/1.1, ads, nor Javascript files that trigger requests for ads, generally cannnot be delivered without the user's computer making a request first. Users can and do manage to exercise some control over their computers and they can prevent these non-interactive requests from being sent, from inside and outside the browser.
With HTTP/2 and HTTP/3, the necessity of a user-generated request disappears. As soon as the user "connects" (UDP) to the website's server, the server could for example send a Javascript file to the user's browser which can in turn trigger requests to other domains for ads or the purpose of tracking, all without any preceding request for the ad/tracking-related Javascript file. This is another feature of HTTP/[23] called "server push", but interestingly it is not the feature being used to sell HTTP/[23] to users (i.e., pipelining).
So, how does a user stop unwanted ads being "pushed" upon her in the stream (irrespective of the application, e.g., browser)? I generally don't use a "modern" browser, nor Javascript nor graphics. I like my pipelining outside the browser and free of advertising-related cruft.
It's worth considering that the motivation for speeding up websites via HTTP/[23] is solely for the purpose of speeding the delivery of more ads, more "stealthily", to users. This is a classic case of someone trying to sell you on a "solution" to a problem they themselves have created (or to which they are contributing).
Like an ISP trying to upsell customers to faster internet in order that websites bogged down with ads will "load" faster. When the ISP itself injects ads into pages of websites that are weighed down by ads.
Well strictly speaking I guess I'd rather have fast ad-laden pages than slow, but more likely these gains will vanish as ad congestion re-converges to the previous equilibrium. Users' tolerance for sluggishness is the true constant, not the amount of ads companies want to serve.
Is it really faster? I'm thinking if you have blocked the ads, that will be significantly faster. Google's benchmarks of course would not include how much faster HTTP3 is for pages with blocked ad content.
HTTP 2 can't just send content from other domains through the same connection (and any proposal that adds the ability, e.g. through signing, also can be used with HTTP 1.1 connections)
And pushed content needs to be accepted by the browser, just sending someone ad bytes doesn't really do anything useful. It doesn't impact adblocking, and if a browser vendor wants to take the adblocking features away they can also just do that for the traditional model.
Clients can refuse pushed requests (e.g. if they match filtering rules), so it's not like the server will push the full files through. It'd be interesting to check if clients do take e.g. OS settings about metering into account and disable push entirely to even avoid the initial transfer.
A related question: is it faster because it sends less data, or is it faster because it grabs more of the bandwidth by not using TCP-type congestion control?
When "everyone" uses your software/websites, you can get away with this, much like Microsoft did back in the day. Internal Windows programs ran faster and seemed more stable than third party software written to run on Windows. It generally offered better "UX", to use today's lingo.
The thing that is totally ignored by the myopic focus is the value of not being part of the Borg. Putting small speed differences aside, that value is not insubstantial, though the Google communications department is not responsible for keeping users informed about anything more than the value of Google.
The fastest internet would be one without ads (not to mention the other benefits). Google will not inform anyone about that. It is not included in any tests.
I don't disagree with your sentiment. However, their biggest gains in terms of percentage points (as discussed in the article) are for YouTube. And YouTube wouldn't be significantly faster without ads in the way that browsing primarily textual websites is faster without ads. Getting buffering times down is actually a substantial improvement here esp. on flaky connections. (Though the article doesn't make it clear whether flaky connections specifically benefit from QUIC.)
Waiting for pre-roll ads on YouTube certainly slows down the viewing experience. I do not use the YouTube JavaScript player. I download the video using a custom script and an HTTP client like tnftp and watch offline. Google is suggesting that users use their browser, their website and their internal player to view someone else's video file, so Google can serve ads, do tracking and collect analytics. The testing is not something generic like downloading a file from a server; instead, it uses Google protocol, Google browser, Google website, Google player and is announced on Google blog.
> In my opinion this is predatory behaviour packaged up as open source good for all.
you appear to have made no attempt to understand or grasp what or why of quic & http3. many ietf engineers from all corners have worked on this because they believe to be an improvement. this tackles very real head of line blocking problems & introduces a much more forward & fast security model.
quit your cheap slander please. your casual, uninvested vitriolic outburst is disgusting. show some manners. you immediately jumped to the nasty gross conclusion you wanted to based off some engineers citing improved performance, threw slander at the attempt without even a quick look at how or why engineers sought these improvements. this behavior is sickeningly anti-social, & nothing more than a projection of your warped world view. please attempt to surface something even somewhat copied to truth when you go about shooting off.
Breaking the site guidelines this badly is easily a bannable offense on HN. Worse, we already asked you a few weeks ago not to do it anymore: https://news.ycombinator.com/item?id=24512910.
I'm going to cut you some slack because it looks like your other comments since then have been good, but if you do it again we are going to have to ban you, so please review the rules and stick to them: https://news.ycombinator.com/newsguidelines.html.
People argue both sides of this. If Google implements a new protocol on their servers and their clients without standardizing it, they're end-running the standards process or embrace-extend-extinguishing the open internet. If they do standardize it and then deploy the standard implementation, they're.. I don't even know, making billions of page loads faster and that's bad because they're Google?
What's the right way for Google to improve their internet-facing services at a protocol level?
The underlying concern is that Google is in a position to dictate. They control most phones and most browsers and the most popular websites. Any standardization is pro forma, because what matters is what Chrome/Android/google.com does, and not what the standard says.
An emperor can build trust by relinquishing power.
What you're proposing as a solution has already happened: Google relinquished their control over this protocol to the IETF, where it changed so much as to be incompatible with Google's original.
Now they're updating their own deployment, making it compatible with the updated standard.
Chrome/Android/google.com is literally changing what they do to match what the standard says.
Huh? They're reporting for their own products presumably because they have access to that information that is accurate, and they're a couple of the world's most popular, most visited sites.
But the speed improvements will come for everyone who uses the protocols, not just Google, of course. What is sickening about that?
Google Chrome collects performance and usage information for _every_ site you visit, not just Google properties. This is part of "Chrome Lighthouse" or whatever.
imo this is a quite harsh & pointed take you have presented. you seem to focus on some very-nearby headline sentences that do focus on performance, where-as the real story is much more interesting & the tech much more promising.
> blatant exploitation that’s occurring as there is too much centralised ownership
what makes you think this is so lopsided? yes, the spdy drafts released in 2012 originated from google. and google spent enormous amounts of effort, time & money championing & supporting development of QUIC as it made it's way through the IETF, where other non-Google engineers also worked to improve HTTP and build a powerful new transport protocol that shows enormous progress & is opening doors.
where is the exploitation?
> The myopic internal focus. ‘Look we’ve made our new thing a standard and look it makes our products run faster’
actually they made two standards. this is much better than where we were. with http2, we had built a true monster of a specification, untame-able. for good reason! we wanted good things! but the http2 spec was trying to shoe-horn a bunch of streams inside tcp, a streaming transport protocol, and that never quite fit (head of line blocking problems resulted), but just as bad, it made http2 a massive work that was hard to evolve & grow & reuse & enhance.
they took an extremely broad view, & said, these pieces don't belong together. they delegated responsibility into component pieces. they made pieces re-usable.
the result is that there are now a couple dozen efforts related to improve the underlying QUIC transport for lots of interesting use cases. the QUIC working group lists a couple dozen efforts[1] & enhancements, such as multi-path, load-balancing tuning, multicast, ack controls, satcom capabilities, & webtransport, a potential radical simplification & rework of websockets in a more connection-friendly manner. this is all work being done outside of http, being done with quic, because of these advances by these very careful, considerate, thoughtful, aware engineers, & their willingness to work with other engineers & the IETF to figure out how best to improve things, how best to decouple http2's transport protocol from it's application protocols.
> In my opinion this is predatory behaviour packaged up as open source good for all
i would very much like to hear some of what you feel or think any of your numerous very heavy accusations are due or deserved. using acerbaic words like "most sickening sentence", "myopic internal focus", & "blatant explotation" are big big words, big angry moods, and it's really uncomfortable, really hard for me to process & deal with such emotional turmoil directed at something that seems so innocent & like such a natural refinement & progression over the very good solid ideas & improvement that were http2, as it tried to move on & progress beyond http1.1 pipelineing, which everyone wanted very much wanted & in many cases did give up on.
so why do you hold your opinion? it really hurt me to hear your opinion, stated so pointedly, at such a lot of work that so many engineers all over the industry have contributed to & worked hard on. is this new dissent you have? are there other anti-http3 anti-quic folks who have staked some of their problems & claims & issues, or who have other ways they want the community to work through standards & specifications to improve the internet? what are the issues here, what's wrong? i for one thank my lucky stars that there are corporate patrons paying engineers good money to improve the world with works like this, to do the logical & consistent task of breaking http2 into it's transport (quic) and application (http3) protocols, improving the speed & reliability of the net.
thank you Google & IETF for doing all sorts of g...
While this seems good to have a more efficient transport, I can't make sense of this
> Since the subsequent IETF drafts 30 and 31 do not have compatibility-breaking changes, we currently are not planning to change the over-the-wire identifier.
Are there slow-moving internal software at Google that relies on this nonce? This looks like the kind of thing that some clients will tend to rely on (for a reason yet unknown). That's how clients grow the standard in unintended ways, no?
On another note:
3. optionally, the trailer field section, if present, sent as a single HEADERS frame.
I see you're paving the way for gRPC on the Web (of browsers) by adding trailers (a header sent after the body), which is not supported today for HTTP/1 not /2 by at least the top 3 browser vendors in volume.
I'm divided: I'd be glad to get rid of grpc-gateway and websockets but isn't proto-encoded communication bad for the open Web /in principle/? Maybe it's only a tooling problem.
I think there's a large volume of tools that can be built that will make things much more discoverable as we go along this route. Things like the gRPC reflection, health checks, etc can all be instrumented in tooling with no guess work as to how to directly talk to any API that implements it. No guessing if it's `GET /healthz` or `GET /healthcheck` etc.
There's a lot of magic you can do with protos. At my current company we're even generating forms/UIs entirely off of proto message definitions for things like configs. Engineers no longer need to think about how to make something work cross language, manually wiring up a UI, etc.
I cant wait to see what doors this opens up for gRPC on the browser as that will bring many more OSS devs into the ecosystem.
Does anyone know when HTTP/3 is going to get wider support in gRPC. There's an open issue in the github project about this [0]. In IoT use cases where you want to do bi-directional stream of data to/from a location getting rid of some head of line blocking will make me a happy camper.
Is this being added to Chromium code? Its hard to tell if its being added (and in which release) or if parts of it or all of it are already in Chrome or Chromium and are just being enabled now
It's in there (and has been for a while). You can open your network inspector, enable the "Protocol" heading, and look for "h3" requests. For example, if I visit cloudflare.com right now, I see a bunch of requests with protocol "h3-29". If I visit Google maps, I see requests with "h3-Q050". (The part after the h3- is the draft number; Cloudflare's servers use draft 29; Google uses their own thing which identifies itself as Q050.)
It is safe to conclude that eventually drafts will settle down further, QUIC and HTTP/3 will pass last call and get published, maybe in 2021.
I don't know what "the cross-out treatment" is exactly but if you mean the UI behaviour where non-secure contexts get a red line or the words "Not Secure" then there's no reason that will change. HTTP/1.1 over TLS is still fine, HTTP/1.1 plaintext was already treated that way. The newer protocol isn't really "more secure", than HTTP/1.1 over TLS, but it is as this article notes, faster and more capable.
Does anyone know what the maturity of standalone C-compatible implementations is like?
Curl seem to be evaluating two different stacks: ngtcp2+nghttp3 (C, seems to be from developers behind aria2) and Quiche (Rust, from Cloudflare)
Then there's Google's C++ QUICHE implementation which seems to not be used by anyone outside of Chromium (Even node.js apparently isn't using this, unless the code is just old).
429 comments
[ 4.1 ms ] story [ 295 ms ] threadI expect HTTP/2 usage to disappear, leaving HTTP/1.1 and HTTP/3 as the main versions in use. For HTTP traffic (as distinct from other upgraded protocols like WebSocket) HTTP/2 is mostly better for users than HTTP/1.1, but TCP head-of-line blocking is its one particularly serious problem. For users, I would characterise HTTP/3 as generally just the best of both worlds, and once you have it there there’s no reason at all for HTTP/2.
HTTP/1.1 will remain popular indefinitely for compatibility with older servers and clients that aren’t being updated to the latest stuff, and for HTTP upgrading mechanisms.
Like, the final chapter of the Rust book does this. We implement a really minimal HTTP server.
Turns out that, even though what we do is spec compliant, some versions of Chrome don't properly deal with the responses we give, which has had to lead to errata. Implementing the web means knowing the implementation details of the major implementations, and following them, sadly. It's not actually that simple.
HTTP is the lingua franca of the internet. We need to keep a simple, text-based version of it around, so that the barrier to entry for competing with the big boys remains reasonable. We've already lost that fight with browsers, but HTTP is still in a pretty good place. Even HTTP/3 is reasonable for a small startup to implement. And if you can't manage that, you can implement HTTP/1.1 and sacrifice some performance for simplicity.
This is probably where we differ; I pretty much think that you do have to do this in this situation. Or at least, like, sure, you don't have to, but you lose a significant amount of audience, which is one of the major points of bothering with the web in the first place.
In terms of building things today, I'm more saying that if you need an internet protocol for moving data around, HTTP is a pretty dang good choice. It has some cruft, but if you were to start making a replacement from scratch you would end up with a large subset of HTTP/1.1. That's not true of HTTP/3. You simply don't need the complexity for a large number of useful tasks.
Now, in terms of the future. I think that the internet will long outlive the web (at least as we currently conceive of the web), and I think HTTP as a transport layer will outlive it as well. In that future, I want HTTP/1.1 to still be a thing.
https://blog.chromium.org/2013/06/experimenting-with-quic.ht...
* https://github.com/cloudflare/quiche
* https://github.com/djc/quinn
* https://github.com/mozilla/neqo/
1: https://interop.seemann.io
There’s no reason to ask everyone on the planet to change “https:” to “http3:” when we still can’t even reliably complete the “http:” to “https:” transition. We’ve learned that users simply do not care at all about “http:” or “https:”. We shouldn’t have to ask people to update their QR codes for HTTP3 just because we updated the protocol.
Should we have introduced ftpp:// for passive FTP to distinguish it from classic FTP? No: it would only confuse users, cause frustration for pages linking to FTP urls, and both servers and clients are perfectly capable of negotiating this silently without surfacing it to the user.
In general the pushback with HTTP3 is that site operators would rather not have to do the extra work to enable it. But from a user’s perspective, there is no work to enable it. It’s just https:// like always and one day it gets faster. Sites that refuse to do the extra work to turn it on will be visibly slower than their peers once it’s widespread enough.
If you believe that HTTP3 should have had its own URI spec, you would have needed to make that case a few years ago to the committee implementing it; it’s not going to change now. I assume their discussion about that is in the archives, and I expect it boils down to “this is not relevant to users, they should not be expected to care”.
I just think it's weird that we've left ourselves without any way to send a client directly to an HTTP/3 site. Instead they _must_ establish a TCP connection to the site and be redirected via Alt-Svc headers to HTTP/3.
https://hn.algolia.com/?q=https%3A%2F%2Fblog.cloudflare.com%...
The Unifi issue you cite is due to a series of problems that are related to the http:// to https:// migration, most of which Unifi could have easily discovered and mitigated had they cared to. I'm really disappointed in Unifi here, but the browser is at fault, too.
First: Your browser's fallback process for handling "the user entered an invalid URI" is attempting http:// first, rather than https:// first.
Second: The Unifi is responding over http:// with a completely useless error page, rather than a redirect to https:// at the same port.
Third: The Unifi probably isn't setting a Strict-Transport-Security header on responses to https://:8443, which means that your browser can't learn a better default.
Fourth: If the Unifi's instructions tell you to enter "unifi.home.arpa:8443" rather than "https://unifi.home.arpa:8443", their instructions are clearly wrong. (If you're not following their instructions precisely as written, that would explain your discover of the prior three; I can't say I blame you — I would have left it off too.)
If it notices that HTTP/3 always loses or fails, it will gradually stop trying on the rationale that your network is broken so it's a waste of time.
If your site uses Cloudflare, this Just Works™ since Cloudflare will answer HTTP/3 and emit DNS records saying it speaks HTTP/3 so there's no new work for you. Otherwise, to enable it you'd need to either create SVCB records in your DNS (your DNS server may need to be updated) or use the Alt-Svc: feature and give up on the performance improvement for first visits.
Home > Settings > Developer, for anywhere in iOS 14 that uses the system HTTP library.
Note that you'll need a device with development mode enabled for the latter.
https://developer.apple.com/wwdc20/10111 has more details near the end.
What danger could possibly happen if I'm reading about a Physical Therapy clinic?
They don't take credit cards, there's no information for me to enter on the website.
But unless the Physical Therapist knows how to manage the server, they get this scary warning.
Maybe it isn't a big deal to US healthcare because they make lots of money. But I imagine there are others that don't have the technical abilities to upgrade to https. Could your grandma do it for her sewing store?
This is where all that centralization is really bad for security. It basically makes https a protection only against low effort MITM of last mile ISPs.
You are entitled to revocation of any unexpired certificates for names over which you can demonstrate control. For Let's Encrypt for example you can automate this, simply make the API calls to demonstrate control (as you would for issuance) and then present the certificate that is to be revoked (it's in the logs) and ask their API to revoke it.
Maybe DNSSEC could be used here to help if ACME added a way to force DNSSEC-only domain validation.
For example: No one is stopping someone from intercepting your request to your clinic and add a form asking for personal details - and then using those details to "restore password" - or simply ask for your CC number. You might not fall for it but are you as confident in all other patients?
Grandma might be able to edit HTML, but "what's sudo? What's ssh? This one website says I need to pay for certs?"
My biggest concern as http becomes less and less acceptable is that practically the entire internet relies on lets encrypt to run.
Sym crypto is the only answer (Schneier,DJB) people have been trumpeting this for years.
To validate the person holding that certificate is who they claim to be, how can I do that? By either getting their certificate out of band (impractical), or trusting an intermediate.
Lets encrypt doesn't make it any easier or harder to get an invalid certificate.
Now if the server wants me to authenticate, https has that built in. I can present my own client certificate, and if it's signed by somewhere the server trusts, it knows who I am. But how would a random server authenticate who I am? I'd personally rather use certificates or ssh keys or similar than usernames and passwords, but that's too complex for the average person.
Clearly I could have lost control over the key to my certificate, or the server could have lost theirs, there's not much you can do about that, no matter what type of authentication system you use.
First, getting authentic data from the provider so that you know what they published is what you're reading.
But also links and embedded links/scripts. Since HTTP can be (relatively) trivially MITMd, it not only exposes end users to getting manipulated info, but also, having them running Javascript that's not what the site owner intended.
In fact that's exactly how China attacked GitHub recently: https://threatpost.com/github-attack-perpetrated-by-chinas-g...
Your browser might flag a http server as dangerous (mine doesn't - it just has a padlock with a line through), but you're leaking information to your ISP that you are reading about a Physical Therapist.
If your site tries to do https and fails (self signed or invalid certificate) it will rightly flag up that it's a problem.
My grandma would not be able to manage a server on the internet, let alone responsibly manage it. If you can't set up a modern server with https then you shouldn't be running a server on the internet at all.
Thank god we moved on from that.
https://tools.ietf.org/html/draft-ietf-tls-esni-07
I can't find the example (it was linked on HN a few years back), but a clear demonstration of this is a case where the MITM can serve a phishing page that initially appears to be the original site you've hijacked (so the user trusts it, and leaves it alone); but later, while the page is not visible (for example, when the user switches away from that tab), the page will switch over to showing a Facebook login screen or something.
Since the website isn't a known "malicious site" (so no alert from the browser), the user probably won't bother to look at the URL bar. They'll just think they left Facebook open in a tab, and it logged them out for inactivity. So they'll "log back in."
[1] https://news.ycombinator.com/item?id=24711111
EDIT: what are the downvotes for? If for disagreement, this only shows how poorly people misunderstand security of https.
> What danger could possibly happen if I'm reading about a Physical Therapy clinic?
Depends what is a "danger" to you. Your insurance learning you're having issues and deciding to increase the amounts you owe them, because they saw that your back is aching, is definitely a problem.
> But unless the Physical Therapist knows how to manage the server, they get this scary warning.
Wrong. In 2020, if the Physical Therapist can have an http website, they can have an https website with a valid certificate.
It's the same for your grandma store. Going from no website to http is a much much bigger step than going from http to https.
The real danger I see is the disappearance of lots of quality, not-for-profit content that reminds me of the good old Internet, swapping it with new shiny https publishers, of which 90% belong to the same owners. That's the real danger to the society. The long tail is disappearing, while commercial interests, and the manipulation that comes with that sneaks in everywhere.
This ship has sailed, though: “plaintext HTTP” is available only with HTTP/0 and HTTP/1. This article is discussing HTTP/3, which carries forward the requirement of wire encryption that HTTP/2 argued over for a long time and then incorporated into the standard.
(Incidentally, my grandmother was a Smalltalk and 6502 assembly programmer of educational software in the 80s. She let me read her technical books at age 5. Probably best to find another example, such as “non-technical site owners”.)
Also note that because http:// and https:// are different schemes, there is no requirement that they serve the same website. http://example.com/foo and https://example.com/foo could be completely different resources, or completely different websites. An opportunistically encrypted load of an http:// URL still needs to load the http:// website, not the https:// one. Though opting in to HSTS eliminates this distinction.
For that matter, HTTP/1.1 allows full URLs to be specified in the request line, as an alternative to the traditional "Host" header. This is usually only used when using HTTP proxies:
but what is interesting is since this also includes the scheme, it potentially allows you to do something very peculiar: theoretically you could access an https:// logical resource over an unencrypted HTTP/1.1 connection, e.g. by telnetting to example.com:80 and issuing "GET https://example.com/foo HTTP/1.1". It would of course be insane to support this, but if one disregards the fact that https:// is supposed to invariably imply secure communication, theoretically even https:// resources could be loaded unencrypted, just as http:// resources can be loaded encrypted using opportunistic encryption.In short: scheme and protocol are different things, and for good reason.
URIs are resource identifiers. They exist to identify a resource, not how to access it. Tying those resource identifiers to a means of resolution would unnecessarily couple it to a resolution mechanism and thereby reduce the universality and permanence of URIs. URIs which are URLs are closer to describing a means of access but fundamentally there's still an interest in providing enough degrees of indirection that the longevity and permanence of an URL is maximised.
Come on. Networks are extremely FAST by now, TCP or not. It's the silly amount of JS computation pushed to the client that is slow, both in download speed and on the client.
They call this HTTP3, and they shouldn't; it's not HTTP.
If there's a general tuning problem in TCP implementations, the cycle time for getting it fixed should be around 2 years from discovery to all regularly updated machines getting the fix. Given global impact, that seems pretty reasonable to me.
This is all based on my brief reading of the QUIC Wikipedia article, so take my knowledge with a grain of salt, but I think that my above summary fits.
Wikipedia at relevant anchor: https://en.wikipedia.org/wiki/QUIC#Background
UDP packets have checksums, its what network switches use to check before sending the packet on or dropping the packet.
Other benefit is UDP doesn't have a window size (buffer). Which is part of the design when computers had ram measured in K instead of GB (Hey my buffer is full, stop). The chatty nature of TCP reduces download speeds across larger physical distances. Its why download managers spin up multiple threads to download part of a file to work around it.
IIRC even UDP isn't ideal, the reason for choosing it over making a brand new protocol was to avoid network devices like routers dropping packets that they wouldn't recognize.
WebSockets is just an abstraction over a reliable protocol (TCP), therefore, WebSockets could theoretically work over QUIC too.
Unfortunately today's internet has needed to be a continuum of newer stuff that still has to work with the older stuff. Such is life.
- SSL and "TCP" handshake are collapsed into a single transaction
- That transaction is worst case 1 network roundtrip, best case (returning user) 0 roundtrips
- Anti-filtering baked in. Quic reveals almost nothing for middleboxes to filter on. There is not yet an accepted solution for encrypting the target server name (SSL SNI) but that's still being worked on AFAIK
- "Modern" congestion control approach, where "modern" means "fuck any TCP connections sharing the link"
QUIC is basically HTTP2 (bidi frames and keep-alive connections) over (TCP over UDP) with encryption builtin. The cool thing about QUIC also, is the ability to 'lower down' to the UDP layer and skip the control and encryption protocol if you need it. (I just dont know if they will extend this feature to the application level).
WebRTC is SRTP with UDP have hole punching et al. if you want so use UDP but with a whole problems of the UDP approach P2P world already taken care of.
WebSockets works over plain TCP.
QUIC is the more advanced of the protocols and it will probably "take over the world" with time, but it has yet to prove itself.
It probably can be a good fit to the cases where the WebRTC is being used for, but i dont now if Chrome will be ambitious enough to let developers mess with the building blocks of QUIC. If not, it will just become a sink to HTTP3 (a no small feat anyway).
But, if I had to pay the electric bill on 2.5 million servers, I would definitely care about wasting resources sending extra packets.
It's a micro optimisation that won't even register for your users, especially if you're reducing latency on 2mb of JS bundles
Until there is dedicated hardware NICs I think you would find HTTP/3 has worse latency. That is until dedicated NIC accelerators come out on the market.
And I guess I am not the first person to wonder about this, any people wanting to share a bookmark/url, tia (so I don't have to use google... ;) )
So if you're hosting via some accelerator like Cloudflare, AWS API Gateway, whatever Google has in this space, or app host like Heroku and friends, they'll happily do the work because they get the aggregate benefit. Your own site will become marginally faster or have happier roaming users, and so on, essentially for free.
When you're developing a generic website, I don't think you should care about this. When you're self-hosting, you can decide if it might be worth it or not. It probably won't be worth the effort unless you're doing something really intricate or special, in which case you'll be really happy that you have the option.
The numbers include total application latency, not just the latency introduced by the network, so the improvement to the network latency is larger. As such, applications that are more sensitive to network latency would show larger improvements.
Thanks, Ian
Disclosure: I authored the post
Another benefit that isn't measured in this post but has been mentioned elsewhere in the comments here is that the experience on flaky wireless connections (without changing IPs) should be much better. TCP was designed on the premise that packet loss almost never due to physical failure to transmit a packet, and almost always due to routers queues being full (i.e. network congestion). Wireless networks violate this assumption badly: physical-layer issues are the most likely cause of packet loss on a wireless connection. TCP reacts to wifi packet drops by backing off, assuming that some router is overloaded, but the routers are fine — it's just last hop signal that's bad. In those circumstances, the client should just try again instead of throttling the connection to nothing. Since HTTP/3 uses UDP, it can potentially handle dropped packets more appropriately.
On your second point, it's configurable how TCP reacts to packet loss. For example, wasn't BBR congestion control made to address exactly that case?
Switching between cells will cause a latency spike, and a lot of correlated packet loss if the subscriber has a large queue of undelivered data, but that's all. But handling packet loss and ordering are what TCP is supposed to do.
I have no idea of what you mean by "the TCP connection is no longer there". The TCP connection is a distributed system living on the client and the server. It doesn't go away unless one of the endpoints decides so. (Modulo stateful middleboxes, like NATs. But nobody in their right mind would run a TCP state-aware middlebox on a cellular network base station).
IP changes are relevant when switching networks entirely, like going from WiFi to mobile.
One type of roaming that does trigger for smartphones and similar devices is WiFi->4G/5G->WiFi.
You're at home, obviously you don't want expensive mobile network data charges when you've got WiFi. So the connection is over WiFi. But as you walk out the door, currently your application software needs to spot that the WiFi is going away (not too hard), connect over the mobile network (unless your policies say to give up instead to save money) and keep going. QUIC would allow this to be done transparently at the transport layer, at least in some cases. When you reach a coffee shop/ friend's place/ work and there's WiFi again, the opposite transition saves you money and if you go indoors and signal is weaker may also be necessary to deliver a working network.
TLS 1.3 and ESNI are already seeing blocking because middleboxes don't understand it.
Have there been any leaps in Firewall tech, or will most companies still disable this?
QUIC is explicitly designed to frustrate this sort of thing, so the enterprise will just have to choose between having and not having it, or switch from MITM to endpoint backdoors.
What you end up with is two connections. A connection from the browser to your product, and then a connection from your product to the web site. Your product is in the middle and can apply any policies whatsoever that it desires.
There are two things about this that vendors do not like, or which their customers do not like and the vendors would prefer somebody else take the blame for not them.
1. For this to work the browser needs to trust the product. The product will need to mint its own certificates for each site visited, and it can't make genuine ones, so it'll need to be explicitly trusted by the browser. This requires more honesty from your customer (the product's operator) in regard to their users (employees / students / visitors / whatever) where previously a product might try to snoop unobtrusively. That's no longer an option.
2. Actually doing all this heavy lifting costs money. More CPU power, more RAM, even more network bandwidth because you can't just snoop a few frames at the start of a connection you need to proxy decrypt/ re-encrypt every single byte even if you realised very quickly that it was actually fine. This makes the product more expensive, even though it's also worse because their users ask awkward questions now.
- 0-RTT handshakes are great but there’s still the problem of slow start.
- QUIC’s congestion control mechanism is pretty much the same as TCP’s and doesn’t perform particularly well over e.g. mobile networks.
- Mandatory TLS means it’s going to be a huge PITA if you ever need to run a quic service locally (say, in a container).
- Having it in user space means there’a a good chance we’ll end up with 100s of implementations, all with their own quirks. It’s bad enough trying to optimise for the three big TCP stacks.
Let's Encrypt!
Sure, you can get anything to work, but it WILL be a huge PITA.
Unless your cron script is doing some funky DNS altering, that is.
[1] https://github.com/go-acme/lego [2] https://go-acme.github.io/lego/dns/
I would totally be down with say, the US government issuing citizens with a DNS name under their ccTLD somewhere. Done your tax paperwork in reasonable time? Your name is guaranteed by law to keep working for another year. Maybe 1480219643.ny.citizen-names.us is ugly but it'd satisfy this problem for individuals. Maybe they could bolt on a checkbox, $50 extra to the IRS and you get to pick any as-yet unreserved legal name, or they have rules like for license plates.
No, it wouldn't, because that involves interacting with the public DNS hierarchy.
> you shouldn't need to buy a domain to do stuff locally on your own device [emphasis added]
There are also free dynamic dns providers that let you set txt records and get certificates. But of course you can't depend on one of those to last forever.
1. have the domain in question resolve to a server with a public IP
2. have that server generate the certs with any ACME client with HTTP challenge
3. have that server ship the certs to the actual server hosting the service via intranet
4. in the intranet, have the domain resolve to the actual server via /etc/hosts override
All of that is not that hard to set up even at scale with proper config management tools. Having said that, I don't actually use it for that many services myself. The most significant one is LDAPS.
I have a wildcard certificate for *.local.example.com (and local.example.com), and a local DNS server which resolves all the subdomains of local.example.com.
All local servers share the same certificate and it gets refreshed automatically every 2 months. local.example.com has a public NS entry to a custom nameserver which only exists so that letsencrypt can perform the DNS validation for that domain (and its subdomains).
This way I can use server-1.local.example.com, server-2.local.example.com, workstation-1.local.example.com internally with TLS.
Head-of-line blocking is only a problem if you’re multiplexing connections. Just open one TCP socket per request and you’ll never have head of line blocking. There are issues with opening multiple TCP sockets of course (mainly Slow Start) but these aren’t insurmountable.
They’ve already proposed adding HTTPS and SVCB DNS records for performance, it would be easy enough to implement a ICANTAKEIT record that lets the browser know it’s OK to open as many sockets as it needs.
And there's other reasons you wouldn't want to use as many connections as you have assets to download; each connection has startup overhead.
What happens when your ping time is >500ms?
> was that the performance overhead will be zero
I think QUIC is motivated by Google's expansion into developing markets (China, India, etc). These areas are primarily mobile markets that would like to consume the same content we do. What might sound like small overhead (SYN->SYN-ACK) actually takes half a second. If your performance is measured in this way than N connections times half a second is a long time. And, on mobile networks, sometimes your TCP connection will drop even if there's still data being sent back and forth (some times you can see latency spikes up to 3sec on really bad networks which causes most software to timeout since it thinks no data came in because of head-of-line blocking).
It's a truely miserable experience that QUIC or HTTP/3 can easily solve. Imagine how slow an `apt update && apt upgrade` is and how much of that overhead can be dropped by connecting to 1 mirror a single time and bulk requesting 10 to 100 file transfers. This allows you to maximize your network throughput. Think instead of how slow this would be if you opened 10 to 100 connections each of which might take 500ms per startup. In the worst case that's a 500ms penalty versus a 5 second penalty.
Actually, that's not a problem with one reused connection versus N simultaneous connections (as coddle-hark said, the connections are made in parallel). It's a problem with how many round trips it takes to set up each connection.
Games can now also be built over a REST-like API using separate channels for different priority messages: movement, world state, chat, etc. Since you don't need to worry about blocking you get way better performance. Almost every game engine networking component essentially implements TCP-over-UDP just to get application level control over these functions.
Dev and prod should be as similar as possible anyway.
But like... why?
It's also one of those things that once you sort it out it's no longer a problem. Like "why do I need to setup all this complex stuff to manage a dependancy? Just give me your source code and let me `gcc -o binary a.c b.c ....`"
In reality once you solve a problem with an ergonomic solution and the solution improves your alignment with production and comes at no real cost it's a win/win/win.
https://blog.filippo.io/mkcert-valid-https-certificates-for-...
https://github.com/FiloSottile/mkcert
More importantly, I don’t think it’s a good idea to teach people to add self signed certs to their certificate stores willy-nilly. Seems like a good way to get pwned.
HTTP/2 also allowed this, but suffered from head-of-line blocking between those multiplexed connections. Quic streams are independent. One Stream can still make progress if datagrams which contained data for another stream got lost.
For a lot of systems the TLS handshake is the most expensive part of an operation. Reducing the amount of TLS handshakes by N can literally reduce cost by up to N in those systems.
HTTP/3's WebTransport (i.e. gRPC + sessions) defines a Session far more logically than a TCP Connection + your ad-hoc in-application Session does.
The predecessors of WebTransport already appear every everywhere in low-latency and realtime networked applications, like games, chat and video, on mobile devices. Typically that is achieved using UDP + an ad-hoc session management and authentication protocol. Or worse, undoing TCP connections and managing sessions on top of TCP connection breaks (as most dual web + native applications do).
Why reinvent that clumsy stuff over and over again instead of having it standardized? TCP is already dead on mobile, for many of the most popular applications people actually use.
Why? One of the main intends of QUIC is imho to be better in this scenarios. E.g. by handling retransmission and loss detection in a different fashion than TCP.
[0] https://quicwg.org/base-drafts/draft-ietf-quic-recovery.html
And it might also have a bit more flexibility when to retransmit (but I'm not an expert).
Big QUIC implementors have all used the interop runner, intended to prevent exactly that:
https://interop.seemann.io/
And it’s open source: https://github.com/marten-seemann/quic-interop-runner
"U.S. House's antitrust report hints at break-up of big tech firms: lawmaker (reuters.com)"
https://news.ycombinator.com/item?id=24697860
They could have shut off a large portion of IIS traffic to those that weren't running Internet Explorer.
I guess they failed because they were too late to the web - Netscape ate their breakfast.
https://www.metzdowd.com/pipermail/cryptography/2002-June/00...
https://wiki.c2.com/?MicrosoftPalladium
The crown went from NCSA to Apache and then only recently to Nginx.
But more generally companies have written up IETF paperwork for other protocols. Lots of Microsoft protocols have RFCs for example. But one thing that's less common is actually engaging with full-blown IETF working group standards development like Google did here, as opposed to just saying "Look here's the protocol we built, you can use that, or not". The IETF is totally happy to accept what I guess you could call a "donation" of that sort, and it's much less effort. Maybe you take some internal documents, you reassemble them into the rough shape of an RFC, you publish that draft, you get a bunch of feedback about that document, focused on clarifying the explanation, making sure you cover everything required, and so on rather than altering the protocol (which you've maybe already actually shipped in a product) and after maybe 6-12 months you've got a polished RFC ready to publish.
If you use a work VPN for example, or a corporate WiFi network that's not just a few home WiFi routers with a more professional SSID and password, you probably end up using protocols Microsoft "donated" in this way, like PEAPv0/EAP-MSCHAPv2 - these protocols are awful but there was no multi-step process where other vendors improve on it and then they eventually reach consensus and publish. Microsoft shipped products that do MSCHAPv1, then wrote it up so that other products could interoperate with Windows, and when they made MSCHAPv2 they followed the same path.
Look at LetsEncrypt: A Google initiative. Yet 25% of the world’s websites use it.
No. Let's Encrypt is a service of the Internet Security Research Group, a California Public Benefit Corporation, it isn't an "initiative" of Google except in the same sense that the Red Cross is an initiative of Google, or Sweden is a US state, to make it seem "true" you need to squint so hard you can't see anything properly at all.
how does this increase their control?
I guess both can be true.
Right now it's possible to selectively block client activity on your network (your smart TV snooping or showing ads) but that's going to get much harder in the future. You'll have to chose all or none when it comes to clients.
And it's all done under the guise and blessing of "privacy". It's really a bleak future for the web.
Sorry, I went on a bit of tangent. But to answer your question: HTTPS makes it incredibly difficult to introspect and alter content that is flowing through the web and your browser. Allowing a user (and his ISP if done correctly) to easily at the network level alter the content, one can do all sorts of magic that we haven't even begun to explore because it's effectively impossible.
The big usage of this would be ad-blocking and removal. At this point the two biggest ad-blocking mechanisms we easily have available are: DNS-blocking of ad servers, and add-ons/plugins that are allowing introspection of the data on the web pages visited. Both of those avenues are being attacked. Add-on APIs and capabilities are being neutered in little bits and pieces both on Firefox + Chrome. And DNS is being attacked with things such as DNS over HTTPS (again under the guise of privacy).
Not to mention that even SSL certificates that allow MITM for the user are being attacked by initiatives such as embedding SSL certificates into binaries, and certificate pinning (which luckily seems to have been abandoned).
We need FOSS/Stallman-level activism and wars against this stuff that is eating away at the rights we have over our own hardware. Whatever you call this issue, it should be right up there with "right to repair", "own our own data", "right to be forgotten", etc.
Edit, wrong acronym.
I have a MITM proxy on my network that strips ads, rewrites pages with custom stylesheets, and all that across every single device connected to it, and it's hard but not impossible to set everything up, and they are only trying to make that harder.
I agree with you completely, except for "right to be forgotten" --- which tends to become interpreted more as a "right to rewrite history".
"Those who give up freedom for security deserve neither."
I'm using firefox
If you’re comparing it to HTTP/1.1, the performance improvements are generally a lot better than that. The latency improvements are commonly something around that, but the total page loading performance will tend to be better because you get proper multiplexing.
But then you may say, why do we need this instead of HTTP/2, which had proper multiplexing? Well, it improves things a bit further, commonly improving throughput and latency by 1–10% if I’m recalling the right figures; but more importantly, it fixes the TCP head-of-line blocking issue that made HTTP/2 often actually perform a lot worse than HTTP/1.1 on low-quality connections.
I know of sites that have held off on HTTP/2 or rolled it back because it made things measurably worse for some users, and of sites that split things across domains with some HTTP/1.1 and some HTTP/2, deliberately, purely because of the TCP HOLB issue. HTTP/3 fixes that, so that it should no longer be a question of whether you make things faster for some users at the cost of others—you can instead make it faster for everyone.
I'm curious with the multiplexing improvements if we'll see greater performance gains in the long-term as we changed how we package and bundle JS.
I've seen a significant improvement in general page performance using Webpack's chunking, where it automatically breaks up each of your components into smaller .js file and only loads them if the page uses them (basically on-demand async importing of JS files that were preprocessed with webpack).
It went from loading one giant blob of JS on every page into one primary JS file (about 25% smaller) + a bunch of tiny 1-10kb .js files that load async. A typical heavily interactive page would load 5-10 of these async files.
There's probably opportunities to go even further in breaking up the primary file (which handles the logic of which JS components to load + includes the Vue/whatever framework and other JS dependencies).
I understand the utility of "loading once and caching" stuff but for serious JS-heavy frontends the bundled JS files becoming extremely bulky (sometimes in multiple megabytes due to legacy dependencies) and ideally you'd minimize that always-cached part as much as possible.
Also very confused at how we’re spinning HTTPS as a bad thing now? Cloudflare and Lets Encrypt did significantly more for HTTPS adoption than Google anyways... and it is a bit preposterous that it is somehow being spun as a negative. It’s about security as much as it is about privacy...
(I am a Google employee but speaking entirely in a personal capacity. Additionally, I do not work on Chrome or QUIC.)
On the other hand, on a typical secured WiFi connection over TCP over an Ethernet connection, like 10 times more complicated stuff is going on in protocols and the software stack. It’s not as if we went from bit banging HTTP directly down an Ethernet cable to a hopelessly complex stack of software; we just added another element of complexity at the application layer in exchange for real security and privacy benefits. Example.com doesn’t need it but it has become a best practice for good reason so it is used on most of the net even when not strictly necessary.
Enforcing HTTPS is a best practice because an absurdly overwhelming majority of user agents, like 4 or 5 nines of them, support HTTPS and the redirect ensures they use HTTPS and makes downgrade attacks a little more involved.
Over the past decade I've helped maybe 100 small businesses set up internet presence, and I promise you none of them understand https or set it up correctly at first, despite often paying for it from hosting providers like Godaddy.
This isn't the fault of the engineers behind implementing it; it was necessary of course. But if the web were a perfect authoritarian regime we could have just saved us all the headache and dropped http altogether, thus avoiding this bureaucratic protocol redirecting mess.
I would be very interested to read about why that was not done actually. (I'm sure there were reasons)
> the following second level domain names reserved which can be used as examples.
> example.com
Existing protocols like TCP and TLS are not really simpler than QUIC, you just don't think about them because we have implementations of them already. However, _changing_ TCP and TLS is extremely difficult to impossible because middleboxes snoop on traffic and mess it up in various ways. As an example, multipath TCP has been engineered to look like regular TCP and automatically downgrade to regular TCP if middleboxes can't handle it. Making this work is hard and 100% a waste of time just to work around the fact that people deploy these boxes. I believe TLS 1.3 also had deployment challenges due to middleboxes.
QUIC encrypts ~everything so that middleboxes can't make broken assumptions and manipulate traffic. Adopting it is a one time pain that enable later improvements to be possible.
There was about one year delay between the point where the protocol was initially "done" and experiments showed it could not be deployed partly because of middleboxes although also due to server intolerance (web servers that go "What? TLS 1.3? No, rather than negotiating TLS 1.2 I'll just ignore you and hope you go away you weirdo") - until the point where the revised TLS 1.3 wire spelling was finished and tested (about six months before it was published as RFC 8446)
The core idea in TLS 1.3 as shipped is that the initial setup phase looks outwardly very much like TLS 1.2 resumption. Interpreted as if it was TLS 1.2 the TLS 1.3 client claims to be trying to resume a previous connection, a TLS 1.3 server claims to accept that resumption, but really they actually just agreed a brand new connection. A TLS 1.2 server would see the resumption attempt, but it has no memory of any such prior connection (there wasn't one, the "connection ID" is just random bytes) so it offers a new one using TLS 1.2 and everything goes swimmingly.
This way of doing things allows TLS 1.3 to be as fast on first connection as TLS 1.2 was on resumption without causing problems with incompatible middleboxes or servers. It does make the "spelling" on the wire pretty weird looking though if you are used to looking at TLS 1.2.
The other essential goal was to never back off. A TLS 1.3 client will never go "Huh, TLS 1.3 didn't work, let's try again with TLS 1.2 instead". The design means if the remote server can speak TLS 1.2 (or 1.0 or 1.1) it will respond as such to your TLS 1.3 connection. This means adversaries can't try to "downgrade" you to a bad older version.
You control your computer - and want to mess with network traffic, make your own CA. Its not that hard.
It is possible to use HTTP/2 without HTTPS, but the problem is that there were a lot of systems that modified unencrypted HTTP traffic and got confused by HTTP/2 protocol - it looked nothing like HTTP/1. The easiest workaround for this issue was to require HTTPS, so that's what was done.
Also when HTTPS is being used the server can say during TLS handshake that it supports HTTP/2 avoiding the cost in having to figure out whether the server supports HTTP/2 - this cannot be done with HTTP as there is no handshake. If a web browser were to assume the server supports HTTP/2 it would make initial HTTP/1 requests slower as it would have to try HTTP/2 first (and then you would have people complaining about Google making HTTP/1 slower to make HTTP/2 look more attractive). If a web browser would say that it supports HTTP/2 it would make HTTP/2 requests slower as it would have to try HTTP/1 first (which would slow down HTTP/2 when it was supposed to be fast).
I don't think this is a good idea... about a decade ago... as a research project I ran honeypot farm of 13 machines to learn more about malware. The honeypot machines were autonomously surfing the net, parsing the DOM and choosing random links. I ran them in a sandbox and was getting weekly malware hits.
Much to my surprise... most of the malware was coming over advertisement networks on shady websites.
The only downside to this is that rogue IoT devices or hacked IoT devices can easily get around DNS filtering, but that was already possible before DoH by using or running some benign free public http api for dns lookups.
0: https://i.judge.sh/hollow/Lyra/chrome_hxURk11GDb.png
1: https://i.judge.sh/bony/Fleet/s4HD5OqNvf.gif
Why? The user agent will still be able to choose what to display, and protocol improvements don't prevent you choosing an agent that has your interests at heart.
Using secure transport means nobody else gets to decide, and I certainly have a long list of people I don't want deciding whether I see things, so that helps.
Well, that's a depressing sentence to read. The vultures may be circling, but Firefox isn't dead yet.
I don’t like this any more than you, but it’s the truth.
- doesn't update via a sketchy background process (Google Updater, or whatever they've renamed it to this month to avoid scrutiny)
- allows me to customize the UI to fit my needs (tree style tabs are an absolute must for me)
- allows me to use a full ad blocker like uBlock Origin instead of arbitrarily limiting the ad blocker API to advance the interests of advertisers
Of course, Firefox's management is an enormous problem, from the way they've prioritized features to the recent layoffs to the enormously stupid decisions (letting a certificate expire that disabled almost all add-ons, the Mr. Robot tie-in "experiment", pushing pocket, default disabling userChrome.css, forcing auto-updates) they've made in the past 5 years. But the core of Firefox is good.
I would love a startup that builds an entire business off of a fork of Firefox that's completely based on privacy, perhaps with some non-invasive monetization like:
- a $5-20 one-time fee to use (with weak enforcement, a la Sublime Text's "annoy you every 5 saves" model)
- a paid vs. free split where the free version of the browser adblocks ads but replaces them with in-network, verified safe ads
- Linux kernel donation-style only model, with no parent corporation
Because of all of the Firefox devs floating around who just got laid off, you could even snatch up some guaranteed capable talent already familiar with the code base. And the best part? They're already vetted to not be part of the management-industrial complex that's taken over Firefox these days.
It's enough of a skew that when rendering errors crop up, product managers have to decide how many eng-hours it's worth to chase down the small implementation difference between Chromium and Gecko to snag 1 in 10 potential lost visitors, instead of throwing a UA-sniffing "best viewed in Chrome" banner on the page and calling it a day.
Being a rarely-used browser is a negative feedback loop for compatibility, regardless of what standards say (because standards are often too loose to guarantee full interoperability in all corner cases; they rarely give performance constraints and often don't consider all possible combinations of feature use).
Don't know if this is 100% accurate, but Tor?
You probably meant "Tor Browser". Changes from there were backported, and last time I checked plan was to have it entirely backported within Mozilla Firefox.
your ideal privacy focused firefox comes with a conflict of interest built in
I thought it's unmaintained since the recent Mozilla layoffs?
[1] https://github.com/Eloston/ungoogled-chromium
We're literally discussing this on a post where Chrome is switching from a proprietary protocol (Google QUIC) to a standardized protocol (IETF QUIC).
(Disclosure: I work for Google, speaking only for myself)
What websites are Chrome-only?
As an early Linux user, I still remember running a Windows VM with IE installed, for years, just to do online banking. Heck, at my current corporate job all the Mac users (mostly the web designers) are given VMs to run IE11 to fill out their timecards, and use product management software. This is absurd, but real.
I'm no stranger to having to use VMs to do basic stuff online, but not everyone else is. And, to be honest, no one should have to set up a VM to use a browser they cannot trust, just to protect themselves from stupid drive-by malware.
This is the real clincher - websites discriminating against Firefox often don't know why. I assume it's because they don't want to be liable for using their software on a browser they haven't tested on. Or it's just the good ol' Google search on Firefox mobile thing, i.e. "we'll gimp it for no particular reason!"
So if you now want to spoof as Chrome to your bank, you spoof as Chrome to all websites.
Rather a foot-gun from Mozilla but on par for their recent choices.
But I do think it makes much more sense to make the browser just do the job directly, rather than delegating that to a separate device.
Firefox continues to block ads just fine, and it'll keep doing so in a QUIC world, while protecting me even more from malicious local DNS servers. The average person is much more likely to encounter a hostile DNS server than a "helpful" one.
I'd much rather take away the choice to screw with what I see from my ISP.
Encryption is what allows user choice rather than leaving you at the mercy of your ISP.
Google only ever shows you ads you want, never "unwanted content". Are you suggesting Google could do even better if they just knew a little more about you?
I'm not saying I'll be giving them unfettered access to my browsing habits so that they can give me some perceived monetary benefit in return. But even if that were the case, so long as they didn't do anything fraudulent or violate my privacy by giving my personal data out, then I'm 100% fine with it. This is no different than Google having algorithmic access to all my personal emails. Once we figure out the two scenarios are the same, we'll quickly realize this whole "protect me from my ISP", "privacy" movement is just a front for taking away people's right to control their own hardware.
I choose Dillo or Netsurf. Now how can I still use sites it can't even render because the developers have drunk the Google-aid and used some trendy framework that requires the latest version of Chrome and JS just to display some static text and images?
Fuck Google and its creeping control over the Internet.
Once these practices become sufficiently spread, the majority of developers and content producers will never understand that an alternative is possible.
Or maybe he will need it: those same developers can perfectly be contractors for a government agency whose site the user has to access.
Trends slowly creep everywhere, independently on technical merit.
It's mostly radio buttons (with a loading screen and a pile of js/css to make it pretty of course.) You fill it out, click submit and a matching suit gets shipped to your house. I couldn't get some of the controls to work and sent the support people an email. It turns out the form they built uses some special chrome only API and doesn't work in Firefox.
Ditto when I submitted my rental application for my current apartment (how can you screw up a single page with a file form that badly?)
The trends are definitely going the wrong way.
history repeats itself (or more exactly we humans repeatedly step upon the same pile of stuff) Back then it was IE only APIs. Those APIs of course were for better and richer functionality and user experience. And we all know how it ended.
Will it? Even on Mozilla Firefox (which fewer and fewer sites are tested against) you're pretty limited in controlling this. I have zero faith that google will keep that working in chrome
Admittedly sites could switch to rendering everything in JavaScript using canvas or WebGL. But so far no one is resorting to this, because you have to effectively reimplement big chunks of the browser. Maybe one day there will be a JS framework that does this, but then it will be easy for adblockers to target that specific framework.
Isn't one of the biggest advantages of ad blocking that it can cut your bandwidth use? I mean, if you aren't going to show the ads, why download them in the first place?
In the end, limiting IFrame depth would probably do more than many things for stopping some of the bad actors.
I use uBlock Origin and EFF Privacy Badger for most surfing, which does a decent enough job. I don't think that the enhancements to the protocol really do that much... though I also don't know that some of the tradeoffs are worth losing a human-readable protocol.
Of course, this makes it more annoying to deal with user-hostile user agents such as some kinds of appliances and other locked-down devices; in which case I would suggest "don't buy user-hostile devices".
Such as the Chromebooks many on this site like to rave about.
Ad blocking extensions are really a "last defense" and can be slowly lobotomised as they are under browser vendors' control.
HOSTS files may also be simplest (I totally disagree btw), but I can't imagine they're anywhere near the most common.
That's exactly how DoH is being implemented, and it's why it has caused so much controversy.
That is correct, the IPv6 probes are embedded in the Chromium source, and are removed by the Ungoogled Chromium and/or Inox patchset [1].
[1] https://github.com/Eloston/ungoogled-chromium/tree/master/pa...
That's also a major difference to Ungoogled Chromium, where UC will request "https://..." by default if you just enter the domain.
So in the case of Enterprise Proxies that have no locally force-installed cert to sniff on internet traffic will likely end up with HTTP-everywhere being used. But usually employers that encourage such bad practices also install their snakeoil MITM certificates locally.
0: https://i.judge.sh/chief/Spoon/notepad_fwyvP8v6li.png
1: https://docs.pi-hole.net/guides/dns-over-https/
You might be thinking of the HTTP server push functionality. That was introduced with HTTP/2 and has been deployed for years already over TCP transports (i.e. totally unrelated to QUIC).
Due to how advertising networks work, I'd be surprised if anyone used server push in the way you fear.
there is such a poisonous mentality that has taken root, that is popular. no one at the ietf shares these delusional fears, & it's not because the ietf is a bought out shadow puppet. it's because in reality http3 brings what http2 brought but technically better which brought what http1 brought but technically better.
Did you have a good look at how the internet evolved in the last 15 years?
The IETF can invent HTTP/23 with DNS-over-whatever tomorrow, that doesn't change anything about the general state of the internet, which can best be summarized as a "burning pile of poop".
Do you really need any examples of how broken everything is? Do you really wonder that people have "grimdark fantasies" about what the "next cool web feature" will bring to us?
It's about HTTP/3.
You will lose performance, but you’ll gain control.
I don't think we'll ever have unblockable adverts. It would give users a huge incentive to change browser. Google get a great deal of value from people using Chrome and I don't see them giving that up just to serve ads to people that want to block them.
More information here: https://discourse.pi-hole.net/t/how-do-i-block-ads-on-youtub...
And better tracking. In DoH RFC [0], 8. Privacy Considerations, 8.2. In the Server:
"HTTP's feature set can also be used for identification and tracking in a number of different ways. For example, Authentication request header fields explicitly identify profiles in use, and HTTP cookies are designed as an explicit state-tracking mechanism .."
"Determining whether or not a DoH implementation requires HTTP cookie support is particularly important because HTTP cookies are the primary state tracking mechanism in HTTP. HTTP cookies SHOULD NOT be accepted by DOH clients unless they are explicitly required by a use case."
I will stick to DoT.
[0] https://tools.ietf.org/html/rfc8484
Also, it isn't like one couldn't be tracked by DNS resolvers without cookies: https://news.ycombinator.com/item?id=20219878 and https://news.ycombinator.com/item?id=19828702
I cannot imagine it happening, it has to be blanket ban. Real life examples, excluding China?
> tracked by DNS resolvers without cookies
Thats Very clever :)) Safari fixed similar thing that was using HSTS, but I bet they'll kill this one too.
I'm sorry but this is very much going to happen since nearly 1B Androids are now DoT capable. ESNI may also be blocked for same reasons once it is widely deployed.
> Safari fixed similar thing that was using HSTS, but I bet they'll kill this one too.
Safari cannot cover for apps sending DNS requests.
That's prediction, not facts I asked for.
DNS-over-HTTPS can actually be useful. I can do bulk DNS lookups from DOH servers using HTTP/1.1 pipelining, retrieving thousands of names at a time over a single TCP connection. I can look up every name for every HN item in one go, store this data in zone file served by a localhost DNS server and generally never have to use remote DNS when browsing HN. This makes for fast browsing with a text-only browser.
The issue I am surprised more people are not raising is the decision of Google to encourage Golang developers to use a "built-in" DNS resolver in their applications rather than relying the system resolver and submitting to traditional user controls like resolv.conf, nsswitch.conf and HOSTS. Regardless of the motivation behind this choice, IMO it tips the scales toward developers instead of (non-Windows) users in terms of ease of control over DNS lookups, not to mention the privacy issue (shared by DOH) of enabling a third party DNS provider to segregate lookups by device.
I don't see them even when searching for commercial things, so I guess they are blockable (I just have uBlock Origin).
Is that built-in resolver somehow configurable? (env vars?)
Firewalls can't block this because then you introduce a denial of service vector. If I can block anyone on the Internet from accessing a service because the service's firewall blocks the source IP... this is why this isn't a solution for dns and other udp protocols' amplification attacks, either. Otherwise we'd block offenders and be done with the problem of amplified DDoS attacks really quickly. The problem is allowing legitimate clients to pass that look (nearly?) identical to what the attacker sends. The STK seems to solve this (in a similar way to TCP, while allowing for 0RTT after the client met the server once), so let's use it?
Edit: just noticed you posted another comment critical of QUIC. To be clear, this isn't "QUIC is amazing, let's use this STK and it'll be great". I don't know enough about it for that. Heck, I like the textual property of HTTP/1 and would be fine keeping that as well. I just noticed this security problem with HTTP/3 and would prefer to see it fixed before widespread deployment given how heavily similar services are abused.
There are too many broken machines on the Internet that can't deal with anything that isn't TCP or UDP.
QUIC is disabled on our corporate network, simply because the network firewall/SSL inspector can't see what's going on, and can't regulate traffic, so it just blocks all UDP. our internet still works because sites see that QUIC doesn't work and fall back to TCP. Heaven forbid the entire web moves to QUIC or we'd be in trouble.
The whole way this debate is going irks me. It's like there is two camps: those who think all the world is smart phones being used by people way out in the desert and everyone else. There are lots and lots of devices that have high speed, low latency connections. The people that use those devices are people, too. We should not over optimize for the remote smart phone user over everyone else.
But I get it. Security and Privacy is really only about ‚compliance‘ and legal protection for large corps.
1: connections management + encryption
2: streams and multiplexing
Seems pretty good to me?
Besides that the crypto and handshake parts also need streams with guaranteed delivery and ordering, since they carry TLS stream data.
But QUIC Datagrams do have ACKs, and don't have retries. Maybe we don't want them to have ACKs, but as long as it's opt-in, is that not enough for the upper layers?
> Besides that the crypto and handshake parts also need streams with guaranteed delivery and ordering, since they carry TLS stream data.
QUIC packets are individually encrypted so more metadata can be encrypted too. And I don't think connection establishment uses any sort of stream abstraction either since people speak of n-packet handshakes?
Imagine the following: The users writes a few bytes on a stream, those get immediately transmitted and lost. Before the retransmission, the user enqueues more data.
The Quic implementation has now the opportunity to merge everything into a single Quic "packet", and even a single Quic "frame", and send everything together. If those things were on top of datagrams, it might need to send the whole datagram again?
There are also other scenarios: E.g. the stream getting reset while transmission is in progress. If that happens none of those data chunks will ever have to be retransmitted. I feel like having an additional layer here will make this harder and less efficient.
> And I don't think connection establishment uses any sort of stream abstraction either since people speak of n-packet handshakes?
It does! All the TLS/handshake data is transferred in CRYPTO frames (https://tools.ietf.org/html/draft-ietf-quic-transport-30#sec...). CRYPTO frames are more or less the same as STREAM frames (https://tools.ietf.org/html/draft-ietf-quic-transport-30#sec...). They both represent an ordered reliable byte stream - just in different namespaces.
This is important for the handshake, since the TLS implementation will act on this ordered stream data and kind of treat it as a TLS data over TCP stream.
OK fair enough.
> The Quic implementation has now the opportunity to merge everything into a single Quic "packet", and even a single Quic "frame", and send everything together. If those things were on top of datagrams, it might need to send the whole datagram again?
QUIC doesn't resend datagrams; QUIC itself just uses datagram ACKs for congestion control. But if it notifies the next higher layer about ACKs, that layer is free to coalesce on retry, just like normal streaming.
> There are also other scenarios: E.g. the stream getting reset while transmission is in progress. If that happens none of those data chunks will ever have to be retransmitted. I feel like having an additional layer here will make this harder and less efficient.
STREAM_RESET would be entirely internal to the streaming layer, right? Again, the datagram layer doesn't re-transmit so no need to worry about that.
The point is: despite CORBA's convoluted complexity, at least HTTP + CORBA experiment was somewhat sane as it allowed to use multiplexed connections right out of the box and relied upon standard network capabilities without reinventing the wheel. All that in 1999 or so.
DNS over HTTPS, QUIC et al look nothing less than a monopolistic attack on open web. Google really wants to own the Internet.
https://caddyserver.com/
https://github.com/m13253/dns-over-https
This is the most sickening sentence for me. The myopic internal focus. ‘Look we’ve made our new thing a standard and look it makes our products run faster’. This is just blatant exploitation that’s occurring as there is too much centralised ownership. In my opinion this is predatory behaviour packaged up as open source good for all.
Myopic focus is exactly what the system rewards.
There also needs to be some adjustment to that valuation based on greater good delivered by the company. If they killed off a bunch of smaller businesses, that's a negative. If they emitted a bunch of carbon, that's a negative. If they caused injuries or deaths, that's a negative. If they contributed to open source products that enabled other companies to exist, that's a positive.
Carbon taxes are one step at capturing one very small aspect of this "greater good" factor, but there need to be other adjustments as well.
Another vague idea I've had is a hypothetical economic system in which the government doesn't print money (or isn't the only one printing money) but rather money is brought to existence by certain good deeds. Money can also be traded for goods and services, of course, in addition. So while you could make money by selling food or selling phones, you could also literally print your own money (translate: government hands it to you, in a controlled fashion) by sucking carbon out of the environment and proving that you did that to claim your money.
Their function is to raise money, whether they use the product or not (you don’t invest in something unless you believe it will provide value to some group of people) they’ve done their job and the company can continue to advance and adapt due to the capital. Further if you set what a company can be worth you’ve limited their resources and limited their innovation as a result.
You’ve also turned human labor into currency in an attempt to get rid of currency. You cannot get rid of the concept of money. Without it you must trade resources (like labor), which history has shown is a very bad idea. The idea of a government being able to print money is a very deliberate feature, not a bug. I cannot do this justice, but read up on why we have money in the first place.
Ex: Why does clicking on a location link in google search load a big slow SPA to display a list of "cards" instead of just having a maps/web link in the search results?
Presumably if Search did link to Google Maps, other geographic information systems would have to be represented, just like various streaming platforms are represented in the video tab.
And 3% is still a lot if you're looking at global Internet traffic.
Nobody has moved over to HTTP2 yet, let alone HTTP3.
The real motivation is probably to merge ads into the same stream as the content, so they can't be blocked by anything outside the browser.
[1]: https://news.ycombinator.com/item?id=24711247
Most network stacks in major operating systems enable Nagle's algorithm[1] which was designed in the mid 80's to improve the efficiency of TCP/IP networks. John Nagle, the parent you're responding to, likely understands the HTTP/3 improvements at a level beyond what most of us can comprehend given his deep experience in this area[2].
As the author of two foundational RFCs (RFC896[3] and RFC970[4]), I think the parent also has a fairly good recognition of and experience working with IETF working groups.
[1] https://en.wikipedia.org/wiki/Nagle%27s_algorithm
[2] https://news.ycombinator.com/item?id=8381957
[3] https://tools.ietf.org/html/rfc896
[4] https://tools.ietf.org/html/rfc970
i'm still highly alarmed, both by John & the general level of discourse going on all throughout this thread. i posted replies to a number of others too. there is wild unsubstantiated & mean-spirited speculation running rampant through this, imo, good news. no one talks to how or why they think this is going to help spy on us, or reduce our ability to block ads, yet it's a very popular & trendy opinion. it seems widely assumed that this is all for bad, and everyone seems to want to believe that mis-information.
i find it distressing that the world would be so paranoid & crazy as this. after years of IETF hard work & discussion, after countless engineers work tirelessly to maximize privacy & security, after countless points are raised & tackled, the world greets what we think is a real & significant improvement with disdain, distrust, & belittling. this feels like the kind of easy-to-spread paranoia & madness that is part & parcel to the disinformation that has grown a threat to civil order, a threat to reason. it's too easy to knock things down[1], done so casually, & people seem to want to hear it too much. i realize i haven't been helping, haven't been waging an effective campaign to try to promote a healthier course for us, better discourse, but i want to. i want to not be overwhelmed & saddened by unsupported unreason.
touching back to @animats' post:
> The real motivation is probably to merge ads into the same stream as the content,
i don't see any potential for how this would impact ad-blocking or other security measures on the web. HTTP3 offers no new features or capabilities over HTTP2. existing extensions & tools ought be unaffected.
> All that effort to get a tiny improvement.
imo QUIC+HTTP3 is a straightforward & sensible simplification over what we had, & was a natural route to enhancing the existing systems.
http2 wanted to share a connection, allow out of order serving of requests in a better way than the obsolete & complicated/painful & largely removed http1.1 pipelineing, so servers could start working on upcoming work before finishing the current request.
quic has been an attempt to take a lot of the good work already done on http2, & to drive it further down the stack, enabling a) others to use the transport/session layers now distilled into quic for their own uses, and b) radically simplifying the http specification's responsibilities by separating out quic transport/session concerns from http.
beyond making http3 much simpler, there are other benefits. a capable replacement for WebSockets is forming via WebTransport[2], and a lot of people are hoping the complex SCTP-based WebRTC stack can be re-designed to use WebTransport/quic, once webtransport advances[3].
overall, the greatest proof that this is a simpler, better, more natural path than what we had comes from a quick look a the QUIC active & related documents[4], where we can see a number of different frontiers of innovation for other ways QUIC might be improved & enhanced, including topics such as multicast, load balancing, unreliable connections, & more: quic is a flexible, interesting, compelling extraction of really neat & interesting http2 technology, & decoupled from http, we are seeing amazing innovation take root & allow all sorts of good frontiers to open. quic is itself a big improvement to what was available for transport & session protocols, and it is throwing open the doors to colossal levels of innovation that were not conceivable before.
[1] https://en.wikipedia.org/wiki/Brandolini%27s_law
[2] https://w3c.github.io/webtransport/
[3] Animats ↗ > The real motivation is probably to merge ads into the same stream as the content.
I was thinking of Google-hosted content, with Google ads. About 25% of web traffic now comes from Google, although that includes YouTube. Google serves some (most?) ads from "doubleclick.com", which can be blocked at the domain level. But if they slip the ads into the same encrypted connection as the content, it's no longer possible to block them from outside the browser.
As for traffic issues, I've seen a few papers where people compare QUIC and TCP.[1][2] But nobody seems to be looking at what QUIC-type traffic is doing to other traffic on the same path. Not that I have, either. You can boost your throughput a bit by being more aggressive about sending packets. If the nodes in the middle are all FIFO queues (the cause of "bufferbloat"), the one who sends the most wins. This creates a perverse incentive and a way to game the results of such comparisons. Fair queuing can help.
Still, it's probably a win to speed up all the handshaking involved in setting up a TLS connection. The crypto setup is a big cost for small requests.
[1] https://blog.codavel.com/quic-vs-tcptls-and-why-quic-is-not-...
[2] https://github.com/Shenggan/quic_vs_tcp
But no modern browsers actually use HTTP/1.1 pipelining. Interestingly, HTTP/1.1 pipelining works great for non-browser use. Most web servers enable it by default. After all, it works. For example requesting a series of pages from multi-page website, all under a single TCP connection. I have been using HTTP/1.1 pipeplining this way for decades. It is fast and reliable and enables the web to be used as a non-interactive, information retrieval source. It is also 100% ad-free. The user only gets what she requests, nothing more.
As for HTTP headers, privacy-conscious or minimalist users might not send many headers, only the minimum to retrieve the page. That's usually up to three extra lines of text per page for the request headers. (I rarely ever have to send a User-Agent header for HTTP/1.1 pipelining.)
Obviously, the web advertising/tracking industry, including companies like Google that serve this sector, use headers for their own purposes. Online advertising services. That's when presumably they could get big. However, as a user, I have no pressing need for the ability to send/receive larger headers.Websites (IPs represented by domain names) to which users intentionally connect, i.e., the recognisable names that they type and click on, generally don't serve ads. The ads come from other domains, often other servers. Users generally do not intentionally try to connect to ad or tracking servers. HTTP/[01].x's automatic loading of resources, Javascript and other techniques may be used to make those requests, conveniently under the radar and outside the user's awareness.
Still, under HTTP/1.1, ads, nor Javascript files that trigger requests for ads, generally cannnot be delivered without the user's computer making a request first. Users can and do manage to exercise some control over their computers and they can prevent these non-interactive requests from being sent, from inside and outside the browser.
With HTTP/2 and HTTP/3, the necessity of a user-generated request disappears. As soon as the user "connects" (UDP) to the website's server, the server could for example send a Javascript file to the user's browser which can in turn trigger requests to other domains for ads or the purpose of tracking, all without any preceding request for the ad/tracking-related Javascript file. This is another feature of HTTP/[23] called "server push", but interestingly it is not the feature being used to sell HTTP/[23] to users (i.e., pipelining).
So, how does a user stop unwanted ads being "pushed" upon her in the stream (irrespective of the application, e.g., browser)? I generally don't use a "modern" browser, nor Javascript nor graphics. I like my pipelining outside the browser and free of advertising-related cruft.
It's worth considering that the motivation for speeding up websites via HTTP/[23] is solely for the purpose of speeding the delivery of more ads, more "stealthily", to users. This is a classic case of someone trying to sell you on a "solution" to a problem they themselves have created (or to which they are contributing).
Like an ISP trying to upsell customers to faster internet in order that websites bogged down with ads will "load" faster. When the ISP itself injects ads into pages of websites that are weighed down by ads.
And pushed content needs to be accepted by the browser, just sending someone ad bytes doesn't really do anything useful. It doesn't impact adblocking, and if a browser vendor wants to take the adblocking features away they can also just do that for the traditional model.
When "everyone" uses your software/websites, you can get away with this, much like Microsoft did back in the day. Internal Windows programs ran faster and seemed more stable than third party software written to run on Windows. It generally offered better "UX", to use today's lingo.
The thing that is totally ignored by the myopic focus is the value of not being part of the Borg. Putting small speed differences aside, that value is not insubstantial, though the Google communications department is not responsible for keeping users informed about anything more than the value of Google.
The fastest internet would be one without ads (not to mention the other benefits). Google will not inform anyone about that. It is not included in any tests.
I don't disagree with your sentiment. However, their biggest gains in terms of percentage points (as discussed in the article) are for YouTube. And YouTube wouldn't be significantly faster without ads in the way that browsing primarily textual websites is faster without ads. Getting buffering times down is actually a substantial improvement here esp. on flaky connections. (Though the article doesn't make it clear whether flaky connections specifically benefit from QUIC.)
All to show it will benefit everyone, of course.
you appear to have made no attempt to understand or grasp what or why of quic & http3. many ietf engineers from all corners have worked on this because they believe to be an improvement. this tackles very real head of line blocking problems & introduces a much more forward & fast security model.
quit your cheap slander please. your casual, uninvested vitriolic outburst is disgusting. show some manners. you immediately jumped to the nasty gross conclusion you wanted to based off some engineers citing improved performance, threw slander at the attempt without even a quick look at how or why engineers sought these improvements. this behavior is sickeningly anti-social, & nothing more than a projection of your warped world view. please attempt to surface something even somewhat copied to truth when you go about shooting off.
I'm going to cut you some slack because it looks like your other comments since then have been good, but if you do it again we are going to have to ban you, so please review the rules and stick to them: https://news.ycombinator.com/newsguidelines.html.
What's the right way for Google to improve their internet-facing services at a protocol level?
An emperor can build trust by relinquishing power.
Now they're updating their own deployment, making it compatible with the updated standard.
Chrome/Android/google.com is literally changing what they do to match what the standard says.
Huh? They're reporting for their own products presumably because they have access to that information that is accurate, and they're a couple of the world's most popular, most visited sites.
But the speed improvements will come for everyone who uses the protocols, not just Google, of course. What is sickening about that?
it's three sentences you quoted.
imo this is a quite harsh & pointed take you have presented. you seem to focus on some very-nearby headline sentences that do focus on performance, where-as the real story is much more interesting & the tech much more promising.
> blatant exploitation that’s occurring as there is too much centralised ownership
what makes you think this is so lopsided? yes, the spdy drafts released in 2012 originated from google. and google spent enormous amounts of effort, time & money championing & supporting development of QUIC as it made it's way through the IETF, where other non-Google engineers also worked to improve HTTP and build a powerful new transport protocol that shows enormous progress & is opening doors.
where is the exploitation?
> The myopic internal focus. ‘Look we’ve made our new thing a standard and look it makes our products run faster’
actually they made two standards. this is much better than where we were. with http2, we had built a true monster of a specification, untame-able. for good reason! we wanted good things! but the http2 spec was trying to shoe-horn a bunch of streams inside tcp, a streaming transport protocol, and that never quite fit (head of line blocking problems resulted), but just as bad, it made http2 a massive work that was hard to evolve & grow & reuse & enhance.
they took an extremely broad view, & said, these pieces don't belong together. they delegated responsibility into component pieces. they made pieces re-usable.
the result is that there are now a couple dozen efforts related to improve the underlying QUIC transport for lots of interesting use cases. the QUIC working group lists a couple dozen efforts[1] & enhancements, such as multi-path, load-balancing tuning, multicast, ack controls, satcom capabilities, & webtransport, a potential radical simplification & rework of websockets in a more connection-friendly manner. this is all work being done outside of http, being done with quic, because of these advances by these very careful, considerate, thoughtful, aware engineers, & their willingness to work with other engineers & the IETF to figure out how best to improve things, how best to decouple http2's transport protocol from it's application protocols.
> In my opinion this is predatory behaviour packaged up as open source good for all
i would very much like to hear some of what you feel or think any of your numerous very heavy accusations are due or deserved. using acerbaic words like "most sickening sentence", "myopic internal focus", & "blatant explotation" are big big words, big angry moods, and it's really uncomfortable, really hard for me to process & deal with such emotional turmoil directed at something that seems so innocent & like such a natural refinement & progression over the very good solid ideas & improvement that were http2, as it tried to move on & progress beyond http1.1 pipelineing, which everyone wanted very much wanted & in many cases did give up on.
so why do you hold your opinion? it really hurt me to hear your opinion, stated so pointedly, at such a lot of work that so many engineers all over the industry have contributed to & worked hard on. is this new dissent you have? are there other anti-http3 anti-quic folks who have staked some of their problems & claims & issues, or who have other ways they want the community to work through standards & specifications to improve the internet? what are the issues here, what's wrong? i for one thank my lucky stars that there are corporate patrons paying engineers good money to improve the world with works like this, to do the logical & consistent task of breaking http2 into it's transport (quic) and application (http3) protocols, improving the speed & reliability of the net.
thank you Google & IETF for doing all sorts of g...
On another note:
I see you're paving the way for gRPC on the Web (of browsers) by adding trailers (a header sent after the body), which is not supported today for HTTP/1 not /2 by at least the top 3 browser vendors in volume.I'm divided: I'd be glad to get rid of grpc-gateway and websockets but isn't proto-encoded communication bad for the open Web /in principle/? Maybe it's only a tooling problem.
There's a lot of magic you can do with protos. At my current company we're even generating forms/UIs entirely off of proto message definitions for things like configs. Engineers no longer need to think about how to make something work cross language, manually wiring up a UI, etc.
I cant wait to see what doors this opens up for gRPC on the browser as that will bring many more OSS devs into the ecosystem.
0 - https://github.com/grpc/grpc/issues/19126
I don't know what "the cross-out treatment" is exactly but if you mean the UI behaviour where non-secure contexts get a red line or the words "Not Secure" then there's no reason that will change. HTTP/1.1 over TLS is still fine, HTTP/1.1 plaintext was already treated that way. The newer protocol isn't really "more secure", than HTTP/1.1 over TLS, but it is as this article notes, faster and more capable.
Curl seem to be evaluating two different stacks: ngtcp2+nghttp3 (C, seems to be from developers behind aria2) and Quiche (Rust, from Cloudflare)
Then there's Google's C++ QUICHE implementation which seems to not be used by anyone outside of Chromium (Even node.js apparently isn't using this, unless the code is just old).
There are several more: https://en.wikipedia.org/wiki/HTTP/3#Libraries
It's a bit of a mess, and until Curl makes a decision I'm not sure where to go.