Posted via web from Falling Toward Apotheosis

To be clear, this doesn't in any way mean that I have plans to abandon my i-Device ecosystem. However, the buzz surrounding Android, particularly with the impending release of Android 2.2 has piqued my interest.  Plus, I want to get my hands on an official, original, Google-branded (and unlocked) Nexus One before they shutter their online store for good and move to a more typical carrier sales model.

Even in the current pre-Froyo iterations, Android has some interesting and appealing features.  As one would expect from a Google device, it's far more cloud-connected already with its Google services integrations, and looks poised to become even more so as things like Simplify Media come into the picture.

While iPhone OS 4 promises some interesting things, it seems that Apple is still way behind the curve when it comes to a world without wires. The iPhone (and iPad, and iPod touch) remain cryptically tethered to an iTunes-centric world for media sync, and while there's no doubt that Apple is working on better solutions, they're moving at their typically glacial pace in doing so—the Apple TV introduced Wi-Fi based syncing back in 2007, so it's obviously not only possible, but in fact is already built into iTunes.  Sure, performance, particularly over 802.11b/g might be a dog for syncing your entire library, but it would certainly suffice for keeping podcast subscriptions and basic smart playlists up to date.  With Apple's recent acquisitions and patent portfolio, it seems that something really cool may be coming around the corner, but that corner might still be several blocks (or years) away. Apple's priorities are clearly focused on providing a smooth user experience rather than cutting edge bells and whistles—to put it simply they would rather leave a feature out entirely than do a half-baked version of it.

Don't get me wrong—I do respect Apple's approach, or at the very least I've learned to appreciate it.

You see, Android sounds in many ways like a nerd's dream, with extensive customization options and lots of shiny features to play with.  My twenty-something self would have been all over that, and probably wouldn't have even gone near an iPhone in the first place.  These days, however, I prefer a platform that "just works" for what I need it to do and doesn't get in the way.  The iPhone has proven to be that platform. However, the view from the cheap seats, at least, suggests that Android may be getting there. We'll see once I actually have one in my hands to play with for a while.  

(Admittedly, however, there's still some of that twenty-something kid left in me—the one that gets hooked on "shiny new toy syndrome" every once in a while and needs some new bells and whistles to be entertained by.)

That said, I most certainly still plan to also get a next-generation iPhone when it arrives next month. By that time, Android 2.2 will likely have surfaced for general consumption, which will make for an interesting showdown between what have effectively become the two juggernauts of the smartphone industry.

Posted via email from Falling Toward Apotheosis

My exposure to computers prior to that time had been hanging out in the local Radio Shack while the long-suffering employees kindly let me tinker with the TRS-80s. In fact, I’d go so far as to check out books on programming from the local library and then bring them with me to Radio Shack to experiment. The Atari 2600 was one of the first pieces of computer technology that entered my home (my father’s TI-58C notwithstanding)—and in fact in those days Atari even marketed it as the “Atari 2060 VCS” for “Video Computer System.”

I specifically remember finding the hidden easter egg in Adventure in the early eighties (all on my own—there was no Gamefaq or Wikipedia in those days) seeing the programmer’s signature and desperately trying to figure out if there was a way to access the source code or any other hidden features through that screen. In fact I probably spent more time playing around in that one hidden room to look for additional secrets than I did actually playing the game.

The fact is that it’s never been only about hardware tinkering. Sure, I had fun hacking around inside PCs, building a Z80 system from scratch, and so forth, but there was also plenty of room for software tinkering even back then, and it had nothing whatsoever to do with how physically open the computers or other devices were.

Today these opportunities have only expanded, with many more software development platforms available, more secrets to discover, and more opportunities to share and collaborate on findings. Back in 2007 when I was fiddling with my first-generation iPhone and trying to get it unlocked to work up here in the Great White North, I learned more about the iPhone OS than I ever would have with a screwdriver and soldering iron.

I don’t care how many screws you put into the casing of any modern device—there’s nothing in there that’s much worth looking at any more anyway, and that’s not Apple’s fault, but rather the inevitable result of progress. I have great respect for Cory Doctorow, but in this case he’s tilting at windmills; to put the power and capabilities of an iPad into tinkerable hardware it would likely end up being the size of a large suitcase, at best. The Makers among us may be okay with that, but I’ll pass—I’ve already had a Compaq Portable and really have no desire to return to those halcyon days.

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 http://www.technocrat.ca/?p=45 http://www.technocrat.ca/?p=45#comments Fri, 22 Dec 2006 15:05:00 +0000 Jesse David Hollington http://hollington.ca/technocrat/?p=45 The press on Apple’s Dot Mac service has been mediocre at a best lately, and one doesn’t have to look very far to find commentary berating it for any number of reasons such as the price tag, the lack of features compared to many of the other offerings out there, or just the performance of it in general.

  Even the recent improvements to the web mail and address book interface were met with mixed reviews, with the general feeling being that it was about time Apple caught up with the other technology out there.
  
  However, I think that many people are really missing the point of what .Mac is and what it’s intended to be. Each of the .Mac services, taken separately, don’t necessarily have much to recommend them…. There are certainly better e-mail services out there, better online storage services, better web hosting services, and so forth. However, few of these “solutions” integrate all of those services together in the way that .Mac does.

  More to the point, few of these other solutions can offer such an insanely easy turnkey solution for the average Mac user. For one relatively low annual fee, one gets all of the possible online services that the average user would need, rolled up into one nice neat package that “just works” for the most part with the technology that is already built in to Mac OS X.

  .Mac’s detractors often quote how much more cheaply they can get e-mail services or web hosting from other providers. GMail seems to be a favourite point for these folks to quote how there is a wonderful free solution out there for both e-mail and file storage, and there’s therefore no reason anybody should ever pay for e-mail.

  Now, I for one firmly believe in paying for any service that I would rely on, and for me, e-mail is absolutely mission critical, period. I do not believe that Google is as altruistic an organization as many would want to believe, and therefore have no desire to stake my e-mail on a “free” service. Certainly, Apple’s not necessarily any better, but at least I know what they’re getting out of providing me with e-mail service: $99/year. Apple’s motives are clear, as is the likelihood that they will continue providing this service as long as enough people are paying for it.

  Certainly, there are other good inexpensive commercial solutions for e-mail, web hosting, and online storage, but these ultimately end up being standalone services, and one has to shop around a bit to find out what is going to work best, and play the game of trying to integrate these services both into the Mac OS experience, and with each other.

  It’s not that these aren’t good services—they are, but to compare them to what .Mac offers is actually somewhat unfair. .Mac is really not trying to be all things to all people, but is rather a basic solution for the average Mac user who wants one-stop shopping for a place to get e-mail and build a few snazzy web pages to share a few pictures of the kids.

  It’s an unfair comparison to price out individual services and then try to suggest that you can get the same functionality as .Mac for less money, because you’re still missing a lot of the integration by doing so, both between the services themselves, but more importantly between OS X and the online world.

  As I said in a previous post, I switched to a Mac to simplify my life. I never even really thought about building web pages until iWeb, as the idea generally seemed to be not worth the time and trouble. Today, however, the tools I use all have a “Publish to .Mac” button or menu option tucked conveniently within. Build a web page, push a button, walk away. This is how technology is supposed to work… Quietly, in the background, and with a minimum of fuss in order to achieve a desired result.

  These same applications will export web pages to a directory structure, of course, but without .Mac one would still need to get those up onto a server somehow. Granted it’s a trivial experience for somebody with a bit of technical knowledge, but it still takes more time and fussing around to do, and even designing an automator workflow to do it is still an extra step that one shouldn’t need to bother taking when a solution is there that already does the job.

  Again, however, this is me speaking as a technology person, who would know how to do this… In my case, it’s mostly about efficiency of time, and not really wanting to be bothered complicating my world when I can just get one-button publishing instead. However, looking at the other person I live with, who is not technology-savvy, this would be a much more cumbersome experience. After all, what is simpler? Pressing a button and getting a web page? Or exporting to a file system, finding those files, and then figuring out how to upload them somewhere else.

  Another example of how .Mac “just works” away quietly in the background was encountered when I lost my Powerbook hard drive last summer…. I was away on a project in Halifax for a couple of weeks, and my drive simply stopped spinning one morning. While I had a full backup at home (courtesy of SuperDuper), that was back in Toronto, so did me little good on the project I was on. With an external hard drive and my OS X install CDs, I had my Powerbook back up and running in under an hour, but of course that was just a clean install. This was where the .Mac sync services and iDisk backups came to my rescue…. I fired up the System Preferences, entered my .Mac credentials, and then just watched as it basically downloaded all of my mission-critical data—mail preferences, e-mail messages, address book, calendar, documents in progress, and even my Safari bookmarks and keychain. Within two hours I was up and running with everything I needed, and was able to continue working as if nothing had happened.

  Now, I certainly could have done this with a myriad of other online services, but the point was that I didn’t need to. Further, the configuration of this took a trivial amount of time, both originally and even later to restore my data. Once it had been configured (months before this happened), it just worked away quietly in the background, and I simply didn’t have to worry about it.

  I think many of the people who demand more from .Mac don’t fully appreciate the elegance of it’s simplicity, much like any other Apple product. For instance, those who would suggest that the web hosting needs PHP and MySQL support are the same folks who would demand that the iPod add an FM radio, a voice recorder, and a web browser. None of these extra “features” are required to deliver the basic functionality of the product, which does a very good job of delivering those features that it does have.

  Now, that having been said, I don’t think for a moment that there isn’t much room for improvement in the .Mac service offering, but that improvement doesn’t need to be in the area of turning it into a full-fledged web hosting service, or adding needless complexity to the other areas of the service. Rather, a few minor modifications to improve the user experience, and allow people to use the service more transparently are what is in order.

  The new WebMail and Address Book interface were huge steps in the right direction, IMHO, but some basic server-side rules and spam filtering now need to be added to the mixture to provide a more “complete” web-based solution. These are things that improve the user experience and in fact reduce the complexity (by ensuring that the webmail experience more closely mirrors the Mail.app experience).

  Further, the ability to allow for alternative “FROM” addresses to be used on the .Mac e-mail would be desirable. Obviously, the problems with mail forwarding in and of itself are a difficult issue, and perhaps this is why Apple doesn’t want to go there (the average user is not going to be dealing with forwarding their other mail to .Mac in most cases), but it would be a large boon to those people who want to switch to using .Mac to store their e-mail without having to switch to using a mac.com address. The same could be said for web page hosting, although this is obviously less of an issue, since redirection services exist for those who know how to use them (and those who don’t aren’t likely to care).

  Another HUGE issue from a user experience point of view is the access requirements for .Mac groups. The groups are a wonderful but very under-utilized feature, since if you want to invite people who aren’t already .Mac users, they have to go through signing up for a trial account. The result has been that those who don’t have a bunch of friends already on .Mac don’t really get much traction on the .Mac groups. There needs to be a way to sign up for .Mac groups without going through the trial account registration (which will also scare most Windows users away in principle alone). Even a simpler sign-up page that just provides a basic Mac.com userid and password without requesting so much additional information would probably go a great distance in simplifying this experience. This is one area in which .Mac most definitely does NOT “just work.”

  The bottom line, however, is that while .Mac needs to grow and expand somewhat to improve the user experience, the service itself does a very good job of providing what it’s designed to—a simple one-stop-shop for all the basic online services that the average Mac user is likely to need, wrapped up into a simple package that is tightly integrated with the Mac OS.

  ]]> http://www.technocrat.ca/?feed=rss2&p=45 2 http://www.technocrat.ca/?p=48 http://www.technocrat.ca/?p=48#comments Fri, 01 Sep 2006 20:47:00 +0000 Jesse David Hollington http://hollington.ca/technocrat/?p=48 (or, “How an iPod Changed My Perspective on Technology”)

  A topic I’ve been meaning to espouse on for some time is exactly how I’ve managed to go from being such a die hard geek to being somebody who enjoys using Apple’s technology (not that the two are mutually exclusive).

  A close friend of mine has taken great joy in telling people how my views on technology took a dramatic shift shortly after I got an iPod, and of course while that may sound overly simplistic, it’s essentially true.
  
  Firstly, I am what most would call an übergeek. My fascination with computers and all things technical goes back to my early childhood, when I used to hang out at the local Radio Shack and fiddle with the TRS-80’s and Tandy Colour Computers. I built my own Z-80 based machine when I was about 12, installed my first Novell NetWare network when I was about 14, and have been on the Internet since before most people even knew there was an Internet (no, kids, the World Wide Web is not the Internet).

  In that time, I have always been a fairly die-hard PC user. I was never overly fond of Windows, having eschewed it in favour of OS/2 until such time as I really had no other option than to become assimilated by the great Microsoft collective (although to be fair, Windows 95 did start to look a bit promising compared to what else was out there at the time). Although I had once owned an Apple IIe, I never considered the Macintosh computers that succeeded it to be much more than toys. Sure they were great for desktop publishing and other work like that, but nothing that a real hardcore geek would ever use…. An operating system without a command prompt? What was that all about.

  Further, in the professional world in which I worked, nobody was really out there using Macs. Windows pretty much carried the day at that time, and on the few occasions I encountered Macs in my job, they were pretty much isolated from the rest of the world—relegated to special-purpose tasks such as graphics publishing and so forth, and seldom even connected to the networks on which I tended to hang out. Mac support was seldom (if ever) required, so they could be safely ignored as those “other” computers that no serious computer user would ever use.

  My Foray into the world of Digital Music

  When the MP3 phenomenon hit in the late 90’s, I was fairly quick to jump on that bandwagon, and by Christmas 1999, I had a Creative Labs Nomad MP3 player (note that I’m not talking about the Nomad II, or Jukebox, or any of those which came later—this was the original Nomad… 32Mb of RAM and a parallel port interface to transfer your music). However, as a concept, this was very cool, and the idea of being able to carry even a few songs around on a portable player like this was something I had been wanting to do for a while.

  Of course, the nature of the technology was such that I tended to replace the songs very seldom, and the Nomad gradually fell into disuse. I needed something with more capacity, and began looking at the Creative Labs Nomad Jukebox that came out a year later with a serious case of techno-lust. Of course, the price range was not particularly reasonable for me at the time, and I therefore took a “wait-and-see” approach, deciding instead on upgrading to an Iomega “HipZip” player… The 40Mb inexpensive replaceable media (Clik Discs) seemed a brilliant idea at the time (a time when 40Mb of Compact Flash memory would have set one back close to $500). Again, I used this for quite a well, but it, too, gradually fell into obscurity. I just didn’t feel like listening to the same music all the time, and changing the music just wasn’t all that convenient.

  Throughout this time, I was somewhat aware of this thing called an “iPod”, but of course it was an Apple thing, for Macs only, so it never gathered much interest for me.

  By early 2003 I had pretty much decided that the only way to go was with a hard-drive based player. I needed to be able to carry ALL my music around with me, all the time. Well, at that time, the only two games in town were Creative and Apple. Again, the iPod just looked a little “goofy” to me, seemed too simple, and was too much of an “Apple thing.” On the other hand, Creative had just released their 20GB Jukebox ZEN, which had portability, capacity, AND USB 2.0 transfer speeds going for it. I had always been quite happy with Creative’s stuff (even my original Nomad, not to mention a multitude of PC sound cards and other accessories), so I took the plunge and picked one up.

  At that time, my entire music library fit nicely into 20MB, with quite a bit of storage space left over. The Jukebox ZEN itself worked quite well, with a reasonably decent menu system, albeit a small screen, and pretty reasonable sound quality. The software on the other hand, was much less intuitive. Creative bundled their own software application, and for a time I wrestled with it until eventually picking up a replacement in Red Chair’s Notmad Explorer. Notmad seemed like a simple enough concept—manage the content on your Jukebox as you would any other file system, replacing a tag-based index for a file and folder structure. Bi-directional drag-and-drop was supported, and even something of a “sync” feature that would do it’s best to synchronize with a hard-drive based music library, although success with that was often limited, and the number of options available for file naming and syncing just proved that sometimes you can have too many choices.

  While the Jukebox itself worked well, the hassles with getting music on and off of it, and the fact that the interface wasn’t quite intuitive (small screen, too many menu layers, etc), meant that it too didn’t get used as much as I would have liked. Of course, the fact that it wasn’t the smallest of devices didn’t really help either.

  It really wasn’t that I didn’t know how to manage my music, as I am a very technically literate person… The reality was that I just really couldn’t be bothered—there were things that I would much rather be doing with my time than organizing, transferring, and cataloguing my songs, or messing with software applications that didn’t quite work as well as they should.

  During this time, I also experimented with a number of home digital media systems—devices designed to take music from a computer’s hard drive and stream it over a wireless network link to a home stereo system or other remote speakers. My use of the Creative Nomad prompted me to pick up the Creative Wireless Music System, since again this seemed like a good solution at the time. However, that experience proved to me that Creative Labs, while they may know digital sound equipment, most definitely did not excel in the area of wireless networking. My second device was the Linksys Wireless Media Adapter, which seemed to have the reverse problem (Linksys, of course, knew how to build a networking device, but the PC-based software and on-screen menu firmware was limited almost to the point of being frustrating).

  In looking for a better solution in that area, I eventually came across the SlimDevices Squeezebox. I ordered one of these, and within a few days had ordered a second one, replacing both my Creative and Linksys devices without hesitation. The Squeezebox had the advantage of on-device displays and menus, as well as a very good server-based software to catalog music and control the devices.

  It was this foray into SlimDevices that I think first made me take a look at iTunes. One weekend, as I was exploring the various options and plugins for the SlimServer, I came across some neat features related to iTunes integration. Having long ago developed a disdain for most of the other options for music management on a Windows PC, I decided to download iTunes and take a look.

  The next morning I went out and bought an iPod.

  The Thin Edge of the Wedge

  The fact is that the simplicity and intuitiveness of iTunes demonstrated the problem that I had been having all along—I was spending more time managing my music than actually listening to it. I had always known that Apple prided themselves on making simple and user-friendly apps, but I had always associated “user-friendly” in that context with unsophisticated. While iTunes didn’t necessarily have every feature that one could think of, the necessary stuff was all there, and it was there in a very easy-to-use fashion. Where most Windows-based music library software had you worrying about file names and directories and the underlying file system, iTunes took the logical step of insulating the user from that, concentrating instead on organizing music by indexed tag information. Certainly, the files still had to go somewhere, but as the end-user managing the music through iTunes, those were details I didn’t need to know or care about beyond giving it a common library location.

  Of course, being a technical user, I explored all of the facets of iTunes, and spent some time going under the hood and looking at the database files and seeing what I could do with it. However, those were things I did because I wanted to, not because I had to.

  Further, the integration with the SlimServer devices was brilliant. I came home one day after creating an On-The-Go playlist on my iPod, dropped by iPod into the dock, and by the time I got to the living room, the playlist was available on my Squeezebox.

  To me, this was the first foray into a realm where things “just worked” It identified something I had been striving for in my use of technology for many years… The fact that technology should simplify our lives, not complicate them. While it’s okay, even beneficial to understand technology, it shouldn’t be a pre-requisite, any more than driving a car requires knowledge of auto mechanics.

  The simplicity of the iPod solution became even more apparent when I handed my iPod to my wife, who is most certainly not a technology person, and she was able to navigate it and figure out how to access all of the basic functions in under 30 seconds.

  Around this same time, I also transitioned from a Palm Tungsten T3 to a Blackberry device for much the same reasons… While Palm OS could do a whole lot of really neat and cool things, getting it to manage the important details of my life was often more of a struggle than it was worth. Like my music, I was spending more time managing my calendar than actually following it. The Blackberry, on the other hand (with an Exchange server on the back-end) was another example of technology that “just worked.”

  Contemplating a Switch

  At that point, the rather nebulous concept of making the transition for Windows to Mac OS X started to become a bit more firm in my mind. I had played with Powerbooks at a couple of local Apple resellers while shopping for iPod accessories (there were no “Apple Stores” in Toronto in those days), and I really liked what I saw. In fact, on one occasion I even went over to the online Apple Store and configured a Powerbook for my needs so I could get an idea of what I’d be looking to spend.

  In addition, the fact that OS X was in reality a derivative of BSD Unix “under the hood” was in and of itself very appealing. I had been playing with Linux for about seven years at that point, and I really liked some of the things that I could do with it. Unfortunately, despite numerous attempts by the Linux community to produce a decent GUI, driver support, and business productivity applications, Linux itself still fell short as a desktop OS. I ended up keeping a dual-boot configuration around so I could boot up Windows to do my day-to-day work, and Linux when I wanted to do more “low-level” networking and programming stuff.

  Ultimately, though, the problem was that as sexy and powerful as Mac OS X looked, the question I still had to answer was whether somebody in my particular line of work could actually take the plunge without losing too much of the functionality I had come to know and love from my Windows world…

  The Next Step…

  Despite the Powerbook having a great appeal, the combination of potentially losing functionality and the price point itself prevented me from ever really exploring it until almost nine months later.

  During the summer of 2005, I purchased a pair of new laptops for my wife and I, and by that time I had mostly abandoned the concept of making the switch to OS X. I was embroiled in the use of a number of Windows applications, from Microsoft Office to Project to Visio, not to mention a number of networking related tools, all of which just made a transition to OS X seem impractical at best.

  However, later that summer, it occurred to me that I should get a dedicated “music server” for my Squeezebox devices, since I was now relying more and more on a laptop, my desktop computer (which had traditionally done the job), would not always be on, and would be performing other tasks. For this purpose, a Mac Mini seemed an ideal solution—SlimServer would run on OS X, iTunes of course lives on OS X, and I doubted that I would find a Windows or Linux-based machine with as small of a footprint as a Mac Mini at even twice the price. I also figured this would be a good chance to play with OS X a bit more, but that was really a secondary consideration.

  So in late August, the Mac Mini came in, and I set it up with all of the necessary software to support my digital music collection, both for streaming to the Squeezeboxes and syncing my iPods. The idea was that this would be a box that would sit rather unobtrusively in the corner, and not be used for much else.

  However, something happened in the process of setting this box up. I began to explore Mac OS X more fully, and I began to explore the Unix capabilities of the box (after all, SlimServer was heavily based in the Apache and Perl space, and require a little bit of Unix-geeking to get running properly). The combination of power and simplicity once again impressed me.

  In addition, Apple had quite cleverly bundled a trial edition of Microsoft Office 2004 for Mac. I had always had vague ideas of Office being available for the Mac, but hadn’t really explored it until now. I fired up Word and Excel, opened a few of my documents (across the network from my Windows PC, which was also surprisingly simple, since I hadn’t actually configured any networking client of any kind on the Mini), and they came across without a character out of place.

  Word and Excel compatibility aside, however (since I really expected that would be fine), the burning question in my mind was still the e-mail issue—or more specifically the groupware issue. In most corporate and professional environments, there is more to business services than just e-mail…. Calendars, shared folders, address books, etc., all have to be accounted for. My world in that area ran on an Exchange server, and the ability of the Mac to handle this was probably my biggest concern…. Sure I can do e-mail via IMAP, but what about my calendar? I knew from reading the back of an Office 2004 box that it came with this thing called “Entourage”, but wasn’t entirely certain of it’s compatibility with something like an Exchange server.

  Well, fortunately for me, Microsoft had made great strides in the few months before this in improving Entourage’s compatibility with Exchange. I fired up the Entourage client on my Mac Mini, plugged in a few basic configuration values, and suddenly my whole Exchange mailbox was just “there”.... Including my calendar and my address book.

  The discovery of Entourage was the last major hurdle to my acceptance of Mac OS X as a viable alternative to my years on Windows. The existence of Virtual PC was the other one, and I had been aware of that particular option for some time, but while that would be fine for less frequently used apps like Visio and Project I was not about to buy a Mac just to leave a Virtual PC session running all the time for my e-mail client.

  After about two more weeks of playing with the Mac Mini, I had made my decision to go shopping for a Powerbook.

  The Switch

  The fact that I had only two months prior bought a new Windows laptop caused some consternation—mostly with my wife, who really didn’t see the point in going out and spending more money, but the economics of the situation eventually won out—The Windows laptop was new enough to go on eBay and still be able to recover a significant portion of the purchase price. Ditto for the Mac Mini, which I decided would not be required in my new configuration either. These would fund the Powerbook purchase, so off I went to the Apple Store (we had one by that time) in late September.

  Along with the Powerbook was a purchase of Microsoft Office 2004, Virtual PC, and a multitude of other accessories. Office 2004 would form my staple set of applications, and I decided that Virtual PC would supply compatibility with any Windows applications that would otherwise be left behind (the two most notable being Visio and Project from a business productivity point of view).

  In the process, however, the lure of bundled software again proved useful. The Powerbook came with a version of OmniGraffle pre-installed, and for my purposes this simply blew Visio out of the water for ease of use. So, another software package went onto the back shelf. In addition, my needs for project planning were usually far simpler than to require Microsoft Project, so the bundled OmniOutliner would also meet those basic needs (although both OmniGraffle and OmniOutliner were quickly upgraded to the Pro versions).

  Suddenly, I found that Virtual PC wasn’t as necessary as I had thought. I still needed it for testing certain applications, and dealing with certain specific networking tools (working with administrative tools on Novell NetWare and Windows networks, for instance), but I would really have no need to load it up or live in it on any kind of regular basis.

  In the process as well, I also fell in love with Keynote. While Word and Excel were required for compatibility with my Windows-laden colleagues, I generally didn’t do much collaborative work on presentations, so putting them together in Keynote would be just fine. If somebody wanted a copy of the presentation for reference, I could export to Powerpoint, or simply save as a PDF. I found Keynote to be far easier to use than Powerpoint, and the graphics were a lot smoother and cleaner, particularly where animations and transition effects were involved.

  In addition, over the next few months I had a bit of a love-hate relationship with Entourage, particularly in relation to the built-in iApps (Mail/iCal/etc), but that’s a story for another day.

  The bottom line is that I very quickly became hooked, and as I discovered more and more OS X native applications that would do what I needed and wanted, my satisfaction with OS X only increased. Ultimately, I had a machine that would be the best of three different worlds… The very user-friendly, intuitive and aesthetically pleasing OS X GUI, the raw, unbridled power of Unix under the hood, and the ability to fall back to Windows for those things that still required that world.

  My OS X experience has not been perfect… There are still some idiosyncrasies and stability problems sometimes, but these are far more rare than experienced in Windows. In addition, Apple’s design of OS X has done some clever things to decrease user frustration, whether intentionally or not… For example, when an application is busy or has stopped responding, the graphic rendering of the application continues to work beautifully. The window itself may not update (as the application is busy or frozen), but it can still be moved around, minimized, and resized, and does not interfere with the rest of the user’s experience. It’s a little thing, but seeing half-drawn windows of hung applications on Windows was always something that I found extremely frustrating—it gave a feel of something being broken or “not quite right” when this happened, and it was often impossible to drag another window out of the way to see what the hung app was doing last.

  At the end of the day, it may not be all wine and roses, but the fact is that I find the OS X solution to be more powerful, easier to use, and overall a far more pleasant experience than struggling with Windows. Again, technology that simplifies my life, rather than complicating it further…. OS X lets me go under the hood when I want to, but doesn’t force me to on a daily basis, with the result being that I can generally get more productive work done, and have fun at the same time.

  ]]> http://www.technocrat.ca/?feed=rss2&p=48 2 http://www.technocrat.ca/?p=49 http://www.technocrat.ca/?p=49#comments Fri, 16 Jun 2006 00:12:17 +0000 Jesse David Hollington http://hollington.ca/technocrat/?p=49 http://www.technocrat.ca/?feed=rss2&p=49 2 http://www.technocrat.ca/?p=50 http://www.technocrat.ca/?p=50#comments Mon, 09 Jan 2006 11:04:09 +0000 Jesse David Hollington http://hollington.ca/technocrat/?p=50 “The upshot of this is that any business models that rely on “selling” copies of previously televised TV shows, such as Apple’s sale of “Lost” and “Desperate Housewives,” is doomed to failure. Why pay for that content when it can be extracted for free.” (Via The Register)

  This interesting article in The Register makes the point that Apple’s current iTunes-based distribution model is “doomed to failure” as tools now exist to transfer recorded video content to the iPod.

  However, this statement misses one very important point: That of the balance between simplicity and cost.
  

  Apple has always been a forerunner of the principle of simplicity in technology. In short, this would seem to mean that they recognize that technology should do what it is designed to do in the most user-friendly and simple way possible, and that it should simplify our lives rather than complicating them with more bells and whistles.

  The iPod is purchased by a lot of average consumers who are not highly technical users. In fact, some would even suggest that this is Apple’s target market. There are certainly more feature-rich digital audio players out there, yet Apple’s iPod continues to dominate the marketplace. Some can argue that the “trendiness” of the iPod contributes to this, but I don’t think the iPod would retain this trendiness if it weren’t also an incredibly intuitive and easy-to-use device. In short, if people bought iPods because they were cool, but then stopped using them because they were complicated, they would soon no longer be cool.

  At the same time, the iTunes Music Store provides a simplified way of obtaining content for your iPod. In the audio world, it is not a complicated thing to purchase a CD, insert it into your computer, and import it into just about any software, and iTunes (the software) certainly makes this a simple process. However, despite this simplicity, there are still those paying iTMS $0.99 per track to download music.
  Now why would people do this, when there are so many free options available? Certainly, the free options are of questionable legality at best depending upon your country of residence (I’m talking about P2P services here of course), but I don’t think that this alone precludes people from using them.

  Further, there are other inexpensive methods available for getting music content, including online services like eMusic and allofmp3.com. However, despite these other methods, iTMS continues to do reasonably well.

  The reality is that most iPod users are not computer geeks. Most iPod users are “joe consumer” who bought an iPod to listen to their music, and simply want to get their music onto their iPod in the simplest way possible.

  Now, the average consumer usually still buys CDs, and iTunes (the software, not the store) makes this import process very easy and painless. Hence the majority of legitimate music on most iPods probably came from a purchased CD.

  This approach diverges when entering the realm of video content, however. At this time, there is no reasonable way to purchase a DVD and automagically transfer it onto your iPod. There is software available that attempts to do this, but it is a time-consuming process at best, and generally not something that the average non-technical user wants to attempt. However, one might as well suggest that this alone would doom iTunes’ video content approach to failure in the same way the availability of commercial audio CDs would doom iTunes’ music content sales. After all, importing a CD into iTunes is so easy why would anybody bother to buy their music from the iTunes Music Store?

  However, the article goes even further in assuming that the majority of iPod users actually have the capability in terms of hardware and knowledge to record video content from their TVs and then convert it into iPod format, and that therefore every owner of an iPod video who wants to watch a TV show on their iPod would rather do this than shell out $1.99.

  If this were true, then sales of DVD box sets of TV shows should have never taken off either, since all of this content is freely available on TV, right?

  Frankly, this is an unrealistic assumption even for a technical user. I’m a very experienced computer user myself, and I couldn’t even begin to be bothered with this process just to get content onto my iPod, and being in Canada, I can’t even get the iTMS video content yet, since it’s only available in the U.S. So in my case, I’d rather not even have that content on my iPod than go through the trouble of recording it and transferring it manually.

  So if this is the response of somebody who actually has the knowledge and ability to do this, how much more likely is the average iPod owner to bother?

  Again, the iPod won it’s market share for its simplicity and ease of use. iTMS will continue to survive for the same reason… I can either invest $35 for a season of a show I want to watch and have it on my iPod within minutes, or invest far more than $35 in time, effort, and hardware to record every episode of a season from my cable/satellite feed and encode it for my iPod, and wait several months to get a whole season.
  To me, the choice is obvious.

  ]]> http://www.technocrat.ca/?feed=rss2&p=50 1