Paulo Andrade

Keeper of Secrets.

twitter github stackoverflow linkedin email
The Alert Hammer
Jul 31, 2019
8 minutes read

To a man with a hammer, everything looks like a nail.

There has been a lot of discussion about the increasing number of security alerts Apple has been adding to macOS, both with Mojave (10.14) and the upcoming Catalina (10.15). Michael Tsai has collected a large portion of that on his blog. So much has been said that I almost gave up on writing this… but seeing Apple go this route is so frustrating that I needed to vent.

The rise of the alert

Apple started adding user consent alerts way back in High Sierra. The first time an app would try to access your location, contacts, calendar, reminders or photos a system alert would prompt the user for consent. Mojave expanded these prompts to automation, camera and microphone. And now Catalina adds screen recording, keyboard input monitoring, access to folders such as Desktop, Documents and Downloads, user notifications and Safari downloads…

These alerts are just another step on a long path Apple has been taking to protect user’s data. Previous steps include code signing, sandbox, gatekeeper, the “curated” Mac App Store and notarization.

But security features are most useful when they’re invisible. All previous steps were mostly invisible. This last one… not so much.

The problem with alerts

Generally speaking, and from a user experience perspective, alerts should mostly be avoided. They interrupt the user and force an action/decision from their part. They break the user flow, and have high cognitive load. Simply put they’re “annoying”. And Apple knows it.

Slide from WWDC 19's "Advances in macOS Security"

Slide from WWDC 19's "Advances in macOS Security"

They do have their place, however. To confirm a destructive action that cannot be undone, unexpected errors, and of course, to confirm user intent when the action has potentially high security risks.

You probably are already aware that most users simply skim (or don’t read at all) the alerts that are shown to them. Their focus will shift straight to whatever action allows them to get back to what they were doing. Prompting for everything will further banalize the alert to the point of nuisance… making them, in effect, useless.

And we’ve been here before with Windows Vista.

The problem with the Security Through Endless Warning Dialogs school of thought is that it doesn’t work. All those earnest warning dialogs eventually blend together into a giant “click here to get work done” button that nobody bothers to read any more.

Coding Horror on Windows Vista

Microsoft admittedly toned down their User Account Control prompts (UAC) prompts since then.

Does this make the system more secure? If every user of Windows were an expert that understands the cause/effect of all operations, the UAC prompt would make perfect sense and nothing malicious would slip through. The reality is that some people don’t read the prompts, and thus gain no benefit from them (and are just annoyed). In Vista, some power users have chosen to disable UAC – a setting that is admittedly hard to find.

Engineering Windows 7 blog

Note how on one end of the spectrum alerts are useless for users that don’t understand the implications of allowing such access and on the other end experts want to turn them off.

So for the benefit of a few power users in the middle of the spectrum that feel more secure with these, every one else gets to be annoyed.

In short, alerts can be useful but they really must outweigh the cost of having them in the first place. And this is where I think Apple is failing badly. They are so excited with this new found hammer that they can’t help themselves but to hammer on.

A better way

To discuss some alternatives let’s group these alerts into different classes.

Live data

Prompting the user before an app can access the camera, microphone, screen or location is mostly useless. After the initial permission there’s no guarantee the app won’t use it again without user knowledge nor that the data it got was handled properly.

To make matters worse, some of these permissions actually require a visit to System Preferences and an app restart.

Secrets has this cool feature when setting up two-factor authentication where it would automatically search currently open windows for the QR Code with the seed value. On Catalina, this is now so cumbersome that’s just easier to manually type or copy/paste the value. So long for “surprise and delight”.

Sure there might be cases where you could discover an app is accessing your location or microphone without your consent… but now that the alerts are here, an ill intended developer can still build a feature as an excuse just for you to allow access. In the end, Apple is basically asking you to make a judgement call on the developer… Ouside of the developer community, how many users do you think are able to do that?

Still some people will say: “but I want to know if the app is doing that!”. That’s fair. Alerts aren’t the way to do it though. There’s a better solution and Apple already employs it for location services.

Menu bar icon listing apps using location

Menu bar icon listing apps using location

Now imagine the same for the camera, microphone and screen recording. You wouldn’t be prompted but simply notified. And you’d still be able to remove access if desired. Users who understand and care about these alerts would still know what’s going on, and for everyone else it would just work. Everybody wins.

Automation

I’ve blogged about this before but the gist is, not all automaton actions are security risks. Skipping a song on iTunes, or opening a mail compose window should not require user consent. User consent prompts should be left as a decision to the app performing the action, not applied blindly to every form of automation.

Disk access

Since sandboxing was introduced, apps do not have access to files outside their sandbox unless the user demonstrates intent (either via drag & drop or the open/save panel). But since its introduction that Apple has allowed apps to specify a set of folders that would be available to the app without explicit user consent.

Sandbox file access settings

Sandbox file access settings

Presumably, declaring these entitlements would allow Allow to rejects apps that did not have a valid reason for them. On Catalina, accessing these folders will now prompt for consent. Is this an admission that Mac App Store curation doesn’t scale? Even then, why separate these folders from the rest of the file system?

I believe a more generic approach is needed here. If apps declare which folders they want unrestricted access to (be it Downloads or the root folder) the user should be asked once at the initial launch for all the folders the app needs. This would prevent Terminal.app from yelling at me every time I cd into one of those special folders.

User notifications

Just like you’re used to on iOS, apps wanting to send user notifications now require user consent. But unlike iOS, apps on macOS can still create windows that mimic notifications and present those while in the background. It sounds like Apple added this just because “it’s the same on iOS”.

Either way, preemptively asking for permission to send notification isn’t the best solution. You’re probably familiar with the flow of opening an app, getting through a couple of setup screens to finally being asked for permission to send notifications. At this point you probably don’t even know what the notifications are for but you’re already being asked to make a decision.

Fortunately, Apple acknowledged this last year and added provisional authorization to notifications. This defers user consent to the first notification the user receives.

Slide from WWDC 18's "What's New in User Notifications"

Slide from WWDC 18's "What's New in User Notifications"

Unfortunately, the macOS team did not get the memo.

Safari

Safari already showed an alert every time you clicked on a link that opened an app1. By itself, opening and app should not pose a security risk. If the app can be triggered to do something potentially dangerous, it should be the app presenting the alert. At the very least, there should be a checkbox on the alert to whitelist the current website. This could probably have prevented the zoom fiasco

On Catalina, it will now also prompt you for every download!

The solution here is to send the Safari team to Europe for the rest of the year. After clicking “OK” on the 67838th cookie consent warning they’ll be vaccinated for life.

Contacts and photos

If anyone at Apple is reading this, congrats! You got this one right. Unlike above with live data, informing the user that an app accessed my contacts or photos would be too late.

However, unlike iOS there’s no dedicated UI to pick a photo or contact for uses cases where blanket access to this data is not needed.

Conclusion

Apple wants users to confidently be able to install apps on macOS. That’s a noble goal. Code signing and the sandbox are great examples of how that might be achieved. These security prompts however, I believe, do just the oposite.

For one, what once was software that just worked now is gated by annoying alerts and Security Preference trips. Secondly, for many users, the constant flow of security prompts forcing them to make a decision probably instills more fear than security.


  1. Apple exempts their own apps, so when you follow an App Store link the Mac App Store opens without any user consent. ↩︎



Back to posts