31–40 of 78 posts
I was going to comment that they would probably enjoy learning about Gopher, the competitor to http, which is a simple enough protocol to browse without a client, but they beat me to it when they brought up Gemini at the end of the article. Gemini they describe as similar to Gopher but with Markdown, then berate it for requiring TLS. Perhaps they can fork it.
HTTPS is great, of course, but there's still a place for plain HTTP. It is essential that HTTP continues to be universally supported (even behind the ridiculous warnings that browsers put these days). There are several, independent reasons for that: 1. You can build a complete http server and client from scratch with a manageable number of lines of assembly code, as has been demonstrated many times. The innocent "s"…
On private networks only, please. Otherwise, they will not be harmless for long.
> For static http pages with permanent content, encryption is not really necessary.
Unless you actually care about receiving the true content. Which, if you intend to reach that site, you probably do.
> now holds some power over your content.
That's simply untrue. Complete FUD.
> which is tantamount to shutting them down.
No it is not. Stop whining and go home
Earlier quoted context omitted.
Seems like a browser issue, not a website issue.
> Seems like a browser issue, not a website issue. That's why Mozilla and Google have been working on the transition to HTTPS for years. Mozilla announced deprecating HTTP back in Apr/2015 [1], to allow plenty of time for everyone to upgrade. 1. https://blog.mozilla.org/security/2015/04/30/deprecating-non...
Earlier quoted context omitted.
> Seems like a browser issue, not a website issue. That's why Mozilla and Google have been working on the transition to HTTPS for years. Mozilla announced deprecating HTTP back in Apr/2015 [1], to allow plenty of time for everyone to upgrade. 1. https://blog.mozilla.org/security/2015/04/30/deprecating-non...
Right, but if the security threat is the browser silently executing malicious code, shouldn't that be the fix, rather than the protocol? HTTP data itself isn't harmful.
A simple HTTP redirect to download a PDF file can also lead compromising the user's computer.
Earlier quoted context omitted.
Seems like a browser issue, not a website issue.
Browser's can't verify the integrity of website contents.
>While this push for security is good for protecting modern communication, there is a whole web full of information and services that don’t need to be secured It's not only about security. I wonder if it happens in other countries too - here in Russia ISPs used to inject advertisements directly into HTTP traffic which was very annoying and now they inject propaganda justifying the war. Fortunately very few sites use…
> Please don’t contact me to “well ackchyually” me and explain MITM attacks and how your terrible ISP inserts ads into your unencrypted web pages
Earlier quoted context omitted.
Right, but if the security threat is the browser silently executing malicious code, shouldn't that be the fix, rather than the protocol? HTTP data itself isn't harmful.
JavaScript code can be malicious, even while sandboxed (e.g. downloading a file). There are still dozens of browser security issues found and fixed every month. A simple HTTP redirect to download a PDF file can also lead compromising the user's computer.
>While this push for security is good for protecting modern communication, there is a whole web full of information and services that don’t need to be secured It's not only about security. I wonder if it happens in other countries too - here in Russia ISPs used to inject advertisements directly into HTTP traffic which was very annoying and now they inject propaganda justifying the war. Fortunately very few sites use…
That's still security, and such security is part of why HTTPS exists. TLS promises three things:
* Integrity :: that the two participants (for HTTPS this will be a web server and user agent) move data without anybody else getting to alter it successfully.
* Confidentiality :: that the two participants move data without anyone else learning what the data is [but they can learn when data is moved and a upper limit on how much data was moved]
* Authenticity :: that the participants can, at their option, reveal some proof of identity to the other tied to this TLS session. For HTTPS typically only web servers provide such identity, as a Certificate.
Injecting crap into your data is forbidden by the Integrity requirement.
HTTPS is great, of course, but there's still a place for plain HTTP. It is essential that HTTP continues to be universally supported (even behind the ridiculous warnings that browsers put these days). There are several, independent reasons for that: 1. You can build a complete http server and client from scratch with a manageable number of lines of assembly code, as has been demonstrated many times. The innocent "s"…
> Let's allow simple harmless things to stay around. On private networks only, please. Otherwise, they will not be harmless for long. > For static http pages with permanent content, encryption is not really necessary. Unless you actually care about receiving the true content. Which, if you intend to reach that site, you probably do. > now holds some power over your content. That's simply untrue. Complete FUD. > which…
Not always. My website is a sand castle in the beach. I take care of it and love it, but I don't mind if the wind takes it down, or if some kids destroy part of it, or if some idiot takes a photo of it and photoshops it in order to misrepresent my work. It is just a sand castle. However, I would feel really angry, frothing at the mouth angry, if I was forced to "register" my sand castle in some stupid place so that the passerby could be assured that it is mine, or otherwise not be allowed to build a sand castle at all. This is what I feel by being forced to use https just to store some irrelevant static files.
Regarding CA and censorship, what I said is true and can be verified with a small amount of googling. I don't have the patience right now to do that for you, surely another HN reader can provide the relevant references if you are honestly interested.
This page doesn't seem to grasp the reasons behind using encrypted connections. It's not some 'security' blanket statement or 'have something to hide', it's tamper-prevention (including MITM malware injection), privacy, and a little bit of identity verification (not really something people do in the real world). https://www.troyhunt.com/heres-why-your-static-website-needs... If your problem is some ancient device tha…