Tweet Deletion Tools Compared on Privacy: On-Device or Uploaded
Tweet Deletion Tools Compared on Privacy: On-Device or Uploaded
推文删除工具的隐私对比：本地处理与云端上传
Two tools can both remove 2,000 old tweets and look identical in the result. The difference sits in the process: where your content goes, who can read it, and how long it stays. 两款工具都可以删除 2,000 条旧推文，且最终结果看起来完全一样。但它们的区别在于处理过程：你的内容去了哪里、谁能读取它，以及它会保留多久。
Comparing deletion tools as one category does not work. What you are actually comparing is their data architecture, and architecture sets the ceiling on privacy risk. A cleaner interface on top of a riskier architecture does not change the risk. 将所有删除工具归为同一类进行比较是行不通的。你实际上是在比较它们的数据架构，而架构决定了隐私风险的上限。在风险较高的架构之上提供一个更简洁的界面，并不能改变其风险本质。
Three places where the difference lives
差异存在的三个维度
- Where analysis happens. Parsing the archive inside your own browser, or uploading it to someone else’s server and parsing it there. 分析发生的位置。 是在你的浏览器内解析归档文件，还是将其上传到他人的服务器进行解析。
- What access is granted. Reading an archive file that never leaves your machine, or handing over read and write access so the tool can post, edit your profile and read direct messages on your behalf. 授予的访问权限。 是读取从未离开你电脑的归档文件，还是交出读写权限，让工具能够代表你发布内容、编辑个人资料并读取私信。
- How long data is kept. Plaintext dropped once processing ends, or retained across logs, caches and backups for a period set by someone else. 数据保留时长。 是在处理结束后立即删除明文，还是将其保留在日志、缓存和备份中，且保留期限由他人设定。
Data flow in three architectures
三种架构中的数据流向
| Architecture | Where the archive goes | Access needed | Exposure |
|---|---|---|---|
| 架构 | 归档去向 | 所需权限 | 暴露风险 |
| On-device analysis | Stays in browser memory, never uploaded | None, no account grant | Analysis only, deletion has to happen separately |
| 本地分析 | 保留在浏览器内存中，从不上传 | 无，无需授权账号 | 仅限分析，删除需另行操作 |
| Cloud bulk deletion | Archive or credentials sent to a server | Read and write account access | Plaintext may reach logs and backups, and you wait on their execution |
| 云端批量删除 | 归档或凭据发送至服务器 | 账号读写权限 | 明文可能进入日志和备份，且需等待其执行 |
| Direct via platform API | No archive involved, calls hit X directly | Read and write account access | Full scope, activity log sits on the platform side |
| 通过平台 API 直接操作 | 不涉及归档，直接调用 X 接口 | 账号读写权限 | 全范围权限，活动日志留存在平台端 |
No architecture wins outright. On-device analysis pushes privacy risk to the floor and cannot delete anything. Cloud tools are fast and require trusting someone’s handling of your plaintext. The right choice depends on what is inside your archive, and on whether you would be comfortable seeing that content in a support ticket. 没有哪种架构是绝对完美的。本地分析将隐私风险降至最低，但无法直接执行删除。云端工具速度快，但需要你信任对方对明文的处理方式。正确的选择取决于你的归档文件中包含什么，以及你是否能接受这些内容出现在客服工单中。
What permission scope actually means
权限范围的真正含义
Read and write access sounds abstract. In practice it means the holder can act as your account. Visible actions include posting, deleting, changing your avatar and bio, reading direct messages, and inspecting who you follow. 读写权限听起来很抽象。实际上，这意味着持有者可以以你的名义操作账号。可见的操作包括发布、删除、更改头像和简介、读取私信以及查看你的关注列表。
Some tools request only what deletion needs. Others ask for the full set at once. The broader the grant, the wider the blast radius if that company has an incident, and the more you have to unwind later. 有些工具只请求删除所需的权限，而另一些则一次性索要全部权限。授权范围越广，一旦该公司发生安全事故，你的受损范围就越大，后续需要处理的烂摊子也越多。
One habit covers most of this: create the grant for the cleanup only, then revoke it in your account’s connected apps list the moment the job finishes. Do not leave it sitting there because you might do another pass next spring. 养成一个习惯可以解决大部分问题：仅在清理时授予权限，任务完成后立即在账号的“已连接应用”列表中撤销授权。不要让它一直挂在那里，因为你可能明年春天才会再次清理。
How to read a retention promise
如何解读保留承诺
Most privacy policies say they do not sell your data, which answers a question you were not asking. Ask these instead, and look for answers you could quote: 大多数隐私政策都声称不会出售你的数据，但这回答的并不是你真正关心的问题。请改为询问以下问题，并寻找你可以引用的答案：
- Is the uploaded archive stored as plaintext or encrypted, and who holds the key? 上传的归档文件是以明文还是加密形式存储的？谁持有密钥？
- How long after processing is the plaintext removed, and are backups and log copies purged on the same schedule? 处理后多久会删除明文？备份和日志副本是否遵循相同的删除周期？
- What channel handles deletion requests, and must you file one yourself? 通过什么渠道处理删除请求？是否必须由你亲自提交申请？
- Are there subprocessors, and is that list public? 是否有子处理商？该列表是否公开？
A policy willing to answer those four usually also publishes its access scopes. A policy that answers none of them and instead repeats its commitment to privacy has promised you nothing measurable. 愿意回答这四个问题的政策通常也会公开其访问权限范围。如果一份政策对这些问题避而不谈，只是反复强调其对隐私的承诺，那么它并没有给你任何可衡量的保障。
A checklist you can reuse
可复用的检查清单
| Item | Pass condition |
|---|---|
| 项目 | 通过条件 |
| Analysis location | The vendor states clearly whether data leaves your device |
| 分析位置 | 供应商明确说明数据是否会离开你的设备 |
| Permission scope | Deletion needs only, no posting or DM access attached |
| 权限范围 | 仅限删除所需，不包含发布或私信访问权限 |
| Retention period | A specific number of days, not a phrase like “reasonable period” |
| 保留期限 | 明确的天数，而非“合理期限”之类的模糊表述 |
| Revocation | One click to disconnect after the job, no support ticket |
| 撤销权限 | 任务完成后一键断开，无需提交工单 |
| Scope control | Keep list and range selection supported, so you can target one window |
| 范围控制 | 支持保留列表和范围选择，以便精准定位特定时间段 |
Scope control gets overlooked more than the rest. A tool that only offers “delete everything before year X” leaves you unable to keep portfolio links while clearing contact details out of the same period. If your archive has anything worth keeping, that limitation turns a one-hour job into a manual one. 范围控制比其他项目更容易被忽视。如果一个工具只提供“删除 X 年之前的所有内容”，那么当你想要清理该时间段内的联系方式，却又想保留作品集链接时，就会束手无策。如果你的归档中有值得保留的内容，这种限制会将一小时的工作变成繁琐的手动操作。
Where the risk actually concentrates
风险真正集中的地方
If you are deciding between two tools and cannot read their architecture, fall back on content. The question is not how many tweets you are deleting. It is what kind of content sits in the archive. 如果你在两款工具之间难以抉择且无法读懂其架构，那就回归到内容本身。问题不在于你删除了多少条推文，而在于归档文件中包含什么类型的内容。
An archive full of public commentary is low stakes. An archive containing DM exports, onboarding photos from past employers, delivery confirmations and screenshots of calendar invites is a different object entirely. That second archive is the one where uploading to a third-party server deserves real scrutiny, even if the interface is nicer and the price is lower. 全是公开评论的归档风险较低。但如果归档中包含私信导出、前雇主的入职照片、快递确认单和日历邀请截图，那性质就完全不同了。对于后者，即使第三方服务器的界面更美观、价格更低，上传时也必须进行严格审查。
Using this comparison
如何使用此对比
Turn the privacy comparison into one concrete step. Start with a method that costs nothing and uploads nothing, then decide separately whether speed is worth a grant. The check at digital-footprint-health.shop runs entirely on your machine and deletes nothing, so it tells you what is in the archive before you decide who gets access to it. When you reach the deletion stage, compare candidates on the checklist above rather than on pricing alone. 将隐私对比转化为一个具体的步骤。先从免费且无需上传的方法开始，然后再单独决定速度是否值得你授予权限。digital-footprint-health.shop 上的检查工具完全在你的机器上运行且不执行任何删除，因此它能在你决定授权给谁之前，先告诉你归档里有什么。当你进入删除阶段时，请根据上述检查清单对比候选工具，而不是仅仅看价格。