研究揭示Android应用在原生与Web边界泄露设备标识符

总体来看，这些行对应了 852 次请求。另有 7 次请求分散在 Index Exchange、Aarki、DoubleClick 以及另一个 Smartborad 端点。这些公司中的大多数，在我查看这些流量记录之前从未真正接触过，更不用说在知情的情况下同意共享我设备的广告标识符了。

exciteads.com 这个案例尤其值得深入挖掘。许多发往 streamkey.excitead.com 的请求来自 Amazon Publisher Services 代码加载的广告，而该代码本身又是由 Unity ironSource Exchange 代码加载的。具体来说，在 ironSource Exchange 将控制权移交给 Amazon 之后，一个 Amazon URL 将以下内容加载到了 WebView 中：

<script type="module" src="https://cdn.excitead.com/play/e_player/w.js?a=00130"> </script>

随后，该脚本发起了大致如下的 fetch 调用： fetch( "https://streamkey.excitead.com/ad2?" + "app_name=Wordscapes" + "&bundle=com.peoplefun.wordcross" + "&ifa=<GAID>" + "&lat=<LATITUDE>" + "&lon=<LONGITUDE>" + "&country=US" + "&schain=<SUPPLY_CHAIN>" + "&instanceid=<EXCITEAD_INSTANCE_ID>", method: "GET", mode: "cors", headers: { /* ... */ } );

另一条链路：MX Player 到 InMobi 到 Branch 和 AppsFlyer

MX Player（com.mxtech.videoplayer.ad，版本 3.2.5）是一款现归 Amazon 所有的应用，在视频流媒体和文件传输方面相当受欢迎（下载量超过 10 亿次，甚至在 Play Store 上获得过 Editor's Choice 奖）。我总共花了 12 分钟点击浏览该应用的 UI，最终发现了一些非常清晰的 WebView 内跨方数据共享案例。

VisibleV8 将一条来自 https://ac.onedsp.inmobi.com/cache?id=<CREATIVE_ID> 的广告归因于该请求。该域名随后加载了一个脚本，该脚本创建了一个 image 对象，并为其分配了一个 Branch impression.link URL，其中以 $aaid 携带测试 GAID。观察到的操作等价于： const branchPixel = new Image(); branchPixel.src = "https://impression.link/impression" + "?branch_key=<BRANCH_KEY>" + "&$3p=a_inmobi_dsp" + "&$household_measurement=false" + "&$aaid=<GAID>" + "&user_agent=Mozilla/5.0+(Linux;+Android+14;" + "Pixel+4a+(5G)+Build/<BUILDID>;+wv)..." + "&~ad_set_id=<AD_SET_ID>" + "&~campaign=<CAMPAIGN_NAME>" + "&..."; 同一个 InMobi 主机还提供了另外两个创意脚本。每个脚本都向 AppsFlyer 发起了一个 image 请求。其中一个是 Mistplay 应用的曝光： const appsFlyerPixel = new Image(); appsFlyerPixel.src = "https://impression.appsflyer.com/com.mistplay.mistplay" + "?pid=inmobidsp_int" + "&c=Mistplay_InMobi_Android_US_tROAS_iap_spend_all_v2" + "&af_siteid=com.mxtech.videoplayer.ad" + "&af_c_id=<CAMPAIGN_ID>" + "&af_adset=<AD_SET_NAME>" + "&af_ad=<CREATIVE_NAME>" + "&click_id=<INMOBI_CLICK_ID>" + "&advertising_id=<GAID>" + "&af_lang=en" + "&af_ua=Mozilla/5.0+(Linux;+Android+14;" + "Pixel+4a+(5G)+Build/<BUILD_ID>;+wv)..."; 另一个 AppsFlyer 请求针对的是被广告的应用，并携带了相同类别的字段。创建 Image 是一种常见的跟踪像素技术：不需要显示任何可见图像，但为其 src 属性赋值会使 Chromium 发出 GET 请求。在这三个案例中，GAID 都与 MX Player 包名或发布商投放位置、广告系列和创意标识符，以及包含设备型号和 Android Build ID 的详细 user agent 一同出现。这是以一种非常透明形式呈现的跨方广告数据流。执行脚本是从 InMobi 主机获取的，接收方是 Branch 和 AppsFlyer，而被广告的应用又属于另外的公司。

有趣的是，在撰写本文时，MX Player 的 Google Play 数据安全部分声称不与第三方共享任何数据。然而，在我对 3.2.5 版本的测试中，我观察到从 InMobi 基础设施加载的 JavaScript 构造了发往 Branch 和 AppsFlyer 的请求，其中包含设备的广告 ID。

Google 的数据安全文档明确要求开发者将透过第三方 SDK 和应用控制的 WebView 进行的数据传输纳入考量，但某些例外情况除外。这些特定传输是否符合例外条件，仅凭流量记录我无法确定，但这种差异引发了疑问：应用商店的隐私披露在多大程度上准确反映了嵌入式广告基础设施的行为。

Royal Smash（com.cyphergames.royalsmash）是一款下载量超过 1000 万次的游戏，在 Google Play Store 热门游戏榜上排名第 7，它也表现出了一些有趣的数据传输行为。我玩了大约一个小时（不幸的是，大部分时间都卡在广告小游戏上）。当我查看日志时，我看到其中包含六个发往 view.adjust.com 的 Image.src 事件，以及两个发往 track.tenjin.io 的携带 GAID 的事件。

Adjust 事件来自一个空脚本，形式如下： setTimeout(function () { const img = new Image(); img.src = "https://view.adjust.com/impression/..." + "&idfa=<GAID>" + "&gps_adid=<GAID>" + "&ip_address=<PUBLIC_IP>" + "&campaign_id=..." + "&applovin_click_id=..." + "&applovin_event_id=..." + "&android_id_lower_sha1=<ANDROID_ID_SHA1>" + "&os_version=14.0.0"; }, 500); 尽管参数名为 idfa，其值却是 Android 测试设备的 GAID；相同的值在 gps_adid 下重复出现。该请求还携带了公共 IP、广告系列和 AppLovin 事件标识符，以及一个标记为小写 Android ID 的 SHA-1 值。然而，IDFA 参数的存在让我怀疑这种跟踪行为是否也存在于 iOS 上。不幸的是，iOS 是一个封闭的花园，对 WebView 内部几乎不可见，这使得这种级别的监测基本上是天方夜谭。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）