5 ms·

Still plenty of websites which run on HTTP. I know mine certainly do. Security isn't everything, there's also accessibility to think about. HTTPS breaks in ma

Still plenty of websites which run on HTTP. I know mine certainly do. Security isn't everything, there's also accessibility to think about. HTTPS breaks in many circumstances when it's not needed, including on current browsers. You can also use a stripping proxy. Bigger issues I've encountered with actually using Mosaic is that a) it does not support the Host header, so you must have a dedicated IP address, and b) it doesn't like semicolons in then Content-Type header, which most of today's servers include.

imiric 4y ago
> Security isn't everything, there's also accessibility to think about. TLS is not just about security. It also protects the authenticity of your content, ensures privacy and even accessibility for your visitors. Without it, any node between your visitor and your server could inject content and JavaScript to do all sorts of nefarious tracking and profiling. These days there's really no excuse for using plain HTTP on public facing sites. Please rethink your decision.
- forgotmypw17 4y ago
  Actually, there is a very good excuse: I want to access the content I need with the browser and configuration I currently have, and without the ability to alter it. While the threat of MITM is technically true, thanks to being on a relatively safe networks segment, I have yet to encounter it happening in the real world, except in cases of captive portals, when I actually want it to happen. I think it is largely an over-stated threat for most read-only applications. The impact on accessibility, on the other hand, is real and huge.
  - neurostimulant 4y ago
    You must be lucky. My cellphone carrier used to injects scripts and ads on plain http requests. Imagine seeing ads on wikipedia. Now that https is everywhere, this behavior is largely stop.
    - forgotmypw17 4y ago
      I know that ads sometimes get injected for some people, but it has not been an issue for me. I see loud and intrusive ads on Wikipedia already, and it's why I've started using wikiless instead.
      - neurostimulant 4y ago
        Are you sure about seeing ads Wikipedia? AFAIK Wikipedia itself doesn't run any ads [1] (except occasional call for donation), so the ads must've come from other source (e.g malicious extensions, malwares that install mitm proxy to inject ads, etc). [1] https://en.wikipedia.org/wiki/Wikipedia:Funding_Wikipedia_through_advertisements https://en.wikipedia.org/wiki/Wikipedia:Funding_Wikipedia_th...
  - myfonj 4y ago
    There was similar discussion about "provide un-encrypted access to your pages for accessibility" few months ago here at HN under "Consider disabling HTTPS auto redirects" post [1]. [1] https://news.ycombinator.com/item?id=31895148 https://news.ycombinator.com/item?id=31895148
- Beldin 4y ago
  It's not just your site: an HTTP site allows for injecting HTTP urls for images/css files on other sites, e.g. <link src="http://target.site/..."> If target.site's auth or session cookies aren't properly protected, this is sufficient for stealing them [1]. And plenty of sites have insufficient protection on their cookies [1]. [1] http://www.open.ou.nl/hjo/papers/compsec21.pdf http://www.open.ou.nl/hjo/papers/compsec21.pdf
  - forgotmypw17 4y ago
    Thanks for the paper link. There are risks and there are benefits. Managing the risks to get the benefits is the game. My sites only use cookies for user preferences preferences and client-linked session tokens, so I am not too worried. A different way to mitigate the risks is by only storing information that does not need to be private, remaining small and un-interesting, designing for transparency and auditability, and keeping a close eye on those audit logs.

imiric 4y ago

> Security isn't everything, there's also accessibility to think about. TLS is not just about security. It also protects the authenticity of your content, ensures privacy and even accessibility for your visitors. Without it, any node between your visitor and your server could inject content and JavaScript to do all sorts of nefarious tracking and profiling. These days there's really no excuse for using plain HTTP on public facing sites. Please rethink your decision.

forgotmypw17 4y ago
Actually, there is a very good excuse: I want to access the content I need with the browser and configuration I currently have, and without the ability to alter it. While the threat of MITM is technically true, thanks to being on a relatively safe networks segment, I have yet to encounter it happening in the real world, except in cases of captive portals, when I actually want it to happen. I think it is largely an over-stated threat for most read-only applications. The impact on accessibility, on the other hand, is real and huge.
- neurostimulant 4y ago
  You must be lucky. My cellphone carrier used to injects scripts and ads on plain http requests. Imagine seeing ads on wikipedia. Now that https is everywhere, this behavior is largely stop.
  - forgotmypw17 4y ago
    I know that ads sometimes get injected for some people, but it has not been an issue for me. I see loud and intrusive ads on Wikipedia already, and it's why I've started using wikiless instead.
    - neurostimulant 4y ago
      Are you sure about seeing ads Wikipedia? AFAIK Wikipedia itself doesn't run any ads [1] (except occasional call for donation), so the ads must've come from other source (e.g malicious extensions, malwares that install mitm proxy to inject ads, etc). [1] https://en.wikipedia.org/wiki/Wikipedia:Funding_Wikipedia_through_advertisements https://en.wikipedia.org/wiki/Wikipedia:Funding_Wikipedia_th...
- myfonj 4y ago
  There was similar discussion about "provide un-encrypted access to your pages for accessibility" few months ago here at HN under "Consider disabling HTTPS auto redirects" post [1]. [1] https://news.ycombinator.com/item?id=31895148 https://news.ycombinator.com/item?id=31895148
Beldin 4y ago
It's not just your site: an HTTP site allows for injecting HTTP urls for images/css files on other sites, e.g. <link src="http://target.site/..."> If target.site's auth or session cookies aren't properly protected, this is sufficient for stealing them [1]. And plenty of sites have insufficient protection on their cookies [1]. [1] http://www.open.ou.nl/hjo/papers/compsec21.pdf http://www.open.ou.nl/hjo/papers/compsec21.pdf
- forgotmypw17 4y ago
  Thanks for the paper link. There are risks and there are benefits. Managing the risks to get the benefits is the game. My sites only use cookies for user preferences preferences and client-linked session tokens, so I am not too worried. A different way to mitigate the risks is by only storing information that does not need to be private, remaining small and un-interesting, designing for transparency and auditability, and keeping a close eye on those audit logs.