3 ms·

Sorry, but your comment is literally all wrong.

• rsync 10y ago
  Have you ever built toolchains on top of parsing web resources with unix primitives ? Adding SSL makes it a lot more complex and limits your toolset dramatically. If your source is sensitive, by all means - use SSL. I don't think anyone would argue with that. But if you provide a useful resource that isn't sensitive or controversial (say, for instance, the weather) why would you want to chop off so much interoperability ? I guess if the only way you've every used the web is with a web browser, this doesn't make any sense to you.
  • pfg 10y ago
    mholt is the lead developer of Caddy[1], so it's probably safe to assume that he knows a bit about this. The goal behind the HTTPS everywhere effort isn't just to encrypt private data, but also to provide authentication for your content. ISPs are known to interfere with HTTP requests, injecting ads, malware and what not. That's something that affects anyone, even static sites. [1]: https://caddyserver.com/ https://caddyserver.com/
  • mholt 10y ago
    This has nothing to do with complexity or tooling. Many people, including you, forget that TLS protects content from tampering. ISPs, captive portals, and other network entities are known for injecting ads or intercepting transmissions. Imagine your liability if a bad actor is injecting child porn on your site to a large portion of your audience. This isn't unheard of, by the way. Arguably less criminal, even Comcast is known for injecting content into pages.[1] [1]: https://gist.github.com/ryankearney/4146814 https://gist.github.com/ryankearney/4146814