What happened was, Paul Hoffman, Lauren, and I were sitting up talking about privacy, looking at a WordPress blog, and this weird thing happened: We typed in its address with “https:” at the front, and it showed up as locked/HTTPS in some browsers but not others. It took quite a bit of poking around to figure out.
What’s actually happening · First, wordpress.com is perfectly happy to accept secure HTTPS connections. Good for them! (Although for something as intensely personal as blogging, I think there’s a strong case that they should force HTTPS for all connections from platforms that can handle it, i.e. anything later than XP).
First, it’s really lame that wordpress.com is doing this kind of insecure crap in the default themes that huge numbers of people use, creating privacy risks that don’t need to exist. Second, this is a common class of error, it happens all over the place. So, what should a browser do when it happens?
Safari · Here’s a screen shot:
That’s interesting: Safari goes ahead and runs the insecure code. But, in compensation, doesn’t show either the lock symbol or “https”.
I suppose you can make an argument that this is Apple It-Just-Works thinking, but the silent auto-security-downgrade makes me a little uncomfortable.
IE · IE 11 on Windows 7, to be precise. (Screenie courtesy of Paul Hoffman.)
It shows the secure HTML but no lock, and there’s a little notice at the bottom offering to “Show all content.” This is praiseworthy, except for the word “content” is a symptom of laziness, they know perfectly well that the security problem is around a script to be run, so why not say so? I’d be way more willing to “display insecure content” than “run insecure code”.
By the way, this a quite a bit different from IE10, which showed the lock and didn’t offer any way I could see to run the insecure code.
Firefox · It shows the lock and, like IE, doesn’t run the script.
But beside the lock in the address bar there’s a little shield thingie you can click on. Firefox still says “content” (it’s a script, dammit) but “blocking” is more accurate than IE’s “not displaying”.
Chrome · For the longest time, I thought Chrome, which shows the lock, just silently suppressed the unsafe bits. But then I noticed that it has a shield thingie too.
Chrome’s English is a little klunky (“includes script from unauthenticated sources”, sounds like a Russian Bond villain), but it’s perfectly comprehensible and way more accurate than any of the other browsers at informing a human what’s going on. On the other hand, I don’t like the shield hiding where it’ll never be seen, off at the right edge of the address bar.
These are all failure modes · The browser is trying to help ordinary civilian humans make a potentially-dangerous choice and it’s just not those people’ jobs to know this shit. Yeah, we can quibble about handling corner-cases elegantly and yeah, they matter.
But if your app is doing this to people, then you’re doing it wrong.