Apple Reduces Excessive Sequoia Permission Requests, Shifts to Monthly
In the latest macOS 15.0 Sequoia beta, Apple has backed off somewhat from the previous release’s radical increase in the frequency with which you would be prompted to approve permission requests from apps that need screen recording access (see “macOS 15 Sequoia’s Excessive Permissions Prompts Will Hurt Security,” 12 August 2024). At 9to5Mac, Chance Miller reports that the latest beta of macOS 15.0 (but not of macOS 15.1, which I’m running) has relaxed the policy. However, the repetitive permissions prompts, which seemingly stem from misguided thinking about how people evaluate digital risks, remain unnecessary.
In the previous macOS 15.0 beta, Sequoia would prompt users to continue allowing screen recording permissions every week for each app, as well as prompting after every restart or logout. Remember that many different kinds of apps request screen recording permissions for entirely legitimate reasons other than directly recording onscreen pixels to an image or movie file. Such apps include Adobe Photoshop, Adobe Premiere, Bartender, Default Folder X, Display Link, Google Chrome, Ice, Keyboard Maestro, Slack, Splashtop, TextSniper, and Zoom.
As of the latest macOS 15.0 beta, Sequoia triggers these additional permission prompts monthly, rather than weekly, and has dropped the additional prompts after restarting or logging out. Miller says the prompt text is now more specific:
[App name] is requesting to bypass the system private window picker and directly access your screen and audio. This will allow [App name] to record your screen and system audio, including personal or sensitive information that may be visible or audible.
Reducing the frequency of these repeated permissions prompts is a step in the right direction, but the overall change is still a mistake. A monthly schedule is less annoying than weekly prompts, but it’s more irritating than what we’re currently accustomed to, with no indication from Apple of why the purported additional security is necessary. There are instances of malware surreptitiously recording the screens of infected Macs, but most predate macOS asking the user to grant screen recording permissions, like FruitFly (2003–2017) and Mokes (2016). In 2021, XCSSET used a zero-day security exploit to bypass the permissions prompt entirely by injecting itself into legitimate apps with such permissions. Repeated prompts wouldn’t have helped in such a situation.
Also, while specificity in interface language has its place, even I don’t know what “requesting to bypass the system window picker” means, so I can’t imagine that a user less involved in the technical details of macOS would have any clue. Allowing obscure technical language to creep into a user interface is problematic on its own; putting it in a dialog meant to inform ordinary users about a potential security concern exacerbates the feelings of ignorance many people already have. Nobody who would have approved usage the first time would find themselves denying it on a subsequent occasion because of this new language. It’s far more likely that people will tune out the dialog gobbledygook and reduce their overall system vigilance.
Many hope the Persistent Content Capture entitlement, which developer Craig Hockenberry pointed out last week, could provide an exemption for approved apps. However, Apple describes it as “a Boolean value that indicates whether a Virtual Network Computing (VNC) app needs persistent access to screen capture” and has said nothing about whether it would be available to apps requesting screen recording permissions for other reasons.
Barring that, I’m sticking with my recommendation from the previous article: present the user with a “Continue to Allow” prompt several days after initially granting an app screen recording permissions. That would cause the user to think about the permissions while the app installation was still fresh and allow them to rescind permissions or remove the app if it was only for short-term use. In the hypothetical scenario where a malicious recording app is being installed by someone with admin access to the Mac, such as a domestic abuser, a randomly scheduled second prompt would be harder to conceal.
The negative reaction from developers, beta testers, and the media has already caused Apple to pull back somewhat on this feature. However, we shouldn’t see it as a compromise worth accepting in its current state because we don’t know why Apple made the poor choice in the first place. I continue to encourage you to tell Apple what you think. If you’re using the public beta of Sequoia, use Feedback Assistant to file another 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.
Think about Safari. When you use it to share a window on Google Meet, say, you get the system-level “select the screen element you want to share” picker. That picker is a macOS feature. The user interacts with the user to pick a window, and macOS gives Safari a video stream of that window. Safari doesn’t get access to a list of available windows, and therefore doesn’t need screen sharing permissions, as the user explicitly picks a window to share each time.
Compare this to Chrome, where the “pick a window to share” UI is built by Chrome. It needs to get access to all windows, so it needs screen sharing permissions ahead of time. It then calls the system API to get the list of windows, etc.
If you don’t use the system provided “pick a window” API, you get that warning alert. Technically speaking, that’s the SCKContentSharingPicker. See WWDC 2023 session 10136.
Aha—thanks, Avi! That makes perfect sense, but I still can’t see most ordinary users understanding it. Many of the people I do video calls with can’t reliably share screens in Zoom, much less identify an interface element as the system window picker.
I received a reply from Apple about this. Apparently this is an older API and there’s a newer one that developers are supposed to switch to: “As mentioned in Developer and AppleSeed for IT release notes, applications utilizing deprecated APIs for content capture such as CGDisplayStream & CGWindowListCreateImage can trigger system alerts indicating they may be able to collect detailed information about the user. Developers need to migrate to both ScreenCaptureKit and SCContentSharingPicker to prevent these alerts.”
Interesting! @peternlewis @gotow, is this something you’ve looked into?
I just talked with a screenshot utility developer, who said the new APIs aren’t appropriate for their app.
@tomdar2 The reply you received from Apple is wrong. I built a test app using only ScreenCaptureKit (no old APIs) and it still resulted in warnings in Sequoia.
Using SCContentSharingPicker may eliminate Sequoia’s reminders, but that API isn’t appropriate for my use-case - it’s only useful for picking the screen area or window you want to capture. My app programmatically captures an image of a specific, known window, so interactive picking isn’t necessary or desirable. And as Adam already pointed out, developers of screenshot apps want to bypass the SCContentSharingPicker to make a more complete, feature-rich and reliable screenshot user interface. SCContentSharingPicker is fairly bare-bones, making it generally useless to developers.
As Jon said - Apple will bypass the alert if you use their screen picker (maybe), but that is not a practical solution for an application that wants to allow the user to control the area they pick via other means. Keyboard Maestro lets you pick the area as being 100 pixels inset from the front window’s borders, let’s see the Apple screen picker do that… And that’s just a trivial case.
I’ve spoken with another screenshot app developer who did the same thing and came to the same conclusion.
I can confirm this. I’m the developer of a screenshot app and also wanted to see if the claims are true that, if only modern ScreenCaptureKit APIs are used, no permission dialogs (or less thereof) would appear - but it is not the case (macOS Sequoia 15.0 beta 7).
Unless you use the actual ScreenCaptureKit window picker, which is not the best experience for screenshooting apps (your mileage may vary), there is no way around those permission requests and reminders.
I actually implemented a “Standby window capture” mode into my app, made possible by ScreenCaptureKit, where my app will appear as a capture option in any window’s green zoom button hover menu, but I’m not entirely sure it’ll catch on. It’s just not made for this stuff.
– Matthias
Nick Heer discusses more of what might be going on and suggests that Apple’s terrible wording in the current version of the dialog might imply that the initial versions of macOS 15 Sequoia won’t ship with this limitation. Fingers crossed that he’s right, or that Apple rethinks what it’s doing.