macOS 下程序监视剪切板不需要任何权限的吗？

1. 这个东西叫“剪贴板”，至少 Windows 和 macOS 都是这么叫的。
2. 通常来说你不希望在每个程序里第一次按 Ctrl/Cmd+V 的时候弹出一个对话框。

@geelaw #1 这不一样吧，一个是用户主动粘贴，一个是软件主动读取，就和淘宝的那个口令一样

非沙盒 App 权限多了去了，剪贴板算啥。

@lcandy #2 如果文本框是进程自己的，那么用户主动粘贴的实现就是进程在用户粘贴的时候读，至于是操作系统默认实现的读，还是软件自己实现的读，这无法区分。即使可以，另一个问题是很多文本编辑器都需要复杂功能，无法使用操作系统默认的实现。

如果你希望按进程控制剪贴板的权限，首先要做的是把所有“默认可以让用户粘贴”的文本框都由操作系统的特殊进程提供，并跨进程合成完整 UI 。这仍然不能解决复杂文本编辑器第一次粘贴需要被打断的问题。

举个例子：在 macOS 里，如果你用“打开”对话框导航到 Documents，并且拒绝提供权限，那么“打开”对话框无法显示里面的内容。在 Windows 里，如果 UWP 用 FileOpenPicker，它不需要具有访问本地文件系统的权限也可以让用户自由选择该用户有权限访问的内容。这个区别在于，macOS 里每个 app 的“打开”对话框都是进程内代码，自然不能访问被拒绝的文件夹；而 Windows UWP 里的“打开”对话框是一个专门的进程（该进程有权限访问文件系统，并且可以把权限提供给 UWP ）完成的，该进程确保打开文件是用户自己的操作。

在文本框的例子里上述解决方案仍然不好，因为通常一个 app 可以要求自己的文本框执行一些操作，那么它可以要求文本框粘贴，然后读取内容。此外，进程隔离仍然不能解决复杂、非系统实现文本框的粘贴问题。

iOS 都不需要任何权限，何况 mac

挺好了，至少只是监视而不是帮你修改

@geelaw 纠正一下，macOS 打开文件的对话框是 NSOpenPanel，是由系统进程管理的。

当然无论是 NSOpenPanel 还是 FileOpenPicker 都不能阻止应用自己读文件然后画一个假的对话框。

@XDDD #7 看了一下，这个是 10.15 引入的改变。这个和 UWP 的情况不一定一样，如果打开文件对话框的进程仍然被原来程序的权限限制，进程隔离的意义就不在于权限隔离了，而是比如稳定性、兼容性等。现在打开文件对话框是否还受程序本身能否访问某个文件夹的限制？

程序想自己画对话框和安全问题无关，UWP 无法自己读文件然后自己画对话框，它通常没有权限读文件系统。

@geelaw macOS 的沙盒是 10.5 时候的事，比 UWP 不知道早到哪里去了……

我倒是很好奇你说的“无法显示 Documents”的是哪个应用。这听起来像是自己读文件画的对话框（受限于沙盒读不到）。但是沙盒应用搞这种乌龙听起来实在可疑。

@XDDD #9 10.15 的改变是所有的 app 都会得到进程外的对话框（不仅仅是 sandboxed ）。我找了一下，是不能显示被拖拽的文件夹，见第三张图 https://apple.stackexchange.com/a/332686 不过我以为 macOS 的权限限制对所有的进程都有效，比如 Terminal 似乎不是 sandboxed app 但是仍然受到个人文件夹访问限制。

@geelaw 完整沙盒和敏感数据限制是两个不同的东西。沙盒带来的是磁盘访问限制和一整套 API，应用通过这些 API 来完成必要的文件处理。敏感数据限制是系统自动完成的，对应用完全透明。

Mac App Store 软件无法实现，不然你认为 Paste 为什么 Side Load 一个 Paste Helper 单独安装器？迅雷没进 Mac App Store，所以可以

NSPasteBoard 可以跨进程共享读和写，也有底层 API 可用，但是 Mac App Store 应用会受限只有同一个 Group ID 可读写，因此实现不了监听任意读写。

@lizhuoli #12 MAS app 不可能有剪贴板隔离，否则无法解释复制数据后到处都可以粘贴。Paste Helper 的作用是直接把数据放到另一个进程里（不需要手动粘贴），和把内容放入剪贴板、读取剪贴板无关。