> The additional time to deliver a document over HTTPS is imperceptible to humans on any remotely modern (last ~15 years) hardware on almost any connection outs

> The additional time to deliver a document over HTTPS is imperceptible to humans on any remotely modern (last ~15 years) hardware on almost any connection outside of the absolute worst network environments. b:~[0]# time curl --no-progress-meter --output /dev/null http://noiseprotocol.org real 0m0,353s user 0m0,004s sys 0m0,003s b:~[0]# time curl --no-progress-meter --output /dev/null https://noiseprotocol.org real 0m0,705s user 0m0,041s sys 0m0,006s b:~[0]# It takes double the time to load the page with TLS. No matter the hardware and network (tested with high bandwidth low latency not congested FTTH) you can't go faster than the speed of light and the additional TLS handshake does not make loading any faster. Notice also the increase in CPU time when using HTTPS (user field in time). > That it doesn't receive sensitive data is moot -- it sends what can easily be considered sensitive data. White papers about encryption and obfuscation protocols are often of interests to, for example, political dissidents both in countries where they're at risk and abroad, and they may be targeted in either case. Modern extensions like ECH (which is beginning to be widely available[0]) offer a degree of protection against that, and prevent snooping in general. AFAIK ECH only works with a central MiTM proxy like cloudflare, not with a selfhosted page. It's debatable what privacy implications hosting using cloudflare has. You cannot prevent the hostname from being sent in plaintext to a selfhosted third party website if you want SNI, which servers often expect clients to send. EDIT: ECH is disabled globally on Cloudflare currently: https://developers.cloudflare.com/ssl/edge-certificates/ech/ https://developers.cloudflare.com/ssl/edge-certificates/ech/ Whenever you connect via TLS, Firefox sends an unencrypted OCSP HTTP request to the CA servers that includes the hostname. Yet another thing that slows you down when requesting websites protected by TLS that wasn't measured in my curl benchmark (unless OCSP stapling is used, of course). > Political dissidents aside, it's another channel advertisers can use to see your browsing habits and build up a targeted advertising profile. There have been isolated incidents where ISPs were caught injecting ads into users' pages; I think a more realistic issue would be ISPs auctioning off browsing histories. ISPs can only do that if you allow them to. Where I live, they can't; it's forbidden by law and network history is considered personal data. Injecting ads is also illegal where I live; ISPs tampering with anything above layer 3 is not allowed as per Internet neutrality laws here. Just the IP address is enough to figure out someone is browsing the Noise Protocol website: Try visiting http://138.68.46.44 http://138.68.46.44 > I wouldn't have noticed that that document is plain-HTTP if not for the fact that I decided to toggle Firefox's HTTP-only mode earlier that day just to see what impact it has on day-to-day browsing. Maybe set this your browser up so that it automatically changes the protocol to HTTPS from HTTP without failing? This way, you wouldn't've noticed any issue at all. Bottom line: There is no reason to force users to use TLS on noiseprotocol.org and doing so would be worse for users of the website without providing much benefits.