现代汽车的隐私与数据安全：一种物理移除解决方案 (现代汽车的隐私和数据安全：一种物理移除解决方案)

核心内容概要:

本文探讨了现代汽车日益增长的数据收集和隐私安全问题，并提供了一种物理移除汽车数据通信模块 (DCM) 和 GPS 以阻止数据传输的解决方案。

问题背景:

现代汽车配备了大量传感器，持续收集并传输包括位置、速度、燃料量、视频、驾驶员注意力数据等海量信息。这些数据通过内置的调制解调器（DCM）和 GPS 传输到云端，并可能被第三方数据经纪人（如 LexisNexis 或 Verisk）用于商业目的。 这种做法引发了严重的隐私和安全担忧，并已导致多起事件：

• Subaru (2025): 存在漏洞，允许远程解锁车辆并追踪车辆位置。
• 保险公司: 汽车制造商与保险公司分享驾驶数据，导致保费上涨。
• Tesla (2023): 员工共享客户车辆记录的裸体视频和其他敏感图像。
• Jeep Cherokee (2015): 黑客成功远程控制车辆，包括点火、刹车、锁和转向。
• Mozilla 隐私测试: 25 家汽车制造商在隐私保护方面表现不佳，收集包括性活动、移民身份、种族、面部表情、体重和遗传信息等敏感数据，并将其出售给第三方。
• Tesla (2017): 存在漏洞，允许远程查看车辆位置和控制其他功能。
• 广告和数据收集: 汽车开始投放广告并收集用户数据。

解决方案：物理移除 DCM 和 GPS

为了避免依赖公司承诺或无效的隐私选项，本文提出了一种通过物理移除 DCM 和 GPS 来阻止数据传输的方法。

功能影响:

移除 DCM 和 GPS 会影响以下功能：

• 云连接功能: OTA 更新、丰田云服务和 SOS 功能将无法使用。
• 车内麦克风: 需要安装 DCM 绕过套件来恢复车内麦克风功能。
• CarPlay: GPS 信号问题可能导致 CarPlay 定位错误。完全断开车内 GPS 可以解决此问题。
• 蓝牙: 即使移除 DCM，连接手机蓝牙仍会使车辆通过手机网络传输数据。建议使用 USB 连接或蓝牙转 USB 适配器。
• 保修: 移除 DCM 和 GPS 可能会使部分保修失效，但根据 Magnuson–Moss 保修法，整个保修不应因此失效。

所需工具和步骤:

• 工具: 拆卸面板工具包、棘轮扳手、10mm 和 8mm 扳手、可选精密螺丝刀、DCM 绕过套件。
• 步骤:
  1. 拆卸中控台面板。
  2. 移除 DCM (需要小心操作，并注意线路连接)。
  3. 安装 DCM 绕过套件以恢复麦克风功能。
  4. 断开 CarPlay 的车内 GPS 信号。
  5. 重新组装车辆。

验证结果:

• 确认仪表盘右上角显示“无连接”图标。
• 确认顶置控制台上的 SOS 灯已关闭。
• 确认车内麦克风工作正常。

结论:

本文提供了一种物理移除汽车数据通信模块和 GPS 以保护隐私的解决方案。作者认为，随着汽车技术的不断发展，这种方法可能不再可行，但目前仍然有效。作者呼吁更强有力的联邦隐私法来保障个人数据安全。

AI 使用对个人技能的影响：一位软件开发者的反思 (AI Usage and its Impact on Personal Skills: A Software Developer's Reflection)

日期： 2026年5月14日

核心观点： 这篇文章记录了一位软件开发者在使用人工智能（AI）工具后，对自身技能退化和职业发展产生担忧的反思。

主要内容：

• 技能退化： 作者认为频繁使用 AI 生成内容（包括文章和代码）导致自身写作和编程能力下降。虽然作者并非认为自己写作能力很差，但AI的使用让他感到自己的风格和声音被稀释，无法准确表达自己的想法。
• 编程技能的丧失： 在编程方面，作者已经完全依赖 AI 提示生成代码整整一年多，几乎忘记了手动编写代码。他对此感到非常沮丧，因为编程曾经是他生活的重要组成部分。目前，他正在努力重新学习手动编程。
• 对软件开发未来趋势的看法： 作者相信软件开发技能不会完全消失。虽然AI会减少对程序员的需求，但仍然需要具备阅读和编写代码能力的人。
• 对行业专业化的反思： 作者引用了 Robert Martin (Uncle Bob) 的观点，认为软件开发行业在过去20-30年中，由于需求激增，专业性有所下降。他希望 AI 技术能够促使行业回归更专业化的状态，类似于计算机科学成为职业之前，由物理学家、数学家和学者从事编程的时代。
• 自我怀疑与 AI 的循环： 作者坦诚自己经常在写作过程中产生自我怀疑，并试图使用 AI 来评估自己的作品，这进一步加剧了他的担忧。他意识到需要克服这种自我怀疑，重新建立对自身能力的信心。

总结：

这篇文章表达了作者对人工智能工具可能带来的负面影响的担忧，特别是对个人技能的退化。他正在积极采取行动，试图通过重新学习手动编程来恢复自己的技能，并希望 AI 技术能够促进软件开发行业回归更加专业化的发展方向。文章也探讨了作者自身的自我怀疑问题，并强调了克服这种怀疑的重要性。

英国住房系统更换 Palantir 技术，节省数百万英镑

概述

英国住房、社区和地方政府部 (MHCLG) 已成功地将用于安置乌克兰难民的住房系统中的 Palantir 技术替换为内部开发的系统，从而节省了数百万英镑的运行成本。 此举反映了英国政府减少对大型美国科技供应商依赖，并推动“主权技术”的趋势。

背景

“乌克兰家园”计划旨在将逃离冲突的乌克兰人与提供住宿的个人和家庭进行匹配。最初，Palantir 公司免费提供了其 Foundry 平台支持该计划，以迅速建立一个系统。该系统整合了来自多个政府部门的数十万签证申请和数百万份住宿提供信息。然而，政府首席商业官员对 Palantir 采用“零成本”或“象征性成本”的初始报价策略表示担忧，认为这与公开招标原则相悖。

系统更换

MHCLG 的数字领导者 Coco Chan 在博客中宣布，该部门已经用内部开发的系统取代了基于 Palantir Foundry 平台的原有系统。新系统更灵活，能够满足更高的安全标准，并且已经每年为 MHCLG 节省了数百万英镑的运营成本。 该系统于 2025 年 9 月正式投入使用。

Palantir 的回应

Palantir 公司表示，它为支持该计划感到自豪，并在短短九天内建立了一个解决方案，帮助安全安置了超过 157,000 名难民。 同时，该公司也指出，系统的更换表明企业并没有被锁定在 Palantir 的技术中。Palantir 还强调，其系统是支持乌克兰应对俄罗斯侵略的多方面努力的一部分，包括军事支持、扫雷、调查战争罪行以及为学生提供安全上学等。

意义与影响

• 节省成本: 更换系统为 MHCLG 节省了大量运营成本。
• 主权技术: 此举被视为英国政府迈向“主权技术”的重要一步，减少对外部供应商的依赖。
• 政府能力: 前政府技术顾问 Terence Eden 认为，这表明英国公务员在适当资源支持下，可以胜过像 Palantir 这样的私营公司。
• 公共服务依赖: 此事件引发了关于英国公共服务过度依赖大型美国科技供应商的讨论。
• 灵活性和控制: 内部开发系统提供了更大的灵活性和对数据及代码的控制。

专家观点

• BCS 副主席 Emma Logan 强调，在内部构建数字服务具有明确优势，但外部专家可以提供经验、专业技能和快速组建大型团队的能力。
• Public Digital 的 Rob Miller 建议政府不仅要考虑减少对大型科技企业的依赖，还要考虑投资建设内部能力的速度。

总结：关于X.com（原Twitter）的隐私扩展问题

主要内容：

该信息提示用户在使用X.com（原Twitter）时可能遇到的问题，并提供了解决方案。

关键点：

• 问题： 用户在使用X.com时可能会遇到问题。
• 原因： 某些与隐私相关的浏览器扩展程序可能导致这些问题。
• 解决方案： 用户应禁用这些隐私扩展程序，然后再次尝试。

总结：

如果在使用X.com时遇到问题，请检查并禁用可能导致冲突的隐私扩展程序。

CVE-2026-42945 漏洞利用 PoC 总结

这是一个针对 CVE-2026-42945 漏洞的利用 PoC，该漏洞是 NGINX ngx_http_rewrite_module 中于 2008 年引入的一个关键的堆缓冲区溢出。该漏洞允许未经验证的远程代码执行，针对使用 rewrite 和 set 指令的服务器。

漏洞发现：

该漏洞以及另外三个内存损坏问题 (CVE-2026-42946、CVE-2026-40701、CVE-2026-42934) 由 depthfirst 的安全分析系统在对 NGINX 源代码进行单次 onboarding 后自主发现。

漏洞原理 (TL;DR):

NGINX 的脚本引擎采用两遍过程：首先计算所需的缓冲区大小，然后复制数据。当 rewrite 替换包含 ? 时，主引擎会设置 is_args 标志。然而，长度计算遍在全新的零化子引擎上运行。

• 长度计算遍: is_args = 0 → 返回原始捕获长度。
• 数据复制遍: is_args = 1 → 调用 ngx_escape_uri 带有 NGX_ESCAPE_ARGS 标志，将每个可转义字节扩展为 3 个字节。

由于缓冲区大小计算不正确，复制遍会使用攻击者控制的 URI 数据溢出未分配足够的堆缓冲区。利用该漏洞需要跨请求的堆内存布局控制 (heap feng shui)，通过 POST 身体（因为 URI 字节不能包含 null 字节）喷洒，来破坏相邻 ngx_pool_t 的 cleanup 指针，将其重定向到伪造的 ngx_pool_cleanup_s，在池销毁时调用 system() 函数。

受影响和已修复的版本：

官方供应商公告：https://my.f5.com/manage/s/article/K000160932

使用方法：

已在 Ubuntu 24.04.3 LTS 上测试。

1. ./setup.sh — 构建容器。
2. docker compose -f env/docker-compose.yml up — 启动易受攻击的 NGINX 服务器。
3. python3 poc.py --shell — 获取 shell。

更多信息：

有关此漏洞的更多技术细节，请参阅 技术文档。

总结：关于绕过 macOS M5 芯片上的 MIE 内核漏洞的研究

这篇报告主要讲述了一个安全研究团队在苹果园区（Apple Park）与苹果公司分享了他们发现的漏洞，这是第一个公开的在 M5 芯片上运行的 macOS 内核内存破坏漏洞，并且成功绕过了苹果的 MIE (Memory Integrity Enforcement) 安全机制。

核心要点：

• 漏洞发现与报告： 研究团队于本周初亲自前往苹果园区，向苹果公司报告了该漏洞。该漏洞是基于在 M5 芯片上的 macOS 26.4.1 (25E253) 系统发现的，可以从本地非特权用户获取 root 权限。
• 漏洞细节： 该漏洞利用了两个漏洞，通过一系列系统调用，最终获得 root shell。漏洞利用链仅使用数据，无需修改代码，运行在启用了 MIE 的 bare-metal M5 硬件上。
• MIE 的重要性及局限性： MIE 是苹果公司花费五年时间、投入数亿美元打造的硬件辅助内存安全系统，旨在阻止内存破坏漏洞，被认为是目前最先进的安全防御技术之一。尽管如此，研究团队成功绕过了 MIE，证明了即使是最先进的防御机制也并非万无一失。
• AI 在漏洞发现中的作用： 该研究团队利用了 AI 工具 Mythos Preview 来辅助漏洞发现和利用开发。Mythos Preview 可以快速识别已知类型的漏洞，并进行泛化。但绕过 MIE 仍然需要人工专业知识。
• “AI 漏洞大灾区”的预示： 该研究表明，随着 AI 技术的进步，未来可能会出现更多能够绕过高级防御机制的漏洞，预示着一个“AI 漏洞大灾区”的到来。
• 后续计划： 研究团队将在苹果公司修复漏洞并更新系统后，公开详细的 55 页技术报告。
• 团队规模与 AI 的力量： 强调了即使是小团队，借助 AI 技术也能取得重大突破，甚至能让世界顶级公司寻求他们的帮助，体现了 “小而有力量” (nhỏ mà có võ) 的精神。

总结：

该报告展示了安全研究团队利用 AI 技术成功绕过苹果 MIE 安全机制的成果，突出了 AI 在漏洞发现和利用开发中的潜力，同时也提醒了业界，即使是最先进的防御技术也需要不断更新和改进，以应对日益增长的安全威胁。 该团队将详细技术报告的发布与苹果的修复进度挂钩，展现了负责任的安全研究态度。

Okay, I'm ready. Please provide the content you want me to summarize. I will do my best to provide a concise, accurate, and markdown-formatted summary in Chinese, keeping it under 800 words and adhering to your instructions. Just paste the content here.

whichllm: 寻找最适合您硬件的本地 LLM

简介

whichllm 是一个命令行工具，旨在帮助用户找到在他们的硬件上运行的最佳本地大型语言模型 (LLM)。它自动检测您的 GPU/CPU/RAM，并从 HuggingFace 筛选出最适合您系统的模型，并根据实时基准进行排名。

主要功能

• 自动硬件检测: 支持 NVIDIA、AMD、Apple Silicon 和 CPU。
• 智能排名: 根据 VRAM 适配度、速度和基准质量对模型进行评分。
• 一键聊天: 可以直接下载并启动模型聊天会话。
• 代码片段: 生成可复制粘贴的 Python 代码，方便使用模型。
• 实时数据: 从 HuggingFace API 拉取模型数据，并提供离线缓存。
• 基准感知: 集成实际评估分数，并根据置信度进行调整。
• GPU 模拟: 使用 --gpu 标志模拟任何 GPU，方便规划。
• JSON 输出: 方便将结果用于管道处理。

工作原理

1. 数据管道: 从 HuggingFace API 获取模型数据，并通过各种基准进行评估。
2. 排名引擎: 自动检测硬件，估算 VRAM 使用情况，评估兼容性，计算速度，并根据基准、模型大小、量化、硬件适配度、速度、流行度和数据来源进行评分。
3. 项目结构: 代码组织良好，主要模块包括 CLI (命令行接口)、hardware (硬件检测)、models (模型获取与评估)、engine (排名引擎) 和 output (输出显示)。

使用方法

• 基本使用: whichllm - 自动检测硬件并显示最佳模型。
• 模拟 GPU: whichllm --gpu "RTX 4090" - 模拟特定 GPU 以进行规划。
• CPU 模式: whichllm --cpu-only - 仅使用 CPU 运行。
• JSON 输出: whichllm --json - 以 JSON 格式输出结果。
• 运行模型: whichllm run "qwen 2.5 1.5b gguf" - 下载并启动模型聊天会话。
• 代码片段: whichllm snippet "qwen 7b" - 生成可复制粘贴的 Python 代码。

安装

• uv (推荐): uv tool install whichllm
• Homebrew: brew install andyyyy64/whichllm/whichllm
• pip: pip install whichllm

示例输出

$ whichllm --gpu "RTX 4090"

#1  Qwen/Qwen3.6-27B     27.8B  Q5_K_M   score 92.8    27 t/s
#2  Qwen/Qwen3-32B       32.0B  Q4_K_M   score 83.0    31 t/s
#3  Qwen/Qwen3-30B-A3B   30.0B  Q5_K_M   score 82.7   102 t/s

关键亮点

• 基于证据的排名: 不基于大小，而是根据实际基准进行排名。
• 考虑新旧程度: 较新的模型可以超过旧的基准排行榜上的模型。
• 证据分级: 对不同来源的证据进行分级和调整，确保评估的准确性。
• 架构感知: 估算 VRAM 使用情况，考虑量化、速度和硬件因素。

总结

whichllm 是一个功能强大的工具，可以帮助用户轻松找到最适合其硬件的本地 LLM，从而优化性能和体验。它提供了自动检测、智能排名、方便的运行和代码片段生成等功能，并支持多种模型格式和硬件平台。

OpenAI Codex 移动应用发布：随时随地协同开发

OpenAI 发布了 Codex 的移动应用，现已集成到 ChatGPT 移动应用中，旨在提供随时随地协同开发的能力。超过 400 万用户每周使用 Codex，移动应用旨在解决长期任务中协作的需求，让用户能够快速提问、审查结果、调整方向、审批或添加新想法。

主要功能与特点：

• 随时随地连接： 用户可以通过移动应用连接到运行 Codex 的任何设备（笔记本电脑、Mac mini 或远程环境），实时查看和操作活动线程、审批、插件和项目上下文。
• 全面操作： 不仅可以远程控制单个任务，还可以操作所有线程、审查输出、审批命令、切换模型或启动新任务。
• 安全可靠： Codex 使用安全中继层，在不直接暴露设备的情况下，实现设备间的安全连接和状态同步。
• 及时指导： 移动应用允许用户在关键时刻提供指导，例如在通勤途中做出决策，或在会议间隙快速处理问题。
• 企业环境支持： Codex 可以直接连接到企业管理的远程环境，利用现有的安全策略、凭证和计算资源。
• 新功能：
  • 程序化访问令牌： 允许在 ChatGPT 工作区设置中直接创建范围化的凭证，适用于 CI/CD 流程和内部自动化。
  • Hooks： 扫描提示中的敏感信息、运行验证器、记录对话、创建记忆或自定义 Codex 的行为，适用于特定仓库和目录。
  • HIPAA 合规性： 在本地环境中使用 Codex (CLI, IDE, App) 支持符合 HIPAA 要求的 ChatGPT Enterprise 工作区，助力医疗机构更快、更可靠地支持患者护理和运营流程。

可用性：

• Codex 在 ChatGPT 移动应用中正在预览版向所有计划（包括免费和 Go 计划）及所有支持的地区发布。
• 需要更新 ChatGPT 移动应用和 macOS 上的 Codex 应用才能体验。
• Windows 上的连接支持即将推出。
• Remote SSH 和 Hooks 适用于所有计划。
• 程序化访问令牌适用于企业版和商业版。
• HIPAA 合规性仅适用于符合条件的 ChatGPT Enterprise 工作区在本地环境中使用 Codex。

总而言之，Codex 移动应用旨在提升开发效率，提供更灵活的协作方式，并扩展 Codex 在企业环境中的应用范围。

DwarfStar 4 项目总结 (DwarfStar 4 Project Summary)

Antirez (Redis 的开发者) 分享了关于 DwarfStar 4 (https://github.com/antirez/ds4) 项目的进展和未来规划。该项目迅速获得关注，原因是其满足了对本地 AI 体验的需求，并受益于以下几个因素：

• 模型选择: DeepSeek v4 Flash 模型兼具大型和快速的特性，使其成为本地推理的理想选择。
• 量化技术: 2/8 位量化方案降低了内存需求，使得在 96 或 128GB RAM 的设备上运行成为可能。
• 本地 AI 社区的经验: 近年来本地 AI 社区积累的经验，以及 GPT 5.5 等技术的辅助，加速了项目的开发。

项目现状与未来方向:

• 模型可替换性: DwarfStar 4 不会固定使用 DeepSeek v4 Flash，未来会根据性能评估选择最佳的开源模型，强调“实际上快速”的特性。DeepSeek v4 Flash 的新版本，特别是针对编码优化的版本，以及其他专业领域的模型（例如法律、医疗）是潜在的方向。
• 专业领域模型: 针对特定领域（如编码、法律、医疗）的模型将通过加载所需模型的方式提供服务，实现灵活应用。
• 重要里程碑: Antirez 认为，目前 DwarfStar 4 的体验已经可以替代 Claude / GPT 等在线模型，这标志着本地 AI 发展的重要进步。
• 向量引导: 向量引导技术使得 LLM 的使用更加自由。

未来发展重点:

Antirez 计划在接下来的工作中重点关注以下几个方面：

• 质量基准测试: 进行质量评估和基准测试。
• 编码代理: 考虑添加编码代理作为项目的一部分。
• CI 测试环境: 搭建本地硬件环境，以确保长期质量。
• 端口扩展: 增加对更多硬件平台的支持。
• 分布式推理: 实现序列和并行分布式推理。

总结:

DwarfStar 4 项目的快速发展和潜力巨大，Antirez 强调 AI 不应仅仅依赖于提供服务，本地 AI 的发展至关重要。 项目团队感谢社区的支持，并期待未来的发展。

Claude Code 在大型代码库中的大规模应用模式总结

本文探讨了 Claude Code 在大型代码库（例如百万行代码的单体仓库、数十年历史的遗留系统、横跨数十个仓库的微服务架构等）中的大规模应用模式。 Claude Code 能够应对这些复杂环境的挑战。

Claude Code 如何导航大型代码库

Claude Code 像软件工程师一样导航代码库：遍历文件系统、读取文件、使用 grep 查找所需内容，并跟踪代码库中的引用。它在开发人员的机器上本地运行，不需要构建、维护或上传代码库索引。 与基于 RAG (Retrieval Augmented Generation) 的 AI 编码工具不同，Claude Code 避免了因索引无法跟上代码更新而导致的信息过时问题。 Claude Code 通过充分利用上下文信息（如 CLAUDE.md 文件和技能）来确定搜索方向，从而提高效率。

Harness (工具生态系统) 的重要性

Claude Code 的能力不仅仅取决于模型本身，更取决于围绕模型的工具生态系统，即 "Harness"。 Harness 由五个扩展点组成：

• CLAUDE.md 文件: 包含代码库知识的上下文文件，在每个会话开始时自动加载。
• Hooks: 用于自我改进的脚本，例如在会话结束后提出 CLAUDE.md 更新建议。
• Skills: 按需提供特定领域的专业知识，避免在每个会话中加载所有知识，通过 progressive disclosure (渐进式披露) 来解决。
• Plugins: 打包技能、Hooks 和 MCP 配置，方便安装和分发。
• MCP servers: 连接到内部工具、数据源和 API。
• LSP (Language Server Protocol) 集成: 提供开发者在 IDE 中使用的符号级别导航功能。
• Subagents: 隔离的 Claude 实例，用于特定任务，并将最终结果返回给主代理。

成功部署的三个配置模式

1. 使代码库可导航: 通过精简 CLAUDE.md 文件、初始化子目录、使用 .gitignore 文件排除生成文件、以及使用 LSP 服务器，确保 Claude Code 能够有效地找到正确的上下文。
2. 主动维护 CLAUDE.md 文件: 随着模型智能的演变，定期审查和更新 CLAUDE.md 文件，移除不再需要的规则，以适应新的模型能力。
3. 指定 Claude Code 管理和采用负责人: 组建专门团队或指定负责人，负责配置管理、插件分发和 CLAUDE.md 规范，以确保一致性和推广。

总结

Claude Code 在大型代码库中的成功应用，依赖于良好的代码库结构、持续的配置维护和明确的组织责任。 通过精心设计的 Harness 和适当的配置模式，可以充分发挥 Claude Code 的潜力，提高开发效率。

英国军方向特里斯坦-达库尼亚岛空投医疗物资及人员报告总结 (Summary of UK Military Airdrop to Tristan da Cunha)

这份报告由彼得·米林顿撰写，记录了英国政府为应对在 MV Hondius 游轮爆发的汉塔病毒疫情，向位于南大西洋的特里斯坦-达库尼亚岛提供的紧急援助行动。

事件背景:

• 4月中旬，一艘游轮在特里斯坦-达库尼亚岛停留期间，一名乘客后被诊断为疑似汉塔病毒感染。
• 岛上的小型医院资源紧张，医疗氧气和物资储备不足。

援助行动:

• 应岛上行政长官和总督的请求，英国政府决定派遣军事人员和医疗物资空运至岛上。
• 由于特里斯坦-达库尼亚岛没有跑道，援助必须通过空投方式进行，且岛屿风力强劲，天气变化迅速，空投行动面临挑战。
• 英国皇家空军选择了一架 Airbus A400M 运输机，并配备了一架 Voyager 空中加油机以支持远程飞行。
• 5月9日，运输机从 Ascension 岛起飞，经过空中加油，最终于下午5点左右到达特里斯坦-达库尼亚岛。

空投细节:

• 由16 空降旅的英国陆军 Pathfinder 排组成的小组，包括六名伞兵、一位顾问医生和一位 ICU 军用护士，首先从飞机上空投。
• 伞兵从 7,000 英尺 (2,134 米) 高度，距离岛屿 5 公里处跳伞，由于风力影响，在海面上漂移。
• 随后，医生和护士使用双人伞降落在岛上的 9 洞高尔夫球场上。
• 总计 3.3 吨的物资被分成三次空投到岛上的 Patches 地点，飞机飞行高度仅 175 英尺，速度为 162 节。
• 岛民负责收集空投物资和降落伞。

后续工作:

• 军方人员在 Prince Philip Hall 建立基地，并得到岛民的热情接待。
• 医生和护士迅速投入工作，为岛上医院的医护人员提供支持，并帮助处理疑似汉塔病毒病例。
• 患者病情稳定。

岛民反应:

• 岛民对英国政府、外交部、国防部和军队的援助表示衷心感谢。
• 他们对此次空投行动的壮举表示惊叹，认为这是一次历史性的时刻。

未来展望:

• 军方将继续执行任务，并将在稍后时间提供进一步报告。
• 任务完成后，军方人员将乘船离开岛屿。

其他:

• 岛上的警察 Barry Thacker 写了一首诗，表达了对参与此次行动的所有人的感谢。
• 英国国防部、BBC 等媒体对此次行动进行了报道。

总而言之，英国政府迅速有效地响应了特里斯坦-达库尼亚岛的医疗需求，通过一场复杂而勇敢的空投行动，为岛民提供了至关重要的支持。

前沿人工智能访问受限：趋势与应对 (Limited Access to Frontier AI: Trends and Responses)

本文探讨了当前前沿人工智能（AI）访问受限的趋势，并分析了其背后的原因和潜在影响。过去，人们普遍认为AI模型将广泛可用，但近期事件表明，前沿AI的访问将受到经济和安全约束。

主要趋势：

• 安全考量： 开发商出于对模型被滥用的担忧（例如网络攻击、生物武器设计），开始限制访问，优先向防御者提供早期访问权限，再逐步向可信赖的用户开放。
• 政府干预： 美国政府正考虑采取措施，可能将限制访问作为国家安全政策的一部分。这可能包括优先保障美国公司获取AI能力，并利用AI技术进行情报收集。
• 模型盗窃与蒸馏： 模型蒸馏（Distillation），即通过访问API tokens来复制模型的技术，对开发商构成威胁。这可能导致开发商加强安全措施，限制访问，甚至受到政府干预。
• 计算资源短缺： 提供前沿AI模型需要大量的计算资源，而这种资源日益短缺，导致开发商面临运营压力，并可能限制模型的广泛使用。
• 市场力量变化： 由于计算成本高昂，提供AI访问不再像软件行业那样具有规模经济效应。这意味着，只有那些能够承担高昂成本或有效将API tokens转化为收入的公司才能获得访问权限。

潜在影响：

• 地缘政治分化： 前沿AI访问的不等分布可能导致国家间的财富、安全和权力差距扩大，引发冲突和不稳定。
• 创新受阻： 限制AI访问可能阻碍创新，因为初创企业和有抱负的部署者将无法充分利用AI技术。
• 技术鸿沟： 最终可能出现前沿AI能力被少数人垄断的局面，加剧技术鸿沟。

应对策略：

• 提升安全性： 加强全球安全措施，降低AI被滥用的风险，从而减少对限制访问的需求。
• 增加计算资源： 大力建设数据中心，缓解计算资源短缺问题。
• 互惠协议： 非美国国家可以通过提供数据中心建设的优惠条件，换取美国公司提供前沿AI访问权限。
• 保持自主能力： 中等实力国家应保持一定的AI自主研发能力，以应对可能出现的访问限制。

文章强调，应对这些挑战需要采取务实的措施，包括构建安全可靠的AI生态系统，增加计算资源供应，以及建立公平的访问机制，以确保AI技术能够为全球带来福祉，而不是加剧不平等。

对新评论家的批判性审视：人工智能对高等教育的侵蚀

引言

文章探讨了人工智能（AI）在大学校园中的日益普及，以及它对高等教育的潜在危害。作者奥文·英林，一位21岁的作家和《新评论家》的助理编辑，认为AI的使用不仅仅是作弊问题，更是一种对文化和学术传统的深刻威胁。

核心论点

英林认为，当前大学面临的挑战并非学生不够努力，而是他们没有受到足够的挑战。AI工具的普及，特别是ChatGPT等大型语言模型，正在将有前途的年轻人变成“呆头转向”的庸才，并可能彻底改变大学的本质——无论是作为人文项目、道德训练场，还是职业技能培养地。

AI的蔓延

文章详细描述了AI在芝加哥大学的渗透过程：

• 早期阶段： 最初，AI被视为一种无害的“良性肿瘤”，仅限于经济学专业课程，学生利用AI完成简单的作业，获得良好成绩。
• 中期阶段： AI的使用蔓延到经济学系，学生在考试中直接使用手机拍照上传到AI平台，复制生成的答案。
• 后期阶段： AI开始侵蚀人文科学， plagiarisms 案例减少，成绩却普遍提高。
• 校园媒体： 芝加哥大学的校报《芝加哥先锋报》曾刊登两篇完全由AI撰写的文章，未被发现。
• 平行增长： 学生们开始将生活的方方面面，包括电子邮件、健身计划、书籍摘要，甚至与异性的交流，都委托给AI。

大学的应对与转型

文章批评了大学对AI使用的麻木不仁，认为惩罚作弊行为并不能从根本上解决问题。大学公告宣传“AI在课堂中的应用”，但实际情况是学生们只是在用AI替代学习、教学和交流。

对“AI在课堂中”的质疑

作者对大学推广“AI在课堂中”的政策表示怀疑，认为这与精英大学追求卓越的理念相悖。他认为，如果AI被用于标准化教学，降低教学质量，那么这将会对高等教育造成不可挽回的损害。

对教育的思考

文章引用了歌德的观点，强调教师与学生之间的关系是教育的核心。作者认为，AI无法取代真正的教师，也无法激发学生的学习热情和创造力。

未来的担忧

文章表达了对AI可能导致高等教育丧失独立性和多样性的担忧。他担心，大学可能会沦为为社会“需求”培养人才的工厂，而不是培养具有批判性思维和独立判断力的公民。

结论

文章呼吁对AI在高等教育中的应用保持警惕，避免其对学术传统和人文精神造成破坏。作者强调，保护大学的独立性和多样性，对于维护自由和民主至关重要。

后记

文章末尾包含与《新评论家》创始编辑的对话，讨论了对AI的愤怒根源、芝加哥大学的现状、以及对高等教育未来的担忧。

总结

文章以批判性的视角审视了AI对高等教育的影响，认为AI的应用不仅带来了作弊问题，更可能导致教育的标准化和庸俗化。作者呼吁人们警惕AI对学术自由和人文精神的潜在威胁，并努力保护大学的独立性和多样性。

安大略省审计报告：AI Scribe 系统存在严重问题，医疗记录准确性堪忧

摘要：

安大略省审计长办公室发布报告，对安大略省医疗保健提供者使用的 20 个 AI Scribe 系统进行了评估，结果显示这些系统存在严重缺陷，对患者医疗记录的准确性构成威胁。评估发现，这些 AI 系统经常遗漏关键细节、插入错误信息，甚至捏造内容，严重影响了医疗记录的可靠性。

主要发现：

• 信息捏造和错误建议： 20 个系统中有 9 个被发现 "捏造信息并对患者的治疗方案提出建议"，而这些内容并未在原始录音中提及。例如，系统错误地报告未发现肿块，或声称患者存在焦虑情绪，尽管这些情况从未被讨论过。
• 药物信息错误： 20 个系统中有 12 个在患者记录中插入了不正确的药物信息。
• 忽视患者精神健康问题： 20 个系统中有 17 个 “忽略了患者的精神健康问题”，其中 6 个系统完全或部分忽略了相关信息。
• 缺乏强制性审核： 虽然 OntarioMD 建议医生手动审核 AI 生成的笔记，但目前所有获批的 AI Scribe 系统都缺乏强制性的准确性审核功能。

评估流程问题：

报告指出，评估流程的设计存在严重问题，导致了不合理的评分标准。

• 地域因素权重过高： 系统是否在安大略省拥有本地业务，占据了评估总分的 30%，远高于医疗记录准确性（仅 4%）。
• 安全和隐私关注不足： 偏见控制、威胁风险和隐私评估以及 SOC 2 Type 2 合规性等关键安全和隐私保障仅占评估总分的 2% 和 4%，分别。
• 评估标准不合理： 报告认为，这种不合理的权重分配可能导致选择出使用 AI 工具产生不准确或有偏见的医疗记录，或缺乏充分保护来保护敏感个人健康信息的供应商。

官方回应：

安大略省卫生部表示，目前有超过 5000 名医生参与 AI Scribe 计划，且尚未收到与该技术相关的患者伤害报告。然而，报告的发现仍然引发了对 AI 在医疗保健领域应用准确性和安全性的担忧。

总结：

安大略省的 AI Scribe 评估结果表明，在医疗保健领域应用 AI 技术需要谨慎，并需要建立更严格的评估标准和审核机制，以确保患者医疗记录的准确性和安全性。不合理的评估流程是导致当前问题的关键因素之一，需要进行改进。

硬盘固件修改的探索之旅：初步分析与修改 (HDD Firmware Hacking: Initial Analysis and Modification)

本文档记录了作者在尝试 Xbox 360 软破解过程中的经历，因为需要延迟硬盘读取时间以触发漏洞，从而深入研究了硬盘和固态硬盘的固件修改。系列文章将涵盖固件的dump和分析、JTAG 调试硬盘、修改硬盘固件以及利用AI辅助分析和识别未知MCU架构等内容。第一篇文章重点介绍了硬盘固件的dump、分析和修改。作者强调，本文档不包含AI辅助的内容。

背景

作者最初的目标是利用 Xbox 360 读取硬盘数据时的竞速条件漏洞。为了延长读取时间，作者最初的想法是修改硬盘固件，在读取特定扇区时引入几百毫秒的延迟。尽管之前读到过一些关于硬盘固件修改的文章，但缺乏可直接使用的信息。作者最初只想修改一个硬盘以完成 Xbox 360 漏洞的开发，之后再考虑扩展到其他型号。 最终，作者找到了其他方法来调整竞速条件攻击，而无需修改硬盘固件。

测试对象

作者选择了以下硬盘/固态硬盘作为测试对象：

• Samsung HM020GI
• Hitachi HTS545032B9A300
• Western Digital WD3200BEVT
• Samsung PM871a

初步研究

作者在 HDD Guru 论坛上搜索了这些硬盘型号的固件，并阅读了 MalwareTech 的博客系列文章。作者发现，许多论坛帖子要么不正确，要么不适用于所选型号的硬盘。作者的计划是：

1. 获取固件dump，或者自行从硬盘上dump。
2. 将固件加载到IDA Pro进行分析，并绕过压缩或加密。
3. 找到一种方法将修改后的固件重新刷新到硬盘，例如手动编程闪存芯片或使用厂商提供的命令。
4. 分析固件，找到处理读取请求的代码，特别是DMA READ EXT命令。
5. 编写补丁，在读取特定扇区时引入几百毫秒的延迟。
6. 将修改后的固件刷新回硬盘。

固件获取

作者在HDD Guru论坛上找到了Western Digital硬盘的固件dump，并且通过Twitter联系到一位网友，获得了Samsung HM020GI的固件dump。Samsung PM871a的固件在Lenovo的固件更新工具中找到，并利用反编译更新工具，获取了刷新固件的命令。

Western Digital 固件分析

Western Digital硬盘的固件格式简单，由一系列静态链接的可执行文件/数据段组成。这些段除了第一个加载器stub外，都经过压缩。作者通过反编译加载器stub，识别出LZHUF算法，并编写了IDA加载器插件，以加载整个固件。

Samsung PM871a 固件分析

Samsung PM871a的固件被混淆，作者通过反编译Lenovo的固件更新工具，破解了混淆算法并获取了原始固件。作者发现固件开头有28字节的疑似签名，但怀疑并非强加密算法。

固件刷新

作者计划使用厂商提供的 backdoor 命令刷新 Western Digital 硬盘的固件。由于 WD 硬盘使用内部MCU闪存存储固件，作者决定在电路板上安装SPI闪存芯片，并用它来测试修改后的固件。

固件分析与调试

作者通过JTAG接口对Western Digital硬盘的MCU进行调试。作者发现，硬盘使用VSC（Vendor Specific Command）来处理读取请求。作者通过设置内存访问断点，找到DMA READ EXT命令的处理函数，并最终确定了代码位于硬盘的overlay模块中。

固件修改

作者编写补丁，在读取请求处理函数中插入延迟代码，并利用JTAG接口在内存中直接修改代码，实现了读取延迟。初步测试表明，延迟时间与预期值有所偏差，但基本实现了读取延迟的目的。

结论

在作者后续的研究中，最终无需修改硬盘固件就能成功利用 Xbox 360 漏洞。 本文档开源了作者编写的IDA和固件相关的脚本，希望能够帮助他人探索硬盘固件的秘密。作者希望看到更多关于硬盘固件的文档，例如反汇编固件和厂商 backdoor 命令的记录。

总而言之，本文档详细记录了作者探索硬盘固件修改过程，展示了固件dump、分析、调试

Anubis：网站反爬虫保护机制摘要

以下是对提供内容的摘要：

Anubis 是一种网站反爬虫保护机制，旨在阻止 AI 公司大规模抓取网站数据，从而避免网站宕机和资源不可用。

核心原理：

• 工作量证明 (Proof-of-Work)： Anubis 采用类似于 Hashcash 的工作量证明方案，即要求客户端进行一定程度的计算才能访问网站内容。
• 成本递增： 这种机制在单个访问者层面影响忽略不计，但对于大规模爬虫而言，计算成本会显著增加，使其抓取变得更加昂贵。

当前状态与未来发展：

• 临时解决方案： Anubis 目前是一个临时方案，目的是争取更多时间用于开发更精细的解决方案。
• 指纹识别： 未来计划重点发展指纹识别技术，特别是针对无头浏览器（headless browser）的识别，例如通过分析字体渲染方式。
• 目标： 通过指纹识别，能够识别出合法用户，从而避免向其呈现工作量证明页面，提升用户体验。

注意事项：

• JavaScript 依赖： Anubis 需要使用现代 JavaScript 特性，因此需要禁用 JShelter 或其他类似插件，以确保其正常运行。

总结：

Anubis 通过工作量证明机制限制大规模爬虫，同时致力于通过指纹识别技术进一步优化反爬虫策略，最终目标是保护网站资源，提升用户体验。

波雷利斯：纯 OCaml CCSDS 协议栈在低地球轨道成功启动

核心概要： Parsimoni 团队成功将纯 OCaml 实现的 CCSDS 协议栈 (Borealis) 部署到 DPhi Space 的 ClusterGate-2 载荷模块上，并在低地球轨道运行。该项目实现了端到端加密的命令与控制，以及后量子密钥轮换，充分利用了 OCaml 的安全性和性能优势。

关键细节：

• 项目背景： Borealis 项目旨在解决卫星软件安全性问题。OCaml 语言因其安全特性，是运行在太空中的理想选择。KC Sivaramakrishnan 在 ICFP 2022 的演讲中回顾了 OCaml 5 的十年工程，该版本引入了安全且高效的多线程支持。
• 启动时间及状态： 2026 年 4 月 23 日，Borealis 协议栈成功在低地球轨道启动，并显示“healthy”健康状态。
• 运行环境： Borealis 运行在 DPhi Space 的 ClusterGate-2 载荷模块上，使用 Arm SoC (四核 Cortex-A53，4GB RAM)。
• 协议栈架构： Borealis 是一个守护进程，使用标准的客户端-服务器协议进行通信。协议栈是纯 OCaml 实现的 CCSDS 协议族，涵盖无线电帧到 Bundle Protocol 和安全扩展等所有层级。二进制格式使用 ocaml-wire 代码生成器。
• 安全机制：
  • BPSec: 每个 Bundle 包裹在两个扩展块中，一个用于加密有效载荷，另一个用于认证。
  • OTAR: 支持空中密钥轮换 (Over-The-Air Rekeying)，用于后量子签名密钥 (ML-DSA-65)，确保密钥在卫星寿命周期内安全。
  • SDLS: 安全联盟，用于管理加密参数。
• 关键创新： Borealis 是第一个公开展示在轨后量子 OTAR 的演示。
• 软件规模与构建： 飞行二进制文件大小为 5-10 MB，静态链接，使用 FROM scratch Docker 镜像构建。
• OxCaml 性能提升： 测试结果显示，使用 Jane Street 的 OxCaml 分支，并采用 exclave_ stack_ 注解后，CCSDS 数据包调度热路径的 p99.9 延迟从 29 ns 降低到 9 ns，并且消除了 GC 压力。
• OCaml 的优势： OCaml 减少了与内存相关的安全漏洞，例如缓冲区溢出和使用后释放错误。OxCaml 进一步提升了性能，并提供了对程序性能关键部分的安全控制。
• 未来发展： Parsimoni 计划扩展 Borealis 的规模，实现对多个卫星的专业载荷二进制文件的安全部署和管理。他们正在研究安全更新、载荷隔离和运行状态验证等问题。
• 技术栈：
  • 语言： OCaml, OxCaml
  • 协议： CCSDS, BPv7, BPSec, OTAR
  • 验证： F*，EverParse
  • 操作系统： Linux

总结： Borealis 项目的成功标志着 OCaml 在太空软件领域的应用取得了重要突破。通过安全、高效的 OCaml 协议栈，Parsimoni 团队为卫星通信和控制提供了一种更安全、更可靠的解决方案，并为未来的太空软件开发铺平了道路。

Claude for Legal：参考指南 (Claude for Legal: Reference Guide)

这份文档概述了用于法律工作流程的 Claude 插件，涵盖公司商业、隐私、产品、公司、劳动、诉讼、监管、AI 治理和学习等领域。 插件可作为 Claude Cowork 或 Claude Code 插件使用，也可以通过 Claude Managed Agents API 部署。

核心要点:

• 两种部署方式： Claude Cowork (桌面插件) 或 Claude Code (代码插件)，或通过 Claude Managed Agents API 部署。
• 核心理念： 这些插件旨在协助律师分析问题，而非提供法律建议。所有输出均为草稿，需要律师审核、验证并对结果负责。
• 安全措施： 插件内置了安全措施，包括引用来源、保守的法律判断、明确的管辖区假设以及在提交、发送或依赖任何内容之前设置的明确闸门。
• 插件架构： 插件包含实践领域插件、管理代理食谱、MCP 连接器和命名代理。
• 社区技能： 鼓励社区构建法律技能，并提供安全安装和评估机制。

主要功能和组件：

• 实践领域插件： 涵盖了广泛的法律领域，每个插件都围绕一个冷启动访谈和 CLAUDE.md 实践配置文件构建。
• 管理代理食谱： 用于定时、需要人工干预的工作流程，例如续约监控、诉讼日历监控、监管信息监控等。
• MCP 连接器： 连接到通用生产力工具 (Slack、Google Drive、Box) 和法律特定系统 (Ironclad、DocuSign、iManage、Everlaw、CourtListener 等)。
• 命名代理： 端到端工作流程代理，例如供应商协议审查器、DSAR 响应器、终止审查器、索赔图表构建器等。

代理示例：

使用方法：

• Claude Cowork: 在 Claude 桌面中安装插件。
• Claude Code: 使用 /plugin 命令安装插件，并运行冷启动访谈以配置实践配置文件。
• Claude Managed Agents: 通过自己的编排器部署管理代理。

定制化：

• 冷启动访谈: 调整插件以适应团队的实践方式。
• 编辑实践配置文件: 直接编辑 ~/.claude/plugins/config/claude-for-legal/<plugin>/CLAUDE.md 进行小修改。
• 重新运行设置: 重新运行冷启动访谈以进行全面调整。

关键资源：

• QUICKSTART.md: 快速入门指南。
• MCP 连接器: 允许 Claude 连接到各种法律系统。
• **社区

美国大范围干旱状况总结

根据弗吉尼亚理工学院气候学家安德鲁·埃利斯（Andrew Ellis）的分析，目前美国超过 60% 的地区正经历干旱，其中超过 20% 的地区处于极端干旱状态。这种干旱状况因其强度和覆盖范围的罕见性而被认为是几十年来的最严重之一。

干旱原因：非典型的拉尼娜现象

埃利斯解释说，过去秋季和冬季的拉尼娜现象（即太平洋赤道西部的降温）是导致美国南部地区干旱的主要原因。虽然拉尼娜期间西部的干旱现象比较常见，从西部穿过大平原南部到东南地区，但本次拉尼娜事件的特殊之处在于太平洋西北部也持续干旱。

通常，拉尼娜期间的风暴路径会沿着美国与加拿大边境向北移动，导致美国南部缺少产生降水所需的风暴动力。来自西南地区的太平洋风暴系统频率降低，墨西哥湾向美国东部输送湿气的通道也减少。此外，气候变暖也在加剧这些状况，导致土壤通过蒸腾作用损失更多水分，从而加剧干旱的影响。

受影响地区

科罗拉多州和东南地区（特别是佐治亚州和佛罗里达州）是受干旱影响最严重的地区，这些地区广泛存在极端和异常干旱状况。更广泛地说，从南部到大西洋中部的美国东南象限以及中部落基山脉和高大平原地区也正经历着广泛而深度的干旱。 埃利斯指出，从新泽西州到阿肯色州的各州在拉尼娜年份更容易受到秋季和冬季干旱的影响，因为它们依赖墨西哥湾和东南海岸线的湿气，但这些湿气供应在过去六到八个月中大部分被切断。 与之相反，俄亥俄河谷通常在拉尼娜年份更湿润，并且到目前为止，今年大部分地区仍然没有干旱。

缓解前景

在夏季获得显著的干旱缓解较为困难。通常，夏季末或秋季初的热带风暴系统能带来缓解，但这些系统也存在强风和短时间内降雨过多的风险。 中部落基山脉和高大平原地区尤其依赖冬季积雪和大规模冬季风暴系统，因此夏季缓解较为困难。 虽然东南和中大西洋地区可能会出现由墨西哥湾和北大西洋湿气驱动的湿润夏季，但这些事件很少持续足够长的时间以消除深层干旱。

展望未来，预计下秋季和冬季可能会出现历史性的厄尔尼诺现象，这可能会产生与今年拉尼娜现象相反的条件。

关于埃利斯

安德鲁·埃利斯是弗吉尼亚理工学院自然资源与环境学院地理系教授。他的专业领域包括气候科学、气象学、降雪变化、干旱的发生和监测以及评估干旱和半干旱气候下淡水资源的可持续性。

1

内容摘要：

该内容描述了一个项目贡献者可以选取的权益（perk）。

主要信息：

• 权益名称： 权益的标题为 perk.title，如果不存在，则显示 perk.id。
• 价格： 该权益是免费的，或者需要至少 {{formatAmount(perk.price.noExponents(), srvModel.currencyData.divisibility)}} {{targetCurrency}} 捐款才能获得。
• 货币： 使用 {{targetCurrency}} 作为捐款货币。
• 剩余数量： 剩余可用权益数量为 {{new Intl.NumberFormat().format(perk.inventory)}}。 如果权益售罄，则显示“Sold out”。
• 已售数量： 已售出的权益数量为 {{new Intl.NumberFormat().format(perk.sold)}}。
• 总价值： 所有权益的总价值为 {{formatAmount(perk.value, srvModel.currencyData.divisibility)}} {{targetCurrency}}。
• 贡献者： 显示了贡献者数量，表示为 "Contributor" 或 "Contributors"，具体取决于已售出的权益数量。

Mullvad VPN 出口 IP 分配机制分析与安全隐患

本文分析了 Mullvad VPN 的出口 IP 分配机制，并指出了其潜在的安全隐患。

核心发现：

• Mullvad VPN 提供了多出口 IP，旨在避免因 IP 封锁和限速问题。
• 出口 IP 的分配并非随机，而是基于 WireGuard 密钥（pubkey）的确定性算法。该密钥每 1 到 30 天轮换一次（除非使用第三方客户端，则永不轮换）。
• 尽管服务器拥有大量出口 IP 地址池（总计超过 8.2 万亿个组合），但实际观察到的 IP 组合数量却非常有限，仅有 284 种。
• 研究发现，Mullvad VPN 使用种子（pubkey 或隧道地址）为随机数生成器（RNG）提供种子，并使用 IP 地址池大小作为上限。这种机制导致了 IP 组合的有限性，并且不同服务器之间存在共享 IP 索引的现象。
• 通过分析，可以计算出 IP 地址在池中的相对位置，并发现它们通常落在同一百分位（约 81%）。
• 研究者开发了一款工具 (https://tmctmt.github.io/mullvad-seed-estimator/)，可以根据出口 IP 组合估算浮点值范围，从而确定共享这些 IP 的用户数量。

技术细节：

• Mullvad VPN 的客户端和后端使用 Rust 语言编写。
• RNG 使用 rand::rngs::StdRng，其行为可能与直觉不符。具体而言，random_range 函数在不同边界条件下，产生的浮点数可能并非完全独立。
• 示例代码展示了使用固定种子和不同边界的 random_range 函数的行为。

安全隐患：

• 由于 IP 组合数量有限，Mullvad VPN 用户之间的匿名性降低。
• 通过分析 IP 地址的浮点值范围，可以推断出多个用户共享相同的 IP 组合，从而增加被识别的风险。
• 攻击者可以通过分析 IP 日志（例如，从数据泄露或法律途径获取）来关联不同账户，并进行去匿名化攻击。

防护建议：

• 避免频繁切换服务器，一次 pubkey 切换不超过一次。
• 强制轮换 pubkey，例如通过退出 Mullvad 应用。

总结：

Mullvad VPN 虽然提供了多出口 IP，但其出口 IP 分配机制存在缺陷，导致用户匿名性降低。用户应注意采取防护措施，以降低被识别的风险。

KDE 项目获得德国主权科技基金资助，推动欧洲数字主权

摘要:

德国主权科技基金（Sovereign Tech Fund, STF）向 KDE 项目拨款 128.52 万欧元（约合 110 万英镑或 150 万美元），以加强其核心基础设施的可靠性和安全性，包括 Plasma 桌面环境、KDE Linux 以及其通信服务的基础框架。

主要内容:

• 资助背景： 此次资助是 STF 持续支持开源项目的一部分，此前该基金已分别向 GNOME、FreeBSD 和 Samba 提供了资金支持。这反映了欧洲对数字主权的日益重视，尤其是在美国政治局势变化和对美国科技公司依赖性担忧加剧的背景下。
• KDE Linux 项目： KDE Linux 是 KDE 项目内部开发的、技术上具有创新性的 Linux 发行版，目前仍在开发中。它借鉴了 Valve 的 SteamOS 3 的设计理念，都基于 Arch Linux，采用双 Btrfs 格式的根分区，并使用 KDE Plasma 作为桌面环境。
• SteamOS 和 ChromeOS 的影响： KDE Linux 的设计借鉴了 SteamOS 和 ChromeOS 的经验，这两者都具有强大的韧性和维护便利性。这表明 STF 认可了 KDE Linux 的设计理念。
• 欧洲数字主权趋势： 越来越多的欧洲组织正在寻求摆脱对美国云服务的依赖。例如，国际刑事法院 (ICC) 正在转向德国的 ZenDIS 提供的 OpenDesk 解决方案，以替代 Microsoft Office。法国数字事务总局 (DINUM) 也计划采用 Linux 桌面系统。
• DINUM 的解决方案： DINUM 计划使用 Nix 配置来构建定制的、不可变的操作系统镜像，而不是构建全新的发行版。该项目以 Sécurix 为基础镜像，并使用 Bureautix 作为示例配置，用户使用 YubiKey 进行身份验证，配置信息从服务器同步到客户端。Sécurix 和 Bureautix 的命名致敬了法国漫画人物 Astérix 和 Obélix。

总结：

德国主权科技基金对 KDE 项目的资助，以及欧洲其他组织对开源和本土化解决方案的日益关注，都表明了欧洲推动数字主权、摆脱对美国科技公司依赖的决心。KDE Linux 和 DINUM 的解决方案代表了欧洲在操作系统领域的重要尝试，有望为欧洲提供更安全、自主的数字基础设施。

古巴电力危机：燃料耗尽，美方援助争议

主要内容：

古巴正面临严重的电力危机，哈瓦那首都的电力供应已经中断至每天20-22小时。这主要原因是古巴的柴油和燃料油储备已经耗尽。古巴能源部长文森特·德拉·O·列维表示，由于美国自1月份实施的石油禁运，国家能源系统处于“维持生命”状态。

关键细节：

• 燃料短缺： 仅靠3月份俄罗斯赠送的73万桶石油已耗尽，目前电力供应完全依赖古巴国内的石油、天然气和可再生能源。
• 总统指责： 古巴总统米格尔·迪亚斯-卡内尔将电力短缺归咎于美国实施的“种族灭绝能源封锁”，并指责美国对向古巴供应燃料的国家实施威胁性的关税。
• 美方援助争议： 美国国务院声称提供1亿美元人道主义援助，但古巴政府否认收到过任何关于此援助的通知，称之为“虚构”和“1亿美元的谎言”。古巴外交部长布鲁诺·罗德里格斯质疑资金来源、分配方式以及援助的性质（现金或物资）。
• 美国制裁及禁运： 自特朗普政府于1月份恢复并加强对古巴的长期经济禁运以来，古巴失去了主要的石油供应来源（委内瑞拉），并面临来自其他潜在供应商的制裁威胁。特朗普政府还宣布古巴为“国家安全和外交政策的非常规和非同寻常的威胁”。
• 最新制裁： 近日，美国对古巴镍矿公司（Moa Nickel S.A.）和GAESA（古巴国有企业管理集团）实施了制裁，指控其将资金转移到海外账户，而非用于改善古巴的经济状况和基础设施。

总结：

古巴正在经历严重电力危机，燃料耗尽是主要原因。美国实施的石油禁运和制裁被认为是导致危机的关键因素。美国提出的援助方案受到古巴政府的质疑，双方就援助的真实性和意图存在争议。

GGUF 文件格式总结 (GGUF File Format Summary)

GGUF 是 llama.cpp 项目使用的语言模型文件格式。其主要优势在于它是一个单独的文件，相比于 Hugging Face 仓库（例如 Qwen/Qwen3.5-0.8B）的多个 JSON 文件或 Ollama 模型的 OCI 镜像，更加简洁易用。

主要内容包括：

• 聊天模板 (Chat Templates): 用于处理对话式语言模型的特定格式。这些模板使用 Jinja2 模板语言编写，定义了对话的结构和流程，例如用户和模型的角色切换、工具调用和多媒体信息处理。不同的模型可能使用不同的聊天模板，甚至包含多个模板以支持不同的功能（如工具调用）。
• 特殊标记 (Special Tokens): 用于控制语言模型生成过程。常见的特殊标记包括结束序列标记、开始序列标记以及用于工具调用的标记。这些标记不应该直接呈现给用户，但通常具有文本表示。
• 采样器配置 (Sampler Configuration): 定义了从模型输出的概率分布中选择下一个 token 的方式。GGUF 格式现在支持直接在模型文件中指定采样器链，取代了自定义格式。
• 采样器链顺序 (Sampler Chain Sequence): GGUF 标准允许指定采样步骤的顺序，这对于获得最佳结果至关重要。
• 缺失的功能 (Still Missing): 虽然 GGUF 已经涵盖了许多必要的内容，但仍有改进空间：
  • 工具调用格式 (Tool calling formats): 缺乏统一的工具调用语法，导致不同引擎需要为每个模型实现解析器。
  • 思考标记 (Think tokens): 缺乏用于标记模型思考过程的特殊标记，需要针对不同模型编写特定代码。
  • 投影模型 (Projection Models): 目前多模态 LLM 需要单独的投影模型文件，破坏了单文件管理的优势。建议将投影模型权重和配置嵌入到主 GGUF 文件中。
  • 支持功能列表 (List of Supported Features): 缺乏模型支持功能（如图像输入、工具调用、思考标记）的明确标识，导致需要进行猜测或编写 hacky 代码。

总结 (Conclusion):

GGUF 格式因其简洁性和可扩展性而备受推崇，并且拥有强大的社区支持。未来，GGUF 社区将继续努力完善标准，并提供更好的开发者体验，方便模型交换和应用开发。

特斯拉壁挂式充电器固件降级绕过：漏洞分析与利用

本文总结了对特斯拉壁挂式充电器固件更新流程的分析，并揭示了固件降级绕过的方法。

更新流程回顾：

特斯拉壁挂式充电器采用单线CAN (SWCAN) 进行固件更新，流程如下：

1. 启动 UDS (统一诊断服务) 会话 (类型 2)。
2. 使用安全访问级别 5，XOR-0x35 算法进行身份验证。
3. 运行例程 0xFF00，准备并擦除被动槽。
4. 将 0x0E 写入标识符 0x102，标记槽可 UDS 设置。
5. 使用 "Request Download" / "Transfer Data" / "Request Transfer Exit" 推送固件。
6. 运行例程 0x201，验证新写入的镜像并切换槽。
7. 运行例程 0x202，重启。

充电器使用两个固件槽：一个活动槽（当前运行）和一个被动槽（更新目标）。 更新成功后，槽位会翻转，新的固件在下次启动时生效。

固件版本 24.44.3 的变更：

主要变更集中在 switch_to_new_firmware() 函数 (对应 UDS 例程 0x201) 中。新增了 check_image_and_antidowngrade() 函数，用于解析固件片段、重新计算 CRC，并调用 verify_firmware_segments_platform() 进行安全锁紧 (ratchet) 比较。

安全锁紧信息嵌入在固件片段中 (VRSN 用于版本，VRS2 用于锁紧值)，位于 0x100000 到 0x100010 之间。只有固件更新程序会解析这些信息，引导加载程序 (bootloader) 不会。设备端锁紧值存储在 PSM (Persistent Storage Manager) 中，每次激活更高锁紧值的镜像时递增。

引导加载程序 (boot2) 的特性：

引导加载程序位于闪存的固定地址，不包含在 Tesla 发布的任何固件更新中。它执行以下检查：

• 魔术头部 (SBFH)
• 每个片段的 CRC32
• RSA 签名，使用 keystore 中的密钥

但引导加载程序不了解安全锁紧。 只要签名和 CRC 正确，它就会执行任何固件镜像，无论其版本如何。 因此，安全降级保护仅由 switch_to_new_firmware() 函数在调用例程 0x201 时执行。

槽位激活方式：

例程 0xFF00 调用 prepare_passive_slot()，根据当前启动标志选择“被动”物理槽并擦除它。 g_boot_flags 在启动时设置，并且在会话期间不会更新。 它反映了从哪个槽启动，而不是分区表当前所说的内容。

part_write_layout() 不会修改固件数据，只通过增加每个槽位的生成计数器来重写分区表。 引导加载程序在启动时选择具有最高 gen_level 的槽位。

降级绕过方法：

利用了安全锁紧只存在于更新程序中，且引导加载程序不检查锁紧值的漏洞。

1. 将有效的、最新的固件发送到被动槽，并调用例程 0x201，验证通过后，写入分区布局。
2. 在未重启的情况下，再次调用例程 0xFF00，由于 g_boot_flags 未改变，选择相同的物理槽作为被动槽，擦除先前验证的固件，但分区表保持不变。
3. 将旧的、已签名但存在漏洞的固件发送到现在的空槽。
4. 跳过例程 0x201 (因为它会拒绝该镜像)。 直接调用例程 0x202 重启。

重启后，引导加载程序读取分区表，选择具有最高 gen_level 的槽位（我们刚刚重写的槽位），验证其签名（仍然有效），并启动。 旧镜像上的安全降级检查从未运行。

漏洞利用：

利用了一个小的扩展版的 Pwn2Own 汽车模拟器。更新流程被重复执行：首先

WinUI 3 性能反馈：关于 DWM 同步的问题

以下是对提供内容的总结：

核心问题： 用户认为 WinUI 3 在运行时存在明显的渲染延迟，尤其是在窗口调整大小（resizing）时，缺乏与桌面窗口管理器 (DWM) 的同步导致体验不佳，严重影响了用户体验。

具体表现：

• 窗口调整大小的卡顿： 渲染内容无法与窗口边框同步，产生明显的延迟感。
• 与 UWP 的对比： UWP 应用通过私有 API 实现 Direct Composition (DComp) 同步，从而获得流畅的窗口调整大小效果。WinUI 3 缺乏这种同步机制。
• XAML Islands 的情况： 即使使用 WinUI 2 的 XAML Islands，也能通过 DComp 同步来实现与 UWP 相似的流畅效果，这使得 WinUI 2 在某些方面优于 WinUI 3。
• 手动实现成本高昂： 手动实现 DComp 同步需要大量时间，不具备实用性。

建议和期望：

• 与 DWM 团队沟通： 建议 Microsoft 团队与 DWM 团队沟通，解决同步问题。
• 启用 DComp 同步： 即使在 Windows 1809 及更高版本中不可行，也应考虑在较新版本的 Windows 11 中启用 DComp 同步，等待 DWM 团队发布可供 WinUI 3 使用的 API。
• 公开 DWM API： 建议将 DWM 相关 API 公开，允许开发者控制 UI 的渲染方式。
• 优化 DWM： 希望 DWM 能够减少 GPU 和内存占用，并提供更多开发者控制选项。
• 避免 Web 应用的体验： 当前 WinUI 3 的窗口调整大小体验与 Web 应用相似，这降低了其作为原生应用的吸引力。

当前选择：

• 由于 WinUI 3 性能问题，用户目前选择使用 QT Widgets 和 wxWidgets 等替代方案，这些方案在窗口调整大小方面表现更好，并能降低项目对特定操作系统平台的依赖。

总结： 用户对 WinUI 3 的未来发展持乐观态度，但强调 DWM 同步对于提升 WinUI 3 的吸引力至关重要。 缺乏 DWM 同步是目前阻碍用户采用 WinUI 3 的主要原因。