Pasteboard Privacy Preview in macOS 15.4

I understand that reading the clipboard is a potential privacy leak, but for me the iOS notifications are the native app equivalent of cookie notices. Annoying friction that snaps me out of what I'm trying to do.

Here's a thought: allow us to decide which apps trigger this notification. Make it opt in, or at the very least opt out.

That's the sort of thing Apple would do if they were thoughtfully designing their OS, and were operating under the assumption that a computer is owned by you, and you should make decisions about how it works. Neither is true; they are evidently thoughtless, and as far as they're concerned, *they* own your computer, even though you paid money to purchase it from them.

Is this saying that an app can decide that regardless of the users wishes a clipboard cannot be read programatically?

That's not privacy, that allowing an application to dictate what a user can do on their own Mac!

This is a sensible idea that I don't trust Apple to implement with the proper nuance.

On one hand, I like the idea that the pasteboard is not "free for all", but on the other, so many cool things my Mac – and iOS cannot – come from that access:

1. I use Alfred's clipboard manager a couple dozen times a day;

2. A Keyboard Maestro macro (hi Peter!) monitors my pasteboard for Youtube links I copied and adds them to Unwatched automatically;

3. Different key combinations allow me to paste the content after some processing (i.e. copy a certain string, process it through a regex again in KM, paste only a section properly adapted).

4. I can see the current content of the pasteboard in the menubar thanks to an app I wrote a few years ago and that I imagine will now die.

5. Certainly many more things I'm not thinking about right now...

Take those thing away – or put them behind continuous Vista prompts – and you'll have magically dumbed down macOS to iPadOS level.

On a side, I *love* that while podcasts wish for clipboard managers on iPadOS, Apple makes things harder on the Mac. Because Users are not to be trusted, right?

The right way to make this would be to have a clear way to tell macOS "I trust this app" and actually make the operating system NOT bother you again.

Good Feedback submitted to Apple by Sindre Sorhus: [FB17587626: NSPasteboard needs a way to programmatically request full access to the pasteboard](https://github.com/feedback-assistant/reports/issues/655)

There is a new section in the "Privacy & Security" prefs called "Paste from Other Apps".

Once an app triggers the permission request for the first time, it appears in this list. Option can then be set to "Ask", "Allow", "Deny". The Allow setting allows full access as per the current status quo.

This pane can be opened using URL: "x-apple.systempreferences:com.apple.preference.security?Privacy_Pasteboard".

The preference can be reset using "tccutil reset Pasteboard "

@Peter What are you referring to? I’m not seeing anywhere where it says that the copying app is given a veto. accessBehavior is read-only.

@Cesare Yes, it would be good to be able to prompt the user for all access instead of making them go into System Settings. However, this does seem to be an improvement over some other privacy settings (like Full Disk Access) in that the app can at least see the current setting.

@Anonymous Thanks!

I think apps should be able to specify whether they may put sensitive data into the clipboard or whether it'll all be safe. Finder or my Find Any File, for instance, only put file paths into the clipboard. I can't see any security issue with that, and I don't think macOS needs to ask users if they want to paste such information into other apps.

OTOH, password managers should be assumed to handle sensitive information. There's also https://nspasteboard.org for the "nice" players, but it should be under the user's control whether they want to allow other apps to pick up the data a password manager puts into the pasteboard, which means in this case not the app that did put the data INTO the clipboard is relevant but which apps MAY READ the clipboard: A web browser may, a questionable background process for a "I clean up your disk" tool should never be allowed to read such a clipboard.

So, there's two sides: Some apps that GENERATE clipboard data should be set to either "this is all safe data" or "this should be put under scrutiny" and then there's the apps that you want to either always trust to read the clipboards (e.g. clipboard recorders that you trust anyway) or those you never trust (e.g. other background apps that should have no need for clipboard data) or where you want to be asked each time.

The receiving side has already been covered somewhat in earlier macOS versions ("Allow iClip to read the clipboard of 1Password?") but not in the detail I'd like to see, and I guess control over the sending side is what is new, but again in a not very user-friendly way.

Correct me if I'm wrong.

The Pasteboard thing on iOS is very annoying. It often goes off when I initiated the paste myself and it keeps repeatedly asking about it even after I allow it the first time

I swear, the combination of extreme security and unpolished bugginess are going to result in an iOS and MacOS that ask you to confirm every single thing you do. It’s already a mess

@Manx Yeah, often these privacy protections sound great in concept but end up causing problems because they don’t work as advertised. Local Network Privacy is the worst because it seems to trigger incorrectly, there’s not really any way to troubleshoot it, and there’s no way to reset it for testing.

Thanks to the URL shared by Micheal, I could test my app ClipBar, which monitors the pasteboard and displays the current content in the menu bar, therefore accessing it every time it changes.

Without manually choosing "Allow" in Settings (which means Allow FOREVER), it's as bad as one could imagine: an alert pops up each time the pasteboard changes, stating "ClipBar is trying to access your pasteboard" (circa, I translated from Italian), with two buttons: Deny and Allow. Allow in that alert means Allow ONCE.

I certainly agree this is better than other recent changes (Local Network access last year, for instance), but if in Settings there are 3 options, why only show two in the alert?
And nevertheless, using the word Allow with different meaning in the alert and in Settings is a poor choice.

I guess my approach will be to check the current status and, if != Allow (FOREVER), display a screen with a button to open Settings. Not terrible, not ideal.

@Cesare Forelli Requiring granting a permission when launching is a common pattern in macOS apps now, especially for apps that require several permissions in order to function.

It'd sure be nice if Apple provided some kind of unified way of doing this, similar to granting permissions to browser extensions where it happens automatically (no need for the developer to do anything other than listing what permissions they need) and all in one prompt that you only see once, but that would mean Apple would need to actually do something reasonable, proper and convenient for its developers, which they are apparently deathly allergic to.

@Bri You're right, it's a common pattern that Users have come to accept, though nobody loves it; for some apps – clipboard managers or my aforementioned niche pasteboard visualiser – this last change is possibly more extreme, because once pasteboard access is denied, those apps are basically rendered useless.

---

I want to be honest, my initial reaction was tainted by the really terrible experience I had (and continue to have) with Sequoia's new Local Network access management, where to this day Apple "proudly" states in their Technical Note 3179 (https://developer.apple.com/documentation/technotes/tn3179-understanding-local-network-privacy) that "There's no general API that returns whether the current process has local network access (FB8711182).".

This time around, they:

a. Gave us developers a heads up;
b. Built the Pasteboard privacy enhancement around a NSPasteboard.accessBehavior property that the apps can query to know their place in the world.

These two things make a lot of difference and I think my gut reaction was unfair, though I remain convinced that having an in-app popup that says "Allow" where it means "allow once" and the Settings panel that says "Allow" for "always allow" (there, "Ask" means "allow once") is a poor and confusing design decision.

For my app, I went with a check on launch and a "blocking" alert (screenshot: https://cdf1982.com/assets/images/temp/clipbar_pasteboard_alert.png) that explains the requirement and points the user either to the Settings panel or to quit the app, since there's no use for it without such capabilities.

I'll submit to App Review later today, and hopefully I won't be rejected for mentioning something that will come in a future OS update.

@Cesare Forelli: That's a very clever app - useful and cheap. Bought, thanks!

@Plume Wow, thanks! I hope you'll find it useful for a long time :)

---

A note for other developers in my situation: Apple quickly approved an update that includes the alert mentioned above (Open settings / Quit); I kept the release notes pretty generic ("This update makes sure ClipBar will continue to work properly with upcoming system changes.") and provided extensive notes for App Review, explicitly referring to the publicly available AppKit update from April recommending to prepare apps for the upcoming security change; I also attached the alert screenshot. Approval went smoothly.

Sindre Sohrus just shared (https://github.com/feedback-assistant/reports/issues/655#issuecomment-2886557194) the response he received from Apple for the Feedback he filed:

> ...
> The HI design for iOS (which we are following on macOS) states clearly that the dialog itself should NOT include a direct link to the System Settings pane where the "always allow" option exists.
>The goal is to avoid making it too easy for apps to bypass the feature by getting users to grant "always allow" rights after fatiguing them sufficiently by showing excessive dialogs.

By all means, the update for my app ClipBar should have been rejected instead of approved – as it was a couple days ago – based on this reply.

> For the same reason, we should introduce API that lets apps simply show a dialog in-process that would grant such "always allow" permissions.

Yes, they really should. No way to predict this would have been needed and be ready on day one, I suppose.

> Instead, a proper "onboarding" flow should guide users to the corresponding System Settings pane under Privacy & Security, so users are clearly aware that they are making a privacy-related and permanent change.

If I get this right, no direct link, but instructions. Because people love to read.

> That said, with an eye towards streamlining such "onboarding" behavior for e.g. pasteboard managers, we have at existing API to query the current state of the app (NSPasteboard.accessBehavior).
...

Streamlining to a point, I'd say considering that direct linking is forbidden.

@Cesare Forelli
I'm not interpreting that reply as saying that making your own UI for linking to the System Settings for permanently granting the permission is disallowed. I think they're saying that they intentionally chose to have their own permission dialog that appears automatically not include an "always allow" option because then users would just click it without understanding what it was. They admit they need an onboarding method, and that having it guide the user to the System Settings and granting the permission in there is okay (since apparently that's the required bar to clear for the user to understand what they're doing 🙄). So I think you did the right thing.

I do think you're right to be concerned though that you might get rejected from the app store for this, or for any number of other arbitrary reasons. Do you find it's worthwhile distributing your app on it as opposed to the web?

I dutifully enabled EnablePasteboardPrivacyDeveloperPreview for my Mac apps yesterday, experimented a bit with the detectedPatterns API but then got sidetracked debugging a problem in Default Folder X.

While debugging, I started running into VERY strange problems. Sorting menu items had slowed to a crawl and I wasn't able to select any menu items that had submenus attached to them. I thought Apple might have done something in the Sequoia 15.5 update that broke DFX and I'd somehow missed it in testing. I spent half the afternoon trying to figure out what changed. Everything worked in a test app that I built to isolate the behavior, but continued to fail in situ in Default Folder X.

Then I finally tested Default Folder X on another machine running 15.5, and everything worked fine. Huh? Then I remembered I'd set the EnablePasteboardPrivacyDeveloperPreview user default on my personal machine. I turned it off and all of the problems went away.

So developers beware: The EnablePasteboardPrivacyDeveloperPreview user default appears to change things other than just the pasteboard privacy checks. From my vantage point, it really screws up menus. I don't know whether to file a bug now or wait for the first WWDC beta...

@Jon Thanks for sharing. I’ve seen a couple other reports of seemingly unrelated weirdness caused by that user default. Not sure what else it’s doing to cause all this.

@Michael Now that I know it's the EnablePasteboardPrivacyDeveloperPreview default that's causing the problem, I can create a very simple test project that exhibits issues. The menu manager is just half-baked.

@Bri

Apologies for the delayed response!

I wanted to do some research, because I interpreted the following sentence in Apple's response to Sindre Sohrus Feedback

"The HI design for iOS (which we are following on macOS) states clearly that the dialog itself should NOT include a direct link to the System Settings pane where the "always allow" option exists"

as an indication that my alert, while it passed App review this time, is actually against the Human Interface Guideline, but your reply made me suspect (and hope) that I might have been too pessimistic and instead a button to open settings can be interpreted as guiding the User towards settings, as they want.

Sadly, what I believe is the relevant section of the iOS HIG (https://developer.apple.com/design/human-interface-guidelines/privacy#Requesting-permission) doesn't actually contain any clear statement about not including direct links to System Settings, so I either didn't find the relevant part (and I did really look far and wide today!), or the Apple engineer was referring to something that is not publicly available.

My impression, and again I'd be happy to be wrong, is that they really don't want a direct link, so my next App review lottery ticket can very much turn into a rejection for that alert.

To answer your question, I'm an odd indie developer: I truly love the App Store and I never felt the desire to distribute apps outside of it, despite Apple being a poor steward.

The commission I pay to them feels reasonable for the discovery it provides to me – as an indie I do very little marketing, apart from a website – though I know most developers disagree; it's especially true for my main app GlanceCam, because it's an IP camera viewer, which means it handles sensitive data, and the feedback I got over time from many Users is that they trust it more because it comes from the App Store.
So yeah, the list of things I'd like Apple to do to improve for the App Store, and the Mac App Store in particular, is very long and it touches all the known pain points (sandboxing, paid updates, ability to issue refunds directly, not knowing the name and an email address of my Users, the tendency to feature a far too small group of apps in the main page...), but I still think I would not do what I do without the App Store, same as a decade ago.

I know there is a category of apps that store pasteboard history and there are a lot of people who find them useful…but outside that category i’m not sure if it’s appropriate to programmatically paste.

Whatever small convenience the user is getting by autofilling something doesn’t seem worth it, they can just hit command v.

They probably should add another action IMO “Protected Copy” and “Protected Paste” for copying passwords that would put data on a different pasteboard

That is absolutely not what "security through obscurity" means. You would be well advised to learn about it.

@matt Seems like it to me:

Obscurity in the context of security engineering is the notion that information can be protected, to a certain extent, when it is difficult to access or comprehend. This concept hinges on the principle of making the details or workings of a system less visible or understandable, thereby reducing the likelihood of unauthorized access or manipulation.

As Guilherme Rambo points out [here](https://github.com/feedback-assistant/reports/issues/655#issuecomment-2978491184), Tahoe's clipboard manager does not ask for permission. Because of course.