Let's get this notarization stuff in order
Dave Mark is a smart guy. He has been teaching people to code on Macs for as long as your correspondent has written about them. So when we saw him draw the wrong conclusion from something basic, we knew we had to say something.
Wojtek Pietrusiewicz's recent post "The last Hackintosh," about making a generic PC that fools macOS into thinking it's Apple hardware that should run Apple's operating system. Pietrusiewicz suspects that "Since Apple recently updated their iMac with [Intel] Core I9 [processors] and skipped the T2 [security chip], this is probably the last time I'm building this sort of computer, before macOS is locked down forever."
Nobody cares
Mark followed this path, but let's tidy it up posthaste: Apple's push for increased Mac security has almost nothing to do with "locking down" build-your-own-clones. Apple licenses its operating systems only for Apple hardware, and therefore likely ignores the issue as much as possible. You can't buy a retail box of macOS anymore; you can only download it after agreeing to a license that says you'll use it only on Apple hardware.
In other words, there's none of this last-decade fuss about "I should be able to do what I want with software I bought." It's not free—it's included with a Mac, as are updates for that machine. If it appears to work, it probably fails silently in several cases (you can hope they don't involve disk I/O but no one's promising that), and no one cares if it doesn't work at all. No one who writes that code is trying to make it work. If they think of it at all, it's likely the opposite, but they're not going to slow down the operating system with copy protection.
Mark then added, "It does feel as if the Mac is heading down the road of getting more and more locked down." It's the same as saying "more and more secure" but from the perspective that hacking the OS is a good thing. But then Mark points to notarization in macOS Mojave and Catalina as "another sign of macOS lockdown." He quotes the requirements that as of 10.14.5, all software signed with a new Developer ID must be notarized. Also, in Catalina, all software built after 2019.06.01 and distributed with Developer ID must be notarized.
The quote is correct. (In fact, as of today, all software submitted for notarization must meet Apple's more stringent security requirements: it must use the hardened runtime, must sign all components with Developer ID, must include a secure timestamp with the code signature, must be built with current SDKs for Catalina, and cannot include the com.apple.security.get-task-allow entitlement that allows debuggers to inject code even on systems with System Integrity Protection (SIP).
These are not trivial changes to a lot of applications, especially utilities, and developers have rightly complained about the process. It did not help that Apple originally intended to force notarized software into using the hardened runtime without documenting what it was or what it prevented. (This was corrected in 2019.)
Less Carrot, More Stick
But this is classic carrot-and-stick Apple: if you want your software to run on double-click, you have to accept the hardened runtime that automatically stops code injection, library hijacking, and other common exploits. Apple can't provide these services for end users—the ones who should be protected—if it doesn't know when your code is trying something exploitable. (Heck, they designed an entire programming language around the idea of making common security bugs impossible. It's called Swift.)
If developers don't want to do this, they can opt out—but their users must explicitly acknowledge the risk on the first launch. Programs without notification should appear in the Security & Privacy pane of System Preferences in macOS 10.14 and later, with an "Open Anyway" button that will launch the program. Alternatively, in the Finder, those users will have to Control-click or right-click on the icon, pick "Open" from the shortcut menu, and then pick "Open" again in the ensuing warning dialog box. Still, all this is only on first launch. If you have approved the program, your system will launch it normally from that point onward.
Security is a big problem, and Apple is using a bigger stick than usual here. To developers, the message is, "users can always run your code if they choose." Yet to avoid everyone working around the system on every fake Flash installer, they do not advertise this information to users. It is thoroughly documented, but not linked from the main security pages. Apple clearly, and heavy-handedly, wants developers to notarize the software.
This is unfortunate in some ways, and we can see why Dave Mark got a bit lost. In the carrot-and-stick metaphor, notarization is supposed to be the carrot—the good thing you get for free by submitting your code to Apple for a return ticket that Gatekeeper checks. The stick is supposed to be the extra hoops to open non-notarized programs on first launch.
The problem is that the carrot is coated in castor oil—in this metaphor, that's the hardened runtime. Apple demanded that developers use something that was only mentioned in one header file somewhere without adequate explanation. The hardened runtime rarely affects simple application, but the more powerful your app becomes, the more the hardened runtime may interfere.
Do you have a long-standing Mac app that allows UNIX environment variables to affect its operations? Hardened runtime doesn't allow that; the programmer must ask for an entitlement to see those variables. Does your program need to load older plug-ins that aren't signed with Developer ID? That's another no-no without a special entitlement.
Many of the hardened runtime entitlements are the same as for sandboxed applications, so those programs are probably already rightly asking for access to your contacts, calendars, microphone (which weirdly seems to be a different entitlement in the sandbox than for hardened runtime), photos, and the like. And we'll be the first to admit that some of this is harder for utilities than for document-based programs. There was a to-do last year about the problems with trying to launch a non-notarized command-line tool because you don't double-click it in the Finder, so it's harder to use the workarounds.
But holy cow, if a program that has its fingers in as many parts of the system as 1Password 7 is notarized, the system has to be pretty robust.
Are you not satisfied?
Probably not, because we have yet to describe the actions the mysterious notarization process takes on your behalf! To be continued!