Mojave’s New Security and Privacy Protections Face Usability Challenges

posted in: October 2018 | 0

The boy who cried wolf.Photo by the Internet Archive.


Mojave’s New Security and Privacy Protections Face Usability Challenges


Back in 2016, security researcher and developer Jonathan Zdziarski released a tool called Little Flocker that could protect Macs at the file level. Much as a firewall analyzes and blocks network traffic, Little Flocker locked down the file system and allowed only authorized applications access to only approved files.

Little Flocker was too complex to manage for average users, but it quickly became a darling among Mac security experts. Most modern malware doesn’t blindly hit your computer through a network scan. Instead, it tricks you—or your computer—into installing some piece of software that then does bad things. Little Flocker ensured that applications could access only data they were supposed to, making it far more difficult for malicious software to complete its nefarious mission. In fact, this compartmentalization is the foundation of iOS security and one of the primary reasons that iOS is the most secure consumer operating system available.

A Little Flocker alert.

When Zdziarski took a job at Apple in 2017, he sold Little Flocker to the security vendor F-Secure, which released it as Xfence. Zdziarski’s job change started the clock ticking on when we might see similar capabilities built into macOS. With macOS 10.14 Mojave, Apple has added file-level protections, plus some additional security enhancements. And you know what? Mojave is running into the same usability issues that users of Little Flocker endured.

Apple is enhancing OS security to boost OS privacy

Apple has been inching down this path of protected files in macOS since it introduced Gatekeeper and sandboxing. With each release, Apple has tightened the sandboxing screws to limit the traditionally near-unfettered access of apps. However, application sandboxing as we’ve seen it so far applies only to apps downloaded from the Mac App Store and offers no protection to apps installed from any other source.

Mojave extends these protections in three key areas across all applications on your Mac:

  • Access to the camera and microphone
  • Access to certain private data stores (beyond those protected in High Sierra)
  • Inter-application communications with Apple events

Access to the camera and microphone is easily understood. If an app is going to use the camera or microphone, it needs to ask for permission, just as apps do in iOS. There’s little that’s controversial or potentially problematic about this privacy enhancement.

For most Mac users, the most obvious and significant changes are the enhanced notifications and protections for managing access to core privacy-related data stores: Location, Contacts, Calendars, Reminders, and Photos. In Mojave, when an application tries to access your location, contacts, calendars, reminders, or photos, you’ll need to approve that request to grant access. Again, this is similar to how things work in iOS and High Sierra—when an app wants to work with your photos or contacts, it has to ask permission first.

You might be thinking that there’s quite a bit more that deserves protection, and you’d be right. In fact, Mojave extends protection to data in Mail, Messages, Safari, Home, Time Machine, and certain administrative settings, but without the granular notifications of the data types we’ve been discussing. Apps can request access to data in Mail or Messages or Safari too, and they’ll appear in the Full Disk Access list in the Privacy pane of the Security & Privacy preference pane.

The Full Disk Access list in the Privacy pane of Security & Privacy.

Keep in mind that non-Apple data repositories don’t receive this special protection, so if you use a third-party photo app (like Adobe Lightroom) or calendar software (such as Microsoft Outlook) with its own database and storage, these new protections won’t help you.

The first time you launch an app that tries to access these data stores, you’ll get a notification dialog asking for access. If the app was compiled with the Mojave-specific version of Xcode, the notification will feature developer-provided text describing why the app wants access. For older apps, the notification will instead show generic, Apple-provided text.

Screenshot showing an authorization request from Mimeo Photos, with the developer-supplied text.

Here’s where things start to get tricky. If you provide access, all should be well, since the app is getting the data it expects, and it will appear in the appropriate list in the Privacy pane of the Security & Privacy preference pane.

But if you deny access to an older app, it may crash, since it has no way of anticipating such an error condition. Since Apple hasn’t yet officially released Mojave, we can’t say for sure what will happen, and it will undoubtedly vary by app. For a deeper dive on these changes over time, developer Howard Oakley has written some excellent posts about his struggles to update his tools for Mojave.

Protecting inter-application communication is complex

Mojave also introduces new authorizations for the Apple events that applications use to communicate with each other. Apple events are the essential backbone to Mac automation capabilities you might not even realize you are using, because Apple events enable one application to launch and sometimes control another app.

In a blog post talking about how scheduling and scripting works in Super Duper, Dave Nanian of Shirt Pocket notes that simply choosing Show in Finder in Xcode will trigger a new authorization request. (That was true in Mojave beta 8; in beta 10, Show in Finder works without an authorization request but choosing File > Open in External Editor in Xcode still asks to control the Finder.) The ability to interconnect and allow applications on the Mac to communicate and send commands to each other is deeply embedded into far more applications than the average user might realize.

An annoying Xcode permissions prompt.

These inter-application requests also trigger notifications to authorize access, again using a mix of developer-specified and default text. Combined with the personal data protections, this could lead to a flood of alerts and user confusion. Nanian compares it to the well-intentioned but eventually removed alerts that Microsoft used in Windows Vista.

Windows Vista User Account Control prompt.

And of course, lots of people write their own apps using AppleScript. Over at Six Colors, Jason Snell talks about how he wrote an AppleScript-based app that demands authorization repeatedly even after he added it to the Accessibility list in the Privacy pane of the Security & Privacy preference pane.

Authorization request dialog from an AppleScript app.

Developer Felix Schwarz discusses these complexities with a deconstruction of the notifications and the complexity required to manage them. Apple has addressed some of his concerns, but will likely struggle for some time to strike the right balance between security and usability.

Mojave lets developers protect their own apps

While the most visible changes in Mojave center around user notifications, the Mac’s new operating system also includes a range of additional under-the-hood hardening. Some of these are obvious evolutions, such as enhancements to the System Integrity Protection (SIP) features that defend the core operating system from malware.

In an unexpected set of changes, Apple is extending some of the runtime protections it uses for its own applications to developers. Opting into these improves an application’s ability to protect itself from being compromised by malware, with features like improved code signing, a tighter “chain of trust” to allow only expected code libraries, and restrictions on running debuggers against an app. All of these inhibit common ways attackers compromise applications to gain control of a system.

Apple has even created a notary service for developers to submit applications for additional review. Unlike app review, this notary service is available to all applications, even those distributed outside the Mac App Store. Notarized apps are checked for their security settings and embedded malware before Apple will sign them. This is merely the first step, as Apple intends to require notarization for all apps signed with developer IDs in the future. If you recall, a developer ID is required to install an app on Macs with the default Gatekeeper settings.

With great security come great usability challenges

Regardless of how Apple finesses these dialogs in Mojave and its updates, all Mac users will need to get used to authorizing app requests for privacy-protected data as they now do on iOS. Balancing security notifications and authorization requests is notoriously tricky. Prompt users too often and they will both become annoyed and reflexively click OK. A security feature has failed when the noise of so many alerts leads users to stop reading them—and that eventually leads to malware asking for and receiving authorization. It’s a modern-day version of the “The Boy Who Cried Wolf.”

These prompts are nothing new to anyone who uses a recent version of iOS, but the concern is that the Mac is a more complex environment with more inter-app communications and cross-app file access than most users tend to use on their iPhones.

As a security professional, I don’t think Apple has much of a choice in adopting file level protections. The threats are just too great, and the liability just keeps growing. Apple has, for the most part, focused on the right data to protect, but it still needs to improve the user experience surrounding notifications, especially for users with a mix of old and new applications that use different wording for their authorization requests. Practically speaking, most users don’t install that many applications that access these personal data stores. And even then, authorization requests for contacts or photos are relatively easy to explain, and for users to understand, particularly if they’ve seen similar requests in iOS.

Some types of applications, such as backup apps, face greater challenges. For example, I use Arq for system backups (see “Roll Your Own Cloud Backups with Arq and B2,” 18 May 2018). After installing the Mojave beta, I experienced a string of repetitive alerts for access to every one of my protected data categories, followed by failed backups even after I clicked OK a few dozen times. The eventual answer was to go into the Security & Privacy preference pane and add Arq to the Full Disk Access list manually. Average users would likely have trouble figuring this out on their own, and they may be confused and unhappy about having to do it even if the developer provides instructions.

Authorization requests for Apple event–based inter-application communication are even more likely to be problematic from a usability standpoint. Developers will have to update their apps with useful notification descriptions, plus include extensive error handling in case users make a decision that impedes an app’s functionality.

Apple needs to improve Mojave to provide both developers and users with clear alerts that avoid the pitfalls that crippled so many similar attempts in the past. There’s a reason any mention of Windows Vista still sends shudders down the spine of anyone who worked a help desk during those perilous times. And the company needs to improve the current situation for anyone who creates AppleScript-based apps to make sure such apps don’t prompt constantly for access.

Don’t get me wrong. Apple is moving in the right direction. These features have measurable security benefits and the potential to make attacks against Mac users dramatically harder, which will result in increased safety for all. Mojave’s security and privacy enhancements are a natural progression from Gatekeeper, sandboxing, restrictions on kernel extensions, and the under-the-hood hardening of recent years. Combine these software changes with Apple’s recent inclusion of special security hardware in the MacBook Pro and iMac Pro, and you can see how the company is driving Mac security closer to where iPhones and iPads are today, all while striving to maintain the flexibility that makes the Mac essential.

But to achieve that goal, Apple must put more work into striking the right balance between security, privacy, and usability.

A Prairie HomeKit Companion: Automating Your Home

At this point in our “A Prairie HomeKit Companion” series, you should be up and running with HomeKit home control. We first covered installing and setting up your Accessories and then discussed how you could control them individually and create Scenes to control them in groups. In this installment, I’m going to show you how to use Automations to toggle Accessories or Scenes when certain triggers fire.

Before you can automate HomeKit, you must have a device that can act as a hub: either a fourth-generation Apple TV or an iPad running iOS 10. The hub is necessary because something in the house has to be present to trigger Automations. Setting up a HomeKit hub confers an additional advantage: it lets you control your Accessories while you’re away from home.

The Hubbub About Hubs — Why can only Apple TVs and iPads work as HomeKit hubs? Why not AirPort base stations, which are already hubs of a sort? The reason is likely that the Apple TV and iPad both support Bluetooth, which controls many HomeKit devices. Why can’t you use a Mac as a hub? Your guess is as good as mine.

An iPad is slightly easier than an Apple TV to set up as a hub, and chances are better that you have one, so I’ll start there:

    1. In Settings > iCloud, make sure that you’re signed into your primary iCloud account.
    2. Also under Settings > iCloud, make sure that iCloud Keychain and Home are enabled.
    3. Go to Settings > Home and enable Use this iPad as a Home Hub.

It’s that simple! But here’s the trick: if you want your Automations to work while you’re out and about, your iPad must stay home! If you take your iPad hub with you, the Automations won’t work, because your hub isn’t connected to your home Wi-Fi network.

Therefore, if you own a fourth-generation Apple TV, it makes a better hub than the iPad, because it’s unlikely that you’ll take it out of the house. However, the trick here is that two-factor authentication must be enabled on your iCloud account. Note that this is different than Apple’s older two-step verification scheme, and if you have that enabled, you’ll have to disable it first to enable two-factor authentication. Apple explains this process in a support article, and I give easy, concise directions in “iOS 10: A Take Control Crash Course.”

Once you’re past that hurdle, using your Apple TV as a HomeKit hub is as simple as making sure that you’re signed in to your primary iCloud account under Settings > Accounts. You also need to have iCloud Keychain enabled on an iOS device or Mac.

Then, under Settings > Accounts > iCloud, you should see a HomeKit header, and under that, you should see Home: Connected. If you don’t, make sure everything is signed in properly.

The other way to check on your hubs is via the iOS Home app. First, if a hub isn’t responding, you’ll see that in the status messages on the Home screen. To see the status of all your hubs, tap the arrow in the upper left. Under Home Hubs, you’ll see your hubs and their statuses.

To test if your hubs will work as you expect while you’re away from home, turn off Wi-Fi on your iPhone temporarily. Then, while you’re connected just via cellular data, try controlling your HomeKit Accessories. If your hubs are working properly, everything should work just as it does when you’re connected to Wi-Fi.

Finally, note that when it comes to HomeKit reliability, the more hubs, the better. I recommend setting up as many as you can, because if one disconnects or flakes out for some reason, you’ll have backups to ensure your Automations keep running. I’ve found HomeKit to be much more reliable since I added a second hub.

Once your hubs are set up, you can control your HomeKit devices from anywhere in the world! That works exactly the same as it does when you control HomeKit devices inside your home. You can also set up Automations because the hub will always be available to invoke them.

Automatic for the Home — The hardest part of setting up HomeKit Automation is getting the hubs in place. Then it comes down to figuring out what you want to do.

Just as with other aspects of home automation, be sure to communicate with your housemates and proceed carefully. If you set up an Automation to turn off the lights when you leave the house, you could leave your spouse and kids in the dark when you run to get ice cream.

It’s easy to go overboard on Automations, so I recommend keeping them simple. My wife wakes up at 5:30 AM, so I have my Good Morning scene set to light up the house for her. I then have my Good Night scene set to trigger at 8:30 AM, because I don’t need the lights by that point. And then at 3:00 PM, Good Morning comes on again, so the house is lit up when she comes home from school.

I’d like to set up an Automation to turn outside lights on and off at appropriate times of day. We like to keep our exterior lights on at night for security reasons, but I often forget to turn them off during the day, which wastes power and reduces bulb lifespan. Our encased porch light could probably hold a Hue bulb safely, but Philips doesn’t make outdoor flood lights like we have on the side of the house, so I’d need to install something like Elgato’s Eve Light Switch to automate those lights.

If you had a HomeKit-compatible thermostat, you could also create an Automation to set the temperature down when you drive away in the morning and back up when you leave work.

That should give you a few ideas for useful Automations. What you want to avoid is making it seem like your house is haunted — lights turning off or on at seemingly random times, spooking everyone in the house.

Setting Up Automations — Once you set up a hub, the Automation screen in Home becomes available. In it, you can see existing Automations and set up four different Automation types: My Location Changes, A Time of Day Occurs, An Accessory Is Controlled, and A Sensor Detects Something. The steps for configuring them are roughly similar.

First, you tap Create New Automation in the Automation tab and then configure the trigger — the conditions that will cause the Automation to be invoked. Then you choose which Accessories and Scenes to turn on or off.

  • My Location Changes: I’m not wild about geofence triggers that go off when you arrive at or leave a specified location. They’re fine if you live alone, but if you share your house with others, they can create all sorts of problems unless everyone has the same schedule. For instance, there’s no way to configure the lights to turn off only if my wife and I both leave the house.However, geofence triggers do have their uses. For instance, you could set up your outdoor lights to turn on when you approach your house. If you had a HomeKit-enabled garage door, you could even have it open automatically as you drive up.To set up a location Automation, tap Create New Automation in the Automation tab and then My Location Changes.At the Location Automation screen, first choose a triggering location. This can be your home, a recently accessed Maps location, or a location you find in a search. Then choose whether to trigger the automation when you arrive at or leave the location. Finally, the map lets you adjust the trigger’s sensitivity. The red pushpin marks the spot, and you can drag the blue dot to adjust the trigger radius around the spot. Tap Next when you’re satisfied.

    Once you’ve defined the location, choose Scenes and Accessories to activate. Tap Next.

    The final screen lets you review your options and offers a few more tweaks. You can set the location trigger to work only after sunset. If you added any Accessories to the Automation, you can choose whether to turn them on or off; you can also press and hold on the Accessory button to make adjustments like brightness and temperature, just as you normally would when controlling it.

    If you’re unhappy with any of the settings, tap Back to go back in the process and change things. If you’re satisfied, tap Done to finish.

  • A Time of Day Occurs: Setting a Time Automation works almost the same way, except at the Time Automation screen you choose the days and times when the trigger should go off. Two time options are sunrise and sunset, which are determined automatically based on where you live.
  • An Accessory Is Controlled: With this option, you can set HomeKit to activate something when you control an Accessory. For instance, if you turn on a light bulb, you could set smart plugs in the room to turn on lamps as well. I haven’t found a use for this option yet, but you might.You start by choosing one Accessory that will trigger the automation. Next, choose whether to trigger the automation when the Accessory turns on or off. Then, choose Accessories and Scenes to activate with the trigger, and proceed as normal.
  • A Sensor Detects Something: In theory, you could set this to trigger actions when say, a smoke alarm or water detector is activated. However, even though I have an Elgato Eve Room sensor, which monitors air quality, temperature, and humidity, this option is grayed out. That’s unfortunate, because it would be great to use these sensors alongside a HomeKit thermostat to balance the temperature in my house better. If you know of a sensor that works with this trigger, let me know!

Editing Automations — Once your Automations are set up, you can view them from the Automations screen in Home. Tap one to see its settings.

It’s important to see how to disable an Automation, which is the first switch on the Automation settings screen. If you have a day off or know that you’ll be too sick to go to work the next day, you probably don’t want your lights coming on at 5:30 in the morning.

You can also change the triggers for the Automation and what Scenes and Accessories will be set by the automation.

Finally, there’s an option to delete the Automation. I seldom do this unless I’m just playing with test Automations that I don’t intend to keep. Instead, disable an unwanted Automation first, and then delete it later if you don’t miss it.

HomeKit home automation is incredibly powerful, and it’s even better when you configure it to be truly automated. But as always, with great power comes great responsibility, so be careful what you set, discuss your Automations with other family members, and keep things simple so they’re easy to manage.

This concludes our coverage of the Home app, but we’re not done with HomeKit. Next time, I’ll tell you about a more powerful HomeKit app that gives you additional control over your devices.