One of the most pervasive changes in macOS security, notarization of apps, is set to change again this summer. This article explains what’s happening, and considers whether it’s benefiting the user.

Under current rules, all third-party developers of software for macOS are supposed to deliver their software through the App Store, or to notarize it before distributing it independently. Although Apple makes this a rule for developers, users aren’t limited by it in any meaningful way: downloading and using an app which isn’t notarized involves a small detour on the first run, but that doesn’t seem set to change in macOS 12. Nor has Apple announced any change in rules over the signing or delivery of software.

The rules for users as they stand are:

• Completely unsigned code can still be run without penalty on Intel Macs, and on M1 Macs only in Rosetta 2.
• Code signed using ad hoc rather than Apple-issued certificates can be run without penalty on all Macs, including natively on M1 Macs.
• Code signed using a developer certificate, whether or not it’s notarized, can be run without penalty on all Macs.

There are some small but important exceptions to this, kernel extensions in particular, which are required to be notarized on both Intel and M1 Macs. Another more complicated class of software are plug-ins for other apps, which have to be notarized, otherwise the user may have to explicitly approve the plug-in through the General tab of the Security & Privacy pane (when they’re quarantined). However, other software which isn’t notarized or supplied from the App Store will take the more circuitous route through Gatekeeper checks when first run only after it has been downloaded from the Internet, or copied across using AirDrop, which also sets the quarantine flag.

But every few weeks, we hear about more malware which Apple has happily notarized, and told us that it has checked for malicious software and found it to be wholesome. So what’s the point of notarization if we can’t fully trust apps which have been notarized?

Like every other security measure, notarization cannot provide perfect protection, but acts as a filter, and a very effective one at that. Just because passwords or any other form of security protection aren’t perfect, you don’t give up and use easily guessable passwords, do you? I know that a good lockpicker could probably unlock my front door in less than a minute or two, but do I leave the house unlocked to spare them the bother? Notarization is but one layer of security among many, which are only needed because we, being human, still can’t seem to resist tempting offers like a Flash Player update six months after Adobe finally killed it.

Another argument against notarization which seems popular is that it gives Apple a ‘kill switch’. Of course, Apple has had, and used, certificate revocation as a means of blocking signed apps from being run since 2019, and long before that it was blocking known malicious apps from being brought out of quarantine. Over that period, I haven’t heard anyone complaining about all the certificates on malware which have been revoked. So maybe we’re only too happy when certificate revocations block malware, in which case what we want is some means of detecting malware before it gets distributed to users. Like notarization, perhaps?

What we don’t see, or perhaps appreciate, is what Apple gains in its battle against malicious software from the notarization process. The most essential data in addressing malware is a copy of that software. Not only does notarization give Apple a copy of all the software which is notarized, but macOS sends Apple the cdhashes of all newly-opened software. Should any notarized software turn out to be malicious, Apple already has everything it needs to block the malware from running when newly installed, revoke its certificate, update XProtect (and MRT, where appropriate) to detect the malware, and monitor prevalence on Macs. Once detected, the time to deploy effective countermeasures is greatly shortened by notarization.

The battle against malicious software remains cat-and-mouse, as it always will be. If we want to be able to run the software of our choice, rather than just Apple’s, notarization will remain an important tool to ensure the cat doesn’t fall too far behind in that chase. For the time being, at least, it’s hard to come up with an alternative which could be more effective.

So what did Apple announce about notarization at WWDC this year?

In a brief presentation, Olivia Hillman, one of the engineers who works on the Notary service, explained that those developers who notarize through Apple’s Xcode development environment won’t see any change in that process, but anyone who has been using the command altool can now use a new and improved command notarytool instead. This addresses some of the problems which developers have experienced with customised methods of notarizing their software. An example command now reads:
xcrun notarytool submit OvernightTextEditor_11.6.8.zip --keychain-profile "AC_PASSWORD" --wait --webhook "https://example.com/notarization"
which will need to include an app-specific password to negotiate 2FA on App Store Connect.

She also said that the Notary service has been streamlined, and now has a dedicated backend which should be both more reliable and faster. Performance targets are for notarization to be completed within 15 minutes for 98% of submissions, and most to be finished in less than 5 minutes.

Developer details on notarization generally are here, and the new notarytool is explained here.

Summary

Notarization isn’t perfect, but Apple continues to invest to improve it. Until someone comes up with a better idea, it’s likely to stay.

Monterey doesn’t appear to make any significant changes to current macOS policies for running unsigned or non-notarized code. If it works in Big Sur, it should also work in macOS 12.

Those developers who have been using altool to notarize their software can now use notarytool instead, which should improve their workflows. Although altool is now deprecated, it’s not going away just yet.