The new Chrome hack forces embeddable content hosting sites (e.g. imageshack) to choose between supporting https, or giving up the analytics data they gain from

The new Chrome hack forces embeddable content hosting sites (e.g. imageshack) to choose between supporting https, or giving up the analytics data they gain from being embedded on so many pages. It also forces sites with embedded content to implement hacks, converting img and other embed tag uris specified as http into https uris. But if the underlying page is loaded over https, obviously you either want to try getting the resource over https or not at all. What other sane thing is there for a web app to do other than convert all such uris from http to https when serving a page over https? Many uris will break that way, but it's better than not serving any of them. And, if that's the only sane thing for a webapp to do in that situation, why not put that logic into the web browser? As I mentioned in reply to gst, browsers supporting HSTS already have several modes of "force https for a uri specified as http". Adding one more hardly seems like an unacceptably ugly hack. Regardless, embedded content sites that would be swamped if all requests were over https, and sites that map http://foo http://foo and https://foo https://foo differently, are going to have to figure out solutions, or they'll stop being embedded as more sites enable https. Even under the status quo, mixed content warnings and symbols are a little bit scary and sites wishing to go https-enabled or https-only will encourage members to use embeddable content hosting services that support https.