>You can get practically as much security by pushing malware signatures to the client without the massive privacy overreach of having Apple archive each and every bit of code that you generate for distribution.
> Notarization is clearly part of a defense in depth strategy for macOS.
Defense in depth means layering security. It's, for example, when you use password hashing but also full disk encryption. That way if someone gets your hard drive, even if they break the disk encryption, they don't get your password in plaintext. Even if they know how to crack the password hash, they first have to get past the disk encryption.
Notarization and signatures aren't two separate measures. They're the same measure implemented two different ways. That's basically useless. If some piece of code is identified as malware then it both gets revoked and added to the malware list, and then they both catch it. If it hasn't been identified then it's neither revoked nor on the malware list.
The things that make it past one also make it past the other. There is no defense in depth because there is no depth. The two measures would have to operate based on a different principle in order to achieve that.
Notarization is distinct from code signing/signatures, and has distinct security benefits. Notarization involves uploading the entire binary to Apple, where signatures involve you creating signatures on files that Apple is blind to.
Apple cannot guarantee they are revoking all certificates for a given malicious application with code signing, because they do not know what variants exist even if they have obtained one of them. Revoking just one code signing certificate may not be sufficient. With notarization, they can search for these variants and prevent new variants from being signed by new developer accounts -- protecting machines that i.e. have outdated XProtect definitions.
It's linguistically confusing to try to distinguish between malware signatures and digital signatures when we're comparing them, so let's call one fingerprinting and the other one certifying.
> Apple cannot guarantee they are revoking all certificates for a given malicious application with code signing, because they do not know what variants exist even if they have obtained one of them.
This is making the case that certification/notarization is worse than fingerprinting because the same malicious application could have multiple independent certificates. But since notarization is the thing people are objecting to, that's no argument in its favor. (Though, of course, they could, and possibly do, refuse to notarize apps with known-malicious fingerprints, so if there is a difference there at all then it's only by implementation and not by necessity.)
> With notarization, they can search for these variants and prevent new variants from being signed by new developer accounts -- protecting machines that i.e. have outdated XProtect definitions.
Let's think about this for a minute. You have a malicious application that at one point had a valid certificate. The user goes to run it.
If they have a working network connection to check whether the certificate is revoked, they have a working network connection to get the latest malware fingerprints. If they don't, they get neither. So what's it buying you?
XProtect has a wider scope than notarization, though, and its detection rules are different. Notarization and XProtect are both focused on stopping malware but they don't actually operate on the same principle, notarization happens in the cloud before deployment (to stop malware from being deployed) and XProtect happens continuously in the operating system (to stop malware from running), checking for malicious signatures. That functionality intersects with notarization, but it's not equivalent.
It operates based on the same principle. There is a list of known-malicious software and you reject that software. If the bad software is known, they can both reject it. If it isn't known, neither of them would.
Defense in depth requires one of the measures to catch things the other one wouldn't.
I hardly notice the cost as a user. Sometimes I have to right-click and application to open it the first time, same as it’s been since Gatekeeper was introduced as far as I know.
As for developers, well. Apple clearly do not treat their developers right.
A defense in depth would be to have layers of trust for applications, identifying and preventing bad behaviours, rather than trying to lock developers in.
Apple do this too, it's called XProtect: https://support.apple.com/guide/security/protecting-against-...
They also have a built-in malware remediation tool, which is presumably what was used when they killed the vulnerable Zoom web server on everyone's Mac: https://www.zdnet.com/article/apple-update-kills-off-zoom-we...
Notarization is clearly part of a defense in depth strategy for macOS.