欢迎来到 psychic debugging session 。

第一个问题：你试过找到一个仓库里有的 .DS_Store ，然后在那个目录下 git rm -f ./.DS_Store 再 git commit 再 git push 吗？

第二个问题：你试过关掉 Finder ，再删除 .DS_Store ，再 git add . 再 git commit 再 git push 吗？

第三个问题：想没想过给出程序的输出会更容易调试问题呢？

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

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 所用函数的解析性是数学定理，不是假设。

论文说的是从状态倒推，用户使用的 LLM 看到的输出不是状态，而是状态决定的分布的样本。

@icyalala #3 论文里有实验验证（需要权和状态）。另外这个和 MD5 是完全不同的情况：MD5 里面定义域比对应域小很多，因此必然损失信息；论文的建模里，定义域是有限集（注 1 ），对应域是连续统势的集，加上函数、参数的选择方式，以 1 的概率（此处的概率是参数初始化和训练的随机性）不损失信息。

当然，单射和可高效求逆是两个分开的问题，论文通过实验证明了可以高效求逆。

注 1：实际上应该可以允许到可数集，用概率对单调集合序列的连续性即可从有限集的情况自动得到可数集的情况。

入侵授时中心很有《非常 24 小时》（胡兵、邬倩倩 等）的味道。

第一个问题，为什么把 sparse VHD 翻译成“稀疏矩阵”？应该是“稀疏 VHD （虚拟硬盘）”吧……？我特意查了一下 WSL 的（机翻）文档，似乎没有这样翻译。

最简单的解释是，根据文档，设置 sparseVhd 为 true 之后新的 VHD 默认是稀疏的，楼主看的 VHD 可能不是新的。另外 22 GB 逻辑容量的实体大小是 17 GB 也可以由 #1 的理论解释，实际的数据可能确实有 17 GB 。

似乎是根据最近有过焦点的 Edge 的窗口大小的。

而且 Edge 设置 placement 有些 bug ，比如在全屏模式下 Ctrl(+Shift)+N 会得到错误大小的还原窗口。另外我还发现 Edge 似乎对多用户 (操作系统意义下的用户) 支持有问题……

建立一个新用户，是否有此问题？使用 Register-AppxPackage 在旧用户上重新注册应用包，是否依然有问题？

或许更好的做法是告诉大家之前对系统做了什么修改，不然有无数种方法弄坏 appx 程序。

@yulon #8 explorer.exe 是会对 WM_SETTINGCHANGE "Environment" 作出反应的，如果你需要重启 shell 才有效，说明改变环境变量的进程忘记广播此消息。

除了 PATH 以外都是用户先于系统，PATH 由 系统 > 用户 的顺序合成我不知道是什么时候开始的，但从 Vista 以来这个设计可以缓解一些 UAC 提权攻击。

假设 PATH 是 用户 > 系统 的顺序，那么在 Vista 上，管理员用户运行的非提权程序当然可以修改用户的 PATH ，这会导致重新登录后提权程序的 PATH 先搜索非提权程序指定的目录，是一种提权攻击的渠道。UAC 禁止提权的时候继承环境变量也是出于这个考虑。

反之，如果是 系统 > 用户，那么提权程序的 PATH 先搜索的目录只有提权时才能修改，不存在越权的问题。

如果提权程序搜索 PATH 的时候本来就无法从系统级 PATH 找到，那么这是提权程序的设计问题，无论哪种顺序都不安全，因此对决定 系统/用户 级别 PATH 谁优先不作贡献。

@datou #62 你说的（除了 no ）和我说的是一回事儿。

@aprikyblue #3 楼主写的是 C 不是 C++，没有 enum class 。（当然，换成 C++ 似乎是比较好的选择。）这一点可以从这段代码可以编译知道（见下面第二点）。

————

几个可以挑剔的点：

一双下划线是保留标识符。

二是初始化的时候 constness 不合适，注意 const BizTypeRef 是 struct __BizType * const 而不是 struct __BizType const *，于是这里会丢失 const ，如果实现方（很容易无意间）尝试修改只读复合字面量的 .value 的话会有 UB 。

三是，如果实现方不需要数据，那么实际上没有必要使用 value ，用 non-const 复合字面量本身就可以确保几个表达式的对象不占据相同的位置（但是 const 复合字面量可能会是同一个对象）。

————

@ysc3839 #7 楼主的版本有不同的值，所以无法是同一个位置。在文件作用域的复合字面量是静态存储期。