Skip to content
Thoughtful, detailed coverage of everything Apple for 34 years
and the TidBITS Content Network for Apple professionals
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.

Subscribe today so you don’t miss any TidBITS articles!

Every week you’ll get tech tips, in-depth reviews, and insightful news analysis for discerning Apple users. For over 33 years, we’ve published professional, member-supported tech journalism that makes you smarter.

Registration confirmation will be emailed to you.

This site is protected by reCAPTCHA. The Google Privacy Policy and Terms of Service apply.

Comments About Mojave’s New Security and Privacy Protections Face Usability Challenges

Notable Replies

  1. Thanks for a useful and informative article. I have a slightly different take on the core problem, from the user’s standpoint, for this kind of attempt at security enhancement. Overwhelm and “the boy who cried wolf” complacency are important, but secondary problems. The foundational problem is that the user doesn’t have enough information to confidently make a good decision the first time, the second time, or any of the times when they are asked to allow or prevent an action. Only one of the six dialog boxes in the article, for Mimeo Photos, gives the user a fair shot at informed consent. The others, as is common, ask the user to decide something without sufficient information.

    Permission requests usually fail to be useful in at least one of three areas. 1) Very often, they don’t explain in a meaningful way which entity is asking for permission. Some are like the Xcode example in the article, known to some users, and fuzzy or unknown to most. Many are like the Microsoft Management Console example, which sounds good, but could be a trojan as easily as a valid part of the OS. Searching the name from the dialog box on the Internet may get thousands or millions of hits, but most of those won’t clarify whether the user should allow or forbid the action. 2) Allow or forbid what, exactly? The permission requests seldom give useful detail about the result of approval. As in the article examples, “perform actions with that app”, “read a file" and “access to control ‘System Events’ do not give me a basis for saying yes or no. If I am to be a meaningful gatekeeper, I need meaningful information. Once again, even a diligent Internet search is unlikely to give me enough information to decide whether the action presents an acceptable risk, or useful benefits. 3) If detail about the nature of the potential actions is scarce, information on the consequences of the result is usually non-existent. Few dialog boxes say anything about what will happen if I say yes, and what will happen if I say no. I have little or nothing to go on for judging the risks and benefits of either a positive or a negative choice. This is the hardest aspect to research, since it is usually impossible to compose a meaningful question about the non-delineated results of the proposed action. A user like me can guess that saying “No” is slightly safer than saying “Yes”, but at the same time, saying “No” will cause the failure of many operations that are, in fact, useful to me.

    Rather than “the boy who cried wolf”, I suggest a different metaphor. Most permission-seeking dialog boxes amount to this: “Program XyZZ is about to flip a coin. Do you want Heads or Tails?” About the only thing I have to go on is whether I remember the name “XyZZ". Beyond that, my decision is about as random as guessing the result of a coin flip. Until Apple, or whatever other security system, can give the user enough useful information to make meaningful decisions, these systems will cause frustration without helping security.

  2. I don’t disagree with you, Derek—more information is generally better—but most of these dialogs should appear right after the user has initiated some action. So if you launch SelfieKiller, and it asks for access to your Photos, you should have quite a bit more context, given that you presumably just downloaded SelfieKiller.

    My experience with systems that try to explain what they want is that there’s a fine line between too little information (your heads/tails example) and too much information (overwhelming the user through obfuscation). That’s part of what we’re getting at in this article: the trick is for developers to provide useful text in app that are newly compiled for Mojave and Apple to do a good job with default text for older apps.

  3. Thanks to @mjtsai for this pointer to the apropos xkcd!

  4. This reminds me of the old days when Mac OS 7-9 would throw up error codes for this, that and the other thing. Even if you had a dictionary of the error codes the explanations were aimed at programmers, not users. So they were mostly useless; their only value to users was to frighten them. But thanks for the article explaining all this stuff.

  5. Adam, that is because Apple developers DON’T write for “the rest of us”! They write those “explanation” dialog boxes as if they are talking to a co-developer who understands “geek speak”. It’s the same as if I, as a retired USAF member, was speaking to a civilian about an Air Force issue but I used AF terminology rather than simple English.

  6. That’s not true in general anymore, particularly with consumer-focused macOS and iOS software. Developers know full well that they need to write to the level of their users—the bomb dialog days that @jeff5 refers to above are long gone.

    The problem is that writing clearly and concisely is hard, and writing user interface text is even harder because of the extreme constraints. A dialog can’t contain a page of text, or even a paragraph, and even if it could, users wouldn’t read that much.

  7. I agree with Derek on the principle behind the problem. But I don’t believe it’s a matter of needing more information, but rather better information.

    With all the wisdom achieved in 30 seconds of reflection :slight_smile: , I think this is the core of what would help me make an informed decision:

    1. What I did, or what the system did, that triggered this dialog box.
    2. What will, or could, happen if I choose to ignore it.
    3. What will, or could, happen if I choose to accept its recommended action
    4. What I could do to make my decision a permanent part of the operating system’s security rules.

    So, if I choose to “Show in Finder,” that might trigger a dialog like this:

    In order to show file “xyz ” in Finder, the application you are using, XXX, needs permission first.

    If you choose NOT to grant permission, the application will not be able to control the Finder and show you “xyz”.

    If you choose to grant permission, the application will be allowed to control the Finder and show you “xyz”. Your choice will NOT be remembered.

    If you would like the application XXX to have full permission to control other applications on this Macintosh, click here to add XXX to the list of trusted applications.

    That may be a long dialog, but most users would likely only see it once. I believe it would offer meaningful actionable information without bogging most people down in the weeds.

    PS: I miss the bomb dialog. Not because I liked the circumstances under which I saw it, but because the icon said it all and, damn it, it was witty and whimsical.

  8. I didn’t see Jeff’s response since I started mine then was called away for awhile. True, I remember those days, but I still get alerts that supposedly have a drop-down explanation, but even it doesn’t make sense to a layman.

  9. Even as developer I have struggled in Mojave to get Arq working. I got repeated questions like “Do you want to access Contacts?” Of course, I said no. Only after I got error in the backup I realized what I had to change.

    There will be too many alerts. No user can know what the dialogs entail.

    As for the app notarization: yes, it can be for non-AppStore apps. But it’s only for XCode apps and not for the rest of us. I did a bug report in June but there was no reaction at all from Apple.

    And when the app is notarized I don’t want to see those nanny dialogs AT ALL.

  10. Thank you for this informative article. I really enjoyed it.

    For some very strange reason I enjoy typesetting documents in LaTeX. I can’t say that I am a LaTeX power user, but I like the output.

    As you may be aware, TeX and LaTeX are largely command line scripts that compile documents, but editors such as texstudio allow you to code your document and then compile if from within the editor. All this sort of makes me wonder if or how LaTeX will work with these new security challenges.

    Probably not the right forum to pose this question, but I thought I’d throw it out there anyway.

  11. I like your train of thought, and what I might add is that with some clever programming and design, the dialog could perhaps summarize all that more concisely and let the user who is confused or concerned expand each section to get more information.

    It does feel to me like the real key is to tie the dialog tightly to the action that the user has just performed. It might even be best to say explicitly “You just chose “Show in Finder” in Xcode.” as the first part of the dialog.

    Another thought that comes to mind is that perhaps there’s a role for a chatbot-like interface in situations like this. We’ve become vastly more accustomed to text-based chatting, and actually typing a response would eliminate the reflexive click on a default button without reading.

  12. Interesting. But it makes me want to purchase another computer before Mojave is released and just stash it on a shelf until I need it.

  13. You mean, change the paradigm? Horrors!

    I think that could be a really effective approach, as long as it stays straightforward. One extreme would be the Microsoft Office approach in the 1990s that featured chatbot-like “agents”. “Clippy” is the enduring image from that era, and it made an appearance on late-night TV as recently as last month. Some found it useful, most found its suggestions to be maddeningly irrelevant.

    Of course, we’re talking about a more immediate workflow interruption here, and that leads us back to the balance between necessity and frequency.

    A chatbot could explain its own presence the first couple of times it is invoked, and assure the user that a little effort now means seeing it less in the future. Dialog boxes are too rigid for that kind of flexible communication. They are geared toward discrete responses.

    Also, I’ve never heard of a dialog box that could “phone home” to a help desk, but a chatbot could offer to do that—transparently, of course.

  14. I understand this just well enough to be worried. I currently use Applescripts in FMPro to interact with Interarchy and Safari to up and download files automatically. These scripts are critical to the work I do, and I cannot afford to have them crash during the next four months. It sounds like I should avoid Mojave for at least that long. After that, I will have several months to work on the scripts before I need them again next Fall. Does this seem reasonable, or am I over-reacting?

  15. That sounds reasonable. Are you using the current version of FileMaker? There’s a good chance it will need an update for Mojave and they typically only update the current version.

  16. Sigh… That’s another issue. I’m using v.16 and was hoping to not have to upgrade it. I use this setup to operate a middle school academic league that only functions four months out of the year, and v.16 does everything I need. Actually, the main concern I have is with Interarchy which hasn’t seen an upgrade in a while.

  17. Thank you Rich for your article in this week’s TibBITS. Your article is one of the many reasons I have been a subscriber to TidBITS couple of decades. I just want to add a little background about Apple and their focus on Security for their Operating Systems. Back in the late 1980’s and early 1990’s Apple wanted to break into the Business Market for desktop computers. IBM had captured the market for computers and Microsoft was beginning to dominate the desktop Operating System and Applications Market. Hackers were having a field day with IBM/Microsoft because of their “open standards” for hardware and software. Fortunately, Apple chose to control the both the hardware and software standards for their Mac computers.

    At the time, I was the Information Security Manager for TRW Space & Defense in Redondo Beach, CA. Our charter was to protect company information from the mainframe to the desktop and everywhere in between. The Information Systems Security Association’s Los Angeles Chapter drew members from all industries, including the FBI. Apple sent some representatives to some of our meetings. I remember discussing with them the need for “security by default” for their operating system and applications. By that I mean asking the user for permission open a security control is far better that trying to lock the door after the horse has left the barn. Over the years I have seen Apple change from a proprietary OS to a Unix based OS. Their security improvements over the years, such as “sandboxing”, are the main reason I have stayed with the Apple ecosystem of products.

    I totally agree with Rich that “With great security come great usability challenges”. It has been that way since the early days of Information Security and will continue to be the greatest challenge in the future. So please do your best to engage with Apple so they can make the needed security improvements to their hardware and software products. We will all sleep a little better at night knowing that our data and our privacy are better protected by Apple products than anything else on the market.

  18. Yes, definitely hold off on upgrading until you can test what goes on carefully in a controlled situation.

  19. I “finally” updated to Mojave after testing most of my vital apps on a second Mac. I forgot to check one thing - an Applescript app that I wrote years ago to take a snapshot of a portion of the screen and paste it into a new image file in Graphic Converter. I use it all the time. However… I have just installed Mojave 10.14.1 and the App generates an error like “not authorised to send keystrokes…”.
    I have added the app to the Accessibility list in Security preferences but don’t seem to be able to add it to the Automator list, if that would help (there is no +/- option for the (empty) list).
    I have tried recompiling the app from the Applescript (the Applescript is here ).
    This seems to have something to do with the new security features of Mojave. Any suggestions for a workaround are welcome.

    (Apologies for cross-posting)

  20. Update: I found a fix here:

    I needed to grant access to my compiled app ( in the Accessibility and Full Disk Access options of Security and Privacy preference.

    That worked for my Macbook but the iMac would not allow the change: “There was an error in Security & Privacy preferences”…

    I managed to fix it by copying over a previous version of the app, complied under High Sierra. It seems that compiling Applescript under Mojave exacerbates the bug. I was able to grant Full Disk Access and Accessibility access to the older compiled app and now it works.

Join the discussion in the TidBITS Discourse forum


Avatar for system Avatar for ace Avatar for hartley Avatar for cwilcox Avatar for romad Avatar for scifionea Avatar for jeff5 Avatar for mpainesyd Avatar for Matt_McCaffrey Avatar for rmulliga Avatar for derek Avatar for beatrixwillius Avatar for joeswann