八篇报道今日得分均超过200分。主导主题不是人工智能能力,而是控制权。谁持有钥匙,谁持有快照,谁持有审计记录,而答案往往是“不是你”。今日的两篇报道是开源内存分配器和身份标准,这类事物通常被忽视,直到它们成为你与非常糟糕的一天之间的唯一屏障。
我不喜欢密码凭证
656 点 · hawksley.dev
Ethan Hawksley 认为,密码凭证是企业控制的绝佳工具,但对个人来说却是个糟糕的选择。他强调了这种区别的重要性,而不是轻视这项技术。他承认密码凭证确实带来了实际优势:原生凭证无法被伪装的登录页面窃取,因为私钥从未离开认证器,服务器端的入侵也无济于事。对于能够发放凭证、强制恢复并提供技术支持的企业来说,这确实是一个严格的升级。
对于个人用户来说,他指出威胁模型发生了倒置。主要的风险不是中间人代理,而是永久锁定、因异常行为触发的自动化封禁以及设备丢失。密码凭证并没有消除账户安全中的最薄弱环节——而是将其转移到了恢复环节,而大多数供应商的恢复方式仍然是短信、魔法链接或安全问题。因此,你得到了前门的防钓鱼保护,但后门仍然和之前一样脆弱,还产生了一种虚假的安全感。硬件密钥的批评是最尖锐的部分,这其实是一个设计特性而非缺陷:WebAuthn 凭证在安全密钥上可以创建和删除但不能导出,因此冗余意味着购买两三个密钥并在每个站点注册它们——成本随着账户数量线性增长,且从未变得更简单。通过混合传输(二维码加蓝牙)进行跨设备流的理论安全性和实际脆弱性。他的建议是:在第三方密码管理器中生成随机生成的单站点密码并使用独立的 TOTP 应用。大多数读者会忽略的细微之处是他预计第三方密码凭证——由你自己可以同步和备份的密码管理器持有的凭证——将是最终的答案。他反对的是当前的控制权模型,而不是不对称凭证。
OpenJev
463 点 · openjev.com
页面现在显示“SemIf”,宣布它曾叫作 OpenJev,并附带免责声明,称其与 TypeSafe 无关且未获其背书——这是在某位拥有律师的人注意到名称后发布的通知。它是什么?一个浏览器本地实现的与 Jevons 模型相同的决策程序理念。Jevons 模型的已发布基准引发了“LLMs 无法实际处理概率”的争论。
演示比较了两种从同一加载模型中获取一组允许选项的概率分布的方法。第一种直接读取选择概率并仅在显示选项令牌上进行归一化,没有任何解码。第二种要求模型逐个令牌以 JSON 格式写出概率分布,这样你可以观察每个令牌的到来并记录时间。一切都在客户端通过 wllama 进行,使用固定版本的 GGUF 构建——没有后端,权重从 Hugging Face 拉取并在浏览器中缓存,使用 performance.now() 记录时间,没有预设结果。你可以选择 Qwen3 0.6B(639 MB)、MiniCPM5 2B(1.56 GB,桌面默认)或 Qwen3.5 4B(3.01 GB)。
得分榜是有趣的部分,页面比大多数演示更诚实。拥有检查点的得分分别为 44.0%、68.6% 和 81.3% 的平衡准确性——而托管 Jev 模型的已发布准确性为 88.3%。网站明确指出直接得分是对显示选项令牌的 softmax 结果:它们不是校准的置信度,且排除了模型可能偏好的不在列表中的答案。结合量化权重的免责声明,诚实的解读是:一个 2 GB 的量化模型在浏览器中可以达到比一个更大托管模型决策准确性约 70-80% 的水平,带有量化权重的变化和此测量的是选择性读出而非自由形式推理的局限。这对于衡量本地推理以进行分类决策的数据点是有用的。这并不是“一个小的本地模型匹配前沿模型”的说法,页面对此表示了认可。
通过堆溢出和 SSO 配置错误入侵 OpenAI 内部代码库
452 点 · Hacktron
7 月 25 日,Hacktron 将两个不相关的漏洞链成 ChatGPT 和 Codex 账户接管,影响多个 OpenAI 员工,进而入侵 OpenAI 的内部代码库。从发现到内部代码库访问仅用了不到 72 小时。他们通过让被入侵员工的 Codex 在 openai/openai 中打开一个无害的拉取请求来证明访问权限,而无需阅读任何敏感信息。
该链提醒我们,身份是将论坛转变为公司的粘合剂。第一步是通过 Discourse 的图像上传管道在 community.openai.com 中利用 libheif 的堆缓冲区溢出;环境使用了一个缺少安全补丁的 Debian 镜像,且 HEIC/HEIF 上传走了一条 Discourse 没有加固的路径。这导致了论坛的 RCE 和管理权限。第二步是 OpenAI 身份基础设施中的 SSO 配置错误,允许“使用 OpenAI 登录”在论坛上升级为更广泛的 ChatGPT 和 Codex 访问——从那里,所有连接到这些账户的服务:GitHub、Slack、电子邮件。该范围声明不是理论上的,而是结构性的:你连接到 ChatGPT 账户的任何服务都会继承最弱身份使用位置的破坏范围。Bugcrowd 报告提交于同一天早上,OpenAI 在大约 14 小时后确认了修复,Discourse 在周一发布了补丁并增加了图像处理沙箱以作为纵深防御,GHSA-vhm9-85gw-x335 于 7 月 28 日发布。奖金为 6,500 美元,OpenAI 指出,针对 Discourse 主机论坛的测试明确超出了他们的计划范围——这应被解读为对奖金边缘的异常坦率声明,而不是对金额的抱怨。让你感到害怕的是 Hacktron 的后续工作,HEIF Heist:libheif 是 Slack、Meta、GitHub Enterprise、Ruby on Rails、Next.js、Astro 和 Gatsby 图像管道的间接依赖。如果你接受用户控制的 .heic、.heif 或 .avif,那么帖子中的实用建议是假设你受到影响并去检查。对于自托管 Discourse 的操作者,明确告知需要进行 web 界面更新以替换图像,并需要 git pull 加上 ./launcher rebuild app。
Cloudflare 快速隧道
399 点 · Cloudflare
cloudflared tunnel --url http://localhost:8000,无需账号,无需 DNS,无需内网端口。重申一下其工作原理是因为这是产品能够工作的原因:守护进程打开一个仅出站连接到 Cloudflare 的 335+ 边缘位置中的最近一个,而入站流量通过其任何播网络回传到该连接,这就是为什么你不需要端口转发、公共 IP 或防火墙更改。TLS 和 DDoS 过滤来自边缘之后,URL 几秒内打印出来。
快速隧道一直是 cloudflared 的一个功能,所以实际新闻在于包装:一个产品着陆页面,带有真正的代理时代钩子。有趣的新增功能是结构化输出——主机名、边缘和健康状态作为 JSON 输出到 stdout,因此编码代理不需要正则表达式解析日志——以及默认的临时生命周期,隧道在进程结束后会关闭。这使其成为代理在循环中启动并忘记的评估框架或 webhook 端点的合适选择。它是一个比固定配置更好的基本工具。
然而,页面没有说明的内容很多。没有提到速率限制,没有承诺的正常运行时间,也没有说明快速隧道是否适用于任何负载。任何依赖于一个隧道的人都知道其中的空白:主机名是随机的、不可撤销的,并在进程结束后死亡,这是测试循环的特征,也是发送给客户的演示的陷阱。框架“0 个端口打开,没有入站流量”是准确的,也是一场魔术表演——你确实打开了一个端口,只是 Cloudflare 的。这是一个不错的交易。但这并不是无暴露的同义词。
jemalloc 5.4.0
309 点 · GitHub
标题是日历,而不是变更日志。jemalloc 的上一个次要版本 5.3.0 于 2022 年 5 月发布;5.4.0 则于 9 月 17 日发布,因此这是 5.x 线的第一个功能版本,已经四年多没有更新了。超过 160 个提交,发布说明以非同寻常的坦率描述了它们,主要是技术债务——重构、修复、测试覆盖率和选项清理。
真正的功能是固定内存。EXTENT_ALLOC_FLAG_PINNED 允许自定义的 extent 分配钩子标记非可回收映射,如 HugeTLB 页面,以便它们优先在正常衰减和清除管道之外被重用,而匹配的 stats.pinned、stats.arenas.<i>.pinned 和每个 extent 的 pinned 字节 mallctl 最终使固定使用变得可观察。如果你使用巨大的页面运行 jemalloc,这就是你想要的变化:之前分配器和你的固定策略在争夺相同的页面,但没有看到谁占上风。
不兼容的变化是 tcache 政策。每个 bin 的填充和保留目标现在根据 GC 事件之间观察到的需求进行调整,而不是旧的固定填充和刷新政策,以及七个过时的调优旋钮:lg_tcache_nslots_mul、tcache_nslots_small_min、tcache_nslots_small_max、tcache_nslots_large、tcache_gc_delay_bytes、lg_tcache_flush_small_div、lg_tcache_flush_large_div。在 malloc_conf 中设置这些旋钮会无声地忽略它们,而对应的 opt.* mallctl 返回 ENOENT——无声地忽略一个配置旋钮会产生一个非常慢的事故,所以在升级之前去你的配置中找到它们。tcache_ncached_max 仍然有效。此外修复了:errno 现在在 free、free_sized 和 free_aligned_sized 以及 process_madvise 基础的清除过程中保持一致;free_sized() 和 free_aligned_sized() 接受 NULL(C23);arena_reset 中的一个潜在死锁;prof-sampling 保护页的交互;以及 TSD 生命周期边缘情况,即在线程拆解后晚些时候的降级分配。runtime experimental_infallible_new 选项现在是编译时 --enable-cxx-infallible-new,这是一个直接的胜利,用于移动构造函数优化。
如何使用 LLM 写作
296 点 · sockpuppet.org
两条规则和一个工作流程。规则一:你不得使用 LLM 建议的任何一个词。规则二:将它的赞美视为缺陷,因为模型的默认姿态是鼓励,它会告诉你一篇平庸的草稿是好的。规则一背后的理由比听起来要尖锐——前沿模型优化以产生令人愉悦的措辞,因此它们的建议到达时已经预设了标题,一篇由单独优秀的措辞组成的文章读起来就像没有标题的杂志。
工作流程是一个你可以实际运行的循环:自己撰写初稿,严格交给一个强大的模型以识别问题,自己重写标记的段落,然后将原始版本和重写版本交给一个对编辑过程一无所知的第二个模型,询问哪个更好。这一步是应对大多数人忽略的偏见的解决方案——如果你编辑的模型也是评判修订版的模型,它已经知道了你想要听到的内容。他明确指出这需要一些工具,草拟了一个使用 Python/HTMX/SQLite/Tailwind 的工作坊应用,并建议将这些步骤通过 Codex、Claude 或 Antigravity CLI 运行。推荐阅读是“风格:清晰与优雅的写作”,他将其推荐给程序员,作为散文的蓝图。
这之所以成立,是因为其底层假设:读者在极低的精度下就能检测到 LLM 生成的文本,无论你如何打磨它,因此 LLM 辅助写作只有在声音和判断保持在人类手中,而模型进行耗时的机械扫描——被动语态、名词化动词、填充副词、属于其他地方的段落——时才有效。这与“提示它来写这个”建议相反,这是工具的正确形态。结尾的诚实注释是:他将最终成品输入了 GPT-5,后者说它太长了 20%,他没有修改。这是一个正确的决定,也是规则二的精彩示范。
美国军方在使用 AI 生成假情报报告后险些引发战争
230 点 · CNN
一位特种作战司令部分析师查询了一个聊天机器人关于一份关于船只清单的情报报告,该报告源自美国特种作战司令部太平洋司令部。聊天机器人融合了公开信息和政府系统中持有的机密信号情报,得出结论称中东的一艘中国船只携带了核武器项目的组件,并生成了一份情报报告。该报告在今年春季在美国军事中流传,正值与伊朗的战争期间,引发了拦截该船只的计划:据 CNN 的四位消息来源称,武装人员正在准备登船,军用飞机在空中待命。
就在行动即将开始前,官员们才深入调查了报告的来源,并发现它是由 AI 协助生成的,聊天机器人错误地识别了货物。一位消息来源对报告的描述是“完全虚假”。另一位的描述是“差点引发战争”。CNN 无法确定被误识别的货物是什么,也无法确定聊天机器人是商业产品还是政府产品——这比听起来更令人不安。一位前高级美国官员对政府工具的描述是记住这句话:“内部工具大多只是商业产品的‘化妆’版本。”
问题不在于分析师使用了聊天机器人。问题在于输出被包装成“军事官员信任的报告”形式,使用了相同的工具,而对格式的信任代替了验证的作用。再加上一月份的“AI 加速战略”推动在目标、物流和供应链中加速采用,你有了一个机构,其防备单一虚假句子的唯一防线是下游的人类怀疑。CNN 指出,SOCPAC 和五角大楼未对要求置评作出回应。故事中的任何人都没有做任何稀奇古怪的事情;失败模式是一个漫长而无聊的依赖链,中间有一个未经审计的模型,最终决定是否发射武器。
ZCode 内部:悄悄上传你的整个 Git 历史到云端
204 点 · ferstar
这是今天的故事,从磁盘清理开始。~/.zcode——Zhipu AI 编码桌面应用的数据目录——已超过 700 MB。在 v2/checkpoints/ 内,一个状态文件描述了一个 313,070,842 字节的加密存档,由一个 345,549,173 字节的工作空间构建而成,标记为 baseline,且 failureCount 为 564。这是一个完整的商业项目快照,位于一个待处理目录中,正在进行重试。
作者读取客户端的 app.asar 以重构流水线,这是最糟糕的信封加密:客户端向 zcode.z.ai 请求凭证,接收一个对象键和该加密周期的 RSA 公钥,将工作空间打包成 tar.gz,使用 AES-256-CTR 加密,使用 服务器提供的 公钥通过 RSA-OAEP-SHA256 对称密钥进行包装,直接上传到阿里云 OSS;OSS 然后回拨给 Zhipu 注册快照。私钥从未触碰你的机器。作者尝试了每一个本地私钥,如预期,均失败。你自己的磁盘上的密文无法被你、客户端或任何其他东西打开,只能被 Zhipu 的后端打开。
打包的内容是关键部分。每次捕获都是无条件的——本地生成的清单以明文形式写入,对于一个 42,411 个文件的快照,分解为 .git/lfs/ 占 196.1 MB(56.8%)、.git/objects/ 占 102.2 MB(29.6%)、.git/logs/ 重定向日志、源代码和文档占 46.2 MB(13.4%)。.git 目录占整个负载的 86.6%。因此,云接收的不是你的工作树,而是你的仓库的整个历史:历史 API 密钥和秘密在后续提交中被删除,未推送的本地分支名称泄露了未发布的成果,以及 .git/config 中的内部 GitLab 主机名和路径。第二个清单 repo_snapshot_extra_manifest 对工作空间中的全局应用配置文件进行哈希。捕获事件在 captureBeforePrompt 和标记为 repo-wiki-update 的任务完成时触发;一个活跃会话最多产生了 62 个捕获事件。
两个 UI 切换是“仅优化体验”(optimizeAgentExperienceEnabled)和“仓库快照索引”(repoSnapshotIndexingEnabled)。前者控制数据是否可用于模型训练,而不是是否收集和上传数据。后者控制服务器端对已上传快照的索引。捕获旁路在启动时无条件实例化,不受用户偏好控制;唯一的要求是一个有效的 JWT。登录意味着活跃,没有任何设置可以关闭它。隐私政策提到收集在对话中提交的文本、文件和代码,但未提及工作空间快照上传。删除待处理存档是击打地鼠游戏——半小时后它又重新捕获,failureCount 从 564 增加到 565。修复方法是在内核级别锁定目录(Linux 上使用 chattr +i,macOS 上使用 chflags uchg),这接受的权衡是破坏了检查点回滚 UI。正常的聊天、自动补全和工具执行继续正常工作。
整个事件更有趣的是谁发布的。昨天的汇总报道中,Zhipu 真实地介绍了在国产加速器上构建 GLM 推理的写实——一家展示真实工程严谨性的公司。今天,该公司发布的桌面应用上传了用户无法解密的仓库,使用的是供应商持有的密钥,并且开关的含义与其标签不符。
通过线
这批报道中的每一个都关乎用户认为自己持有的某物的控制权。
密码凭证并没有消除账户中最薄弱的恢复路径,而是将其转移——而在当前的生态系统中,你所依赖的是供应商的同步服务或你无法备份的密钥。ZCode 将你的仓库历史打包成只有其服务器可以读取的密文,并将关闭开关的标签与实际含义不符。聊天机器人在军事情报管道中拥有结论,而格式的权威性在验证步骤中得以保留。Cloudflare 的快速隧道拥有主机名和边缘,而页面对其暴露程度的自信正是它不记录的地方。OpenAI 的论坛,尽管不是人们认为是 OpenAI 攻击面的产品,但却是进入内部代码库的门,因为 SSO 就是将“哪个服务”简化为“哪个身份”。
读起来乐观的故事是那些保持不变量明确的故事。jemalloc 的四年延迟发布是一堆 bug 修复和技术债务,这正是一个记录了自己不兼容变化的项目的样子——而 tcache 政策变化之所以可怕而不是恶意,是因为它被写入了发布说明。同样,写作建议之所以有效,是因为人类保持了对声音和判断的所有权,而一旦允许模型拥有其中任何一个,它就会变成一种负担。新技术不会消除做出决策的人的责任。上述失败都是同一个错误——将工具的信心视为你自己的替代品。