Edit: Besides that problem #1 is offtopic since it has nothing to do with https and that 3/4 other points are captain obvious, #4 is actually a good one. It's so obscure that many will forget to enable it ("all pages are secured anyway"), but whenever a user visits any http page, an attacker can inject a small frame loading the http version of my website, and even if I redirect, the cookie was already sent and read by the attacker. Only an HSTS header or enabling the secure-cookie option protect against this.
If there was something worth protecting on a personal blog site, it might be a different story.
1 is very on-topic - there's no way that data should be sent in the clear.
HSTS is good, but unfortunately only partially supported. Agree on the secure cookie, but of course you need to drop the dependency on accessing it over HTTP before you do that.
> This blog isn’t terribly controversial. But if only the "controversial" stuff is private, then privacy is itself suspicious. Thus, privacy should be on by default.
HTTPS is not really that effective for privacy. An attacker can still see what site you visited (Well, the IP, but it would be fairly trivial to get the domain as well) and with a little bit of analysis could most likely make a fairly accurate educated guess about exactly which page you requested.
>> ...and with a little bit of analysis could most likely make a fairly accurate educated guess about exactly which page you requested.
Could you elaborate on this? I would have assumed that with the request URI being encrypted that this would be extremely difficult (load times/payload size maybe?) for all but the simplest of sites.
Yeah, essentially it comes down to timings/measuring payload lengths. Even for complex websites it may still be possible to attempt to infer what you're viewing. For example, if you are interested, take a look at this research paper which explains how to capture what a user is typing in an auto complete (i.e sends a request every time you type a character) box even over an encrypted connection:
Which could leak information about what you're looking at or looking for. The site is not mentioned specifically in the paper but Amazon uses a autocomplete for it's search which exhibits similar behaviour to what is discussed in the paper. So even on a site like Amazon if you visited it over a secure connection an attacker could most likely find out what you are searching for or looking at on Amazon.
I almost didn't read past the introduction, where he claimed a secure form in an unsecured page meant that the contents of the submitted form would be transmitted in the clear.
Edit: Besides that problem #1 is offtopic since it has nothing to do with https and that 3/4 other points are captain obvious, #4 is actually a good one. It's so obscure that many will forget to enable it ("all pages are secured anyway"), but whenever a user visits any http page, an attacker can inject a small frame loading the http version of my website, and even if I redirect, the cookie was already sent and read by the attacker. Only an HSTS header or enabling the secure-cookie option protect against this.