文章提交注意事项：
请在发布文章时用HTML代码加上至少一条新闻来源的链接；原创性消息，可加入相关信息（如涉及公司的网址）的链接。有任何问题，邮件至：he.fang#zhiding.cn
注意：收到邮件乱码的用户请修改客户端的默认字体编码，从"简体中文（GB2312）"修改为"Unicode（UTF-8）"。
solidot新版网站常见问题，请点击这里查看。
2016 年，Google 宣布将杀死 Chrome Apps。根据当时 Google 公布的死亡时间表：2016 年底停止接受新 Apps，2017 年下半年停止在 Chrome Web Store 展示 Chrome Apps；2018 年 Chrome Apps 将只在 Chrome OS 平台上显示。这一决定不影响 Chrome Web Store 中的扩展。Chrome Apps 与扩展的一个主要区别在于应用拥有的权限更多。现在，根据 Google 公布的最新时间表：它将在 2022 年 6 月彻底杀死 Chrome Apps。Google 表示：2020 年 3 月停止接受新 Apps，现有的 Apps 可继续更新到 2022 年 6 月；2020 年 6 月停止支持 Windows、Mac 和 Linux 上的 Chrome Apps，企业版和教育版用户支持到 2020 年 12 月；2021 年 6 月停止支持 NaCl、PNaCl 和 PPAPI APIs，终止支持 Chrome Apps on Chrome OS，企业版客户支持到 2022 年 6 月。
Google Chrome 官方博客宣布，Chrome/Chromium 将在两年内逐步停止支持第三方 cookie。Chrome 是目前市场占有率第一的浏览器，但分析师认为此举对 Google 自己的业务影响甚微，因为搜索巨人有很多其它方法来收集用户数据。Google 表示希望开发替代工具以“维持广告支持的 web”，以便在两年内“使第三方 cookie 变得过时”。这种替代工具可能会使 Chrome 成为更重要的中介，持有用户的相关信息，有选择地与希望确定广告投放目标和衡量广告效果的机构分享。网站将仍能用“第一方 cookie”来标记个人，记录他们的行为。但第三方将无法把他们的 cookie 放在网站上，在用户浏览不同网站时勾画出他们的行为轮廓。
在 Mozilla 之后，Google 也采取行动限制恼人的弹出式通知。计划在 2020 年 2 月 4 日释出的 Chrome 80 将默认屏蔽大部分弹出式通知，改用在地址栏显示有通知的图标，类似 Firefox 的做法——在地址栏显示通知的文字泡泡。Chrome 的设置将引入一个新的选项，用户可以手动选择启用去屏蔽通知，或者等待 Google 在未来几周默认启用。对于用户很少接受的弹出式通知，Google 未来将自动将其屏蔽。
因为遭到部分网站不公平的阻止访问其服务，基于 Chromium 的浏览器 Vivaldi 从最新释出的 Vivaldi 2.10 起修改用户代理字符串（UA string），模仿 Chrome 以规避屏蔽。UA String 是浏览器与网站建立初始连接时发送的数据，其中包含浏览器类型、渲染引擎和操作系统等数据。举例来说，Windows 版本 Firefox 的 UA string 是“Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:71.0) Gecko/20100101 Firefox/71.0”。UA string 始于 1990 年代，网站可以利用这一数据调整性能和功能，或屏蔽过时的浏览器。但今天许多网站使用 UA string 屏蔽用户访问，部分是因为不愿意处理与特定浏览器相关的 bug，部分是因为繁琐，微软和 Google 这么做则是为了独霸市场打击竞争对手。Vivaldi 是基于 Chromium，与 Chrome 基础代码相同，Vivaldi 称它遭到屏蔽的主要原因是竞争对手所为。
Google 开始推送更新修复上周曝出的 Chrome 79 数据丢失 bug。该 bug 主要影响基于 WebView/Chrome 的 Android 应用，原因是 Chrome 79 改变了 user profile 目录的位置，AppCache、File System、localStorage、IndexedDB、Service Workers 和 WebSQL 等 API 生成的用户数据留在了旧的目录，没有迁移到新的目录，结果就是升级到新版本的用户发现许多 Android 应用突然重置、数据丢失或账号锁定。在开发者报告之后，Google Chrome 团队暂停了更新推送。Google 发言人称，用户数据仍然是完整的，在更新之后所有受影响的数据将会恢复。
用户向 Google 递交 bug 报告，称最新的 Chrome 79 (79.0.3945.79)更新会导致其它应用的 localstorage 或 websql 无预见的清空。许多用户都反映了同样的问题，另一名用户报告称，客户在升级到 Chrome/webview v79 后失去了所有的应用数据。用户们建议 Google 在未修复前回滚到旧版本。Chrome 开发者表示他们了解这个数据丢失 bug 非常严重，他们正致力于寻找解决方案最小化数据丢失。
Google Chrome 的一项实验功能导致浏览器标签发生崩溃，全世界有大量企业受波及。问题持续了两天，没有影响所有 Chrome 用户，而是主要影响运行在 Windows Server terminal server 设置——这是企业网络中非常常见的设置——下的 Chrome 浏览器。数以百计的用户通过 Google 支持论坛报告，雇员使用的 Chrome 标签突然变成空白，这一错误被称为“白屏死亡”。一位使用 Costco 邮箱地址的系统管理员称，崩溃影响了所有呼叫中心的工作人员，他们无法再与客户进行聊天。另一名系统管理员称其公司有 4000 雇员受影响，还有一人称影响到了数百人。导致标签崩溃的原因已经找到，是 Chrome 名叫 WebContents Occlusion 的实验功能：当用户移动到另一个应用窗口时，将 Chrome 当前活动标签作为背景标签暂停其活动减少资源占用。Google 是在周二早晨在稳定版 Chrome 启用该功能，结果 bug 导致 terminal server 设置下的 Chrome 标签发生崩溃。一位愤怒的系统管理员说，“我们不是你们的实验鼠。”
Google 认为网站加载越快越好，对于加载缓慢的网站搜索巨人认为应该对其公开的羞辱。Chrome 官方博客宣布了一项计划：给加载缓慢的网站引入标记（badging）。未来这种标记可能会包含速度之外的因素。Google 希望网站开发者提前做好准备，它推荐了一系列工具帮助开发者识别导致网站加载缓慢的因素，这些工具包括 PageSpeed Insights 和 Lighthouse， 并推荐阅读 Web.dev/fast。
Google 开始通过其测试版 Chrome Canary 测试受争议的新扩展系统 Manifest V3。在安全、隐私和性能的名义下，Manifest v3 限制了广告和内容屏蔽功能。Manifest v3 用 declarativeNetRequest API 取代了 webRequest API，允许设置模式匹配规则探测所请求流量并采取行动，但 Google 对规则的数量设置了上限。硬限制将会严重影响广告和内容屏蔽扩展的可用性。最新版的 Chrome Canary 包含了 declarativeNetRequest API，Google 表示 Manifest v3 的实现远未完成。
Google 释出了 Chrome 78。主要变化包括：新标签页可定制菜单，为实验性功能，默认未激活，需要在 chrome://flags 中启用两个选项（chrome://flags/#ntp-customization-menu-v2 和 chrome://flags/#chrome-colors）；Tab Hover Cards，鼠标悬浮在一个标签上会显示标签的简略信息；对所有网站启用黑色模式 Forced Dark Mode；密码检查工具将警告用户密码是否泄漏，默认未启用，需要修改选项 chrome://flags/#password-leak-detection；实验性的 DNS-over-HTTPS (DoH)功能；移除旧的 XSS Auditor 功能；新 API 如 CSS Properties and Values API，Native File System API 等等。
uBlock Origin 作者 Raymond Hill 透露，他递交的扩展开发版更新（1.22.5.100）遭到了 Google Chrome Web Store 的拒绝，理由是没有遵守 Google 的政策。Google 给出的解释是：扩展必须是单一用途，不能捆绑不相关的功能。Hill 称他的扩展根本没有不相关的功能，他不打算再继续递交开发版更新了，因为你根本没有办法从 Google 获得更明确的拒绝解释。他称 uBlock Origin 下一个稳定版更新就是上一个没有被拒绝的开发版也就是 1.22.5rc1+。这一消息在社交媒体上收到了广泛关注，以至于 Chrome 扩展团队的成员也看到了，所以问题也就顺利解决了。但很多 Chrome 扩展开发者都有类似的经历，但他们的扩展没有 uBlock Origin 这样的影响力，他们的声音当然不会被 Chrome 扩展团队成员听到。
在 Mozilla 之后，Google Chrome 也计划引入 DNS-over-HTTPS (DoH)功能，加密 DNS 请求发送到非本地 DNS 解析器。用户发送的 DNS 请求通常是明文发送给 ISP 的 DNS 解析服务器，在不同的网络环境下，明文发送 DNS 请求被认为不安全的，DoH 是这个问题的一个解决方案，它通过加密 DNS 请求到第三方或用户设置的 DNS 解析服务器来保护用户的隐私，然而这个方案的缺陷是你选择的 DNS 服务商将掌握你的 DNS 数据，你需要信任你的服务商。Mozilla 的合作伙伴是 Cloudflare，它是一家云服务商，而 Google 本身是网络广告巨头，它选择的 DNS 服务商可能就是自己，这意味着它将掌握用户更多的信息。这可能会引发新的隐私争议。
Google 正在 Chrome 中内置数据泄露通知服务，当用户使用已泄露的凭证登录网站浏览器将会发出警告。此前 Mozilla 和 Have I Been Pwned 合作推出了 Firefox Monitor 服务，通知用户他们的用户名密码等信息是否泄漏，该服务正被整合到 Firefox 中。Google 最近发布了 Password Checkup 扩展，提供类似的警告。通过 Password Checkup Google 发现 1.5% 登录信息被泄露了，26% 的用户在收到警告之后改变了密码。这一发现促使 Google 决定将泄露通知服务整合到浏览器中。使用 Chrome 78 Canary 测试版的用户可通过chrome://flags 搜索 leak 将 Password Leak Detection 设为 Enabled 启用该功能。
微软的 Edge 已经切换到了 Chromium，微软的开发者正在向开源的 Chromium 项目贡献代码和功能。软件巨人最近向搜索巨人提出的一项功能是改进浏览器的电池续航，Google 已经接受并将其用于 Chrome。这项功能与多媒体内容的磁盘缓存有关。微软开发者 Shawn Pickett 解释说，媒体内容在播放期间会被缓存到磁盘，在播放过程种保持磁盘活跃会增加总体的功耗，阻止操作系统进入较低功耗模式。鉴于媒体播放是高使用场景，额外的电池使用对电池续航有负面影响。微软提出的改变是阻止某些媒体内容缓存到磁盘以改善电池续航。Google 正在测试版 Chrome Canary 中测试该功能，没有默认启用，用户需要输入 chrome://flags 搜索 Turn off caching of streaming media to disk。
最近释出的 Chrome 76 修改了 FileSystem API 的行为，防止网站利用脚本调用 FileSystem API 去检测浏览器是否处于隐身模式。此前在 Chrome 的隐身模式下，FileSystem API 被禁用，以防止在设备上留下痕迹。但即便 Chrome 76 进行了修改，网站仍然能探测 Google Chrome 的隐身模式。研究人员发现，在隐身模式下，Chrome 分配给文件系统的临时存储空间有一个 120MB 的硬限制，因此脚本可以去查询分配的存储空间是否在 120MB 以内，如果是那么浏览器是处于隐身模式。此外还有其它方法能探测隐身模式。
Chrome Web Store 有 188,620 个扩展，但绝大部分扩展半死不活，安装量少的惊人。根据 Extension Monitor 对 Chrome Web Store 的分析报告，半数 Google Chrome 扩展安装量不足 16 次。19,379 个扩展安装量为零，25,540 个扩展只有一个用户。只有很少的扩展拥有成规模的用户群。87% 的扩展安装量不到一千，只有 13 个扩展安装量突破一千万，它们分别是： Google Translate、Adobe Acrobat、Tampermonkey、Avast Online Security、Adblock Plus、Adblock、uBlock Origin、Pinterest Save Button、Cisco Webex、Grammarly for Chrome、Skype、Avast SafePrice 和 Honey。
在安全、隐私和性能的名义下，Google Chrome 提出了新扩展系统 Manifest v3，计划最快本月初释出 Manifest v3 预览版。有没有改进隐私和性能，目前还看不出来。但它究竟有没有改进安全性？ EFF 认为Manifest V3 并没有改进 Chrome 的安全，Google 的声明不是真的：Manifest V3 仍然允许扩展和以前一样观察数据，包括用户访问的网址和网页内容，它没有改变另一种提取用户浏览数据的内容脚本的工作方式，仍然允许扩展在所有网站上运行。Google 对扩展规则的数量设置了上限，它没有杀死广告屏蔽扩展，但它遏制了创新，而且并没有证明这么做是必要的。EFF 建议 Google 如果想要改进安全可以在扩展审核上做得更好些。