Categories
Data Custody The Next Computer

Apple M1 and the ultimate closed system – Part 1

Apple this week announced new Mac laptops and a desktop computer with its in-house system-on-chip. These computers do not use Intel’s processors. Instead, the “M1” chip includes Apple’s own CPU, RAM, graphics chip, and special-purpose chips for security and for machine learning.

By designing the Mac operating system specifically for this hardware (and vice versa), Apple’s M1 computers are now much more powerful at the same power consumption levels than their equivalent Intel ones.

However, with this chip, Apple’s computers are well and truly closed machines.

This closed nature is a problem because of just how much control it takes away from you, who’s paid for and ostensibly owns the machine and the software on it.

Let’s see just how bad it is.

1. Application software is controlled

The question is one of control over the software that you can run on the machine. With the M1, Apple will only allow signed software to run. From Apple’s documentation ealier this year:

New in macOS 11 on Apple silicon Mac computers, and starting in the next macOS Big Sur 11 beta, the operating system will enforce that any executable must be signed with a valid signature before it’s allowed to run.

This other article describes this in a little more detail:

Over the years, Gatekeeper has become more strict, recently adding a notarization requirement. On macOS Catalina, Gatekeeper not only checks whether the software was signed by a valid Developer ID certificate, it also “phones home” to check whether Apple has notarized the software, again refusing to run it if the check fails. Mac developers must sign up for the Apple Developer Program, sign a legal agreement, and pay an annual fee of USD $99 plus tax in order to obtain a Developer ID code signing certificate and upload software to Apple for notarization.

This article goes on to describe how – while not obvious – one could override these warnings on Catalina and run unsigned software. On MacOS Big Sur running on the M1 chip, Apple appears to have removed this exception. No matter what software you download and run – whether command-line tools or graphical applications – they will need to be signed.

This level of control means that Apple could refuse to sign certain apps if it wanted to, for reasons that have nothing to do with security. We have recently discussed how the youtube-dl project was taken off the code hosting site github. In the future, should Apple decide, it could disallow the running of youtube-dl binaries entirely, either downloaded from github or sourceforge or others. The only way that anyone would be able to run this tool would be to download the source code, compile it themselves and run it on their computers only by issuing themselves a local certificate to sign with. But they would not be able to hand that compiled code to someone else – even another Apple M1 machine they own – without compiling it separately.

That effectively kills distribution for software that Apple chooses to censor.

A long-time iOS engineer I know, who I ran this post by, had the following counterpoint:

Apple is definitely making it a pain for anyone to arbitrarily run 3rd party executable code, but to me the end result is just that developers will have to jump through a few more hoops. There will probably be a homebrew/pip/npm like solution that solves this soon. The end user should not see any significant change if they’re coming from modern Macs.

As for the Developer ID requirement – anecdotally I have only heard of one developer whose certificates were unilaterally revoked. Apple is far more likely to suspend your developer account and leave the certificates. This still makes Apple the arbiter of what you can run on your computer, and they will charge the developer for that privilege, but if you’ve only ever run GUI apps on your Mac this has been effectively the case for several years.

However, even Mac OS Catalina, leave alone Big Sur, appears to check for notarization of unsigned executables – even those not built using XCode. A simple hello world program compiled directly using clang is still subject to the same notarization check.

(Part 2 – It’s not just software; it’s control at the Operating System level and at the chip level)