{"id":44412,"date":"2024-08-08T15:23:59","date_gmt":"2024-08-08T19:23:59","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=44412"},"modified":"2024-10-08T16:13:31","modified_gmt":"2024-10-08T20:13:31","slug":"sequoia-screen-recording-prompts-and-the-persistent-content-capture-entitlement","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2024\/08\/08\/sequoia-screen-recording-prompts-and-the-persistent-content-capture-entitlement\/","title":{"rendered":"Sequoia Screen Recording Prompts and the Persistent Content Capture Entitlement"},"content":{"rendered":"

Matthias Gansrigler<\/a> (Mastodon<\/a>):<\/p>\n

As a macOS engineer, what do you do when you’re told by Apple’s security team you have to turn it even more<\/em> into Windows Vista and place even more<\/em> useless alibi-security permission dialogs somewhere, but you’ve run out of new places to put them in?<\/p>

Well, you get creative, and show multiple<\/em> permission dialogs for the same permission<\/em>.<\/p>

Can’t innovate anymore, my ass<\/strong>!<\/p><\/blockquote>\n\n

Chance Miller<\/a> (Mastodon<\/a>):<\/p>\n

\n

With macOS Sequoia this fall, using apps that need access to screen recording permissions will become a little bit more tedious. Apple is rolling out a change that will require you to give explicit permission on a weekly basis to these types of apps, and every time you reboot your Mac.<\/p>\n

[…]<\/p>\n

While many speculated this could be a bug, that’s not the case.<\/p>\n<\/blockquote>\n\n

William Gallagher<\/a>:<\/p>\n

\n

There are accessibility apps that use screen recording, for instance. Keyboard Maestro can use it to look for specific buttons being shown on a screen, and even the Bartender app uses it as part of controlling menubar apps.<\/p>\n

[…]<\/p>

In each case, before the recording can be started, a prompt appears saying that a specified app “can access this computer’s screen and audio.” Curiously, it does not as yet offer the option to say that you don’t want this.<\/p>

[…]<\/p>

There does appear to be a bug in that sometimes there is a significant delay before the Continue to Allow<\/strong> button responds to clicks. It’s also inconsistent in how sometimes clicking that does allow the screen recording, but the screen recording shows that prompt.<\/p>\n<\/blockquote>\n\n

Craig Hockenberry<\/a>:<\/p>\n

\n

I’ve always been proud that xScope is a tool that sits quietly in the background, ready when you need it.<\/p>\n

So much for the “quietly” part…<\/p>\n<\/blockquote>\n\n

Riley Testut<\/a>:<\/p>\n

\n

As someone who reboots my iMac every morning, looking forward to daily permission alerts 🙃<\/p>\n<\/blockquote>\n\n

Miguel Arroz<\/a>:<\/p>\n

\n

I’ve caught suspicious things thanks to macOS security warnings like games wanting global keystrokes (nothing evil going on, just shitty open source multi-platform libs).<\/p>\n

But this seems excessive. Why not asking if I want the app to have this ability during the next 24 hours, or forever? Either it’s a one off, or if it’s not, I don’t want to have to answer every week.<\/p>\n<\/blockquote>\n\n

Jon Gotow<\/a>:<\/p>\n

\n

And if an app isn’t using Sequoia’s new “screen recording picker”, you’ll see this very technically worded warning. I’m not sure how your average Mac user will respond to this.<\/p>\n

[…]<\/p>\n

Of course, the reason I’m grousing about this is because Default Folder X is affected. In some situations, DFX captures an image of an Open or Save dialog and displays it on top the real file dialog as a “curtain” to hide what its doing while it manipulates the dialog. It doesn’t store or transmit the images – it just takes a screenshot of the file dialog, pops it up on the screen to obscure the dialog while it twiddles a menu, then throws away the screenshot.<\/p>\n

Now Sequoia is throwing up scary weekly reminders about it recording “personal or sensitive information”. Sigh. Assuming that this new Sequoia “feature” is here to stay, I feel the only workable solution is to remove the screen captured façade and just put up a blank window to hide what Default Folder X is doing. This is … ugly.<\/p>\n<\/blockquote>\n\n

Kyle Howells<\/a>:<\/p>\n

The privacy teams in Apple have way too much power.<\/p>

Someone high up enough in Apple needs to start telling them NO.<\/p>

My number 1 feature request for iOS and macOS is a big switch to turn ALL these “are you sure you want X to still have permission to do Y” off forever!<\/p>

Every time one of those puts up it both: interrupts me; and presents an opportunity to break things!<\/p><\/blockquote>\n\n

Erik Schwiebert<\/a>:<\/p>\n

\n

Yes, really, this Mac is under our full control (in fact, it gets paved and re-built multiple times a day) in a secure lab. WTH is it prompting for permissions all the time? There isn't even a TCC entry to suppress the alerts when you are full admin. Sigh.<\/p>\n<\/blockquote>\n\n

Tuomas Hämäläinen<\/a>:<\/p>\n

\n

I share my screen on Teams all the time, and I think drawing\/design apps that want to sample colours outside of their windows with the eyedropper tool also need to use this API, so looks like I’m gonna be seeing this a lot… <\/p>\n

Apple have made Mac OS into exactly the thing they made fun of Windows Vista for. After some time, no one is going to be reading these dialogues anyway, people will blindly click on “allow”, effectively working against the intent of better security.<\/p>\n<\/blockquote>\n\n

Luc Vandal<\/a>:<\/p>\n

macOS: Gradually making your Mac more annoying each year because “security”.<\/p><\/blockquote>\n\n

Jason Snell<\/a>:<\/p>\n

\n

It’s part of a general trend for Apple to continue placing barriers in the way of users who are trying to use software on the Mac.<\/p>\n

[…]<\/p>\n

For the past decade, Apple has been trying to tighten the screws on the Mac in order to bring it closer to the level of security offered on iOS. And on iOS, it’s also restricted software features, including a (supremely annoying) feature that repeatedly asks you if you want to continue allowing apps to track your location.<\/p>\n

[…]<\/p>\n

But what Apple’s testing in the latest macOS Sequoia betas is brutal because there’s no end to it. It’s a subscription you didn’t buy and can’t cancel.<\/p>\n

[…]<\/p>\n

Asking for permission a second time is not unreasonable for the reasons I mentioned above. But at some point the user must be in charge<\/em>. […] Some users will make bad decisions. That’s just reality. The wrong reaction is to take the decision out of every<\/em> user’s hands to protect the ones who might do something stupid.<\/p>\n

[…]<\/p>\n

Apple’s recent feature changes suggest a value system that’s wildly out of balance, preferring to warn (and control) users no matter how damaging it is to the overall user experience.<\/p>\n<\/blockquote>\n\n

Steve Streza<\/a>:<\/p>\n

\n

The Vista-ification of macOS is so incredibly sad to watch. It is going to grow harder and harder to convince people not to shut off security features because of how annoying they're getting. Apple is becoming the thing they mocked (and sold a lot of Macs on the back of mocking).<\/p>\n<\/blockquote>\n\n

Sami Samhuri<\/a>:<\/p>\n

\n

Can the macOS team please stop? This is worse than UAC.<\/p>\n<\/blockquote>\n\n

Matthew Cassinelli<\/a>:<\/p>\n

\n

Worst decision Apple has made in years.<\/p>\n<\/blockquote>\n\n

John Brayton<\/a>:<\/p>\n

\n

The excessive permission checking is probably the most frustrating aspect of using a Mac.<\/p>\n<\/blockquote>\n\n

Martin Pilkington<\/a>:<\/p>\n

\n

After winning an Oscar and an Emmy, Apple is moving onto the next step in getting an EGOT by going for the Tony Award in Security Theatre 🙄<\/p>\n<\/blockquote>\n\n

Mike Rockwell<\/a>:<\/p>\n

\n

I’ve been toying with Linux again<\/a> on my 11-inch MacBook Air and I absolutely love how much control you have over the system. Maybe DHH is onto something<\/a> with his switch away from macOS.<\/p>\n<\/blockquote>\n\n

Jason Snell<\/a>:<\/p>\n

And you know what they’ll say if Apple just declares this a “beta bug” and addresses it before launch: “What were you guys all complaining about?”<\/p>

But we know that if we don’t complain, this all just slides through and we’re stuck with it.<\/p><\/blockquote>\n\n

Nick Heer<\/a>:<\/p>\n

\n

But relentless user confirmation is not a good answer for privacy, security, or competition<\/a>. It merely kicks the can down the road, and suggests users cannot be trusted, yet must bear all the responsibility for their choices.<\/p>\n<\/blockquote>\n\n

Matthias Gansrigler<\/a> (Mastodon<\/a>):<\/p>\n

In macOS, when you want to, for example, create a screenshot app and want it to be able to actually take screenshots, you’ll have to get permission from the user for it. With the upcoming macOS 15 Sequoia, that is going to be upped to two dialogs. One: the initial permission request, and two: a weekly reminder, asking if you want to continue to allow this app to capture your screen.<\/p>

[…]<\/p>

I feel like apps on the Mac App Store should get some perks for being reviewed and vetted by Apple’s App Review.<\/p>

[…]<\/p>

A developer of a screenshot<\/em> app that has successfully gone through App Review to be published on the Mac App Store should be able to request a default screen capture entitlement for it, which lets macOS know that no permission dialogs need to be presented, or asked for weekly, at all. It can just take screenshots right after download, because, you know, it’s a screenshot app, and that’s what the user downloaded it for.<\/p><\/blockquote>\n

And similarly for core permissions for other app types.<\/p>\n\n

Guy English<\/a>:<\/p>\n

\n

If adopting new APIs is what developers need to do in order to avoid these user hostile dialogs is what is needed then Apple should provide sample code showing how to move from the old to the new. If the App is on the Mac AppStore they could and should reach out to apps with that entitlement and point the developers in the right direction. For extra points allot Apple dev rel folks to do the conversion for them if needed.\nThis helps the user<\/em>.<\/p>\n<\/blockquote>\n\n

Daniel Jalkut<\/a>:<\/p>\n

\n

I think the problem is there is no new API to avoid the hostile dialogs. They occur with the newest APIs.<\/p>\n<\/blockquote>\n\n

Craig Hockenberry<\/a>:<\/p>\n

You’d think that Apple would have figured out that letting developers know about Security changes ahead of time would be a good idea.<\/p><\/blockquote>\n\n

Craig Hockenberry<\/a>:<\/p>\n

\n

A friend pointed me to this [Persistent Content Capture entitlement<\/a>] the other day and it feels like a solution to the (justified) uproar over the screen sharing nag.<\/p>\n

The issue here is that Apple has provided no documentation or any other guidance on how to get this entitlement and prevent an app from becoming nagware.<\/p>\n<\/blockquote>\n\n

Isaiah Carew<\/a>:<\/p>\n

\n

we’ve clearly hit an inflection point. the kickback from the macOS screen recording warning has been huge.<\/p>\n

for years apple has slowly improved security, but at extreme detriment to usability, functionality, and developer pain.<\/p>\n

i think this either means apple listens and changes course here right now or the groundswell will continue and accelerate.<\/p>\n

i have trouble being optimistic in these cases, but they did eventually listen about the shitty keyboard. so hope is not entirely lost.<\/p>\n<\/blockquote>\n\n

Jason Snell<\/a>:<\/p>\n

Here’s the thing. Apple should<\/em> be making it harder for apps to do stuff without users understanding what they’re approving. But with great power comes responsibility. If you’re going to make these changes, you have to make the effort to mitigate the UX disaster. If you introduce new, better APIs, you need to evangelize them to developers and document them properly.<\/p>

Too often for the last few years Apple does step one and then fails to do steps two and three. Step one is not the sin.<\/p><\/blockquote>\n\n

John Gruber<\/a> (Mastodon<\/a>, 2<\/a>):<\/p>\n

I think it shows just how much care and thoughtfulness went into turning up the dial on these nags that the button label incorrectly capitalizes the “to”<\/a> in “Continue To Allow”. You can say, well, that’s a little thing. But that’s exactly the sort of little thing that almost never shipped from Apple, even in beta, until the last few years.<\/p>

Having to click through these confirmation nags every week, for every such utility you use, is not a little thing at all. It’s the sort of thing companies do when decisions like this are made by people looking to cover their asses, not make insanely great products.<\/p><\/blockquote>\n\n

Craig Hockenberry<\/a>:<\/p>\n

The biggest win for the user experience would be to reorganize System Settings around the apps, and not the categories.<\/p>

I want to see all the things that Google Chrome can access, not dig into Extensions, Privacy, Location, et. al. (and don’t get me started on search capabilities).<\/p>

Harder than it is on iOS because there are more things to allow\/deny, but it’s the way folks expect it to be.<\/p>

Anything short of that is just a bandaid.<\/p><\/blockquote>\n\n

Jeff Johnson<\/a>:<\/p>\n

\n

That info should be in the Finder Get Info window and\/or preview pane. Also when you press and hold an app icon on the iOS home screen.<\/p>\n<\/blockquote>\n\n

Juli Clover<\/a>:<\/p>\n

Apple’s User Privacy Engineering Manager Katie Skinner and Privacy Product Marketing Lead Sandy Parakilas recently sat down with YouTuber Andru Edwards for a wide-ranging discussion on Apple’s privacy policies.<\/p><\/blockquote>\n\n

Previously:<\/p>\n