一个网页能卡住 Mac 桌面，WebGPU 暴露的是共享资源边界
据研究者 Auberon López 的 Deathray 披露，特制 WebGPU 工作负载可令其测试的 M 系列 MacBook 在 macOS Tahoe 上失去正常桌面响应，Chrome、Firefox 与 Safari 均可复现。这里描述的是研究者报告的测试范围，不能扩展成所有 Mac、所有版本均受影响。
作者：韩启明｜OC 政策与安全编辑
据研究者 Auberon López 的 Deathray 披露，特制 WebGPU 工作负载可令其测试的 M 系列 MacBook 在 macOS Tahoe 上失去正常桌面响应，Chrome、Firefox 与 Safari 均可复现。这里描述的是研究者报告的测试范围，不能扩展成所有 Mac、所有版本均受影响。
一句话结论：网页没有读走文件，也可能通过争用共享 GPU 破坏可用性；浏览器隔离需要限制的不只有访问权限，还有资源占用对系统其他部分的影响。
标签页关不掉时，隔离的直觉就失效了
普通用户通常相信，一个网页最多让自己的标签页卡住。这个直觉来自现代浏览器把不同页面放进隔离环境的经验。
但进程隔离并不意味着底层资源完全独立。浏览器可以把计算交给 GPU，桌面窗口系统也依赖 GPU。若一个任务无法被及时打断，其他消费者即使没有共享地址空间，也可能一起等待。
研究者报告，问题发生时系统的其他部分未必全部停止，远程连接仍可能可用；受影响的核心是图形交互，随后看门狗可能触发重启。因此，“整台电脑彻底停止运行”也不是准确概括。
对于用户，可用性损失却是真实的：当前工作被打断，桌面无法操作，尚未保存的状态可能面临风险。技术上属于哪一类故障，不会自动消除这种影响。
WebGPU 的能力扩大了，也需要相应的调度边界
WebGPU 让网页获得更现代的图形与计算接口，能支持复杂渲染和本地计算。这种能力本身不是问题，关键在于不可信工作负载如何与系统其他任务共享资源。
研究者将现象解释为计算任务持续占用资源，使依赖它的图形工作无法继续，并影响 WindowServer。这一解释仍有待独立测量与完整驱动分析验证。
更一般的工程要求是：系统应该能对超时任务进行隔离、抢占或恢复，并尽量避免把一个来源的问题扩散到其他进程。输入检查有用，却不应是唯一的保护层。
为什么不能把它写成“网页接管电脑”
拒绝服务、任意代码执行、越过沙箱和数据泄露是不同问题。当前披露支持的是图形可用性受损，不能据此推导出攻击者能读取密码、修改任意文件或控制系统。
这种区分对用户很重要。夸大影响会制造错误恐慌，也会让真正需要处理的资源隔离问题被淹没在耸动标题里。
同时，不属于更严重的攻击类别，也不意味着无需修复。可用性是用户信任的一部分，低交互门槛的故障尤其容易被恶作剧或恶意链接利用。
安全定级争议，应按各自说法记录
作者表示已向 Apple 报告，随后收到将其视为潜在改进而非安全问题的回复。这里能确认的是作者公开了这段沟通叙述，不能把作者对修复优先级的推测写成 Apple 已公布的计划。
厂商可能按自己的标准区分安全漏洞与可靠性问题，研究者和用户则可能从实际可用性理解风险。讨论应聚焦影响与修复机制，而不是因为名称不同就认为一方必然没有依据。
后续需要关注的，是具体系统版本是否改变了行为、厂商是否发布可核验说明，以及修复是否覆盖相似工作负载，而不只是挡住单个演示。
没有必要在工作机器上验证它有多真
原页面包含会触发问题的演示入口。对普通读者，阅读披露并不需要运行演示，更不应把它转发为让朋友“试试看”的链接。
如果已经遭遇浏览器或系统异常，应保留工作、正常处理恢复，并注意浏览器恢复会话是否重新打开同一页面。不要把反复触发故障当作排查的必经步骤。
对软件团队，相关测试应放在专门环境并获得明确授权。重点是测出隔离与恢复能力，而不是在真实用户设备上收集失败样本。
关键事实
- 证据来自研究者披露，测试集中在 M 系列 MacBook 与 Tahoe。
- 报告称多个浏览器可触发图形桌面失去响应。
- 可用性问题不等于任意代码执行或数据泄露。
- 厂商沟通与修复状态应以可核查的新信息继续跟进。
OC 判断
当网页获得更多本地计算能力，平台就必须把资源治理做得更具体。用户不应该为了信任浏览器而先学会 GPU 调度；这一层复杂度，理应由浏览器、驱动与系统共同承担。
为什么重要
- 对开发者：权限隔离与资源隔离需要同时考虑。
- 对平台：恢复机制应控制故障扩散范围。
- 对用户：不要运行可能导致系统冻结的演示来验证新闻。
评论
围绕这篇文章补充信息、提出问题或分享观察。