Will changes to notarization make any difference?
One of the most pervasive changes in macOS security, notarization of apps, is set to change again this summer. This article explains whats happening, and considers whether its 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 arent limited by it in any meaningful way: downloading and using an app which isnt notarized involves a small detour on the first run, but that doesnt 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 its 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 theyre quarantined). However, other software which isnt 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. Like every other security measure, notarization cannot provide perfect protection, but acts as a filter, and a very effective one at that. Notarization is but one layer of security among many, which are only needed because we, being human, still cant 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 havent heard anyone complaining about all the certificates on malware which have been revoked. So maybe were 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. What we dont 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 Apples, notarization will remain an important tool to ensure the cat doesnt fall too far behind in that chase. For the time being, at least, its hard to come up with an alternative which could be more effective. In a brief presentation, Olivia Hillman, one of the engineers who works on the Notary service, explained that those developers who notarize through Apples Xcode development environment wont 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 isnt perfect, but Apple continues to invest to improve it. Until someone comes up with a better idea, its likely to stay. Monterey doesnt 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, its not going away just yet.