Psylo 的研究人员在苹果的 WebKit 引擎中发现了三个关键漏洞，这些漏洞会导致 iOS 和 macOS 系统出现隐私泄露。这些缺陷会绕过应用层的代理配置，从而暴露用户的真实 IP 地址和 DNS 查询记录。
这三个已识别的绕过漏洞包括：
1. **DNS 预取（DNS Prefetching）：** 允许网站通过设备的标准网络解析主机名，从而绕过配置的代理。
2. **WebAuthn 相关来源请求：** 触发系统级的凭据服务获取，该过程会忽略浏览器层级的代理设置，进而暴露用户的真实 IP。
3. **WebTransport：** 建立直接的 HTTP/3 连接，完全绕过代理路由。
这些漏洞影响了所有依赖 WebKit 的 `WKWebsiteDataStore.proxyConfigurations` API 的 iOS 浏览器，包括 Tor 浏览器和苹果自家的 iCloud 专用代理（iCloud Private Relay）。值得注意的是，全系统 VPN 不受影响，因为它们会对设备的所有流量进行隧道传输。
为解决这些问题，Psylo 浏览器（1.3.1 版本）已进行更新，默认拦截 DNS 预取提示，并禁用 WebTransport 和 WebAuthn。如有需要，用户可以针对特定网站重新启用这些功能。建议开发者通过提供的概念验证网站 `leaks.psylo.app` 测试其自身的配置。
每日HackerNews RSS
研究人员 Tommy Mysk 和 Talal Haj Bakry 发现了 WebKit 中的漏洞，这些漏洞会导致 IP 和 DNS 泄露，从而削弱 iCloud 专用代理（iCloud Private Relay）及苹果设备上代理浏览器等隐私工具的保护作用。
一个关键发现是，WebKit 通过一个独立的系统进程来处理 WebAuthn（用于通行密钥）等 API 的请求，该进程会绕过代理保护，从而暴露用户的真实 IP 地址。由于苹果规定 iOS 平台上的所有浏览器都必须使用 WebKit 引擎，因此这些泄露几乎影响了该平台上的所有浏览器。这也促使一些开发者构建“加固版”浏览器，试图禁用 WebAuthn、WebTransport 和 DNS 预获取等存在问题的特性。
Hacker News 上的讨论凸显了用户对 iCloud 专用代理缺乏透明度和控制权的不满。参与者争论这些泄露究竟是技术疏忽还是系统性的架构缺陷，并指出苹果封闭的生态系统使得第三方浏览器难以彻底解决这些问题。用户希望能有更精细的控制权限，例如为专用代理提供可脚本化的开关；但也有观点认为，这些控制选项被刻意限制，是为了防止恶意应用程序的干扰。
此 Rust crate 提供高性能的前向纠错（FEC）功能，专为软件定义无线电（SDR）和卫星通信而设计。它实现了两种主要的编码方案：
* **卷积码：** 支持多种编码率（1/2 到 1/8）和约束长度（k=4 到 k=16）的维特比（Viterbi）译码（硬判决和软判决）。在 Rust nightly 版本上，它利用 SIMD（SSE/AVX2/AVX512）来获得卓越的性能。
* **里德-所罗门码（Reed-Solomon Codes）：** 实现了 GF(2⁸) 错误和删除译码，包括与常规和双基表示下的 CCSDS (255,223) 标准码完全兼容。
作为 `libcorrect` 和 `libfec` 等传统 C 库的现代替代品，此 crate 与 Phil Karn 的 `libfec` 位兼容。它提供了一个 `fec-shim` crate，为现有的代码库提供直接替换的 C ABI。该库遵循已发布的 CCSDS 标准，并以 BSD-3-Clause 许可证发布。未来计划改进的功能包括支持打孔码（punctured codes）、硬判决删除以及扩展里德-所罗门域宽（最高可达 GF(2¹⁶)）。
FIPS 140-3 认证是一个有价值的采购工具，但常被误解。该证书仅确认特定的模块（在特定版本和配置下）正确实施了获批的算法并符合特定的设计标准。它并不保证更广泛系统的安全性、密钥管理的完整性或运营合规性。 在实践中，该标准经常与实际需求脱节。许多组织，特别是数字资产托管机构，付费购买了经认证的硬件，却禁用了 FIPS 模式，因为它限制了必要的、未获批的算法（如比特币或 BIP32 中使用的算法）。此外，冗长的认证过程往往迫使供应商坚持使用较旧、易受攻击的固件以维持合规性，而未认证的产品反而可能更安全。 作者认为，FIPS 应被视为“筛选底线”，而非全面的安全保障。真正的风险管理存在于模块之外：包括严格的密钥来源追溯、文档化的仪式操作、人员访问控制以及一致的审计日志。如果一个组织在已验证的配置之外运行硬件，应明确记录在案，而不是依赖于不再适用的证书。
抱歉。
传递通行密钥：无密码身份验证中的一种新型攻击面 Pass the Passkey: A Novel Attack Surface in Passwordless Authentication
3 天前
这项研究确定了“Pass-ta-key”——这是一系列针对 Google 同步通行密钥（passkey）生态系统的新型攻击。尽管通行密钥用可靠的公钥加密技术取代了易受钓鱼攻击的密码，但这些攻击表明，受感染终端上的恶意软件如何利用安全设计与实现之间的差距，从而实现对账户的完全接管。
研究人员详细介绍了三种主要的攻击向量：
* **Pass-ta-key：** 恶意软件模拟浏览器行为进行静默身份验证，绕过用户交互和设备解锁要求。
* **Silver Pass-ta-key：** 攻击者作废现有的用户验证密钥并注册自己的密钥。这使他们能够绕过生物识别/PIN 要求，从而有效地为受害者关闭多重身份验证（MFA）。
* **Golden Pass-ta-key：** 通过从进程内存中提取主“安全域密钥”（SDS），攻击者可以解密并窃取受害者所有已同步的通行密钥，从而获得持续访问权限。
这些攻击之所以能够成功，是因为它们利用了依赖方验证薄弱（忽略了“用户已验证”标志）以及凭据管理器在处理入职和恢复流程时的漏洞。为抵御这些威胁，组织必须严格执行用户验证，在注册期间验证证明，并加强恢复流程以防止未经授权的密钥材料泄露。归根结底，终端安全仍然是“零信任”策略中至关重要的组成部分。
最近发表的《Pass the Passkey》一文在 Hacker News 上引发了关于无密码身份验证安全性的讨论。批评者认为该报道有哗众取宠之嫌，指出文中描述的漏洞并非“新发现”，而是已知的终端恶意软件攻击，前提是系统已被入侵。
讨论的核心要点包括：
* **恶意软件门槛**：许多评论者指出，如果攻击者已经绕过了操作系统安全防护并植入恶意软件，他们可以轻易窃取常规密码或会话 Cookie。因此，这些漏洞属于终端特定问题，而非 Passkey 协议本身的内在缺陷。
* **实现细节**：大部分漏洞源于依赖方（网站）未强制要求“用户验证”（User Verification, UV），导致无需解锁设备或进行生物识别验证即可使用通行密钥。
* **用户控制与生态系统锁定**：一个重要的讨论焦点在于易用性与安全性之间的权衡。用户对缺乏标准化的备份和导出选项表示不满，担心过度依赖 Google 或 Apple 等封闭生态系统。
* **结论**：虽然参与者一致认为 Passkey 在防范网络钓鱼方面普遍优于传统密码，但许多人认为，在能够完全取代传统验证方式之前，当前的实施方案需要更高的透明度以及更好的用户自主备份解决方案。
尽管许多公司通过复杂的层级和海量的提示词（prompts）来填充其 AI 编码代理，但 **Pi** 采取了一种极简主义的方法。通过使用极简的系统提示词和仅有的四个核心工具，Pi 优先考虑“上下文规范”——即通过最小化开销来避免 token 冗余和重复指令。
**Databricks** 的研究证实，这种极简设计不仅性能更佳，而且更具成本效益；Pi 以极低的成本实现了比同类大型竞品更高的成功率。该研究表明，决定端到端工程经济性的不仅是模型本身，还有其外围的支撑架构。
至关重要的是，Pi 的极简主义并未牺牲功能。其架构专为扩展性而设计，允许用户定制工作流——例如 **Shopify** 的高性能“自动研究（Autoresearch）”扩展。通过提供一个避免不必要抽象的简洁接口，Pi 使开发人员仅在必要时才增加复杂性。随着前沿模型在处理标准编码环境方面变得愈发熟练，Pi 这种精简的“少即是多”理念证明：一套高效的支撑架构远胜于臃肿的预封装方案。
关于 AI 代理工具“Pi”的 Hacker News 讨论显示，用户群体存在明显分歧：一方看重其极简主义，另一方则对其过于简陋感到沮丧。
**支持 Pi 的观点：**
支持者认为，Pi 的主要优势在于它没有“强加于人”的功能，允许用户构建高度个性化的工作流。得益于其极简设计，它提供了一个干净且可扩展的平台，让开发者只需根据需求添加特定的工具（扩展）。支持者推崇这种对环境的掌控感，并认为进阶用户通过量身定制工具，可以获得显著的效率提升。
**批评意见：**
反对者则认为 Pi “过于极简”，即便是一些其他工具开箱即用的基本功能，它也需要大量手动配置。主要批评包括：
* **默认配置糟糕：** 快捷键设置不便、不符合 XDG 目录规范以及启动速度缓慢。
* **安全隐患：** 默认的“YOLO”模式在没有完善沙箱保护的情况下授予代理过高的权限，被视为重大隐患。
* **臃肿问题：** 有人认为“极简主义”的宣传存在误导，因为该工具仍强制包含 shell 执行器等组件，并非其所声称的那样是一张“白纸”。
总而言之，目前达成的共识是：Pi 更像是“AI 原生版的 Neovim”——对于愿意投入时间进行自定义的用户来说功能强大，但对于追求“开箱即用”工具的用户而言，其效率可能并不理想。
发布 登录 注册 发布 此帖不可用。 登录或注册 X 查看正在发生的事并加入对话 使用手机继续 使用 Apple 继续 使用 Google 继续 或使用用户名或电子邮件登录 相关用户 热门趋势 条款 隐私 Cookie 无障碍 广告信息 更多 © 2026 X Corp. 你无法查看此帖，因为该账户的所有者限制了谁可以查看其推文。了解详情 此帖不可用。
Expat 是一个广泛使用的、基于 C99 标准的跨平台流式 XML 解析器，以 MIT 许可证发布。在长期将该项目作为副业进行维护后，首席维护者 Sebastian 已经与慕尼黑市的“开源休假”（Open Source Sabbatical）项目签署了一份为期六个月的带薪合同。 从 2026 年 8 月 1 日起，Sebastian 将全职专注于 libexpat 的维护工作，优先处理漏洞修复及项目的日常运营。有了这项专门的支持，该项目将能更高效地应对安全问题。Sebastian 鼓励社区提交经过深思熟虑且有理有据的漏洞报告，同时也提醒大家，低质量的人工智能生成内容仍是不受欢迎的。此外，他还欢迎任何成功将基于 Clang 的 MinGW 与 AddressSanitizer 和 Wine 结合使用的人士提供技术援助。
慕尼黑市启动了一项全新的“开源学术假”项目，近期资助了一名开发人员，使其能够全身心投入 `libexpat` XML 解析库的开发工作，为期六个月。这一举措凸显了慕尼黑对“公共资金，公共代码”原则的承诺，旨在鼓励改进该市所依赖的开源软件。
此举在 Hacker News 上引发了关于数字主权以及对微软等美国大型供应商依赖程度的广泛讨论。支持者将其视为对本地技术专长和安全性的战略投资，有助于减少对专有软件的长期依赖。相反，批评者则认为这些资源如果用于其他领域可能效果更好，他们质疑替换成熟办公套件的可行性，并指出此类努力往往会导致低效且短命的项目。
讨论还触及了 XML 相关技术在 Web 标准中逐渐衰落的话题，一些参与者感叹 XSLT 等工具正被以 JavaScript 为核心的环境所取代。总体而言，该讨论反映了两种观点之间的深刻分歧：一方优先考虑通过开源替代方案实现机构自主，另一方则认为公共资金应优先用于更紧迫的经济或技术需求。
Docker 构建缓存经常被误解为单一机制，但它实际上由三种不同的缓存组成：**层级链 (layer chains)**、**挂载缓存 (mount caches，如包管理器)** 和 **镜像存储 (image store)**。它们的有效性取决于您构建的具体“形态”和使用方式。 ### 优化关键规则： 1. **按变更类别思考**：针对常见的“源码变更”（代码编辑）进行优化，而非“冷”（初始）构建。 2. **层级排序**：将稳定且耗时的操作（如安装依赖）置于频繁变动的步骤之上。按“清单优先 (manifest-first)”排序可使构建速度提升 3 到 24 倍。 3. **明确优势所在**：层级缓存（导出到 CI）无法加速已失效的步骤。如果您的速度提升来自挂载缓存（增量编译），则需要**持久化构建器状态**（基于磁盘的缓存），而不是传统的导出/导入后端。 4. **避免导出成本**：导出/导入后端会对每次构建产生“序列化成本”。仅在缓存命中价值大于传输时间时才使用它们。 5. **正确划定作用域**：缓存键的共享范围应仅限于层级共享的范围。 6. **管理缓存增长**：缓存的大小随依赖版本的多样性增长，而非构建频率。 7. **优化分发**：对于 N 个任务的并发作业，应从镜像仓库拉取转向使用共享的镜像存储磁盘。
```Hacker News
最新 | 过往 | 评论 | 提问 | 展示 | 招聘 | 提交
登录
Docker 构建缓存的物理学原理 (blacksmith.sh)
16 点，由 piobio 发布于 1 天前 | 隐藏 | 过往 | 收藏 | 3 条评论 | 帮助
mshekow 1 天前 | 下一条 [–]
他们提供的数据需要批判性地看待。你不能简单地说“Node.js 应用比 <其他技术> 应用的缓存效果好得多”。这很大程度上取决于具体的代码/包结构。你也可以通过我的博文了解不少关于 BuildKit 缓存的知识：https://www.augmentedmind.de/2023/11/19/advanced-buildkit-ca...
回复
lolc 1 天前 | 上一条 | 下一条 [–]
我宁愿读原文。
回复
jiehong 1 天前 | 上一条 [–]
提供的“太长不看”（TLDR）版就是文章的副标题。帮助有限。
回复
考虑申请 YC 2026 年秋季批次！申请截止日期为 7 月 27 日。
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系
搜索： ```
我们终于学会了如何让 div 居中，结果浏览器又加了侧边栏。 We finally learned to center a div, then browsers added sidebars
3 天前
使用 CSS Grid (`place-items: center`) 来居中元素虽然简单，但它会将内容锚定在可视视口，而非整个浏览器窗口。当侧边栏或开发者工具等元素出现时，“完美居中”的内容在视觉上会显得偏移。 为了解决这个问题，作者计算了相对于物理浏览器窗口居中元素所需的偏移量。虽然 `window.innerWidth` 和 `window.outerWidth` 提供了额外的总空间，但它们无法揭示这些空间在屏幕上是如何分布的。 突破点在于利用指针事件（`screenX` 和 `clientX`）来映射网页在浏览器窗口中的位置。虽然 Firefox 直接提供了此数据，但 Chromium 需要在用户与页面交互时进行修正更新。作者最终将此逻辑封装为一个名为“center, actually”的工具，该工具可以自动检测并居中那些用户无法直接控制代码页面上的元素。
这篇 Hacker News 讨论聚焦于用户 `seg6` 发布的一篇博客文章。作者编写了一个脚本，旨在让页面内容在浏览器侧边栏打开时，依然能保持与物理屏幕中心的对齐。
作者的初衷是防止页面内容在浏览器视口变窄时偏离中心。然而，社区的反应却是一边倒的批评。评论者们认为：
* **视口与屏幕的区别**：网页内容应在“视口”（浏览器可用的显示区域）内居中，而非根据物理屏幕进行对齐。
* **用户自主权**：浏览器及其侧边栏受用户控制。试图“自作聪明”地干预布局的网站被视为“用户敌对”或“反设计”。
* **技术风险**：这种方法依赖于侵入性的黑客手段，会导致闪烁、布局故障及无障碍访问问题。
* **设计原则**：许多人认为，网站无权追踪或干涉窗口相对于屏幕或物理环境的位置。
面对关于无障碍性和标准布局行为的强烈抵制，作者承认了批评意见，认同该做法本质上是一种“黑客手段”，并考虑将该功能限制在个人浏览器插件中使用。
请提供您需要翻译的内容。
“Maple-Preview” 是一款能在 iPhone 上达到每秒 120 token 的 Ternary 20B MoE 模型。该模型的发布在 Hacker News 上引发了关于小型大语言模型（LLM）定位的热烈讨论。
尽管许多用户对本地运行模型的高速度和便捷性感到印象深刻，但评论者也指出存在显著的“知识”缺口。由于小型量化模型依赖有损压缩，它们极易产生看似一本正经的幻觉。批评者认为，这些模型不应被视为通用知识库；相反，它们应侧重于强化逻辑推理和无缝调用外部工具（如本地网络搜索或数据库查询），以获取准确信息。
目前普遍的共识是，端侧人工智能的未来不在于将人类的所有经验塞入有限的参数中，而在于构建足够“聪明”的模型，使其能够判断何时将任务委托给确定性代码或外部工具。归根结底，用户将这些超紧凑模型视为与数据交互的专用接口，而非大型、高性能前沿模型的替代品。