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 WiFi access points. Most public WiFi 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” WiFi 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.

(Disclaimer: I am a security consultant as part of my day job. I write for iLounge as a part-time hobby. My full-time job is doing IT Consulting for major corporations and Canadian Federal Government agencies. My credentials include discovering one of the only security flaws ever found in Novell’s GroupWise product).

As an IT Consultant, I am frequently working in various locations at different clients’ sites, and it’s nice to have my Powerbook secure itself when I’m away from the machine. In addition, my other objectives are to keep the OS X Address Book application connected and to iSync my phone whenever it moves back within proximity of my machine.

Ideally, I would want to activate the OS X screen saver and enable the password protection when I move away from my computer (out of Bluetooth range), but otherwise I’d prefer to keep the screen saver password off for normal use, as it gets quite annoying when I’m working near the computer to have to continually re-enter my password after I’ve diverted my attention elsewhere for a few minutes (which happens frequently, as often the Powerbook sits to one side of other systems that I’m working with, rather than being in constant use).

Presently, the only software solution that will actually handle this with any kind of transparency from a security point of view is a tool called Home Zone that has been only recently released in beta form. While Home Zone looks like an excellent package to keep an eye on, it’s fairly new and may also be a bit more complex than the requirements of a basic Bluetooth proximity detection system. One neat feature, however, is that it also adds WiFi detection to the mix. Home Zone also includes pre-defined actions to do things like Enabling and Disabling the screen saver password, a task that is otherwise more difficult to accomplish than one might expect.

Unfortunately, as of Beta 7, I had little success getting it to reliably detect the presence of a Bluetooth device even in the simplest configuration, and it became frustrating to have my screensaver kick in on me while I was working on the computer only because Home Zone had lost track of the Bluetooth device.

Another excellent tool that will handle proximity detection as part of its much more robust suite of features is Salling Clicker. This is an absolutely outstanding application, but again one that goes well beyond basic proximity detection. Further, since Salling Clicker is really just AppleScript-based in it’s operations, the basic solution and scripts that I describe below can easily be adapted into that as well (in fact, even though I’m a licensed user and big fan of Salling Clicker, the only reason I’m not using it for this purpose today is that proximity detection is not yet supported with the Nokia E62 that I use).

The tool I ultimately chose for the purpose of the detection itself is a little free app appropriately called Proximity. This is a thin little program that does one thing, but does it well—that is to sit in the background and scan for a given Bluetooth device at regular intervals. When it detects a change in the device’s availability, it simply calls one of two Applescripts: One for the device leaving range, and another for when the device enters range.

So, armed with that I set out to create two Applescripts that would perform the following tasks:

When the Bluetooth Device enters range:

• Deactivate the Screen Saver Password.
• Deactivate the Screen Saver.
• Reconnect the phone to the OS X Address Book

• Sync the phone using iSync

  When the Bluetooth Device leaves range:

• Activate the Screen Saver Password.

• Activate the Screen Saver.

  Activating the screen saver and performing an iSync are both tasks that are trivial to perform via Applescript. Reconnecting the Address Book and enabling and disabling the screen saver password protection is considerably more complicated, however, as I quickly discovered.

  I should point out that most of what I am documenting here has been gleaned from various corners of the web, and therefore most of the ideas are not specifically my own. However, I decided to try and document some of this in one place in order to hopefully save others the several hours of searching that it took me to put it all together.

  Activating and Deactivating the Screen Saver

  Activating and Deactivating the screen saver itself is trivial to do through Applescript simply through the use of the following two Applescript commands:

  Activating the Screen Saver:

  tell application “ScreenSaverEngine” to activate

  Deactivating the Screen Saver:

       tell application “ScreenSaverEngine” to quit

  Performing an iSync

  Likewise, once iSync itself has been properly configured for your phone, performing an iSync is not much more complicated. A basic sync is performed with the following command:

       tell application “iSync” to synchronize

  However, for my own purposes, I chose to expand upon this. Specifically, I decided there was no point in having iSync automatically sync more often than every 15 minutes or so. This prevents it from kicking in every time I happen to wander away from the computer and back. The following script will only tell iSync to synchronize if a sync has not occurred in the last 900 seconds (15 minutes):

       tell application "iSync"
          if last sync is less than ((current date) - 900) then
              synchronize
          end if
       end tell
  
  

  Further, since the iSync window will otherwise tend to come up and get in the way when this happens, I prefer to keep it hidden with the following additional command:

       tell application "System Events" to set visible of process "iSync" to false

  This will have the effect of running iSync if the phone has not been synced in the last 15 minutes, and immediately hiding the iSync window from view. The iSync will continue to run in the background until it completes.

  Reconnecting to the Address Book

  Although Bluetooth support in the OS X Address Book is a very cool feature, the reality is that it has been poorly implemented up to this point in terms of it’s ability to stay connected to a Bluetooth phone, or even in terms of making this process scriptable via Applescript.

  Fortunately, this was discussed some time ago in the Salling Clicker forums and incorporated into the proximity scripts that are included with Salling Clicker. The solution, it would seem, is to toggle an internal Address Book preference to force it look for its associated Bluetooth device the next time it starts up, and then just shut down the Address Book app and restart it. This is accomplished with the following snippet of code, which is a simplification of code pulled from the “Keep Address Book Connected” script included with Salling Clicker

       tell application "Address Book"
            if not unsaved then
                 try
                      quit
                      delay 1
                 end try
            end if
       end tell
  
       do shell script "defaults write com.apple.AddressBook ABCheckForPhoneNextTime -boolean true"
       try
            tell application "Address Book" to launch
            tell application "System Events"
                 set the visible of process "Address Book" to no
            end tell
       end try
  

  Placed within the script that executes when entering proximity, this will toggle the option to find a Bluetooth device ON in the Address Book preferences, and then shut down and restart the Address Book app. It’s messy, but it does work.

  (I’m sure I’m not alone in hoping that Apple makes this function accessible through Applescript in Leopard).

  The Final Challenge: Enabling and Disabling the Screen Saver Password

  The final hurdle in this process was programmatically changing the password protection on the OS X screen saver. While this is handled very elegantly by the Home Zone application that I mentioned at the beginning of this article, I wanted to find a way to do it programmatically through Applescript myself for various reasons. It turns out this process was slightly more complex than I had initially suspected.

  Firstly, the preference that determines whether the OS X screen saver asks for a password is stored within each user’s local preferences, specifically in the com.apple.screensaver domain. The preference file itself is a little tricky, as it is named based on a host ID. Fortunately, it can be accessed using the built-in “defaults” command-line tool. The specific key is “askForPassword” and contains an integer value of zero or one to determine whether the screensaver prompts for a password or not.

  The following command, executed in terminal or from a “do shell script” within Applescript, will set this value to enable password protection on the screen saver:

       defaults -currentHost write com.apple.screensaver askForPassword -int 1
  
  

  This is well-documented in several places on the Internet, although there a couple of important things that should be noted.

  Firstly, it is necessary to specify the “-int” parameter. Without it, the “defaults” command will write the value as a string value, which will be treated as an “OFF” setting regardless of the content. More specifically, anything in that key other than an integer 1 will disable the screen saver password.

  More importantly, however, this setting does not take effect immediately…. Either the System Preferences application must be opened and other changes made, or the user must log out and back in. This is because the password requirement is only read by the “loginwindow” process.

  By default, changes in the “System Preferences” app in OS X will send a notification to the loginwindow process to re-read these settings. However, to change the setting programmatically and have it take effect immediately, it’s necessary to find an alternative way to refresh the loginwindow process.

  After much digging, the solution was found in a thread on the macosxhints forum, in the last post by Guillaime O. Specifically, Guilaime provides a snippet of C code that can be quickly and easily compiled into an executable to perform this specific function.

       #include <CoreFoundation/CoreFoundation.h>
       int main(int argc, char ** argv)
            {
             CFMessagePortRef port = CFMessagePortCreateRemote(NULL, CFSTR("com.apple.loginwindow.notify"));
             CFMessagePortSendRequest(port, 500, 0, 0, 0, 0, 0);
             CFRelease(port);
             return 0;
            }
  
  

  This code can simply be compiled with the built-in C compiler on OS X (if you have the Development Tools installed), and then simply put somewhere in the path. Then, immediately after running the “defaults” command to set the screen saver password state, simply call this application to refresh the “loginwindow” process and re-read the “askForPassword” setting.

  For my own purposes, I just went with the suggested name of “notif” for the executable, but it can of course be named anything you like.

  The Final Result

  So, after all is said and done, the final result is the following two scripts:

  Entering Proximity.scpt

  
       -- Disable the screen Saver Password
       do shell script "defaults -currentHost write com.apple.screensaver askForPassword -int 0"
       do shell script "notif"
       -- Turn OFF the screen saver
       tell application "ScreenSaverEngine" to quit
       tell application "Address Book"
            if not unsaved then
                 try
                      quit
                      delay 1
                 end try
            end if
       end tell
       -- Reconnect to the Address Book
       do shell script "defaults write com.apple.AddressBook ABCheckForPhoneNextTime -boolean true"
       try
            tell application "Address Book"
                 launch
            end tell
            tell application "System Events"
                 set the visible of process "Address Book" to no
            end tell
       end try
       -- Synchronize the Device
       tell application "iSync"
            if last sync is less than ((current date) - 900) then
                 synchronize
            end if
       end tell
       tell application "System Events" to set visible of process "iSync" to false
  

  Leaving Proximity.scpt

  
       -- Turn on the screen saver password
       do shell script "defaults -currentHost write com.apple.screensaver askForPassword -int 1"
       do shell script "notif"
       -- Activate the screen saver
       tell application "ScreenSaverEngine" to activate
  

  Other Possible Tricks

  One other approach I had tried was to make use of the “CGSession” command to do a lock by returning to the actual login screen (effectively a fast-user-switching feature that presents the login screen without logging the user out). While this was a very neat solution, it lacked the intuitive “unlock” feature, since once returning to the login screen, there was really no way to get back in without a password (at least not a simple method that I have yet discovered without embedding my password somewhere in the file).

  However, for those interested, the following Applescript entry will accomplish this task:

       
       do shell script "/System/Library/CoreServices/
            Menu\\ Extras/User.menu/Contents/Resources/CGSession -suspend"
  
  

  This works reasonably well, and the entering proximity script will even run in the background, so the only disadvantage is that you are forced to log in manually when you return to the computer, and there is a small delay in this process.

  Once thing I was able to do with this, however, was to combine it with another tool, the excellent SleepWatcher daemon, to allow me to run shell scripts when the computer wakes or sleeps. I simply instruct SleepWatcher to run a script including the above command with a slight delay to allow it to complete, and then whenever the computer goes to sleep, my session is returned to the log in screen.

  While the Bluetooth proximity detection feature will also address this (if the computer is awakened without the necessary Bluetooth device nearby), this option is slightly more secure, and allows for the ability for somebody else to log onto the computer if necessary (a screen saver password would restrict access to the currently logged in user only).

  References & Acknowledgements

  Again, most of what is discussed in here has been gleaned and put together from information in various places on the Internet. Specifically, the following should be acknowledged:
  

  Proximity 1.0	A very simple and effective free Bluetooth Proximity detection tool for Mac OS X
  Home Zone beta 7	A very slick up-and-coming solution by Jonas Witt to set parameters based on “Zones” which are in turn based upon WiFi and Bluetooth proximity.
  Salling Clicker 3.0.1	Jonas Salling’s absolutely outstanding Bluetooth remote control and proximity detection app, and the source for the Address Book reconnect script included above.
  SleepWatcher 2.0.4	A neat little daemon by Bernhard Baehr to monitor and execute shell scripts based on sleep and wake events.
  Mac OS X Hints	Most of the solutions and script snippets regarding the screen saver password protection came from the Mac OS X Hints forum. Specifically, the simple but indispensable C code for the “notif” application was contributed to these forums in a post by Guillame O.

  ]]> http://www.technocrat.ca/?feed=rss2&p=44 140