Previous: I foretold that Mac app notarization is security theater Articles index Jeff Johnson (My apps, PayPal.Me, Mastodon)

December 25 2025

This is a follow-up to my recent blog post I foretold that Mac app notarization is security theater. Except for longtime Mac app developers, who have to deal directly with code signing, most people misunderstand notarization, because they don’t realize that notarization, added in 2018, was simply an extension to the preexisting Developer ID program, started in 2012. According to the Apple developer documentation:

A Developer ID certificate lets Gatekeeper verify that you’re a trusted developer when people download and open your app, plug-in, or installer package from outside the Mac App Store.

Give people even more confidence in your software by submitting it to Apple to be notarized. This service automatically scans your Developer ID-signed software and performs security checks. When it’s ready to export for distribution, your software is assigned a ticket to let Gatekeeper know it’s been notarized.

See also:

Beginning in macOS 10.14.5, software signed with a new Developer ID certificate and all new or updated kernel extensions must be notarized to run. Beginning in macOS 10.15, all software built after June 1, 2019, and distributed with Developer ID must be notarized.

In other words, a Mac app is first signed with a Developer ID certificate, and then the signed app is uploaded to Apple for notarization. Even before notarization, Apple always had the ability to revoke Developer ID certificates via OCSP (a service that infamously went down in 2020, causing worldwide havoc to Mac users).

The other day I saw a comment by a former Apple employee suggesting that the introduction of notarization was motivated primarily by XcodeGhost, a supply chain attack. Discovered in 2015, XcodeGhost was malware surreptitiously inserted into otherwise legitimate apps by a compromised version of the Apple Xcode developer tools. The compromised version of Xcode was hosted on a non-Apple server outside the United States, attracting developers in places where direct downloads from Apple of the extremely large Xcode archive could be painfully slow. XcodeGhost ended up infecting many consumer apps, both Mac and iOS, distributed both outside and inside the App Store. (So much for Apple app review, eh?)

I’ve argued that Mac app notarization is security theater. Specifically, I suggested that malware authors could notarize an innocent-looking app containing no malware and then instruct the app to download malware after victims have already installed and launched the app, a trivial bypass to Apple malware scanning. As mentioned in my penultimate blog post, this technique has now been observed in the wild.

My assumption all along was that notarization is intended to stop malware authors from distributing their own maliciously crafted apps, and in this respect I still think notarization is security theater. However, perhaps my assumption was wrong. What if the purpose of notarization is more narrowly focused, to prevent supply chain attacks like XcodeGhost? The requirement of uploading the built app to Apple for a malware scan is not very good at stopping a determined attacker with full control over app creation, submission, and distribution who is intentionally trying to sneak malware past Apple. On the other hand, the notarization requirement can stop an unwitting developer who is unintentionally distributing known malware in their app only as a carrier, a dupe, already a victim themselves.

The timeline of notarization seems a bit off, three years between 2015 and 2018 for Apple to engineer a mitigation for the massive, damaging XcodeGhost supply chain attack. I don’t see a sense of urgency there; it would be practically lackadaisical. Nonetheless, the motivation and implementation would make sense in light of XcodeGhost.

Is this blog post a mea culpa by me? Maybe! I now acknowledge there may be some security benefit to notarization. Whether the benefit outweighs the many downsides is another question, though. In any case, it would have been nice if Apple had made some kind of public, official statement like, "Hey, we’re introducing notarization because of XcodeGhost,” and then the whole thing would have made sense to everyone from the beginning. Instead, Apple chose its habitual path of greatest resistance, security by obscurity. Lords do not explain themselves to mere peasants; ours is simply to obey.

Some silly commenters on the internet have suggested that my criticisms cannot be taken seriously unless I present statistics, presumably statistics about how much malware is stopped and not stopped by notarization. I wonder from where in the world I or anyone else is supposed to obtain these statistics? Assuredly Apple itself collects some internal data, but Apple does not publish its internal data. My feeling is that these commenters are making Apple immune from all criticism: we cannot criticize Apple unless we present the very data that Apple purposely keeps secret. How convenient for Apple. Instead of demanding that I publish statistics about notarization and malware, you should demand that Apple publish these statistics, to back up their unsupported claims about protecting users from danger.

The same goes for App Store scams, by the way. Defenders of Apple OS lockdown admit that App Store review is not perfect (a straw man) while still claiming, with no empirical data whatsoever, that Apple review mostly catches App Store scams and other malware, letting only a small percentage through. But I don’t believe that for a second, nor should you, at least not based on faith and deference.

Jeff Johnson (My apps, PayPal.Me, Mastodon) Articles index Previous: I foretold that Mac app notarization is security theater