AI 摘要：Chrome 137 Beta 版本引入了多项 CSS/UI 增强（如条件函数 if()、阅读流属性、SVG 变换支持）和 Web API 改进（如 WebAuthn 错误对齐、Blob URL 分区、WebAssembly 分支提示），并新增了 4 项 Origin Trials（全帧率渲染阻塞、非渲染 iframe 媒体暂停等）。此外，还扩展了系统强调色支持至 Windows/ChromeOS，优化了开发者工具链。

1. CSS 和 UI 更新
• if() 函数：支持条件值表达式，简化复杂逻辑。
• 阅读流属性：reading-flow 和 reading-order 控制无障碍工具的元素顺序。
• SVG 增强：
• 支持 transform 属性直接应用于 <svg> 根元素。
• <use> 元素可省略片段引用外部文档根元素。
• 系统强调色：accent-color 扩展支持 Windows 和 ChromeOS。
• 视图过渡：view-transition-name: match-element 为单页应用提供动画支持。

2. Web API 改进
• WebAuthn：统一支付凭证创建时的错误类型为 NotAllowedError。
• Blob URL 分区：按存储键（站点、来源等）分区访问，提升安全性。
• 崩溃报告：捕获未响应页面的 JavaScript 调用栈。
• Canvas：支持浮点像素格式，适用于高精度场景。
• Web Cryptography：新增 Ed25519 曲线算法支持。
• WebGPU：
• 允许 GPUTextureView 用于 externalTexture 绑定。
• 简化 copyBufferToBuffer 方法的重载。

3. 新增 Origin Trials
• 全帧率渲染阻塞：通过 full-frame-rate 令牌降低渲染帧率以优化资源分配。
• 非渲染 iframe 媒体暂停：通过权限策略控制不可见 iframe 的媒体播放。
• Rewriter/Writer API：基于设备端 AI 模型实现文本改写与生成功能。

Chrome for Developers

Chrome 137 beta  |  Blog  |  Chrome for Developers

Discover what's coming to Chrome with the latest beta.

AI 摘要：本期 Web Weekly 聚焦前端开发领域的新提案、工具优化与实用技巧，涵盖 Edge 团队的 ariaNotify() 和 console.context() 提案、Node.js 双包风险、CSS 新单位 lh 的应用，以及 Chrome 原生 CSS 轮播的可访问性分析。同时推荐了有趣的 CSS 全息效果、小众浏览器和 JavaScript Set 新方法等资源。

1. Edge 团队新提案
• document.ariaNotify() ：简化无障碍通知的 DOM 操作，直接通过 JavaScript 触发屏幕阅读器提示。
• console.context() ：提供日志分组、样式和过滤功能，优化调试体验。

2. Node.js 双包风险警告
• 官方建议仅发布一种模块格式（CJS 或 ESM），避免因混合格式导致的兼容性问题。

3. CSS 新特性与实践
• lh 单位：基于行高的垂直间距控制，提升视觉一致性。
• Chrome 原生 CSS 轮播：新增 scroll-marker-group 等属性，但当前可访问性不足（Sara 评估，她的结论是：他们还没有准备好，但你自己要多读一读）。
• 纯 CSS 全息效果：纯 CSS 实现，利用 mix-blend-mode 和 background-attachment 实现。 解释博客

4. JavaScript 更新
• JavaScript Set 新方法：difference()、intersection() 等集合操作。
• JavaScript 类中的静态初始化块 - 不久前，我了解到您可以将 "nameless static " 块放入 ECMAScript 类中。他们是做什么的？
• RegExp.escape()：自动转义正则表达式特殊字符（Chromium 136+）。

5. 工具与资源推荐
• 小众浏览器：Vivaldi 及其他非主流选项。
• 自然语言日期解析库 wanasit/chrono
• Node.js 测试最佳实践指南 #测试
• MCP 服务器的集合 punkpeye/awesome-mcp-servers 。 #AI #MCP

6. 其他亮点
• 趣味网站：owlsintowels.org（猫头鹰主题）。
• 设计技巧：复杂曲线边框的 CSS 实现方案。
• My Three Strikes Rule for Blogging 第三次在对话中使用某个想法时，您必须将其写在博客上。 #技术写作

Stefanjudis

Web Weekly #158

The `ariaNotify()` and `console.context()` proposals from the Edge team, Node.js dual package hazards and `lh` CSS unit use cases.

AI 摘要：本文深入探讨了传统双因素认证（2FA）的漏洞（如钓鱼攻击风险），并介绍了更安全的替代方案——通行密钥（Passkeys）。文章通过 WhatsApp、LinkedIn 和 Ubiquiti 的实际案例，详细解析了通行密钥的设置流程、优势（如防钓鱼、跨设备同步）和局限性（如服务间实现差异），并进一步探讨了物理安全密钥（如 YubiKey）的强化作用。最后，作者呼吁用户尽早采用通行密钥，并推动更多服务支持这一技术。

1. 传统 2FA 的漏洞
• 问题描述：通过模拟 Mailchimp 钓鱼攻击案例，说明即使启用 2FA（如验证码），攻击者仍可诱导用户提交动态密码（OTP），从而入侵账户。
• 核心缺陷：OTP 和短信验证码可被钓鱼，无法从根本上抵御社会工程攻击。

2. 通行密钥（Passkeys）的解决方案
• 定义：基于加密技术的数字凭证，存储在设备或密码管理器中，无需手动输入。
• 优势：
• 防钓鱼：密钥与域名绑定，无法被伪造网站窃取。
• 便捷性：支持生物识别（如 Face ID）一键登录。
• 跨设备同步：可通过 iCloud、1Password 等工具多端共享。

3. 通行密钥实践案例
• WhatsApp（移动端）：
• 设置流程：通过 iPhone 的 iCloud Keychain 或 1Password 存储密钥。
• 局限性：部分服务（如 WhatsApp）未提供明确的登录测试路径。
• LinkedIn（PC 端）：
• 混合验证模式：通行密钥与密码共存，仍保留可被钓鱼的 OTP 2FA。
• 用户体验：1Password 自动填充密钥实现秒级登录。
• Ubiquiti（强化 2FA）：
• 完全替代 OTP：通行密钥作为唯一 2FA 方式，支持物理安全密钥（YubiKey）。
• 安全升级：移除邮箱验证，降低中间人攻击风险。

4. 物理安全密钥（U2F）
• 原理：如 YubiKey 通过 USB/NFC 存储通行密钥，需物理接触才能使用。
• 优势：
• 抵御远程攻击：即使密码管理器被入侵，物理密钥仍可保护账户。
• 冗余设计：建议配置多个密钥以防丢失。

5. 通行密钥的推广现状
• 支持平台：1Password 的 passkeys.directory 列出已支持的服务（如 Google、Microsoft）。
• 用户行动建议：
• 优先为关键账户（如邮箱、银行）启用通行密钥。
• 向未支持的服务（如 Twitter）投票施压。

6. 总结与展望
• 防御纵深：通行密钥需与其他安全实践（如警惕钓鱼邮件、使用密码管理器）结合。
• 行业趋势：微软已默认启用无密码登录，通行密钥普及临近拐点。

Troy Hunt

Passkeys for Normal People

Let me start by very simply explaining the problem we're trying to solve with passkeys. Imagine you're logging on to a website like this: