本期热点#

今天最值得先看的，是Backblaze备份策略的争议。原文指出，这家以“尽可能把东西都备份起来”建立口碑的服务，近年悄悄把 OneDrive、Dropbox 等云同步目录排除在外，连 .git 目录也早已不在默认覆盖范围内，但用户既没有在产品界面里得到足够醒目的提示，也没有收到足够明确的通知。问题不只是某几个目录该不该备份，而是灾难恢复这件事最怕“以为自己已经有备份”。评论区普遍提到，备份产品最不该制造惊喜；即便技术实现确实会被占位文件、按需下载机制拖累，服务方也应该把边界讲清楚，并给用户选择权。

把这条放在最前面，也很能概括今天的 Hacker News 讨论气质：大家讨论的不只是新功能和新政策，而是系统边界是否透明、默认值是否可信、用户有没有被悄悄替代做决定。从搜索体验、版权封锁到隐私治理和形式化验证，许多话题最后都落回同一个问题：当工具越来越复杂，谁来保证它仍按你理解的方式运行。

资讯#

今天的资讯更像一组“平台如何行使权力”的样本：有的平台开始收紧反用户增长手法，有的平台继续升级底层安全能力，也有监管和版权执行把公共网络一并卷了进去。

Google Search 把返回键劫持写进垃圾政策#

Google 宣布，站点如果利用历史记录操纵返回键，让用户回不到上一页，而是跳到广告页、推荐流或未访问过的页面，将被纳入搜索垃圾政策处理。原文的重点不在于这种做法有多新，而在于 Google 终于把一个长期存在的黑暗模式变成了可执行的违规项，并给出了明确的生效时间。对依赖搜索流量的网站来说，这意味着“交互层面的作恶”不再只是体验问题，也会影响可见性。

HN 社区的讨论很务实。评论区普遍提到，这种问题并不罕见，LinkedIn、Reddit 以及不少新闻站都曾被点名；高赞评论的共识是，无论是站点自己写的逻辑，还是广告脚本偷偷带来的行为，责任都该由站点承担。也有开发者补充，History API 本身没有原罪，真正令人反感的是把它用在反用户的增长套路里。

西班牙扩大互联网封锁#

这条新闻表面上讲的是盗播治理，核心其实是网络封锁手段继续外溢。原文称，西班牙方面已把动态拦截的范围从足球直播扩展到网球、高尔夫以及部分影视内容，且覆盖更多运营商；封锁对象也不只是域名和 URL，还包括 IP 地址。问题在于，今天的很多合法站点都共用 CDN 和托管基础设施，一旦按 IP 动手，很容易把无关服务一起打掉。

不少开发者在 HN 评论里把矛头指向产品和商业模式，而不只是盗版本身。评论区常见的观点是，官方转播在价格、可得性和使用体验上输给了盗播，于是监管选择了封网，而不是先改服务。另一条反复出现的提醒是，按 IP 动态封锁在共享基础设施时代天然会误伤，等于把版权执行的副作用转嫁给普通网民和无关站长。

OpenSSL 4.0.0 发布#

OpenSSL 4.0.0 带来了 Encrypted Client Hello、TLS 1.2 的 FFDHE 协商、cSHAKE 以及一批与 SM2、SM3 相关的能力，同时继续清理 SSLv3、引擎机制和多组废弃 API。原文最值得关注的一点，是 ECH 终于进入主流 TLS 库的正式版本线，这让“尽量少暴露你在访问哪个域名”这件事离大规模部署又近了一步。对安全基础设施来说，这是清晰的前进信号。

不过 HN 社区的态度并不单向乐观。高赞评论一方面认可 Heartbleed 之后 OpenSSL 的安全治理确实成熟了不少，另一方面也直言 3.x 到 4.x 的 API 设计、性能表现和整体工程复杂度仍让人头疼。也有开发者提到，正因为这些体验问题持续存在，一些项目会继续评估 BoringSSL 或 AWS-LC 之类的替代方案。

博客#

博客区的共同主题更偏向“边界条件”：形式化验证能覆盖到哪里，版本控制能不能换一种心智模型，隐私法在现实供应链里到底能执行到什么程度。

Backblaze 的备份信任危机#

原文对 Backblaze 的批评很直接：备份服务的核心承诺，本来应该是尽量保住你的数据，而不是在你不知情的情况下替你判断哪些目录“不重要”。作者特别担心的是灾难恢复预期被悄悄改写，用户以为自己有多重保险，真正出事时才发现关键文件根本没被覆盖。这里最刺眼的地方，不是技术限制，而是默认行为与品牌叙事之间的落差。

HN 评论没有陷入“云同步目录到底该不该备份”的枝节。评论区普遍提到，备份系统可以有实现限制，但不该让用户事后才知道；如果确实要跳过某些目录，也至少应该把“仅云端占位文件”和“已经完整落地的本地文件”分开处理，并提供可配置项。简评是，所有做数据托管的产品，最后卖的都是信任，一旦默认值开始和用户的常识脱节，问题就不再只是一个设置项。

Lean proved this program was correct; then I found a bug#

这篇文章的亮点，不是“形式化验证翻车了”，而是把验证边界讲得很清楚。作者用 Claude 代理、AFL++ 和 AddressSanitizer 对 lean-zip 进行了海量模糊测试，没有在已被证明的压缩与解压核心逻辑里找到内存安全问题，却在 Lean 运行时发现了堆缓冲区溢出，又在未纳入证明覆盖的归档解析模块中找到了拒绝服务问题。原文因此得出的结论很克制：证明确实有效，但它只能覆盖你真正写进规格、真正纳入信任链的那一部分。

HN 社区对标题表达有明显分歧。很多评论认为，这个标题容易让读者误以为 Lean 的证明本身失效了，实际上暴露的是运行时和规格边界外的漏洞；但也有评论者反驳，对最终用户来说，可利用的缺陷无论落在边界内还是边界外，风险都一样真实。高赞评论的共识仍然是，形式化验证很有价值，只是它从来不是“证明一次，整体无忧”的魔法。

Jujutsu（jj） 想重写 Git 用户的工作流直觉#

这篇教程从 Git 用户的熟悉痛点切入，介绍 jj 为什么值得关心。原文认为，jj 真正吸引人的地方，不只是命令少一些，而是把“当前工作就是一个可变提交”当作一等概念，让拆分、重排、回退和整理历史不必等到最后一刻。它还能继续兼容 Git 仓库，所以个人可以先用起来，不必拉着整个团队一起迁移。

HN 评论的讨论焦点在“顺手”到底是不是一种可迁移的优势。支持者普遍觉得，jj 让历史整理从偶发动作变成日常操作，特别适合边探索边塑形的开发过程；质疑者则提醒，自动把工作区视作提交、以及 jj edit 这种默认改写历史的习惯，也可能变成新的脚枪。评论区隐含的共识是，jj 并不是一组更顺口的 Git 别名，而是一套新的版本控制心智模型。

Flock Safety 与“谁该响应删除请求”这道现实难题#

作者尝试依据加州 CCPA，要求 Flock Safety 删除与自己、车辆和家庭成员有关的数据，但收到的回复是：Flock 只是客户的数据处理方，应该去联系部署该系统的机构。原文的争议点在于，Flock 在现实中并不像一个单纯的被动存储商，而更像是一个把跨机构车牌与轨迹数据组织起来、可检索、可共享的平台。于是问题变成了：当监控基础设施由私营公司搭建、由公共和私人机构共同使用时，公民到底该去找谁主张删除权和知情权。

HN 社区的讨论最有价值的地方，在于把情绪先放到一边，回到法律角色本身。有人指出，如果 Flock 的确只是类似 GDPR 语境中的处理者，它的答复在形式上未必站不住；但也有不少开发者指出，只要平台参与聚合、检索、派生分析或共享，就很难再把自己描述成一根“纯管道”。评论区的共识是，现有隐私法规在这类外包式监控网络面前暴露了执行断层，普通人很难沿着供应链逐层完成维权。

尾巴#

今天这组话题看下来，你会发现一个很朴素的判断标准反复出现：好系统不只是功能强，更要把边界讲明白。备份服务要清楚告诉你什么没备份，搜索平台要明确什么行为会被处罚，安全库要在升级时处理历史包袱，隐私系统则必须回答“谁负责”这个基本问题。

对开发者来说，这些讨论的共同价值不在于立刻学到一条新命令或一个新协议，而在于再次确认一个老原则：默认值、信任链和责任归属，往往比功能清单更决定用户体验。今天的日报就到这里，我们下期再见。