Where a Digital Footprint Check Gets Its Data
Where a Digital Footprint Check Gets Its Data
数字足迹检查的数据来源
A footprint report hands you a score and a list of flagged posts, and the instinct is to start working through the list. Which files the tool opened, and whether any of it left your machine, tends to be an afterthought. That gap matters, because the credibility of every number in the report depends on it.
一份数字足迹报告会为你提供一个评分和一份被标记的帖子列表，人们的直觉通常是直接开始处理列表。至于工具打开了哪些文件，以及是否有任何数据离开了你的设备，往往是事后才考虑的问题。这种认知差距很重要，因为报告中每一个数字的可信度都取决于此。
The files that get opened
被读取的文件
After extraction, the data folder holds around twenty files. A check reads only the ones tied to post content and account history.
解压后，数据文件夹中大约包含二十个文件。检查程序只会读取那些与帖子内容和账户历史相关的文件。
| File | What it holds | Role in the report |
|---|---|---|
| 文件 | 内容 | 在报告中的作用 |
| tweets.js | Every historical post, timestamps, engagement counts | Primary source for the score and the risk list |
| tweets.js | 所有历史帖子、时间戳、互动计数 | 评分和风险列表的主要来源 |
| like.js | Like history | Signals interest patterns and topic exposure |
| like.js | 点赞历史 | 标记兴趣模式和主题暴露情况 |
| direct-messages.js | Direct message history | Detects contact details shared in private threads |
| direct-messages.js | 私信历史 | 检测在私密对话中分享的联系方式 |
| phone-number.js, email-address-change.js | Linked contact details and change history | Supporting evidence for contact exposure |
| phone-number.js, email-address-change.js | 关联的联系方式及更改历史 | 联系方式暴露的辅助证据 |
| ip-audit.js, account-creation-ip.js | Login and account creation records | Timeline verification, region inference |
| ip-audit.js, account-creation-ip.js | 登录和账户创建记录 | 时间线验证、地区推断 |
tweets.js does the heavy lifting. The remaining files act as cross-checks. If one stretch of tweets.js is dense with location mentions, and the IP records show logins from that city in the same window, the location signal is far stronger than post text on its own.
tweets.js 承担了大部分繁重的工作，其余文件则起到交叉验证的作用。如果 tweets.js 中的某一段包含大量位置提及，而 IP 记录显示在同一时间段内有来自该城市的登录记录，那么该位置信号的可信度要远高于仅凭帖子文本的判断。
Which file feeds which block
各个数据块的来源
A report reads as a single verdict. Taken apart, each block has a different origin.
报告看起来像是一个单一的结论，但拆解开来看，每个数据块都有不同的来源。
| Report block | Main source | Method |
|---|---|---|
| 报告板块 | 主要来源 | 方法 |
| 0 to 100 health score | tweets.js | Weighted by item count and share per risk category |
| 0 到 100 的健康评分 | tweets.js | 按项目数量和各风险类别的占比加权 |
| Risk item list | tweets.js | Pattern matching for phone numbers, emails, addresses, locations |
| 风险项目列表 | tweets.js | 针对电话号码、电子邮件、地址、位置的模式匹配 |
| Sensitive topic flags | tweets.js | Dictionary and context rules, with false positives |
| 敏感主题标记 | tweets.js | 词典和上下文规则，包含误报处理 |
| Activity timeline | tweets.js plus IP records | Aggregated by timestamp |
| 活动时间线 | tweets.js 加 IP 记录 | 按时间戳聚合 |
| Contact exposure surface | tweets.js, direct messages, account files | Cross-file comparison |
| 联系方式暴露面 | tweets.js、私信、账户文件 | 跨文件比对 |
Because the blocks draw on separate sources, a problem in one does not contaminate the others. A mislabelled topic flag does not move the contact exposure line.
由于这些板块利用了不同的来源，其中一个板块的问题不会污染其他板块。例如，一个被错误标记的主题不会影响联系方式暴露的统计结果。
What gets skipped on purpose
故意跳过的内容
Unread fields fall into two groups: those unrelated to privacy risk, and those that would distort the analysis.
未读取的字段分为两类：与隐私风险无关的字段，以及会扭曲分析结果的字段。
- Ad engagement records. Nothing to do with what you posted, and they only inflate item counts. 广告互动记录。 与你发布的内容无关，只会虚增项目数量。
- Follower and following lists. Volume swamps signal, and they involve other people’s data. 关注者和被关注者列表。 数据量过大会淹没有效信号，且涉及他人的隐私数据。
- Device tokens and personalization settings. No bearing on whether a post carries risk. 设备令牌和个性化设置。 与帖子是否带有风险无关。
- Language tags stored on posts. Re-detected during parsing, since stored tags drift over time. 帖子存储的语言标签。 在解析过程中重新检测，因为存储的标签会随时间推移而失效。
That filtering has a visible consequence. Report item counts come out lower than people expect, and the mismatch gets misread as missing data.
这种过滤会产生明显的结果：报告中的项目计数往往低于人们的预期，这种差异常被误读为数据丢失。
Where the line between reading and writing sits
读取与写入的界限在哪里
This is the question that deserves the least hedging. Parsing stays local. Extraction, file reads, rule matching and scoring all run on your device. Post text does not cross the network. Results stay local. The score and the list are held in memory and are not submitted anywhere.
这是最不需要含糊其辞的问题。解析过程完全在本地进行。提取、文件读取、规则匹配和评分都在你的设备上运行。帖子文本不会通过网络传输。结果保留在本地。评分和列表仅保存在内存中，不会提交到任何地方。
Only deletion needs authorization. Removing posts calls the platform API, which requires an authorized connection. That step uses delete permission and does not upload archive content. The dividing line is between reading and writing. Once you know where it falls, the architectural questions answer themselves.
只有删除操作需要授权。删除帖子会调用平台 API，这需要经过授权的连接。该步骤仅使用删除权限，不会上传存档内容。读取与写入的界限就在这里。一旦你明确了这一点，架构上的疑问便迎刃而解。
Why the count never matches the platform
为什么计数永远与平台显示不一致
A mismatch is normal, and sorting the causes stops you misreading it.
不一致是正常的，理清原因可以避免误读。
- Time gap. The archive is a snapshot from the day you requested it, so anything posted since is absent. 时间差。 存档是你申请当日的快照，因此之后发布的内容都不会包含在内。
- Deleted content. The archive keeps posts you removed afterwards, which no longer appear on the platform. 已删除内容。 存档保留了你后来删除的帖子，而这些帖子在平台上已不再显示。
- Reposts and quotes. Counting rules differ from the page display, and the gap can run into the hundreds. 转发和引用。 计数规则与页面显示不同，差距可能达到数百条。
- Media-only posts. No text means no text match, but the post still appears on the timeline. 纯媒体帖子。 没有文本意味着没有文本匹配，但帖子仍会出现在时间线上。
With those four in hand, the correct comparison becomes obvious. Match archive entry totals against the post total on the platform, never against the risk list, which has already been filtered once.
掌握了这四点，正确的对比方式就显而易见了。应将存档的总条目数与平台上的帖子总数进行对比，而不是与已经过一次过滤的风险列表进行对比。
Knowing where the data comes from turns the report from a verdict into a chain you can question. Questioning it is the point.
了解数据来源，能让这份报告从一个“最终判决”变成一个你可以质疑的证据链。而质疑，正是其意义所在。