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

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

@zackZhong #2 > MD5...
我没说过 MD5 是选择明文安全的加密算法。实际上单纯 MD5 三个字符并不代表任何一种加密算法。

> 但我的密码存在密码管理器上。
如果你认为存在密码管理器里面就安全了，为什么还要先加密再存呢？如果密码管理器本身是安全的，无论你对送入密码管理器的东西做什么都不会让它变得不安全（理论情况下，也假设你做的事情都是高效的），但是是否“更安全”并不是明显的事情，尤其是你做的额外操作并没有什么特别的安全性的时候。

@koswu #4 这个想法的问题在于这个加密工具的 key 不泄露也很容易攻击，不需要等到 AES 被破解的一天。

这个不能真的用来管理密码，因为它实际上就是 multi-time pad，非常不安全。

你的加密算法（不是说密钥生成算法）没有任何随机性，同一个密码的加密多次总是相同的，这表示你的加密方法不具有选择明文攻击下的安全性。默认情况下，使用的加密算法应该具有选择密文攻击下的安全性。

如果你知道密码 A 和密码 B 的密文，你可以算出 A xor B 。一个非常严重的推论是：如果你知道密码 A 、密码 A 的密文和密码 B 的密文，如果 B 的长度不超过 A，则可以完整还原密码 B 。假设你在网站 A 的密码因为网站 A 的失误泄露了，而你的密码的密文也泄露了，好巧不巧，网站 A 的密码还是最长的，那么你所有网站的密码就都泄露了。

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

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

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

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

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

Cloaking 的概念和 UWP 没关系，如果你用虚拟桌面的话，不在当前桌面显示的窗口都会被 cloaked 。

输出为 HTML 之后用 Word 打开好像就行了吧。如果你想要不同的格式可以打开之后在“设计”选项卡里更换。

如果要设置表格风格可以在文件最开始添加 inline CSS 。

如果要纯天然渲染结果可以随便找个开源的 Markdown 解析器，用 COM 访问 Word 进行输出，或者输出 Office XML 。

@Leon6868 #5 因为 Windows 10 会预热启动 UWP 来提升体验。我说过了你需要用 DwmGetWindowAttribute，这里你需要判断窗口是否被掩盖（ cloaked ），一个例子代码见 https://devblogs.microsoft.com/oldnewthing/20200302-00/?p=103507

此外我也提示过你可能想要模拟任务栏或者 Alt+Tab 对话框选择窗口的方式。

另外下面的 Email GitHub Twitter 的链接在在指针悬停时会显示反对角线调整大小的光标，看起来很奇怪。是设计使然吗？

以及当点击 Show Address of BTC 或 Show Alipay 弹出模态对话框后，Email GitHub Twitter 以及主题切换按钮会移位。

@tanranran #17 打印后的可用性当然也很重要，当然你不是这个意思。

大多数网站关掉 JavaScript 还有基本功能，而且为了隐私关闭（一部分网站的） JavaScript 也不是什么新鲜事儿。

似乎关掉 JavaScript 就完全不能用了。

@opengps #3 这个问题和句柄泄露无关，USER 句柄是不计数的，泄露方式只能是建立的窗口之后不使用。而且一个会话里的 USER 句柄数量最多是 65536 。

“用户不能操作”仍然不是一个有意义的定义，而且用户当然可以操作 IME 窗口，不然候选词列表怎么用？如果你觉得任务栏是否显示这个窗口的按钮可以作为判据，那么你可以模拟任务栏的选择，这是有文档记录的：

https://docs.microsoft.com/en-us/windows/win32/shell/taskbar#managing-taskbar-buttons

定义“无意义”，如果当前没有显示的窗口是无意义，你可以通过 IsWindowVisible 和 DwmGetWindowAttribute 判断。

微软做了极简风：粗糙。Google 做了极简风：微软粗糙。显然截图里微软的 UI 更有用：显示修改日期、子对象数目、共享状态等。

另外，OneNote 笔记本实际上是文件夹，类似于本地 OneNote 的结构，而且 OneNote 笔记本的名字和位置都需要显示才能管理，假设你想有两个同名的笔记本，如果不显示位置则无法区分哪个是哪个，也没法移动位置，而且 OneNote 笔记本共享、删除等也可以和其他 OneDrive 里的对象一样管理。既然本来就是同类物，为什么不显示呢？

Google Photos 和 OneNote 无法像 OP 所说那样比较，OneDrive 里也有不显示但是占用空间的东西，比如 Windows 8 、Windows Phone 备份数据。根本区别在于 Google Photos 没有把照片当“文件”管理，而 OneNote 就是文件。

最后，日历、邮件、联系人放在一个 app （我想你说的是 Outlook 和衍生的 communicationapps ）是因为 Outlook 的定位是 personal information manager，而不是单纯的“邮件客户端”。

@ipwx #19 #20 基于 RSA 签名算法并不是“用私钥加密”，根本没有“加密”的概念。

#0 JWT 不一定具有保密功能，不存在“密文”“加密”的概念。不过楼主有一部分说得没错，验证签名、消息验证码不需要使用 hash 函数，只不过真实世界里的签名、消息验证码都在某些步要用 hash 函数，因为不用 hash 函数的（可证明安全）方案实际效率令人无法忍受。

难道你么不觉得最重要的暗示是 Desktop application 也可以使用 Live Tile 了吗？这个是一个巨大进步。

另外这个自定义色彩的删除是一个巨大退步，实际上从 Windows 10 最开始就一直在走下坡路，仔细看 Windows 8/8.1 的磁贴渲染，颜色的运用和动画的缓动函数都好太多了。

C# 不可能的，Windows 95 于 2001 年结束支持，C# 1.0 是 2002 年发布的。

上古版本的 BASIC 是可以的。

你不需要知道 tuple_cat 或者 index_sequence 或者 disjunction，这些全都可以通过基础手段实现。

第二个的思路：列表 A 没有重复等价于 (A 是空的) 或 (A 第一个元素不等于其他且 A 去掉第一个后无重复)。

第三个的思路：可以通过枚举算出一个元素在列表里的位置。

使用 hash 函数 ❌
使用伪随机函数 ✔

这样会得到一个具有适应性密码泄露安全性的方案：使坏者可以请求任意 app 的密码，最终它需要猜出一个未曾见过密码的 app 的密码，希望它猜不出来。

一种方式是把 hash 函数建模为随机预言，这样 hash 函数可以充当伪随机函数，但是这显然不如伪随机函数好，后者是标准模型下可证明安全。

在实践中，大家相信 AES 是伪随机函数（而且 AES 比 SHA256 快，而且 SHA256 已经不能被建模为随机预言了），所以正确的做法应该是通过 KDF 把密码变成 AES key，然后把 app 名字编码为 AES 输入，把 AES 输出映射为 app 密码。