Chrome – mylogs.cn https://mylogs.cn 发现、记录、分享 Wed, 12 Aug 2026 02:24:26 +0000 zh-Hans hourly 1 Chrome 上线防盗号新机制：把登录凭证焊死在芯片里 https://mylogs.cn/chrome-device-bound-session-credentials/ Wed, 12 Aug 2026 02:24:10 +0000 https://mylogs.cn/chrome-device-bound-session-credentials/ 谷歌 Chrome 浏览器近日上线了一项新功能，有望显著遏制一种随着双因素认证普及而愈发常见的盗号手段。这项功能名为「设备绑定会话凭证」（Device-Bound Session Credentials，简称 DBSC），它把保护登录身份的密钥直接锁进了用户设备里的硬件安全芯片。

Chrome 上线防盗号新机制：把登录凭证焊死在芯片里
图片来源：Wikimedia Commons

在双因素认证、通行密钥等更强验证方式普及之后，单纯靠偷密码已经很难得手，攻击者于是把目标转向了「会话 Cookie」。网站为了省去每次刷新都重新验证的麻烦，会把一段代表「已登录」的字符串存在浏览器里，这就是会话 Cookie。一旦这段 Cookie 被窃走，攻击者把它粘贴进自己的浏览器，就能在有效期内顶替原主人的身份。

把私钥焊死在芯片里

DBSC 的思路，是将会话凭证的加密密钥存放在设备内置的一处「硬件堡垒」中。在 Windows 上，这处堡垒叫 TPM（可信平台模块）；在 macOS 与 iOS 上，它叫安全隔区（Secure Enclave）；其他平台也有各自的名称。近期发布的 Windows 版 Chrome 147 与 macOS 版 Chrome 150，已经能够在这类芯片里生成并保存密钥。

它的工作逻辑和通行密钥相似：网站服务端只保存用户的公钥，并在下发会话 Cookie 时附带一个验证挑战；浏览器必须用存放在 TPM 或安全隔区里的私钥对挑战签名，服务端才会认可。由于硬件会把私钥隔离起来、拒绝将其导出，攻击者即便偷走了 Cookie，也无法用私钥完成签名应答，自然无法冒用身份。

安全研究者、Report URI 创始人 Scott Helme 在个人博客中评价说：「攻击者无法从设备里偷走私钥，这正是核心保护所在。他能偷走 Cookie，却无法用仍安全地留在你设备上的私钥去应答 DBSC 挑战。」

目前仍是灰度测试

需要留意的是，DBSC 眼下并非全面开放。它仅出现在 Windows 版 Chrome 147 与 macOS 版 Chrome 150 中，而且只对一部分用户开启，外界判断谷歌仍在小范围灰度测试。用户若想确认自己的浏览器是否已启用，可以打开开发者工具，切到「应用」标签向下滚动——当登录到支持 DBSC 的网站时，若保护已开启，就会看到「设备绑定会话」的字样。

至于其他基于 Chromium 内核的浏览器是否会跟进，目前尚不清楚，但业界普遍预期只是时间问题。Chrome 安全团队提醒，会话 Cookie 窃取类攻击（包括信息窃取木马与中间人攻击）近年来明显上升，DBSC 是继通行密钥之后，又一层「不依赖共享密钥」的身份验证思路，目的都是让攻击者更难把用户的登录身份整个搬走。

来源：Ars Technica（作者 Dan Goodin，2026 年 8 月 11 日）

]]> 不用写一行代码，给网站装上 AI 代理专用接口 https://mylogs.cn/cloudflare-webmcp-developer-preview/ https://mylogs.cn/cloudflare-webmcp-developer-preview/#respond Fri, 07 Aug 2026 10:15:04 +0000 https://mylogs.cn/cloudflare-webmcp-developer-preview/ 互联网最初是按「屏幕对面坐着一个人」来设计的：有人阅读页面、点击按钮、填写表单。但如今，越来越多的访问来自 AI 代理，而它们面对的仍是一个为人类打造的网络。

不用写一行代码，给网站装上 AI 代理专用接口
图片来源：Cloudflare

Cloudflare 在 8 月 6 日推出了 WebMCP 的开发者预览版，试图改变这一局面：网站只需在控制台里打开一个开关，无需编写任何代码，也不改动源站，浏览器中的 AI 代理就能直接调用这个网站提供的工具。Cloudflare 会向页面注入一个轻量桥接层，为访客的代理注册一套可用工具集。

从「爬」到「调用」

过去，AI 获取网站内容的通行做法是爬虫抓取：把内容复制回自己的服务器，往往既不给原网站带去流量，也不留下多少署名。Cloudflare 认为存在一条更好的路径，而且这条路径不需要爬取。

WebMCP 是一项新的浏览器标准，目前已在 Chrome 146 中实验性上线，在页面里以 document.modelContext 的形式呈现。网站可以主动向浏览器内运行的代理暴露一组工具，代理就不必再对着为人类设计的页面元素反复猜测。这样一来，代理的浏览体验可以与人类用户完全不同，token 花在真正要完成的任务上，而不是消耗在无谓的页面导航中。唯一的门槛在于：网站必须自己去实现它。

Cloudflare 一直在这条链路的两端同时布局。其远程浏览器 BrowserRun 已支持 WebMCP，代理可以发现并调用网站暴露的工具；Cloudflare Radar 也即将提供自己的 WebMCP 工具。这次的预览版针对的是另一端——让任何托管在 Cloudflare 上的网站，通过一个开关、零代码就获得这些能力。

技术实现：边缘注入加浏览器桥接

手动实现 WebMCP 本身就是一个不小的工程：需要设计要暴露哪些工具、把它们接入现有界面，还要随着标准演进持续维护。Cloudflare 的目标是把这件事简化成拨动一个设置开关。

这些工具以「工具包」（pack）的形式组织，相关工具可以整体启用。工具包的设计考虑了扩展性：随着 Cloudflare 陆续增加新包，网站只需打开开关即可接入更多能力，无需重新部署。当前开发者预览版包含两个工具包，两者都完全在浏览器中运行。

整套实现由两部分组成，均位于源站之前，不触碰网站自身代码，且对静态站点和单页应用一视同仁。

第一部分是边缘注入。当网站在 Cloudflare 控制台中开启 WebMCP 后，Cloudflare 使用 HTMLRewriter 在每个 HTML 响应中添加一行内容——一个指向桥接脚本的引用。标签和它加载的脚本都来自边缘节点、同源提供，页面的其他部分保持原样：

<script
  type="module"
  src="/.webmcp/bridge.js"
  data-packs="c2pa,mcp-server-client"
  data-mcp-url="/mcp"></script>

其中 data-packs 属性列出要激活的工具包。如果网站已有自建的 MCP（Model Context Protocol，模型上下文协议）服务器，data-mcp-url 就指向该服务器，默认为同源的 /mcp 路径。

第二部分是桥接层。它在页面中运行，负责寻找 WebMCP 接口。如果浏览器不支持该接口，脚本直接返回、什么也不做，页面行为与之前完全一致。

找到接口后，桥接层会把 data-packs 中列出的工具包合成一份工具清单，逐个通过 .registerTool 注册。一个工具包就是一组 MCP 工具描述符及其处理函数。像内容凭证包这样的静态包会预先声明自己的工具；而像站点 MCP 服务器包这样的动态包，则在启动时先发现工具，再进行注册。

在当前预览版中，每个工具都完全在访客的浏览器内运行，不存在向 Cloudflare 服务器的往返请求。内容凭证包在本地抓取图片并解析其前几 KB 的内容溯源元数据；站点 MCP 服务器包则从页面直接与网站的 MCP 服务器端点通信，使用访客所在的源和其已有的会话。

桥接层代码由运行在边缘的 Worker 提供。Cloudflare 表示这为后续扩展留出了空间——未来的工具包将能够调用这个 Worker，去完成页面自身无法独立完成的任务，比如用 Workers AI 总结站点地图，或查询 AI 搜索索引。

对代理而言，这些都只是普通的 MCP 工具。Cloudflare 直接沿用了 Model Context Protocol 自身的 Tool 和 CallToolResult 类型，因此一个已经能与 MCP 服务器对话的代理，不需要任何额外改造就能驱动页面。用 Cloudflare 的说法：浏览器只是 MCP 运行的又一个场所。

两个预览工具包

内容凭证包用于读取图片的溯源元数据，服务于 C2PA 内容凭证计划的参与方。其中 scan_images_c2pa 会扫描页面上的每一张图片，返回一份简短摘要，包含图片总数、已扫描数量、带有 C2PA 信息的数量，以及每张图的格式、声明生成方（例如 Adobe Firefly）、标题和签名者等字段。若需要更细致的信息，inspect_image_c2pa 可以解码单张图片的完整清单，包括编辑历史、声明的作者以及签名证书。

另一个是站点 MCP 服务器包。它会读取网站自有 MCP 服务器通过 tools/list 公布的每一个工具，为其注册一个代理封装。当代理调用该工具时，封装函数会以同源方式向 /mcp 发起 POST 请求，携带访客现有的会话凭据，并将返回的 CallToolResult 原样传回。

对站点运营者来说，这一变化的实际意义在于 AI 流量的处理方式：代理不必再从原始 HTML 中反推网站意图，而是可以调用结构化工具、拿到准确且符合预期的结果，同时保留会话上下文，网站方也能完整看到代理的交互行为。

WebMCP 采用 MCP 2026-07-28 版本规范，该版本将协议从有状态的会话管理转向基于 Streamable HTTP 的无状态模型，代理通过标准 POST 请求调用工具，用 Mcp-Method 和 Mcp-Name 请求头路由指令，从而更适合在边缘基础设施上横向扩展。

需要注意的是，这仍是开发者预览版，WebMCP 标准本身在 Chrome 中也处于实验阶段。站点运营者可以将 BrowserRun 指向自己的域名，查看代理究竟会发现哪些工具、又会如何调用它们，然后再决定是否放行生产流量。

来源：Cloudflare 官方博客、Cloudflare Browser Run 开发者文档

]]> https://mylogs.cn/cloudflare-webmcp-developer-preview/feed/ 0 别再瞎关标签页，按一下就知道谁吃内存 https://mylogs.cn/%e5%88%ab%e5%86%8d%e7%9e%8e%e5%85%b3%e6%a0%87%e7%ad%be%e9%a1%b5%ef%bc%8c%e6%8c%89%e4%b8%80%e4%b8%8b%e5%b0%b1%e7%9f%a5%e9%81%93%e8%b0%81%e5%90%83%e5%86%85%e5%ad%98/ https://mylogs.cn/%e5%88%ab%e5%86%8d%e7%9e%8e%e5%85%b3%e6%a0%87%e7%ad%be%e9%a1%b5%ef%bc%8c%e6%8c%89%e4%b8%80%e4%b8%8b%e5%b0%b1%e7%9f%a5%e9%81%93%e8%b0%81%e5%90%83%e5%86%85%e5%ad%98/#respond Thu, 06 Aug 2026 04:57:15 +0000 https://mylogs.cn/%e5%88%ab%e5%86%8d%e7%9e%8e%e5%85%b3%e6%a0%87%e7%ad%be%e9%a1%b5%ef%bc%8c%e6%8c%89%e4%b8%80%e4%b8%8b%e5%b0%b1%e7%9f%a5%e9%81%93%e8%b0%81%e5%90%83%e5%86%85%e5%ad%98/ 你开了二十来个标签页，切换开始卡半秒，打开系统任务管理器一看——一排一模一样的”Google Chrome”进程，谁也认不出是谁。MakeUseOf 撰稿人 Robin John 以前只能随手关几个标签碰运气，直到发现浏览器自带一个任务管理器，每一项都标了名字。

别再瞎关标签页，按一下就知道谁吃内存
图片来源：Robin John / MakeUseOf

快捷键是 Shift + Esc（Chrome 在当前窗口时按）。被别的软件占用了的话，从右上角三个点 → 更多工具也能打开，Mac 上在”窗口”菜单下。它显示的是网页真实标题和扩展真实名称，右边跟着内存数字，点”内存占用量”这一列排序，几秒钟就知道谁最能吃。

真正的意外通常是扩展。 Robin John 排序后发现，一个密码管理器、一个语法检查器加一个广告拦截器，三个加起来比他实际打开的十个网页还多。扩展整个会话期间一直在跑，有些还往每个页面注入脚本——标签页越多开销越大，列表里却只占一行。

右键点表头可以再加两列：JavaScript 内存能看出哪个网页应用自己在堆里屯东西，空闲唤醒次数对笔记本尤其有用，某个进程在后台不停唤醒，内存看着正常，电量照样掉。设一次 Chrome 就记住了。

选中一行点”结束进程”，只干掉那一个标签或扩展，标签还留在栏上显示错误页，刷新就回来。某个页面卡死时，这比整个浏览器强退划算得多。

注意这里的数字一直在动，同一标签隔三十秒读数就不同，也和系统显示的总占用对不上。它擅长揪异常值，不适合精确测量。

我的判断是，它真正的价值是把”关标签页”从玄学变成有据可依。视频站排在前面很正常，但一篇两小时前打开、你早忘了的新闻页，数字还在往上爬，那多半是内存泄漏。

来源：MakeUseOf

]]> https://mylogs.cn/%e5%88%ab%e5%86%8d%e7%9e%8e%e5%85%b3%e6%a0%87%e7%ad%be%e9%a1%b5%ef%bc%8c%e6%8c%89%e4%b8%80%e4%b8%8b%e5%b0%b1%e7%9f%a5%e9%81%93%e8%b0%81%e5%90%83%e5%86%85%e5%ad%98/feed/ 0 网页慢了四秒，凶手藏在浏览器里 https://mylogs.cn/%e7%bd%91%e9%a1%b5%e6%85%a2%e4%ba%86%e5%9b%9b%e7%a7%92%ef%bc%8c%e5%87%b6%e6%89%8b%e8%97%8f%e5%9c%a8%e6%b5%8f%e8%a7%88%e5%99%a8%e9%87%8c/ https://mylogs.cn/%e7%bd%91%e9%a1%b5%e6%85%a2%e4%ba%86%e5%9b%9b%e7%a7%92%ef%bc%8c%e5%87%b6%e6%89%8b%e8%97%8f%e5%9c%a8%e6%b5%8f%e8%a7%88%e5%99%a8%e9%87%8c/#respond Wed, 05 Aug 2026 13:11:18 +0000 https://mylogs.cn/%e7%bd%91%e9%a1%b5%e6%85%a2%e4%ba%86%e5%9b%9b%e7%a7%92%ef%bc%8c%e5%87%b6%e6%89%8b%e8%97%8f%e5%9c%a8%e6%b5%8f%e8%a7%88%e5%99%a8%e9%87%8c/ 网页打开得慢，你大概率会怪两件事：网不行，或者这站本身卡。MakeUseOf 撰稿人 Pankil Shah 原本也这么想，直到用 Chrome 自带的工具测了一遍，发现拖后腿的是浏览器自己——每个页面平均慢四秒。

网页慢了四秒，凶手藏在浏览器里
图片来源：MakeUseOf

开发者工具里藏着一台体检仪

那个工具叫 Lighthouse，是谷歌开源的页面审计工具。它会重新加载页面，记录各部分出现的耗时，给出性能评分，并列出谁在拖慢：渲染阻塞脚本、第三方跟踪代码，还是浏览器扩展。

用法很简单：

  1. 打开要测的页面，按 F12 调出开发者工具；
  2. 找到 Lighthouse 标签（找不到就先点 >> 展开）；
  3. 点「Analyze page load」，等约 30 秒出报告。

报告最上面是性能评分，低于 50 属于糟糕。往下的 Speed Index 表示页面完全呈现花了几秒。单次结果参考价值有限，多测几个常去的站再下结论。

关键一步：普通窗口和无痕窗口各测一次

无痕窗口默认不加载扩展，两边差值就是扩展的账。Pankil Shah 测下来平均差出四秒，报告直接点了名。他装的广告拦截、Cookie 弹窗关闭、强制深色模式，每个只加几十毫秒，叠起来就是四秒。

接下来在地址栏输入 chrome://extensions，把不再需要的挨个停用——他关掉了深色模式、Vimium、Volume Master、标签页会话管理等几项，每关一个重跑一次测试，收益看得很清楚。

说白了，扩展是那种「装的时候顺手，之后再想不起来」的东西。另有两件 Lighthouse 测不出但同样有效的事：清一次浏览器缓存，换掉运营商默认的 DNS。

今晚就按 F12 测一测你最常开的那个网站，看看四秒里有几秒是自己加上去的。

来源：MakeUseOf

]]> https://mylogs.cn/%e7%bd%91%e9%a1%b5%e6%85%a2%e4%ba%86%e5%9b%9b%e7%a7%92%ef%bc%8c%e5%87%b6%e6%89%8b%e8%97%8f%e5%9c%a8%e6%b5%8f%e8%a7%88%e5%99%a8%e9%87%8c/feed/ 0 AI花60天，揪出1072个Chrome漏洞 https://mylogs.cn/ai%e8%8a%b160%e5%a4%a9%ef%bc%8c%e6%8f%aa%e5%87%ba1072%e4%b8%aachrome%e6%bc%8f%e6%b4%9e/ https://mylogs.cn/ai%e8%8a%b160%e5%a4%a9%ef%bc%8c%e6%8f%aa%e5%87%ba1072%e4%b8%aachrome%e6%bc%8f%e6%b4%9e/#respond Mon, 03 Aug 2026 23:54:17 +0000 https://mylogs.cn/ai%e8%8a%b160%e5%a4%a9%ef%bc%8c%e6%8f%aa%e5%87%ba1072%e4%b8%aachrome%e6%bc%8f%e6%b4%9e/ 你每天在用的浏览器，刚刚经历了一场史上最密集的漏洞清理。Chrome 安全团队公布的数字是：在 M149 和 M150 两个版本里，一共修掉 1072 个安全漏洞，比此前 23 个版本修掉的总和还多。而在 2024 年 8 月发布的 M128 版本，这个数字还只有四五十个。

AI花60天，揪出1072个Chrome漏洞
图片来源：NurPhoto / Getty Images

变量是 AI。谷歌在 2026 年上线了一套基于 Gemini 的智能体框架，专门在整个 Chrome 代码库里翻找漏洞。最典型的战果，是一个从 2013 年就存在的沙箱逃逸漏洞——它能骗浏览器去读取本地文件，十几年里躲过了一轮又一轮测试，今年初被 AI 挖了出来。谷歌还把漏洞处理拆成四段流水线：先让智能体过滤掉重复和无效的报告，再在对应系统的虚拟环境里复现问题、补上调用栈信息，把最耗人力的环节交给机器。

Chrome 全球约有 35 亿活跃用户、七成多的浏览器份额，修得越快，风险窗口就越短，甚至可能需要一周发两次补丁。

我的判断是，这条消息真正的重点不在「谷歌很努力」，而在另一面：AI 能这么高效地找出漏洞，攻击者手里的 AI 同样能。谷歌先发现的那批，未必就是别人正在利用的那批。

所以最实在的动作只有一个：别再拖着那个「重启以完成更新」的提示不点。你的浏览器，多久没重启过了？

来源：ZDNET

]]> https://mylogs.cn/ai%e8%8a%b160%e5%a4%a9%ef%bc%8c%e6%8f%aa%e5%87%ba1072%e4%b8%aachrome%e6%bc%8f%e6%b4%9e/feed/ 0 谷歌用 AI 一个月修 1072 个漏洞，比过去两年还多 https://mylogs.cn/%e8%b0%b7%e6%ad%8c%e7%94%a8-ai-%e4%b8%80%e4%b8%aa%e6%9c%88%e4%bf%ae-1072-%e4%b8%aa%e6%bc%8f%e6%b4%9e%ef%bc%8c%e6%af%94%e8%bf%87%e5%8e%bb%e4%b8%a4%e5%b9%b4%e8%bf%98%e5%a4%9a/ Sun, 02 Aug 2026 03:23:59 +0000 https://mylogs.cn/%e8%b0%b7%e6%ad%8c%e7%94%a8-ai-%e4%b8%80%e4%b8%aa%e6%9c%88%e4%bf%ae-1072-%e4%b8%aa%e6%bc%8f%e6%b4%9e%ef%bc%8c%e6%af%94%e8%bf%87%e5%8e%bb%e4%b8%a4%e5%b9%b4%e8%bf%98%e5%a4%9a/ 十年前，Chrome 每六周推送一次安全补丁，这个频率在当时还引起过争议。如今这套节奏被彻底改写——谷歌正在试点每周推送两次安全修复，原因不是浏览器突然变脆弱了，而是 AI 挖漏洞的速度已经快到让人跟不上。

谷歌用 AI 一个月修 1072 个漏洞，比过去两年还多
图片来源：WIRED

两个版本，1072 个漏洞

Chrome 安全团队在 7 月 30 日发布的报告中给出了一组扎眼的数字：6 月发布的两个大版本 Chrome 149 与 Chrome 150，合计修复了 1072 个安全漏洞。作为对照，此前两年发布的 23 个版本加在一起，修复总数为 1036 个。换句话说，两个版本干完的活，超过了过去两年的总和。

这些漏洞中确实有一部分来自外部研究者提交，但激增的主因是 Chrome 安全团队内部流程的快速演进——他们把 AI 工具全面接入了漏洞发现、分级和补丁开发的每一个环节。

“在 Chrome，我们从 2012 年起就在用机器学习——在它还没被叫作 AI 的时候——来辅助发现漏洞、自动化模糊测试工作。这一直是我们发现漏洞、赋能开发者的重要手段。”Chrome 副总裁兼总经理帕丽萨·塔布里兹（Parisa Tabriz）表示，”但今年确实很不一样。无论进攻还是防守，都真切地到了一个拐点。”

从两周一次到每周两次

Chrome 原本已经在向”每两周一个大版本、外加每周一次安全更新”的节奏靠拢。但漏洞发现的密度实在太高，团队把新模型和新能力接入工作流后成效又太显著，最终决定试点每周推送两次安全修复。

“我们走到这一步的原因很简单：修复实在太多了。所以在这段时间里每周提供两次更新，对我们来说最合理。”Chrome 工程总监道格·特纳（Doug Turner）说，”会不会一直这样？谁知道呢。”

特纳向外界解释了这套系统为什么这么能挖。谷歌训练的模型掌握了两类关键知识：一是历史上出现过的每一个安全漏洞编号，二是 Chromium 代码库全部提交历史中每一行代码被修改的原因。

“我们训练模型，让它了解我们过去见过的每一个安全漏洞，”特纳说，”第二件很酷的事情是，Chromium 历史上的每一行代码，模型都知道它当初为什么被改。”

这套上下文让 AI 工具能在 Chrome 这个庞大复杂的代码库里精准锁定潜在弱点，包括那些早已不再活跃开发、也很少有人再去审视的功能模块——比如打印功能。

一个藏了 13 年的沙箱逃逸

公开资料显示，谷歌在 2026 年初部署了基于 Gemini 构建的智能体框架，扫描范围覆盖整个 Chrome 代码库，而不再局限于模糊测试能触达的代码路径。这套框架支持开放权重模型与闭源模型协同工作，会多轮运行以抵消模型输出的不确定性，并调用一个由 Chromium 全部版本历史和历史漏洞构成的知识库。

其中最引人注目的一项发现，是一个在代码库里静静躺了 13 年多的沙箱逃逸漏洞。该缺陷可让被攻陷的渲染进程绕过隔离机制，诱使浏览器读取用户本地的文件。它之所以能存活这么久，并非因为多么隐蔽，而是传统安全审查要么从正在变动的代码入手，要么依赖能触发崩溃的输入，要么等外部研究者上报——没有哪一种方法是为”把 13 年前的老代码重新翻一遍”设计的。

此外，谷歌 DeepMind 与 Project Zero 合作的 BigSleep 项目，以及自动修复工具 CodeMender，如今已原生嵌入 Chrome 的持续集成系统，每 24 小时对全球开发者提交的所有代码变更跑一遍。仅 2026 年 5 月一个月，这套集成就拦下了 20 多个漏洞，其中包括一个被评为最高严重级别的缺陷。

不只是谷歌

同样的趋势正在其他厂商身上出现。微软本月早些时候宣布，在例行的”补丁星期二”更新中，一次性修复了创纪录的 570 个安全漏洞，并将激增归因于内部对 AI 的使用。苹果则暂未出现类似的指数级增长——独立统计显示，苹果 2026 年至今修复了 482 个漏洞，大致与去年持平，也和 2015 年的水平相当。

这波浪潮会持续多久

特纳和其他安全研究者都认为，AI 带来的漏洞发现狂潮未必是永久状态。至少对 Chrome 这类成熟稳定的产品而言，等到 AI 能找出来的漏洞被清理得差不多之后，新漏洞数量会出现回落。原因之一在于，模型可以被训练成对软件项目的演进历史了如指掌。

除了这种”打地鼠”式的补丁工作，Chrome 安全团队同时把重心放在结构性改造上——例如把部分 C++ 代码用内存安全的 Rust 语言重写，从而让整类常见漏洞彻底不再成立。

“眼下有一个短期的高峰，但我认为会形成新的平衡，”塔布里兹说，”我觉得对整个行业而言，真正重要的是所有在做软件安全的人都把 AI 纳入自己的开发流程。我最大的期望是一切都变得更安全。但我不会假设一切都会自动变好，也不认为这是免费的。”

来源：WIRED《Chrome Needs Twice-a-Week Patching Thanks to AI Bug Hunting》（作者 Lily Hay Newman）；补充资料参考 TechCrunch 与谷歌安全博客公开报告

图片来源：WIRED

]]> 浏览器插件到底在看什么？四步查清楚 https://mylogs.cn/%e6%b5%8f%e8%a7%88%e5%99%a8%e6%8f%92%e4%bb%b6%e5%88%b0%e5%ba%95%e5%9c%a8%e7%9c%8b%e4%bb%80%e4%b9%88%ef%bc%9f%e5%9b%9b%e6%ad%a5%e6%9f%a5%e6%b8%85%e6%a5%9a/ Sat, 01 Aug 2026 12:24:45 +0000 https://mylogs.cn/%e6%b5%8f%e8%a7%88%e5%99%a8%e6%8f%92%e4%bb%b6%e5%88%b0%e5%ba%95%e5%9c%a8%e7%9c%8b%e4%bb%80%e4%b9%88%ef%bc%9f%e5%9b%9b%e6%ad%a5%e6%9f%a5%e6%b8%85%e6%a5%9a/ 密码管理器、购物比价、写作助手、翻译工具……浏览器扩展装着装着就有了十几个，每一个当初都有充分的安装理由。问题在于，扩展一旦装上就很少再被审视，而它们能读到的内容，往往比使用者以为的要多得多。

浏览器插件到底在看什么？四步查清楚
图片来源：MakeUseOf

MakeUseOf 撰稿人 Afam Onyimadu 在偶然翻看自己所用密码管理器的隐私政策时意识到，自己授予的数据访问权限可能已经超出了心理承受范围。于是他把工具栏上的扩展逐个查了一遍，结果大多数扩展的权限与其功能相符，但有三个”手伸得太长”，最终被卸载。他的排查方法可以直接照搬。

第一步：先看浏览器里的权限清单

  1. 在地址栏输入 chrome://extensions 打开扩展管理页面（Edge 等基于 Chromium 的浏览器路径类似）。
  2. 找到要检查的扩展，点击”详细信息”（Details）。
  3. 查看该扩展声明的权限项。

需要提醒的是，这一步只能看个大概。以 LastPass 为例，页面上只列出了两条：”读取您的浏览历史记录”和”显示通知”。这两句话既没有说明”浏览历史”具体涵盖哪些数据类型，也没有交代扩展读取页面之后会发生什么。

第二步：去读隐私政策，那里才有细节

浏览器权限说明的是扩展在技术上”可以”访问什么，隐私政策才写明开发者声称自己”会收集”什么、拿去做什么。这位撰稿人转而查阅了各扩展的官方隐私政策和 Chrome 应用商店页面上的数据披露，得到的信息完整得多：

  • LastPass： 其全球隐私声明与商店页面列出的收集类别包括网站内容、身份验证信息、用户活动、位置以及个人身份信息，远比”读取浏览历史”具体。不过其密码保险库采用零知识加密，官方无法读取其中内容。
  • Honey： 美国隐私声明（2025 年 10 月版）中列出页面浏览记录、搜索关键词、浏览或购买过的商品、交易金额，以及订单是完成还是退货；出于个性化目的，还可将这些信息与用户的 PayPal、Venmo 账户关联。
  • Rakuten： 扩展条款（2026 年 3 月版）写明，无论用户是否点击扩展图标，它都会自动收集所访问页面的信息，其中包括生成式 AI 网站。条款同时声明不收集、不存储聊天记录，功能仅限于在 AI 输出内容中识别其联盟商家的名称或域名。
  • Grammarly： 隐私政策（2026 年 7 月版）明确其在启用状态下会读取用户正在各网站输入的文字，并称会以”尽力而为”的方式排除姓名、地址、密码、支付信息等敏感字段——”尽力而为”并不是铁板钉钉的保证。

第三步：用六个问题决定去留

判断标准不该是”这个扩展危不危险”，而是”它是否还配得上这些权限”。这位撰稿人在动手卸载前，对每个扩展依次自问六个问题：

  1. 是否每周都会用到它？
  2. 它拿到的权限与它现在实际提供的功能是否相称？
  3. 浏览器自带功能是否已经能做到这件事？
  4. 能否只收窄它的权限，而不必彻底删除？
  5. 如果它明天消失了，是否会察觉？
  6. 有没有权限要求更低的替代品？

第四步：删除、收窄或替换

  • 直接删除。 Rakuten 的返现按钮使用频率不高，却在所有访问过的网站上持续记录购物车内容，性价比不成立，删掉。
  • 收窄权限。 Honey 在网购时确实有用，删除代价较大。折中做法是在扩展详情页把”网站访问权限”从”在所有网站上”改为”点击时”，这样它只在被主动点击时才运行。
  • 换成更克制的替代品。 Grammarly 对多数人来说不好替代，这位撰稿人改用了自托管的 LanguageTool Server；LastPass 的隐私政策虽无意外，他仍换成了开源可自托管的方案，让相关数据留在自己的服务器上。

需要说明的是，被卸载的扩展并非恶意软件，隐私尺度也因人而异。真正的收获是养成翻看隐私政策的习惯——多数令人不安的细节其实都白纸黑字写在里面，只是从没有人去读。

来源：MakeUseOf

]]> 靠AI找漏洞：Chrome两个月修了1072个Bug，补丁频率翻倍 https://mylogs.cn/%e9%9d%a0ai%e6%89%be%e6%bc%8f%e6%b4%9e%ef%bc%9achrome%e4%b8%a4%e4%b8%aa%e6%9c%88%e4%bf%ae%e4%ba%861072%e4%b8%aabug%ef%bc%8c%e8%a1%a5%e4%b8%81%e9%a2%91%e7%8e%87%e7%bf%bb%e5%80%8d/ Sat, 01 Aug 2026 05:21:25 +0000 https://mylogs.cn/%e9%9d%a0ai%e6%89%be%e6%bc%8f%e6%b4%9e%ef%bc%9achrome%e4%b8%a4%e4%b8%aa%e6%9c%88%e4%bf%ae%e4%ba%861072%e4%b8%aabug%ef%bc%8c%e8%a1%a5%e4%b8%81%e9%a2%91%e7%8e%87%e7%bf%bb%e5%80%8d/ 谷歌 Chrome 浏览器刚刚交出了一份令人咋舌的安全成绩单——仅 2026 年 6 月的两个大版本（Chrome 149 和 Chrome 150），就修复了 1072 个安全漏洞。这个数字超过了此前 23 个大版本修复量的总和。

靠AI找漏洞：Chrome两个月修了1072个Bug，补丁频率翻倍
图片来源：Wired

推动这一变化的不是突然涌入的大量人工报告，而是谷歌内部 AI 工具在漏洞发现领域的规模化应用。

从六年一周到一周两次

回顾 Chrome 的安全更新历史，节奏一直在加快。

十年前，Chrome 率先引入自动更新机制时，每六周发布一次安全补丁的做法还颇具争议。如今这已成为主流软件的标配。但进入 2026 年后，连这个频率也跟不上了。

Chrome 安全团队负责人帕丽萨·塔布里兹（Parisa Tabriz）在接受 Wired 采访时表示，谷歌至少从 2012 年起就开始在安全领域使用机器学习（当时还不叫”AI”），主要用于自动化模糊测试和漏洞发现。”但今年真的很不一样，”她说，”无论对攻方还是防方来说，这都是一个拐点。”

工程总监道格·特纳（Doug Turner）透露，由于漏洞修复数量激增，Chrome 团队目前正在试点每周发布两次安全更新的新节奏。”我们走到这一步是因为漏洞修复实在太多了，每周两次是目前最合理的方案，”特纳说，”这是否会永远持续？谁也不知道。”

AI 如何改变了漏洞发现

谷歌在 7 月 30 日发布的白皮书中详细介绍了这套 AI 驱动的安全系统：

发现端：团队利用 Gemini 等大语言模型构建了代理覆盖系统，能够理解 Chromium 代码库中每一行代码的历史变更原因、每一个已知 CVE（通用漏洞披露）的细节。这让 AI 工具可以精准定位潜在弱点——包括那些已经不再活跃开发的功能（比如打印模块），这些区域通常不再吸引人类安全研究者的目光。

一个典型案例是：AI 系统在 Chromium 代码库中发现了一个潜伏了 13 年的沙箱逃逸漏洞。攻击者可利用该漏洞绕过沙箱机制读取用户本地文件。这种”沉睡”多年的老漏洞，靠传统人工审计很难被发现。

排序与验证端：AI 发现漏洞后会立即介入优先级排序——过滤重复或描述不清的报告、自动生成概念验证代码并在多个操作系统上复现问题、评估严重程度并分配给对应的开发人员。这套自动化流程每月为开发者节省数百小时。

修复端：系统采用”修复代理”生成多个候选补丁，再由”批评代理”从中筛选最优方案。整个流水线已在最近的版本中大规模运转。

不只是 Chrome 的问题

Chrome 并非唯一一家因 AI 而大幅提升漏洞修复数量的公司。

微软在本月早些时候宣布，在例行的”补丁星期二”更新中一次性修复了创纪录的 570 个安全漏洞，微软同样将数量激增归因于内部 AI 工具的使用。独立统计显示，苹果 2026 年至今已修复约 482 个产品漏洞，尚未呈现同样的指数级增长。

网络安全行业此前已多次警告：AI 将以越来越快的速度发现海量软件漏洞，数量甚至可能呈指数增长。面对同样使用 AI 的恶意黑客，防御方也必须依靠 AI 来跑在对手前面。

补丁疲劳与新平衡

更频繁的补丁意味着用户需要更频繁地重启浏览器。为了缓解这个问题，谷歌正在探索多项技术：

  • 缩短主版本周期：从传统的 4 周缩短至 2 周
  • macOS “零窗口重启”：Chrome 150 引入了新机制——当用户关闭窗口但未退出应用时（macOS 应用在此状态下仍在后台运行），Chrome 利用这段时间自动完成更新安装
  • 动态补丁技术：正在研发中的底层改进，目标是让补丁在浏览器运行时直接安装，无需任何形式的重启

塔布里兹认为，当前的高频修补是一个”近期的峰值”，行业最终会达到一个新的平衡点。”对于像 Chrome 这样成熟稳定的产品，一旦 AI 能发现的漏洞大部分被修复完毕，新发现的数量应该会出现下降，”她解释说，”因为 AI 模型可以被训练成对软件项目的演化历史有百科全书般的理解。”

但她同时强调：”我不会假设一切都会自动变好。安全不会免费到来。”

对开发者的启示

Chrome 的经验对整个软件行业具有参考意义。当 AI 将漏洞发现从”手工作业”变成”工业化流水线”后，安全团队的工作重心将从”找漏洞”转向”管理漏洞修复节奏”和”构建纵深防御”。

谷歌也在同步推进结构性安全改进——将部分 C++ 代码用内存安全的 Rust 语言重写，从架构层面消除整类常见漏洞。这种”发现+根治”双管齐下的策略，可能是 AI 时代软件安全的标准答案。

来源：Wired，原文链接 https://www.wired.com/story/chrome-needs-twice-a-week-patching-thanks-to-ai-bug-hunting-for-now/

]]> 安卓刷网页总卡顿？外媒实测这款浏览器比Chrome快 https://mylogs.cn/%e5%ae%89%e5%8d%93%e5%88%b7%e7%bd%91%e9%a1%b5%e6%80%bb%e5%8d%a1%e9%a1%bf%ef%bc%9f%e5%a4%96%e5%aa%92%e5%ae%9e%e6%b5%8b%e8%bf%99%e6%ac%be%e6%b5%8f%e8%a7%88%e5%99%a8%e6%af%94chrome%e5%bf%ab/ Thu, 30 Jul 2026 05:04:29 +0000 https://mylogs.cn/%e5%ae%89%e5%8d%93%e5%88%b7%e7%bd%91%e9%a1%b5%e6%80%bb%e5%8d%a1%e9%a1%bf%ef%bc%9f%e5%a4%96%e5%aa%92%e5%ae%9e%e6%b5%8b%e8%bf%99%e6%ac%be%e6%b5%8f%e8%a7%88%e5%99%a8%e6%af%94chrome%e5%bf%ab/ 不少安卓用户都有类似的体验：Chrome 和 Firefox 功能强大，但日常使用中总觉得慢半拍——尤其是同时开着几十个标签页和标签组，或者加载一个广告繁多的资讯网页时，卡顿、白屏、反复重新加载的情况屡见不鲜。

安卓刷网页总卡顿？外媒实测这款浏览器比Chrome快
图片来源：MakeUseOf

MakeUseOf 撰稿人 Abhijith N Arjunan 分享了他的解决办法：在同一部安卓手机上把 Brave 浏览器与 Chrome、Firefox 并行使用数周后，他发现在真实的日常任务中，Brave 的速度体验明显领先。这里说的不是跑分测试，而是每天都会遇到的网页加载、标签切换和视频播放。

网页加载更快：先把广告”拦在门外”

Brave 提速的核心并不神秘：它会在页面进入渲染阶段之前，先剥离广告和跟踪组件。标签页不必加载这些内容，打开速度自然更快。这位撰稿人表示，日常访问的大多数网站（包括许多新闻站点）加载速度都有肉眼可见的提升。

值得一提的是，Brave 与 Chrome 使用相同的渲染引擎（Chromium），因此提速并没有带来网页兼容性问题。而他此前在 Chrome 和 Firefox 上搭配 uBlock Origin 等去广告扩展的体验，始终不如 Brave 内置的系统级拦截来得干脆。Brave 的”防护盾”（Shields）功能还能精细控制 Cookie 存储、拦截浏览器指纹追踪，且可随时按站点关闭。

多标签切换不再”重载轮盘赌”

对于习惯不关标签直接切换应用的用户，Brave 的表现同样稳定：

  1. 开启多设备同步后，几十个标签分组依然流畅，切换标签与标签管理界面时没有 Chrome、Firefox 上常见的卡顿；
  2. 离开一段时间后回到浏览器，大多数标签无需重新加载，中断的浏览可以直接继续；
  3. 还可以自行设置标签保留时长，并跨设备同步标签组，适合多任务场景。

滚动和视频播放更顺滑

由于后台运行的广告脚本和跟踪器更少，Brave 在页面滚动和视频播放上也更流畅。它开箱即可拦截视频贴片广告，并支持后台播放；还能屏蔽 Shorts 短视频、推荐内容等干扰元素。据这位撰稿人观察，用 Brave 看在线视频的耗电量甚至低于专门的视频应用。

注意事项

Brave 并非在所有场景下都是最优解：安卓版 Brave 不支持浏览器扩展（Firefox 支持），与谷歌账号及其服务的整合也不如 Chrome 紧密。如果不依赖这两点，日常以阅读、浏览、看视频为主的用户可以从 Brave 官网下载安卓安装包一试。

来源：MakeUseOf

]]> 禁用Cookie也没用？网站靠”指纹”认出你，教你反制 https://mylogs.cn/%e7%a6%81%e7%94%a8cookie%e4%b9%9f%e6%b2%a1%e7%94%a8%ef%bc%9f%e7%bd%91%e7%ab%99%e9%9d%a0%e6%8c%87%e7%ba%b9%e8%ae%a4%e5%87%ba%e4%bd%a0%ef%bc%8c%e6%95%99%e4%bd%a0%e5%8f%8d%e5%88%b6/ Wed, 29 Jul 2026 02:06:50 +0000 https://mylogs.cn/%e7%a6%81%e7%94%a8cookie%e4%b9%9f%e6%b2%a1%e7%94%a8%ef%bc%9f%e7%bd%91%e7%ab%99%e9%9d%a0%e6%8c%87%e7%ba%b9%e8%ae%a4%e5%87%ba%e4%bd%a0%ef%bc%8c%e6%95%99%e4%bd%a0%e5%8f%8d%e5%88%b6/ 过去想减少网站追踪，思路很简单：关掉第三方 Cookie、拉黑追踪域名、装个广告拦截器。但现在网站有了更隐蔽的手段——浏览器指纹。Lifehacker 撰稿人 Ritoban Mukherjee 近期撰文详解了这项追踪技术的原理，以及各大浏览器的应对方法。

禁用Cookie也没用？网站靠
图片来源：René Ramos/Lifehacker/Adobe Stock

什么是浏览器指纹

浏览器指纹是指网站通过查询设备的大量细微技术信息——屏幕分辨率、时区、已安装字体、显卡驱动、处理器核心数、电池电量等——拼出一个专属于这台设备的唯一标识。整个过程不需要向浏览器安装任何文件或扩展，纯靠服务器端与 JavaScript 信号完成，因此即便禁用了全部 Cookie，网站依然能认出用户并跨站追踪浏览记录。

常见的指纹采集手段包括：让浏览器偷偷绘制一张隐藏 2D 图像再分析像素数据（Canvas 指纹）、渲染 3D 图像获取显卡型号（WebGL 渲染）、通过文字渲染尺寸摸清系统字体库（字体枚举），以及用一段无声音频生成设备独有的声波签名（AudioContext）。

想知道自己暴露了多少？可以访问电子前哨基金会（EFF）的免费检测工具 Cover Your Tracks 扫描一下。文章作者在已禁用 Cookie 的情况下测试自己的浏览器，仍然泄露了 18.26 比特的识别信息。

各浏览器的防护设置

指纹追踪无法彻底阻止，但可以大幅提高追踪难度。以下是主流浏览器的具体设置步骤：

Safari（需 17 及以上版本）：iPhone/iPad 上进入「设置 > 应用 > Safari > 高级」，打开「高级跟踪和指纹识别保护」，选择「所有浏览」；Mac 上在 Safari「设置 > 高级」中启用同名选项。

Edge：默认已有基础防护。点击右上角三点菜单，进入「设置 > 隐私、搜索和服务」，把「跟踪防护」调到「严格」档即可获得最高强度防护，可信站点可加入例外列表。

Firefox：进入「设置 > 隐私与安全」，在「增强型跟踪保护」中选「自定义」，勾选「Cookie」和「指纹追踪程序」，并将指纹拦截范围设为「所有窗口」；也可以直接选「严格」模式一步到位。

Brave：自带的 Shields 组件是实测防护最强的开箱即用方案之一，只需确认「跟踪器与广告拦截」处于「标准」或更高等级，它会主动扰乱指纹 API 采集到的数据。

Chrome：情况最不理想。自 2025 年 4 月 Google 关停 Privacy Sandbox 后，Chrome 没有内置指纹防护，只能依赖 Canvas Blocker、Fingerprint Spoofer 等第三方扩展。但 Manifest V3 框架限制了扩展在页面加载完成前注入代码，往往给指纹脚本留出了得手的时间窗口。文章建议：真正在意指纹防护的用户，可以考虑换用同为 Chromium 内核的 Brave。

来源：Lifehacker

]]>