Chrome is deploying HTTP/3 and IETF QUIC
blog.chromium.org
blog.chromium.org
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.
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?
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.
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.
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?)
- 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-...
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:
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)"
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...
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.)
> GET /index.html HTTP/1.1
> Host: example.com
< HTTP/1.1 301 Moved Permanently
< Content-length: 0
< Location: https://example.com/index.html
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
$ 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
...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).
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.
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.
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%...
Bad Request
This combination of host and port requires TLS.
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.
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:
GET https://example.com/foo HTTP/1.1
...
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.
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.
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.
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).
> 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.
On another note:
3. optionally, the trailer field section, if present, sent as a single HEADERS frame.
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.
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.
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
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.
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.
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.
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.
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.
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
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.
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 good for us all, imo.
[1] https://datatracker.ietf.org/wg/quic/documents/
there's a lot here beyond performance. i encourage you to investigate a little further & to see what quic + http3 bring & how they emerged from http2. that there is some performance win is good, but don't let that one statement narrow down your own understanding of this important enhancement.
the best evidence i can point to is a quic look at the IETF work group's active & related documents[1]
There are too many broken machines on the Internet that can't deal with anything that isn't TCP or UDP.