Lost in Translocation

It’s nearly eight years since macOS started silently running quarantined apps from a random path on a hidden volume, a process widely known as App Translocation, or more formally Gatekeeper Path Randomisation (GRP). This was introduced in macOS 10.12 Sierra to prevent malicious software from pulling tricks with plug-ins, and has since caused some users weird problems.

One shortcoming is that Apple’s user documentation doesn’t seem to mention this anywhere, such as in its latest account of Gatekeeper. Even its Platform Security Guide only mentions it in passing: “When necessary, Gatekeeper opens apps from randomized, read-only locations. This is designed to prevent the automatic loading of plug-ins distributed alongside the app.” The only explanation provided for developers is in these notes in Apple’s Developer Forums, where we’re told that “the exact circumstances where the system translocates an app is not documented and has changed over time.”

This article attempts to explain how App Translocation or GRP work as of macOS 14.4.1 Sonoma. Even if you’re already familiar with how it has worked in the past, this might yet bring a surprise or two.

What happens

If you download software from outside the App Store, that isn’t supplied on a signed disk image, such as a regular Zip archive, then unarchiving and launching that app in place triggers the app to be translocated, and run the first time from a randomised path. This most commonly occurs when the Zip archive is decompressed into a folder, and the user launches the app from there without moving it into an Applications folder, although the exact conditions are more complicated.

The app isn’t moved into translocation, but copied in such a way that its files retain the same inode numbers, but appear on a different volume mounted in that randomised location, such as /private/var/folders/zy/jmx4mdfx6s36fdtd0_4ndl7c0000gn/T/AppTranslocation/613DF902-6BE1-4C37-A4C2-349AA050923C/d/.

Previously, it has been possible for apps to clear translocation following that first run, as in principle that should clear them from quarantine, and allow their next run to occur normally. In practice, though, that doesn’t happen in recent versions of macOS, and unless the app is moved from its original location, it’s condemned to be run in eternal translocation.

Effects

Although apps should be designed and implemented so they can be run from any location, developers have reported various problems in getting their apps to work in translocation.

For users, any other software that relies on an app running from a stable and accessible path is likely to have problems. One example of that is Little Snitch, which associates its firewall rules with paths of apps and processes. It therefore may experience difficulties associating rules with apps being run in translocation.

Another situation where translocation can have adverse effects is with apps using a self-updating mechanism, such as Sparkle. These may not be able to work if the app is in translocation.

If apps were only to be run in translocation once, its effects would be limited. However, there are scenarios in which an app can effectively be condemned to be translocated every time it’s launched unless the user becomes aware of that, and knows how to stop the behaviour.

How to avoid translocation

An app will be translocated if all the following apply:

the app has an apple.com.quarantine extended attribute attached;
the app must be opened by Launch Services (normally the Finder) rather than a command shell;
the app hasn’t been individually moved in the Finder from the folder it was unarchived or downloaded to, wherever that was.

Tests in Sonoma 14.4.1 show that apps won’t be translocated if:

they have no apple.com.quarantine extended attribute, or it has been removed;
they have been moved individually in the Finder so that they’re now enclosed in a different folder.

The following will normally result in the app being run in translocation:

opening the app in the folder that it first arrived in, even if that folder has been moved elsewhere, such as into an Applications folder;
moving the app at the same time as other apps, even if they’re all put into an Applications folder. Group or simultaneous moves in the Finder aren’t counted as a move that will stop future translocation;
running the app again without moving it from a location from which it has already been translocated. Until the app is moved from that location, it’s likely to be repeatedly translocated every time that it’s run.

Recommendations

When you download an app that’s not supplied by the App Store, or installed from a signed disk image, before you try running that app, move it individually (one app at a time) from the folder it arrived in, to an Applications folder. Once it’s there, you should be able to run it without the risk of it being translocated.

Should you have any apps that are currently being translocated because of the way they were installed, move them individually (one app at a time) from the folder they’re currently in to a different folder, and run them from there.

I’m very grateful to Enzo for revealing that group app moves don’t stop translocation.