Yet Another Mac OS X Location Changer

I was going about my business, as you do, having used the LocationChanger script and launchd agent to automatically switch my Mac between my home and non-home network locations. Of course, I decided I could do it a little better, and got to work.

Here is the result: AutoLocation.

I learned a few new things while cooking this up, including how to actually deal with arrays in bash, a nifty thing called process substitution (which resulted in my favorite line in the whole script), and a great way to return arbitrary values into variables from functions.

I really like it when I learn new things on the way to solving a problem for myself. It’s the best way to learn something.

Advertisements
Yet Another Mac OS X Location Changer

Using SuperDuper! for FileVault2 System Volumes

Since my first Mac (an Aluminum PowerBook G4), I had relied upon SuperDuper! as my backup method for my Mac notebooks. It’s a wonderful tool, and faithfully replicates an entire volume, including making it bootable, for a worst-case drive failure scenario. I’ve used it for migrating my system to a new disk when doing disk upgrades, transferring an image to a new/replacement notebook, and just plain backups.

I’ve long since switched to using CrashPlan for my backups. CrashPlan has worked wonderfully, and saved my bacon a number of times. I use it on every computer I own. Crashplan isn’t, however, an ideal solution for migrating data to a new drive when upgrading your hard disk, simply because it’s rather slow to restore a lot of data over the network.

So, back to SuperDuper! I go, as I’m planning to add an SSD to my current MacBook Pro, and re-instate the “build a DR boot volume on an external drive” policy at home. The wrinkle is that since the upgrade to OS X Lion, both my wife’s and my notebooks are using FileVault2 for full-disk encryption. Given the sheer amount of personal information on these computers, it’s the only sane thing to do, especially when the notebooks are bound to iCloud, with Find My Mac enabled. (This gives you remote-wipe capability on your notebook, which is very useful if it’s lost/stolen.) Unfortunately, there’s no clear way to use SuperDuper! with a clean hard drive and end up with an encrypted volume that duplicates the original.

At least, not directly within SuperDuper.

All is not lost, though, as there is a way to do it, and get a fully encrypted, bootable duplicate of your FileVault2-encrypted OS volume!

In short, the procedure is:

  • Install OS X Lion to your destination hard drive
  • Activate FileVault2 on the new install
  • Reboot to your normal startup disk
  • Use SuperDuper! to “Smart Update” the destination
  • Boot from the destination (SuperDuper! target) disk again
  • Open System Preferences -> Security, and click on the FileVault tab.
  • Click the button to enable users to unlock the volume, and enable any additional accounts (if you have the users there to type in their passwords.)
  • Reboot to your normal startup disk again
  • Pat yourself on the back! You did it!

I’ve tested the procedure on my old MacBook Pro, from which I’m preparing to remove the SSD to transplant it into my new MacBook Pro. It works, it boots from either volume, and they’re both encrypted (granted, with different recovery keys, as one would expect). I’ll post a followup in about a week complete with screenshots of the whole process when I migrate my OS volume to the SSD in my new MacBook Pro.

Stay tuned!

Using SuperDuper! for FileVault2 System Volumes

Balance (Security vs. Usability)

I suppose this should be filed under “Get More Pageviews”, but nonetheless, I took the click-bait to Sophos’ calling Apple out on making the iPhone 4S safer to use while driving easy to access by bypassing your passcode. My main issue is that they take what is a legitimate concern regarding the tradeoffs between security and ease of use (and even safety of use while driving) and instead paint it as a deliberately cavalier attitude towards data security.

What’s disappointing to me though is that Apple had a clear choice here.
They could have chosen to implement Siri securely, but instead they decided to default to a mode which is more about impressing your buddies than securing your calendar and email system.

You see what he did there?

Ever notice how an expert in a certain field will only ever see choices from the perspective of that field? Interesting how there is the assumption that the only options were secure and insecure. It’s like he just assumes that nobody will ever try to use a phone while driving, something that seems like it would gain a huge safety improvement by reducing phone interaction.

On my lowly iPhone 4, if I want to call my wife while I’m on the freeway to see if I need to stop at the store, I’d have to:

  • Pick up the phone
  • Press the home button or the power button
  • Swipe across the bottom of the screen
  • Tap in my passcode, or, as suggested in the Sophos article, my complex alphanumeric-with-symbols password
  • Tap the Phone icon
  • Tap the Favorites button if it’s not already on the Favorites page
  • Tap my wife’s entry

With an iPhone 4S and Siri, I’d presumably need only to:

  • Pick up the phone
  • Tap the button that activates Siri
  • Speak: “Siri, call my wife.”
  • Acknowledge Siri’s confirmation of my request by saying, “Yes.”

I wouldn’t ever have to look at the phone. The only touch target I’d need is a physical button on the phone, which is easy to locate without looking. It’s only marginally more complicated than asking a real person sitting in the car with you to dial the phone for you, because you have to push a button two times. I’m reasonably certain it’s this use case which Apple designers and engineers had in mind when setting the default options on the iPhone 4S, with the assumption that the security-conscious people could find and disable the “enable Siri while iPhone is locked” option themselves.

After all, while the iPhone is a popular device for businesses, it’s not the only market Apple sells to. Apple is going to make the choice, every time, to make it’s products easy and delightful to use for its primary customer base.

You know, ordinary people.

Balance (Security vs. Usability)

I really need to meet this Systems Boy…

… Or at least add him to my daily reading.

My last source of confusion (on this matter, at least) is that people are going after Apple on this at all. Until the iPhone there was never an expectation that phones should either run Flash or be open. A phone is not a personal computer. It’s a phone. All smartphones are just phones. They play by a whole different set of rules. And that set of rules is much longer and stricter than that of a personal computer. No one ever complained that Nokia’s phones weren’t open. Or Motorola’s. Or Samsung’s. Why now is it completely offensive that Apple’s phones should be? Moreover, there are no phones in existence today that can display Flash content because of all the reasons cited by Jobs in his letter. Google’s phones don’t. Neither do Palm’s. So why is everyone going after Apple? It’s just crazy.

Quick update: About the only thing that has changed since he posted this, I think, is that Google has announced with Adobe that they’re going to get Flash on the Android platform. We’ll have to see how that turns out, but I honestly don’t have high hopes, primarily because touch is not the same as keyboard, monitor and mouse, and I’m not sure Flash content designed for web-on-PC will translate well.

I really need to meet this Systems Boy…

Dear Adobe Reader Safari Plugin: Die.

If you’re anything like me, you have a strong dislike for all the stupidity that surrounds the Adobe Reader (formerly known as Acrobat Reader.)

I won’t go into the details here (though this guy can explain it in great detail), but because I very occasionally need features of Adobe Reader, I still keep it installed on my Mac, while I use Preview for all my other PDF needs. I’ve gone so far as to install the Firefox PDF Plugin for Mac for when I use Firefox, just to avoid Adobe Reader. And, really, there’s no point in Adobe Reader for most cases where you just want to be able to view or print PDF files. Doubly so, since Mac OS X lets you print any document to a PDF file as a default feature of the OS.

There are, though, edge cases where having Adobe Reader installed and available are useful. So I have it installed, but I refuse to use their web plugin. Adobe doesn’t care, though, and will periodically, sometimes randomly, and sometimes even without my consent, re-install the plugin. Even though I’ve told it not to. Adobe Updater, I’m looking at you, here.

Sadly, my solution is heavy-handed. I created a launchd task that will forcibly remove the Adobe Reader plugin from /Library/Internet Plugins whenever it’s created. It’s fast, efficient, and works.

And, as soon as I can figure out the new wordpress theme, I’ll post it here in a legible form

UPDATE: Thanks to Lynne and Chad on Twitter for suggesting the Preserve Code Formatting plugin!

And now, the Launchd config. Save this as:
"/Library/LaunchDaemons/org.unnerving.RemoveAdobeReaderPlugin.plist"


Label
org.unnering.RemoveAdobeReaderPlugin
ProgramArguments

rm
-rf
/Library/Internet Plug-Ins/AdobePDFViewer.plugin

QueueDirectories

/Library/Internet Plug-Ins/AdobePDFViewer.plugin

WatchPaths

Dear Adobe Reader Safari Plugin: Die.

Oh… Safari was already awesome.

So, yeah, this is probably old news to everyone else, but I’m late to the party, as usual. I finally tripped over two menu options in the History menu of Safari that I had not previously noticed.

The first is “Reopen Last Closed Window.” This is very useful.

The second is “Reopen All Windows From Last Session.” This takes care of my biggest concern regarding session restore.

So I guess maybe a “Reopen Last Closed Tab” option might be about all I could add to that to be truly complete.

I do still look with great envy at Firefox’s extensions system, particularly for Adblock Plus, FlashBlock and NoScript.

Oh… Safari was already awesome.

Safari: You’re Awesome, But You Could Be More Awesome

It’s been about a week and a half since Apple release the last batch of updates for OS X, including the latest version of Safari. In the interests of keeping up to date with security updates, I went ahead and updated. I did my research first, though, and uninstalled Saft before the attempt (there were some who had problems with InputManagers installed during the upgrade.)

I was happy to discover, this evening, that Saft had been updated to support the latest version of Safari. Despite my general revulsion for running InputManager-based hacks (let alone other system behavior modification software, like Haxies, that hook in even deeper to the system), Saft offers a subset of functionality that I simply don’t like doing without. A couple of the features, I feel, really should be integrated into Safari proper.

Continue reading “Safari: You’re Awesome, But You Could Be More Awesome”

Safari: You’re Awesome, But You Could Be More Awesome