Orien Daily
- 検証 vs 実証：论文里用错一个字，意思差很远
写研究计划书的时候，脑子里想说"验证假设"，手底下写出来的到底是検証还是実証？这两个词在学术界出现频率极高，但混在一起用的话，导师读起来会觉得概念不清。
検証（けんしょう）侧重点在于"检查、确认是否正确"。已有的理论也好，某个主张也好，你拿数据去对照它、检验它，这个动作叫検証。换句话说，検証的对象是别人已经提出来的东西，你的角色是审核者。论文里常见的「仮説を検証する」就是这么回事——假设不是你定的，你只是拿来验。
実証（じっしょう）则偏向"用事实来证明、使……成立"。它更强调你通过实验或案例，正面地把某个观点支撑起来。实证研究叫「実証研究」，实证分析叫「実証分析」，这些词背后的逻辑是：我要拿出实在的证据，让这个论点站得住脚。
一句话区分：検証是"查它对不对"，実証是"证它站得住"。好比法庭上，検証像交叉质询，実証像呈堂证供。
最常见翻车场景：写「実証的アプローチ」，结果整篇论文都在做统计检验，没有任何实地案例或实验数据支撑——这在日语学术语境下会被认为用词不当，统计检验应该用検証的アプローチ。
那么问题来了：如果你要做一个既有假设检验又有实地数据分析的研究，该用哪个词？ - JWT 的算法协商陷阱：当服务器说"你选算法"
一个常见的 JWT 实现细节，看着无害，实际能直接提权。场景是这样的——很多 JWT 库在验证签名时，会从 token 头部的alg字段读取算法，然后据此选择验证方式。问题在于，攻击者可以把alg从RS256（非对称）改成HS256（对称），然后拿服务器公开的 RSA 公钥当 HMAC 密钥来签名。服务器拿到 token，看到alg: HS256，就用公钥做 HMAC 验证——而攻击者刚刚就是用这把公钥签的名，验证自然通过。整条攻击链只需要一个公开的公钥端点和一个不做算法白名单的服务端。
根因不是 JWT 设计本身，而是验证方把"对方声明的算法"当成了可信输入。修复说起来简单：服务端硬编码只接受哪些算法，不从 token 头取；如果用的是 RS256，就永远只走非对称验证路径，拒绝降级成 HMAC。但现实中老旧代码和默认配置常常忽略这一步，扫描 GitHub 上 populist JWT 库的 issue 列表，算法混乱类的 bug 至今还在冒头。 - eBPF 验证器：内核里的迷你编译器
Linux 内核里藏着一个不太起眼却极其精巧的组件——eBPF 验证器。当你往内核加载一段 BPF 程序时，它并不会直接执行，而是先被这个验证器逐指令扫描。验证器要做的事情本质上就是编译原理里的程序分析：它模拟执行所有可能的路径，追踪每个寄存器和栈槽的类型与范围，确保程序不会越界访问内存、不会无限循环、不会使用未初始化的变量。最有趣的部分是它对循环的处理——eBPF 早期干脆禁止循环，后来才允许有限循环，验证器通过限制总指令数（上限一百万条）和跟踪状态来保证终止。它还会做死代码消除，把不可能到达的分支直接剪掉，这在某种意义上就是在做编译优化。如果你去看kernel/bpf/verifier.c，会发现这个文件有三万多行，占了整个 eBPF 子系统代码量的大头，比虚拟机解释器本身还大得多。换句话说，内核团队把最多的工程精力不是花在"怎么运行 BPF 程序"，而是花在"怎么确保 BPF 程序不会搞崩内核"上。这个取舍很说明问题：在一个特权执行环境中，安全验证的复杂度永远高过执行本身。 - 🌅 Orien Daily 朝刊【5.15】
1️⃣ MIT校长谈学术资金与人才危机
2️⃣ 车主物理拆除RAV4联网模块
3️⃣ SpaceXAI合并后50+人离职
4️⃣ OpenAI Codex登陆手机
5️⃣ 电力公司弃居民转供数据中心
6️⃣ Anthropic进军中小企业，SIer要凉？
7️⃣ Bun的Rust重写已合并
8️⃣ 习近平警告特朗普台海误判风险
频道：@OrienDaily - 🌃 Orien Daily 晚刊【5.14】
1️⃣ Win API进Linux内核 — 游戏性能提升
2️⃣ Needle：26M模型学会调用 — Gemini蒸馏超小模型
3️⃣ Anthropic复盘Claude Code
4️⃣ K8s v1.36发布 — 安全默认+AI负载
5️⃣ AI聊天机器人泄露手机号
6️⃣ Notion变身Agent中枢
7️⃣ 中美首脑北京会谈 — 就台湾问题交锋
8️⃣ 太阳能无人机破纪录后坠毁
频道：@OrienDaily - HTTP/2 协议层面的「极速拒绝服务」——Rapid Reset 攻击
2023 年底，Cloudflare、Amazon、Google 联合披露了一个影响几乎所有 HTTP/2 实现的漏洞：CVE-2023-44487。攻击原理出奇地简单——HTTP/2 支持多路复用，客户端可以在一个 TCP 连接上同时发起大量请求流（stream），每个流有独立的 ID。协议同时允许客户端随时发送 RST_STREAM 帧取消一个流。把这两个特性组合起来：攻击者瞬间发起成千上万个请求流，然后立即对每个流发送 RST_STREAM。服务端收到 RST 后释放资源，但请求处理的开销已经发生——连接速率限制根本拦不住，因为从连接维度看一切"正常"。结果就是极低带宽成本打瘫后端，而攻击者手中可能只握着几十条 TCP 连接。各 CDN 的缓解集中在两个方向：一是对单连接内 RST_STREAM 的频率设限，二是对并发流的创建速率做更激进的约束。有意思的是 HTTP/3（基于 QUIC）天然不受影响，因为 QUIC 的流管理机制截然不同——这大概是少有的"新协议更安全"的真实案例。
