Even protocol state (equivalents of TCP FIN/SYN/etc) is encrypted, to ensure that middleboxes don't get ideas about what the protocol is 'supposed' to do - ideas which make it hard to change the protocol in the future.
That's the simplest explanation, though, so that's probably what happened. Oh well.
There are hundreds of thousands of organizations that need inspection and caching and proxying of internal www traffic. That all protocols should disallow or frustrate this disregards real needs of users and organizations.
Further still, if protocols can't be designed to be implemented easily or to allow for implementation bugs or lack of features, it's a crap protocol or application. Middleware will always be necessary, and encryption really shouldn't change the requirements of how middleware needs to work with a protocol.
IOW, it's completely fair to argue that users might not have a universal right to encryption, but it's just as legitimate to argue that browser vendors have no obligation to enable the trivial circumvention of encryption. If the software doesn't work for your needs, then stop using the software.
The middleware should require effort to install, and it should be obvious when it is active. Otherwise, companies which have no business MITM'ing the traffic -- such as ISPs and free wifi providers -- will start to do it just because it's so simple.
For example, Google may require MDM app on the Android devices which is used to access corporate data. This app ensures that the device has the right policy (screen lock, encryption) and I think it may also check for malware apps. This is how it should be -- if you need corporate control over devices, install special application on it, it will be more efficient and it will do more.
Nobody made that argument. But browser makers have an obligation to keep the world wide web usable. If it's not usable, say goodbye to dot com companies selling services to businesses, which aside from advertising revenue (and the hopes and dreams of venture capitalists) is the only way they survive.
The only reasonable alternative if you start locking out legitimate business use cases of traffic inspection is to abandon the web and start making proprietary native applications and protocols like back in the old days. This is bad for users and bad for business.
It's not like it's even hard to support these use cases while maintaining user security! Browsers just totally suck at interfacing with a dynamic user role. Better UX and a more flexible protocol would solve this, but nobody wants to make browsers easier to use (more the opposite)
As a regular user, I can't just use a captive portal to get free wifi, because any site I go to has HTTPS, so they all break and I can't accept the god damn HTTP accept page unless I can conjure up a valid domain that has no HTTPS like I'm Svengali. Now all the OSes have special checks to see if there's a captive portal because the browsers couldn't be troubled to build a function for it, even though it would improve their security and usability at the same time.
Captive portals are not the enemy. Shitty UX and a bad attitude toward the needs of real users is. Locking browsers/protocols down more is just doubling down on this mentality.
Then continue to use the encryption that exists today. After all, your concern is for future standards that make encryption stronger.
> And fork a browser? Are you nuts?
A lone user forking a browser would be nuts. A company that's already willing to pay through the nose for MITM proxies can afford to fund a minor browser fork. Indeed, if this use case is as important as you suspect, then you ought to start a company that sells customized browsers for exactly this purpose. Think about what site you're on; where's your entrepreneurial spirit? :)
> But browser makers have an obligation to keep the world wide web usable.
Usable for whom? Between users (who need strong encryption), websites (who need strong encryption), and corporate intranets (who need to snoop), whose needs ought to be prioritized?
> abandon the web and start making proprietary native applications
The web emerged from a world where all applications were native and proprietary, I don't think any browser vendor is losing sleep over this possibility.
> Browsers just totally suck at interfacing with a dynamic user role.
Again, sounds like there's demand for a new browser then. :)
> nobody wants to make browsers easier to use (more the opposite)
Why is that?
Every non-Microsoft browser vendor used to cry themselves to sleep at night from days fighting against vendor lock-ins and corruption of standards. They certainly care if it all goes south.
I suppose people don't want easier browsers because they imagine they are easy enough and can't imagine something better. At least I hope that's the reason, and not that they fear change, or are indifferent to the needs of people other than themselves and prefer to design for that alone.
There's no way in hell I'm crazy enough to make a browser, though. I'd rather run for elected office, or eat an entire Volkswagen Golf.
Were you writing a forum post? It was lost because it got submitted to captive portal. Were you in dynamic app? It crashed because it got HTML instead of JSON. Does you page reload ads in the i-frames? Your page position and page itself is now lost, and you are in captive portal page. Did you have a native app which did HTTP requests and cached them? Congrats, you have invalid data in your cache now.
And I have seen captive portals which were broken. How about you get redirected to login page every time you go to your favorite website, because the redirect page got cached somehow?
Good riddance. Yes, the browsers should include better captive portal support like android does, possibly triggered by the SSL certificate mismatch errors, but even the current situation when I have to type "aaa.com" by hand all the time is great.