This week’s update to XProtect, bringing it to version 5354, came with a surprise: a brand new file that sets new security protection policies for eight widely used third-party apps. Although Apple hasn’t explained what this changes, this article hazards a guess.

Most recently, XProtect’s main focus has been on providing extensive sets of rules used to perform static detection of malware, but in the past it has been more versatile. In the days when most relied heavily on third-party Java support and used Adobe’s Flash Player, it was XProtect that blocked the use of vulnerable versions of those, in addition to checking for malware signatures. So this new protection isn’t entirely out of character.

The new file, AppProtectionPolicy.plist, is the first version of a set of default rules that apply protection to specific third-party apps, currently including:

• Chat client: Discord
• Browsers: Google Chrome, Brave, Microsoft Edge, Firefox
• Crypto wallets: Ledger Live, Exodus, Wasabi.

Over the last year or so, there have been malicious imposters and other code accessing private data of those apps, and the main purpose of this addition appears to be to block that. To accomplish this, the property list prescribes paths to the folder each uses in ~/Library/Application Support, together with an allowed Team ID and code signing IDs to set which apps and code are allowed access to the contents of each folder.

At the end, the property list also sets half a dozen sub-folders that are excluded from those protections. They form two groups, some for Native Messaging Hosts, and others to support Chrome’s Progressive Web Apps.

These are most likely linked to two new features listed for SIP in Apple’s Golden Gate release notes:

• “Accessing files in other developer teams’ app data containers and app group containers no longer prompts the user for authorization; such accesses are denied by default and can be managed by the user in Privacy & Security settings.”
• “XProtect may now restrict access to app data that is commonly targeted by malicious software. Accessing files created by other developer teams’ apps may be denied by default but may be managed by the user in Privacy & Security settings.”

This new AppProtectionPolicy.plist in XProtect thus appears to provide system security policy with the rules it needs for the second of those, specifying the apps concerned, their protected folders, and the IDs of the code that is allowed access to them.

What this doesn’t tell us is which versions of macOS can implement those rules. It seems most unlikely that this uses an existing mechanism built into previous macOS, and more probable that it requires significant new code to ingest the property list and apply it in system policy. It’s therefore almost certain that macOS 13 Ventura and earlier simply ignore this new file. It’s more plausible, although still unlikely, that Sonoma or Sequoia could apply it. While I think it’s more likely that Tahoe might be able to support it, as it has been announced as a new feature in Golden Gate, I suspect 27.0 might be the first to protect these third-party apps, another good reason to plan to upgrade earlier rather than later this year.

There’s a touch of irony here, in that current versions of Golden Gate being tested in beta can struggle to update XProtect data, and some are still running previous versions and are most reluctant to update, consistently returning errors for xprotect check. However, there are signs of change in that as well.