摘要

  • W3C 于 2026 年 9 月 24 日更新 EPUB Annotations 1.0 工作草案：四天前仍为「待补」的安全章节，现讨论外部批注文件、伪造署名及阅读器处理风险；这不是正式推荐标准。
  • 草案承认 EPUB 出版物没有普遍接受的统一识别码。外置批注文件附带的书名等资料只能辅助匹配，creator 字段也不能自行验证写作者。
  • 本文建议把书籍匹配、署名核验、内容安全和重复 ID 的处置分开记录。这是编辑分析，并非 W3C 强制表单。

把旧阅读器里的划线与课堂笔记导入新设备，是正当的可携带性需求。但如果文件标着某位教师的名字，系统又把笔记安放在相似标题的另一版书里，屏幕呈现出的熟悉感会比证据走得更快。这是用于说明控制边界的假设场景，不是已发生的事故。

9 月 20 日的 EPUB Annotations 工作草案在隐私与安全两节都只写着 T.B.D.。9 月 24 日版本仍未完成隐私章节，却新增了五小节安全说明。它指出，从外部取得的独立批注集应视为不可信输入；其中的 Creator 对象可以被冒用。草案还建议让读者能区分本机编写和外部导入、尚未核验的笔记。这里讨论的是设计责任，不是对任何厂商实现的认证。

第一道边界是「这本书」。批注集以 AnnotationSet 打包，about 信息可带书名、出版者、作者和日期。草案明确指出，EPUB 出版物没有一个被普遍接受的标识。因此，阅读器可能需要结合书籍元数据与批注目标是否存在来判断，并在不匹配时提醒使用者，必要时请其亲自选择。字段相似只是线索；它无法把两种版本、两份文件或两次导入变成同一对象的证明。

第二道边界是「谁写的」。草案允许批注标示个人、组织或软件代理；但外置文件的署名没有内在真实性保证。新版安全章节把经认证渠道传输或密码学签名作为可以提高可信度的条件，同时提醒实现者不要把未经核验的署名和本地笔记混为一谈。草案并未给出通用签名格式，也没有指定由谁担保教师、同事或出版者的身份。

第三道边界是「文件可以要求系统做什么」。文本批注中的标记不能被当成 HTML 或脚本解释。外部媒体与链接可能造成自动请求或追踪，恶意路径可能试图越出 EPUB 容器，复杂选择器和过大的 JSON 可能耗尽资源。草案分别讨论这些风险，并不等于已证明存在特定阅读器漏洞。导入一个文件，也不意味着授予它无限制访问网络、文件系统和渲染引擎的权力。

草案还把重复批注 ID 的处理放在书籍匹配之后：确认上下文后，阅读器应更新原有记录或让用户解决冲突，而不是悄悄再造一条。可见，互通的最后一步不是传输成功，而是接收方作出可解释的判断。哪条书籍线索被采纳、署名核验到什么程度、是否替换旧笔记，都应当有清楚边界。9 月 24 日文件仍是可修改的工作草案，隐私章节仍待补；这些未定之处不能被界面上的整齐排列掩盖。

来源