@
lcandy #2 如果文本框是进程自己的，那么用户主动粘贴的实现就是进程在用户粘贴的时候读，至于是操作系统默认实现的读，还是软件自己实现的读，这无法区分。即使可以，另一个问题是很多文本编辑器都需要复杂功能，无法使用操作系统默认的实现。
如果你希望按进程控制剪贴板的权限，首先要做的是把所有“默认可以让用户粘贴”的文本框都由操作系统的特殊进程提供，并跨进程合成完整 UI 。这仍然不能解决复杂文本编辑器第一次粘贴需要被打断的问题。
举个例子：在 macOS 里，如果你用“打开”对话框导航到 Documents，并且拒绝提供权限，那么“打开”对话框无法显示里面的内容。在 Windows 里，如果 UWP 用 FileOpenPicker，它不需要具有访问本地文件系统的权限也可以让用户自由选择该用户有权限访问的内容。这个区别在于，macOS 里每个 app 的“打开”对话框都是进程内代码，自然不能访问被拒绝的文件夹；而 Windows UWP 里的“打开”对话框是一个专门的进程（该进程有权限访问文件系统，并且可以把权限提供给 UWP ）完成的，该进程确保打开文件是用户自己的操作。
在文本框的例子里上述解决方案仍然不好，因为通常一个 app 可以要求自己的文本框执行一些操作，那么它可以要求文本框粘贴，然后读取内容。此外，进程隔离仍然不能解决复杂、非系统实现文本框的粘贴问题。