macOS 15 Sequoia’s Excessive Permissions Prompts Will Hurt Security
I rarely write about Apple’s betas because something significant may change between when I publish an article and when Apple updates the beta or releases the production version. I don’t want to waste your time or mine.
But it’s a different story when things should change, as is the case with what feels like one of Apple’s biggest potential missteps currently in the macOS beta—one from which it could still pull back. macOS 15 Sequoia constantly asks for permission to reauthorize apps that rely on screen recording, which is true of many utilities beyond screenshot apps. It’s bad for usability, increases user frustration, and decreases security awareness.
Continue to Allow
A few days after installing the developer beta of macOS 15.1 Sequoia on my M1 MacBook Air, I realized something was very wrong. I rely on CleanShot X for the many screenshots I take while writing TidBITS and TCN articles, and I wasn’t surprised on my first use after upgrading to be asked if I wanted to continue granting CleanShot X permission to capture my screen. After a complete operating system upgrade, I can see Apple’s desire to have us verify previously granted permissions we hadn’t thought about in a while. (For some people, that’s when they discover they’re still running a utility or other app they haven’t used in years.)
However, I was taken aback to receive the same prompt again a short time later. And increasingly irritated when I was asked again after another day or two. And again. And again. Eventually, with my usability hat aflame, I decided to write something about it and tried to capture a screenshot of the dialog. That proved tricky because until I clicked Continue To Allow (and yes, the Apple Style Guide’s rules on capitalization clearly state that it should be “Continue to Allow”), CleanShot X didn’t have permission to capture a screenshot. Triggering a screenshot stacked a second dialog on top of the first, and macOS stopped responding for a few minutes. Eventually, I was able to click Continue To Allow in both dialogs and continue working. The problem was that CleanShot X was capturing all mouse clicks as I tried to select the dialog for the screenshot, so I couldn’t properly click Continue To Allow. The correct way to capture these screenshots was to press Escape to cancel CleanShot X’s screenshot-capturing mode and use Apple’s built-in screenshot tools, which, unsurprisingly, require no permissions. Weirdly, it turns out that clicking Open System Settings has the same effect as Continue To Allow, and System Settings provides no additional information explaining the request.
Before I finished writing this piece, Chance Miller at 9to5Mac published “macOS Sequoia adds weekly permission prompt for screenshot and screen recording apps.” He does a good job covering the situation, noting that this prompt repetition is intentional on Apple’s part, not a bug. The prompts recur weekly, whenever you reboot, or, as I discovered, when you log out and log back in. Although an update to Miller’s article quotes well-known developer Craig Hockenberry as noting that there may be an entitlement developers can request from Apple to sidestep these prompts, the company has shared no information about that. Michael Tsai has also captured the outrage from the Mac development community, and Jason Snell, John Gruber, and Nick Heer have weighed in.
While I mostly encountered these dialogs using a screenshot app, many apps request the Screen & System Audio Recording permission in macOS to identify and position onscreen interface elements or perform other tasks. A few of these include Adobe Photoshop, Adobe Premiere, Bartender, Default Folder X, Display Link, Google Chrome, Ice, Keyboard Maestro, Slack, Splashtop, TextSniper, and Zoom. If Apple continues down this path with Sequoia, there will be a lot of approvals to acknowledge every week or more frequently.
Security Through Endless Warning Dialogs
Many have decried the increase in permissions prompts over the past few years. In “Mojave’s New Security and Privacy Protections Face Usability Challenges” (10 September 2018), security expert Rich Mogull presciently wrote:
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 Boy Who Cried Wolf.”
We’ve already passed the point of security alert overload. The first time or two that the Sequoia beta prompted me to reauthorize, I admit that I didn’t read the text of the alert beyond determining that I should click Continue To Allow to capture the screenshot I needed for whatever I was writing. The dialog came in direct response to the keyboard shortcut I had just pressed, and I have used and trusted CleanShot X for years. It wasn’t until the dialog popped up a few more times that I read it closely to see if I was missing something. I wasn’t.
Apple seems to assume that all third-party apps that monitor the screen (or audio) could be malicious. That may not be a problematic foundation on which to develop a security framework, but it’s patently not the case in the real world. I’d guess that over 99% of apps on all Macs are legitimate for the simple reason that no one intends to install a malicious app or run it regularly.
There have been isolated examples of updates to legitimate apps being compromised (Transmission and Handbrake), but those were in 2016 and 2017—it’s just not an everyday concern for users. We also recently saw the kerfuffle with Bartender, which had long required screen recording permissions, being sold to a new owner without notifying users (see “Bartender Developer Explains and Apologizes for Quiet Acquisition,” 5 June 2024). In none of these cases would extra prompts have made any difference because users had no way of knowing that anything had changed.
By prompting for continued permission, Apple is asking if we still trust previously trusted apps. What would change in any short period of time that would have us reconsider this action? We would need new information to make a different choice. I could see an argument for double-checking permissions a few days after the first launch to ensure the user knows the app is still active, but repeated checks? After every restart?
It made sense when Apple added location permission alerts in iOS that appear occasionally after weeks or months of background location access. The alert shows how many times you’ve been tracked, shows a map with locations your device has provided, and lets you take a sensible action. The dialog lets you switch location permissions to “only while using.” Perhaps you had forgotten you gave an app permission during a trip and didn’t realize it continued tracking you at home. Maybe you don’t remember installing and giving that app permission at all. Whatever the case, the process makes sense—and it pops up only rarely.
Adding protections against virtually non-existent threats and providing warnings without a sensible action that can be taken actively harms the Mac experience. More than one writer has brought up the specter of Windows Vista, which became known for excessive security dialogs and prompted mockery from Apple. Like most Mac users, I never used Windows Vista when it shipped in 2007, so these second-hand comparisons felt fuzzy until I dug up this 2006 piece from Stack Overflow and Discourse co-founder Jeff Atwood. He warned that “security through endless warning dialogs” doesn’t work for exactly the reason that has proved to be true:
All those earnest warning dialogs eventually blend together into a giant “click here to get work done” button that nobody bothers to read anymore. The operating system cries wolf so much that when a real wolf—in the form of a virus or malware—rolls around, you’ll mindlessly allow it access to whatever it wants, just out of habit.
It’s depressing to see Apple recapitulating Microsoft’s mistakes from over 15 years ago.
Apple’s Actual Motivation?
I’m left wondering why Apple is adding these additional permissions prompts. The cheap answer is that Apple’s security team believes that apps regularly go over to the dark side within a week and we will figure that out by getting a prompt to remind us that we have already granted it screen-recording permissions. But that’s patently stupid. If the user trusts an app on Monday and nothing changes with that app by the following Monday, there’s no reason to doubt the previous trust level. If there were, Apple should use its anti-malware systems to block the app from running at all, right? More likely, Apple believes people intentionally install an app that is actually malware, give permissions when prompted, and would only reconsider if prompted repeatedly. That still feels excessive.
Perhaps the change was prompted by the success of how Apple quietly ratcheted up the passcode requirements for Touch ID and Face ID a while back. In addition to other cases in which you had to enter a passcode for an iPhone or iPad (or a password for a Mac), such as after restarting, Apple added a 6.5-day countdown clock that starts every time you enter your passcode. After that period elapses, a second 4-hour timer starts: if you don’t unlock your device with Touch ID or Face ID within that period, you are prompted to enter your passcode the next time you use it. Although it’s a slight annoyance for users to enter their passcodes at least once per week, it’s an overall security win because the routine reinforcement helps ensure that people don’t forget their passcodes.
However, with permissions prompts, routine reinforcement is unnecessary and excessive, and it desensitizes us to essential security warnings. Plus, computers should save us from repetitive work, not give us more unnecessary buttons to press.
We can hope that the public outcry will cause Apple to rethink this problematic path, but additional direct user complaints will also help. If you’re using the public beta of Sequoia, use Feedback Assistant to file a bug against these dialogs. Those who aren’t testing the beta can try using Apple’s Feedback page, perhaps for the Mac you plan to upgrade.
I look forward to Maps, when I start a route to somewhere Apple considers unsafe, asking me to confirm that I really want to go there, and not letting me do anything on my iPhone until I’ve answered. And doing the same thing every time I want to go there subsequently.
Regarding the screen recording security prompt, I’m glad that people with a lot of visibility like Jason Snell are raising the issue now, but I’ll get more concerned about it when Sequioa actually ships rather than getting worked-up over a beta.
I believe I read somewhere that Apple has an API for screen recording and that these prompts affect apps using older methods to screen-grab. But that may also have been wrong.
I kind of understand why Apple is doing this, especially after Microsoft’s Recall debacle. It is a potential security issue for anyone to be grabbing screenshots at any time without us being aware. As mentioned in this thread, frequent security prompting can make a bad habit to always hit allow. But only asking once and never again seems also not to be the right answer.
I get the prompts every time after the machine wakes up from sleep. It is very annoying, to say the least.
It might be worthwhile for everyone that is impacted by this to provide feedback to Apple indicating that this “feature” severely impacts productivity and usability of macOS and needs to be re-evaluated. (It’s been done in the past).
Providing examples of applications that would generate these prompts and keeping the feedback fact-based – eschewing the outrage – might get Apple’s attention if enough of us do this. I, for example, use VMware Fusion which needs screen recording privileges - and it would be an extreme annoyance to re-authorize the function on any regular basis.
Perhaps the ability to permanently white-list applications, or provide application-by-application control would be preferable than this blanket “authorize everything after 1 week”.
Constantly treating users like idiots, destroying their productivity, ultimately does not lead to better security. It leads the user to NOT trust (in fact, to hate) the very entity who is trying to protect them. It’s an ignorant case of the boy who cried wolf.
I agree! Overuse of security, including forcing password reentry and alternate authentications, causes decreased security overall.
I installed Sequoia 15.1, Beta 2 this afternoon. Apple changed the “Open System Settings” button to read “Allow for One Week” instead. It’s a lot less annoyance.
I’m all for security, but there needs to be more trust left to the user.
My wife works for a large company that uses Okta for authentication and identity verification. It’s so NOT user-friendly. I can’t tell you how many times over the past few years that she’s been locked out of her work Mac because of permission and login issues caused by Okta security requirements (password changes, session timeouts, multiple levels of login, etc).
Apple, don’t be Okta. Give your users a little more credit.
Oh dear - I read this with a heavy heart. I am already growing weary of Apple ID security issues with Sonoma where I have had to reset my Apple ID 4 or 5 times in the last few weeks for no apparent reason (and each time to regenerate app-specific password). I have already made my Apple ID password much less secure in order to make the process marginally less painful. I agree - measures like these have the effect of reducing rather than increasing security.
Don’t forgot the downstream effects - early in the pandemic, we all sat through meetings where someone went to share their screen but couldn’t had to figure out that they had denied the permissions, search for the setting to change it - and quit Zoom (or whatever) then rejoin the meeting for the change to take effect.
Given a choice, some people will make the wrong one. And when they do, they’ll go to share their screen, but can’t… and now this has the potential to happen after every reboot, and after every log out? In many workplaces, mandatory logout is required for security, so this can become an everyday occurrence.
Even people who don’t use a Mac will suffer from it.
Aha! The next beta changes the wait period to a month.
In the macOS 15.1 beta, which is what I’m running, Apple changed the text from Continue to Allow to Allow for One Week and made it the default button.
It sounds like the macOS 15 beta is slightly ahead in upping the time to a month. That’s 4 times less annoying than weekly but still 12 times more annoying per year than it should be.
What would be reasonable, from your perspective?
In thinking about it more, I’m going to stick with what I said in the article, which is the first launch plus another sanity check several days later. It is entirely reasonable to prompt on the first launch because that’s when the user is most aware of what’s happening. But if we assume that the user could have been fooled into installing malware, it’s worth asking again fairly soon so they’ve had a chance to use the app a little and decide what they think. It wouldn’t be entirely unreasonable to ask after an app is updated, but I think that would get annoying for some apps and might dissuade some developers from releasing quick bug fixes.
Repeated permissions prompting without good reason is like requiring people to change their passwords repeatedly—something that sounds good but actively hurts security. (And that’s just an analogy, not an invitation to change the topic to scheduled password changes.)
The latest episode of Accidental Tech Podcasts reports someone who wrote in reporting the potential scenario of personal abusive behavior - so, for example, a former abusive spouse or partner who has installed some sort of screen recording application, as well as perhaps a keylogger, audio recorder, video recorder, etc., to continue monitoring the person who was abused. (I know someone this happened to, though not in this way - it wasn’t anything like a key logger or screen recorder, but someone who made sure that she had Apple ID access before the relationship was severed, access to the automobile’s account online to keep track of the location of the car, among some other things.) We know that video and (I think) audio show an indication (with hardware or software light indicators). Somebody in that situation may welcome these repeated prompts, if only to make them aware that perhaps they are being spied on.
Perhaps there is a way for users to be able to say that I don’t need that level of scrutiny, but, again, this is part of a beta process, so maybe Apple is already thinking of this.
There was an excellent discussion of this on this week’s Upgrade (#524) and Jason specifically talks about why an alert some days after first run is important for abusive situations. Highly recommended listen. It’s the fifth chapter at 40m38s.
Seems reasonable to me!
I think the indicators are a nice, subtle way to show that something is happening that you might want to pay attention to without interrupting what you’re doing, but the personal safety benefit feels overblown.
If we accept the hypothetical that a former abusive spouse can install monitoring software that evades the audio/video indicators and acknowledge the initial first launch permissions prompt, we’re assuming that they have full administrator access to the physical Mac, at which point all bets are off.
I’d argue that my suggestion of a several-day-later prompt (on a random schedule, so the miscreant can’t know when it will reappear) is a far better and more effective way of addressing this scenario than a monthly prompt.
I wonder if this issue will affect software like EyeTV4 that records OTA tv channels? It would appear that it would but not sure.
I’ve been thinking about this myself. I’d like to see a “privacy review” panel in System Settings that pulls all this stuff together in one place, and instead of individual apps nagging you, have a single notification that reads “Take a few minutes to review your privacy settings.”
Yes, that would be nice, however IIRC an objection to this is that these requests are modal and synchronous: the app can’t continue unless you make your decision one way or the other. So the UX wouldn’t be terrific, even if the permission were simply denied by default, at the very least you’d need to restart affected apps, for instance. I’m not sure how Apple changes this without changing the APIs for requesting access, so even more adjustment and dev frustration.
Yeah, I take your point. You’re right. It wouldn’t work for the first launch, but an omnibus view would work for follow-up reconfirmations.
I work with users requiring a range of Accessibility issues.
The lack of as much as a glossary extends the DYSUTILITY of the whole process.
Being asked for an access/identity constantly, often ending in a lock out and or reset of a password, with poor transparent and even identifiable connection to a location and definition of what has been addressed or changed, is common.
It results in a risk of literal EXCOMMUNICATION, a risk that correlates with the current level of computer literacy, an Accessibility issue.
Add this to the feature creep that adds complexity that benefits only a small percentage of users.
This is a problem across all software, understandably, but add in the wanton marketing to “make it feel fresh” that seems to be an added layer and one ADDS unfamiliarity that make identification of changes representing security issues approach the impossible for even very computer literate users.
When one excommunicates, locks out, users, feedback is reified, absent from those whom it fails.
In the past I worked trying to connect older users.
Now I work trying to disconnect them from threatening complexity, confusion and increasing risk.
The process seems to be trying to expand universal use by exclusion rather than inclusion, merely changing the definition of who is included.
Could an app could receive some form of a security certification from Apple, where requested accesses were noted and catalogued. The OS could validate that certificate, ask the user once and that’s a form of double check. Let Apple’s team do the work in checking through what these apps actually do, rather than users getting increasingly numb or frustrated depending.
If an app doesn’t have such a certification then maybe once a month…
I think that’s the idea behind the Persistent Content Capture entitlement, which Apple hasn’t said will work for this or not yet.
Just my 0,02 € here:
I often use my Mac 14–16 hours daily, and have been doing so for several decades.
I was TERRIBLY annoyed when the public beta began nagging me about these permission prompts, spent hours on the net — and was glad to see that I was not the only one
Then it switched from
<perceived>daily or every two days to weekly, still horrible.And when I read now that it’s probably going to be once per month, I find that … oh well, I can live with that. I have perhaps a dozen apps in that section of the security prefs, and some I actually use many times daily are …
Maybe it’s just the effect of a little pain feeling almost like a relief after having hurt a LOT before …
BUT …
I really think that being asked once per month would be totally acceptable for me, for the overall benefit of feeling a little more secure — like, perhaps, reminding me to check whether Default Folder is still owned by Jon Gotow or something …?
Having thought about this a little more, here’s another possibility: launch apps in a “permission denied” mode, but accumulate a queue of apps requiring permissions. After the queue stabilizes (no new additions for N minutes), pop up a “review your privacy permissions” reminder and show a Privacy Review panel.