Removing ‘spurious’ quarantine flags attached to documents using Sandstrip often proves only a temporary solution to the problem of security alerts, when trying to open documents which have been set to be opened by non-default apps. I’ve been looking at how XProtect behaves in response to changes made in quarantine flags, and can offer an alternative approach which can work better.

When you open a document which has no quarantine flag attached to it using the GUI, such as the Finder (double-click) and LaunchServices, the sandbox seems quick to add a ‘spurious’ quarantine flag to it, even when the sandboxed app doesn’t save that document. So the approach used by Sandstrip to completely remove these ‘spurious’ flags is often too transient to help much. Without tinkering with the sandbox itself, there seems little to be done to help, unless Apple changes this behaviour.

However, the behaviour isn’t as quick or consistent if a document already has a quarantine flag, either one gained as a result of being downloaded from the Internet, or an existing flag attached by the sandbox. Following a little experimentation, I discovered that the best way to maintain access to flagged documents and resist the sandbox from adding an active quarantine flag, is to set an existing flag as if the document had been checked by XProtect and passed – in the same way that this is handled for apps.

Surprisingly, this still isn’t perfect. When a sandboxed app saves a document, it’s most likely to write a fresh ‘spurious’ quarantine flag to it. Even more surprisingly, that occurs with ‘genuine’ quarantine flags – a behaviour which appears to reduce security.

Quarantine flags which are written to files which have been downloaded from the Internet contain a UUID which refers to their entry in the QuarantineEvents database at ~/Library/Preferences/com.apple.LaunchServices.QuarantineEventsV2. Those entries contain additional information which is significant, and readily available to apps and other software.

When the sandbox overwrites an existing ‘genuine’ quarantine flag, that UUID is lost, and its ‘spurious’ flags don’t contain any reference to entries in the QuarantineEvents database. Thus the sandbox behaviour loses the association with that additional information which is of security value.

Pratique has a similar interface to my free utility for stripping ‘spurious’ quarantine flags, Sandstrip, but instead of removing them, it marks files with a flag which indicates that they have been checked by XProtect – in the same way that flags change when an app has passed its first run checks. So long as that modified flag remains attached to a document, you can change the app set to open it, and double-clicking it won’t trigger a security alert and refusal.

This should prove a more lasting way of dealing with the problems caused by quarantine flags on documents, particularly if you don’t save them using an app which runs in a sandbox.

However, changing flags indiscriminately could also cause a major vulnerability. If you had downloaded an app in a Zip archive, for example, setting the flag on either the archive or that app to indicate that it had passed first run would let it escape the security checks which take place when you first run an app. So Pratique is careful not to change quarantine flags on apps and other executable bundles, or on archive documents.

The first beta-release version of Pratique is now available from here: pratique10b1
from Downloads above, and its Product Page.

This should run in Sierra, High Sierra and Mojave, although I have only been able to test it in Mojave, so would greatly appreciate reports from those older versions of macOS, please.