Hacker News Reader

Comment by blackhaz | Hacker News Reader

And it's OK. This "HTTPS everywhere" concept is damaging. I think it should be revised. The amount of overhead and the lack of ability to optimize encrypted content for transferring over, say, satellite or other radio links, is bad. Lots of people still use very expensive (>$2,000 per Mbps) long-RTT connections that would benefit immensely from content optimization techniques. And most of them are cost-sensitive because they live in developing countries.

View on HN

You mean that super costly 1KB in front of a request that pulls extra megabyte of data on a typical website? I really hope you missed a /s

I can save about 30% of traffic by optimizing content via HTTP. Can't do that with HTTPS without MITM or similar questionable practices breaking the purpose of HTTPS. While you're sitting on a 100+ Mbps DSL, somebody in the middle of Africa is struggling on an ISDN-like link.

Optimise for the most common case. I imagine there are far more people in the US with broadband connections being put at risk of MITM attacks than people in Kenya with very slow internet trying to look at the US governments website.

I am not against HTTPS per se. Use it for sensitive content.

How do you get around the risk of MITM attacks? It's a sensitive site, given the level of authority it carries for the average user.

If you live in a country where you can't trust your ISP then there is a very real MITM risk.

What exactly are these techniques that work in plain HTTP but not in HTTPS? It seems like the difference between the two does not pertain to the actual content at all, but I am more curious than knowledgeable in this case.

Intermediate nodes can cache http traffic, but not https.

Also intermediate nodes could compress or shrink images or do similar types of things.

> Also intermediate nodes could compress or shrink images or do similar types of things.

And we come back a full circle. Even if the image is not sensitive, I'm glad I can force https to workaround my ISP being "helpful" and shrinking images.

As far as I'm concerned, that third parties can change the content of a response mid-air is exactly the reason that you should use HTTPS. If you rely on handing unencrypted data over the internet to a third party provider, you have to accept that other parties may also modify the requests and their responses.

You may think that it isn't a big deal because you aren't serving sensitive information, but if your users are dropping in from a random hotspot or are in one of the countries where ISPs seem to be able to do whatever the hell they want, there are tons of possible intrusions, ranging from inserting ads or replacing the entire response with a gentle reminder to pay your internet bill, to inserting outright malicious software.

It's like leaving your front door unlocked just for the convenience of being able to walk inside without unlocking it.

Supporting caching doesn't necessarily mean intermediates can modify the requests/responses mid-air. You can still hash and sign content, and servers can cache these responses.

Nonetheless, that approach seems to be a way of the past. HTTPS is essentially expected now, so CDNs are required to achieve similar performance - Great news for CDNs ;)

The trade-off is worth it. By a large margin.

YMMV.

In my consistent experience over 5+ years, https always performs worse on poor-quality mobile connections here in the UK. In rural areas with EDGE or poor 3G, a given site will simply not load over https but it will (slowly) over http.

So the trade-off for me is between "senate.gov doesn't load, at all" and "senate.gov does load, but may leak the information to someone that I was looking at senate.gov, or may potentially be MITMed to give me misleading information about the US senate".

The balance of probabilities is such that the trade-off of enforced HTTPS everywhere, on sites like that, is _not_ worth it for me. I obviously don't object to people using HTTPS who want to. Nor do I object to sites where a MITM attack would be catastrophic (e.g. banks) requiring it. What I object to is that, where there's a balance-of-probabilities decision, I am increasingly no longer empowered to take that decision for myself, and the result is that I simply can't view many websites in particular circumstances.

Throwaway because being anything other than 100% supportive of HTTPS is the surest way to burn karma on HN.

In this case, the site is enforcing HTTP - you can't view it on HTTPS.

So serve the same content over both http and https and let the user choose.

That said, if making the site very low bandwidth were the goal I would start by removing the pointless images.

Wouldn't that be a whole new level of "premature optimization"? Serve https by default and also http for those still needs it for the reasons you outline.

This is almost as bad as when people were arguing against long signatures on Usenet.

https is the least of your worries in terms of overhead.

> benefit immensely from content optimization techniques. And most of them are cost-sensitive because they live in developing countries You can't optimise the size of encrypted content until you've downloaded it. It could go through a third party on your behalf but then they argue, what's the point in the encryption at all.

Frameworks everywhere! :)

Something like gzip that "all" browsers and servers support? Which i would belive more than makes up for any https overhead.

They're proposing lossy compression. That'd be a neat feature though, during the negotiation (once your comms are encrypted) you could ask the server to perform lossy compression on certain resources, would save battery life on the mobile client as well!

That's kind of what mobile sites do. They shrink the size of the site making it simpler and smaller.

Reply on news.ycombinator.com