webshit weekly (2017/07/21)
An annotated digest of the top "Hacker" "News" posts for the third week of July, 2017.
July 15, 2017 (comments)
Some bureaucrats make boring decisions about meaningless garbage. Hackernews feels vindicated, and celebrates by rehashing ancient tribal lore. The arguments start with "misunderstanding the terms of the document" and move through "misunderstanding the terms of all documents" before settling on "zero-knowledge declaration of best practices." Nothing useful is even brought up, much less discussed.
July 16, 2017 (comments)
An internet posts to Forbes to link to Twitter. Hackernews argues about whether it's better to work at a place where you have to treat your management team like a debt collector or whether it's better to just start out rich. Every single comment is replied to with "well that's not the norm," followed by an anecdote the responder insists is the actual norm.
July 17, 2017 (comments)
An internet mentions that current "deep" "learning" tactics maybe aren't perfect. Hackernews is comfortable with the fact that the class of computing they refer to as "deep learning" has nothing to do with learning and the only "depth" is the pile of bullshit they proceed to spew about how the real problem is pretending computers are people. Some time is spent replacing existing misconceptions with new, more dangerous misconceptions. Everyone agrees that the solution is more abstraction, and all current problems are the fault of those lazy assholes over in the biology sector.
July 18, 2017 (comments)
Big Pharma continues the war against its own users. Hackernews is sorry that people are needlessly dying, but it just costs too much money to know things. Better luck next time!
July 19, 2017 (comments)
Bitcoin Idiots, LLC watches another batch of feckless morons get their toys stolen. Hackernews sagely gathers around the campfire to explain that Bitcoin Idiots, LLC committed a cardinal sin: programming computers without asking Mozilla how to do it right. Hackernews can't figure out how any of the affected parties can continue living after having lost so much money, never stopping to notice that there was no money at all involved.
July 20, 2017 (comments)
An internet posts a tabloid story about a medical case. Hackernews (all of whom are neurologists) bikesheds the tabloid. The rest of the comments are people translating everything into computer analogies for the readers unwilling to pretend they have medical degrees.
July 21, 2017 (comments)
An internet makes a bash script to encrypt things. Hackernews dives into a multi-hour argument about how to make files appear in two places at once. Once someone notices this particular program exposes metadata and isn't generally as useful as real password managers, the floodgates of self-promotion open as every single Hackernews links to the github url of every home-built password manager ever made.
webshit weekly (2017/07/14)
An annotated digest of the top "Hacker" "News" posts for the second week of July, 2017.
July 08, 2017 (comments)
An internet posts some pictures of war. Hackernews is primarily concerned with whose fault war is, but not to the degree that they can't take some time to shit on the quality of the photos, the intentions of everyone involved, and the person who took the pictures.
July 09, 2017 (comments)
An internet debugs some shitty software. No solutions are forthcoming. One Hackernews goes on a completely unrelated rant about other shitty software, which prompts an explosion of unrelated garbage from uninvolved onlookers. The rest of the comments are people telling each other to buy Apple products, since those are infallible.
July 10, 2017 (comments)
An internet notices that a top-level domain is run by cretins. Hackernews points out the United Kingdom is morally reprehensible, then daydreams about using this sort of administrative vulnerability to defraud people on the web. Naturally, the weapon of choice would be Let's Encrypt. Someone mentions that several other ccTLDs got burned as well, reinforcing the fact that everything except .com will forever be a second-class citizen.
July 11, 2017 (comments)
Some internets attempt to fight lobbyists. Hackernews debates why and invents six thousand inaccurate analogies to explain the situation. One Hackernews gets angry that the topic of discussion focuses on America, as though anyone gives a shit about network policies anywhere else.
July 12, 2017 (comments)
Google would like the government to protect its ability to monitor all humans equally. Hackernews recommends that Google quit fucking around and openly dictate government policy. The usefulness of a nuclear second-strike capability is debated for some reason. The rest of the comments are armchair quarterbacking the entire concept of network neutrality.
July 13, 2017 (comments)
Lifetime Bell Labs intern Russ Cox promises that his boss will care more about your opinions. Hackernews threatens to shoot down the International Space Station unless someone brings them generics. The Rust Evangelism Strike Force circulates plainclothes agents in the crowd to disperse pamphlets.
July 14, 2017 (comments)
An over-engineered data cache receives further overengineering. Lots of noise occurs about "clustering" and "distributed". The cache now officially supports the Raspberry Pi -- and since the Redis developers are still not aware that processors can have more than one core, running it will not affect the real databases you run with the rest of your CPU. Hackernews spends all day bickering about the use of the term 'slave.' Again.
Discourse on HTTPS (2017/07/12)
An internet lectures passersby about webshit. The lectures are sprinkled with advertisements for an HTTP server that runs as root. We are expected to take security advice from this person seriously.
We do not.
Your site needs HTTPS.
"But my site doesn't have forms or collect information from users."
Doesn't matter. HTTPS protects more than just form data! HTTPS keeps the URLs, headers, and contents of all transferred pages confidential.
If I wanted confidentiality, maybe I'd care about HTTPS. But I don't, and if someone else does, they can acquire it themselves. My site does not need HTTPS.
"There's nothing sensitive on my site anyway."
Your site is a liability! Just because your site is hosted safely in your account doesn't mean it won't travel through cables and boxes controlled by who knows how many corporate- and state-owned entities. Do you really want someone injecting scripts, images, or ad content onto your page so that it looks like you put them there? Or changing the words on your page? Or using your site to attack other sites? This stuff happens: on airlines (a lot, and again), in China, even ISPs do it (a lot). And HTTPS prevents all of it. It guarantees content integrity and the ability to detect tampering. If we encrypt only secret content, then we automatically paint a target on those transmissions. Keep which of your transmissions contain secrets secret by encrypting everything.
None of those things are my problem. If people don't want to see my site with random trash inserted into it, they can choose not to access it through broken and/or compromised networks. If other website operators are concerned about this sort of thing, they are free to use HTTPS, but I have no reason to do so. Encryption should be available to anyone who wants to serve encrypted content, but I have no interest in using it for my website. It's a shame that people are using web browsers (note: not my website, but BROWSERS) as attack vectors. The legions of browser programmers employed by Mozilla, Google, Apple, and Microsoft should do something about that. It's not my flaw to fix, because it's a problem with the clients. My site does not need HTTPS.
"The site is HTTP, but our forms are submitted over HTTPS."
This is as bad as not using any HTTPS at all! All the attacker has to do is change the link or form action to a URL on his/her own server. There's no way to detect this because it happens over the wire with plain HTTP. Encrypt the WHOLE site and redirect HTTP to HTTPS.
This is a great reason to use HTTPS! It has nothing to do with my website, which does not have any interactive elements whatsoever. I don't use forms. What is there to attack? Nothing: my site does not need HTTPS.
"I can't afford a certificate."
I hope they soon become freely available from competent people as well. Meanwhile, I'll continue to pay for SSL certificates when I need them -- which is not for my website, because my site does not need HTTPS.
"HTTPS is difficult to set up and maintain."
Sure! I'll reengineer everything to use some hipster http server, which doesn't even run on half of the operating systems I use. What could be easier? No, thanks; my site does not need HTTPS.
"Attackers can still impersonate my site, even if I use HTTPS."
They can try, but as long as your private key stays private, browsers will show warnings if attackers present a mismatched or invalid TLS certificate. And if the attacker does not use HTTPS at all, browsers should mark the imposter page as insecure. To this end, HTTPS guarantees authenticity.
This is only true as long as some asshole certificate authority does not issue illegitimate certificates for my website. Good thing that doesn't happen, over and over and over and over. You can't convincingly pretend to be me if I don't make any promises about who I am, so my site does not need HTTPS.
"Domain-validated (DV) certificates aren't secure."
Yes they are. Just don't lose control over your DNS and choose a competent certificate authority (as opposed to less competent or troublesome ones). There is absolutely no difference in the cryptography in a DV certificate compared to that of an extended validation (EV) certificate.
Earlier you recommended letsencrypt, and now suddenly you want me to pick a competent certificate authority? The only reason they didn't leak my info already is because my site does not need HTTPS.
"But CAs can misissue for my site any day <...or any other complaint about the CA system>."
Look, this discussion isn't about PKI. It's the best system we've got for right now. Deal with it and secure your site. Use CAA records to restrict which CAs can issue certificates for your site, then cross your fingers and hope transparency and oversight works (it does, so far).
Your "best system" is a trash fire and gains me nothing. I will not participate; my site is secure enough for my desires without it. As an industry, take a breath and get your shit together, and get back to me when you're not such a goddamn embarrassment. I will not have to cross my fingers because my site does not need HTTPS.
"HTTPS doesn't hide the size of the content, leaking clues to attackers."
TLS 1.3 and HTTP/2 have padding frames to inflate the size of the ciphertext.
Super! Let me know when those get out of draft spec status and into something I can feasibly implement. Actually, don't; I do not need those technologies because my site does not need HTTPS.
"HTTPS doesn't hide the DNS lookup."
Of course not. DNS != HTTP. But is that really a valid reason not to encrypt the connection between your website and its visitors?? (Hint: no.)
This is indeed a pretty stupid objection to have against HTTPS. Fortunately I do not care whether the user's DNS lookups are hidden. I don't care if anything is hidden. So even though we're in agreement about this not being a valid objection: my site does not need HTTPS.
"HTTPS is slow."
No it's not. Sites with modern servers load faster over HTTPS than over HTTP because of HTTP/2.
...assuming you use HTTP/2. Which I will not. Anyway, I don't care whether HTTPS is slow, because my site does not need HTTPS.
"Phishing sites use HTTPS."
... so you won't?
No, but for entirely non-phishing related reasons. I won't use HTTPS because my site does not need HTTPS.
"Our site displays ads over HTTP."
Sorry, not sorry. Doesn't change the fact that your site still needs HTTPS. Switching to HTTPS with ads still over HTTP will cause mixed content warnings in browsers, so you better figure out a cute way to wiggle out of that ad publishing contract that looked really attractive when you first signed it, or convince your ad network to move to HTTPS before you do.
Obviously my site does not display ads; as has been pointed out, It does not even appear to be monetized. This is because I have a real job and the entire web ad industry can fuck itself off a cliff. So, while mixed-content warnings are pretty obnoxious, my site does not need HTTPS.
"It works over HTTP just fine."
That's what Oil and Gas International thought, too. Until browsers started flagging HTTP pages as insecure.
Good thing I'm not Oil and Gas International! I don't personally care if browsers flag HTTP pages as insecure, as insecurity does not materially affect my site. It works perfectly well right now, because my site does not need HTTPS.
"But TLS proxies break the guarantees of HTTPS."
Only if the end user's computer is modified to trust the TLS proxy. This requires administrator (root) privileges, so the owner of the computer must allow it. Besides, HTTPS interception can usually be detected by web servers.
First of all, there are plenty of circumstances in which root is not required to trust a CA. But that's not really the point here: this is all just handwaving away the earlier whining about how governments and ISPs are molesting HTTP traffic. If your government is actively hostile to your communications, overthrow it. If you think J. Random User is going to give a single shit (or even notice) when the telco provider ships a phone update that adds trust to MITM certs, you're completely delusional. So, yes. TLS proxies do break the "guarantees" of HTTPS. It's just software. It can't fix your society. Fortunately, none of that affects me, because my site does not need HTTPS.
"At least I can still serve my site over both HTTP and HTTPS."
The only reason you should open port 80 on your server is to redirect all requests to port 443 and then close the connection on port 80. (Someday, maybe we can drop port 80 altogether.)
I'll do whatever the fuck I please over port 80, thanks. I will abstain from port 443, because my site does not need HTTPS.
"My site is only accessible internally or with a VPN."
How much do you trust the corporation or state that owns the infrastructure? And the companies that produced the hardware that comprises your network? Or the VPN provider?
Far, far more than I trust you. I can sue my networking vendors for failure to meet the terms of their contract. What's my remediation for your bad advice? Anyway, I don't need to trust a VPN. This site is not intended to be encrypted at all, so my site does not need HTTPS.
"We hash the passwords."
Good for you. Now please tell me you're collecting them via HTTPS. ... you are, right?
I'll do you one better: I don't collect passwords at all! Only an asshole would build plaintext auth, so I agree that passwords should only be sent across encrypted connections -- but my site does not need HTTPS.
"HTTPS impacts SEO."
You're right—HTTPS improves it! Switching site URLs improperly may impact your search rankings, but HTTPS actually improves them. Just do the switch properly according to the search engine you're optimizing for, and everything will be fine, with only temporary side-effects at most.
I do not give a shit about SEO and I fervently wish for the speedy retirement of everyone who does. SEO shitbags rank with email spammers as the absolute lowest pigshit dirtfuck dregs of humanity. The world would be a better place without any of their noise. SEO is not of interest to me: one more reason my site does not need HTTPS.
"It's the browser's job to keep users safe."
True, but incomplete. It is not SOLELY the browser's job. Browsers can only keep the users safe if the server provides credentials through an HTTPS certificate. As a site owner, it's your responsibility to provide these credentials for your clients.
Horseshit. Users must keep themselves safe. Software can't ever do that for you. Users are on their own to ensure they use a quality web client, on a computer they're reasonably sure is well-maintained, over an internet connection that is not run by people who hate them. None of the packets I send out are unsafe, so my site does not need HTTPS.
— HOW TO GET ON HTTPS —
The easiest way is through Let's Encrypt and the Caddy web server, which enables HTTPS for all your sites automatically. You can also use a simple, stand-alone Let's Encrypt client called lego, which runs on every platform.
If you prefer a little more setup and system integration with traditional web servers, the EFF's client Certbot will suit you well.
There are plenty of other ways to get your site on HTTPS without much trouble. Das Surma has a guide for several web servers and CDNs like Cloudflare can make your site available over HTTPS for minimal fees, if any at all.
I don't really care how to get on HTTPS, because my site does not need HTTPS.