> Any random ISP, open wifi, or other entity could trivially MITM a popular site via HTTP and obtain privileges...
If a user is MITM'ed, it doesn't matter if some features are disabled. The attackers can do anything they damn well please, like directing the user to a compromised HTTPS site to access those features, or to a drive by download to do worse things.
Not true at all. A user's grant of permission applies to a particular site, and HTTPS ensures that nobody can spoof that site. If the user visits an HTTP page and an MITM attack redirects that to some HTTPS page elsewhere, that page will still have to ask the user for permission. But if HTTP pages can ask for permission to access those same features, then an MITM attacker can redirect to a spoofed version of a popular HTTP site that asks for that permission.
Concrete example: geolocation permission. You visit some popular mapping site that uses HTTP, and grant it persistent permission to use your location. Later, you browse something else via HTTP over a Tor connection. In that browsing session, if you saw any permission prompt for geolocation, you'd reject it. However, a malicious exit node could MITM you and use that to determine your location by pretending to be the mapping site, without a permission prompt.
Ditto for getUserMedia (webcam/audio), fullscreen, and any other permission a user can grant or deny on a site-by-site basis.
So, browsers want to drop the possibility to use those features from HTTP, not just to push sites to HTTPS but because the entire concept of granting permission only to a specific site doesn't doesn't work with HTTP.
When the user grants permission to a site, how does that permission work? By domain or resolved IP address? If it's by domain and there's no HPKP for it (and IP not cached), the MITM can send a malicious IP through DNS for any domain. The server at malicious IP can fake being whatever domain and the attack will work.
By domain. However, with a requirement for HTTPS, it doesn't matter if MITM hijacks that domain and points it at another IP, because the server on that IP can't present a valid certificate for that domain, so it won't load at all.
Pinning makes that even more secure, but even without pinning, requiring HTTPS raises the bar from a simple MITM to obtaining a fraudulent certificate from a trusted certificate authority (risking a blacklist of that CA in all browsers).
I think that instead of HPKP, the parent poster meant to refer to HSTS.
If the attacker MITMs an HTTPS request, then they have to provide a forged certificate (whether HSTS is set or not).
If the attacker MITMs an HTTP request which would have normally been redirected (e.g. typing "facebook.com" into the URL bar), then HSTS is required. Without it, no forged certificate required.
HTTPS and HSTS should have just been the baseline the web shipped with, but the web shipped before people thought about these things, and arguably before encryption was stable/secure/fast enough to be practical for the whole web.
I'm very happy that the federal HTTPS-policy includes an HSTS requirement for federal agencies: https://https.cio.gov/
However, even if the attacker MITMs an HTTP request that would have been redirected, for a site that didn't use HSTS, they won't get cookies marked "secure", and they won't get permissions that require HTTPS. So the browser mechanism limiting those permissions to HTTPS still works even in that case, though the user and site both have other problems.
They won't get secure cookies [for the site they're attacking], though they could plausibly redirect the user to a similar-looking HTTPS domain under their control and get permissions requiring a secure origin.
True, but they won't get permissions that the user grants on a site-by-site basis, which also means the attack can't silently happen in the background.
If a user is MITM'ed, it doesn't matter if some features are disabled. The attackers can do anything they damn well please, like directing the user to a compromised HTTPS site to access those features, or to a drive by download to do worse things.