First we have this. Your computer isn't yours. We had something similar in the last millennium, but that time it was about not thinking a personal computer is so 'personal'. This time it's a bit different - it's about how your computer (at least your Apple computer) is never really yours at all, ever.
Let's take them together. Let's let ourselves get a bit paranoid. What do those two pieces say?
They say that you can't wipe and reinstall an Apple OS without realtime approval from Apple. Apple changed the disk layout of systems now, and it's possible that the secondary read-only volume is checked with a message digest, otherwise your system won't run. Note this is hardly about Apple protecting you from malfeasants. This is about Apple protecting Apple from you.
Now for the really creepy part. This is about when you try to launch an application.
If everything goes according to plan - and Apple definitely have a plan - then their system launch services, which will perhaps ultimately launch your application, will discover a sort of 'watermark' on your application's 'binary' or 'executable'.
The launch services will see this by inspecting the header section of the binary, something they have to do anyway. When they see the extra special section for this 'watermark', they'll then jump on disk to your application's 'CodeResources' file at the path 'Contents/_CodeSignature' and read it.
'CodeResources' is just an ordinary property list file, a sort of XML file. It doesn't contain resources per se. That's a misnomer. It contains checksums and instructions.
And so forth. The paths are relative to 'Contents'.
Note in the example above that even the blasted application icon is checksummed. So perhaps if you tried to improve that icon, your application wouldn't run any longer?
Occasionally you'll see the key:
Followed by either:
But 'false' is likely the default and can be omitted.
So, for every file mentioned here in 'CodeResources', the launch services will have to 'checksum' as they read it in (which they have to do anyway, mostly at any rate, as they're trying to run your application - only resources used at launch are loaded).
But at this point we're only a third of the way there. Or two thirds, depending on how you look at it. For to verify the integrity of all your files in 'Contents', aside from checksumming them again, the launch services have to verify the integrity of your binary (executable). This is made possible by virtue of the 'seal' put into your binary and thereafter referenced in the binary's header section. So if the binary checks out, and if all the other files - the NIBs, the image files, all the other files - check out, whichever order is used, then it's time for Step Three.
(Phoning Home. ☎)
That's right. And this is the really scary part. For every program launch on every Apple computing device needs realtime approval from Apple.
It's not as if some loser is sitting at a console in Cupertino and suddenly sees that Steve Blogs in Birmingham wants to run Calculator and then has to click 'OK' to get Steve's Calculator to run. It's all automatic, so to speak. The signal (request) comes in, the Apple computer looks through a checklist, and then approves. Or not.
What do the launch services on your Apple device send to Apple? Some is known. And of course this can change at any time. Things can begin with a so-called 'handshake', for example. Your device contacts Apple, then Apple makes a request, then your device fulfills it. Apple will need data on what application you want to run. The launch services can also be asked personal details about you and your device. Apple can allow or disallow the application, or they could have a ban on running any of your applications across the board. The important thing is the launch services won't run anything if Apple, far far away, don't give the go-ahead.
And as for the 'seal' on your binary: you can't put it there, not if you want Apple to market it for you. Apple will have to do that. The 'seal' is a so-called 'root certificate' which only Apple own. (Yes it's probably locked up in one physical vault after another.) So if you want to distribute your wares through Apple's App Store, you have to get Apple's approval to get the seal (unlike systems for comparable platforms). And Apple of course reserve the right to cancel your 'contract' at any time for any reason. (Oh they might give you an official reason, but that doesn't have to be the real reason. You'll never know the real reason. Sleep well.)
Is there any way around this?
For the part about wiping and reintalling: no. [Note this concerns the M1 or the T2, not the data drive.]
For the other part? Yes. Let us explain.
Apple's plan for 'total control' contains a 'gap'. A fly in the ointment.
Apple can't require everything on your system to be cryptographically sealed - only stuff you download from the Internet. There are still ways to dodge the matter with other transfer protocols, but most, including HTTP or web brower operations, are caught.
Initially Apple had the technology in their own web browser Safari but quickly moved into their own 'shell', connected to their 'Finder' and the Cocoa code class NSDocumentController. Safari will still issue notifications on downloads, but the code today goes much deeper.
Vital to 'closing the gap' for Apple is impregnating every download with the extended attribute 'Quarantine' or its full name 'com.apple.quarantine'.
Also vital for Apple is the ability of their other utilities to recognise this Quarantine flag and act appropriately. For example, the system unarchiver:
Will recognise this flag and dutifully impregnate every file item it expands and puts on disk.
So far, so good. Nothing really sinister has happened at this point. The launch services are not yet called in. They're only called in when you actually try to run something.
The launch services can't know if your application is 'legacy' (and is to be ignored) or if it's been cleansed by some third-party external tool. If your application doesn't have the Quarantine flag, then it's just run like any old ordinary application of old.
(In fact this is what happened on the day Apple released Big Sur: their servers got overloaded and no one anywhere on the planet could get things to work. Only products from one company continued to run as if nothing happened.)
The key is to remove the Quarantine extended attribute before the launch services find out.
Once the launch services find out, it's like Frodo putting on the One Ring: suddenly one is in an alternate universe, where you need permission to save a file to Documents, or to Movies, or to Pictures... Things can get pretty ridiculous. Justin Long would have a shit-fit and hide in the ladies room.
So how does one remove that Quarantine flag before the launch services find it?
First off, you have to be able to see it, and Apple didn't make that easy. There are some command-line tools, but they're not easy to use.
Xattr shows the attribute's name on the left and its contents on the right. The contents is initially displayed in hex, but this can be flipped to textual.
Xattr also lets you remove individual attributes or all at once, both for the current document window and for all open document windows. You can also add attributes of your own. Save the attribute itself to disk under the name you wish to give it, then import it and save it to your target file.
You can also export attributes to disk where they can be further inspected. (Attributes are often stored in the XML Binary format, so a utility like PlistEdit is perfect for the job.)
And to help you more readily spot the files with extended attributes, all our file management utilities automatically single them out, and our file system scanner Xscan has a special option just for that purpose.
Going through all downloaded files one by one would be quite the task, so there's another helpful utility available.
As its name implies, XaBatch works on batches of files - either recursively from a given directory, or directly through drag-drop. The user can specify which extended attributes are to be added or removed.
Even this can prove to be a burden with all the files you download, so for that purpose we created a 'quick and dirty' application that both cleanses files and write-protects them against further abuse.
Clean and Seal sits best at the bottom of your desktop, either off to the side or all along the bottom. And all you do is drop files on it. Dropped files are automagically cleansed and sealed.
As Safari so helpfully notifies the system when it's downloaded something, CandS also incorporated an additional technology called Seahaven. Seahaven will automatically find the files Safari mentions and cleanse them.
The Rixstep utility Lightman does the same. As long as Lightman's running, all Safari downloads are cleansed of their extended attributes, including the Quarantine attribute.
At this point it became obvious that a generic, and completely automatic, utility was called for. What was needed was something like the Windows NT file change notification system. Nothing like that is built into any of Apple's file systems, but the File System Events API proved to be just as good or better, although perhaps operating on a somewhat higher level (where 'low' is not pejorative but 'high' perhaps is).
It turns out that Apple's File System Events system is busier than Microsoft's by several orders of magnitude. To better study what was going on (and it's a lot) we created this. Note this is for educational purposes only, and does not remove any Quarantine flags.
Keymaster is the natural moniker for this brilliant app, as Apple's dungeoner got the Ghostbusters name Gatekeeper. Now the Gatekeeper is Sigourney Weaver in the movie and the Keymaster is Rick Moranis, but we needn't carry that analogy too far. Suffice it to say Keymaster nullifies all the evil Gatekeeper has done.
The key to Keymaster (no pun intended) is that it's completely configurable. You can run as many Keymaster processes as you want, simultaneously. You can blend several Keymaster processes into one process (advisable). You can specify precisely which directories Keymaster is to keep watch over.
Keymaster runs overlapping threads at different so-called 'latencies', being activated by the ubiquitous Apple File System Events daemon. What one thread doesn't get at, another one will. For manual intervention, one need only stop and start your Keymaster session again to get an automatic and instantaneous cleanse (and seal) of everything (recursively) in its target paths.
For this reason, it's advisable to keep your Desktop and Downloads directories as sparse as possible. The system's screen shot facility drops a lot of attributes (including Quarantine) on the files it creates, as does Apple's utility Preview.
What's It All Good For?
But what's it all good for? Not the Rixstep 'anti-Apple' utility bundle, as that should be obvious: a more complete freedom to do what you want on your own computer, and on your own terms, to make your computer your computer again, as much as possible.
But why did Apple do it? Certainly the reason they cite, improved safety, holds little water, especially after their extensive, seemingly never-ending, Justin Long campaign, hammering home again and again just how safe their systems already were.
The answer is 'money'. They're being sued on several fronts at the present time for their unprecedented 'Apple usury' of 30% 15% on all sales, a steep amount that only gets passed on to the consumer.
Current estimates are that Apple can enjoy an additional yearly profit of $6-8 billion just by 'forcing' more and more products into their App Store.
Apple's marketing are doing all they can to make 'next generation' users suspicious of anything not downloaded by Apple. This unknown highly suspicious software may damage your computer or abduct your grandmother. And they make it as difficult as possible, and increasingly difficult, to find the hoops users have to jump through just to run their own software.
But the disadvantages to the conscionable vendor far outweigh any advantagees. Selling one's soul into slavery doesn't lead to restful sleep either.
Stockholm/London-based Rixstep are a constellation of programmers and support staff from Radsoft Laboratories who tired of Windows vulnerabilities, Linux driver issues, and cursing x86 hardware all day long. Rixstep have many years of experience behind their efforts, with teaching and consulting credentials from the likes of British Aerospace, General Electric, Lockheed Martin, Lloyds TSB, SAAB Defence Systems, British Broadcasting Corporation, Barclays Bank, IBM, Microsoft, and Sony/Ericsson.
Rixstep and Radsoft products are or have been in use by Sweden's Royal Mail, Sony/Ericsson, the US Department of Defense, the offices of the US Supreme Court, the Government of Western Australia, the German Federal Police, Verizon Wireless, Los Alamos National Laboratory, Microsoft Corporation, the New York Times, Apple Inc, Oxford University, and hundreds of research institutes around the globe. See here.