Quarantine: Apps and Documents
The quarantine flag is among the stickiest of all xattrs. When you unZip an archive which has been flagged, the xattr is normally propagated to all items which are saved from that, a behaviour which ensures that compressed apps retain their flag when uncompressed, for example. This isn’t, though, imposed by macOS, and some tools and utilities which can decompress archives may not follow this behaviour; the bundled Archive Utility does, though.
macOS has been attaching quarantine flags, in the form of the com.apple.quarantine extended attribute, to documents for as long as it has been to apps, since macOS 10.5 in 2007, as part of the the same process. If a webpage or other file is downloaded from the Internet and saved on your Mac by an app which adds quarantine flags, then a normal quarantine xattr will be added to it. When you decompress a flagged Zip archive, quarantine flags are automatically attached to all the files extracted from it.
[…]
The role and purpose of these quarantine flags added by sandboxed apps remains obscure, beyond being used to prevent the execution of shell scripts, web archives, etc.
Unfortunately, it can also prevent opening shell scripts, e.g. just to edit them.
Opening a document using LaunchServices, by double-clicking or dragging and dropping it, is very different. macOS then checks both the quarantine flag and the OpenWith xattr. If the latter points to the same app as the default for that document type, then regardless of the quarantine flag, the document is opened as expected; similarly, if there’s no quarantine flag, none is enforced.
But if a document has both quarantine flag and OpenWith xattr, and the app specified in the latter isn’t the default, macOS refuses that request when it’s made through LaunchServices. This results in the dialog that you see, which doesn’t make any sense because it’s actually intended for apps which can’t pass their first run tests, not for documents at all.
[…]
macOS is clearly behaving in this way as a defence against malware, which might install an innocent-looking document but set its OpenWith xattr to ensure that it’s processed (installed or run in some way) using a third-party tool instead. However, there are several serious flaws in the way that this is currently implemented, in particular the differences in operation between app and document quarantine.
[…]
Furthermore, determining document behaviours like this through opaque metadata prevents the user from making judgements of their own on which documents to trust. It essentially deems every document untrusted for ever, which is most bizarre in comparison with the treatment of apps, which once they have passed their first run checks are so trusted that they can even have broken signatures and macOS doesn’t bat an eyelid at running them.
I think that these log extracts demonstrate how the failure to open these documents is a behaviour determined by XProtect as a result of its scan not of the document contents (which were entirely innocent), but on discovery of the quarantine flag and the OpenWith extended attribute. The error returned, -67062, is incorrect, and results in the wrong alert being displayed to the user.
As far as I can discover, this behaviour and its use of this alert is undocumented by Apple in either its user documentation or that for developers.
[…]
Apple needs to correct this immediately: blaming its third-party developers for an undocumented feature in macOS is plain wrong.
Open the Security & Privacy pane in its General tab. If you’re quick enough, there will be an additional item at the bottom offering the button to Open Anyway. If you don’t see it, it’s because you were too slow to react: try again, only faster!
If you click on the Open Anyway button, you’ll see another security dialog which has a similarly incoherent message.
What a bizarre user interface.
What happens is that macOS sets the quarantine flag on that document to indicate that XProtect has approved it, by changing its first numbers from something like 0082 to 00e2. This is what my free app Pratique does without your having to go through two security alerts and the Security & Privacy pane. This ensures that the next time that document – and that document alone – has its quarantine flag checked, it will not be blocked in the way that it was.
[…]
Open the Finder contextual menu on the document, then press the Option key. Now the Open command at the top will open that document via the security confirmation dialog, or you can choose any other app to open it instead. This results in the same change being made to the quarantine flag, with the added bonus that, as you were holding the Option key, the Finder window will automatically vanish too.
Previously:
Update (2019-05-14): Howard Oakley:
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.
In certain circumstances, trying to open a document in macOS 10.8 and later can result in a security error and refusal. This article summarises knowledge about this issue: how it arises, what it means, and how to work around it.
Update (2020-11-07): See also: Quarantine and the quarantine flag.
