Google VPN被发现会覆盖Windows 11/10的DNS配置

Google VPN被发现会覆盖Windows 11/10的DNS配置 通常情况下，一些专业级用户会使用同时兼具高可用和高安全性的 DNS 服务器，例如 CloudFlare 提供的服务器，亦或者使用 AdGuard 搭建的自定义 DNS 服务器。考虑到 Google One VPN 是用来保护用户隐私的，在启用加密隧道连接后强制使用谷歌 DNS 倒也无可厚非，毕竟每家公司肯定都认为自家服务才是最好的。但在用户关闭连接后自定义设置的 DNS 并不会恢复，也就是在非加密隧道连接的情况下，依然会使用谷歌 DNS 服务器，于是这就引起了一些隐私方面的担忧。更让人担忧的是谷歌配置 DNS 时默认并没有启用 DoH 或 DoT，因此在断开连接后，实际使用非加密的谷歌 DNS 服务器执行连接，这有可能会泄露用户的域名请求记录。不过针对该问题实际上更早的时候就有用户提出了，并且谷歌工程师也进行了回应，在 2023 年 11 月份的一个反馈贴中，用户称在 Windows 10/11 中都存在相同的问题，而在 Mac 版 Google One VPN 中不存在这个问题。谷歌工程师在 2024 年 1 月发布回应称，为保护用户隐私，Google One VPN 特地将 DNS 设置为谷歌 DNS，防止恶意软件修改 DNS 或通过 DHCP 插入的恶意 DNS 窃取用户隐私。尽管谷歌认为这对大多数用户来说都是一个比较好的做法 (实际上在讨论中大部分网友都不赞同这个观点)，但谷歌也明白有些用户确实希望使用自己的 DNS，因此他们计划在未来版本中添加相关功能，可能是连接时使用自定义 DNS 亦或者是断开后自动恢复为用户指定的 DNS。 ... PC版： 手机版：

Google Analytics将在7月1日关闭谷歌通用分析 所有网站和应用都必须迁移至GA4

Google Analytics将在7月1日关闭谷歌通用分析 所有网站和应用都必须迁移至GA4 谷歌对 GA4 的期望是非常高的，因此按惯例谷歌要砍掉旧版本或产品，其中 Google Analytics 3 也叫 Google Universal Analytics (谷歌通用分析) 将被停掉。按照谷歌原计划，通用分析是要在 2023 年 7 月 1 日停止服务的 (包括通用分析 360)，不过后来因为争议太大谷歌将其延长到 2024 年 7 月 1 日，而目前距离截止时间已经很近了，所以谷歌开始发邮件通知使用 GA3 的用户。谷歌在邮件中表示：从 2024 年 7 月 1 日开始，Google Analytics 4 将完全取代通用分析，从那一天起，谷歌将关闭所有通用分析服务和通用分析 API，这意味着通用分析将无法通过 Google Analytics 前端或 API 访问。如果您尚未完全迁移到 Google Analytics 4，请按照迁移指南立即开始进行迁移。在支持文档中谷歌也说明了不迁移的后果，即从 7 月 1 日开始，通用分析的媒体资源将停止处理数据，之后一小段时间内网站管理员 / 开发者仍然可以查看通用分析报告，但只有使用 GA4 的媒体资源才能获取新的统计数据。不过即便网站管理员忘记迁移其实也问题不大，因为谷歌会代表网站创建 GA4 媒体资源，谷歌称会尽可能重复使用现有的网站标记，同时复制 GA3 中的媒体资源设置，因此统计仍然是不间断的。关于 GA3 和 GA4 主要争议其实在产品功能方面，一些网站管理员并不喜欢 GA4 所以迟迟不愿意迁移，不过谷歌开启自动迁移后，除非网站管理员手动退出，否则都会完成自动迁移。具体网站管理员可以在 Google Analytics 控制台查看迁移情况： ... PC版： 手机版：

谷歌翻译疑似退出中国内地市场，Chrome 浏览器内置翻译无法使用

谷歌翻译疑似退出中国内地市场，Chrome 浏览器内置翻译无法使用 访问有几率显示与搜索和地图等其他谷歌服务相同的跳转提示页面。 并且 translate.googleapis.com（Google 翻译 API，常见于 Google Chrome 浏览器内）不再分配中国内地的服务器地址，所以浏览器内置的 Google 翻译无法使用（手动通过 hosts 等方法绑定中国内地服务器 IP 地址仍然可以继续使用） 浏览器内置API不支持扩展配置的socks5代理，所以挂梯子是无效的，除非用系统代理。 解决方法：可以编辑HOSTS文件对域名的地址解析进行修正。 由于采用与相同的 IP地址，可以先ping一下得到对应的IP再修改HOSTS文件。

意大利数据监管机构警告使用谷歌分析可能违反欧盟法律

意大利数据监管机构警告使用谷歌分析可能违反欧盟法律 在欧洲使用谷歌分析（ Google Analytics ）的又一次打击。意大利数据保护机构发现，当地一家网络出版商使用流行的分析工具不符合欧盟数据保护规则，因为用户数据被转移到美国一个缺乏同等法律框架来保护信息不被美国间谍访问的国家。 Garante发现网络出版商使用谷歌分析导致收集了许多类型的用户数据，包括设备IP地址、浏览器信息、操作系统、屏幕分辨率、语言选择，以及网站访问的日期和时间，这些数据被转移到美国，而没有采取足够的补充措施来提高保护水平，使其达到必要的欧盟法律标准。 它补充说，谷歌应用的保护措施不足以解决风险，这与其他几个欧盟DPA的结论一致，他们也发现在数据出口问题上使用谷歌分析器违反了集团的数据保护规则。

法国法院下令谷歌/CloudFlare/思科公共DNS屏蔽盗版网站

法国法院下令谷歌/CloudFlare/思科公共DNS屏蔽盗版网站 据关注 ISP 和流媒体版权问题的网站 TorrentFreak 发布的消息，法国巴黎法院在 5 月份应版权方要求，命令谷歌、CloudFlare 和思科在其公共 DNS 系统里屏蔽约 117 个盗版网站域名。此次屏蔽的网站主要涉及的版权内容是英超联赛和欧冠联赛，提交申请的版权方则是 Canal+，该版权方还要求法国当地 ISP 即网络运营商也通过 DNS 系统屏蔽这些域名。谷歌、CloudFlare 和思科运营着世界排名前列的公共 DNS 系统，其中谷歌的就是 8.8.8.8、CloudFlare 运营的是 1.1.1.1、思科的是 OpenDNS 系统。这些公共 DNS 系统运营商需按照法院要求将这些盗版网站域名解析到错误的 IP 从而实现阻断连接，当然阻断连接的范围也仅限于法国境内。最初版权方是要求法院下令法国境内的 ISP 通过他们自己的 DNS 系统执行屏蔽的，但显然精明的用户会更换 DNS 从而绕过屏蔽，选择谷歌、CloudFlare 和思科的 DNS 都是个不错的选择，这也是 Canal + 现在要求这些公共 DNS 系统也屏蔽这些域名的原因。那么这些屏蔽措施有用吗？从某些方面来说是有用的，因为这影响 “高达” 800 多名法国用户访问这些盗版网站。谷歌代表律师通过分析法国视听和数字通信监管局 Arcom 的数据发现，谷歌、CloudFlare 和思科 DNS 屏蔽盗版网站影响大约 0.084% 的法国用户，但这些受影响的用户也会寻找其他规避方法例如继续更换 DNS 或使用 VPN，最终大约只有 2% 的用户 (这 0.084% 的用户里的 2%) 会放弃继续访问这些盗版网站。通过相关公开数据谷歌代表律师认为这大约影响了 800 多名法国用户，所以实际影响可以说微乎其微或者说完全没有。谷歌计划遵守这一决定也就是屏蔽这些盗版域名，同时在此前谷歌也已经从搜索结果里删除这些域名让用户无法直接通过关键词搜索找到这些网站。至于 CloudFlare 和思科是否也会遵守这个决定还不清楚，不过既然是法院下令要求的，通常情况下只要争议不是特别大，这些公司是会遵守的。 ... PC版： 手机版：

一台DNS根服务器与同伴失去了联系 草台班子运维让故障持续长达四天

一台DNS根服务器与同伴失去了联系 草台班子运维让故障持续长达四天 下面简要介绍域名系统的工作方式以及根服务器在其中的作用：当有人在浏览器中输入时，处理请求的服务器首先必须将人性化的域名翻译成 IP 地址。这就是域名系统的作用。域名系统流程的第一步是浏览器查询本地操作系统中的本地存根解析器。存根解析器会将查询转发到递归解析器，递归解析器可能由用户的 ISP 提供，也可能是 Cloudflare 和 Google 分别提供的或服务。如果需要，递归解析器会联系 c-root 服务器或其 12 个对等服务器之一，以确定 .org名称服务器会将请求转给维基百科名称服务器，后者会返回 IP 地址。在下图中，递归服务器被标记为"迭代器"。鉴于根服务器在确保一台设备可以找到互联网上任何其他设备方面的关键作用，有 13 台根服务器分布在世界各地。事实上，每个根服务器都是一个服务器集群，这些服务器在地理位置上也很分散，因此冗余度更高。通常情况下，13 台根服务器各自由不同的实体运营步调一致。当对它们所托管的内容进行更改时，所有服务器一般都会在几秒或几分钟内完成更改。C-root DNS服务器上的奇怪事件这种紧密同步对于确保稳定性至关重要。如果一个根服务器将流量查询指向一个中间服务器，而另一个根服务器将查询发送到另一个中间服务器，那么我们所知的互联网的重要部分就可能崩溃。更重要的是，根服务器会存储必要的加密密钥，以便根据DNSSEC 机制对一些中间服务器进行身份验证。如果所有 13 个根服务器的密钥不一致，就会增加DNS 缓存中毒等攻击的风险。Cogent公司拒绝对此发表评论，其负责维护的12个c-root实例在上周六突然停止更新。法国工程师斯特凡-博茨迈耶（Stéphane Bortzmeyer）是最早在周二的一篇文章中指出这一问题的人之一，他当时指出，c-root比其他root服务器晚了三天。在 Mastodon 上，我们进一步注意到了这种滞后现象。到周三中午，滞后时间已缩短至一天左右。到周三晚些时候，c-root 终于更新完毕。这一滞后促使工程师推迟了原定于本周对处理以 .gov 和 .int 结尾的域名查询的域名服务器进行的工作。原计划是将服务器的 DNSSEC 更新为使用 ECDSA 密钥。由于新密钥无法统一推广到所有根服务器，因此这些计划不得不被取消。负责 .gov DNSSEC 过渡的 Cloudflare 工程师 Christian Elmerot 周三宣布："我们完全了解并监控着 C 根服务器周围的情况，在情况稳定之前，我们不会继续进行正在进行的 DNSSEC 算法滚动。" 服务器过渡的工程师也发出了同样的呼吁，但只是在一些人担心尽管出现了问题，工作仍会继续进行之后。Elmerot在接受采访时说，更新问题对现实世界的影响很小，但随着时间的推移，影响会越来越大。他解释说随着根区变化的累积，版本之间的差异开始变得越来越重要。根区的典型变化是更改授权（NS 记录）、轮换 DNSSEC 更新的 DS 记录以及 DNSSEC 签名的更新。如果差异仍然存在，那么过时的根服务器将看到 DNSSEC 签名过期，这将开始产生更明显的后果。使用多个根服务器可以降低解析器使用落后根服务器的几率。在 c-root 出现故障的同时，同样由 Cogent 维护的c-root网站也出现了故障，导致许多人无法访问该网站。许多人认为这两个问题的原因是一样的。后来发现，网站问题是由于Cogent将用于托管网站的 IP 地址转移到了法国电信公司 Orange 的非洲子公司 Orange Ivory Coast。这次混淆让 Bortzmeyer 开了个玩笑："已向 Cogent 报告（票据 HD303751898），但他们似乎不明白自己管理的是根域名服务器。"出现这些错误的原因是，近几个月来，Cogent公司终止了与几家运营商的合作关系，根据一种被称为对等互联的安排交换彼此的流量。最近的一次终止发生在上周五，当时Cogent公司"部分剥离"了印度运营商塔塔通信公司（Tata Communications）的业务，此举导致Cogent的客户无法访问塔塔通信公司在亚太地区托管的许多网站。周三晚些时候，Cogent发表了以下声明，他们表示直到周二才意识到故障，并又花了 25 个小时才修复故障：世界协调时 5 月 21 日 15:30 时，Cogent Communications 的 c-root 团队被告知，c-root 服务的根区在 5 月 18 日之后不再跟踪根区发布服务器的变更。分析表明，这是由于一项无关的路由政策变更造成的，其副作用是使相关监控系统瘫痪。c-root 没有因为这次中断而无法回答任何 DNS 查询，唯一的影响是根区的新鲜度。c-root 提供的根区同步已于 5 月 22 日 16:00 UTC 时完全恢复。最初，一些人猜测塔塔通信公司的停运、c-root 网站的中断以及 c-root 本身的更新错误都与此有某种联系。鉴于声明含糊不清，这些事件之间的关系仍不完全清楚。 ... PC版： 手机版：