Finder security errors opening documents: a summary

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.

This issue only affects documents for which the default app has been set to a different one, either in the Finder’s Get Info dialog or by some other means. If you never use that feature, then it should never trouble you on your Mac.


The three conditions required for this security error to occur are:

  1. The document must have a quarantine flag attached to it.
  2. The document must have an OpenWith extended attribute attached to it, setting a non-default app to open that document.
  3. The document must be opened using the Finder, e.g. by double-clicking it, or dropping it onto the app icon, or another mechanism which is handled by LaunchServices.

All three conditions must be satisfied.

The quarantine flag, an extended attribute of type, can be set either when it was downloaded from the Internet using a method which sets this flag, such as Safari, or by opening or saving the document in an app which runs in a sandbox, such as Apple’s apps bundled with macOS, all those supplied by the App Store, and many others supplied by other means. It is not normally attached by apps which have merely been hardened and/or notarized.

The OpenWith extended attribute of type is attached to documents when the user changes the app set to open that document in the Finder’s Get Info dialog. If the user sets that back to the default app used to open that document type, although the extended attribute remains in place, the security mechanism recognises that the default app is being used and this mechanism isn’t then triggered.

Opening the document from within an app doesn’t act via LaunchServices, and is unaffected by this mechanism.

What happens

If those three conditions are met, a check of the document by XProtect returns an error -67062, which results in display of the error alert, and that attempt to open the document is terminated. The alert gives no option to open the document by any other means.


Why this happens

Many document types can contain code of different types which can be used to exploit vulnerabilities in apps which can open them. Even plain text files can prove malicious if they are executed as shell scripts. This mechanism appears intended to reduce the risk of this happening, by denying such documents the facility to be opened with an app other than the default set for that type.

For example, you might be sent what appears to be a Word .docx document, but it has an OpenWith extended attribute which sets it to be opened by a vulnerable version of another app, which is then exploited by it.

However, this doesn’t explain why sandboxed apps add quarantine flags to all documents which they open.

How to work around it

macOS provides various ways of working around this security control, of which the simplest is to use the Finder’s contextual menu to Open the document. A security dialog then gives the user the option to proceed to open that document using the non-default app. If the user agrees, the quarantine flag is changed to indicate that the document can be opened without future blocking, and it is opened in the chosen app. The quarantine flag is not removed from the document.


Other simple ways to work around this include opening the document using the Open command within the app, and changing its OpenWith setting to the default app, which of course then leads to the document being opened by that app.

If you want to prevent this from happening proactively, macOS doesn’t provide any direct way to inspect or edit the quarantine flag, but my free utilities Sandstrip and Pratique do. The former strips only quarantine flags which have been set by the sandbox; the latter changes quarantine flags on selected documents to indicate that they have cleared quarantine. They are available from here.

This information is summarised with additional detail in the diagram below, where the three conditions are numbered, and the workarounds are shown in green.

The major problem with this mechanism as it stands is the behaviour of the sandbox. Unlike when apps pass quarantine, the quarantine flags on documents are volatile. Whenever a sandboxed app opens any document, a fresh quarantine flag may be written to it, which wipes out any existing flag which might indicate that the document has already cleared quarantine. The app may do this even when the document hasn’t been saved, and even when it replaces a legitimate quarantine flag which contains a UUID into the user’s quarantine database.

Thus all the workarounds can be undone by simply opening the document using a sandboxed app, leaving the user with the same problem with the document.


Further reading

馃帡 Quarantine: Apps
馃帡 Quarantine: Documents
Documents from an unidentified developer: quarantine misbehaviour in the log
Finder lost
Apple does provide a workaround for document quarantine errors

There don’t appear to be any relevant notes or articles by Apple.

I am very grateful to all those who have contributed information to help me understand what is going on here. I hope that you are now more wise too.