I feel like it's poor taste to try invalidate an opponent's argument by associating them with some unrelated group that's en-vogue to hate. It doesn't add anything meaningful to the argument, it exists just to start fights, and it's a silencing tactic.
"But they're actually similar, their arguments are just like... blah blah." I don't care. It doesn't really matter. I would think we can do better than "this argument is bad because it sounds like this other bad thing."
We really need to stop with the glassy-eyed rhetoric about securing the web or the glorious utopia HTTPS everywhere will be or that people who dislike TLS hate security or puppies or whatever. If they're wrong or misinformed that's should be the end of it. The message should be concise and to the point.
TLS is worth it.
* Yes, it's going to be a PITA to implement and probably means retooling plenty of legacy systems. But the tooling to help is getting better.
* Trust will always be an issue. Certificate transparency is helping.
* Yes, it will require automation if you want a site to be accessible indefinitely. Yes, it does create more work for you to develop that automation or manually rotate certs.
* Yes, it is more complex than HTTP by a huge margin. Cryptography is hard. Security is hard.
* Yes, it's going to cause software rewrites.
* Yes, certificate expiration is a pain and will probably bite you in the ass a few times over your career.
* Yes, major players are going to reward your use of TLS and punish its absence. It's something you're just going to have to deal with.
Telling people that their problems aren't problems never solved anything.
I have to say, I find this article highly insulting. People who are skeptical of trends being pushed in the technology ecosystem are not the same as anti-vaxxers. Frankly, people who think that blindly following the edicts of self interested corporations will keep them safe are the ones who are deluded.
There are many good reasons to be suspicious of calls to deprecate things. Very often, when Google, Apple, or Microsoft announce that something is being deprecated, it is of no benefit to the end user, and is just a flimsy way of covering up a feature regression, or worse, a self serving attack on a technology that competes with their own.
Was anyone asking for the "save" feature to be removed from HTML5 video?
Does anyone seriously think that the locking down of app stores is about helping the user be secure, and not about stamping out competition?
There is no rational reason to not continue to support HTTP indefinitely. The fact that a user could potentially be tricked into going to an insecure site means absolutely nothing, because a user could be tricked into doing anything.
The fact that a browser might not give me, the user, the choice to do something potentially dangerous is ridiculous. HTTPS is not, and probably will never be as easy to set up as HTTP. Even if you had a script that could automatically configure my server, and continue to work reliably indefinitely (and you don't) it would still be inferior to HTTP.
I can access a service over HTTP from over a decade ago, and it will still work. I want to be able to, if I want to, with little effort, set up a server that can be accessed by a web browser. I do not want to have to have any third parties involved. I also do not want to have to set up a certificate authority or anything like that.
Companies like Google benefit from making the rules of what a web browser should be. They are happy to take the hit, if it makes it harder for everyone else. Does anyone think that Amazon.com wants to pay sales taxes? No, but by pressuring the government to collect taxes on them, it harms their competition more.
> There are many good reasons to be suspicious of calls to deprecate things.
What call to deprecation?
All that's being done is letting a user know if or if not their content could have arrived from the server without being intercepted.
> The fact that a browser might not give me, the user, the choice to do something potentially dangerous is ridiculous.
Currently, all browsers allow you to send generally sensitive information over HTTP, they just warn you first.
> I can access a service over HTTP from over a decade ago, and it will still work. I want to be able to, if I want to, with little effort, set up a server that can be accessed by a web browser. I do not want to have to have any third parties involved. I also do not want to have to set up a certificate authority or anything like that.
One point of the article is that nobody is trying to take HTTP away from anyone. I'm not aware of anyone removing HTTP support, just a change to the UI that communicates what guarantees you don't have for this connection.
It's really telling that every anti-HTTPS opinion I have ever heard expressed is either ten years out-of-date (too slow), or completely and totally bonkers (NSA backdoor).
It seems to me that for-profit bloggers will be contrarian for pageviews, and aren't afraid to lie if enough stupid people will believe them.
HTTPS is a pain compared to HTTP, and I should not be pressured to use it, especially if I am on an internal network. Lets Encrypt has made it much easier, but it is still a significant and unnecessary barrier. And as helpful as things like the Lets Encrypt bot is, it still cannot be relied upon.
And anyone who doesn't think we are being spied upon is bonkers. It doesn't matter how secure HTTPS is, because there are so many other ways we can be monitored.
> And anyone who doesn't think we are being spied upon is bonkers. It doesn't matter how secure HTTPS is, because there are so many other ways we can be monitored.
HTTPS doesn't guarantee that, and certainly isn't state-actor proof, but if state actors are your concern, you need more than HTTPS, not less.
What it does, is ensure nobody messed with the data before you get it. The browser indicates that to you.
Basically:
HTTP - Sir, are you aware someone may have changed what is in this enevelope?
HTTPS - Sir, this letter has/not been tampered with.
It's really telling that every pro HTTPS opinion is ten years out-of-date (you can totally trust the certificate authorities), or completely and totally bonkers (my site being injected is somehow my problem).
It seems to me that HTTPS advocates will follow a trend for pageviews, and aren't afraid to paper over HTTPS's glaring flaws if enough stupid people will believe them.
I thought this article was in poor taste and I actually have a lot of respect for Scott and the work he's doing in this space. For a better site with positive arguments for HTTPS: https://doesmysiteneedhttps.com/
I moved the non-profit's website I maintain over to HTTPs.
My own personal site has both. Though frankly that site is static. Oddly I find it useful to have that http site when trying to use some hotel wifi where you need to connect through a splash page. The https don't redirect..
I'm actually surprised this is an issue at this point.
> I find it useful to have that http site when trying to use some hotel wifi where you need to connect through a splash page
I’m in that situation frequently as well. While desktop Firefox deals with captive Wi-Fi portals, on mobile trying to open a personal site of mine over HTTP and letting the request get redirected seems to be the only way I can manage to unlock access to Wi-Fi in some airports.
Even though that site gets little to no traffic except for myself or occasional crawler, the situation bothers me. The reason HTTPS breaks poorly implemented captive portals is directly related to why we’d want HTTPS in the first place. Unreliable or absent HTTPS means a user visiting your site is susceptible to request & response manipulation and injections of undesirable content, from trackers to malware, by an ISP or another intermediary.
I get the same support requests all the time. "How do I know if my internet's broken???" Proceed to walk someone through 50 technical steps, when a button on a browser that the user could push would tell me everything I needed to know in one shot to fix their problem.
The problem with name-and-shame posts, other than their juvenile premise, is that you can read up on what the people in question say, and call the author on their shit. Once you do this, you realize that one these objectors is not like the others, because once you discount the last few entrants' unjustified snake oil and utter quackery, you're left with Dave Winer's objections to Google's strategy on increasing the adoption of HTTPS by more and more explicit visual indicators of HTTP being 'non-secure' [1] and Mozilla's differently-worded, but comparable approach to 'deprecating' HTTP.
By cherry-picking his most abrasive soundbites and his most entitled-sounding Twitter replies, Scott handwaves away Dave's more reasoned frustrations, such as his 2016 lament [3] that his current webhost doesn't offer a no-cost, push-button way of enabling HTTPS, and that his long-runing, statically-hosted blog would now require ongoing maintenance to stay compliant with the ever-changing list of requirements Chrome and Mozilla set in service of a larger goal. He wonders that if UI changes don't have the effect Chrome and Mozilla are hoping for, will more drastic changes follow, like refusing to display HTTP pages altogether, and reading his words he doesn't appear to buy that static, read-only sites need strong assurances of identity and resistance from third-party tampering, especially not at the risk of potentially making access to those pages impaired in the most popular browsers forever.
Dave clearly questions the true motives of Google's promotion of HTTPS, but Scott is right that Google never said that they'd deprecate HTTP. But Mozilla did [2].
I don't agree with all of Dave's points, and I think that for most of the websites people these days actually visit, strong assurances of identity and resistance from third-party tampering are important. But it's unfortunate that Scott tries to present an uncharitable view of Dave's worldview, instead of letting his points stand on their merits.
> It should be noted that this plan still allows for usage of the “http” URI scheme in legacy content.
Mozilla aren't deprecating access to HTTP, but rather new features for pages accessed over HTTP, features that can allow new attacks to surface for HTTP pages.
You should also note no date has been set, since that document was written three years ago.
I like how the author vacillates between "securing the web", "securing all traffic" and "encrypting the web". Because those things are totally the same thing.
I actually had a whole rant ready to go about how people pushing HTTPS like it's Web Contraception is actually harmful to end users and organizations alike, but it appears there are genuine whackos out there now who have picked up on all the flaws in HTTPS and are making up things as they go now. Interesting.
Comparing anti-HTTPS people to anti-vaxxers is a terrible comparison and obvious clickbait. If someone believes that HTTP is good enough, fine with me - it doesn't hurt anyone. If it's a company, their customers can take their business elsewhere if they care. On the other hand, anti-vaxxers cause harm to others due to herd immunity, plus their children usually have no choice in the matter.
I would agree with you if this was just a list of people who think HTTP is good enough.
If you read the article it's not "HTTP is good enough" it's "HTTPS is too slow" or "HTTPS is a plot by Google to take over the web" or fundamentally misunderstanding the value proposition of HTTPS or straight up lying about what it does.
Anti-vaxxers is absolutely a valid comparison here, the people in this blog aren't just not using HTTPS, they're actively encouraging people in their capacity as professionals to avoid using it, for really dumb and dangerous reasons that don't stand up to even the slightest scrutiny.
I think the overall quackery and use of bizarrely flawed and insane reasoning by charlatans is reminiscent of anti-vaxxers.
Additionally, I think use of HTTP over HTTPS could conceivably lead to actual harm for users unaware of the implications:
If for example commercial websites adopted the recommendations of switching to HTTP, people could actually lose money, so this may cause financial harm. Even worse, imagine, for instance, Facebook running over HTTP in an oppressive regime where, say, homosexuality was illegal; if this regime also didn't have enough clout to get Facebook to give them access to their data, then they could now more easily identify and persecute people for their communication content (same would go for dissidents or journalists if they used this), resulting in much worse harm to people than just losing money. There are many other examples were losing confidentiality or integrity of your communications can actually harm you, I just picked the first two that came to mind.
The fact that these diseases have not been totally eradicated does not prove that herd immunity is ineffective. On the contrary, these small outbreaks, as opposed to full-on plagues, show just how effective vaccination has been.
As for the "choice a child actually has"... wtf? You cannot have a meaningful discussion with an 18 month old child about the pros and cons of vaccination. You can barely have a meaningful conversation about eating carrots. Doctors vaccinate at that age because it saves lives.
I'm old enough to predate the MMR vaccine. I had mumps as a kid. It was awful. I still remember it, the pain, the not being able to open my mouth to eat. If my parents could have vaccinated me for that and failed, and I found out as an adult, I'd have been furious with them for exposing me to that suffering, not grateful for the choice.
"But they're actually similar, their arguments are just like... blah blah." I don't care. It doesn't really matter. I would think we can do better than "this argument is bad because it sounds like this other bad thing."
We really need to stop with the glassy-eyed rhetoric about securing the web or the glorious utopia HTTPS everywhere will be or that people who dislike TLS hate security or puppies or whatever. If they're wrong or misinformed that's should be the end of it. The message should be concise and to the point.
TLS is worth it.
* Yes, it's going to be a PITA to implement and probably means retooling plenty of legacy systems. But the tooling to help is getting better.
* Trust will always be an issue. Certificate transparency is helping.
* Yes, it will require automation if you want a site to be accessible indefinitely. Yes, it does create more work for you to develop that automation or manually rotate certs.
* Yes, it is more complex than HTTP by a huge margin. Cryptography is hard. Security is hard.
* Yes, it's going to cause software rewrites.
* Yes, certificate expiration is a pain and will probably bite you in the ass a few times over your career.
* Yes, major players are going to reward your use of TLS and punish its absence. It's something you're just going to have to deal with.
Telling people that their problems aren't problems never solved anything.