Originally published at: https://tidbits.com/2018/09/10/mojaves-new-security-and-privacy-protections-face-usability-challenges/
macOS 10.14 Mojave brings important security and privacy improvements to the Mac, but both Apple and developers need to work harder to avoid overwhelming users with a cacophony of alerts.
Originally published at: https://tidbits.com/2018/09/10/mojaves-new-security-and-privacy-protections-face-usability-challenges/
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.
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.
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.
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.
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.
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 , I think this is the core of what would help me make an informed decision:
- What I did, or what the system did, that triggered this dialog box.
- What will, or could, happen if I choose to ignore it.
- What will, or could, happen if I choose to accept its recommended action
- 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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
Yes, definitely hold off on upgrading until you can test what goes on carefully in a controlled situation.
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 http://mpainesyd.com/idisk/Public/snap2GC.scpt ).
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)