## 苹果的新隐私功能与蜂窝网络位置追踪 苹果的iOS 26.3推出了一项隐私功能，限制了与蜂窝网络共享的“精确位置”数据，但仅限于配备苹果2025年调制解调器的设备。虽然蜂窝塔三角定位的精度有限（数十米到数百米），但蜂窝标准秘密利用设备中的GNSS数据（GPS等）进行精确的位置追踪——精确到个位数米。 RRLP/LPP等协议允许网络*请求*并接收这些精确的GNSS数据，在后台无缝运行。这项能力并非新技术；诸如美国缉毒局和以色列辛贝特等机构已经利用它多年，甚至用于大规模监控，例如COVID-19接触者追踪。 作者指出潜在的漏洞，质疑这些协议是否可能被恶意行为者或外国政府利用。苹果的举措是一个积极的步骤，但他们提倡进一步的用户控制——允许禁用与运营商共享GNSS数据，并在发生此类请求时提供通知。这凸显了超出大多数用户认知范围的隐藏位置追踪层面。
每日HackerNews RSS
此文档似乎是一个PDF文件，主要包含元数据和内部结构信息，而非可读文本。内容由一系列数字代码（“xref”、“obj”、“stream”）和看似随机的字符（“hZiXSg>@ [+jiMbd...”）组成。 本质上，这是定义PDF文档的基础代码——指定了文件内不同元素的位置——但如果没有PDF阅读器解释，则无法向用户呈现任何可辨认的内容。它不是*关于*什么的文档；它*就是*文档本身的结构。 在没有进一步处理或合适的PDF渲染引擎的情况下，无法确定文件的原始内容。
## 苹果平台安全：摘要
最近一份苹果关于平台安全的文件（帖子中链接）引发了 Hacker News 的讨论，焦点集中在内存安全（C 编译方面）和整体安全措施的进步上。苹果修改了其 C 编译器，以防止常见的漏洞，如缓冲区溢出和类型混淆。这利用了较新处理器中的边界安全和内存标记。
然而，对话很快转向了对苹果隐私实践的担忧。用户指出，虽然苹果强调安全性，但 iCloud 备份默认情况下*不*是端到端加密的，这可能允许苹果访问用户消息。虽然“高级数据保护”提供端到端加密，但默认情况下未启用，并且许多用户不会激活它。
讨论还涉及了苹果对其平台的控制，与 Android 的开放性形成对比。一些人认为这种控制能够提供更强的安全性，而另一些人则认为它限制了用户自由。尽管苹果做出了安全努力，但人们对潜在的后门和政府访问表示担忧。最终，该讨论揭示了对苹果的复杂看法：一家在安全方面取得进展的公司，但仍然在需要数据访问和控制的商业模式下运营。
大学教授们面临着一个令人惊讶的挑战：学生们难以集中注意力于必修课程材料，甚至包括电影专业的*电影*。过去十年里，并且在疫情的影响下，教师们报告学生们越来越容易被手机分心，无法参与到长篇电影中。许多人甚至无法看完关键场景，表现出注意力持续时间缩短。 这不仅仅是缺乏兴趣的问题；学生们承认由于缺乏耐心而跳过内容或加快播放速度。虽然流媒体选择很方便，但往往会导致更低的参与度，追踪数据显示许多学生没有开始或完成指定的电影。 教授们认为这归因于在短视频和持续数字刺激中长大的这一代人——“无限滚动”是一个相对较新的现象。一些教授正在适应，通过分配较短的电影或专注于在简短视频中最大化参与度的方法，而另一些教授则试图通过故意节奏缓慢的电影来“重新训练”注意力持续时间。 核心问题凸显了学生媒体消费方式的重大转变，以及教育工作者在培养对更长、更复杂作品的深度参与方面所面临的挑战。
## 动画 AVIF：GIF 的替代品
作者推崇动画 AVIF 文件作为 GIF 的更优替代方案，理由是 AVIF 针对现代网络进行了更好的优化。虽然 GIF 具有其魅力，但 AVIF 动画提供了一种更高效的格式。
使用 FFMPEG 可以创建动画 AVIF。该过程涉及将视频源（或现有的 GIF）转换为 Y4M 中间文件，然后使用 `libsvtav1` 编解码器将其编码为 AVIF。关键的 FFMPEG 命令调整帧率（例如 `fps=15`）和缩放视频尺寸（例如 `scale=720:-1`）以进行优化。
值得注意的是，作者在 2025 年 12 月在 Debian 13 上直接编码为 AVIF 时遇到了问题，需要 Y4M 暂存步骤才能成功转换。他们希望未来不再需要此解决方法。本质上，AVIF 动画为循环视觉效果提供了一条有希望的途径，具有改进的性能。
## Hacker News 上关于 AVIF 的讨论
最近 Hacker News 上出现了一场关于 AVIF 图像格式实用性的讨论，尽管它在理论上具有优势。AVIF（基于 AV1 编解码器）提供卓越的压缩和透明度等功能，但许多用户报告在使用大量 AVIF 文件时，即使在现代硬件上，也存在**显著的性能问题**——特别是高 CPU 使用率。
核心问题似乎源于 AV1 解码的硬件加速有限，导致需要资源密集型的软件解码。一些评论员指出，Mac 电脑处理 AVIF 效果良好，而另一些人则强调 WebP 是一个可行的替代方案，具有更好的实际性能。
对话还涉及 AVIF 在处理带透明度的动画图像方面的潜力，这是常见格式（如 GIF）所缺乏的功能，以及浏览器支持方面的挑战（Safari 是一个值得注意的例外）。未来的视频编解码器，如 AV2，也被提及，它们承诺提供更好的压缩，但需要更多的处理能力。最终，讨论强调了理论优势和普通用户实际可用性之间的权衡。
经过一年尝试向OpenJDK贡献补丁，开发者xtex（张炳武）因Oracle贡献者协议（OCA）审核停滞而放弃努力。尽管在数月内多次跟进邮件，OCA仍未获得批准，回复仅表示道歉并请求另一方进一步审核。 xtex居住在中国大陆，但声明与任何受限制的实体无关，他希望如果存在疑虑，能够明确拒绝，而不是无限期延迟。由于对流程感到沮丧，且没有时间继续“维护”这些PR，xtex发布这些补丁供他人采用。 这些补丁包括修复了损坏的`llvm-config`检查以及JDK 24零变体中的堆栈溢出问题，以及最初计划用于龙芯JDK分叉的多个补丁。xtex鼓励任何感兴趣的人以原创作品的形式重写这些补丁，以避免OCA要求。相关提交和拉取请求的链接已提供。
## 开源贡献的挫败感与公司管控
一位开发者分享了他们尝试一年向OpenJDK贡献补丁的经历，最终因缺乏审查和优先级而放弃。 这引发了Hacker News上关于为大型开源项目贡献代码的挑战的讨论，特别是像Oracle这样有公司支持的项目。
许多评论者表示有类似经历——提交的补丁被忽略，难以从维护者那里得到回复，以及贡献除非来自大型公司（Google、Red Hat）的员工，否则不被重视的感觉。 一些长期参与开源的人员哀叹从协作精神转变为期望被接受，而另一些人则指出贡献不是理所当然的权利。
一个关键问题是维护者的负担，他们通常是志愿者，时间有限。 许多人指出，虽然琐碎的补丁对新手入门有好处，但也可能让维护者不堪重负。 讨论还涉及公司贡献者许可协议（CLA）以及对公司控制表面上开放的项目的问题。 几位评论员认为，目前的系统偏向于已建立的贡献者，并阻止了新人的加入。 最终，该讨论强调了在大型开源生态系统中导航的困难，以及对更好贡献者入职和审查流程的需求。
## 播客广告的十字路口 (2024 总结) 播客广告是一个24.3亿美元的市场，但面临一个关键挑战：广告数量增加正在导致听众流失。虽然每周有1.58亿美国人收听播客，但自2020年以来，广告时长增加了39%，现在平均在45分钟的节目中接近5分钟。这导致30%的听众*仅仅*因为广告过多而放弃节目。 研究表明存在“10%阈值”——超过这个广告时长会显著降低广告效果（转化率下降25-40%）。一些类型，如犯罪纪实，远远超过了这个阈值，达到34%的广告占比。 尽管存在风险，广告商仍在继续投入资金，因为播客通过主持人朗读广告建立了独特的亲密感和信任感。然而，数据表明每集2-3个广告（6-10%的运行时长）是平衡收入和听众留存的最佳点。近50%的听众可以容忍*合理的*广告，但26%的听众会因过度打断而离开。 播客的未来取决于优先考虑听众忠诚度，而不是最大化短期广告收入。
## 播客广告现状与听众沮丧
最近在Hacker News上出现了一场讨论，主要围绕播客中广告数量增加的问题，以及这些广告最终是否会损害这种媒介。核心观点是，过多的广告会驱赶听众，从长远来看可能会损害播客创作者的利益。
许多评论者分享了减少广告干扰的方法——使用应用程序自动跳过片头广告，利用快进按钮，或在可能的情况下选择无广告订阅。甚至有人表示会*购买*播客中宣传的产品。然而，人们也对播客的经济模式表示担忧，一些人认为目前的系统令人费解地可持续。
人们探讨了替代广告支持模式的方法，包括通过Patreon等平台进行直接听众支持，甚至使用BitTorrent等去中心化分发方式。YouTube作为播客平台的兴起也受到了关注，一些创作者在那里提供无广告版本，并使用Sponsorblock等广告拦截插件。
最终，这场讨论凸显了支持创作者和保持积极聆听体验之间的紧张关系，许多人认为动态插入的、重复的广告尤其令人沮丧。
## CPython-Internals：深入剖析Python的实现
“CPython-Internals”仓库是对CPython解释器源代码的详细探索，旨在阐释其内部运作机制。它基于CPython 3.8.0a0版本构建，面向有兴趣了解Python底层*如何*运作的Python程序员。
该仓库分为几个部分，涵盖核心Python **对象**（如字典、列表和类）、**模块**（包括`io`、`pickle`、`re`和`asyncio`）、**解释器**本身（GIL、垃圾回收、异常处理和导入机制），以及**扩展**的可能性（C API、Cython和C++集成）。它还涉及从语法到字节码的编译过程。
除了代码相关的文档外，该仓库还提供了一份精选的**学习资料**清单——书籍、博客和视频，供进一步学习。欢迎贡献，包括知识共享、更正和翻译的拉取请求，以及建议和问题的提交。
该资源拥有超过4.4k星标和458个fork，对于那些寻求更深入理解Python实现的人来说，它是一个宝贵的资源。
## CPython 内部原理与 Python 实现讨论
最近 Hacker News 上的一条链接（github.com/zpoint）引发了关于 CPython 实现细节的讨论。 许多评论者分享了深入研究 C 代码的经验，指出其混合了现代和较旧的风格，并且由于缺乏易于“Google 搜索”的细节，导致查找信息具有挑战性。 一些人发现基于代理的编码工具对架构问题有帮助，而另一些人则强调了人工智能在处理复杂方面（例如广泛使用实用宏）时会遇到的困难。
对话还涉及 Python 及其实现（CPython、PyPy 等）之间的关系，并争论是否在讨论 Python 时应始终指定“CPython”。 许多人认为，只有在与替代实现进行对比时才需要这样做。 讨论还包括 Python 和 JavaScript (V8) 之间的性能差异，声称 Python 中的技术债务阻碍了优化，以及 Python 3.13/3.14 中最近添加的实验性 JIT 编译器。 分享了有关 CPython 内部原理的更多探索资源，包括文档链接。
## Nvidia Shield TV：十年的支持与独特方法
一篇Ars Technica的文章引发了Hacker News上关于英伟达对Shield TV持续更新十年承诺的讨论，这种做法在Android TV领域几乎是无与伦比的。用户认为这种长寿归功于英伟达的**垂直整合**——控制着硬件和软件，从而能够绕过像高通这样的公司施加的典型SoC（系统级芯片）支持限制。
虽然良好的文档*可以*实现长期支持，但讨论强调，如果芯片制造商放弃平台，仅仅依靠制造商的意愿是不够的。据报道，英伟达的首席执行官优先考虑继续更新Shield TV，并为此投入了大量预算。
许多用户赞扬Shield即使在十年后仍能持续运行，并对缺乏有竞争力的替代品感到遗憾。一些人建议探索Apple TV或Ugoos设备等选项，但承认存在权衡。对话还涉及了Android TV令人沮丧的现状，竞争产品充斥着广告和过时的硬件。
最终，Shield TV成为一款获得持续支持的罕见设备，引发了人们的疑问：为什么英伟达会继续这项努力，同时大力关注人工智能市场。
Meta正面临指控，源于最近的诉讼和美国调查报告，称其能够访问用户的加密WhatsApp聊天记录——尽管该平台声称实现了端到端加密。该诉讼由Quinn Emanuel Urquhart & Sullivan提起，基于匿名举报人的说法，声称Meta可以访问“几乎所有”用户通信。 Meta强烈否认这些指控，称其“绝对不属实”，并暗示该诉讼是为了支持NSO Group，一家最近在WhatsApp提起的案件中败诉的间谍软件公司。Meta正在寻求对Quinn Emanuel的制裁，指控其进行宣传噱头。 专家对此表示怀疑，指出在大型公司内部掩盖此类漏洞的难度。虽然WhatsApp会收集用户元数据，但访问消息*内容*的核心说法存在争议。美国商务部的调查尚未得到证实。Meta坚持WhatsApp的加密是安全的，并承诺捍卫用户隐私。
黑客新闻 新 | 过去 | 评论 | 提问 | 展示 | 招聘 | 提交 登录
美国据报正在调查指控，称Meta可以读取加密的WhatsApp消息 (theguardian.com)
174点 由 echelon_musk 1天前 | 隐藏 | 过去 | 收藏 | 1条评论
dang 1天前 [–]
评论已移动至 https://news.ycombinator.com/item?id=46838635，其中包含原始来源。回复
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请YC | 联系
搜索：
## htmx Server-Sent Events (SSE) 扩展总结 htmx-ext-sse 扩展通过连接到服务器发送事件 (SSE) 流，实现网页的实时更新。SSE 是 WebSockets 的一种轻量级替代方案，通过标准的 HTTP 连接运行 – 使其防火墙友好。与 WebSockets 不同，SSE 是**单向的**（仅服务器到客户端）。 **主要特性与属性：** * **`hx-ext="sse"`**: 在 HTML 元素上启用扩展。 * **`sse-connect="<url>"`**: 指定 SSE 服务器的 URL。 * **`sse-swap="<message-name>"`**: 定义哪个服务器消息更新元素的内容。 * **`hx-trigger="sse:<message-name>"`**: 基于 SSE 消息触发 HTTP 回调。 * **`sse-close=<message-name>`**: 收到特定消息时，优雅地关闭连接。 **安装：** 可以通过 CDN 或 npm 轻松添加，确保在加载扩展*之前*加载 `htmx.org`。 **接收事件：** SSE 消息包括事件名称和数据。使用 `sse-swap="message"` 处理未命名的事件，并使 `sse-swap` 值与服务器的事件名称匹配以处理命名的事件。 可以在同一元素或子元素上监听多个事件。 该扩展还包括自动重连逻辑以提高可靠性，并分发自定义事件以进行生命周期管理（连接打开、错误、消息、关闭）。 提供了一个演示服务器用于测试。 此扩展取代了旧的 `hx-sse` 属性，现有用户需要迁移。
## HTMX 更新与替代方案：摘要
一则黑客新闻讨论集中在 HTMX 库的近期和潜在变化上，该工具使用 HTML 属性构建服务器驱动的 UI。即将到来的 HTMX v4 最初将包含服务器发送事件 (SSE) 作为核心功能，但开发者正在考虑将其移回扩展，原因是重新设计的 WebSocket 扩展 – 旨在避免偏袒某种流式传输方法。核心扩展（SSE、WebSocket 等）将一起发布，以便更轻松地组合。
对话还强调了替代方案，如 **Datastar**，它提供类似的功能并包含 SSE 支持，具有客户端变量管理等功能，以简化状态处理。 许多用户正在构建自己的框架，灵感来自 Datastar，例如 **Hyperstar**，以实现更像 SPA 的语法。
讨论涉及 HTMX 为寻求简洁性的后端工程师带来的好处，并承认 HTMX 功能强大，但存在局限性 – Datastar 在处理大型数据集的虚拟滚动方面表现出色。最终，用户赞赏 HTMX 减少前端复杂性的能力，但一些人担心更改会破坏现有的简单设置。