June 16, 2016

Yesterday I found a flaw in the new "feature" App Translocation, AKA Gatekeeper Path Randomization. (One could even call it a "protection racket", because you either pay a percentage to be in the crap store, or Apple breaks your software updater.) Today I found another flaw. You know what they say, you've seen one, you've seen them all. (They, circa 20th century, Hearsay Publications Inc.)

As I explained in previous posts, App Translocation kicks in when you download an archived app (e.g., in a zip file), unarchive the app, and run the app from the archive location. App Translocation stops, permanently, when you move the app bundle to a new parent folder. The flaw I found yesterday is that an app can remain vulnerable even after reparenting, depending on the new parent and the archive layout. The flaw I found today is that an app becomes vulnerable again if you reparent it and then move it back to the original location. Why in the world would you do that? One word: undo. Maybe you moved the app somewhere but then changed your mind about where to put it. Maybe you hit undo accidentally. Maybe your cat stepped on the keyboard or trackpad. Maybe the app unarchived into a folder, you moved the app by itself into /Applications, but then you decided that you wanted to put the entire folder in /Applications instead of just the app. Which is even worse, because you're keeping the possibly malicious resources at the same relative path to the app, but the app is now no longer protected by App Translocation.

The fundamental problem, the primary cause of both of the flaws I discovered, is that App Translocation happens automatically, without any awareness by or notification to the user, but App Translocation is turned off by a manual action by the user — moving the app bundle in Finder — again without any awareness or notification. Unless the user is very knowledgable like us [compliment the readers here to win them to your side - Ed.], and paying extremely close attention to details normally hidden, the user has absolutely no idea that App Translocation is protecting them, or that it has been accidentally turned off by them. Users will continue to behave as they usually do, i.e., following "workflows" (generously labeled) that confound developer expectations.

The more I learn about App Translocation, the more I feel that it is a bad idea with a botched implementation. Or a botched idea with a bad implementation? In any case, perhaps Apple should just shelve it for now, take a year to ponder, and come back with a better solution in macOS 10.13 (codename Voorhees).