> Every request is sensitive in the sense that it's another piece of data that can be used to build a tracking profile of the computer that sent it.
HTTPS does not protect you from third parties profiling what sites you visit, only the specific URL paths you access (since who you connect to is still in the clear).
In a big organization, a caching HTTP proxy server would provide the caching benefit, where an HTTPS-only Internet cannot. But while a home user has a single IP, all users behind a caching HTTP proxy server effectively share the same IP (or cluster of IPs), and are mix-anonymized (unless the proxy is not configured this way).
So sure - HTTPS ensures that URL paths accessed are private. But there are cases where there is a caching benefit and the real-world privacy-loss isn't as big as you make out in those situations.
If you're bothered about organizations spying on their users, then sure, those users can use HTTPS. My argument is about the cases where users are doing things where they want the caching though.
> Using HTTP takes that choice away.
Users and websites can still have the choice of using HTTPS. If we were talking about banning HTTPS or not requiring HTTPS to be available, then you'd have a point. But we're talking about banning HTTP. That takes choice away by definition, so don't pretend this is about taking choice away from users. In reality what you're arguing for here is to foist your choices about trading cacheability for privacy onto others by taking their choices away. There's nothing wrong with this position, but let's not pretend that it is something that it isn't.
I'm certainly in favor of sites being HTTPS only when they involve directly private information. I also accept that access to anything involves a tracking trail which in aggregate is privacy-sensitive. But where there is a caching benefit (or some other benefit) of not using HTTPS, perhaps users should have the choice to do so. Maybe clients shouldn't do it by default, and maybe it's reasonable for sites to always offer HTTPS as an option. Still, "don't ban HTTP" does have a case in such scenarios.
I think part of the problem here is that HTTP has spawned a number of use cases larger than any of us can contemplate at once. This is much broader than the general "web app" or "information browsing" use cases for which the HTTPS case is really important. "Ban HTTP" means banning all of these cases. It's very difficult to convince anyone that all use cases have really been genuinely considered on neutral grounds, and much easier to make the decision first and then pretend that workarounds are enough when a new use case is presented.
Implementing your suggestion would make things very convoluted when it all works perfectly already.
When I'm at work and want to access my online banking securely, I don't want my organization's proxy cache to MITM me. So I choose not to use my organization's MITM CA.
When I'm at work and am working on testing my reproducible server deployment, I really want to use my organization's caching proxy server so that I can download packages at 1 or 10 Gbit instead of the much lower speed of my organization's shared Internet connection.
This is very easily done right now: I use HTTPS for my online banking, and HTTP for my distribution package downloads. Everything points at my organization's proxy server, but no other special arrangements are required.
You're telling me that my organization has to roll out its own CA, implement HTTPS MITM caching, and I have to add the CA in my test deployment, all for what? So my organization can MITM my online banking, or that my organization's MITM proxy is now an additional attack surface for my online banking?
Sure, there are technical ways round this, but it involves jumping through hoops for no privacy gain. As I've pointed out elsewhere, downloading distribution packages over HTTPS offers no real privacy benefit since what users are downloading can be inferred from download sizes anyway.
Again: all I'm saying is that there are valid use cases for the current status quo.
This might sound like a stupid question, but unless I am grossly under-informed, with HTTPS, all a proxy server can do is forward the connection and the data.
The proxy could not see the URL(s) being requested, so caching is not going to work. Or is it?
The proxy can MITM the connection, as long as the browser accepts the proxy's certificate. Corporate environments tend to have their own CA infrastructure, so this isn't much of a problem for them.
> Corporate environments tend to have their own CA infrastructure, so this isn't much of a problem for them.
That's a very broad statement. Some corporate environments certainly do, and so this isn't much of a problem for them. But some corporate environments certainly do not, and so this is a problem for them. What you're essentially doing here is requiring that all corporate environments that don't currently have a CA infrastructure deploy one instead of using HTTP caching that works today. You're positively encouraging CA MITMing here.
HTTPS does not protect you from third parties profiling what sites you visit, only the specific URL paths you access (since who you connect to is still in the clear).
In a big organization, a caching HTTP proxy server would provide the caching benefit, where an HTTPS-only Internet cannot. But while a home user has a single IP, all users behind a caching HTTP proxy server effectively share the same IP (or cluster of IPs), and are mix-anonymized (unless the proxy is not configured this way).
So sure - HTTPS ensures that URL paths accessed are private. But there are cases where there is a caching benefit and the real-world privacy-loss isn't as big as you make out in those situations.
If you're bothered about organizations spying on their users, then sure, those users can use HTTPS. My argument is about the cases where users are doing things where they want the caching though.
> Using HTTP takes that choice away.
Users and websites can still have the choice of using HTTPS. If we were talking about banning HTTPS or not requiring HTTPS to be available, then you'd have a point. But we're talking about banning HTTP. That takes choice away by definition, so don't pretend this is about taking choice away from users. In reality what you're arguing for here is to foist your choices about trading cacheability for privacy onto others by taking their choices away. There's nothing wrong with this position, but let's not pretend that it is something that it isn't.
I'm certainly in favor of sites being HTTPS only when they involve directly private information. I also accept that access to anything involves a tracking trail which in aggregate is privacy-sensitive. But where there is a caching benefit (or some other benefit) of not using HTTPS, perhaps users should have the choice to do so. Maybe clients shouldn't do it by default, and maybe it's reasonable for sites to always offer HTTPS as an option. Still, "don't ban HTTP" does have a case in such scenarios.
I think part of the problem here is that HTTP has spawned a number of use cases larger than any of us can contemplate at once. This is much broader than the general "web app" or "information browsing" use cases for which the HTTPS case is really important. "Ban HTTP" means banning all of these cases. It's very difficult to convince anyone that all use cases have really been genuinely considered on neutral grounds, and much easier to make the decision first and then pretend that workarounds are enough when a new use case is presented.