A few weeks ago, shortly after completing a clean installation of Catalina on my MacBook Air, I had a funny idea: wouldn’t it be great to reinstall Lion, the operating system it shipped with, and see what it is like to use nearly ten years after it was released?
I haven’t touched a truly old version of MacOS in years, and certainly not one called “Mac OS X” in a very long time. For a start, installing an old version of MacOS in 2020 is more difficult than it sounds, especially if you don’t have a copy of the specific or newer version of the operating system that shipped with your Mac because you resolved to become slightly better about your data hoarding habits.
It becomes significantly easier after you recognize that you failed that resolution.
Installing Lion was refreshing — in part because there are far fewer steps in Setup Assistant. There are just eleven screens, the last of which informs users that Lion changes the direction the trackpad scrolls relative to the material onscreen. There’s an animation of this and, cleverly, Apple requires users to scroll to the bottom of a small text area to click the button that finishes the setup process. You may not start using Mac OS X Lion until you have learned how to scroll.
However, perhaps the most notable part of installing Lion was that it was ready to go immediately after completing the steps in Setup Assistant. The last screen appears and confirms that Lion is set up, then the desktop zooms in, and then you can use your computer right away. Sure, Spotlight will be indexing, so it will be slow for a while, but you can get started.
Catalina is different. Many steps have been added to Setup Assistant since Lion, including options to turn on location services, enable Siri, enable various iCloud features, and — for Macs with supported hardware — steps to enrol fingerprints for Touch ID and add credit cards for Apple Pay. Some screens have been removed (remember registering your Mac?) or consolidated (picking the user picture is now done when setting up the admin user account), but the process is still far more expansive than it used to be. I counted at least seventeen screens; some screens have been consolidated as an “express setup” option, and the Apple Pay and Touch ID features are not supported on my Mac.
And that’s just Setup Assistant. After you complete those steps and you see the Catalina desktop for the first time, you have more work ahead of you. Apps need permission to send you push notifications, permission to use your contacts, and permission to use your location. Even though you said you wanted to switch on Location Services and that it was okay for Maps to use your location, Maps will ask for your location the first time you run it. Calendar will ask to use your location immediately after setup finishes. The weather widget in Notification Centre will need to be granted location permission now and probably several times in the future. Notifications will appear that you will need to dismiss.
There’s more, too. If you download apps from a source outside of the Mac App Store, you’ll be asked if you really want to open the app upon its first launch. This has long been a feature of MacOS’ Gatekeeper security software, but Catalina requires apps to be notarized. If the app is not notarized, Catalina will tell you that the app “cannot be opened” and give you the options to cancel opening it or move it to the trash. This is a lie: you can open the app — any app — by visiting the Security & Privacy preference pane, clicking the “Open Anyway” button, and then bypassing another scary-looking warning dialog.
The way that Catalina determines whether an app is safe seems to depend on several factors, and they can collide in comical ways. While writing this piece, I wanted to install a fresh copy of Catalina on a new volume of my MacBook Air’s hard drive to verify the installation procedure above. However, I only had a copy of the installer on my iMac, so I AirDropped it to myself. When I went to run the made-and-signed-by-Apple package, originally downloaded from the Mac App Store, I was told that it could not be opened because it was potentially dangerous.
The path to this present reality more or less began with Lion. It was the first version of the system to be available through the Mac App Store, introduced in a late update to Snow Leopard, and, with it, came the “Allow Apps Downloaded From” section of the Security & Privacy preference pane. It originally contained three options:
Mac App Store
Mac App Store and Identified Developers
Anywhere
That last option has been hidden since MacOS Sierra. It’s still possible to open apps from anywhere, but MacOS now requires you to jump through hoops that weren’t there previously. And these hoops are ratcheted tighter with every recent version of MacOS. Catalina, in particular, is notable for the vast quantity and types of cautions that users are expected to handle.
Want to download a file from a website? Safari will get you to confirm that you actually want to download that file.
Explicitly typed a command in Terminal that accesses your desktop — even something as innocuous as ls ~/Desktop? You’ll have to confirm that you are, indeed, okay with Terminal’s desktop access.
Want to run ls ~/Downloads? You’ll have to okay access to that folder, too. There’s no way to say, in any of these dialogs, that you’re entirely okay with anything Terminal wants to do. You can, however, give Terminal full disk access in a different tab of the Security & Privacy preference pane.
Security & Privacy was one of those things in Preferences that you used to set and forget. It now seems as though it’s something you’re expected to open regularly if you are a technically inclined user.
These security prompts and confirmation dialogs also have the effect of offloading some of the responsibility for a secure environment to the user in a way that, I believe, is unfair. It’s irritating to more technically literate users because it adds work to everyday tasks. For them, it is a regression.
Less technical users, on the other hand, do not have the skillset to determine what is a security concern and what isn’t. It doesn’t help that some of Apple’s own apps, daemons, and background service have inscrutable process names and many of them need some form of permission or password to run. Nor is it helpful that the Gatekeeper warnings change in mysterious and undocumented ways. But, even if everything were perfectly labelled, a user with less technical background wouldn’t have an informed clue about what they should allow and what is genuinely dangerous.
Furthermore, we know that overloading users with permission prompts encourages them to click whatever button will allow them to move on with their task, which means that they are more likely to agree to something unintentionally. We also know that people exposed to alerts and alarms on a frequent basis learn to tune them out, even in cases where those alarms are extremely important, like in hospitals (PDF). The fire alarm in my apartment building has been mistakenly activated so frequently that it is more or less just background noise. I’ll probably burn to death one day. I’ll also probably mistakenly click an “okay” button and unleash some form of minor havoc on my computer because I am inundated with permission prompts.
It’s not just security-related permissions, either. When a MacOS app wants to show push notifications, it must ask the user for consent. It’s the same thing for location, use of the microphone, a Mac’s camera, and accessing contacts, calendars, reminders, and photos. And then there are APIs that allow apps to watch over keystrokes, control other apps, and control the computer. Individually, these permission requests aren’t dreadful, but they quickly accumulate.
I’ve seen various proposed solutions to this onslaught, often centred around the idea that MacOS now needs some sort of “pro mode” — a command line switch or something of the sort that allows an advanced user to disable much of the system’s nanny state policies. That’s not a bad idea, but I don’t think it fully acknowledges how bad this situation is.
Permission consent dialog boxes are a particularly ham-fisted approach towards privacy and security. They are a last-ditch effort; an over-reliance upon them in Windows Vista was famously parodied by Apple in a “Get a Mac” ad. At best, they are irritating. But, at their worst, they are an acknowledgement by the company that builds the platform that they have been defeated in a larger argument.
The reason there are so many privacy-centric requests is because there are basically no limits to the exploitation of personal data. If we had the confidence that allowing an app access to our contacts, for example, would not expose that list to data mining and privacy-invading marketing nonsense, we would not need to spend time granting permissions.
Unfortunately, there isn’t a comparable fight for security vulnerabilities. Users’ trust is an infinitely exploitable resource and it is the primary job of malware creators to do just that.
Yet I return to my argument that requiring users to determine which processes are safe is a demand that is overwhelming to most and disruptive to the comparatively few users who are equipped to handle such a decision.
Of course, there are other protections built into the system that help prevent malware and other problematic software from running. Apple explains several of these on its marketing page for Catalina, and there are other technologies like sandboxing and the antivirus protection offered by XProtect and MRT. But if security is, as with so many things in life, like an onion, the dialog boxes are like individually wrapping a bag of the things in clingfilm: it ends up being something that gets in the way for pseudo protection. These seemingly endless permission requests disrupt the Mac’s balance of capability and user friendliness.
The future of the Mac — a friendly face atop a powerful Unix core with an amazing software ecosystem — should not be a bureaucracy that cripples its finest qualities, nor one which users are responsible for fidgeting with.
Update: The Mac App Store was introduced in an update to Snow Leopard, not Lion, as previously and incorrectly stated.