> Here's a good summary of the issues that are readily understandable:
> http://cryto.net/~joepie91/blog/2015/05/01/on-mozillas-forced-ssl/

The arguments could be better:

- Baseline Requirements are a thing and required for CAs to fulfill
  before they can be included into trust stores. Certificate
  Transparency is used to monitor issuing of new certificates and detect
  compromises.
- It doesn't merely provide confidentiality, but also ensures integrity
  of whatever I download (provided I'm not on corporate network and
  install their root CA). This is a low-effort way of ensuring third
  parties on the network can mess with something like packages downloaded
  via snow/akku. A workaround would be to use cryptographic signing, but
  that's a far bigger can of worms to get right.
- Let's Encrypt turned out to work just fine since that blog post. They
  support wildcards, though they require a DNS challenge. Mind you,
  wildcards are not recommended to be used (the argument is that a
  compromise of a server would allow serving arbitrary subdomains).

That leaves the argument that browser makers lock out features for
websites not using HTTPS, thereby raising the overall barrier to entry.
This is the only one I sympathize with. There should be no need to set
up HTTPS locally to do web development.

> The upshot for Scheme.org is that TLS is a standard which we must
> support.  But that doesn't mean we must _require_ it. I think we
> should continue to offer plain unencrypted HTTP access. That should be
> relatively uncontroversial for most of our sites, which host technical
> content that is readily available to the world from public git repos.

call-cc.org operates on this principle (the main reason being that
`chicken-install` has minimal dependencies and therefore cannot depend
on a TLS library), but had to do a lot of editing to use relative (when
referring to content on the same domain) or protocol-relative URLs (when
referring to content on a different domain/subdomain). Some people have
a policy of preferring https:// URLs whenever possible and the browser
not automatically redirecting them makes that more annoying.

> However, some of our sites will have a login feature. Currently the
> only one is Gitea but there will probably be more. Perhaps these
> should continue to require TLS so that passwords are not sent in the
> clear?

I'd still keep using TLS for delivery of source code meant to be
installed on other people's machines (like tarballs on snow/akku). I've
considered researching how hard it would be to pull off a MITM scenario
on package managers/repositories in the Emacs/Scheme/CL ecosystems, I
guess not terribly. Whether it makes sense to actively invest time into
it, no idea. What are your thoughts on this?