你的会计会把你的工资单上传到不明的 PDF 网站吗？

想想今年都有谁经手过你的工资单。你自己、你的雇主，几乎可以肯定还有一位会计或薪资专员。现在再想想那一刻：当这份 PDF 需要和上个月的合并到一起，或者需要为银行拆成单独的几页时，这件事是在哪里发生的？

对很多专业人士来说，答案是他们在搜索结果第一页找到的一个免费网站。他们把你的工资单拖进去、点一下按钮、下载结果，然后继续干别的。它管用。但这也意味着你的薪资、你的银行账户信息，还有你的身份证号，刚刚跑到了一台你从没听说过的服务器上。

这才是值得聊一聊的地方。

那些经过别人之手的文件

你很少会自己处理那些敏感的 PDF，它们都要经过中间人之手。

薪资部门和会计会看到工资单、合同、税务申报和银行证明。人力资源部门处理身份证扫描件、社保号、病假条，有时还有诊断证明。律师事务所经手的东西从离婚文件到遗产文件无所不包。诊所的行政前台会把转诊单和检验报告合并成一个文件交给保险公司。

这些人当中的每一个，在某个时刻，都需要对一份 PDF 做点枯燥的操作：把四个文件合并成一个；从一份 40 页的扫描件里抽出第 3 到第 7 页；把文件压小一点好塞进邮件。这些活儿都谈不上体面，而这恰恰就是为什么它们会被丢到手边最快的工具上去做，而不是最安全的那个工具。

“一小时后删除”并不是一种保证

大多数在线 PDF 工具会把你的文件上传到它们的服务器，在那里完成操作，再把结果发回给你。那条写着”你的文件将在 1 小时后删除”的小提示，也许完全是真心实意的。问题是你没法核实它，使用它的那位会计也没法。

一旦一份工资单落在了别人的服务器上，哪怕只是短短一瞬，有几件事就已经脱离了所有人的掌控。日志和备份可能会把副本保留到承诺的时限之外。服务器本身可能被攻破。这个工具可能跑在它并不拥有的基础设施上，让你的文件经过一些没人提及的存储桶和处理队列。一份从未离开过笔记本电脑的文档，不会在别处发生的数据泄露中外泄。

对于一张度假照片，谁会在意呢。但对于一份印着你薪资和身份证号的文件，这账就得换个算法了。

GDPR 实际上对他们提出了什么要求

这部分是专业人士有时会略过的。当一位会计或人力资源部门处理你的数据时，GDPR 并不把它当作他们可以随意支配的私人物品。他们是在代表他人处理个人数据，而这是带着责任的。

他们应当采取适当的技术措施来保障这些数据的安全（第 32 条）。他们应当清楚自己把数据分享给了谁，而一个接收上传文件的不明 PDF 网站，就是这条链路里的第三方。如果他们把你的数据交给了一个处理者，按规定双方之间应当有一份约束此事的合同。而万一那个网站发生数据泄露，为此买单的，是那些工资单被曝光的人——以压力为代价，甚至以更糟的代价。

为了省下三十秒，就把一位客户的报税表上传到一个不明的免费工具，很难跟上面这些要求对得上号。大多数这么做的专业人士，只是从来没想过文件去了哪里。那个工具感觉就像一个计算器，而不是一次数据传输。

解决办法：让文件留在设备上

有一类 PDF 工具的工作方式不一样。它不会把你的文件发到服务器，而是在浏览器内部完成整个操作。代码只下载到设备上一次，你的 PDF 在浏览器自己的内存里被打开和修改，处理完的文件直接保存回同一台机器。这份文档哪儿也没去。

reader.me 就是这样工作的，这也正是它适合敏感文档的原因。当一个薪资部门用我们的合并 PDF 工具把一摞工资单拼到一起时，这些文件是在他们自己的电脑上、在他们的浏览器里被处理的。没有任何东西被上传到我们这里，因为根本就没有一个可供上传的服务器环节。关掉标签页，工作内存就消失了。

这一点你也不必盲目相信。打开浏览器的 DevTools，切到 Network 标签，跑一次合并，然后看着：没有任何一个请求把你的文件带出去。如果文件没有出现在任何请求体里，那它就没有被发到任何地方。

实际该怎么做

如果你是那位专业人士，请改掉一个习惯。在你把客户的工资单或合同放进一个网页工具之前，先问问：它是在浏览器里处理，还是在服务器上处理？如果你分辨不出来，就跑一次 DevTools 测试弄清楚。挑一个客户端处理的工具，把它设成你的默认选择。反正它本来就更快，因为没有上传下载的来回往返，而且办公室 Wi-Fi 断了它照样能用。

如果你是那位客户，你完全有权发问。下次你的财税代理或人力资源在处理你的文件时，问问他们是怎么处理你的 PDF 的，那些文件会不会离开他们的电脑。一个好的回答是”所有东西都留在我们机器上”。一耸肩，那就是个值得追问下去的信号。那些页面上印着的是你的薪资和你的身份证，问一句它们去了哪里，是一件完全合情合理的事。

这活儿本身平淡无奇。合并几个文件不过几秒钟。唯一的问题是：那几秒钟是发生在你自己的设备上，还是发生在一个陌生人的服务器上——而对于一份工资单来说，这个问题值得搞对。