视频：COMP1531 Week 3 Lecture 1（2026-09-29，约 1:50） 来源：本地 ASR 转写 + 视频截帧整理，非官方材料，细节以视频和 spec 为准。时间均为视频时间，点链接直接跳转。

本讲两位讲师：前半节 Rani Jiang 讲 Iteration 1，并用 clearData 演示一个 feature 的完整流程；后半节讲 Dynamic Verification 和 Code Coverage。

• 0:24:59–0:30:51 是现场 debug，可以跳过。
• 0:53:30–1:04:20 是课间休息。

Demo 0 · 前端 sample 演示（0:04:20–0:05:35）

• 演示 tutor 写的终端界面（TUI）闪卡 app：新建卡片（Q: best CSE course / A: COMP1531），建 deck，再往 deck 里加卡。
• 讲师说这只是 sample，不是 reference solution，他们实现时也做了自己的假设。

Demo A · 用 clearData 走完一个 feature 的完整流程（0:14:42–0:50:28）

• 0:14:44：合并 GitLab 上的 "[Iteration 1] Updated Starter Code" MR（不用 approve，有冲突就照常解决）
• 0:15:52：在 Issue board 新建 work item clearData，打标签 core、critical、in progress，链接 spec，设 due date
• 0:17:45：git checkout -b iter1-clearData
• 0:18:26：在 interface.js 写 stub：clearData() 返回 {}。data 对象是 {cards: [], decks: [], studySessions: []}；clearData 把三个数组都重置成 []，然后 commit
• 0:23:00：新建 src/clearData.test.js。测试按三类想：返回值、副作用、错误（clearData 没有错误情况）。第一个测试是 test('return value', () => expect(clearData()).toStrictEqual({}))
• 0:24:59–0:30:51：现场 debug，可以跳过：报 vitest not found，接着是 ERR_MODULE_NOT_FOUND。最后的解法：rm -rf node_modules、删掉 package-lock.json、npm cache clean --force、npm install
• 0:32:31 / 0:33:26：先讲 automarking 也会看 coverage，然后跑 npm run coverage。屏幕上 interface.js 是 Stmts 62.5%、Funcs 50%，未覆盖第 16–27 行
• 0:34:07：为什么要测副作用：把清空的代码注释掉，返回值测试照样能过。副作用测试的思路是 cardsCreate → clearData → cardsView 应该查不到；deck 同理
• 0:35:17：循环依赖：cardsView、decksList 队友还没写完怎么办？三种办法：先注释掉并在 MR 里写明、用 test.todo(...)、用 test.skip(...)
• 0:40:27：git commit -m "feat: add initial tests for clear"
• 0:41:29：重构拆文件：新建 clearData.js（放 doClearData），interface.js 里只写 return doClearData()；data 挪到 dataStore.js 里 export。重跑测试全部通过，有测试才敢放心重构。commit 是 "feat: refactor clear to be in separate file"
• 0:44:00：git push --set-upstream origin iter1-clearData，建 MR，标题带 issue 号（"43 - clearData feature"），assign 自己并加 reviewer。要不要删源分支问 tutor。之后队友 review、留评论、approve、merge，最后把 issue 拖到 closed
• 0:46:36：提交前检查：在 CSE 上跑 1531 iter1-dryrun，加 --show-tests 能看到测试内容。现场 dryrun 报错了，讲师说之后会修
• 0:49:21：跑课程前端做 sanity check：报 decksList failed: Not implemented，现场补一个 stub 后又报下一个没实现的函数
• 0:50:28：Q&A：要不要一个函数一个文件？组里自己取舍，有理由就行

要点

• 一个 feature 的完整流程：issue → branch → 实现 + 测试 → commit → push → MR → review → merge → 关 issue。
• 只测返回值不够，要测副作用。
• 依赖的函数还没写完时，用 test.todo / test.skip 先占位。
• interface.js 只负责转发，实现放在独立文件里，这样文件更整洁，也能减少 merge conflict。

Demo B · 动态验证 + Code Coverage（1:30:29–1:49:47）

代码在 GitLab 的 lecture 仓库 3.1-Dynamic-Verification，文件夹是 2.4-dynamic-verification。

• 1:32:02：回顾 removeVowels.test.js 的 import/export；clone 下来没有 node_modules，先 npm install
• 1:34:23：跑测试，代码里故意留的错误让测试失败，改好后通过
• 1:35:20：package.json 的 scripts："test": "vitest run"、"coverage": "vitest run --coverage"。对比 npm test（跑全部）和只跑单个文件
• 1:36:24：grade.js 的 computeGrade(mark)：≥85 HD、≥75 DN、≥65 CR、≥50 PS，其余 FL
• 1:37:24：删掉 DN 的测试，测试仍然全部通过，说明全绿不等于测全了
• 1:39:04：加 --coverage：grade.js 是 Stmts 77.77%、Branch 75%、Funcs 100%，未覆盖第 7、13 行
• 1:41:12：打开 coverage/index.html 网页报告，没覆盖的行会高亮
• 1:42:11：补回 DN 测试后变成 88.88%、Branch 87.5%，只剩第 13 行（FL 分支）
• 1:43:06：讨论：要盯着没覆盖的部分，而不是追百分比；branches 比 functions 更重要；一个函数一个文件对 coverage 没帮助
• 1:46:40：一句话定义：dynamic verification 就是测输出是否符合预期
• 1:48:15：加 test('returns FL for below 50')，computeGrade(45) 应返回 'FL'（AI 补全的），到 1:49:40 达到 100%
• 1:49:07：100% 覆盖仍然不够：负分和超过 100 的分数也会被接受，边界情况没测到

要点

• 看 coverage 报告时，先看 Uncovered Line #s 和 HTML 报告里高亮的行，不要只盯着百分比。
• Branch coverage 比 function coverage 更能说明问题。
• 覆盖率 100% 不代表测试足够，边界情况（edge cases）要另外考虑。

来源：checkoff/02、checkoff/03 页（https://cgi.cse.unsw.edu.au/~cs1521/26T3/checkoff/02/questions 、/03/questions，Synced 2026-09-20 / 09-26）

check-off 流程：tutor 在 lab 里走到你旁边，给你一段程序，陪你逐行过一遍，然后问几个问题； 过了会给你一个 access code，在 check-off 页面输入。其余 lab 题照常做。 你现在状态（student.md）：Week 01 = True 5/5，Week 02 = False，Week 03 = False → 今天 16:00 lab 两个都要做。 程序是 tutor 当场给的，没法提前背答案——要练的是「看一行 MIPS 能说出它干嘛」。

1. 看到一行就要能说出来（Week 02 核心）

syscall（先把编号放 $v0，参数放 $a0）

寄存器：$t0–$t9 临时；$s0–$s7 函数调用后还要保住的；$a0–$a3 传参；$v0 返回值/syscall 号； $ra 返回地址；$sp 栈顶；$zero 永远是 0。

2. if / while 怎么变成 MIPS（tutor 最爱问）

口诀：条件取反，跳过去。

// C:  while (i < 10) { ...; i++; }
loop:
    bge  $t0, 10, end     # i >= 10 就跳出（把 < 取反成 >=）
    ...
    addi $t0, $t0, 1
    b    loop             # 回到开头再判
end:

// C:  if (x > 5) { A } else { B }
    ble  $t0, 5, else     # x <= 5 就去 else（> 取反成 <=）
    A
    b    endif            # 做完 A 必须跳过 B，否则会接着做 B
else:
    B
endif:

可能被问：「为什么是 bge 不是 blt？」→ 分支是"满足就跳走"，跳走的地方是循环外面，所以要写循环结束的条件（i < 10 的反面 i >= 10）。 「if 后面那个 b endif 删了会怎样？」→ A 做完会掉进 B，两个都执行。

3. 数组 / 内存（Week 03 核心）

    .data
nums:   .word 3, 1, 4, 1, 5      # 5 个 int，已初始化
buf:    .space 40                # 40 字节 = 10 个 int，**未初始化（不保证是 0）**
msg:    .asciiz "hi\n"           # 字符串，自动加 '\0'

第 i 个元素的地址 = 数组首地址 + i × 4（int 占 4 字节）

    la   $t1, nums        # t1 = &nums[0]
    mul  $t2, $t0, 4      # t2 = i * 4        （也可以 sll $t2, $t0, 2）
    add  $t2, $t2, $t1    # t2 = &nums[i]
    lw   $t3, 0($t2)      # t3 = nums[i]       （写回用 sw）

必背问答：

• 为什么乘 4？ int 4 字节，地址按字节算。char 数组就乘 1，用 lb/sb。
• la 和 lw 区别？ la 拿地址（门牌号），lw 去那个地址把东西拿出来（屋里的东西）。
• 忘了乘 4 会怎样？ 读到错位的地址；lw 地址不是 4 的倍数会直接报 unaligned 错误。
• numbers[i-1]？ 地址再减 4，或写 lw $t3, -4($t2)（括号前的数字是字节偏移）。
• 2D 数组 a[r][c]（每行 N 列）：地址 = 首地址 + (r × N + c) × 4。
• struct：每个字段在首地址上加固定偏移，lw $t0, 4($t1) = 取偏移 4 的那个字段。

4. 函数（Week 3 Lecture 2）

• 调用：参数放 $a0..$a3，jal f；返回值在 $v0。
• jal 会把"回来的地址"写进 $ra。函数里如果还要再 jal 别的，必须先把 $ra 存到栈上，不然 $ra 被覆盖、jr $ra 回不去（死循环或乱跳）。
• 典型开头/结尾：

f:
    addi $sp, $sp, -4     # 栈上开 4 字节
    sw   $ra, 0($sp)      # 存 $ra
    ...
    lw   $ra, 0($sp)      # 取回
    addi $sp, $sp, 4
    jr   $ra

• 用了 $s 寄存器也要这样先存后恢复；$t 寄存器调用后不保证还在。

5. 被问到时的回答套路

1. 先说这个寄存器代表 C 里哪个变量（"$t0 是 i，$t1 是数组首地址"）。
2. 再说这一段对应 C 哪一行（"这 4 行就是 x = numbers[i]"）。
3. 让你预测输出：拿第一个、第二个值手算一遍循环，别跳着猜。
4. 真不会：说"我觉得这里是在算 &numbers[i]，因为它乘了 4 再加首地址"——讲出推理比答对还重要。

6. 顺便复习你自己交过的 lab02（tutor 可能拿它问）

grade（if/else 链）、count（while 计数）、seveneleven（循环 + 取余判断）、sequence（循环 + 步长）。 开 lab 前把你自己的 .s 打开，每题能口述"哪个寄存器是哪个变量、哪行是循环条件"就够了。 lab03（printbigger / swap_numbers / unordered）截止 2026-10-06 12:00，还没开始。

RakkoTasks 读你的收件箱，挑出真正需要你处理的事，写成一句中文待办。你的邮件要交给它读，所以这一页讲清楚三件事：它怎么运行，数据去了哪里，它怎么保护你。

• 不需要你的邮箱密码：Outlook 走微软官方授权，Gmail 用可随时撤销的应用专用密码
• 只读收件箱：不会替你发信，也不会删信
• 无统计、无广告：页面里没有任何追踪或第三方脚本
• 源代码公开：每一行都能在 GitHub 上看到

它怎么运行

你连接自己的邮箱。 在设置页添加邮箱，全程不需要输入你的邮箱登录密码。Outlook 类邮箱通过微软官方页面授权，RakkoTasks 拿到的是一份授权凭证，不是你的密码；Gmail 使用 Google 的「应用专用密码」，它和你的 Google 登录密码是两回事，随时可以在 Google 账户里单独撤销。

每 15 分钟看一次收件箱。 后台程序通过加密连接读取收件箱里的新邮件，你也可以在待办页手动刷新。它只读取邮件，不会替你发信，也不会删信。

AI 判断哪些是你要做的事。 广告、营销和标题党邮件会被过滤掉。真正需要你处理的事，AI 会写成一句中文待办，并标出截止时间和分类（学业、工作、个人、账单、其他）。

在手机或电脑上处理。 打开网页就能查看、勾选和编辑待办，也可以把它安装到主屏幕。待办还能同步到 iPhone 的「提醒事项」，或用订阅链接显示在日历里。

直接问你的邮件。 用一句话问「下周有哪些截止」，AI 会在你自己的邮件里查找，回答时附上它引用的原邮件。

数据去了哪里

RakkoTasks 用到的外部服务就是下表这几家，没有别的。

DeepSeek 如何处理收到的内容，以 DeepSeek 自己的隐私政策为准。

它怎么保护你

这些措施都写在代码里。

• 不需要你的邮箱密码。 连接 Outlook 走微软官方授权，连接 Gmail 用应用专用密码，你的邮箱登录密码从头到尾都不会交给 RakkoTasks。不想用了，去微软或 Google 账户里撤销授权，RakkoTasks 就立刻读不到你的邮箱。
• 每个人一个独立空间。 邮箱、邮件和待办全部按账户隔离。想访问别人的数据，系统会当作它根本不存在，连「有没有」都不会透露。
• 凭证只进不出。 应用专用密码和授权凭证保存后，永远不会再返回浏览器。网页只能知道「已连接」或「未连接」。
• 原邮件在隔离框里打开。 邮件的网页内容会先清洗掉脚本和危险代码，再放进一个禁止运行脚本的隔离框里显示。
• 默认挡住远程图片。 很多营销邮件用隐藏图片记录你是否打开了邮件。RakkoTasks 默认不加载远程图片，需要看时你自己点一下再显示。
• AI 不会被邮件牵着走。 有人会在邮件里写指令，想诱骗 AI 做事。邮件内容交给 AI 时会明确标成「待阅读的资料」，不是指令；AI 只能查你自己的邮件，不能上网，也不能执行任何操作。
• AI 的回答也会过滤。 AI 写出的内容在服务器和网页上各过滤一遍：图片一律移除，链接只保留普通网址，不会在你没点任何东西时悄悄发出请求。
• 日志里没有你的邮件。 运行日志只记录数量和编号，比如「本轮处理 12 封」，不写邮件标题、正文或任何凭证。
• 随时停用或删除。 停用邮箱会立刻清除它的凭证，已经生成的待办保留，以后可以重新启用。彻底删除会把这个邮箱的邮件和由它生成的待办一起删掉。
• 日历链接可以随时换。 日历订阅链接可以一键更换，旧链接立刻失效。同步「提醒事项」用的是单独生成的专用密码，服务器只保存它不可还原的指纹。
• 全程加密连接。 网页访问走 HTTPS。连接邮箱服务器时会严格校验对方证书，冒充的服务器连不上。

源代码

RakkoTasks 的全部代码公开在 GitHub。上面每一条保护措施，都能在代码里找到对应的实现。

仓库地址：https://github.com/KurisuRakko/RakkoTasks

后端用 Python 写，负责收邮件、调用 AI、存储数据；前端是一个可以安装到主屏幕的网页。

也可以用 Docker 在自己的机器上部署一份，数据就完全留在你手里。登录部分需要接入一个兼容的登录服务，仓库里的部署说明写了步骤。

内容按 2026 年 9 月的代码撰写。如果这页和代码有出入，以代码为准。

写于 2026 年 9 月。本文面向没有技术背景的读者，文末附有给技术读者的细节，可以跳过。

注册 Priestess 的时候，常有人问：「管理员能看到我的密码吗？」

答案是：不能。 不是 Rakko 承诺「不去看」，而是 Priestess 从一开始就没有把你的密码存下来。这篇文章想讲清楚四件事：

1. Priestess 到底存了什么；
2. 为什么这样存了之后，连 Rakko 也没法知道你的密码；
3. 谷歌、学习通这些平台是怎么做的，又出过什么事；
4. 欧盟是怎样用法律要求网站这样做的。

一、保险箱和榨汁机：两种「保管」方式

想象你把一样重要的东西交给别人保管，大致有两种办法。

第一种是保险箱。 东西锁进去，需要的时候用钥匙打开，原样取出来。这叫「加密」。它的问题是：谁有钥匙，谁就能看到原件。 如果网站把你的密码锁进保险箱，那么掌握钥匙的管理员，或者偷到钥匙的小偷，都能把密码拿出来。

第二种是榨汁机。 把一个苹果放进去，出来一杯苹果汁。果汁没法再变回苹果；但同一个苹果每次都会榨出同样的果汁。这在技术上叫「哈希」。

Priestess 对你的密码用的是榨汁机。

为什么可以这样做？因为 Priestess 根本不需要知道你的密码是什么，只需要判断你这次输入的对不对。注册时，它把你的密码「榨」成果汁存起来；以后每次登录，它把你这次输入的密码再榨一遍，两杯果汁一样，就说明密码是对的。整个过程不需要保留苹果本身。

有些东西确实只能放保险箱

榨汁机不是万能的。有些信息系统必须拿到原件才能工作，这时只能锁进保险箱：

规律很简单：只需要核对的，就榨掉；非用原件不可的，才上锁。 你的登录密码属于第一种。

二、你的密码在 Priestess 里经历了什么

光用一台普通榨汁机还不够安全。小偷如果偷走了整仓库的果汁，可以自己拿常见的苹果一个个去榨，看哪杯对得上。所以 Priestess 给这台榨汁机加了三道保险。

第一道：一味锁在别处的秘方

在榨汁之前，Priestess 会先给你的密码加上一味秘方。这味秘方不放在存果汁的仓库（数据库）里，而是单独锁在服务器的另一个保险柜中。

好处是：就算有人把整个数据库偷走，手里没有秘方，他连「拿苹果去试」都无从下手，因为他根本不知道该怎么复现同样的榨法。

加秘方这一步还有个附带的好处：不管你的密码有多长，都会先变成固定的长度，后面的榨汁机就不会漏掉其中任何一个字。

第二道：每个人独一无二的调料

每个账号在榨汁时还会额外加一撮随机调料，每个人都不一样。

于是，就算你和另一个人碰巧用了同一个密码，存下来的果汁也完全不同。小偷没法提前做一张「常见密码对照表」一次查出成千上万个账号，只能一个账号一个账号地慢慢试。

第三道：一台故意很慢的榨汁机

Priestess 用的是一台故意设计得很慢的榨汁机。

在一台普通电脑上实测，它榨一次大约要 0.07 秒。你登录时根本察觉不到这点等待。可对小偷来说就完全不同了：普通的快速算法，一台电脑一秒能算几十万次甚至更多；换成这台慢机器，一秒只能算十几次。想把几十亿个可能的密码挨个试一遍，时间会被拉长几万倍。

最后：贴一张写明「第几代」的标签

每一杯果汁上都贴着标签，写明是用哪一代榨汁机榨的。将来有了更好的机器，你下次登录、密码核对成功的那一刻，系统会自动用新机器重新榨一杯，把旧的换掉，你不需要做任何事。这个机制现在就在工作：早期没有加「秘方」的旧记录，会在用户下次登录时自动换成新做法。

顺带一提：连「这个账号存不存在」也不泄露

如果有人输入一个根本不存在的用户名，Priestess 仍然会假装认真榨一遍汁再回答「登录失败」。这样，别人就没法通过「回答快慢」来判断某个用户名是否注册过。

三、为什么 Rakko 看不到你的密码

把上面的内容串起来，「看不到」体现在四个地方：

1. 仓库里没有。 数据库里只有果汁，没有苹果。Rakko 打开数据库，看到的是一串毫无意义的字符，和小偷看到的一样。
2. 管理面板上没有。 管理员查看用户信息时，只能看到「已设置密码：是 / 否」。
3. 日志里没有。 系统在运行时会记录一些日志，比如「某时某刻有人登录失败」，但从不记录你输入的密码内容。
4. 能换锁，不能看钥匙。 如果你忘了密码，可以通过邮件自助重置；Rakko 也可以直接给账号设一个新密码。管理员这样做之前要再输一次自己的管理员密码，而且会留下操作记录。无论哪种方式，都是用新密码覆盖旧密码，旧密码不会被任何人看到。

说句实在话

「看不到」有一个边界，我们不想夸大。

你登录时，密码需要通过加密的网络连接交给服务器核对。就像你把钥匙递给门卫验一下，门卫接过去的那一瞬间是拿得到的。Priestess 的规矩是：验完立刻忘掉，不抄在本子上、不拍照、不告诉任何人。这份保证来自程序的写法和运营的纪律，而不是物理上不可能。

真正连这一瞬间都省掉的办法，是 Passkey（通行密钥）：用手机或电脑的指纹、面容解锁来登录，密码压根不需要发给服务器，服务器那边只保存一份「只能用来验证、不能用来冒充你」的信息。这也是 Priestess 推荐的主要登录方式，密码更多是作为备用。

你自己能做的

• 不要在多个网站用同一个密码。 Priestess 保管得再好，如果你在另一个网站用了同一个密码，而那个网站泄露了，坏人就可能拿它来试你的其它账号。
• 密码长一点比花哨更重要。 Priestess 要求至少 12 个字符，不强制你加大小写或符号。一句只有你知道的长句子，往往比短而复杂的密码更好记，也更安全。
• 用密码管理器，开启两步验证或 Passkey。

四、别人家是怎么做的

大公司通常不会把「用哪台榨汁机、放几味调料」全部公开，法律也没有要求它们公开。下面看两个例子：一个是做得不错、但也犯过错的谷歌；一个是强调密码没有泄露、却被卷进大规模个人信息泄露风波的学习通。

谷歌：没公开配方，但公开过自己的失误

谷歌没有公开账号密码具体用的是哪一种算法。它在 2019 年的一篇官方博客里讲过总原则：密码先经过单向的「榨汁」处理，然后把榨出来的结果连同用户名一起再锁进保险箱（加密），才写进硬盘。等于榨汁机和保险箱两道都用上了。

有意思的是，这篇博客本身是一份认错声明。谷歌发现，面向企业客户的 G Suite（现在叫 Google Workspace）从 2005 年起有一个漏洞：管理员在后台替员工设置或找回密码时，系统会多存一份没榨过的原始密码。2019 年 1 月又出了一次类似问题，一小部分新注册企业客户的密码被原样存放了最多 14 天。谷歌表示，这些数据一直放在自家加密的内部系统里，没有发现被滥用，普通个人账号也不受影响；它通知了受影响企业的管理员，并要求他们重置密码。

连谷歌都会在「管理员代设密码」这种不起眼的角落出错。所以 Priestess 在这条路径上同样只保存榨过的果汁：管理员替你设新密码时，系统拿到密码就立刻榨掉，不留原件。

谷歌还有一个给其它开发者用的登录服务 Firebase，这一边的做法倒是公开的：它用的是一种改良版的 scrypt 慢速算法。scrypt 不光费时间，还特别费内存，小偷很难靠专门定制的硬件批量加速。每个项目都有自己独立的一套参数和密钥；从别处搬进来的旧密码记录，会在用户第一次成功登录时自动换成新做法，和前面讲的 Priestess「贴标签、自动换代」是同一个思路。

谷歌也有必须用保险箱的场景：谷歌密码管理器。它替你记住的是你在其它网站的密码，将来要原样填回去，所以不能榨，只能加密保存。默认情况下，这个保险箱的钥匙由你的谷歌账号保管；如果你手动开启「设备端加密」，钥匙就只存在你自己的设备上，连谷歌也打不开。

此外，从 2023 年 10 月起，谷歌把 Passkey 设成了个人账号的默认登录选项，希望大家尽量不再用密码。

另一种教训：2022 年的学习通

2022 年 6 月，有人在网上兜售号称来自「超星学习通」的 1.7 亿多条学生信息，包括姓名、手机号、学校、学号等，话题一度冲上微博热搜第一。

学习通很快回应：已经报警；技术排查了十几个小时，还没有发现明确的泄露证据。它同时强调自己不保存明文密码，采用的是「单向加密」，也就是本文说的榨汁机，连公司内部员工都拿不到密码原文，网传「密码泄露」不属实。

但媒体随后发现，有社工库机器人（黑产用来倒卖、查询个人信息的工具）已经能查到与本人学习通资料一致的学号、姓名、手机号，不少网友也说自己接到了骚扰或诈骗电话，怀疑与此有关。在我们能查到的公开资料里，还没有看到这件事的最终调查结论。

这个案子的教训有两层：

• 榨汁机只保护密码。 就算密码榨得好好的，姓名、手机号、学校这些信息一旦流出，照样能被拿去骗人。一个网站要保护的，远不止密码。这也是后面要讲的欧盟法律管的是「所有个人数据」，而不只是密码的原因。
• 榨汁机也分好坏。 当时有专家提醒：「单向加密」如果用的方法不够强，只要有足够的时间和算力，照样可以被解开。所以光说「我们加密了」还不够，还要看用的是哪台榨汁机、有没有秘方和调料。

放在一起看

做得好的公司，思路其实非常一致：只存果汁，用慢机器，秘方分开放，并且努力让大家不用密码。 但就算做到了这些，还有两件事要时刻记着：一是谷歌那样藏在角落里的疏忽，二是学习通风波提醒我们的：密码之外的个人信息同样要守住。

五、欧盟是怎样定这些规矩的

在欧洲，网站该怎样保护用户数据，主要由一部法律决定：《通用数据保护条例》（GDPR）。它常被当作全球个人信息保护的标杆。

欧盟的法律是怎么「写」出来的

欧盟立法有点像一份合同的诞生：

• 起草人是欧盟委员会，只有它可以正式提出法律草案。
• 签字人有两位：一位是欧洲议会，由欧洲选民直接选出的议员组成；另一位是欧盟理事会，由各成员国政府的部长组成。两边都同意，法律才能通过。
• 两边意见不一时，三方会坐下来反复协商，逐条讨价还价，直到拿出一份双方都能接受的文本。

欧盟的法律分几种。其中「条例」一旦通过，所有成员国直接照办，不需要各国再自己改写成本国法律。GDPR 就是一部条例。它取代的是 1995 年的一份旧「指令」：指令只规定目标，由各国自行立法落实，结果各国宽严不一。

GDPR 从提出到落地花了六年多：

• 2012 年 1 月，欧盟委员会提出草案；
• 之后经过四年多谈判，2016 年 4 月正式通过；
• 法律给企业留了两年准备期，2018 年 5 月 25 日起正式实施。

它并没有规定「用哪台榨汁机」

你可能以为，这样一部法律会写明「密码必须用某某方法保存」。其实没有。GDPR 的写法是：

企业要考虑当下的技术水平、实施成本和数据面临的风险，采取与风险相称的技术和管理措施，例如加密，并且要能持续保证数据的保密性。（第 32 条大意）

此外，它还要求个人数据必须以确保安全的方式处理（第 5 条），并要求企业从设计之初、默认状态下就只处理必要的数据（第 25 条）。

为什么不直接写死方法？因为一部法律要用很多年，而技术几年就会变。二十年前被认为足够安全的算法，今天已经可以被轻易破解。如果法律写死某种方法，它很快就会过时，甚至会保护那些照着旧标准做、实际已经不安全的企业。

所以 GDPR 选择只规定「要做到什么程度」，不规定「具体用什么工具」。这就好比交通法规不规定你必须开哪个牌子的车，只要求刹车必须合格；而且「合格」的标准会随着时代自动提高。

胡萝卜和大棒

胡萝卜：如果企业发生了数据泄露，原则上要尽快报告监管机构，情况严重时还要逐一通知受影响的用户。但法律也规定：如果泄露出去的数据被处理得让外人看不懂，比如经过了加密，就可以不必逐一通知用户（第 34 条）。也就是说，平时防护做得好，出事时的麻烦就小得多。

大棒：没做好安全措施，最高可以罚 1000 万欧元，或者全球年营业额的 2%，按两者中较高的算；违反更基本的数据处理原则，上限翻倍，达到 2000 万欧元或 4%（第 83 条）。

谁来说明「怎样才算做好」

既然法律只写原则，就需要有人把原则翻译成具体做法。这份工作由各国的数据保护机构和它们共同组成的欧洲数据保护委员会（EDPB）承担。它们会发布指南，举大量例子。

其中一个例子几乎就是在讲本文的主题：

一个菜谱网站被黑客入侵，1200 个用户的密码被偷走。但这些密码都用当下可靠的方法「榨」过，还各自加了随机调料，而调料没有一起泄露。EDPB 认为，这种情况对用户权益没有风险，网站甚至不必向监管机构报告，只需要内部登记；不过仍然建议网站提醒用户换密码。

EDPB 还在同一处指出：更理想的做法是采用根本不需要服务器处理密码的登录方式，也就是前面说的 Passkey 这一类。

两张真实的罚单

德国，Knuddels（2018 年）。 这是一个德国聊天网站，把用户密码原样存放，没有做任何「榨汁」处理。2018 年它被黑客入侵，约 33 万组账号和密码被公开到网上。当地数据保护机构认定它违反了 GDPR 关于安全措施的规定，开出 2 万欧元罚单，这也是 GDPR 实施后德国的第一张罚单。金额不算高，是因为该公司事后非常配合，也很快完成了整改。

爱尔兰，Meta（2024 年）。 Meta（Facebook 的母公司）在 2019 年主动向爱尔兰数据保护机构报告：公司发现，部分用户的密码以明文形式存放在内部系统里。这些密码并没有泄露给外人，但监管机构依然认定它没有采取适当的安全措施、没有按规定报告和记录，于 2024 年 9 月处以 9100 万欧元罚款并给予训诫。

两个案子放在一起看，道理很清楚：把密码原样存着，这件事本身就是违规，不需要等到真的被偷。

这些规矩和 Priestess 有什么关系

先说清楚：GDPR 约束的是在欧盟境内经营、或者面向欧盟境内的人提供服务的机构，就算机构本身不在欧盟也一样。Priestess 是一个个人运营的服务，并不以欧盟用户为对象，严格来说是否适用要看具体情况，本文也不构成法律意见。我们把 GDPR 当作一把标尺，用来检验自己做得够不够好。中国的《个人信息保护法》第五十一条同样要求处理个人信息时采取加密、去标识化等安全技术措施，方向是一致的。

拿这把标尺量一量：

结语

保护密码最好的办法，是从一开始就不保存它。

Priestess 不保存你的密码，只保存一杯变不回苹果的果汁；Rakko 看不到你的密码，不是因为自觉不去看，而是没有东西可看。欧盟的法律没有告诉大家该用哪台榨汁机，但它把道理讲得很明白：你替别人保管的东西，要用这个时代最靠谱的办法去保管。

附：给懂技术的朋友

看不懂这一节完全没关系，跳过即可。

• 密码哈希：先用服务端密钥（pepper）对密码做 HMAC-SHA-256，结果 base64url 编码后再做 bcrypt（cost 10，16 字节随机盐，盐来自 CSPRNG），最后加上版本前缀 v2.bcrypt-pepper. 存入数据库。pepper 以 Worker secret 注入，不进入数据库和代码仓库。这与 OWASP Password Storage Cheat Sheet 推荐的 bcrypt 加 pepper 的预哈希做法一致。
• HMAC 预处理的副作用：bcrypt 只取输入的前 72 字节，而 HMAC 输出编码后固定为 43 个字符，所以 Priestess 允许的最长 4096 字符的密码，每一个字符都会参与计算；同时 pepper 让「password shucking」式的攻击无法进行。
• 参数升级：没有版本前缀的旧式纯 bcrypt 记录，在登录校验成功后会自动重算为 v2 格式，并写入审计日志。
• 防用户名枚举：用户名不存在时也会对一个固定的假哈希执行一次 bcrypt 比对，让两种情况的响应耗时接近。
• 高熵凭证只做 SHA-256：会话 token、密码重置 token、OIDC client secret 都是系统随机生成的高熵字符串，不怕字典攻击，存 SHA-256 摘要即可；慢哈希是专门针对人类挑选的低熵密码的。
• 必须可逆的秘密：TOTP 密钥、短信服务商凭证等使用 AES-GCM 加密保存，密钥与数据库分离。
• 坦白说：OWASP 目前把 Argon2id 列为首选，并把 bcrypt 归为遗留系统的选项；cost 10 是它给出的 bcrypt 最低推荐值。版本前缀机制就是为将来平滑迁移准备的。

参考资料

• 《通用数据保护条例》（Regulation (EU) 2016/679）原文，EUR-Lex
• 欧洲数据保护监督员（EDPS）：GDPR 的立法历程
• EDPB：Guidelines 01/2021 on Examples regarding Personal Data Breach Notification（案例 06）
• 爱尔兰数据保护委员会：对 Meta 处以 9100 万欧元罚款（2024-09-27）
• IAPP：德国 GDPR 首张罚单（Knuddels）
• GDPRhub：LfDI Baden-Württemberg – O 1018/115
• OWASP Password Storage Cheat Sheet
• Google Cloud 博客：Notifying administrators about unhashed password storage（2019-05-22）
• Firebase：Firebase Authentication 使用的改良版 scrypt
• Google 博客：Passkeys are now enabled by default for Google users（2023-10）
• Gizmodo：谷歌密码管理器的设备端加密
• 澎湃新闻：超星学习通回应「用户数据泄露」传闻，已向公安机关报案（2022-06）
• 南都·隐私护卫队（转载于安全内参）：学习通回应 1.7 亿数据疑泄露，专家称密码加密仍有安全风险（2022-06-21）

此渲染由 Yohaku API 生成，或存排版之虞，最佳体验请往：https://rakko.cn/posts/mathematics/line-segment-not-vector-subspace-math1231

Take x = v = 1v. Since 0 <= 1 <= 10, we have x in S.

However, 11x = 11v. This is not in S, since the coefficient 11 does not satisfy 0 <= 11 <= 10.

Therefore S is not closed under scalar multiplication. Hence S is not a vector subspace of R^3.

览毕，何不一言？

此渲染由 Yohaku API 生成，或存排版之虞，最佳体验请往：https://rakko.cn/posts/mathematics/sets-that-are-not-vector-spaces-math1231

Take v = (...) in S, since ...

However, kv = (...), and substituting this into the defining condition gives ...
Thus kv is not in S.

Hence S is not closed under scalar multiplication, so S is not a vector space.

Take u = (...) and v = (...) in S, since ...

However, u + v = (...), and substituting this into the defining condition gives ...
Thus u + v is not in S.

Hence S is not closed under vector addition, so S is not a vector space.

The zero vector is not in S, since substituting 0 into the defining condition gives ...

Therefore S is not a vector space.

览毕，何不一言？

这是最新文档

Intermediate Value Theorem (介值定理 - IVT)

秒杀关键词： continuous (连续), opposite signs (一正一负), root (根), exists c such that f(c) = 0 (存在c使得函数值等于某数)。

大白话： 从A点走到B点，如果一个在水面上，一个在水面下，那你肯定得穿过水面。你刚才做对的那道平面题就是这个。

Mean Value Theorem (中值定理 - MVT)

秒杀关键词： derivative (导数), $f'(c)$, rate of change (变化率), tangent parallel to secant (切线平行于割线)。

大白话： 你开车从悉尼去堪培拉，平均时速是 $100$。那路上肯定有那么一瞬间，你的仪表盘速度刚好指在 $100$ 上。只要题目扯到导数和平均变化的关系，闭眼选它。

Maximum-Minimum Theorem (极值定理 / 最值定理)

秒杀关键词： closed interval (闭区间 $[a,b]$), maximum / minimum (最大值/最小值), bounded (有界的)。

大白话： 一段连绵不断的山脉，只要圈定一个明确的起点和终点，里面绝对能找出一个最高峰和一个最低谷。

Second Fundamental Theorem of Calculus (微积分基本定理第二部分)

秒杀关键词： 题目里同时出现了积分号 $\int$ 和 求导符号 $\frac{d}{dx}$。

大白话： 积分的上限是个变量 $x$，然后让你对整个积分式子求导。这就是微积分的核心——求导和积分是逆运算。

Inverse Function Theorem (反函数定理)

秒杀关键词： $f^{-1}$, one-to-one (一一映射), inverse (反函数)。

大白话： 专门用来算反函数的导数的。原函数某点的斜率如果是 $2$，反函数对应点的斜率就是 $\frac{1}{2}$。

Fundamental Theorem of Algebra (代数基本定理)

秒杀关键词： polynomial (多项式), complex roots (复数根)。

大白话： $n$ 次多项式必定有 $n$ 个复数根。这在你们这门微积分课里多半是个凑数的干扰项。

Split Function Theorem (分段函数定理)

秒杀关键词： piecewise function (分段函数)，检查连接点 (break point)。

大白话： 就是左极限等于右极限，左导数等于右导数那套东西。

此渲染由 Yohaku API 生成，或存排版之虞，最佳体验请往：https://rakko.cn/posts/productivity/truth-table-speedrun

览毕，何不一言？