Google Drive PDF打码应用为何只用drive.file权限且不上传文件

一个打码工具的最小权限困境

当开发者决定让用户直接从 Google Drive 中对 PDF 进行打码（redaction）时，第一个设计问题跟打码本身毫无关系。真正的问题是：我们究竟能用多小的权限把这件事做成？

打码工具天然要接触用户最敏感的文件——合同、病历、法律文书。如果换成懒办法，申请完整的 Drive 访问权限当然最省事，但那同时也是最糟糕的选择。Google Workspace Marketplace 上架的 Redact PDF by PDF Redaction 在官方博客中详细拆解了它背后的权限取舍，这套思路对任何要接入云存储的敏感数据处理产品都有参考价值。

权限选择：drive.file 而不是 drive

Google 提供的 Drive 权限是一整个光谱。宽泛的 drive 和 drive.readonly 会暴露用户的每一个文件，同时触发受限权限的验证流程，安全团队看到这种申请大概率会直接拒绝。

drive.file 是逐文件授权的：应用只能访问用户明确打开或通过 Google Picker 主动选择的文件。对于一个「用……打开」（Open with）类型的集成来说，这正是开发者想要的契约——权限确认弹窗上写的内容，管理员一眼就能看懂。

代价也很实在。使用 drive.file 后，应用无法任意创建新文件，也不能浏览文件夹，因此「用……打开」和 Picker 成了仅有的两个入口。作者明确表示接受了这一限制。这其实点出了敏感数据产品的一条基本原则：产品形态应该迁就权限模型，而不是反过来。

Google Drive API 的权限范围（OAuth Scope）本质上是一份"契约声明"，决定了应用在用户账户中能看到和操作哪些资源。drive 和 drive.readonly 属于敏感范围（Sensitive Scope），申请时不仅会弹出"查看、编辑、创建和删除您所有 Google Drive 文件"这类令用户警觉的确认文案，还会触发 Google 的 OAuth 应用验证流程——需要提交隐私政策、演示视频，甚至接受第三方安全评估，整个过程可能耗时数周。对于面向企业 Workspace Marketplace 上架的产品，这几乎是准入门槛。而 drive.file 属于非敏感范围，无需该验证，且授权弹窗只显示"查看、编辑、创建和删除您通过此应用打开的特定 Google Drive 文件"。另一关键点是 drive.file 的授权范围是动态累积的：用户每通过 Picker 或"用……打开"选择一个新文件，该文件才进入应用的可访问集合，此前未被选中的文件始终不可见。这种"白名单式"的逐次扩张，正是它被称为"逐文件授权"的原因。

令牌只留在浏览器内存里

「用……打开」菜单通过 Drive 的 state 参数把文件 ID 传给应用站点。应用解析该 ID、请求用户完成 Google 授权，再用拿到的 access token 抓取这一个文件。

关键在于这个 token 从头到尾都不需要经过后端，于是它确实没经过。令牌只存在于交接页面会话期间的内存中——数据库里没有可泄露的东西，也没有需要定期轮换的凭据。对做安全审计的人来说，这种架构的说明成本极低，因为攻击面本身就几乎没有。

这里涉及的 access token 是 OAuth 2.0 流程中用于调用 Google API 的短期凭据，通常有效期为 1 小时。与之配套的是 refresh token——一种长期凭据，用于在 access token 过期后静默换取新令牌。传统服务端集成往往把 refresh token 存进数据库，因为后台任务需要在用户离线时继续访问 Drive。而这套架构因为完全在浏览器会话内完成所有操作，既不需要后台访问，也就根本不需要 refresh token。这带来两个隐性收益：其一，攻击面从"数据库+网络+凭据轮换机制"压缩到"单个浏览器标签页的生命周期"；其二，安全审计中常见的"令牌存储加密了吗、轮换策略是什么、离职员工残留凭据如何清理"等问题在此架构下直接消失——不是答案更好，而是问题不存在。这正是"架构保证优于政策承诺"的典型体现。

PDF 直接进浏览器，只有文本出网

应用没有把 PDF 通过服务器中转，而是让浏览器直接从 Drive API 下载文件，之后渲染、扫描件 OCR、打码全部在客户端完成。

唯一携带文档派生数据的网络请求是 PII（个人身份信息）检测，而且它传的是抽取出的页面文本，不是文件本身。对更严格的环境，应用还提供本地检测模式，完全不发送任何数据。

这套数据流设计值得单独拿出来说：很多同类工具会把「服务端处理」当成性能优化的默认项，但对打码场景来说，文件不出浏览器本身就是最强的隐私承诺——它不依赖政策声明，而是由架构保证的。

客户端打码的核心技术栈通常由三层组成：用 pdf.js 之类的库在浏览器中渲染 PDF 页面，用 Tesseract.js 对扫描件做 OCR 以提取文字层，再用像素级遮罩或文本层删除完成真正的打码。需要警惕的是"假打码"——仅用黑色矩形覆盖文字，底层文本仍可通过复制粘贴或提取工具复原，这在法律文书场景中可能构成严重泄密。真正的打码必须从内容流中移除对应文字并进行重新编码。就 PII 检测而言，它通常是基于命名实体识别（NER）模型识别姓名、地址、身份证号、银行账号等信息，服务端调用只是把抽取出的纯文本发送给检测 API。由于文本不包含原始排版和图像，泄露敏感版面信息的风险较低，但文本本身仍可能含有 PII，因此本地检测模式对合规要求高的行业（医疗、法律、金融）尤为重要。

刻意没做的两件事

作者列出了两个主动放弃的功能，这部分反而最能说明权限模型带来的约束：

不回写 Drive。 打码后的文件只在本地下载。回写需要更宽的权限，而「用打码版本覆盖原文件」本身就是一个危险操作。

不做文件夹级自动化。 整目录批量打码很诱人，但需要超出 drive.file 的权限。真有这种需求，走 API 或工作流方案比把 Drive 权限拉伸到超出其设计目的更合适。

把「我们做不到什么」写清楚，按作者的说法，是隐私文档里最诚实的一部分。

"回写 Drive"需要 drive 或至少允许创建文件的更宽范围，因为 drive.file 虽然允许创建文件，但在"用……打开"单文件授权场景下，应用对目标文件并没有稳定的写权限保障，且覆盖原文件属于破坏性操作，一旦打码判断有误便无法回退。文件夹级自动化则从权限模型上就与 drive.file 冲突——浏览目录、枚举子文件都需要读取用户并未逐一选择的文件，超出了逐文件授权的语义。作者提到"走 API 或工作流方案"，指的是让企业用 Google Drive API + 服务账号，或借助 Zapier、Make 之类的自动化平台，在组织自有的权限框架内完成批量处理，而把工具本身限定在单文件、人工确认的操作路径上。这种"能力换信任"的取舍，是敏感数据产品常见的战略选择。

给同类开发者的三条经验

1. 从支持你入口的最窄权限开始，然后看什么东西会坏掉，而不是反过来先要权限再砍功能。
2. 让后端经手的数据越少越好，你中转的每一个字节都是你要负责的字节。
3. 把「不能做的事」列成清单，它比功能列表更能建立信任。

这三条经验并不限于 Google Drive 集成。任何处理用户敏感文件的 AI 应用——无论是文档摘要、合同审查还是数据脱敏——都面临同样的权限与数据流向决策。Redact PDF 的案例说明，把权限收窄和数据不出端这两件事做扎实，功能上的让步完全可以接受。

应用的集成方式和权限限制在其集成文档中有更详细的说明。