11 ms·

So much negativity in this thread. Personally I am _very_ excited by HTTP/3 (and QUIC), it feels like the building block for Internet 2.0, with connection migr

So much negativity in this thread. Personally I am _very_ excited by HTTP/3 (and QUIC), it feels like the building block for Internet 2.0, with connection migration over different IPs, mandatory encryption, bidirectional streams and it being a user-space library – sure, more bloat, but from now on we won't have to wait for your kernel to support feature X, or even worse, your ISP-provided router or decade old middleware router on the Internet. I haven't had the chance to read the actual spec yet, but it's obvious that while the current tech (HTTP2) is an improvement over what we had before, HTTP/3 is a good base to make the web even faster and more secure. HTTP/3 won't be IPv6: it only requires support from the two parties that benefit from it the most: browser vendors and web server vendors. We won't have to wait on the whole internet to upgrade their hardware.

zzzcpan 8y ago
Googlenet is not internet 2.0 and barely anyone in the world beyond a couple of megacorps can benefit from HTTP/2, HTTP/3, HTTP/4, etc. It feels more like the web is dead, completely captured by megacorps.
- dochtman 8y ago
  QUIC is developed by an IETF working group where anyone can participate, and there are definitely some productive participants who don't work for Google (or any of the other big companies).
  - zzzcpan 8y ago
    That's not really true. Independent participants don't have any power to affect any of it.
  - takeda 8y ago
    Like they listened to varnish author about making actually useful changes? For example implementing proper sessions, so cookies could go away.
    - dagenix 8y ago
      Just because they didn't agree with his suggestion to make major changes to the protocol semantics didn't mean they didn't listen to him.
    - JoshTriplett 8y ago
      TLS Token Binding provides exactly that.
      - takeda 8y ago
        Yeah, and who is using it? Why cookies are still there?
        anticensor 8y ago
        Cookies can do more than sessions.
        takeda 8y ago
        Sure they can, but sessions are pretty much the only reason why end users have cookies enabled.
- est31 8y ago
  The web is captured by megacorps but it's not captured because of HTTP/2.0. It's captured because of network effects or whatever. And you are wrong, there is a benefit from using HTTP/2.0 on any website that has more than 1 resource to download.
- tialaramex 8y ago
  So, presumably organisations like the IRS and Wikipedia are "barely anyone" and all of the big technology companies are "a couple of megacorps" but can you explain why you believe the _users_ don't benefit? [About a third of all "popular" (ie top 10 million) web sites are HTTP/2 today] Or did you just mean "I don't care about the facts, I'm angry and the world changes which I don't really understand, so I just make things up and call that truth because it's easier" ?
  - gambler 8y ago
    >[About a third of all "popular" (ie top 10 million) web sites are HTTP/2 today] Don't forget that a huge chunk of them are hosted on megacorp cloud platforms. Everything became so "simple" and "streamlined" that companies are forced to outsource all their hardware and platform management and then hire a small army of AWS certified devops.
    - judge2020 8y ago
      > companies are forced to outsource all their hardware and platform management Nothing is being forced. You can still set up a server in your basement, or rent/build a data center and run nginx to get all of the benefits of H2, TLS1.3, etc. You can even get "megacorp-quality platform management" with things like Outposts, GKE on-prem, Azure stack, etc.
      - gambler 8y ago
        >Nothing is being forced. Not directly, but it is by complexity of dominant technology stacks, protocols and standards that are influenced by ubercorps.
- rswail 8y ago
  Running nginx as reverse proxy on internal system. HTTP/2 happens automagically if a client requests it. It definitely has an impact on our system which requires sub 50ms response times on 2000+ concurrent requests. It's a PITA if you want to debug the streams because not plain text, but given that we're over TLS, that's not really possible anyway. In testing, we use ye-olde HTTP/1.1 and no TLS, but even over HTTP/2 and TLS, the browser will still display a JSON request/response happily. Rare that we have to go lower in the stack.
marcosdumay 8y ago
Honestly, I'd feel much better if people were standardizing QUIC and we simply run HTTP/1.1 over it. Instead we now have transport layers that are application specific and 3 completely different web protocols with none of them being considered legacy, 2 of them being complex enough that people aren't very willing to move. That does not look like a good foundation for anything.
- detaro 8y ago
  Part of the process while moving QUIC through IETF was separating it from the HTTP layer, which is why now HTTP/3 and QUIC are different things - although given history and involved players, the HTTP use case was a priority, but other companies are looking to use it underneath other protocols. From my understanding, compared to HTTP/2, the stream concept has moved out of the HTTP spec in the underlying level, where it hopefully can benefit other use cases too.
  - justincormack 8y ago
    Indeed, and the encryption is split too. Overall it is starting to look nice to use, although I need to read the spec in more detail to understand a bunch of the details.
- collinmanderson 8y ago
  http/2 usage has gone from 24% to 33% in the last year, which is pretty good growth. https://w3techs.com/technologies/details/ce-http2/all/all https://w3techs.com/technologies/details/ce-http2/all/all
jlouis 8y ago
I'm worried, not because of the standard itself, which seems well thought out, even if rushed. I'm worried because you have a protocol implemented in the userland for a few mainstream languages. It seems everyone now has to pay the price of a protocol implementation on top of a protocol implementation on top of a protocol implementation. Big players---either because they have thousands of open source developers, or is backed by a corporation---they have it easy. Smaller players? Not so much. Also, note that the exact problem that HTTP/3 tries to solve was known in the design process of HTTP/2 and some people even noted having multiple flow control schemes at multiple layers would become a problem. We are letting the same people design the next layer, and probably too fast in the name of time to market. This should definitely live in a way people can make use of it easily, with an API highly amenable to binding. If it gains traction, we need a new UDP interface to the kernel as well, for batching packets back and forth. This kills operating system diversity as well, or runs the risk at doing so. OTOH, I see the lure: SCTP never caught on for a reason, and much of this is the opposite of my above worries.
- shereadsthenews 8y ago
  The TCP state machine sucks and all of its timing parameters are outdated and unsuitable for modern networks. QUIC frees us from the tyranny of the kernel. Being in userspace is a feature.
  - jandrese 8y ago
    The rallying cry of everybody who later comes to the realization that they have re-implemented TCP.
    - treve 8y ago
      Maybe re-implemented SCTP, but this time it's usable.
    - Jasper_ 8y ago
      So what if we use our experiences and in-depth knowledge of a past protocol, take into account the flaws, and build something better? You say "re-implemented TCP" as if it's the only possible way to build a reliable packet protocol, and that it has no flaws, and we can't make any improvements to it. TCP isn't alien technology we don't understand. We do understand it, and its limits, and its constraints, and that means we can build a better one next time.
jimmaswell 8y ago
Irrespective of the protocol, my optimism for the future of the web has been curtailed by developments like extensions having less and less power over time (recent example is Google's plans to intentionally cripple ad blockers), plugins going away, hobbyist websites becoming more burdensome to set up and maintain if insecure http is deprecated, browsers planning to disable autoplay, etc. It feels like the golden age of the creative and vibrant web peaked during the brief window where all the new HTML5 stuff was around, Firefox used the old extension system, and Flash and Java applets were still common. After that point it's been becoming more and more sterilized. My web apps that automatically played some sound aren't going to work anymore without some obnoxious "click here to begin" screen that doesn't fit in with the content. No more plugins letting us extend our browsers in new ways (what a convenient "coincidence" for Google that this gives them more control over what the user gets to do and makes tracking what goes on easier). I have to give Reddit Enhancement Suite permission every single time it tries to show a preview from a domain it hasn't previously done so from before. It's all suffocating. HTML5 makes up for some of the lost capability but it's not enough and what parts of HTML5 are going to actually work are basically at the whim of Google now. But at least HTTP/3 will let us load buzzfeed listicles a few milliseconds faster, so there's that.
- deleted 8y ago
  [deleted]
- iwalton3 8y ago
  At least Let's Encrypt has made certificates easier than ever to add and update. Installation of a self-updating certificate takes less than 10 minutes on many server setups.
  - gambler 8y ago
    The sheer fact that you need to involve a third party for encryption shows that the web is fundamentally, conceptually broken and no longer lives up to its original design goals.
    - nine_k 8y ago
tialaramex 8y ago
It's a misconception that you have to wait with IPv6. If you're a large organisation you can move to IPv6 "today". What you do is, internally you cease buying IPv4-only gear and using IPv4 addressing etcetera. Everything inside is purely IPv6. A lot of your networking gets simpler when you do this, and debugging is a LOT smoother because there's no more "Huh 10.0.0.1, could be _anything_" everything has globally unique addresses because it's not crammed into this tiny 32-bit space. At the edge, you have protocol translators to get from IPv6 (which all your internal stuff users) to IPv4 (which some things on the Internet use) but you probably already had a bunch of gear at the edge anyway, to implement corporate policies like "No surfing for porn at work" and "Nobody from outside should be connecting to port 22 on our machines!". This isn't really practical for "One man and an AWS account" type businesses where your "Internet access" is a Comcast account and an iPhone, but if you're big enough to actually have an IT department, suggest they look into it. It may be cheaper and simpler than they'd realised.
- 1_player 8y ago
  > It's a misconception that you have to wait with IPv6. Yes and no. As I stated at the end of my comment, the problem w/ IPv6 is that who's benefitting the most isn't clear: I am interested in it, as a power user. Average Joe doesn't care. App developer doesn't care (no killer IPv6 apps yet). Large ISPs with extensive CG-NAT deployments don't care (not worth the money, yet, see IPv6 adoption in the UK). Who cares about HTTP/3? Average Joe — Not really. Mozilla/Google — Hell yeah they do. It'll be in Chrome before anyone else (if it isn't already). Same with nginx/Apache/any other webserver, Joe Blog with his own VPS will want to enable it. And that's all you need.
  - judge2020 8y ago
    > (no killer IPv6 apps yet). If it helps, Apple now requires apps support IPv6-only networking. https://developer.apple.com/support/ipv6/ https://developer.apple.com/support/ipv6/
    - gsich 8y ago
      This is just client side, any tunneling or NAT64 is still allowed.
simias 8y ago
It may be my embedded developer bias but I don't actually consider moving things outside of the kernel to be necessarily a good thing. Standard kernel interfaces are (usually) a guarantee of stability and good isolation, are generally easier to probe using standard tools, easier to accelerate in hardware etc... Not everything should be in the kernel of course, but low level network protocols should be IMO because they're good targets for potential hardware-acceleration (I'm convinced that it would make sense to handle SSL in-kernel for instance, with a userland daemon handling certificate validation, but that's a story for an other day). I mean, if you can easily update whatever userland library you're using, why can't you upgrade your OS? If the library is easy to upgrade it means that it uses a well defined and backward-compatible interface. What do you get by shifting everything one layer up? In the end it's just software, there's not really any reason why upgrading a kernel driver should be any harder than upgrading a .so/.dll. So the logic is "kernels are too slow to update and integrate the last new standards, so let's just move everything one step up because browsers auto-update"? Except that there's no technical reason for that, on my Linux box my browser and my kernel are updated at the same time when I run "apt-get upgrade" or "pacman -Syu" or whatever applies. The kernel I'm using at the moment has been built less than a week ago. So if the problem is that Windows sucks balls and as a result people end up effectively re-creating an operating system on top of it to work around that, then yeah, from a practical standpoint I get it but I'm definitely not "_very_ excited" about it. It's a rather ugly hack. If in general if the question is "who do you trust more to select and implement new internet standards, kernel developers or web developers?" then I take a side-glance at the few GBs used by my web browser to display a handful of static pages at the moment and I know the answer as far as I'm concerned... So yeah, it might make sense, but I still think it just goes to show what a shitshow modern software development has become. Instead of fixing things we just add a new layer on top and we rationalize that it's better that way.
- k_ 8y ago
  I generally agree with that, but what about mobile? AFAIK android kernel updates are really slow to reach users; when they actually do (depending on support from vendors, which vary a lot).
- 1_player 8y ago
jjtheblunt 8y ago
I can't believe you wrote "Internet 2.0". Not sure why.
mlindner 8y ago
> or even worse, your ISP-provided router or decade old middleware router on the Internet. I can guarantee you that middleware will continue to exist. If they need to they'll force QUIC connections to terminate and switch to TLS 1.3. There's no way that companies will allow encrypted communications leaving their companies en-masse without being able to decrypt the content. Even more so for any totalitarian state governments that need to spy on their citizens..
- JoshTriplett 8y ago
  > There's no way that companies will allow encrypted communications leaving their companies en-masse without being able to decrypt the content. Then they'll install MITM certificates on the individual endpoints that they already control. The ability to intercept connections between endpoints is inexorably going away.
MaxBarraclough 8y ago
About the mandatory encryption and the performance: this will prevent ISP caching of static content. That would be bad news for, say, Steam and Debian, who use HTTP (not HTTPS [0][1]) to distribute content. (They verify integrity with secure hashing, of course.) I presume they'll decline to adopt HTTP/3. [0] https://developer.valvesoftware.com/wiki/SteamPipe#LAN_Caching https://developer.valvesoftware.com/wiki/SteamPipe#LAN_Cachi... [1] https://whydoesaptnotusehttps.com/ https://whydoesaptnotusehttps.com/
smittywerben 8y ago
Bit late to the party, I misunderstood the HTTP/3 but I am very excited for QUIC, and _not_ because of Google's illuminati spec but because I hope people will be interested in secure UDP. I like datagrams so much more than an accept-listen-keepalive-blocking-foreverloop-callback-async-threaded-future hell that is TCP. I could be wrong of course I need to read the spec too. Anything UDP makes me giddy.

zzzcpan 8y ago

Googlenet is not internet 2.0 and barely anyone in the world beyond a couple of megacorps can benefit from HTTP/2, HTTP/3, HTTP/4, etc. It feels more like the web is dead, completely captured by megacorps.

dochtman 8y ago
QUIC is developed by an IETF working group where anyone can participate, and there are definitely some productive participants who don't work for Google (or any of the other big companies).
- zzzcpan 8y ago
  That's not really true. Independent participants don't have any power to affect any of it.
- takeda 8y ago
  Like they listened to varnish author about making actually useful changes? For example implementing proper sessions, so cookies could go away.
  - dagenix 8y ago
    Just because they didn't agree with his suggestion to make major changes to the protocol semantics didn't mean they didn't listen to him.
  - JoshTriplett 8y ago
    TLS Token Binding provides exactly that.
    - takeda 8y ago
      Yeah, and who is using it? Why cookies are still there?
      - anticensor 8y ago
        Cookies can do more than sessions.
        takeda 8y ago
        Sure they can, but sessions are pretty much the only reason why end users have cookies enabled.
est31 8y ago
The web is captured by megacorps but it's not captured because of HTTP/2.0. It's captured because of network effects or whatever. And you are wrong, there is a benefit from using HTTP/2.0 on any website that has more than 1 resource to download.
tialaramex 8y ago
So, presumably organisations like the IRS and Wikipedia are "barely anyone" and all of the big technology companies are "a couple of megacorps" but can you explain why you believe the _users_ don't benefit? [About a third of all "popular" (ie top 10 million) web sites are HTTP/2 today] Or did you just mean "I don't care about the facts, I'm angry and the world changes which I don't really understand, so I just make things up and call that truth because it's easier" ?
- gambler 8y ago
  >[About a third of all "popular" (ie top 10 million) web sites are HTTP/2 today] Don't forget that a huge chunk of them are hosted on megacorp cloud platforms. Everything became so "simple" and "streamlined" that companies are forced to outsource all their hardware and platform management and then hire a small army of AWS certified devops.
  - judge2020 8y ago
    > companies are forced to outsource all their hardware and platform management Nothing is being forced. You can still set up a server in your basement, or rent/build a data center and run nginx to get all of the benefits of H2, TLS1.3, etc. You can even get "megacorp-quality platform management" with things like Outposts, GKE on-prem, Azure stack, etc.
    - gambler 8y ago
      >Nothing is being forced. Not directly, but it is by complexity of dominant technology stacks, protocols and standards that are influenced by ubercorps.
rswail 8y ago
Running nginx as reverse proxy on internal system. HTTP/2 happens automagically if a client requests it. It definitely has an impact on our system which requires sub 50ms response times on 2000+ concurrent requests. It's a PITA if you want to debug the streams because not plain text, but given that we're over TLS, that's not really possible anyway. In testing, we use ye-olde HTTP/1.1 and no TLS, but even over HTTP/2 and TLS, the browser will still display a JSON request/response happily. Rare that we have to go lower in the stack.

marcosdumay 8y ago

Honestly, I'd feel much better if people were standardizing QUIC and we simply run HTTP/1.1 over it. Instead we now have transport layers that are application specific and 3 completely different web protocols with none of them being considered legacy, 2 of them being complex enough that people aren't very willing to move. That does not look like a good foundation for anything.

detaro 8y ago
Part of the process while moving QUIC through IETF was separating it from the HTTP layer, which is why now HTTP/3 and QUIC are different things - although given history and involved players, the HTTP use case was a priority, but other companies are looking to use it underneath other protocols. From my understanding, compared to HTTP/2, the stream concept has moved out of the HTTP spec in the underlying level, where it hopefully can benefit other use cases too.
- justincormack 8y ago
  Indeed, and the encryption is split too. Overall it is starting to look nice to use, although I need to read the spec in more detail to understand a bunch of the details.
collinmanderson 8y ago
http/2 usage has gone from 24% to 33% in the last year, which is pretty good growth. https://w3techs.com/technologies/details/ce-http2/all/all https://w3techs.com/technologies/details/ce-http2/all/all

jlouis 8y ago

I'm worried, not because of the standard itself, which seems well thought out, even if rushed. I'm worried because you have a protocol implemented in the userland for a few mainstream languages. It seems everyone now has to pay the price of a protocol implementation on top of a protocol implementation on top of a protocol implementation. Big players---either because they have thousands of open source developers, or is backed by a corporation---they have it easy. Smaller players? Not so much. Also, note that the exact problem that HTTP/3 tries to solve was known in the design process of HTTP/2 and some people even noted having multiple flow control schemes at multiple layers would become a problem. We are letting the same people design the next layer, and probably too fast in the name of time to market. This should definitely live in a way people can make use of it easily, with an API highly amenable to binding. If it gains traction, we need a new UDP interface to the kernel as well, for batching packets back and forth. This kills operating system diversity as well, or runs the risk at doing so. OTOH, I see the lure: SCTP never caught on for a reason, and much of this is the opposite of my above worries.

shereadsthenews 8y ago
The TCP state machine sucks and all of its timing parameters are outdated and unsuitable for modern networks. QUIC frees us from the tyranny of the kernel. Being in userspace is a feature.
- jandrese 8y ago
  The rallying cry of everybody who later comes to the realization that they have re-implemented TCP.
  - treve 8y ago
    Maybe re-implemented SCTP, but this time it's usable.
  - Jasper_ 8y ago
    So what if we use our experiences and in-depth knowledge of a past protocol, take into account the flaws, and build something better? You say "re-implemented TCP" as if it's the only possible way to build a reliable packet protocol, and that it has no flaws, and we can't make any improvements to it. TCP isn't alien technology we don't understand. We do understand it, and its limits, and its constraints, and that means we can build a better one next time.

jimmaswell 8y ago

Irrespective of the protocol, my optimism for the future of the web has been curtailed by developments like extensions having less and less power over time (recent example is Google's plans to intentionally cripple ad blockers), plugins going away, hobbyist websites becoming more burdensome to set up and maintain if insecure http is deprecated, browsers planning to disable autoplay, etc. It feels like the golden age of the creative and vibrant web peaked during the brief window where all the new HTML5 stuff was around, Firefox used the old extension system, and Flash and Java applets were still common. After that point it's been becoming more and more sterilized. My web apps that automatically played some sound aren't going to work anymore without some obnoxious "click here to begin" screen that doesn't fit in with the content. No more plugins letting us extend our browsers in new ways (what a convenient "coincidence" for Google that this gives them more control over what the user gets to do and makes tracking what goes on easier). I have to give Reddit Enhancement Suite permission every single time it tries to show a preview from a domain it hasn't previously done so from before. It's all suffocating. HTML5 makes up for some of the lost capability but it's not enough and what parts of HTML5 are going to actually work are basically at the whim of Google now. But at least HTTP/3 will let us load buzzfeed listicles a few milliseconds faster, so there's that.

deleted 8y ago
[deleted]
iwalton3 8y ago
At least Let's Encrypt has made certificates easier than ever to add and update. Installation of a self-updating certificate takes less than 10 minutes on many server setups.
- gambler 8y ago
  The sheer fact that you need to involve a third party for encryption shows that the web is fundamentally, conceptually broken and no longer lives up to its original design goals.
  - nine_k 8y ago

tialaramex 8y ago

It's a misconception that you have to wait with IPv6. If you're a large organisation you can move to IPv6 "today". What you do is, internally you cease buying IPv4-only gear and using IPv4 addressing etcetera. Everything inside is purely IPv6. A lot of your networking gets simpler when you do this, and debugging is a LOT smoother because there's no more "Huh 10.0.0.1, could be _anything_" everything has globally unique addresses because it's not crammed into this tiny 32-bit space. At the edge, you have protocol translators to get from IPv6 (which all your internal stuff users) to IPv4 (which some things on the Internet use) but you probably already had a bunch of gear at the edge anyway, to implement corporate policies like "No surfing for porn at work" and "Nobody from outside should be connecting to port 22 on our machines!". This isn't really practical for "One man and an AWS account" type businesses where your "Internet access" is a Comcast account and an iPhone, but if you're big enough to actually have an IT department, suggest they look into it. It may be cheaper and simpler than they'd realised.

1_player 8y ago
> It's a misconception that you have to wait with IPv6. Yes and no. As I stated at the end of my comment, the problem w/ IPv6 is that who's benefitting the most isn't clear: I am interested in it, as a power user. Average Joe doesn't care. App developer doesn't care (no killer IPv6 apps yet). Large ISPs with extensive CG-NAT deployments don't care (not worth the money, yet, see IPv6 adoption in the UK). Who cares about HTTP/3? Average Joe — Not really. Mozilla/Google — Hell yeah they do. It'll be in Chrome before anyone else (if it isn't already). Same with nginx/Apache/any other webserver, Joe Blog with his own VPS will want to enable it. And that's all you need.
- judge2020 8y ago
  > (no killer IPv6 apps yet). If it helps, Apple now requires apps support IPv6-only networking. https://developer.apple.com/support/ipv6/ https://developer.apple.com/support/ipv6/
  - gsich 8y ago
    This is just client side, any tunneling or NAT64 is still allowed.

simias 8y ago

It may be my embedded developer bias but I don't actually consider moving things outside of the kernel to be necessarily a good thing. Standard kernel interfaces are (usually) a guarantee of stability and good isolation, are generally easier to probe using standard tools, easier to accelerate in hardware etc... Not everything should be in the kernel of course, but low level network protocols should be IMO because they're good targets for potential hardware-acceleration (I'm convinced that it would make sense to handle SSL in-kernel for instance, with a userland daemon handling certificate validation, but that's a story for an other day). I mean, if you can easily update whatever userland library you're using, why can't you upgrade your OS? If the library is easy to upgrade it means that it uses a well defined and backward-compatible interface. What do you get by shifting everything one layer up? In the end it's just software, there's not really any reason why upgrading a kernel driver should be any harder than upgrading a .so/.dll. So the logic is "kernels are too slow to update and integrate the last new standards, so let's just move everything one step up because browsers auto-update"? Except that there's no technical reason for that, on my Linux box my browser and my kernel are updated at the same time when I run "apt-get upgrade" or "pacman -Syu" or whatever applies. The kernel I'm using at the moment has been built less than a week ago. So if the problem is that Windows sucks balls and as a result people end up effectively re-creating an operating system on top of it to work around that, then yeah, from a practical standpoint I get it but I'm definitely not "_very_ excited" about it. It's a rather ugly hack. If in general if the question is "who do you trust more to select and implement new internet standards, kernel developers or web developers?" then I take a side-glance at the few GBs used by my web browser to display a handful of static pages at the moment and I know the answer as far as I'm concerned... So yeah, it might make sense, but I still think it just goes to show what a shitshow modern software development has become. Instead of fixing things we just add a new layer on top and we rationalize that it's better that way.

k_ 8y ago
I generally agree with that, but what about mobile? AFAIK android kernel updates are really slow to reach users; when they actually do (depending on support from vendors, which vary a lot).
1_player 8y ago

jjtheblunt 8y ago

I can't believe you wrote "Internet 2.0". Not sure why.

mlindner 8y ago

> or even worse, your ISP-provided router or decade old middleware router on the Internet. I can guarantee you that middleware will continue to exist. If they need to they'll force QUIC connections to terminate and switch to TLS 1.3. There's no way that companies will allow encrypted communications leaving their companies en-masse without being able to decrypt the content. Even more so for any totalitarian state governments that need to spy on their citizens..

JoshTriplett 8y ago
> There's no way that companies will allow encrypted communications leaving their companies en-masse without being able to decrypt the content. Then they'll install MITM certificates on the individual endpoints that they already control. The ability to intercept connections between endpoints is inexorably going away.

MaxBarraclough 8y ago

About the mandatory encryption and the performance: this will prevent ISP caching of static content. That would be bad news for, say, Steam and Debian, who use HTTP (not HTTPS [0][1]) to distribute content. (They verify integrity with secure hashing, of course.) I presume they'll decline to adopt HTTP/3. [0] https://developer.valvesoftware.com/wiki/SteamPipe#LAN_Caching https://developer.valvesoftware.com/wiki/SteamPipe#LAN_Cachi... [1] https://whydoesaptnotusehttps.com/ https://whydoesaptnotusehttps.com/

smittywerben 8y ago

Bit late to the party, I misunderstood the HTTP/3 but I am very excited for QUIC, and _not_ because of Google's illuminati spec but because I hope people will be interested in secure UDP. I like datagrams so much more than an accept-listen-keepalive-blocking-foreverloop-callback-async-threaded-future hell that is TCP. I could be wrong of course I need to read the spec too. Anything UDP makes me giddy.