Ars Technica has a longish post on the state of play regarding HTTPS. What it's good for, what it's not, who is pushing it, how browsers are reading it, etc.
The present humble website converted to https a couple of years ago after the divine Google decreed that it would be giving search preference to such sites. Since it's Google, there had to be an ulterior motive; the Ars article says it's because Google's competitors can't scrape search results from https -- is that true -- how creepy is that.
Being hustled in this fashion was horrible but for tommoody.us the only downside has been (i) paying some additional cash for the certificate and an IP address (still pretty cheap) and (ii) older pages with http image tags get the "partially secure" yellow warning flag in browsers.
To elaborate somewhat on (ii) -- according to the predominant, ultra-picky browsers, my posts with images prior to July 2014 don't rate the little green "secure lock" icon. The posts themselves are encrypted but because I used "http" in the text of the post at the time I uploaded the images, dumb browsers treat this as insecure, even though my host redirects all the http image requests to https before they reach the browser!
If I had better command line skills I would edit my MYSQL tables to convert all instances of "https://www.tommoody.us/images/..." in the text of posts to "https://www.tommoody.us/images/..." But I don't.
The Ars article mentions a change-in-the-works to the prevailing web protocol (W3C) that might solve this problem:
To prove that Barnes actually does care about URLs, he's the co-editor of a W3C specification that aims to preserve all those old links and upgrade them to HTTPS. The spec is known as HSTS priming, and it works with another proposed standard known as Upgrade Insecure Requests to offer the Web a kind of upgrade path around the link rot Berners-Lee fears.
With Upgrade Insecure Requests, site authors could tell a browser that they intend all resources to be loaded over HTTPS even if the link is HTTP. This solves the legacy content problem, particularly in cases where the content can't be updated (like, for example, The New York Times' archived sites).
Both of these proposals are still very early drafts, but they would, if implemented, provide a way around one of the biggest problems with HTTPS. At least, they'd prevent broken links some of the time. Totally abandoned content will never be upgraded to HTTPS, neither will content where the authors, like Winer, elect not to upgrade. This isn't a huge problem, though, because browsers will still happily load the insecure content (for now at least). [emphasis added by TM]
Probably by the time this W3C spec gets adopted Google will have forced us bloggers who aren't part of the Google Plus/Zuckerberg Hoodieverse to change our sites to something else entirely (moan).
Update: An emailer amends my statement "my host redirects all the http image requests to https before they reach the browser" to note that "your server sends a 302 redirect to the browser, telling it to make another request for the HTTPS url; the browser performs two requests." The point is the image is encrypted by the time it reaches the browser and the "yellow flag" designation is unfair.
The same emailer also suggests that I google "mysql change http urls to https" and thinks that leads to a non-command-line solution. Well, yes, that's the first thing I did, and Word Press recommends using phpMyAdmin to edit the MYSQL database. That requires what I called "command line skills" and I'm not comfortable with their suggestion, since every site has its own little nuances. I'd rather lobby for browser makers to be less aggressive about tainting sites with yellow flags.
Update 2: Thanks to mb for fixing this using phpMyAdmin -- those piss-yellow triangles no longer show up for my innocent, older posts.