This is just Apple's overreach extended to the desktop. Excessive control that makes developer's lives hell while adding barely any security on top.
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.
The issues being called out here is that it comes at too high of a cost to both develops and users compared to the benefits it provides.
As for developers, well. Apple clearly do not treat their developers right.
They do, it’s called…code signing and notarization?
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.
Defense in depth requires one of the measures to catch things the other one wouldn't.
Defense in depth is layered, like an onion.
Combining automatic certification with fingerprinting is layered, like a cake. It's not the same thing.
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.
And that's exactly what I have a problem with.
> 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?
Is it really that hard to get your code signed as a malware developer? No, not at all. Is that worth bothering developers so much? Maybe not. Is it a power grab? Probably. Does that together make notarization useless for security? No, not really.
Notarization is just a step in the chain. It disincentives malware, especially trivial malware (which is the largest quantity and the most relevant for the bulk of the users) by tipping the economics of it slightly less in the malware developer's favor. It does this at the cost of also tipping economics less in regular developer's favor. You may disagree whether or not that's worth it (and I might be inclined to share that opinion), but that doesn't make notarization useless from a security perspective.
Moreover, Apple was also already using OSCP to check for revoked certificates when validating the code signature. They’d already revoked malware-producing Developer ID certificates several times in the past before notarization ever existed.
I think the issue with pushing malware signatures to the client is that it is reactive rather than proactive - i.e. by the time you have identified a malware signature, it is already too late (which leads to an inevitable cat-and-mouse / whack-a-mole game).
The big issue I’ve always had with capability security (as implemented here and in Fuschia) is that, while it is a better security model in many ways, it’s also a lot easier to use against developers and power users, especially when you depend on PKI to implement your unforgeable tokens.
But notarization is the same. Apple isn't vetting notarized apps before they're distributed. All it does is impose a cost on the developer, who could still for all you know be a member of the Russian mafia. Or any random developer who has had their machine compromised and then used to sign the compromising party's malware.
It doesn't get revoked until somebody identifies the code as malware. It's the same reactive process as malware signatures.
However if an inclusion list is used, then the malware changing its signature means that it loses the ability to execute.
A nightmare (and not cheap) to deal with it as a developer.
And that’s just non-Xcode. If you use Xcode it’s often automatic.
You can't have read the same article I just read!
XCode notarization does work for many developers, perhaps even the majority! It is a fragile process, though, and the author is not the only one for whom it fails.
This is not iOS where the App Store is the only way to install an app.
This comment is not an endorsement of any aspect of Apple's business model, I'm just correcting a factual error in your comment.
It was a great step forward, but I don't understand why they made it so complicated with an approval process, when Google did the same thing afterwards and could just say "the first million dollars a year is 15%, after that it's 30%".
The total revenue difference for the different companies is probably negligible.
(or... outside of the App Store you can sign up for a PayPal account and accept payments at a 3% rate instantly)
If you are a small dev with just one developer account, you'll sail through the applicaton process.
If your bar to hit is Linux, you'll never be happy with anything.
Note that this landscape might change in the future. Microsoft is working on Azure Code Signing, which will mean Microsoft themselves manages issuing the certificate, doing the identity verification, etc - the only catch being that they probably don't want to have to deal with any lost keys or improperly stored keys, so they don't let you generate your own cert and you can only sign certs via the API or other integrations. All of this info is available via this talk [2] and it's the only public information available on this service that i've found.
0: https://codesigncert.com/sectigo-ev-code-signing
Makes sense to me...