geelaw

@pweng286 #1 大模型不需要理解加密后的输入，做的运算是大模型的同态作用。（同态加密的意义就是可以把任何运算都在密文里面进行，而不需要知道明文。）

如果大模型不经常更新的话，用 (F)HE 有点大炮打蚊子，可以用凝练的函数求值（ laconic function evaluation ）。但我对两者的实践都不是很了解，而且我的猜测是：现阶段它们的效率还不足以在可以容忍的时间内算完 LLM 一轮作用。

@qwingmix #13 直接阅读字体的授权是最快的解惑方式。如果授权明确了是不可撤销的，则按照授权使用就不会有事儿。

@processzzp #10 微软的文档观点相反 https://learn.microsoft.com/en-us/typography/fonts/font-faq 但是很神奇的是最后链接里列出的“自带”的简体中文字体只有等线、仿宋、楷体、黑体（ SimHei ）。另外链接页面是 Windows 10 的，没有授权信息页指向 Windows 11 的，而 Windows 11 的自带列表里有雅黑。

我的理解是：要么微软无权授权但错误授权（因此授权无效），要么方正无权追究 Windows 用户用商业软件在像素图里使用雅黑但错误追究（因此是无效诉讼）。当然，这并不改变方正会找人麻烦的事实。

信息不足。

如果你为员工建立了 Personal Account （定义见 https://docs.github.com/en/site-policy/github-terms/github-terms-of-service ），并且这些账户是免费的，并且你的员工自己有（别的、免费的） Personal Account ，并且两个 Personal Accounts 都是人类使用而非机器使用，则违反了“一个人最多一个免费 Personal Account （除了额外的一个机器账户）”的规定。

另外就是如果这些账户都是同一台电脑建立的，可能 GitHub 记得这件事，所以一个封了，其他的也就都一起被发现了。

如果是上面的情况，规避方法：不要帮别人创建 GitHub Personal Account ，除了上面的问题之外，还有一点比较重要的是你的员工可能没有被提示看 GitHub 使用条款，这会导致注册流程从合同角度不成立。让员工入职之后自己建立，或者使用自己本来就在用的账户，并且把公司邮件加入他的账户邮件里。

申诉找回：可以访问 support dot github dot com slash contact slash cannot_sign_in 申诉。如果是因为上面的原因，可以解释清楚状况并告知自己已经了解了规则，至少应该是可以取回数据的。

Windows 计划在 2027 年去掉 VBScript 的支持，届时可以用 PowerShell

(New-Object -ComObject InternetExplorer.Application).Visible = $true;

如果要命令行（创建快捷方式）的话

PowerShell -NoProfile -Command (New-Object -ComObject InternetExplorer.Application).Visible = $true;

@niubiman #21 不太确定你说的 Ctrl/Cmd+V 的 API 是什么，Windows 上发生的事情也是：用户按了 Ctrl+V ，程序意识到了这一点，然后调用 OpenClipboard, GetClipboardFormatNameW, GetClipboardData 读取剪贴板，操作系统不知道程序为什么调用它：可以是 Ctrl+V ，可以是上下文菜单的“粘贴”，可以是工具栏的“粘贴”，可以是这个 app 就是想查看剪贴板。

我没有仔细看过 WinRT 是如何限制剪贴板 API 只有前台才能访问的，有两种可能：WinRT 剪贴板 API 单纯选择在非前台时不访问剪贴板，实际无权限约束，直接用 Win32 API 就可以访问（当然，这样做的 app 无法通过审核就是了，但可以 sideload ）； AppContainer SID 拒绝非前台线程访问剪贴板，即实际上有权限约束。

iOS 上，我不确定用户点击菜单的时候，是真的有权限隔离，还是系统菜单和 app 主动访问都在同一个进程里，只是系统菜单访问剪贴板用的是私有 API （和 app 主动调用的 API 是两套路径），所以主动调用之以绕过弹框的 app 无法通过审核。

我的点在于：要区分用户是否主动，需要权限隔离（操作系统内核所施加的安全性）而非仅仅是审核（本质上是所有上架 app 被迫自律）；权限隔离需要的模型可以做，但不简单。

@niubiman #10 用户无法调用 API ，只能用手按一下屏幕，然后程序知道用户按了一下某个按钮的时候，调用 API 去访问剪贴板。

此问题根源在于无法准确建模访问剪贴板的时机，解法也只能是正确建模。一个可以考虑的思路是这样的：

1. 系统进程可以任意访问剪贴板
2. 所有 app 都默认不能访问剪贴板，但可以被用户同意访问（类似于地理位置的权限模型）
3. 提供一个新的按钮控件，此控件生活在系统进程里，点击此按钮时，系统进程读取剪贴板并传送到 app 进程的事件处理程序里

因为新按钮控件位于系统进程，在合适的权限模型下，app 进程无法访问系统进程，所以无法假装点击。

另外商店审核也可以加入规则，但在 API 和进程权限、隔离上建模是最重要的部分。

@Linho1219 #15 原生文本框的代码只要依然运行在 app 进程里，app 就完全可以选择把原生文本框里访问剪贴板的代码抽取出来。

当然，能这样做是因为 app 的代码并不是严格受控的，一般地，剪贴板 API （或者任何本机代码）并不知道自己的调用者是谁——对比 JavaScript ，后者可以做到“只有用户点击按钮的时候，才能用代码开启新标签页而不被默认阻拦”，是因为“谁、什么时候调用的”的信息来自 JS 引擎。