TLS everywhere is great for large companies with a financial stake in Internet centralization. It is even better for those providing identity services and TLS-outsourcing via CDNs. It's a shame that the IETF has been abused in this way to promote a campaign that will effectively end anonymous access, under the guise of promoting privacy.
I think he makes a very good point here: if browsers did not support plaintext HTTP at all, and only CA-verified TLS, it would be practically impossible for those who want to run a server somewhere, to anonymously serve a site containing public information. If everyone has to obtain a certificate from a CA, that is another way they can be tracked by a central authority.
> if browsers did not support plaintext HTTP at all, and only CA-verified TLS
That's a very big "if", and it reeks of FUD.
Show me a browser that has any plan to drop support for plaintext HTTP any time in the foreseeable future.
Firefox ain't one of them. Last time I checked, their plan was to reserve some of the more dangerous features (such as access to the camera) for secure websites. Hardly a plan to drop support for plaintext HTTP.
If you still aren't convinced that the current controversy is just a bunch of FUD, I'll bet $100 that 10 years from now, I'll still be able to post public information (say, the full text of RFC 2616) on a plain HTTP site and have you access it with a mainstream browser.
A very big "if" indeed, but not a completely unrealistic assumption in my opinion.
It will not happen at once but gradually.
Neither Firefox nor Chrome intend to support plain HTTP/2 without encryption. Google already favors pages with TLS, my bet is they will also favor HTTP/2 sometime soon. Like you said: Browser will "reserve some of the more dangerous features (such as access to the camera) for secure websites.". They might even show a red bar for HTTP instead of a green one for HTTPS.
> ... that 10 years from now, I'll still be able to post public
> information (say, the full text of RFC 2616) on a plain HTTP site
> and have you access it with a mainstream browser.
I'm sure you are right. We will be able to use HTTP in 10 years much in the sense that we are still able to use RSS today.
I don't know whether to laugh or cry about this but it is what I see coming.
When abortion was legalized, some people argued that we'd be murdering children soon. Has that happened?
If something is moving in the right direction, but if you're worried that it will go too far, the solution is to get involved and stop it at the right time, not to spread FUD about the hypothetical doom of the world.
> Firefox ain't one of them. Last time I checked, their plan was to reserve some of the more dangerous features (such as access to the camera) for secure websites. Hardly a plan to drop support for plaintext HTTP.
So basically, by your own admission, you say that websites with a near-future version of Firefox will only be able to offer a "full" web-experience if they are offered via HTTPS.
HTTP-based websites will be reserved for an inferior web.
> Classic slippery slope argument.
But somehow saying that this is moving in a HTTPS-only direction is a slippery slope argument? How long until Javacript is only allowed via HTTPS? How long until video and media-APIs will only work with a "secure" DRMed connection, signed by the MPAA?
Taking HTTPS everywhere and removing support for HTTP is the slippery slope and we're already walking it.
Every feature of every part of the HTML spec has to be supported for every transport. End of discussion.
HTTPS everywhere is a misguided effort. Trying to artificially limit HTTP to further your cause is just GOT-level political bullshit. Stop playing dishonestly. If HTTPS everywhere can't win through on its own merits, you should let it die.
> How long until video and media-APIs will only worked with a "secure" DRMed connection, signed by the MPAA?
The slope is so slippery I think I might actually fall off my chair. I don't think you know what the fallacy actually is.
There's no arguing against facts - moving to promote HTTPS and make some features HTTPS-only does go in that direction. But that doesn't mean things will continue going in that direction.
If I keep driving north I'm sure I'll fall off a cliff eventually. The magic happens because the road isn't straight.
> Every feature of every part of the HTML spec has to be supported for every transport. End of discussion.
Where does that feeling of entitlement come from? What makes you think you have the right to access my camera or microphone via your web page, or even execute arbitrary JS on my computer in the first place? Websites have no right to do such things. They are privileges that I grant on a case-by-case basis via my user-agent and various plugins. You don't even have any guarantee that your DOM and CSS will render as you intended, because I block all sorts of things and sometimes even tweak the styles to make the content more readable. My computer, my rules.
So I see no problem with restricting websites to a known-to-be-safe subset of features by default, until and unless a website can demonstrate that they take my privacy and security seriously. Privileges must be earned, not taken for granted, and ruthlessly revoked at the first sign of misuse.
The HTML spec describes the maximum privileges that a website can hope to have, not the minimum that it can expect to have. If your website doesn't need any special privileges, feel free to use whatever transport you want.
> If everyone has to obtain a certificate from a CA, that is another way they can be tracked
They have to be tracked just as much even without that. They have to give their credentials to the hosting provider and to the DNS provider. Even if they didn't and plugged their server directly to the backbone, their IP address and traceroute would leak information about their location.
That said, your point is valid in a parallel universe where anyone could run an anonymous server without registering for DNS or contacting an ISP or a hosting provider or anything at all.
But in that universe, clients would have no way to know if that server contains valid information or data that was substituted on-the-fly. Imagine WWII-style Radio Londres, but one day the broadcast is substituted by one that looks like it comes from Charles de Gaulle, and gives the wrong instructions.
> They have to give their credentials to the hosting provider and to the DNS provider.
Back in the real world you don't need a hosting provider nor DNS to serve a website.
The following is a real address: http://123.234.34.56 (although it doesn't currently point to any real webserver)
You can probably trace the ISP it belongs to, but if that ISP is in another country than the regime you want to hide from, they need to launch a cross-country, international police-investigation, and possibly defend their claims through a trial, to get authorities in that country to force that ISP to divulge the identify of the customer at the other end of that IP.
Being able to serve websites anonymously, through plain HTTP and no hosting-partner DNS is a very real option. With today's high-speed internet connections it's a more real option than ever before.
Pretending this option doesn't exist doesn't lend your arguments any favour.
> You can probably trace the ISP it belongs to, but if that ISP is in another country than the regime you want to hide from, they need to launch a cross-country, international police-investigation, and possibly defend their claims through a trial, to get authorities in that country to force that ISP to divulge the identify of the customer at the other end of that IP.
Which is different from getting the identity of someone who registered a HTTPS certificate with a CA in another country how?
This is why the people advocating this are also advocating alternative CAs like letsencrypt, where the process is automated, only requires proof you control the domain (no real world info needed), and is free. Thus, the CA model is used, but only at a bare minimum.
Then again, I'd like to see browsers support an encryption model based on DNS records, using one of the many unused crypto record types, like KEY, for delivering the private key's fingerprint. For basic use, there would be no need for an outside party to verify its validity, just that the connection isn't being tampered with. This way, there's no tracking by a central authority unless one wants or needs further verification.
I think he makes a very good point here: if browsers did not support plaintext HTTP at all, and only CA-verified TLS, it would be practically impossible for those who want to run a server somewhere, to anonymously serve a site containing public information. If everyone has to obtain a certificate from a CA, that is another way they can be tracked by a central authority.