Over the past couple of days, a debate has been raging over the security (or lack thereof) on MobileMe’s web services. While it’s obvious to anybody who is paying attention that the MobileMe web services do not use an SSL connection to secure any data beyond your password, a recent article by “Prince McLean” at AppleInsider implies that this is actually of no concern as the JSON data exchanges between the client and server apps are themselves secure:

Data transaction security in MobileMe’s web apps is based upon authenticated handling of JSON data exchanges between the self contained JavaScript client apps and Apple’s cloud, rather than the SSL web page encryption used by HTTPS. The only real web pages MobileMe exchanges with the server are the HTML, JavaScript, and CSS files that make up the application, which have no need for SSL encryption following the initial user authentication. This has caused some unnecessary panic among web users who have equated their browser’s SSL lock icon with web security. And of course, Internet email is not a secured medium anyway once it leaves your server.

Of course, whenever a comment like this is made, you can rest assured that there will be more than a few people who will be eager to check it out — in many cases simply out of idle curiosity.

Several posts in the comments to the above article (mine included) make the situation quite clear: The data exchanges between the MobileMe back-end and the user’s browser are definitely not in any way encrypted. Data transactions travel “in the clear.”

I won’t bother boring anybody with the details; Jens Alfke and Thomas Robinson have both already done an excellent job of clarifying the actual facts involved. However, despite this, the spreading of misinformation seems to continue largely unabated. In comments and responses to these posts, “Prince McLean” backpedals slightly in claiming that he never claimed that MobileMe was actually encrypting data, but that he was rather merely referring to the authentication aspect of the JSON apps that would prevent somebody from spoofing a MobileMe server. However, in the original article he goes on to say:

If Apple applied SSL encryption in the browser, it would only slow down every data exchange without really improving security, and instead only provide pundits with a false sense of security that distracts from real security threats.

The suggestion therefore obviously being that the JSON methodology he discusses is somehow better than SSL encryption, since SSL would not really do anything about “improving security.”

Statements such as these would clearly lead most readers to believe that MobileMe is in fact securing their data. Certainly this was the impression that I was left with on an initial read, and I was obviously not alone in this as I originally found the article linked on Daring Fireball, where John Gruber was initially under the same impression.

More importantly that this, however, is the new flavour of misinformation that now seems to have spread as a follow-up. In reading the responses from “Prince McLean” it is apparent that his tactics have changed to suggesting that his comments about SSL not providing any enhanced security are based upon his feeling that there really is no need to encrypt traffic on the Internet — that most “security experts” are really just evil sheisters promoting their own agendas by making us believe that sending confidential information around unencrypted is somehow a bad thing.

For instance, in a comment made by McLean in a response to Jens Alfke’s post, he states:

You also would never say your credit card number over the phone when ordering a pizza because somebody might be listening into your unencrypted phone conversation. Right.

Of course, if somebody has the capacity to sniff your local network traffic, you have already been compromised. They’re probably also going through your house taking DNA samples so they can clone you and replace you with a fake you.

The point that he seems to be missing here is that SSL encrypts your data in transit before it leaves your computer. The suggestion made elsewhere that Internet e-mail is inherently insecure anyway holds no water, since there’s a world of difference between sniffing SMTP sessions at a backbone router and doing it between your computer and the server.

The real goal of data security in this case is to secure the session between the end-user device and the destination server. This is the one area in which traffic is most vulnerable to interception and eavesdropping.

While one can acknowledge that the average user at home may be relatively unaffected by this (provided they’re using a properly WEP or WPA-secured wireless network or a wired connection) the whole argument breaks down significantly when dealing with the mobile user hopping across Wi-Fi access points. Most public Wi-Fi hotspots are unprotected, and therefore any hacker with any number of easily-available tools can sit in the local Starbucks and sniff away at all the data travelling unencrypted over-the-air.

WEP and WPA exist for a reason, but these unfortunately get in the way of most public hotspots by requiring a password to be used, so more often than not no encryption is used at all in these locations.

This is further complicated by the proliferation of “free” Wi-Fi hotspots out there that are actually being run independently, and some are even downright honeypots for intercepting and capturing whatever data they can. I have actually investigated a few of these, and while I’d be digressing by going into detail, the short version is that you should avoid any hotspot with a name like “Free Public Wi-Fi Access” like the plague.

As for real vs perceived threats, the balance is in creating a false sense of security versus recognizing that there really is no security present in this case. Suggesting with a bunch of bafflegab that the JSON exchanges are as secure as an SSL connection is definitely providing a false sense of security, luring the user into assuming that the transactions between the browser and MobileMe servers are every bit as secure as those with an HTTPS service like GMail, when in fact this is patently untrue.

Now, for most of the transactions that I would engage in via a web browser in a public location, I probably don’t care all that much, but at the same time it’s important that people understand that sending out e-mails that might contain sensitive information is a bad idea in these situations. Educating people on the risks of such things is never a bad thing, while spreading apologist propaganda that leads people to believe their data is secure when it’s obviously not goes much too far in the opposing direction.