“不收集数据”背后，白宫 App 把流量发给了谁？一次抓包揭开的隐私反差
一次普通点开，背后却像开了“数据集市”
白宫 App 听上去像一件很“官方”的东西。很多人会自然地认为，既然它代表的是美国最高行政机构，至少在数据处理上应该比普通商业 App 更克制、更透明一些。结果这次抓包分析给人的感觉，恰恰相反：前台是新闻、直播和社交内容，后台却像一个塞满第三方 SDK、嵌入组件和广告基础设施的拼装车。
根据 Atomic Computer 公布的动态分析，他们通过 mitmproxy 给一台 iPhone 做 HTTPS 中间人解密，在不修改任何流量的前提下，完整浏览了白宫 App 的 Home、News、Live、Social 和 Explore 五个标签页。结果很直白：一次会话里，应用总共请求了 31 个不同主机，发起 206 次请求，其中只有 48 次，也就是 23%，真正发往 whitehouse.gov。剩下 77% 的流量，去了 OneSignal、Elfsight、YouTube、Google DoubleClick、Facebook CDN、Twitter/X 图片服务器等第三方。
这个比例本身就很有戏剧性。你打开的是“白宫”App，但大部分数据并没有在“白宫”自己的地盘里打转，而是在一串商业基础设施之间穿梭。它当然未必等于“恶意”，因为当代移动应用高度依赖外部服务早已是行业常态：推送通知找 OneSignal，嵌入社交内容找 Elfsight，视频靠 YouTube，字体和脚本跑在 Google CDN 上。但问题在于，当一个政府机构的官方应用也沿用这套商业互联网默认配置时，风险和责任就不再只是产品经理的 KPI 问题，而是公共信任的问题。
最敏感的，不是它连了多少域名，而是它说了谎
这篇分析里最刺眼的部分，不是“请求很多”，而是“声明很少”。按照报告，白宫 App 的隐私清单中写的是：NSPrivacyCollectedDataTypes: []，也就是“未收集数据”；同时 NSPrivacyTracking: false，即“不跟踪”。可抓包看到的现实是，应用启动时会把语言、时区、国家、IP 地址、首次打开时间、最近活跃时间、设备型号、操作系统版本、网络类型、运营商、是否越狱、会话时长、打开次数，以及一个持久唯一标识符发给 OneSignal。
说得更直白一点，这不是“只传一点技术日志”那么轻描淡写。把这些字段拼起来，已经足够形成一张有连续性的用户画像：你在哪个地区、什么时候用过、换过哪些网络、用的什么型号 iPhone、是不是常用用户、每次大概看多久。尤其是 OneSignal 这类推送和营销平台，最核心的能力之一，就是把“通知送达”与“用户活跃”连接起来。报告甚至提到，应用会先向 OneSignal 发 GET 请求读取已有档案，再通过多次 PATCH 更新新的 IP 和会话信息。这意味着，系统不是一次性记账，而是在持续维护一份“这个设备是谁、最近在哪、活跃了多久”的长期记录。
这就把问题推到了一个很尴尬的位置：如果一款购物 App、短视频 App 这么干，公众可能会皱眉，但不会意外；可一款白宫官方 App 也这么干，而且在隐私标签里写“无数据收集”，那就不是“技术实现粗糙”四个字能带过去的了。苹果的隐私营养标签制度，本来就是为了让用户在下载前快速了解应用会碰什么数据。今天最大的危险，不只是收集行为本身，而是声明与现实之间出现断裂。一个制度如果可以被轻松写成“空白卷”，那它的约束力就得打问号。
社交组件很方便，但也把控制权交了出去
如果说 OneSignal 暴露的是“谁在被记录”，那么 Elfsight 暴露的则是“谁在决定页面里跑什么代码”。Atomic Computer 在此前的静态分析中，就怀疑这款 App 采用了 Elfsight 的双阶段加载器；这次动态抓包则把它坐实了。打开 Social 标签页后，应用会联络多个由 Elfsight 控制的域名，请求 /p/boot/ 之类的接口，再由服务端返回具体应该注入哪些 JavaScript 资源，比如 TikTok、Instagram、Facebook、YouTube 对应的脚本。
这个机制的技术逻辑并不复杂：App 里先放一个平台级入口脚本，真正运行哪些组件、加载哪些资源，由服务器动态下发。对内容运营团队来说，这非常省事，不用频繁发版就能调整社交展示模块；对安全团队来说，这却是一种典型的“远程代码行为扩张”。因为用户终端上最终跑什么，不再完全由上架审核时那个二进制决定，而是由后端配置和第三方平台一起决定。
更微妙的是，报告提到 Elfsight 相关基础设施在一次会话中设置了 10 个以上的 Cookie，其中还包括 Cloudflare 的一些追踪/风控 Cookie。与此同时，YouTube 嵌入还拉起了 DoubleClick，也就是 Google 的广告投放与追踪基础设施。你可以说这些东西未必都用于“广告变现”，因为白宫 App 又不是要靠流量卖货；但从技术轨迹上看，官方应用的内容页里，确实跑进了商业广告生态的老熟人。这种违和感很强——就像你去政府大厅办事，窗口边上突然摆着一套商场会员积分机。
为什么这件事比一款普通 App 更重要
很多人会问：现在谁的 App 不接第三方服务？这话没错。现代 App 开发早就不是“纯手工独立建站”的时代了。推送、统计、视频、评论、社媒聚合、CDN、云安全，几乎每一项功能都有现成外包组件。问题不是“有没有第三方”，而是“有没有边界感”。
政府应用和商业应用最大的区别，在于前者承载的是公共权威。用户下载白宫 App，不只是为了看新闻，更是出于对“官方渠道”的信任。在这种前提下，开发团队理应遵守更严格的数据最小化原则：能不采就不采，能本地处理就别上云，能自建就少外包，能解释清楚就别写成一张漂亮但空洞的隐私标签。因为用户对政府 App 的预期，从来不是“和普通媒体客户端差不多”，而是“比普通媒体客户端更谨慎”。
这件事放到当下的政治和技术环境里看，也格外敏感。过去几年，美国政府在 TikTok、数据跨境、关键基础设施安全、未成年人隐私保护等议题上频频高调发声，要求平台承担更多责任。与此同时，苹果和谷歌也不断强化隐私披露与权限治理。现在如果连白宫自己的官方应用都被发现存在“声明与实际行为不符”的问题，那就难免被外界反问：对科技公司的高标准，能不能先在自己的产品上兑现？
类似争议其实并非孤例。过去不少新闻媒体 App、地方政府服务 App、甚至医疗类应用，都曾被研究人员发现嵌入 Facebook SDK、Firebase、广告监测脚本，导致用户行为在不透明的情况下被送往第三方。区别只在于，这次主角是白宫，所以放大效应格外明显。它提醒我们一个常被忽略的现实：很多所谓“官方应用”，本质上也是由外包团队、通用 CMS、第三方营销工具和嵌入式网页拼出来的工业制品。看起来庄严，里面可能仍是熟悉的商业互联网配方。
真正值得追问的，不只是技术细节，而是治理态度
我看完这份分析后的第一反应，不是惊讶于“居然会有第三方请求”，而是惊讶于“怎么敢写成未收集数据”。因为技术问题通常都能修：去掉不必要的 SDK，把社交内容改成静态嵌入，视频换成隐私增强模式，自建推送或至少重新配置采集字段，这些都不是做不到。真正难修的是组织层面的惰性——没人认真核对隐私标签，没人质疑第三方默认配置，没人站出来说一句“这是政府应用，标准应该更高”。
当然，站在另一边也能提出辩护：推送服务需要设备标识和会话信息，社交聚合工具必须访问多个域名，YouTube 嵌入天然会牵出 Google 的一串基础设施。技术上这些都解释得通。但解释得通，不等于披露得通。今天用户最反感的，往往不是“你收了什么”，而是“你明明收了，却告诉我什么都没收”。
接下来真正值得观察的，是白宫团队会不会回应这份报告：他们是会更新隐私标签、删减第三方组件，还是把问题归为研究者“过度解读”？如果是前者，这件事会变成一次有价值的公共纠偏；如果是后者，它就会继续成为一个反面样本，提醒所有人：隐私治理最怕的，从来不是黑客，而是把复杂外包给第三方后，假装一切都没有发生。
从更广的行业角度说，这也给所有开发者提了个醒。今天的移动应用就像乐高，拼起来很快，但每多接一块第三方积木，就多一份数据流出与合规失真的风险。尤其当你的产品背后站着的是政府、医院、学校、银行这类高信任机构时，“能跑起来”只是及格线，“能解释清楚”才是真正的分水岭。