7 ms·

After my opinion around 4% performance improvement doesn't justify the introduction of this more complicated protocol (maybe google knows how this benefit their

• tpmx 6y ago
  It adds to a number of other great reasons to break up Google and some other big tech companies. The fact that Google is so dominant (controlling both the discovery, browser and casual video content aspects) that they can unilaterally decide on fundamental internetworking protocols is obviviously a very important issue. "U.S. House's antitrust report hints at break-up of big tech firms: lawmaker (reuters.com)" https://news.ycombinator.com/item?id=24697860 https://news.ycombinator.com/item?id=24697860
  • redant 6y ago
    This argument is false. Google contributed the protocol to IETF. Where the competitors introduced a lot of incompatible changes, which Google then implemented. The blog post is literally Google's announcement that they are moving to that public standard.
    • tpmx 6y ago
      What other company could have done this? Was the fact that Google controls so much of the entire usage chain (chrome, google.com, youtube.com) irrelevant?
      • bb88 6y ago
        Back in the 90s Microsoft had been rumored to be developing their own proprietary TCP replacement -- back when IIS was the king of the world. They could have shut off a large portion of IIS traffic to those that weren't running Internet Explorer.
        • tpmx 6y ago
          Makes sense. I guess they failed because they were too late to the web - Netscape ate their breakfast.
        • Ericson2314 6y ago
          Have anything to read on this?
          • bb88 6y ago
            Apparently, was more than just a rumor. https://www.metzdowd.com/pipermail/cryptography/2002-June/002456.html https://www.metzdowd.com/pipermail/cryptography/2002-June/00... https://wiki.c2.com/?MicrosoftPalladium https://wiki.c2.com/?MicrosoftPalladium
        • mr_toad 6y ago
          It might have worked if the majority of web servers had been Microsoft’s, but my recollection is they never got close to having the majority of the web server market. The crown went from NCSA to Apache and then only recently to Nginx.
          • bb88 6y ago
            They had the majority of the corporate market at the time.
      • tialaramex 6y ago
        In this specific case only three other companies make web browsers with significant market share (Mozilla, Apple, Microsoft), so I guess you could argue only those three companies could have done this particular thing and you're correct that only Google owns Youtube. But more generally companies have written up IETF paperwork for other protocols. Lots of Microsoft protocols have RFCs for example. But one thing that's less common is actually engaging with full-blown IETF working group standards development like Google did here, as opposed to just saying "Look here's the protocol we built, you can use that, or not". The IETF is totally happy to accept what I guess you could call a "donation" of that sort, and it's much less effort. Maybe you take some internal documents, you reassemble them into the rough shape of an RFC, you publish that draft, you get a bunch of feedback about that document, focused on clarifying the explanation, making sure you cover everything required, and so on rather than altering the protocol (which you've maybe already actually shipped in a product) and after maybe 6-12 months you've got a polished RFC ready to publish. If you use a work VPN for example, or a corporate WiFi network that's not just a few home WiFi routers with a more professional SSID and password, you probably end up using protocols Microsoft "donated" in this way, like PEAPv0/EAP-MSCHAPv2 - these protocols are awful but there was no multi-step process where other vendors improve on it and then they eventually reach consensus and publish. Microsoft shipped products that do MSCHAPv1, then wrote it up so that other products could interoperate with Windows, and when they made MSCHAPv2 they followed the same path.
  • laurent92 6y ago
    Nonwithstanding your argument, their size also makes them suspect by default. They would be able to push control much farther if it had separated interests. Look at LetsEncrypt: A Google initiative. Yet 25% of the world’s websites use it.
    • unpixer 6y ago
      How exactly do you figure Let's Encrypt is a Google initiative?
    • tialaramex 6y ago
      > 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.
    • deleted 6y ago
      [deleted]
  • deleted 6y ago
    [deleted]
• anderspitman 6y ago
  Since QUIC eliminates head of line blocking, I'd be interested in seeing how it looks over poor connections.
• jraph 6y ago
  > forcing everybody to https so they can increase their control over the internet how does this increase their control?
  • anchpop 6y ago
    It prevents ISPs from snooping. But personally I don't really buy the shadowy conspiracy theories. I think HTTPS makes the internet better (people want to be able to trust their connections are secret), and anything that makes the internet better is good for Google.
    • wtetzner 6y ago
      > But personally I don't really buy the shadowy conspiracy theories. I think HTTPS makes the internet better I guess both can be true.
    • wvenable 6y ago
      There is a trade off. Encryption everywhere protects the clients from the network. That's great for most usage but it's a negative if it's your local network and you want to have more control over clients using it. Right now it's possible to selectively block client activity on your network (your smart TV snooping or showing ads) but that's going to get much harder in the future. You'll have to chose all or none when it comes to clients.
    • userbinator 6y ago
      You want encryption only through the untrusted parts of the network, because otherwise it is secret from you.
  • zo1 6y ago
    It takes away control from the user that no longer has full and relatively-easy control over the data flowing through their hardware. With Google controlling the browser, the web renderer, the HTTP protocols, the add-ons available in the browser and preventing data manipulation due to HTTPS, they have an encryption-protected pipe straight from their servers to the user's screen. And it's all done under the guise and blessing of "privacy". It's really a bleak future for the web. Sorry, I went on a bit of tangent. But to answer your question: HTTPS makes it incredibly difficult to introspect and alter content that is flowing through the web and your browser. Allowing a user (and his ISP if done correctly) to easily at the network level alter the content, one can do all sorts of magic that we haven't even begun to explore because it's effectively impossible. The big usage of this would be ad-blocking and removal. At this point the two biggest ad-blocking mechanisms we easily have available are: DNS-blocking of ad servers, and add-ons/plugins that are allowing introspection of the data on the web pages visited. Both of those avenues are being attacked. Add-on APIs and capabilities are being neutered in little bits and pieces both on Firefox + Chrome. And DNS is being attacked with things such as DNS over HTTPS (again under the guise of privacy). Not to mention that even SSL certificates that allow MITM for the user are being attacked by initiatives such as embedding SSL certificates into binaries, and certificate pinning (which luckily seems to have been abandoned). We need FOSS/Stallman-level activism and wars against this stuff that is eating away at the rights we have over our own hardware. Whatever you call this issue, it should be right up there with "right to repair", "own our own data", "right to be forgotten", etc. Edit, wrong acronym.
• chrismorgan 6y ago
  What are you comparing it to? 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.
  • dmix 6y ago
    Every millisecond counts when loading JS backed features on websites too. I'm curious with the multiplexing improvements if we'll see greater performance gains in the long-term as we changed how we package and bundle JS. I've seen a significant improvement in general page performance using Webpack's chunking, where it automatically breaks up each of your components into smaller .js file and only loads them if the page uses them (basically on-demand async importing of JS files that were preprocessed with webpack). It went from loading one giant blob of JS on every page into one primary JS file (about 25% smaller) + a bunch of tiny 1-10kb .js files that load async. A typical heavily interactive page would load 5-10 of these async files. There's probably opportunities to go even further in breaking up the primary file (which handles the logic of which JS components to load + includes the Vue/whatever framework and other JS dependencies). I understand the utility of "loading once and caching" stuff but for serious JS-heavy frontends the bundled JS files becoming extremely bulky (sometimes in multiple megabytes due to legacy dependencies) and ideally you'd minimize that always-cached part as much as possible.
• jchw 6y ago
  It is optional, backwards compatible protocol. You can still use HTTP/1.1 as a server or client. Literally the only reason 1.0 isn’t still usable is IP exhaustion/vhosts, and that did not change with HTTP/2 or 3. Modern TLS is also a complicated protocol. (If you don’t believe me, I believe google.com will still load in IE 5.5+ with plain old HTTP, albeit in a legacy mode.) Also very confused at how we’re spinning HTTPS as a bad thing now? Cloudflare and Lets Encrypt did significantly more for HTTPS adoption than Google anyways... and it is a bit preposterous that it is somehow being spun as a negative. It’s about security as much as it is about privacy... (I am a Google employee but speaking entirely in a personal capacity. Additionally, I do not work on Chrome or QUIC.)
  • a1369209993 6y ago
    > Also very confused at how we're spinning HTTPS as a bad thing now? > GET /index.html HTTP/1.1 > Host: example.com < HTTP/1.1 301 Moved Permanently < Content-length: 0 < Location: https://example.com/index.html That is how HTTPS is a bad thing.
    • jchw 6y ago
      I have a solution: connect over TLS on port 443.
    • tene 6y ago
      Could you explain what problem you're trying to demonstrate here? What's the bad thing?
      • a1369209993 6y ago
        It's no longer possible to fetch some things over HTTP at all, because the server responds, not with the content requested, but with a demand to use a different, more complicated protocol.
        • jchw 6y ago
          The justification for having most internet services adopt this standardized, patent-unencumbered protocol with multiple free and open source implementations is well documented; it’s become a best practice for many reasons. Your reasoning for not using one of the aforementioned implementations isn’t documented and is hard to guess. On the other hand, on a typical secured WiFi connection over TCP over an Ethernet connection, like 10 times more complicated stuff is going on in protocols and the software stack. It’s not as if we went from bit banging HTTP directly down an Ethernet cable to a hopelessly complex stack of software; we just added another element of complexity at the application layer in exchange for real security and privacy benefits. Example.com doesn’t need it but it has become a best practice for good reason so it is used on most of the net even when not strictly necessary. Enforcing HTTPS is a best practice because an absurdly overwhelming majority of user agents, like 4 or 5 nines of them, support HTTPS and the redirect ensures they use HTTPS and makes downgrade attacks a little more involved.
• uluyol 6y ago
  Please explain how it is more complicated. Also, QUIC is not just about the performance improvements offered today. Existing protocols like TCP and TLS are not really simpler than QUIC, you just don't think about them because we have implementations of them already. However, _changing_ TCP and TLS is extremely difficult to impossible because middleboxes snoop on traffic and mess it up in various ways. As an example, multipath TCP has been engineered to look like regular TCP and automatically downgrade to regular TCP if middleboxes can't handle it. Making this work is hard and 100% a waste of time just to work around the fact that people deploy these boxes. I believe TLS 1.3 also had deployment challenges due to middleboxes. QUIC encrypts ~everything so that middleboxes can't make broken assumptions and manipulate traffic. Adopting it is a one time pain that enable later improvements to be possible.
  • tialaramex 6y ago
    > I believe TLS 1.3 also had deployment challenges due to middleboxes. There was about one year delay between the point where the protocol was initially "done" and experiments showed it could not be deployed partly because of middleboxes although also due to server intolerance (web servers that go "What? TLS 1.3? No, rather than negotiating TLS 1.2 I'll just ignore you and hope you go away you weirdo") - until the point where the revised TLS 1.3 wire spelling was finished and tested (about six months before it was published as RFC 8446) The core idea in TLS 1.3 as shipped is that the initial setup phase looks outwardly very much like TLS 1.2 resumption. Interpreted as if it was TLS 1.2 the TLS 1.3 client claims to be trying to resume a previous connection, a TLS 1.3 server claims to accept that resumption, but really they actually just agreed a brand new connection. A TLS 1.2 server would see the resumption attempt, but it has no memory of any such prior connection (there wasn't one, the "connection ID" is just random bytes) so it offers a new one using TLS 1.2 and everything goes swimmingly. This way of doing things allows TLS 1.3 to be as fast on first connection as TLS 1.2 was on resumption without causing problems with incompatible middleboxes or servers. It does make the "spelling" on the wire pretty weird looking though if you are used to looking at TLS 1.2. The other essential goal was to never back off. A TLS 1.3 client will never go "Huh, TLS 1.3 didn't work, let's try again with TLS 1.2 instead". The design means if the remote server can speak TLS 1.2 (or 1.0 or 1.1) it will respond as such to your TLS 1.3 connection. This means adversaries can't try to "downgrade" you to a bad older version.
• bawolff 6y ago
  We have already forcing everyone to https started long before this. You control your computer - and want to mess with network traffic, make your own CA. Its not that hard.
• anuila 6y ago
  I can’t believe there are still people who are sour about the HTTPS push. Just people complaining that it makes their job harder when it clearly is a huge win for the end user. Do you know how many airport/business hotspots inject junk in your non-HTTPS pages? It’s totally worth spending 5 minute setting it up.
• GlitchMr 6y ago
  HTTP/2 and HTTP/3 don't require HTTPS because "it benefits Google" or whatever, but rather because it's the only way those protocols could be usable to begin with. It is possible to use HTTP/2 without HTTPS, but the problem is that there were a lot of systems that modified unencrypted HTTP traffic and got confused by HTTP/2 protocol - it looked nothing like HTTP/1. The easiest workaround for this issue was to require HTTPS, so that's what was done. Also when HTTPS is being used the server can say during TLS handshake that it supports HTTP/2 avoiding the cost in having to figure out whether the server supports HTTP/2 - this cannot be done with HTTP as there is no handshake. If a web browser were to assume the server supports HTTP/2 it would make initial HTTP/1 requests slower as it would have to try HTTP/2 first (and then you would have people complaining about Google making HTTP/1 slower to make HTTP/2 look more attractive). If a web browser would say that it supports HTTP/2 it would make HTTP/2 requests slower as it would have to try HTTP/1 first (which would slow down HTTP/2 when it was supposed to be fast).