Ventura has changed app quarantine with a new xattr

Now that we’re approaching half time in Ventura’s cycle, it’s good that we’re still discovering new features that Apple forgot to mention at WWDC last June. This article outlines how macOS 13 has changed the process of app quarantine, with the addition of a new extended attribute to track the origin of quarantined apps in their provenance.

Clearing quarantine

What used to happen when a file was downloaded using Safari or another app that supports quarantine, was that an extended attribute of type was added to the downloaded file. This contains the quarantine flag itself, indicating whether it’s set or has been cleared, the time of its attachment, the app or agent that attached the flag, and a UUID reference to an entry in the QuarantineEvents database at ~/Library/Preferences/

When that app was run for the first time and underwent Gatekeeper’s full checks, if it was accepted, the quarantine flag was changed to indicate the app was no longer quarantined, and future launches of that app didn’t undergo full first run checks. For instance, the normal quarantine flag attached when a file transits AirDrop is 0081, and when that’s cleared it becomes 00c1. Other than that changed extended attribute, there seems to be no record kept of the clearance of that flag.


What happens in macOS Ventura is essentially the same until the moment that quarantine is cleared, when macOS now attaches a new extended attribute (xattr) of type to the file. This contains an 11-byte binary reference unique to that quarantine event, and may be protected by SIP to make it persist and prevent it from being stripped.


For example, when an app is transferred between Macs using AirDrop, any existing xattr is replaced with a new one with its flag is set to 0081. When that app is successfully opened on the recipient Mac, and its quarantine flag is changed to 00c1, an 11-byte xattr is added and SIP may be applied to it to prevent its removal.

Some early releases of Ventura appear to have been more thorough in applying the xattr, and have added it to every folder and file within an app when it was taken out of quarantine; in that situation, the 11-byte identifier is identical across all files and folders taken out of quarantine in that app. Behaviour in macOS 13.2.1 currently appears limited to attaching just a single xattr to the .app folder. You may also come across apps in which the original xattrs have been stripped, leaving just the protected xattrs behind.



Defeating any SIP protection is simple for the user: when an app with a protected xattr is copied to another volume, the SIP protection breaks, and the xattr can be deleted in the normal way. However, code that tries to remove that xattr while it’s still protected may fail, and that has resulted in problems reported in Ventura by some users.

Unlike the other xattr that can be attached to any file as part of TCC’s privacy protections, and is also protected by SIP, should only ever be attached to apps and their contents. It always seems to be just 11 bytes in size, although in one case rose to 4096 bytes through trailing padding with zeros, presumably as the result of an error on the part of macOS.


The purpose and use of the xattr is currently unknown, and appears to be still evolving. I’d be very interested to hear of other evidence of its behaviour and use in quarantine.


  • Ventura introduces a new extended attribute, attached to apps when they clear quarantine.
  • The xattr contains binary data of 11 bytes that is unique to that quarantine event.
  • The xattr is protected by SIP, so can’t be removed unless the app is copied to another volume.
  • It’s otherwise undocumented, and its purpose and use are unknown.

GUI access to xattrs and the crawler used above are features of my free utility xattred.


I’m very grateful to Randy Saldinger of Mothers Ruin for pointing out that SIP isn’t always applied to the xattr. I’m not sure whether this only occurs in certain circumstances, or in earlier versions of Ventura, but has been a previous cause of complaint about this xattr.

Randy has also identified the binary content of this new xattr as containing an 8-byte integer that is that app’s primary key in the provenance_tracking table in /var/db/SystemPolicyConfiguration/ExecPolicy. This would enable macOS to check the previous cdhash and other information about the app, perhaps to determine whether fuller checks are required by Gatekeeper, when the app is launched on subsequent occasions. That would make it a key part of Ventura’s new extended Gatekeeper checks.

Please read Randy’s comments below for further information.