Adobe MAX大会展示创新AI工具Project Turntable

在Adobe年度MAX大会上，公司除了发布已确定的新功能，还会通过“Sneaks”环节展示一些概念性技术。其中，Project Turntable 是一款备受瞩目的AI工具，它允许用户将2D矢量图形在三维空间中旋转，同时确保图形从任何新角度观看时仍保持为完全扁平的2D艺术。

该工具的核心技术在于，旋转过程中AI会智能地填补图像中的空白部分，使矢量图形即使在动态旋转时也看似3D对象，但最终静态画面仍忠于原始2D设计。例如，在演示中，一个仅显示两条腿的2D马匹旋转后，AI自动生成了另外两条腿，完整地呈现出立体视角下的马匹形象。

此项目由Adobe研究员陈志钦领导开发。Adobe的Brian Domingo表示，与其它创新项目类似，Project Turntable不一定会上线商业化，但团队预期它将在MAX大会上引起广泛关注。

本次大会上，Adobe已宣布超过100项以创作者为中心的新功能，包括自动图像干扰移除和生成式工作区等。结合同期其他科技公司的重大发布，本周被认为是迄今为止AI领域最具影响力的一周。

ArchiveBox是一个自托管的互联网存档工具，旨在构建一个去中心化的存档网络，作为对中心化Archive.org的补充。面对当前网络环境，项目强调为个人和组织提供私密、半私密的存档能力，以保存对自己重要的内容。

项目背景与愿景：

• 在Archive.org遭受攻击后，ArchiveBox作为自托管替代方案受到关注。
• 项目愿景是未来世界既有健壮的集中式Archive.org，也有广泛分布的、去中心化的ArchiveBox实例网络。

公共存档的局限与新需求：

• 出于对公众审视的恐惧，许多人不愿永久存档，导致历史被遗忘。
• 现代网络用户更注重隐私，希望存档家庭相册、个人书签、公司内部文档等私人内容，并能控制分享范围。
• 对于仇恨言论等有害内容，需要在保留历史记录的同时，避免为其提供公开的免费托管服务。

核心更新：插件生态系统：

• ArchiveBox v0.8是项目历史上最大的更新，重构了内部架构以提升性能，并引入了基于pluggy和pydantic的插件系统。
• 该系统旨在打造一个类似NextCloud或Home Assistant的“应用商店”，支持社区开发的丰富功能。
• 即将推出的部分插件包括：
  • yt-dlp：从多个网站下载视频、音频。
  • papers-dl：通过DOI号自动下载科学论文PDF。
  • gallery-dl：下载Flickr、Instagram等平台的图库。
  • ai：利用大语言模型处理页面截图和文本。
  • webhooks：在存档结果保存时触发外部API。

其他重要新功能与改进：

• 全新的REST API（基于django-ninja）已进入测试版。
• 外部存储支持：可通过rclone连接AWS、B2、Google Drive等云存储。
• 内容寻址存储：引入基于URL和时间戳的唯一标识符（ABID），为未来实例间的P2P共享奠定基础。
• 后台作业系统：使用huey管理任务。
• 简化安装：新的archivebox install命令自动处理依赖。
• abx-dl工具：为追求简单的用户提供的轻量级命令行工具，可一键下载URL内容，无需复杂配置。

项目立场与展望：

• 项目以本地优先（SQLite）为核心设计，P2P共享功能始终是可选的。
• 鼓励用户尝试新的测试版（如pip install archivebox==0.8.5rc50），并支持ArchiveBox及Archive.org的发展。

Winamp 于2024年9月24日通过其比利时所有者 Llama Group 发布了“Legacy Player Code”源代码，旨在让开发者帮助这款标志性软件进化。然而，不到一个月，整个代码库已被完全删除，原因是其许可证条款存在严重问题，并可能涉及代码泄露。

主要问题包括：

1. 许可证条款具有争议：Winamp 采用了“Winamp Collaborative License (WCL) Version 1.0.1”，禁止分发修改版本（无论源代码或二进制），仅允许官方维护者分发软件及修改。这与开源社区的协作精神相悖，原始开发者 Justin Frankel 也批评该条款“完全荒谬”。
2. 代码包含其他项目的授权代码：仓库中似乎混入了其他项目（采用更严格许可证）的代码，尽管这些代码后来被删除。
3. 可能泄露专有软件源码：分析显示，该代码库可能意外包含了 SHOUTcast 服务器软件的源代码，以及来自 Intel 和 Microsoft 的专有软件包。
4. 删除操作无效：Winamp 试图通过直接删除文件来移除问题内容，但 Git 历史仍可追溯，使得敏感代码对熟悉 Git 机制的人依然可见。

尽管许可证限制分支，该仓库仍被 fork 超过 2,600 次，反映出社区对 Winamp 的关注。此次事件导致 Winamp 与开源社区关系紧张，最终以整个代码库被删除收场。

AI PC基准测试：高通NPU实际性能远低于宣传

测试背景与目的

作者在微软Surface平板（搭载高通骁龙X Elite芯片）上对NPU进行基准测试，旨在验证其作为“AI PC”的实际机器学习性能。尽管高通宣传其NPU算力达45 TOPS，但实际测试结果仅为宣传值的1.3%，且NPU运行速度甚至不及CPU。

测试环境与配置

• 硬件：微软Surface Pro 11，搭载12核骁龙X Elite处理器（3.40 GHz）。
• 软件：
  • Python 3.11.9（需从官网安装，因微软商店版本不支持ARM）。
  • Visual Studio Community Edition（用于编译ONNX）。
  • 高通ONNX Runtime（需自行编译，预构建包不支持Windows on ARM）。
• 测试设置：
  • 电源模式设为“最佳性能”。
  • 高通ONNX Runtime会话模式设为sustained_high_performance。

测试方法与模型设计

• 测试模型：模拟Transformer架构中的计算密集型操作，包含6个大型矩阵乘法（形状为(6, 1500, 256) × (6, 256, 1500)）。
• 对比方案：
  1. CPU基准：全浮点运算。
  2. NPU方案一：官方量化方法（量化计算，浮点输入/输出）。
  3. NPU方案二：自定义量化（全量化计算与输入/输出）。
• 评估指标：延迟时间（ms）和等效吞吐量（十亿次运算/秒）。

关键测试结果

• NPU vs CPU：即使采用优化的全量化方案，NPU吞吐量（573 Gigaops/s）仍低于CPU（821 Gigaops/s）。
• NPU vs 宣传：全量化NPU吞吐量仅为宣传值（45 Tops/s）的1.3%。
• 对比GPU：NVIDIA RTX 4080笔记本GPU延迟仅3.2ms，吞吐量达2160 Gigaops/s，为NPU的3.8倍。

影响性能的可能因素

1. 计算限制：测试设计为计算密集型（避免内存瓶颈），但NPU驱动或实现可能存在优化不足。
2. 数据转换开销：官方量化方案中浮点与量化数据的转换占用超过75%的时间，作者通过全量化方案规避。
3. 软件生态：
   • ONNX Runtime是目前Windows on ARM上对NPU支持较好的框架，但存在版本兼容性问题（需使用ONNX 1.16分支）。
   • 其他框架（DirectML、OpenVino、TensorFlow Lite）在ARM平台上支持有限或性能不佳。
4. 配置与误差：可能因量化参数（如无符号8位）、驱动实现等导致性能未达预期。

结论与展望

• 当前NPU表现：实际算力显著低于宣传，且未超越CPU性能，难以发挥“AI加速器”优势。
• 软件优化需求：作者期待未来通过驱动、框架或应用层面的优化提升性能，并指出在其他平台（如Android）上类似硬件表现更佳。
• 技术建议：若需在Windows on ARM上获得最佳AI性能，建议使用ONNX Runtime并采用全量化模型，但需注意当前生态限制。

注：本文所有数据基于2024年10月2日的测试环境，性能可能随后续软件更新而变化。

本文介绍了作者通过“视频抓取”技术，利用屏幕录像和AI模型低成本提取数据的实验过程。

核心方法 作者需要从12封邮件中提取日期和金额数据。为避免手动操作，他使用Mac的QuickTime录制了一段35秒的屏幕视频，内容是其在Gmail中依次点开相关邮件。随后，他将视频上传至Google AI Studio，并提示模型将数据转换为JSON格式。模型准确完成了任务，他进一步将JSON转为CSV以便粘贴使用。

成本与模型选择 整个实验意外使用了更便宜的Gemini 1.5 Flash 002模型（而非计划中的Pro版）。计算显示，处理过程消耗了11，018个token（其中10，326个为视频token），按官方价格计算，总成本不足0.1美分。由于AI Studio在部分地区免费，本次实验实际无费用产生。

方法优势与对比 作者将此方法与其他数据获取方式（手动复制、编程访问Gmail API、浏览器自动化、专用AI工具）进行了对比，认为视频抓取具备以下突出优点：

• 无设置成本：登录即录，无需复杂配置。
• 规避反爬限制：基于用户屏幕操作，不受网站认证或反爬技术影响。
• 数据控制权：用户自行决定暴露给AI的屏幕内容。
• 成本极低：一次典型处理费用微乎其微。
• 结果可控：取决于用户操作屏幕和点击的方式。

可靠性提示 作者补充提醒，由于LLM的固有特性，不能100%信赖其结果的准确性。对于重要项目，需通过人工抽检等方式进行复核。

附加工具 为简化token价格计算，作者使用Claude 3.5 Sonnet生成了一个交互式LLM定价计算器工具，该工具可手动输入或选择预设模型价格。

文章摘要：使用Cloudflare可能意外阻止RSS用户访问网站

许多网站用户依赖RSS阅读器获取更新。然而，当网站启用Cloudflare的某些安全功能时，可能会在无意中阻止合法的RSS用户访问内容。

问题原因

Cloudflare仪表板中的 “机器人战斗模式” 和 “封锁所有AI爬虫和抓取工具” 等工具，旨在拦截恶意机器人流量。这些功能会基于一个评分（由Cloudflare的人工智能生成）评估每次访问，并将其判定为“AI爬虫”或“机器人”。RSS阅读器访问网站时，Cloudflare会向其呈现无法完成的人类验证挑战（如验证码），或直接无理由地阻止访问。

影响

RSS用户无法获取网站内容。唯一的解决方法是联系网站所有者，由其在Cloudflare中添加自定义规则以解除阻止。但这对用户和网站管理员都带来了不便，尤其是当一个RSS服务需要访问成千上万个网站时。

文章提出的临时解决方案

1. 添加白名单：网站管理员可以在Cloudflare中查找被阻止的RSS阅读器的用户代理（User-Agent）或IP地址，然后创建自定义规则将其加入白名单。文章指出，基于IP地址的白名单通常更可靠。
2. Cloudflare的机器人验证程序：RSS服务所有者可以申请加入此程序以避免被阻止。但文章指出该程序存在严重问题：
   • 验证流程不透明且不靠谱（例如使用谷歌表单申请，无状态更新）。
   • 即使通过验证，RSS阅读器仍可能被网站阻止。
   • 要求RSS服务商联系每个网站所有者添加例外的做法，在规模化运营中不现实。

文章的核心观点

Cloudflare的安全工具对于防御恶意机器人是必要的，但需要确保RSS用户等合法工具不被误伤，并应简化相关问题的解决流程。文章作者（Open RSS）正在跟踪此问题，并提供了相关进展的RSS订阅链接。

本文详细介绍了Chromium浏览器中的两个漏洞（CVE-2024-5836 和 CVE-2024-6778）如何被组合利用，以实现从浏览器扩展中逃逸沙箱，并在用户计算机上执行任意命令的过程。

漏洞概述 这两个漏洞共同构成了一个利用链。攻击者可以创建一个恶意Chrome扩展，在用户打开DevTools时自动触发，最终在chrome://policy这一特权WebUI页面上执行JavaScript代码。该代码能够通过漏洞设置恶意的企业策略，从而利用“浏览器切换器”功能执行任意shell命令，完全控制操作系统。

漏洞利用链详解

1. 第一步：在特权WebUI页面执行代码 (CVE-2024-5836 & CVE-2024-6778)

   • 目标页面：chrome://policy。这是一个具有更高权限的WebUI页面，其上运行的JavaScript可以调用私有API与浏览器底层C++代码通信。
   • 攻击入口：扩展通过chrome.devtools.inspectedWindow.reload() API向检查中的页面注入JavaScript脚本。正常情况下，扩展无法在chrome://等特权页面上执行代码。
   • 漏洞方法：
     • 竞态条件法 (CVE-2024-5836)：扩展持续调用inspectedWindow.reload()注入脚本，同时将标签页导航至chrome://policy。在浏览器内部禁用DevTools API之前存在一个极小的时间窗口，如果注入请求在该窗口内到达，脚本就能在特权页面上执行。此方法可靠性约70%。
     • 崩溃排队法 (CVE-2024-6778)：扩展首先使标签页崩溃（例如通过连续触发debugger语句）。Chrome的调试协议存在一个疏忽：即使页面崩溃，Page.reload类型的请求也不会被清除。随后，扩展将标签页导航至chrome://policy，之前排队的reload请求会在新页面上执行，从而注入脚本。此方法可靠性达100%。
   • 根本原因：上述漏洞的根本原因在于inspectedWindow.reload() API在检查页面状态时存在缺陷，未能充分验证页面的来源（origin），并且允许在页面崩溃后继续处理reload请求。

2. 第二步：滥用企业策略设置功能

   • 目标：通过执行的脚本，调用chrome://policy页面的私有API setLocalTestPolicies 来设置任意用户策略。
   • 漏洞：PolicyTestPageEnabled策略（用于启用策略测试页面）的检查存在缺陷。在LocalTestPolicyProvider::CreateIfAllowed函数中，IsPolicyTestingEnabled被调用时，其pref_service参数为null，导致策略启用检查被跳过。对于Chromium及其衍生版本，仅剩的发布渠道（channel）检查总是会通过（因为渠道值被识别为DEFAULT），从而允许未授权地设置测试策略。

3. 第三步：实现沙箱逃逸

   • 利用策略：通过设置BrowserSwitcherEnabled、BrowserSwitcherUrlList、AlternativeBrowserPath和AlternativeBrowserParameters等企业策略。
   • 执行命令：这些策略可以配置为，当浏览器访问特定URL（如example.com）时，启动一个任意可执行文件（如/bin/bash）并带有自定义参数。通过构造特定的参数（例如包含注释#和待执行命令），可以诱使浏览器执行任意shell命令（如启动计算器）。

修复与奖励 Google确认了漏洞并将其评为P1/S1高优先级和高严重性。

• 主要修复：为Page.reload命令添加了loaderId参数验证；在inspectedWindow.reload()函数中增加了URL检查；在WebUI处理器中添加了策略启用状态的真实检查。
• 奖励：作者因此获得了20,000美元的漏洞赏金。

总结 这个案例表明，多个看似微小的设计缺陷或疏忽（如不完整的检查、遗留的代码异常、未文档化的功能）可以被巧妙地串联起来，形成高严重性的安全漏洞。漏洞利用链涉及通过DevTools API注入代码到特权页面，以及滥用未受充分保护的企业策略测试功能来执行系统命令。

WiPhone：一款简单、开源、可用Arduino编程的手机

核心理念

WiPhone 是一款极简主义的 WiFi 手机，旨在让用户“掌控自己的手机”，而非被其束缚。它摒弃了传统智能手机的复杂功能和商业生态的“围墙花园”，专注于提供可控、可定制、注重隐私的通信工具。

主要特点与设计

1. 极简功能：WiPhone 仅支持通话和短信功能，没有应用商店、复杂界面或物理蜂窝网络模块，从而极大减少了追踪风险。
2. 基于 VoIP 通信：所有通话和短信均通过 WiFi 网络使用 VoIP 协议完成。用户可选择商业 VoIP 服务商，或自行搭建私有通信服务器（如使用 Asterisk），实现完全掌控。
3. 开源与可编程：
   • 硬件：基于 ESP32 芯片，完全支持 Arduino IDE 进行编程，拥有庞大的开源示例库。
   • 软件：开源固件允许用户深入研究、修改操作系统或驱动程序，实现深度定制。
   • 扩展性：手机背部设有 20 针可编程接口，并可更换为自定义电路板，方便进行硬件黑客与 DIY 项目。
4. 隐私优先：无蜂窝模块意味着无基于物理或互联网的追踪，用户数据不依赖于商业公司。
5. 离线通信能力：通过可选的 LoRa 模块，WiPhone 可实现点对点离线文本消息发送，无需任何网络服务，适用于偏远地区或应急通信。

硬件规格

• 处理器：ESP32 双核 240 MHz。
• 内存：4MB PSRAM，16MB Flash。
• 屏幕：2.4 英寸（320x240 分辨率）。
• 连接：802.11 b/g/n WiFi，Bluetooth/BLE 双模（软件暂未启用）。
• 电池：900 mAh，正常使用下续航约 8 小时。
• 接口：Micro USB（充电/串口/固件更新）、3.5mm 音频孔、内部 MicroSD 卡槽。
• 输入：25 键背光键盘（全部可编程，其中 4 键为用户预留）。
• 物理：尺寸 120 x 50 x 12.5mm，重 120g。

产品版本

• Regular 版：聚碳酸酯边框，可选透明或灰色前面板。
• Pro 版：阳极氧化铝边框，可选透明或灰色前面板。

社区评价

该项目在硬件和创客社区获得积极评价，被称赞为“电话形态与黑客精神的完美结合”、“尊重维修权的优秀项目”。

适用场景

• 创客与开发者：进行硬件原型开发、学习底层系统编程。
• 隐私倡导者：寻求替代性、可自控的通信方式。
• 特定场景通信：通过 LoRa 实现离网通信，适合徒步、航海或应急准备。
• 教育与实验：学习 VoIP、Arduino 编程和网络搭建。

本文探讨了语言与思维之间的关系，质疑了“语言是思维必要前提”的传统观点。文章指出，尽管哲学家伯特兰·罗素认为语言使思想成为可能，但动物界的大量现象表明，许多高级认知活动（如黑猩猩的策略游戏、乌鸦的工具制作）可以在没有语言的情况下进行。

神经科学家埃维琳娜·费多连科的研究为“语言与思维分离”提供了关键证据。她通过两种互补的方法得出了这一结论：

1. 对失语症患者的观察：即使因左脑大面积损伤而完全丧失语言能力（全球性失语症）的个体，仍能正常完成数学、逻辑、社会推理等多种认知测试。这表明高级思维可以在没有语言的情况下进行。
2. 脑成像研究：利用功能性磁共振成像技术，可以精确定位大脑中的语言区域。研究发现，当人们进行逻辑拼图、数独、规划决策等非语言思维任务时，这些语言区域基本处于静默状态。相反，数学、音乐等领域的层次结构处理由其他脑区负责。

因此，研究认为语言并非“思维的骨架”，而主要是一个高效的沟通工具，类似于“心灵感应”，使人类能够向他人传递内心想法、分享知识，并将信息代代相传。这种能力为人类这一超社交物种带来了巨大的进化优势，促进了合作、工具制造知识传播以及复杂社会关系的维护。

文章进一步指出，人类认知的独特性并非源于单一的“黄金门票”，而是大脑中多个功能系统协同进化的结果，其中包括语言系统、心理理论系统、新颖问题解决系统以及跨情境信息整合系统等。语言是这些系统之一，但并非思维本身的创造者。

最后，文章提及了大型语言模型（如GPT系列）在神经语言学研究中的新角色。这些模型虽然擅长语言处理，但并不擅长思维，这与“语言系统本身不等于思维”的观点一致。同时，它们作为首个可操控的“语言模型有机体”，为研究语言的发展、输入与大脑反应之间的关系提供了前所未有的实验平台。

OpenVMM：一款用 Rust 编写的新型跨平台虚拟机监控程序

概述

OpenVMM 是一款用 Rust 编写的模块化、跨平台虚拟机监控程序，支持 Windows 和 Linux 系统。虽然它可以作为传统的 VMM 使用，但当前的开发重点是将其作为 OpenHCL paravisor 的组成部分。本代码仓库同时托管了这两个项目。

主要特点

• 语言与设计：使用 Rust 语言开发，注重模块化和跨平台兼容性。
• 当前重点：专注于作为 OpenHCL paravisor 的核心组件进行开发和优化。
• 项目结构：同一仓库包含 OpenVMM 和 OpenHCL 两个项目。

快速入门

• 有关如何运行、构建和使用 OpenVMM 的详细信息，请参考 《OpenVMM 指南》。
• 指南以 Markdown 文件形式在本仓库中发布和维护，建议用户和开发者保持其及时更新。

贡献指南

• 项目欢迎社区贡献和建议。
• 大多数贡献要求贡献者签署贡献者许可协议（CLA），以明确贡献的授权条款。提交拉取请求时，CLA 机器人将自动检查并提示是否需要签署。
• 项目遵循 《微软开源行为准则》，相关问题可通过指定邮箱联系。

商标说明

• 项目中可能包含微软或其他第三方项目的商标或标识。
• 对微软商标或标识的使用必须遵守微软商标和品牌指南，不得造成混淆或暗示官方赞助。
• 第三方商标的使用需遵循相应第三方的政策。

文章摘要

背景与挑战

作者运营了一个名为Invex Gaming的CSGO社区服务器（2014-2019），面临作弊者封禁的难题。传统反作弊方法包括服务器端检测、VAC系统及人工审核，但作弊者通过同时更改IP地址和Steam ID来规避封禁，使得追踪困难。

封禁机制与规避问题

• 封禁标识：服务器使用IP地址和Steam ID作为唯一标识，一旦玩家被封禁，其相关标识会被加入黑名单。
• 规避方法：作弊者可同时更换IP地址（如使用VPN）和Steam ID，以新身份重新加入服务器，避免被识别。这导致封禁失效，且共享网络（如家庭或校园）可能误封无辜玩家。

IdentityLogger系统

为解决此问题，作者开发了IdentityLogger系统，利用CSGO内置的VGUI浏览器（支持JavaScript和Steam cookies）：

• Tracking ID引入：通过隐藏浏览器窗口，强制玩家访问服务器控制的秘密网站，设置持久化cookie（Tracking ID），存储在玩家本地Steam安装目录中。
• 指纹识别：结合IP地址、Steam ID和Tracking ID进行三重标识。Tracking ID与玩家本地文件关联，即使更改IP和Steam ID，仍能通过cookie追踪作弊者。
• 实施细节：系统在玩家连接时自动检查数据库，若匹配已封禁标识则踢出，并记录新标识。所有请求通过HTTPS加密，增加破解难度。

效果与影响

• 2017年部署后：大量作弊者被快速封禁，社区声誉提升，作弊行为显著减少。作弊者无法理解如何被检测，因技术细节保密。
• 持续有效性：系统持续运行至2017年10月Valve移除VGUI浏览器。此后作者公开技术并开源插件。

关键点

• IdentityLogger通过创新的cookie追踪解决了同时更改IP和Steam ID的规避问题。
• 系统依赖于CSGO特有功能，操作隐蔽，对作弊者几乎不可见。
• 该方案展示了社区运营中技术应对挑战的实用性。

文章主题
向 CPython 解释器添加新语法，使 Python 支持省略 else 的三元表达式，并默认返回 None。

目标功能
在现有 Python 中，若省略 else 部分，条件表达式会报错。修改后，支持以下用法：

"hello" if 2 + 2 == 4   # 返回 "hello"
"hello" if 2 + 2 == 5   # 返回 None

实现步骤

1. 环境准备：克隆 CPython 源码并编译解释器。

   git clone git@github.com:python/cpython.git
   cd cpython
   ./configure && make
   

2. 修改语法文件：编辑 Grammar/python.gram，为 expression 规则添加新分支。

   • 原规则仅支持 a if b else c 格式。
   • 新增 a if b 规则，当条件为假时返回 None：

     | a=disjunction 'if' b=disjunction { _PyAST_IfExp(b, a, _PyAST_Constant(Py_None, NULL, EXTRA), EXTRA) }
     

3. 重新生成解析器：运行 make regen-pegen 更新语法解析代码，然后重新编译解释器。

4. 验证功能：使用新编译的解释器测试三元表达式。

   print("hello" if 2 + 2 == 4)  # 输出: hello
   print("hello" if 2 + 2 == 5)  # 输出: None
   

关键点

• 通过修改 CPython 的 PEG 语法文件实现语法扩展。
• 新增语法规则利用 _PyAST_IfExp 和 _PyAST_Constant 生成抽象语法树节点。
• 此示例演示了如何通过修改源码为 Python 添加自定义语法。

微信MMTLS加密协议安全分析摘要

核心发现

• 本研究首次公开分析了拥有超10亿月活用户的微信其主网络协议MMTLS的安全与隐私属性。
• MMTLS是TLS 1.3的修改版，但微信开发者的多项密码学修改引入了弱点。
• 微信早期版本使用安全性更低的自定义“业务层加密”协议，该协议在现代微信版本中与MMTLS同时使用。
• 尽管未能开发出完全破解微信加密的攻击，但其实现与十亿级用户应用应有的密码学水平不符，存在确定性IV、缺乏前向保密等问题。
• 研究工具与文档已在GitHub开源，以辅助后续研究。

协议结构与加密机制

微信网络请求经历双重加密：

1. 外层MMTLS加密：基于TLS 1.3修改，负责网络传输层加密。
2. 内层业务层加密：处理应用数据，分为对称与非对称两种模式。

MMTLS外层加密细节

• 密钥交换：使用Diffie-Hellman密钥交换。
• 加密算法：使用AES-GCM。
• 数据记录：分为握手记录、数据记录、警报记录等，结构模仿TLS。
• 连接类型：
  • 短连接：基于HTTP，每个请求响应周期重建连接，大量使用预共享密钥（PSK）恢复会话。
  • 长连接：基于持久TCP连接，为每个连接生成新密钥。

业务层内层加密细节

• 非对称模式（未登录时使用）：使用静态Diffie-Hellman与新鲜客户端密钥对，并用AES-GCM加密。
• 对称模式（登录后使用）：使用服务器提供的session_key，主要用AES-CBC加密，并辅以基于MD5和Adler32的伪签名进行完整性检查。

主要安全问题

MMTLS外层加密弱点

1. 确定性IV：为每个连接生成单个IV后递增使用。在AES-GCM中重用（密钥，IV）对是灾难性的，可能导致密钥恢复攻击。对于十亿级用户规模，暴力破解特定组合具有可行性。
2. 缺乏前向保密：广泛使用预共享密钥（PSK）和持久长连接，导致大部分网络数据在连接间不具备前向保密性。

业务层内层加密弱点

1. 元数据泄露：用户ID、请求URI等元数据未加密。
2. 可伪造的完整性检查：genSignature()函数基于MD5和Adler32，可在不知密钥的情况下伪造有效签名。
3. 潜在的AES-CBC填充预言攻击：使用PKCS7填充的AES-CBC可能易受攻击。
4. 密钥与IV重用：在对称模式下，同一session_key被重复用作加密密钥和IV，导致相同明文产生相同密文。
5. 加密密钥熵不足：服务器生成的session_key仅使用可打印ASCII字符，熵约106位而非128位。
6. 无前向保密：登录后，所有通信使用相同的session_key，直到重启应用。

研究方法与局限性

• 分析对象：微信Android 8.0.21和8.0.23版本。
• 主要方法：使用Frida进行动态分析（hook函数、导出内存），使用Jadx、Ghidra、IDA Pro进行静态分析（反编译APK和原生库）。
• 开源组件：识别出微信使用OpenSSL和腾讯Mars开源库（提供网络等基础功能），但加密相关部分（MMTLS）未开源。
• 局限性：仅分析客户端行为；使用美国手机号测试，可能无法完全代表中国用户行为；仅分析Android版本；未进行全面安全审计。

讨论与建议

• 为何业务层加密重要：它曾是微信唯一的加密层；即使在MMTLS被解密后，内层加密仍是保护数据的最后屏障（假设内部服务器间未重新加密）。
• 为何不使用标准TLS：微信开发者声称是为了实现TLS 1.3的0-RTT会话恢复以满足短连接性能需求，且当时TLS 1.3尚未正式成为RFC。但作者指出，当时已有TLS 1.2会话恢复机制，且现在标准QUIC+TLS已能提供前向保密和单次握手。
• 行业趋势：这反映了中国生态中众多应用偏好自研、往往存在问题的密码系统，而非采用已验证的最佳实践。
• 建议：
  • 对微信开发者：迁移到标准的TLS或QUIC+TLS实现，以提升安全性和性能。
  • 对用户：为降低动态代码加载风险，建议从Google Play商店下载微信而非官网。
  • 对研究界：MMTLS用户量级巨大，但缺乏第三方审查，呼吁进一步研究。

结论

微信的MMTLS协议作为TLS 1.3的定制修改版，虽然意图解决性能问题，但引入了多个密码学弱点。其双层加密架构中的内层业务层加密存在严重缺陷。尽管在当前架构下攻击难度增加，但整体实现未达到十亿级应用应有的安全标准。研究揭示了在中国应用生态中普遍存在的“自研密码学”趋势的风险，并为改进提供了具体路径。

太阳能自托管网站实验摘要

项目概述

作者进行了一项实验，搭建了一个完全由太阳能供电、运行在树莓派上的自托管网站（https://solar.dri.es）。该网站部署在波士顿家中的屋顶露台，使用太阳能电池板和电池供电，旨在探索可持续、本地优先的网页托管方式。

动机与背景

• 作者拥有超过20年的网页开发及大型网站托管经验。此项目是一个专注于可持续性和本地优先的业余项目，旨在使用尽可能小且节能的设置，即使网站可能会间歇性下线。
• 主要动机是探索更环保的网站托管方式，并倡导“本地优先”理念，即小型个人网站可以托管在自家的网络连接上。
• 此举也契合作者对开放网络和独立网络（IndieWeb）的承诺。

硬件配置

• 太阳能系统：核心为一块50瓦的伏能士（Voltaic）太阳能板，搭配一个18安时的磷酸铁锂电池。电池内置带最大功率点跟踪（MPPT）技术的充电控制器，优化充电并具备过充、低温保护等功能。
• 服务器：选用树莓派Zero 2 W，主要原因是其卓越的能效（空闲功耗0.4瓦，负载约1.3瓦），可使网站在电池供电下持续运行约一周。作者也评估了性能更强的树莓派4，但其功耗约为Zero 2的5倍，现有的太阳能设置可能无法在冬季支撑其运行。
• 电压转换：使用降压转换器将太阳能板的12伏输出转换为树莓派所需的5伏。

网络与部署

• 连接：利用树莓派内置Wi-Fi无线连接至家庭网络。
• 安全：为树莓派设置了独立的虚拟局域网（VLAN）进行隔离。
• 外部访问：通过路由器端口转发将HTTP/HTTPS流量导向树莓派。由于家庭IP地址动态变化，作者编写脚本每10分钟通过Cloudflare自动更新DNS记录。
• 网络服务：使用Caddy作为Web服务器，并自动获取Let's Encrypt的SSL证书以支持HTTPS。
• 重要说明：家庭路由器和网络设备仍依赖常规电力，并非太阳能供电；网站也没有故障转移机制，若ISP或家庭网络中断，网站也会下线。

监控与仪表板

• 利用电池充电控制器的RS485接口，通过树莓派扩展板采集太阳能板输出、电池状态（容量、温度等）等实时数据。
• 数据通过网络服务API发送至作者的主网站（https://dri.es，托管于Acquia），并在一个自定义的仪表板上显示。这确保了即使太阳能网站下线，关键状态信息依然可以访问。

能耗与影响分析

• 树莓派Zero 2 W平均功耗1瓦，年耗电量约9千瓦时。按波士顿电价计算，每年仅节省约2.85美元电费，减少约4公斤二氧化碳排放。
• 作者认为，从单一设备看影响有限。但与传统的大型数据中心托管相比，这种低功耗设备托管基础网站的方式，在成本和可持续性上更具优势。
• 项目也引发了关于网站高可用性必要性的思考：对于非关键网站，允许适当的下线时间，可以减少资源过度配置，使网络更加绿色高效。

挑战与未来计划

• 主要挑战：磷酸铁锂电池的充电控制器在气温低于0°C时会停止充电，无法在波士顿的寒冬中为电池充电。作者正研究电池加热、保温或更换更耐低温的电池等解决方案。
• 扩展计划：
  • 将单页网站扩展为包含数百甚至数千页面的网站。
  • 测试在树莓派Zero 2 W上运行Drupal（其主网站的内容管理系统），或尝试升级至树莓派4/5。
  • 实验为主网站创建静态版本，以降低资源需求。
• 监控系统问题：附录中提到，电池内置的充电控制器在电流测量、低温保护后的自动恢复等方面存在一些不便和局限性。

kalmangrad：自动化平滑处理带噪数据的N阶导数

kalmangrad是一个Python包，用于计算非均匀采样时间序列数据的自动化平滑N阶导数。该方法利用贝叶斯滤波技术来计算任意指定阶数的导数，为对噪声敏感的传统数值微分方法提供了一种鲁棒的替代方案。该包基于bayesfilter包构建。

核心特性

• 高阶导数估计：可计算直至任意指定阶数的导数。
• 抗噪声性：采用贝叶斯滤波以减轻数据中噪声的影响。
• 灵活的时间步长：能够处理非均匀采样数据，并自动调整时间步。
• 易于集成：简单的API设计，便于集成到现有项目中。
• 依赖少：仅需NumPy和BayesFilter包（后者本身也仅需NumPy）。

安装

可通过PyPI或从源码安装：

pip install kalmangrad
# 或
git clone git@github.com:hugohadfield/kalmangrad.git
cd kalmangrad
pip install .

主要用法

核心函数是grad，用于估计输入数据y（采样于时间点t）的导数。

def grad(y: np.ndarray, t: np.ndarray, n: int = 1, delta_t=None, obs_noise_std=1e-2, online: bool = False, final_cov: float = 1e-4) -> Tuple[List[Gaussian], np.ndarray]:
    """
    使用贝叶斯滤波/平滑估计输入数据y直至n阶的导数。

    参数:
    - y: 观测数据数组。
    - t: 对应于y的时间点。
    - n: 最高导数阶数（默认为1）。
    - delta_t: 贝叶斯滤波器的时间步长。若为None，则自动确定。
    - obs_noise_std: 观测噪声的标准差（默认1e-2）。
    - online: 标志位，指示以在线（仅使用当前及之前数据）或离线（默认，使用全部数据）方式运行滤波器。
    - final_cov: 过程噪声矩阵对角线上的最终协方差。

    返回:
    - smoother_states: 包含每个导数均值和协方差估计的高斯状态列表。
    - filter_times: 与估计值对应的时间点。
    """

示例说明

该包提供了使用示例，演示如何对带噪声的正弦波数据估计一阶和二阶导数，并将结果与真实值及np.gradient的计算结果进行对比。这直观地展示了其在噪声环境下获得平滑导数估计的能力。

内部函数概述

• transition_func(y, delta_t, n)：计算时间t + delta_t的新状态向量。
• transition_matrix(delta_t, n)：返回状态转移矩阵A。
• observation_func(state)：从状态向量中提取观测值（仅观测第一个元素，即位置）。
• jac_observation_func(state)：计算观测函数关于状态向量的雅可比矩阵。

依赖与许可

• 依赖：Python 3.x, NumPy, Matplotlib（用于示例绘图）, BayesFilter。
• 许可：MIT许可证。
• 免责声明：代码按原样提供，无任何保证，请在具体使用场景中自行测试和验证。

文章摘要：理解官僚主义的演变

1. 组织效率的核心公式

文章开篇指出，成功组织旨在最大化“有意义的输出 / 资源消耗”这一比值。

• 有意义的输出：与组织宗旨一致的成果。
• 资源消耗：主要指时间和金钱。 组织可通过提高输出或降低消耗来优化此公式。官僚机构的问题在于，它们严重破坏了这个公式：复杂的系统、委员会和流程阻碍了有意义输出的产生，同时维持这些复杂性本身就需要消耗巨大资源。

2. 官僚机构的特性与成因

官僚机构具有极强的静态性和变革阻力，主要原因有二：

• 惯性：其规模与复杂性创造了巨大的现状惯性，改变需要巨大能量，且威胁到内部权力者的地位。
• 幻觉工作：员工忙于在官僚体系中生存（如应对各种审批、会议、报告），没有精力与空间去改变体系本身。文章以谷歌为例，指出员工常被淹没在流程中，系统性地磨灭了他们创造影响的渴望。 关键在于，官僚主义并非组织成长的自然结果，而是领导者一系列看似正确的决策累积所致。文章引用了中情局（CIA）曾用于瓦解活动组织的手册作为例证，其中的策略（如“为精确措辞争论”、“将所有事项提交委员会”、“对任何决策的正当性表示担忧”）单独看似乎合理（体现了审慎或专业），但组合起来却能有效瘫痪组织目标的实现。

3. 导致官僚主义的领导错误

领导决策失误主要体现为两种形式：

• 设计不良的激励系统：例如，美国食品药品监督管理局（FDA）因批准有害药物而受罚，但因延迟能救命的研究却不受罚。这种机制导致机构过度规避风险。
• 系统与目标松散耦合：许多制度和流程看似有益或安全，但与组织的核心目标脱节。例如，要求工程团队对每个重大架构决策达成共识，可能会与“高速发布功能以保持竞争力”的目标相冲突。

4. 案例研究：制度审查委员会（IRB）的演变

文章详细剖析了医学研究伦理审查机构（IRB）如何从保护措施演变为官僚枷锁。

• 起源：为防止类似塔斯基吉梅毒实验这样的伦理恶行，IRB于1974年成立，最初是必要的伦理保障。
• 过度演变：在1998年约翰·霍普金斯大学一例患者死亡事件后，审查变得极其严格，导致大量研究停滞、资源浪费。
• 现状：如今IRB监管被视为“紧身衣”，作者Scott Alexander描述了一个简单的病历记录研究如何因繁琐的文书和反复审查（包括关于使用铅笔还是钢笔的争论）而最终被放弃。
• 成本效益失衡：据分析，过度监管为挽救极少数生命，却以牺牲成千上万潜在获救生命为代价，并耗费巨额资金。文章引用总结道：“如果这是一种药物，我不会开它。”
• 演变模式：IRB案例揭示了一个常见循环：发生坏事 → 建立审批流程 → 流程下再次发生坏事 → 流程被收紧 → 最终监管过度。问题根源在于激励错位：IRB没有因促进研究而获得奖励，只因患者受伤害而受到指责，这驱使它倾向于扼杀所有潜在风险。

5. 低效系统的常见例子与改进思路

文章指出，许多源自良好初衷的系统在实践中变得低效，例如：

• 追求共识的系统：耗时巨大，且易受群体决策偏见影响，可能阻碍大胆决策。
• 状态更新会议（如站会）：常沦为微管理和挫折感的来源，并未为参会者创造价值。
• 目的不明的例会：消耗资源却不增加有意义输出。

如何设计有效系统？ 文章提出有效系统应具备四个要素：

1. 清晰的问题陈述：明确系统旨在解决的具体问题。
2. 明确的改进指标：设定可衡量的目标来验证系统效果。
3. 精心的系统设计：设计具体的行动方案。
4. 承诺研究指标：必须定期评估系统是否真正改善了指标，并据此决定保留、调整或废除系统。

核心原则：系统应具有可塑性，需随着环境、组织目标的变化而重新评估和调整。追求的不是“最佳实践”，而是将正确的行动与正确的背景相结合。

6. 结论

建设或管理一个组织需要深刻理解其宗旨，并以高度的自觉性和意图性采取行动。必须不断审视组织的状态、习惯和所建立的系统，使其与核心目标紧密对齐，否则将不知不觉地陷入自我制造的官僚主义迷宫。理由、目的和意图至关重要。

本文挑战了关于医疗保健支出的几种传统观念，提出了基于实证分析的替代解释。核心观点是：医疗保健支出主要由国民收入水平决定，而非价格或利用率等表面因素；美国的高支出源于消费了更多的医疗服务，而非价格异常；健康结果不佳主要源于收益递减和生活方式风险因素。

1. 收入是医疗支出的核心决定因素

• 长期主导关系：在跨国和跨时期分析中，国民的真实平均收入水平是医疗保健支出的最主要决定因素。收入弹性很高（约1.8），即收入增长1%，医疗支出增长约1.8%。
• 优于GDP的指标：使用家庭视角的收入或消费指标（如AIC）比GDP能更好地预测医疗支出。GDP作为代理指标效果较差且概念不同。
• 时间滞后效应：收入变化对支出的影响存在3-4年的滞后，这归因于第三方支付体系、合同谈判和监管等中介环节的复杂性。CMS的预测模型也证实了这种长时滞。

2. 美国高支出源于更多消费，而非更高价格

• 可靠价格指数：基于BEA和CMS等可靠价格指数，美国医疗价格增长并未超过人均收入增长。所谓的“美国价格最高”的论断，通常依据的方法论不严谨或数据来源（如IFHP）并不可靠。
• 更多真实资源投入：美国在医疗保健上投入了更多的真实资源，主要体现在医疗劳动力密度上。自1950年以来，医疗就业份额增长了约六倍。医疗行业是劳动密集型的，工资占运营成本的一半以上。
• 排除其他解释：
  • 工资与利润：美国医疗行业的平均薪酬和利润率并不突出，与其他行业或其他国家相比并无异常。高支出不能归因于医生、高管等群体的高收入。
  • 利用率：常用的门诊、住院天数等利用率指标与支出水平关系微弱。美国的利用率与其高支出水平基本吻合，且在某些先进技术和程序上的采纳率更高。

3. 技术采纳与“强度”是关键机制

• 技术驱动成本：医疗保健支出增长的主要近因是技术变革的采纳。收入提高推动了对更先进、更昂贵诊断和治疗技术（如新手术、药物、设备）的需求和采用。
• “强度”而非“价格”：许多研究将“每次就诊成本”误读为“价格”，实际上其增长主要由强度（即每次就诊中做的检查、治疗更多、更复杂）驱动。随着收入增加，单次医疗接触的干预强度显著提高。
• 衡量指标滞后：传统的国际利用率指标（如特定手术量）往往反映旧技术，在高收入国家可能趋于平稳，无法准确反映通过新技术实现的服务量增长。

4. 美国健康结果不佳的解释

• 收益递减：在高水平上增加医疗支出，对预期寿命等宏观指标的改善效果甚微。高收入国家内部已呈现收益递减规律。
• 生活方式因素：美国相对糟糕的健康结果主要可由生活方式风险因素解释，包括更高的肥胖率、更高的凶杀率和交通事故死亡率，以及近年来的药物过量死亡。这些因素与医疗系统本身关联不大。
• 可预测的模式：美国预期寿命与高收入国家的差距，可以基于其远离健康前沿的距离和支出增长模式来预测，并非系统性异常。

5. 长期可持续性

• 随着生产率提高和收入增长，社会将更大比例的收入用于医疗保健是自然趋势。
• 尽管医疗支出份额上升，但由于其他商品和服务领域的生产率增长更快（其相对价格下降更快），社会对大多数其他商品的实际消费能力仍在持续提高，并不会导致其他领域的消费被“挤占”至匮乏。

总结：传统观点将美国医疗高支出归咎于价格或利用率，本文论证了其根本驱动力是收入增长带来的对更多、更先进医疗服务的需求和资源投入。健康结果差异主要由生活方式等非医疗因素决定。这一分析挑战了“削减价格或利用率即可大幅节省成本”的简单假设。

优化Ion编译器后端

Mozilla的工程师针对Firefox运行微软ONNX Runtime（一个编译为WebAssembly的机器学习库）时内存和CPU消耗过高的问题，对SpiderMonkey的Ion编译器后端进行了一系列关键优化。

问题根源

SpiderMonkey有两个WebAssembly编译器：快速启动的Baseline编译器和生成更快代码但编译时间更长的Ion编译器。问题出在Ion编译一个包含极大函数（其MIR控制流图含132856个基本块）的ONNX模块时，耗时约5分钟并占用超过4GB内存，暴露出编译器后端的性能瓶颈。

核心优化措施

1. 虚拟寄存器活跃范围的数据结构优化

   • 问题：为每个虚拟寄存器存储活跃范围的链表结构，在分配寄存器（需要频繁分割和插入范围）时导致二次方时间复杂度。
   • 解决方案：将有序链表改为可选排序的向量（vector）。初始创建时排序，后续添加新范围时直接追加并标记为未排序。仅在寄存器分配器最终阶段需要时，才进行一次排序。
   • 效果：显著提升缓存局部性，使ONNX模块的Ion编译速度提升约20倍（从5分钟降至14秒）。

2. 支配树构建算法替换

   • 问题：原先基于Cooper等人算法的支配树构建，在处理极大图时效率不佳。
   • 解决方案：替换为Semi-NCA算法（LLVM和Julia编译器也使用的线性时间算法）。
   • 效果：将ComputeImmediateDominators函数耗时从7.1秒降至0.15秒，总编译时间从14秒降至8秒以下。

3. 引入稀疏位集（SparseBitSet）

   • 问题：为每个基本块分配密集的位集来跟踪虚拟寄存器的活跃性，在具有大量虚拟寄存器和基本块的函数中，仅这些位集就消耗超过3GB内存。
   • 解决方案：开发SparseBitSet，使用基于哈希映射的数据结构，配合为小规模数据优化的InlineMap（使用变体/联合类型在小数组和哈希映射间切换以节省内存）。
   • 效果：节省至少3GB内存，并将ONNX模块编译时间进一步缩短至5.4秒。

4. 优化移动解析函数

   • 问题：createMoveGroupsFromLiveRangeTransitions函数内部存在多个二次方时间复杂度的循环。
   • 解决方案：优化关键循环，利用活跃范围已排序的特性，将二次方查找改为线性操作。
   • 效果：使ONNX模块的Ion编译总时间降至3.9秒以下，相比优化前提升超过75倍。

优化成效

这些优化不仅解决了ONNX Runtime的问题，也惠及了其他大型Wasm模块：

• Adobe Photoshop Wasm模块：Ion编译时间从4分钟缩短至14秒。
• JetStream 2基准测试的HashSet模块：受移动解析代码影响，编译时间从2.8秒降至0.2秒。

未来展望

尽管已有巨大改进，但完整编译大型应用（如Photoshop）仍需14秒。为此，团队正在重新架构Wasm编译管线，目标是实现按需、逐函数的Ion编译（在函数变热时才编译），并支持（推测性）内联等新功能，以进一步提升性能和用户体验。

编程时你在脑海中构建什么？

编程主要在我们的头脑中进行，但关于思维过程的讨论却很少。本文探讨了程序员在解决问题时内心的可视化活动。

可视化的本质与差异

• 理查德·费曼指出，即使简单操作（如计数），不同人脑中的思维过程也可能完全不同。
• 这种差异延伸到更复杂的编程概念，导致理解上的障碍：一方认为显而易见的观点，另一方可能难以理解，因为需要转换到不同的思维框架。
• 大多数人在“心眼”中看到图像，这与视觉系统相关，但不同于实际视觉感知。少数人存在“心盲症”，无法在脑海中形成图像。

可视化的重要性

• 形成正确的心理模型是积累编程经验的关键。
• 可视化内容高度依赖具体任务和环境（如独自编程、团队协作、面试设计等）。
• 头脑中的可视化能力有限（作者比喻为约4MB内存），复杂信息需先输出到外部（如纸、白板），再迭代思考。

不同编程任务的可视化方式

作者根据自身经验，列出了常见任务对应的理想可视化工具/图表：

1. 系统设计：经典的白板方框与箭头图，表示组件及其通信关系。
2. 数据库模式设计：标准的实体关系图，显示表属性及外键关系。
3. 优化：
   • 执行优化：使用分布式追踪图或火焰图，快速定位耗时点、瀑布请求或跨服务通信。
   • 空间优化（如内存）：使用树状图，直观显示多层级中占用资源最多的部分。
4. 编写算法：逐步可视化数据结构的状态变化。当超出工作记忆时，需借助笔记或专用代码可视化工具。
5. 编写递归函数：除逐步可视化外，还需追踪调用栈。作者原使用阶梯状图，现转向使用树状表示法，并强调从基本情况开始思考的重要性。

提升可视化能力

• 初学者常专注于语法、工具等细节，难以进行高级可视化。
• 熟练度可通过刻意练习提升：专门花时间反思如何优化内心图像，以使思考更清晰。
• 最佳方法是研究和熟悉针对各类问题的各种图表与工具，让最契合的那个成为大脑中的默认图像。

结语

文章最后列出了几篇相关的扩展阅读文章，并鼓励读者分享自己认为有助于高效思考的工具与图表。