ckunte.net

-No- TLS

Update: I’ve now enabled TLS on this site, and url auto-redirection to https is now in effect. This should now all be seamless.


About a month ago, I turned-down the no-index switch on my site — a directive it carried since 2010, and Google like clock-work promptly elevated it to the top of its “Past year” search results. It looked fine, until I noticed https prefixed to my site URL. But I have not been serving my site over https, so this is annoying. Let me explain.

If a site seeks visitor’s inputs — secret or otherwise, then TLS (encrypting user information/query before transmission) is warranted. But my site is just a catalogue of information, and it seeks no information from a visitor, and so there’s no user interaction to protect. As a result, there is no need for transport layer security. In other words, I serve my site over http by design.

But when a non-https site is accessed through https protocol (thanks Google for incorrectly prefixing my site with https), the browser throws up a cautionary security warning — usually forcing an unsuspecting visitor to backtrack. So, going from complete-obscurity to being-warned-to-stay-away must be progress, I guess.

Two days after I write the above, Google says it will turn the knife in http beginning this July, despite Roy Fielding’s wisdom,1 one of the principal authors of http specification:

TLS does not provide privacy. What it does is disable anonymous access to ensure authority. It changes access patterns away from decentralized caching to more centralized authority control. That is the opposite of privacy. TLS is desirable for access to account-based services wherein anonymity is not a concern (and usually not even allowed). TLS is NOT desirable for access to public information, except in that it provides an ephemeral form of message integrity that is a weak replacement for content integrity.

[…] TLS everywhere is great for large companies with a financial stake in Internet centralization. It is even better for those providing identity services and TLS-outsourcing via CDNs. It’s a shame that the IETF has been abused in this way to promote a campaign that will effectively end anonymous access, under the guise of promoting privacy. […]

If the IETF wants to improve privacy, it should work on protocols that provide anonymous access to signed artifacts (authentication of the content, not the connection) that is independent of the user’s access mechanism.


  1. Para 2 and 3 have been reordered to improve readability and intent.