geelaw

所以答案取决于如何理解“安全”，按照“在模型下满足模型里的约束”的定义，当然是安全的。

Windows 的安全模型里，可执行程序没有身份，最细的权限粒度基本上就是“用户”（会话、窗口站点、桌面基本上和用户这一套是正交的），如果用户 A （人）用用户 B （ Windows 权限控制模型的对象）的身份运行程序 C ，那么 C 可以访问所有用户 B 的信息。

可执行程序没有身份，所以不存在加密方式，使仅某个可执行程序可以解密。所谓 app-bound encryption 只是让恶意软件需要绕路（实际上解密的进程是以用户 SYSTEM 的身份运行的，并检查请求解密的进程是 Chrome ），并不能从权限模型上禁止恶意软件。绕过方法很简单：用户 B 当然是有权限调试用户 B 的进程的，因此恶意软件以用户 B 的身份启动后，只需要调试用户 B 的 Chrome 即可注入任意代码，包括“解密之后发送出去”这种代码，此时 SYSTEM 身份的进程会认为请求解密的程序是 Chrome ，所以会同意。

实际上，要给用户 B 身份的非 app container 的应用程序注入代码非常简单，因为 shell 是可扩展的，只要注册一个 shell 扩展，那么在用户使用“打开”“保存”这类对话框的时候就很可能会加载此扩展。

预防针提示：Windows 8 引入的 app container 只能确保 container D 不能干扰 container D 之外的东西，不能确保用户 B 不能干扰它的 containers 。

@JadePenG #6 “完全在 Excel 表格中找不到”是单纯因为 Excel 没有实现查看缓存的功能，无责任推理：缓存只是一种提升性能的工具，常见场景是被链接表在内网的共享文件夹或者企业私有云里面，链接工作簿可能在各种位置（包括跨国公司的另一个国家的内网里，或者电脑本地），而每次查询都要访问云实在太慢了，或者用户可能出差，笔记本不在内网，或者需要很慢的 VPN ，所以需要缓存让数据在链接工作簿里存在；缓存不是面向最终用户的功能，因此没有必要让最终用户可以查看，而要实现可以查看需要费力气，所以不实现。

答案就在文档里

https://support.microsoft.com/en-us/office/manage-workbook-links-fcbf4576-3aab-4029-ba25-54313a532ff1

链接工作簿是有缓存的，并且可以选择不提示用户刷新缓存。文件很小不代表缓存不到位：首先被查询表是复合文档格式（ xls ），很可能查询工具表本身也是复合文档，这种的存储效率很高；如果查询工具表是 XML 格式（ xlsx ），那它自带 ZIP ，可能有压缩。

如果是 XML 格式，直接解压缩就可以看到缓存的数据。

建议提示单位，而且无论如何实现，允许用身份证号码直接查询工资明细也是比较严重的信息安全问题。有功夫研究自动查询公式，不如一步到位直接自动生成所有人的工资条（ VBA/PowerShell 访问 Excel COM 都很方便）。

那个位置的 DWMFRAMEINTERVAL 的意思是每多少毫秒才允许 DWM 渲染一帧。设置为 16 的话会得到 62.5 Hz ，设置为 17 的话会得到 58.8 Hz 。因为只能设置为整数，所以没法设置为 60 Hz ，此外文档已经提示，实际帧率并不一定等于设置的最大帧率。

真正 tried-and-true 方法自从 Windows XP 就有了：快速用户切换，日常不用管理员组的账户。

较差的策略是使用 Windows 2000 以来的 runas ，而 UAC 就是把一个用户分成俩，按需 runas 。

Math.random 并不安全，不适合用来生成密码。

而且这个 UI 是有些幽默在的，比如点一下“生成密码”，然后把排除字符设置为 ? 然后再点“生成密码”，结果是密码不会重新生成。很难想象这种错误是如何发生的（当然，非人类写的代码，就可以理解了）。

另外一条评论：请不要把研究者等同于他们供职的机构，做研究的是人，不是机构。

@CrazyRundong #12 hello, 这里 idea 的意思是“（证明）思路”，LLM 所用函数的解析性是数学定理，不是假设。