The solution could be Flash plug-in communicating secure connection status to the browser (absence of such or possible warnings). I think this is better option because Flash “knows” about all the browsers but browsers know little about Flash.

Hey, Adobe – Make it Possible! (or MS Silverlight will do it first).

jd/adobe

The alert message would only display with an application loaded over HTTPS attempted to make an HTTP call.

Having the user right-click (a hidden feature) to find out the security status would not solve this problem as most users would not know to do this. And what does mixed communication mean — does it mean that it’s loading a photo over HTTP or sending my credit card information?

The alternative is to do what Marc suggested and not allow HTTP calls in SWFs loaded via HTTPS.

I had a customer email me a few weeks ago asking where they could get to a secure order page. I was baffled because the order page was secure. Turns out it was because they were looking for the little lock icon on the page before starting the order process. Now… the page where they enter in the information WAS secure. But the page before that wasn’t and they didn’t dare click further.

This was a great reminder to me that ordinary users don’t understand security, when it’s appropriate, and when it’s safe to click on. It also reminded me that people do actually look for that lock icon.

Unfortunately because of this I don’t think users would ever understand those dialogs you presented. IMHO the flash player should not allow HTTP requests from a swf loaded over HTTPS. It limits applications but it doesn’t impose any additional requirements on what users’ understand to be “secure”.

Browsers shouldn’t punish the users of applications that are built poorly, when most people will click ‘OK’ to anything they are asked.

The problem is that _you_ are honest but we have to take your word for it. If only the whole world was full of people like you but unfortunately it’s not. Instead we have people who snoop data on open WiFi networks, engage in phishing attempts, and write Trojans.

This feature is one that those of us who _are_ honest should be pushing for. As I said in my article, it is meant to educate and build confidence in users. The more I think about it, the more I see it as a glaring security hole.

@Brian: Unfortunately, even large companies can handle sensitive data poorly. You need only skim this data loss list to see that the weakest link is again, usually human error (a lost laptop, for example). That could very easily be a missing “s” in the code that sends your credit card information over — it doesn’t even have to be on purpose.

And I’m not talking about scam sites here. This feature won’t deter against that (but browsers are building in better tools for alerting users to phishing attempts, etc., in any case).

This feature is simply to reassure users that they can still trust the “this page is secure” lock icon in their browsers with RIAs. The lock icon and HTTPS become meaningless for RIAs unless users know that the application is not going to make HTTP calls (and if it is, then the user should be alerted to this fact and have the option of canceling it.)

If I am shopping on a well known store site, Amazon, Gap, whatever, and they have a form that will take my credit card data, I quite blindly assume my data is going to be kept as safe as these companies can.

Conversely, if I run across a funky looking site where I am thinking of purchasing from, I usually do a search to see if anyone has complained about that site. Scam sites usually are pretty easy to ferret out with a simple google search.

Yet in each case, it is not the https icon I am looking for, I am looking for a company that feels reliable and solid. Because, in the end, even if I see the lock icon, I might feel as though my data got to the other end safer, but if the guys on that end decide to abuse it, well…

Seems like it would be nice to be able to assure users. Of course, not if it just ends up scaring them away from Flash. The pop-up warning box should be in terms my grandma would understand.

For instance, the product I work on generates two session tokens (one normal, one secure) for communication with the server. All safe/idempotent HTTP requests are made over HTTP with the normal session token, and all other request are made using the secure session token via HTTPS. The only non-idempotent request we allow over HTTP (using the normal token) is a FileReference.upload(), since we found the overhead of HTTPS for requests with binary payloads was too much for some slower clients.

The security sandboxing of the Flash Player has taken up uncountable hours of my time, so adding another level of complexity wouldn’t get my tick of approval.