2025 09 23 HackerNews

2025-09-23 Hacker News Top Stories #

AI 生成内容在招聘过程中泛滥，导致求职者伪造能力，使得招聘方难以判断真实水平。

文章以幽默讽刺的方式揭示了技术文档晦涩难懂对新手的困扰，强调技术分享应清晰可理解。

Cloudflare 宣布支持开源项目 Ladybird 和 Omarchy，推动开放互联网的发展。

OpenAI 与 NVIDIA 合作部署 10GW 的 NVIDIA 系统，支持下一代 AI 基础设施的发展。

Cap’n Web 是一个新型 RPC 系统，专为浏览器和 Web 服务器设计，支持多环境运行。

Mozilla 呼吁欧盟拒绝“聊天监控”法案，保护加密技术，维护用户隐私和数字安全。

GEOFABRIK 升级下载服务器基础设施，呼吁用户“负责任地下载”数据，避免频繁重复下载。

特斯拉股东尝试跨大陆自动驾驶测试在 60 英里后发生撞车，暴露自动驾驶技术的不足。

本地优先应用未普及的原因在于同步和冲突解决的复杂性，需借助技术手段解决。

研究指出 eSIM 生态中存在数据跨境、权限过大等隐私与安全风险，呼吁加强监管和技术加固。

You did this with an AI and you do not understand what you’re doing here #

https://hackerone.com/reports/3340109

漏洞报告摘要：cURL Cookie 解析中的栈缓冲区溢出导致远程代码执行

该报告揭示了 cURL 库中一个严重的栈缓冲区溢出漏洞，可导致远程代码执行（RCE）。漏洞存在于 cURL 的 Cookie 解析逻辑中，当处理恶意构造的超大 Cookie 数据时，会因缓冲区大小不匹配和不安全的字符串操作引发内存破坏。

技术细节：

漏洞位置：cURL 的 Cookie 解析代码中，strlen() 函数在未以空字符结尾的缓冲区上执行，导致读取超出分配的栈内存。
根本原因：8192 字节的栈缓冲区被完全填满但未添加终止符，strlen() 会继续读取后续内存，造成 8198 字节的越界读取。
多线程环境下仍可触发，影响广泛。

复现方法：

使用 AddressSanitizer 编译并运行 PoC 代码，可 100% 触发崩溃。
通过恶意 HTTP 响应、伪造 Cookie 文件或命令行注入方式，均可触发漏洞。
示例：curl -b "malicious=$(python -c 'print("A"*8300)')" 可直接触发。

影响范围：

所有使用 libcurl 的应用均受影响，包括 Web 应用、浏览器、API 服务、移动 App、服务器软件及 IoT 设备。
攻击场景包括：恶意网站诱导、中间人攻击、API 恶意响应等，无需用户交互。

安全评估：

CVSS 3.1 得分：9.8（严重级别）
攻击向量：网络（AV:N），复杂度低（AC:L），无需权限（PR:N），无需用户交互（UI:N），影响范围扩大（S:C），可导致机密性、完整性、可用性全面破坏。

验证状态：

已通过 AddressSanitizer 成功复现，PoC 代码可稳定触发漏洞，确认为真实且可利用的高危漏洞。

HN 热度 982 points | 评论 484 comments | 作者：redbell | 16 hours ago #

https://news.ycombinator.com/item?id=45330378

AI 生成内容泛滥导致招聘过程失真，许多求职者通过 AI 伪造能力，使得真正有经验的人才难以脱颖而出。
一些公司因过度依赖 AI 生成的简历和代码而招聘到不合格员工，最终导致项目失败或员工被迅速解雇。
面试中出现候选人直接在面试官面前使用 AI 工具进行实时问答，暴露了对技术能力的真实缺乏。
求职者普遍使用 AI 工具撰写简历和邮件，使得招聘方难以判断其真实水平，甚至影响了职业辅导机构的工作方式。
AI 的普及正在削弱对个人态度、责任感和真实技能的重视，而这些在以往技术行业中被视为核心价值。
招聘流程中对“生产力”的错误定义（如代码量）导致项目快速沦为不可维护的混乱状态，被美其名曰“快速迭代”。
一些技术岗位的招聘者因 AI 生成的虚假作品而放弃真实候选人，导致有能力的人才被排除在外。
企业高层管理者也存在依赖 AI 生成内容的现象，甚至在公开场合表现得像在念 AI 输出的台词，引发对领导力真实性的质疑。
由于 AI 降低了求职门槛，导致真正具备技术能力的人反而被淹没在大量 AI 生成的“优秀”简历中。
有招聘者明确表示，允许搜索资料但禁止使用 AI，以防止浪费时间，但执行效果仍存争议。
一些求职者为了迎合 AI 生成的“理想简历”而放弃真实经历，导致个人职业发展路径被扭曲。

How I, a beginner developer, read the tutorial you, a developer, wrote for me #

https://anniemueller.com/posts/how-i-a-non-developer-read-the-tutorial-you-a-developer-wrote-for-me-a-beginner

这是一篇以幽默讽刺风格撰写的开发者教程博客，作者假装用晦涩难懂的“技术黑话”来指导非技术人员完成一个虚构的编程任务。文章通过大量虚构术语（如“Hoobijag”“Shoobababoo”“Snarfus”“fisterfunk”“gramelions”等）和看似复杂的操作步骤，模拟了新手在阅读技术文档时可能遇到的困惑与挫败感。

文章开头以夸张的“开发者口吻”介绍自己的“丰富经验”，随后描述自己在使用“Snarfus”工具时遭遇“fisterfunk”无法通信的“重大故障”，并自嘲地表示“整个 hoob-tunnel 被 gramelions 堵住”，营造出一种荒诞的技术危机感。

接着，作者“揭示”解决方案：将“Snarfus stagnator”连接到“shamrock Klingon troglodyte emulater”，即可“一切 beep-boops and ding-dongs”，并成功完成“Very Simple Thing”。然而，具体操作步骤却充满无意义字符和乱码，如“ajkl;gawgor;iqeg;iJLkqen”“64A786AGR45JAR; rdja;jg [[]][[]][[]][[]]][ ()()()()()()()(){{}{}{}|{}{|}{}{|}{ ////////////////!! !!!! !! //// !!! agjlkargji;lwej;OI [ASRGASG[]ASGDASG[]EAEadgasg[]EAGE[edaga][]ahgr-0-0=-0-=0-=0=0-0=-0-=0=-0-=0=-0=-0!!!”等，彻底暴露了教程的荒诞性。

文章最后调侃道，前三个步骤可能需要 7 小时和 193 次网络搜索，但“Boop!”那一刻会令人满足。作者强调这“是出于善意的玩笑”，并感谢那些花时间分享知识的人，同时邀请读者尝试用“GewGawGamma”或“ometer2.7”等其他工具复现该方法。

整体来看，这篇博客并非真正教程，而是一次对技术文档过度复杂化、术语滥用和“伪专业性”的讽刺，旨在提醒读者：真正的技术分享应清晰、可理解、以人为本。

HN 热度 816 points | 评论 378 comments | 作者：wonger_ | 23 hours ago #

https://news.ycombinator.com/item?id=45328247

优秀的文档应让初学者在无帮助的情况下也能顺利完成目标，通过观察新手操作可发现文档中的隐藏问题。
文档应避免仅重复术语名称，需提供实际意义和上下文，避免“Nargflargler: Flargles the narg”这类无用描述。
过度追求文档覆盖率会导致低质量内容，如“setDefaultOptions: sets the default options”这种无意义的注释。
API 文档中应明确说明默认参数值，不应让用户自行查找，即使默认值在其他页面定义，也应提供清晰链接。
为维护一致性，默认参数值可仅在一个地方定义，但必须提供明确跳转链接，避免用户迷失。
微软 API 常将关键信息嵌套在多层数据结构中，导致开发者难以获取所需信息，需通过封装层来缓解。
微软 API 设计常将实现细节暴露给用户，缺乏抽象，导致使用复杂，需通过封装库来弥补。
API 设计应通过命名或值对象明确参数含义，避免文档中遗漏单位等关键信息。
文档中应明确参数单位，如字体大小是点、像素还是设备无关像素，否则会引发误解。
有些文档未说明单位或参数含义，可能是因为作者本身也不清楚，仅为了完成“已文档化”的任务。
使用匈牙利命名法（如 duration_ms）有助于明确参数类型和单位，提升代码和文档可读性。
有些 API 结构如 C 枚举在 Swift 中无实际功能，文档应说明其用途，而非仅列出名称。
文档应解释结构体或枚举的实际应用场景，如 AVMetadataKeySpace 用于分组查询元数据键。

Cloudflare is sponsoring Ladybird and Omarchy #

https://blog.cloudflare.com/supporting-the-future-of-the-open-web/

Cloudflare 宣布支持两个独立的开源项目：Ladybird 和 Omarchy，以推动开放互联网的发展。

Ladybird 是一个从零开始构建的全新浏览器项目，不基于 Chromium。它包含两个核心组件：LibWeb 渲染引擎和 LibJS JavaScript 引擎，均自主研发。该项目致力于实现现代网页标准（如 W3C 和 WHATWG 规范），在实践中验证并改进这些标准，同时推动浏览器在隐私、安全与性能方面的创新。目前处于早期开发阶段，预计 2026 年发布 Alpha 版本，欢迎开发者参与贡献。

Omarchy 是一个面向开发者的、基于 Arch Linux 的高度定制化操作系统发行版，旨在让 Linux 更易用、更吸引人。Omarchy 3.0 已于近期发布，具备更快的安装速度和更强的 MacBook 兼容性。它预装了 Neovim、Docker、Git 等开发工具，提供开箱即用的现代化开发环境。Cloudflare 的全球 CDN、R2 存储和 DDoS 防护能力显著提升了其镜像下载速度与可用性。

Cloudflare 强调，此次支持无任何附加条件，纯粹出于对开放互联网生态的共同信念。两个项目分别从客户端（浏览器）和开发环境两个层面，为打破技术垄断、增强选择多样性提供了重要路径。

HN 热度 590 points | 评论 370 comments | 作者：jgrahamc | 11 hours ago #

https://news.ycombinator.com/item?id=45332860

Cloudflare 支持 Ladybird 浏览器可能意在推动未来仅允许经过批准的浏览器访问网络，这与独立开源浏览器的理念相悖，其真实动机值得怀疑。
Cloudflare 支持 Ladybird 类似于 Valve 投资 Proton，是为了减少对其他大型公司平台的依赖，进行战略上的风险对冲。
当前浏览器引擎主要由 Google 和 Apple 控制，若 Google 成为唯一的 Web 引擎权威，将对行业产生重大影响，因此支持新兴浏览器是合理举措。
Apple 在浏览器领域的控制力并不稳固，未来可能面临 Google 通过市场策略削弱 Safari 影响力的局面。
Google 已通过多种方式推广 Chrome，如在搜索和 YouTube 中强制弹出提示、捆绑安装等，推动用户使用 Chrome。
许多开发者倾向于仅支持 Chrome，以避免使用 polyfills 或查阅 CanIUse 表格，简化开发和测试流程。
企业级应用中已普遍存在“仅支持 Chrome”的现象，即使在 iOS 上也如此，这表明开发者更愿意针对 Chrome 优化而非遵循开放标准。
若苹果被迫允许在 iOS 上使用 Blink 引擎，Google 可通过市场宣传和开发者引导，迅速削弱 Safari 的市场份额。
Google 对浏览器生态的影响力源于其广告垄断带来的巨额资金支持，而非技术控制。
尽管 Chromium 是开源项目，但 Google 通过持续投入和主导开发，实际上拥有对整个生态的“事实控制权”。
即使微软可以快速 fork Chromium，但大多数用户不会使用其分支，因此 Google 仍能主导发展方向。
Google 对 Chromium 的控制体现在其对关键功能（如 DRM）的决策权，这些变化会迅速影响所有基于 Chromium 的浏览器。
Chromium 的开发流程中，Google 的 Chrome 版本先行决定功能走向，再将部分功能开放给 Chromium，形成事实上的主导地位。
一些开发者工具（如 Adblock）因与 Chrome 生态冲突而遭遇限制，反映出 Google 对生态的深度影响。

OpenAI and Nvidia announce partnership to deploy 10GW of Nvidia systems #

https://openai.com/index/openai-nvidia-systems-partnership/

OpenAI 与 NVIDIA 宣布一项战略性合作，计划部署至少 10 吉瓦的 NVIDIA 计算系统，用于支持 OpenAI 下一代 AI 基础设施的训练与运行。该合作旨在推动超级智能的发展，首批 1 吉瓦系统预计于 2026 年下半年在 NVIDIA 的 Vera Rubin 平台上投入使用。

为支持这一部署，NVIDIA 将分阶段向 OpenAI 投资最高达 1000 亿美元，每部署 1 吉瓦系统即完成相应投资。此次合作标志着双方在十年技术协作基础上的进一步深化，从早期 DGX 超级计算机到 ChatGPT 的突破，双方持续推动 AI 技术进步。

OpenAI 首席执行官 Sam Altman 强调，计算基础设施将成为未来经济的核心。NVIDIA 首席执行官 Jensen Huang 表示，此次合作是迈向智能新时代的关键一步。OpenAI 将与 NVIDIA 作为首选战略计算与网络合作伙伴，共同优化 AI 模型、软件与硬件的协同发展路线图。

该合作也与 OpenAI 已有的全球合作伙伴网络相辅相成，包括微软、Oracle、软银及 Stargate 等，共同构建世界最先进的 AI 基础设施。目前 OpenAI 已拥有超过 7 亿周活跃用户，广泛服务于全球企业、中小企业和开发者。此次合作将进一步加速其构建对全人类有益的人工通用智能（AGI）的使命。

双方将在未来几周内完成合作细节的最终确认。

HN 热度 374 points | 评论 492 comments | 作者：meetpateltech | 8 hours ago #

https://news.ycombinator.com/item?id=45335474

数据中心的规模通常以电力消耗（如千瓦、兆瓦、吉瓦）来衡量，因为电力基础设施是数据中心建设中最难更改的部分，而计算能力可以随时间升级。
人工智能的发展正在推动数据中心对电力的巨大需求，这种增长导致了美国居民电价的显著上升，引发了对电力成本分摊公平性的担忧。
当前美国电网基础设施老化，难以支撑大规模数据中心的用电需求，而电力成本的增加主要由向可再生能源转型所驱动，而非单纯的数据中心扩张。
尽管数据中心的电力需求巨大，但其电力消耗是固定的，即使内部计算能力提升，电力需求也基本不变，这使得电力容量成为数据中心规划的核心。
有人将 AI 数据中心比作“能源精炼厂”，将电能转化为数据，强调能源是 AI 发展的基础原料，而数据中心则是实现这一转化的场所。
电力供应的瓶颈不仅体现在总量上，也体现在局部电网的承载能力，例如某些数据中心虽有空余机柜，但因电力容量不足而无法使用。
随着芯片制程技术的进步，如台积电 N2 节点，能效提升显著，这有助于缓解数据中心的能源压力，是应对能源挑战的关键技术。
电力成本的上涨对普通家庭影响较大，尤其在低收入群体中更为明显，而大型数据中心往往能通过政策优惠或成本转嫁规避这部分压力。
从长期来看，电力价格的上涨趋势与工资增长基本持平，因此对整体家庭支出的影响可能被工资增长部分抵消，但对特定群体仍构成负担。
一些人指出，数据中心的高能耗问题不应由普通居民承担，而应由企业或政府共同分担基础设施升级的成本，以实现更公平的电力分配。

Cap’n Web: a new RPC system for browsers and web servers #

https://blog.cloudflare.com/capnweb-javascript-rpc-library/

Cap’n Web 是一个基于纯 TypeScript 的新型 RPC（远程过程调用）系统，专为浏览器和 Web 服务器设计，是 Cap’n Proto 的“精神兄弟”。它无需 schema 和大量样板代码，开箱即用，支持在浏览器、Cloudflare Workers、Node.js 等现代 JavaScript 环境中运行。

Cap’n Web 的核心特性包括：

无 schema 设计：无需定义接口文件，直接使用 JavaScript/TypeScript 类和方法。
人类可读序列化：底层使用 JSON，仅做少量预处理，便于调试。
多传输协议支持：原生支持 HTTP、WebSocket 和 postMessage，易于扩展。
极小体积：压缩后小于 10 KB，无外部依赖。
MIT 开源许可：自由使用和修改。

它采用对象能力（object-capability）模型，具备强大功能：

支持双向调用：客户端可调用服务端，服务端也可回调客户端。
函数和对象按引用传递：传递函数或继承 RpcTarget 的对象时，接收方调用的是远程执行的“桩”（stub），实现真正的远程调用。
Promise 链式调用（Pipelining）：可将多个 RPC 调用串联，仅需一次网络往返，显著提升性能。
强安全模型：基于能力的安全机制，适合复杂安全边界场景。

使用示例极简：

客户端通过 newWebSocketRpcSession 建立连接，直接调用远程方法。
服务端在 Cloudflare Worker 中只需继承 RpcTarget，实现方法即可，无需额外配置。

Cap’n Web 特别适合构建实时协作型 Web 应用、微服务间通信，以及需要安全能力控制的场景。尽管仍处于实验阶段，但其设计贴近现代 JavaScript 编程范式，极大降低了 RPC 的使用门槛，让开发者能像调用本地函数一样编写远程调用逻辑。

HN 热度 357 points | 评论 171 comments | 作者：jgrahamc | 11 hours ago #

https://news.ycombinator.com/item?id=45332883

Cap’n Web 通过记录客户端执行回调时的 RPC 操作序列来实现数组映射，而非直接传输 JavaScript 代码，这种方式既巧妙又存在潜在问题。
由于 JavaScript 缺乏类似 C# 表达式树（Expression Trees）的机制，无法在运行前分析函数逻辑，因此必须采用“执行一次并记录”的方式来捕获操作。
用 .toString() 解析函数源码并生成 AST 的方案虽然理论上可行，但在小型库中实现复杂度太高，难以控制体积。
使用特殊占位值（如 RpcPromise）进行记录时，条件判断逻辑可能因类型强制转换而失效，导致映射结果错误。
JavaScript 中所有对象都为真值且可被字符串化，这使得条件判断和字符串拼接容易产生不可预期的结果。
map() 函数名称容易引起误解，因为它并非传统意义上的数据转换，而是用于定义远程数据关联（如 join），名称与实际用途不符。
为提高安全性，可考虑不接受普通函数作为参数，而是使用特定结构化的 DSL 表达式，但可能增加使用复杂度。
通过引入类似 eq、gt 等可追踪的函数，可以实现对查询条件的远程执行，类似 Tanstack DB 的实现方式。
未来可考虑支持索引参数，尽管其值为 Promise，但可用于某些特定场景下的远程操作。

Tell the EU: Don’t Break Encryption with “Chat Control” #

https://www.mozillafoundation.org/en/campaigns/tell-the-eu-dont-break-encryption-with-chat-control/

Mozilla 发起紧急行动，呼吁欧盟拒绝“聊天监控”（Chat Control）法案。该法案要求科技公司对用户私密消息进行“客户端扫描”（Client-side Scanning, CSS），即使消息采用端到端加密，也需在发送前被检查。

这一措施将严重破坏加密技术的完整性，使用户的聊天记录、照片和文件在加密前就可能被读取，导致个人隐私暴露，面临黑客、企业及政府的监控风险。Mozilla 强调，这不仅威胁数字安全，更会动摇人们对互联网的信任，改变人们在线交流的方式。

客户端扫描虽以儿童安全为名，但实际存在严重缺陷：检测工具易出错，可能误报，且一旦开启，监控范围极易扩大，从儿童性虐待内容（CSAM）扩展至其他敏感对话。更危险的是，它会为系统引入新的安全漏洞，使所有用户面临更大风险。

受影响的服务包括 WhatsApp、Signal、iMessage、Telegram、Messenger、iCloud、Google Drive 和 Microsoft OneDrive 等广泛使用的加密通讯与云存储平台。

Mozilla 呼吁欧盟政策制定者：

保护加密技术，确保端到端加密服务完全排除在强制检测之外；
拒绝任何削弱加密、破坏设备安全或制造数字漏洞的措施；
依赖独立专家（如密码学家、儿童保护专家、人权倡导者）制定技术可行且比例适当的解决方案。

公众可通过 Mozilla 官方网站签署请愿书，向欧盟表达反对“聊天监控”、捍卫加密与数字自由的立场。同时建议用户查看 fightchatcontrol.eu 地图，了解本国政府立场，并联系本国议员，共同推动保护隐私的决策。

HN 热度 315 points | 评论 115 comments | 作者：nickslaughter02 | 14 hours ago #

https://news.ycombinator.com/item?id=45331217

将加密通信监控比作强制在每户家庭安装监控摄像头，认为即使政府承诺不滥用，也会成为黑客和敌对国家的首要目标，严重威胁所有人隐私与安全。
欧盟立法者自身享有豁免权，暗示其深知此类监控技术存在严重安全隐患，或可能涉及自身不当行为，因此不应要求普通公民承担风险。
当前社会已陷入“设备非真正拥有”的困境，用户无法自由控制手机等设备，这种观念为政府强制监控提供了便利，必须重新确立设备所有权的法律原则。
手机与住宅不同，用户无法像在家中那样自由修改或移除设备中的监控功能，且操作系统和应用商店限制了用户自主权，使得强制监控更具侵入性。
将“聊天监控”与“五眼联盟”的大规模监控项目（如 ECHELON）类比，指出此类监控早已存在，不应被夸大为新威胁，但需警惕其对隐私的长期侵蚀。
2013 年斯诺登事件后，公众才真正意识到大规模监控的现实，推动了端到端加密技术（如 Signal）的发展，说明公众对监控的警惕是合理且必要的。
欧盟若通过此类法案，将为其他国家（如威权国家）要求科技公司开放加密提供先例，削弱全球数字隐私保护的正当性。
欧盟自诩为“人权堡垒”只是自我宣传，其内部权力运作与全球其他西方国家并无本质区别，不应因其相对温和而忽视其政策的潜在危害。
建议先对欧盟议员的通信进行公开透明化处理，作为“试验性”措施，以检验其对监控的真正立场。
欧盟内部官员自身豁免于监控，说明他们清楚此类技术不可靠且危险，其对公民通信的监控要求缺乏道德与逻辑正当性。
真正的隐私保护应涵盖所有群体，包括受害者、心理咨询者和企业，不应因所谓“儿童保护”而牺牲普遍通信安全。

Download responsibly #

https://blog.geofabrik.de/index.php/2025/09/10/download-responsibly/

GEOFABRIK 近期对其下载服务器基础设施进行了升级，使得数据下载速度更快、可用时间更早。同时，针对请求“latest”文件的请求，现采用 HTTP 重定向至具体最新版本的方式，以提升效率。

作者呼吁用户“负责任地下载”数据。近期发现个别用户频繁重复下载大型文件（如意大利数据文件），一天内下载近万次，严重影响服务器性能，导致其他用户访问变慢。此外，因滥用行为导致的 IP 封禁，也可能波及无辜用户。

为此，提出三点建议：

若需全球数据，建议直接从 planet.openstreetmap.org 获取完整行星文件，无需通过 GEOFABRIK 分块下载。
若需大区域（如欧洲或北美）每日更新，推荐使用 pyosmium-up-to-date 工具，仅下载增量变更，节省约 98% 的流量，且速度更快。
自动化脚本应具备监控和容错机制，避免因磁盘满等异常情况导致重复下载同一文件上千次。

GEOFABRIK 希望持续为用户提供高效、便捷的服务，但需依赖用户的共同维护与合理使用。

HN 热度 311 points | 评论 214 comments | 作者：marklit | 18 hours ago #

https://news.ycombinator.com/item?id=45329414

BitTorrent 由于与非法下载的关联，导致其在公众和企业环境中声誉不佳，阻碍了其广泛应用。
企业网络防火墙通常限制 BitTorrent 流量，因其可能被用于非法活动，且配置复杂，需管理员额外审批。
多数公司电脑和 CI/CD 流程中未预装 BitTorrent 客户端，用户习惯使用简单的 curl 等命令进行下载。
许多人误以为使用 BitTorrent 必须持续“做种”（seed），担心长期占用带宽和存储，因而望而却步。
尽管 BitTorrent 是高效、去中心化的文件传输协议，但其在容器镜像、软件包仓库等场景中应用极少，被严重低估。
一些合法用途如 Ubuntu ISO 下载、OpenStreetMap 数据分发、Wikipedia 数据库镜像等已使用 BitTorrent，但普及度仍低。
企业 IT 安全策略常将 BitTorrent 客户端标记为“潜在恶意程序”，即使其本身无害，也容易引发误报和审查。
即使是合法使用 BitTorrent，也可能因流量特征被误判，导致被 IT 部门警告或调查，带来心理压力。
有案例显示，员工因在实验室电脑上无意持续种子系统镜像，被 IT 管理员询问，但最终被允许继续运行。
一些云服务（如 AWS S3）曾支持 BitTorrent，但已逐步弃用，反映出主流技术生态对它的冷落。
法律层面，虽然个人下载电影在部分国家合法，但律师仍可能发出停止侵权函，造成心理威慑。
自动化 DMCA 通知系统主要针对公开共享的受版权保护内容，普通用户很少收到正式的停止侵权函。
企业对 BitTorrent 的排斥，本质上是出于对潜在安全风险的防范，如数据外泄、恶意软件传播等。
个人认为，比起 BitTorrent 的“坏名声”，大公司滥用用户数据的问题更应受到关注，但现实中公众更关注前者。
在部分国家，如欧盟，由于流媒体服务竞争激烈，导致非法下载行为反而更普遍，进一步强化了 BitTorrent 的负面印象。

Tesla coast-to-coast FSD crashes after 60 miles #

https://electrek.co/2025/09/21/tesla-influencers-tried-elon-musk-coast-to-coast-self-driving-crashed-before-60-miles/

特斯拉股东兼网络博主尝试完成埃隆·马斯克曾承诺的跨大陆自动驾驶旅程，但在行驶约 60 英里后因未能避开路障而发生事故。2016 年，马斯克曾宣称特斯拉将在 2017 年底前实现从洛杉矶到纽约的全程自动驾驶并直播，但这一目标至今未实现。

此次测试由两名特斯拉股东兼 YouTube 创作者执行，驾驶一辆搭载最新 FSD v13.9 系统的 Model Y，从加州圣地亚哥出发，计划前往佛罗里达州杰克逊维尔。然而，车辆在加州境内就因未能及时避让道路障碍物而撞毁，导致防倾杆支架断裂、悬挂系统受损，并触发多项警告。

视频显示，驾驶员在事故发生前双手未握方向盘，尽管乘客早已发现障碍物，但驾驶员直到最后一刻才做出反应。整个旅程仅完成约 2.5% 的计划路线。

作者指出，尽管特斯拉仍处于 L2 级辅助驾驶阶段，且需驾驶员持续监控，但市场对“完全自动驾驶”的期待已高度依赖于马斯克的承诺。如今，特斯拉在自动驾驶技术上明显落后于 Waymo 等竞争对手，真正的“99.999999999%”可靠性尚未达成。

有评论认为，这两位博主的行为值得肯定——他们主动验证了 FSD 的实际能力，即使结果不理想也公开视频，展现了理性与诚实，远胜于盲目相信马斯克的宣传。类似事故在 2020 年也曾发生，当时一辆租用的 Model 3 在 Autopilot 模式下撞上路中轮胎，维修费用高达约 1 万美元。此次事故的修复成本也可能相当高昂。

HN 热度 279 points | 评论 362 comments | 作者：HarHarVeryFunny | 12 hours ago #

https://news.ycombinator.com/item?id=45332120

Elon Musk 很少为自己的言论承担责任，公众也缺乏直接问责的意识，这种行为在拥有巨大权力和影响力的人身上尤其不可接受。
在美国，道歉或承担责任往往被视为失败，而无视批评、持续推卸责任反而能带来更大的成功，这是过去几十年形成的一种文化现象。
工程文化中，承认错误和失败能增强信任和专业性，而总是找借口或推卸责任的人会被认为缺乏能力和诚信。
一些公司如波音在转型为商业文化后，逐渐失去了原有的工程文化，而特斯拉则鼓励一种“说谎”的文化，甚至有工程师为夸大性能数据而撒谎。
组织文化对工程师行为有决定性影响，如果公司一味削减成本、裁减资深员工，即使工程师个人再努力也难以改变整体风气。
有些公司依然保持尊重事实、承认错误的文化，这类公司更受专业人士青睐，也更容易获得客户信任。
真诚道歉是化解愤怒、平息矛盾最有效的方式，但这种做法在像马斯克这样的领导者看来是软弱的表现。
有案例显示，因道歉而被上司责骂的员工，反而因真诚态度赢得了客户的尊重和更高职位的机会。
日本文化中似乎更注重道歉与感谢，这种态度有助于长期成功。
领导者的行为往往基于对“成功”的错误理解，比如将乔布斯的专横行为视为成功的模板，导致不良文化蔓延。
Elon Musk 支持新纳粹主义，倡导“回迁”等白人至上主义言论，其言行存在严重问题。
由于拥有巨额财富和影响力，Elon Musk 可以肆意行事而无需承担后果，这种权力不对等使得问责机制失效。
从 2020 年起，已不再相信 Elon Musk 关于自动驾驶的任何言论，因为他过去有太多不实陈述。
Elon Musk 曾参与并动员右翼极端分子在伦敦举行大型抗议活动，显示出其在政治上的极端倾向。

Why haven’t local-first apps become popular? #

https://marcobambini.substack.com/p/why-local-first-apps-havent-become

这篇文章由 Marco Bambini 撰写，探讨了 “本地优先”（Local-First）应用程序未能普及的原因。文章强调了离线优先应用程序的潜力，承诺提供即时加载和默认隐私保护，但实际上很少有应用程序能够正确实现离线支持。

** 离线优先应用的挑战 **：
- 许多应用程序仅仅是将变更排队到网络恢复时再推送，而这种方法在用户看到 “变更可能未保存” 的警告时显得很不可靠。
- 这主要是因为同步（sync）问题非常复杂。
** 分布式系统的复杂性 **：
- 构建本地优先应用程序实际上意味着创建一个分布式系统。多个设备可以独立地、在离线状态下修改数据，最终需要在不丢失数据的情况下收敛到相同的状态。

主要挑战

不可靠的顺序（Unreliable Ordering）
- 在分布式环境中，事件在多个设备上以不同时间发生。如果简单地按照到达的顺序应用变更，结果可能不一致。
- 例如：设备 A 将 x 设置为 3，设备 B 将 x 设置为 5，当它们同步时，x 的最终值取决于哪个更新先被应用。
冲突（Conflicts）
- 即使有了正确的顺序，当两个设备独立修改同一数据时，仍然会发生冲突。
- 例如：初始余额为 100，设备 A 增加 20，余额为 120，而设备 B 减少 20，余额为 80，当同步时，应该以哪个值为准？

解决方案

混合逻辑时钟（Hybrid Logical Clocks, HLCs）
- HLCs 生成可比较且因果一致的时间戳，允许设备在没有完美同步时达成事件的顺序一致性。
- 这种方法结合了物理时间和逻辑时间，确保即使时钟不同步，设备之间仍可协商 “哪个事件先发生”。
冲突解决数据类型（CRDTs）
- CRDTs 保证了变更的交换顺序不影响最终状态，并且重复应用相同的变更不会产生副作用。
- 最简单的策略是 “最后写入胜利”（Last-Write-Wins, LWW），即更新带有时间戳，时间戳最新的更新将获胜。

为什么选择 SQLite

SQLite 是构建本地优先应用的理想选择，因其轻量、可靠且可在各种平台上使用。
文章提到了一种将每个变更存储为消息的架构，确保最终状态的一致性。

结论

开发者应停止通过请求队列假装支持离线，拥抱最终一致性，采用经过验证的分布式系统技术如 HLC 和 CRDT。
采用小型、无依赖的架构，可以创建快速、离线支持、默认保护隐私的应用程序。

最后，文章鼓励读者查看其开源的 SQLite-Sync 扩展，以获取生产级的跨平台离线优先引擎。

HN 热度 273 points | 评论 291 comments | 作者：marcobambini | 11 hours ago #

https://news.ycombinator.com/item?id=45333021

CRDTs 虽然理论上能解决数据冲突问题，但构建符合用户直觉和业务逻辑的 CRDT 模型非常复杂，且需要持续重建数据状态，实现成本高。
存在无需 CRDT 的替代方案，例如通过合理设计文本处理逻辑来实现离线编辑，避免复杂的数据同步问题。
在没有时钟或 CRDT 的情况下，两个用户对同一段落进行不同修改，无法自动解决冲突，需人工干预或特定策略。
过去几乎所有软件都是本地优先的，但如今企业更倾向于通过控制用户数据来最大化利润，导致本地优先应用缺乏动力。
大多数应用本可轻松实现离线功能，如缓存地图瓦片或媒体列表，但开发者为获取用户数据或广告收入而故意不实现。
一些公司故意让本地数据过期，以迫使用户持续依赖其服务，例如苹果的离线地图和特斯拉的导航数据。
正确使用 Cache-Control 头部和网络层缓存机制，可显著提升离线体验，且无需修改应用代码即可调整缓存策略。
过度强调“本地优先”等概念会分散开发者对核心功能的注意力，导致产品整体体验下降。
自托管服务（如 Immich）虽然功能强大，但安装配置复杂，难以吸引普通用户，与本地优先应用的普及目标不符。
自托管与本地优先是两个不同概念，前者涉及服务器运维，后者关注客户端数据控制与离线使用。
本地优先应用的商业模式不清晰，难以实现盈利，导致开发者缺乏动力，唯有开源社区热情可能推动其发展。
当前市场只有“付费换数据”或“免费换注意力”两种模式，真正“付费不交数据”的商业模式难以生存。
闭源本地应用存在长期数据访问风险，用户无法保证未来仍能访问自己的数据，因此依赖开源或开放格式更安全。
只要底层数据存储格式开放且通用（如 Markdown、PNG/JPG、SQLite），用户即使面对闭源应用也能长期自主访问数据。
本地优先应用的普及需要建立开放协议和基础设施支持，例如由 Dropbox 等平台提供统一的离线应用支持服务。

Privacy and Security Risks in the eSIM Ecosystem [pdf] #

https://www.usenix.org/system/files/usenixsecurity25-motallebighomi.pdf

论文题目：eSIMplicity 还是 eSIMplification？eSIM 生态中的隐私与安全风险

一句话总结：作者通过大量实测发现，旅行 eSIM 和众多在线转售商存在数据跨境、权限过大、删卡失败等真实隐患，呼吁监管、厂商和用户共同加固安全。

研究背景：

eSIM 不用插拔实体卡，远程下载即可上网。GSMA 预测到 2028 年一半智能手机会支持 eSIM。旅行 eSIM 市场爆发，几百家网店卖流量包，监管几乎空白。

主要发现：

数据主权：90% 旅行 eSIM 把流量先绕回母国，美国本地测试却分到外国 IP，用户全部上网记录可被外国运营商看到。
转售商权限：只需邮箱注册就能成为“白牌运营商”，可批量查询用户 IMSI、手机号、PIN 甚至实时大致位置，还能静默发二进制短信。
静默行为：部分旅行卡半夜主动连新加坡服务器或取香港短信，用户毫无感知。
删除失败：离线删卡时服务器收不到通知，原二维码作废，用户无法重装，旅行途中可能直接断网。
私网滥用：医院、展会自建 5G，扫码即入网，恶意配置文件可长期监听定位。
换机困难：有的 profile 与设备唯一编号绑定，手机损坏后必须人工客服迁移，易被社工攻击导致号卡被过户。

攻击场景举例：

会场里扫“免费上网”二维码，安装恶意 profile 后被长期定位，甚至通过二进制短信植入木马。
转售商数据库被拖库，海量用户 IMSI/PIN 泄露，可被批量克隆。
删卡时网络被拦截，服务器仍认为卡有效，用户重装失败当场失联。
冒充用户联系客服，仅提供手机号和账单邮编就能过户 eSIM，接管银行、社交账号的两步验证。

作者建议：

监管层面：明确数据出入境规则，强制披露流量路径；转售商需持牌经营，定期审计。

厂商/GSMA：保证删卡状态可靠送达；开放研究级测试证书，方便找漏洞。

用户层面：装卡前查公司背景、IP 归属；删卡务必连网；拒绝来路不明的免费二维码；定期清理不用 profile。

结论：

eSIM 把“插卡”变成“下载”，也把信任边界推向全球无数看不见的中介。只有监管同步、协议加固、用户警惕三管齐下，才能让 eSIM 真正简单而不简陋。

HN 热度 254 points | 评论 135 comments | 作者：walterbell | 19 hours ago #

https://news.ycombinator.com/item?id=45329127

eSIM 的安全风险主要源于其业务生态，而非技术本身，尤其是第三方网络路由和不透明的配置流程带来的隐私隐患。
尽管使用 TLS 加密，但数据路由路径本身仍可能暴露用户位置和行为模式，对普通用户而言仍具重要影响。
选择受监管的司法管辖区（如欧盟或美国）的网络服务，可能比完全不受控的境外服务更值得信赖，但实际可行性有限。
当前可用的隐私保护手段包括洋葱路由（Tor）、VPN 和使用主流 CDN，但各有局限，如速度慢、信任问题或中心化风险。
某些 eSIM 服务会将流量路由至香港或低质量运营商，导致延迟高、访问受限，甚至影响本地化服务体验。
一些 eSIM 服务提供商使用廉价的底层网络资源，服务质量差，常伴随广告和推广链接，影响用户体验。
在酒店等公共 Wi-Fi 环境中，DNS 劫持普遍存在，用户难以避免，必须通过技术手段应对。
使用 DoH（DNS over HTTPS）虽能提升隐私，但可能破坏 Wi-Fi 登录页面的正常流程，导致使用不便。
为应对 Wi-Fi 拦截，可采用隔离网络栈或客户端防火墙策略，但实现复杂，对普通用户不友好。
现实中用户需在理想安全与实际可用性之间权衡，无法完全依赖“数据不经过某国”来保证安全。