Differences

This shows you the differences between two versions of the page.

--- design:mobile_and_app_measurement [2026/08/27 07:09] – New page: Measuring Mobile Apps — app acquisition, static vs dynamic analysis, UI exploration, and the certificate-pinning problem; 529-paper corpus figures with denominators. Authored by Claude karel.kubicek.claude
+++ design:mobile_and_app_measurement [2026/08/27 07:40] (current) – Generic review: add 'What to Read First'; scope the pinning walkthrough as Android and give the iOS route; add on-device VPN capture, per-app traffic attribution and QUIC; name the reusable datasets; replace an un-intersected inference with the computed 6 karel.kubicek.claude
@@ Line 13: / Line 13: @@
 Everything on this page about "the literature" is a claim about **seven venues** — CCS, IMC, NDSS, PETS, USENIX Security, TheWebConf and IEEE S&P, 2010–2026, 5,859 papers with extracted full text. Mobile-app work is also published at mobile-systems and software-engineering venues (MobiSys, MobiCom, MSR, ICSE, ASE) and at usable-security venues (SOUPS), none of which are in the corpus, so treat the counts as "how these seven security and privacy venues do mobile", not as the state of mobile research.((The absent-venue list is a judgement about where this literature publishes, not a measurement — the corpus cannot see venues it does not contain. Two of the outside-corpus papers cited on this page are from MSR and one from ESEC/FSE, which is the shape of the gap.)) See [[Literature:Corpus]].
+===== What to Read First =====
+Five papers will orient you faster than anything else on this page, and each is here for a methodological reason rather than a topical one.
+  - {[pradeep2022_comparative]} — **the certificate-pinning measurement.** The only paper we found that separates //potential// from //actual// pinning and reports what fraction of pinned destinations its bypass toolchain failed on. Read the methodology, not just the results.
+  - {[bonett2018_discovering]} — **why your static analysis is wrong.** Injects executable leaks into real apps and measures what three well-known detectors miss. Read it before you write "we used FlowDroid". {[pauck2018_promises]} is the independent second opinion.
+  - {[koch2023_enough]} — **the attrition model.** 4,779 apps downloaded, 3,654 analysed, every app-level percentage over the second number. Copy this reporting discipline exactly.
+  - {[kollnig2022_iphones]} — **how to compare two platforms without cheating.** Random samples per platform, cross-platform app identity defined explicitly, code analysis and traffic analysis reported separately.
+  - {[kumar2022_investigation]} — **why your storefront matters.** Geodifferences in mobile apps, measured.
+Two systematic reviews give the taxonomy of approaches, both from outside these seven venues and both old enough to predate Frida's adoption and every LLM-based method: {[kong2019_testing]} on automated Android testing and {[li2017_static]} on static analysis. Read them for the map, not the tool list.
 ===== Which Population Is Yours =====
@@ Line 28: / Line 40: @@
 Two more signals overlap it heavily but not completely: 364 papers name a tool the extraction classified as ''mobile-instrumentation'' (32 of them outside both slices above), and 502 papers draw a population whose unit is ''mobile-apps'' (24 outside both). If you are searching the literature yourself, none of these three queries alone finds everything.
-Where the work is published, as a share of each venue's own output: PETS 12.9% (66 of 510), NDSS 11.7% (82 of 701), CCS 10.7% (106 of 990), USENIX Security 10.1% (143 of 1,410), IEEE S&P 8.2% (63 of 767), IMC 5.0% (32 of 638), TheWebConf 4.4% (37 of 843). **PETS and NDSS are where a mobile privacy measurement most often lands**; IMC and TheWebConf, the two most web-flavoured venues here, publish the least of it.
+Where the work is published, as a share of each venue's own output: PETS 12.9% (66 of 510), NDSS 11.7% (82 of 701), CCS 10.7% (106 of 990), USENIX Security 10.1% (143 of 1,410), IEEE S&P 8.2% (63 of 767), IMC 5.0% (32 of 638), TheWebConf 4.4% (37 of 843). As a //share of venue output// PETS and NDSS lead, but only narrowly and over a two-point spread; **by volume USENIX Security (143 papers) and CCS (106) publish the most of it**. IMC and TheWebConf, the two most web-flavoured venues here, publish the least either way. Note also that ''appAnalysis'' includes malware and vulnerability work, not only privacy measurement, so none of these shares is a share of "mobile privacy papers".
 ===== Getting the Apps =====
@@ Line 42: / Line 54: @@
 | **F-Droid** | fully open index, ''index-v2.json'' with signature verification((F-Droid, [[https://f-droid.org/docs/All_our_APIs/|All our APIs]]. Checked 2026-08-27.)) | ~thousands of FOSS apps. A fine population for a study //about FOSS//; a badly biased one for a study about apps users have |
-**The official Google Play Developer (Android Publisher) API cannot fetch other developers' APKs.** It is scoped to apps you publish. There is no sanctioned bulk-download path, which is why every large Android study in the corpus uses AndroZoo, an unofficial scraper, or a mirror.
+**The official Google Play Developer (Android Publisher) API cannot fetch other developers' APKs.** It is scoped to apps you publish. There is no sanctioned bulk-download path, which is why the corpus's large Android studies rely on AndroZoo, an unofficial scraper, a mirror, a dataset someone else already collected, or industry telemetry — never on a first-party API. Of the 96 ''appAnalysis'' papers with a population of 100,000 apps or more, the sources include vendor product telemetry (NortonLifeLock, Palo Alto Networks), volunteer-device capture (Lumen), and inherited research datasets (Drebin, Andrubis) alongside the three routes above.
 Scraper currency, checked 2026-08-27:
@@ Line 51: / Line 63: @@
 | ''apkeep'' (EFF) | 1.0.0, 2026-04-30((GitHub, [[https://github.com/EFForg/apkeep|EFForg/apkeep]]. Checked 2026-08-27.)) | **Actively maintained.** The one downloader here with a maintainer and a 2026 release |
 | ''gplaycli'' | 3.29, **2020-03-10**; last commit 2021-10-02((GitHub, [[https://github.com/matlink/gplaycli|matlink/gplaycli]]. Checked 2026-08-27.)) | **Abandoned.** Still cited in papers; do not start here |
-| ''PlaystoreDownloader'' | — | **Archived 2024-07-27**((GitHub, [[https://github.com/ClaudiuGeorgiu/PlaystoreDownloader|ClaudiuGeorgiu/PlaystoreDownloader]]. Checked 2026-08-27.)) — read-only, will not track Play's auth changes |
+| ''PlaystoreDownloader'' | 2.0 alpha, 2022-01-08 | **Archived 2024-07-27**((GitHub, [[https://github.com/ClaudiuGeorgiu/PlaystoreDownloader|ClaudiuGeorgiu/PlaystoreDownloader]]. Checked 2026-08-27.)) — read-only, will not track Play's auth changes |
 On terms of service: the Play-specific terms do not carry a blanket anti-scraping clause; the relevant text is in Google's general Terms of Service, and its current wording is conditioned on machine-readable instructions — it prohibits "using automated means to access content from any of our services in violation of the machine-readable instructions on our web pages (for example, robots.txt files that disallow crawling, training, or other activities)".((Google, [[https://policies.google.com/terms|Terms of Service]], effective 30 July 2026, "Don't abuse our services". Checked 2026-08-27.)) That is narrower than the blanket prohibition older papers quote, and it means ''play.google.com/robots.txt'' is a document your ethics section should actually have read. Only **8 of 529** ''appAnalysis'' papers mention store terms of service anywhere near a word about scraping or downloading. This is a reporting gap, not evidence that the field has concluded it is fine.
@@ Line 60: / Line 72: @@
 ^ Tool ^ Latest ^ Note ^
-| ''ipatool'' | v2.3.2, 2026-07-05((GitHub, [[https://github.com/majd/ipatool|majd/ipatool]]. Checked 2026-08-27.)) | Actively maintained; downloads (still-encrypted) IPAs with an Apple ID |
+| ''ipatool'' | v2.3.2, 2026-08-03((GitHub, [[https://github.com/majd/ipatool|majd/ipatool]]. Checked 2026-08-27.)) | Actively maintained; downloads (still-encrypted) IPAs with an Apple ID |
 | ''frida-ios-dump'' | last commit **2020-06-01**((GitHub, [[https://github.com/AloneMonkey/frida-ios-dump|AloneMonkey/frida-ios-dump]]. Checked 2026-08-27.)) | Stale. Widely cited, including by {[pradeep2022_comparative]}; expect to fix it yourself |
-| ''palera1n'' | v3.0.0 beta 2, 2026-07-27((GitHub, [[https://github.com/palera1n/palera1n|palera1n/palera1n]]. Checked 2026-08-27.)) | checkm8-based, so bounded to vulnerable hardware, not to iOS version |
+| ''palera1n'' | v3.0.0 beta 2, 2026-08-03((GitHub, [[https://github.com/palera1n/palera1n|palera1n/palera1n]]. Checked 2026-08-27.)) | checkm8-based, so bounded to vulnerable hardware, not to iOS version |
 | ''Dopamine'' | 3.0.9, 2026-08-22((GitHub, [[https://github.com/opa334/Dopamine|opa334/Dopamine]]. Checked 2026-08-27.)) | Actively released |
-| ''TrollStore'' | 2.1.1, 2024-09-02; commits to 2026-04((GitHub, [[https://github.com/opa334/TrollStore|opa334/TrollStore]]. Checked 2026-08-27.)) | Permanent signing without a full jailbreak, on the iOS versions it supports |
+| ''TrollStore'' | 2.1.1, 2026-04-01((GitHub, [[https://github.com/opa334/TrollStore|opa334/TrollStore]]. Checked 2026-08-27.)) | Actively released. Permanent signing without a full jailbreak, on the iOS versions it supports |
 Because a jailbreak is tied to specific hardware and firmware, **an iOS measurement is implicitly a measurement of whatever devices you could jailbreak**, and that is a sampling statement you owe the reader: model, iOS version, and jailbreak.
-One structural change since 2024 that redefines the iOS population: in the EU, "the App Store" is no longer the only channel. Apple's own documentation states that "users in the EU can install notarized iOS and iPadOS apps from alternative app marketplaces or directly from an authorized developer's website", with further changes to eligibility and fees effective 1 October 2026.((Apple, [[https://developer.apple.com/support/dma-and-apps-in-the-eu/|Apps and the Digital Markets Act in the EU]], page updated 18 August 2026. Checked 2026-08-27.)) A 2026 iOS study sampling only the App Store is sampling one distribution channel out of three in the EU, and should say so. {[liu2026_cracks]} is the corpus's closest look at unauthorised iOS distribution.
+One structural change since 2024 that redefines the iOS population: in the EU, "the App Store" is no longer the only channel. Apple's own documentation states that "users in the EU can install notarized iOS and iPadOS apps from alternative app marketplaces or directly from an authorized developer's website", with further changes to eligibility and fees effective 1 October 2026.((Apple, [[https://developer.apple.com/support/apps-in-the-eu|Apps in the EU]]; the older ''/support/dma-and-apps-in-the-eu/'' path redirects here. Checked 2026-08-27.)) A 2026 iOS study sampling only the App Store is sampling one distribution channel out of three in the EU, and should say so. {[liu2026_cracks]} is the corpus's closest look at unauthorised iOS distribution.
 ==== The storefront is part of your sampling frame ====
@@ Line 98: / Line 110: @@
 ===== Static Analysis =====
-Static analysis is how the field does scale: 225 of 529 ''appAnalysis'' papers (42.5%) name at least one static-analysis or reverse-engineering tool, and that share has been **flat at 41–44% across every four-year window since 2010**. It is not fashion; it is the only way to touch a million apps.
+Static analysis is how the field does scale: 225 of 529 ''appAnalysis'' papers (42.5%) name at least one static-analysis or reverse-engineering tool, and that share has been **flat at 41–44% across all four era windows** (2010–2015, 2016–2020, 2021–2024, 2025–2026). It is not fashion; it is the only way to touch a million apps.
 The current toolchain, with the share of the 529 that used each (folded — see [[#Methodology and limitations of these figures]]):
 ^ Tool ^ Papers ^ What it is for ^ Status, checked 2026-08-27 ^
-| ''Soot'' | 65 (12.3%) | Java/Dalvik IR, the substrate under most Android analyses | Soot 4.7.1 (2026-02-13) still maintained, but the rewrite **SootUp** v3.0.1 (2026-07-16) is where new work goes((GitHub, [[https://github.com/soot-oss/soot|soot-oss/soot]] and [[https://github.com/soot-oss/SootUp|soot-oss/SootUp]]. Checked 2026-08-27.)) |
+| ''Soot'' | 65 (12.3%) | Java/Dalvik IR, the substrate under most Android analyses | Soot 4.7.1 (2026-02-23) still maintained, but the rewrite **SootUp** v3.0.1 (2026-08-07) is where new work goes((GitHub, [[https://github.com/soot-oss/soot|soot-oss/soot]] and [[https://github.com/soot-oss/SootUp|soot-oss/SootUp]]. Checked 2026-08-27.)) |
-| ''apktool'' | 57 (10.8%) | unpack resources and manifest | v3.0.3, 2026-04-19((GitHub, [[https://github.com/iBotPeaches/Apktool|iBotPeaches/Apktool]]. Checked 2026-08-27.)) — maintained |
+| ''apktool'' | 57 (10.8%) | unpack resources and manifest | v3.0.3, 2026-07-20((GitHub, [[https://github.com/iBotPeaches/Apktool|iBotPeaches/Apktool]]. Checked 2026-08-27.)) — maintained |
-| ''FlowDroid'' | 49 (9.3%) | taint tracking, source→sink | 2.15.1, 2026-02-19((GitHub, [[https://github.com/secure-software-engineering/FlowDroid|secure-software-engineering/FlowDroid]]. Checked 2026-08-27.)) — maintained |
+| ''FlowDroid'' | 49 (9.3%) | taint tracking, source→sink | 2.15.1, 2026-02-23((GitHub, [[https://github.com/secure-software-engineering/FlowDroid|secure-software-engineering/FlowDroid]]. Checked 2026-08-27.)) — maintained |
 | ''Androguard'' | 37 (7.0%) | Python APK parsing and analysis | 4.1.4 on PyPI 2026-06-01((PyPI, [[https://pypi.org/project/androguard/|androguard]]. Checked 2026-08-27.)) — maintained |
-| ''jadx'' | 32 (6.0%) | decompile to readable Java | 1.5.6, 2026-02-25((GitHub, [[https://github.com/skylot/jadx|skylot/jadx]]. Checked 2026-08-27.)) — maintained; **this is what replaced ''smali''/''dex2jar''** |
+| ''jadx'' | 32 (6.0%) | decompile to readable Java | 1.5.6, 2026-07-10((GitHub, [[https://github.com/skylot/jadx|skylot/jadx]]. Checked 2026-08-27.)) — maintained; **this is what replaced ''smali''/''dex2jar''** |
 | ''smali''/''baksmali''/''dex2jar'' | 34 (6.4%) | disassemble to smali | Historical: **17.0% of 2010–2015 papers, 3.3% of 2025–2026** |
-| ''MobSF'' | 7 (1.3%) | batteries-included audit framework | v4.5.2, 2026-07-06((GitHub, [[https://github.com/MobSF/Mobile-Security-Framework-MobSF|MobSF/Mobile-Security-Framework-MobSF]]. Checked 2026-08-27.)) — maintained |
+| ''MobSF'' | 7 (1.3%) | batteries-included audit framework | v4.5.2, 2026-08-10((GitHub, [[https://github.com/MobSF/Mobile-Security-Framework-MobSF|MobSF/Mobile-Security-Framework-MobSF]]. Checked 2026-08-27.)) — maintained |
 | ''LibRadar'' | 23 (4.3%) | third-party library detection | **Abandoned — last commit 2018-12-21**((GitHub, [[https://github.com/pkumza/LibRadar|pkumza/LibRadar]]. Checked 2026-08-27.)) |
 | ''LibScout'' | 10 (1.9%) | third-party library detection | **Abandoned — last commit 2019-10-25**((GitHub, [[https://github.com/reddr/LibScout|reddr/LibScout]]. Checked 2026-08-27.)) |
@@ Line 148: / Line 160: @@
 Both appear; the corpus does not report the choice well. Probes over the 529 full texts: **109** say "physical device" or "real device" (or phone/smartphone/handset), **51** name an Android emulator product or phrase, and only **25** state plainly that they ran on an emulator. Emulator use as a share of the named tool families has //fallen// — 8.0% of 2010–2015 papers named an emulator against 1.1% of 2025–2026 — and the plausible explanation is that apps detect emulators — **15** papers mention emulator detection and **35** mention root detection, SafetyNet or Play Integrity — though the corpus cannot establish the causal link, only the co-occurrence.
-The relevant platform fact: **SafetyNet Attestation "was deprecated in 2022 and fully turned down in January 2025"**, and the Play Integrity API is its sole replacement.((Google, [[https://developer.android.com/privacy-and-security/safetynet/attestation|SafetyNet Attestation API]]. Checked 2026-08-27.)) An app checking device integrity in 2026 is calling Play Integrity, which reports on the device, the app's own integrity and the account — so a rooted handset and an emulator both fail it. If your target apps gate behaviour on integrity, say what you did about it.
+The relevant platform fact: **SafetyNet Attestation "was deprecated in 2022 and fully turned down in January 2025"**, and the Play Integrity API is its sole replacement.((Google, [[https://developer.android.com/privacy-and-security/safetynet/deprecation-timeline|SafetyNet Attestation API deprecation timeline]]; the older ''/safetynet/attestation'' path redirects here and carries the same sentence. Checked 2026-08-27.)) An app checking device integrity in 2026 is calling Play Integrity, which reports on the device, the app's own integrity and the account — so a rooted handset and an emulator both fail it. If your target apps gate behaviour on integrity, say what you did about it.
 ==== Driving the app: the coverage problem ====
@@ Line 161: / Line 173: @@
 | ''AndroidViewClient'' | 6 (1.1%) | |
-Only **48 of 529** papers report any coverage measure, and **30 (5.7%)** combine a UI driver with traffic interception — the "drive it and watch the wire" pipeline that a privacy measurement actually needs. When coverage //is// measured, the gap is large: {[bonett2018_discovering]} could only confirm 2,026 of 7,584 injected leaks as executable using GUI exploration, and {[lin2026_chameleoscan]} needed an LLM to get through the UI at all — it reports resolving 85.96% of intrusive ads and 95.56% of pop-ups blocking its exploration, and found distracting elements on 19.21% of the pages it visited.
+Only **48 of 529** papers report any coverage measure, and **30 (5.7%)** combine a UI driver with traffic interception — the "drive it and watch the wire" pipeline that a privacy measurement actually needs. When coverage //is// measured, the gap is large: {[bonett2018_discovering]} could only confirm 2,026 of 7,584 injected leaks as executable using GUI exploration, and {[lin2026_chameleoscan]} used an LLM to get through the UI — it reports resolving 85.96% of intrusive ads and 95.56% of pop-ups blocking its exploration, and found distracting elements on 19.21% of the pages it visited.
 The two systematic reviews to read before building a driver are {[kong2019_testing]} on automated Android testing (2019) and {[li2017_static]} on static analysis (2017). Both are outside these seven venues, and both are old enough that they predate Frida's adoption and every LLM-based method — read them for the taxonomy of approaches, not for the tool list.
 <WRAP important>
-**Attrition is a number you must report, and almost nobody does.** {[koch2023_enough]} downloaded 4,779 apps and successfully analysed **3,654 (76.5%)** — 71.0% on Android, 85.7% on iOS. Every percentage in that paper is over 3,654, not 4,779, and the paper says so. That is the model to copy: the app set you //analysed// is not the app set you //sampled//, and the difference is not random.
+**Attrition is a number you must report, and almost nobody does.** {[koch2023_enough]} downloaded 4,779 apps and successfully analysed **3,654 (76.5%)** — 71.0% on Android, 85.7% on iOS. Its app-level results are all over 3,654, not 4,779, and the paper says so. That is the model to copy: the app set you //analysed// is not the app set you //sampled//, and the difference is not random.
 </WRAP>
@@ Line 172: / Line 184: @@
 To see an app's traffic you terminate its TLS at a proxy you control. Four things stand between you and that, in order.
+<WRAP info>
+**Steps 1–3 below are Android.** iOS interception is a different problem and the page treats it as one: on iOS you install your CA as a configuration profile //and// enable full trust for it in Settings, which gets you unpinned traffic; for pinned apps you need code injection, which on a store-signed binary means a jailbroken device — so the iOS route runs through the jailbreak tooling in [[#iOS]] above, and your device and firmware are part of your sample description. {[pradeep2022_comparative]} did exactly this (Checkra1n plus Frida) and is the worked example. The one iOS-specific pinning-bypass tool the corpus names, SSL Kill Switch 2, is unmaintained and its README caps support at iOS 14.2 — there is no maintained drop-in replacement, so expect to write Frida hooks yourself.
+</WRAP>
 **1. The app must trust your CA.** Since **Android 7.0 (API level 24)** — 2016 — the default trust anchors for an app are system CAs only. Android's own documentation gives the defaults verbatim: apps targeting "Android 6.0 (API level 23) and lower" get %%<certificates src="system" />%% //and// %%<certificates src="user" />%%; apps targeting "Android 7.0 (API level 24) to Android 8.1 (API level 27)" get system only.((Google, [[https://developer.android.com/privacy-and-security/security-config|Network security configuration]]. Checked 2026-08-27.)) Installing your root as a //user// certificate therefore does nothing for any modern app. Your options are to install it as a **system** CA (root plus Magisk, or a modified system image), or to repackage the app with a Network Security Configuration that trusts user CAs, or to hook the validation.
@@ Line 189: / Line 205: @@
 Other measurements triangulate the prevalence, and they disagree because they measure different things over different populations — which is the point:
-  * {[oltrogge2021_mallory]}: of 1,335,322 free Play apps, 99,212 shipped a custom Network Security Configuration; of those, **88,174 (88.87%) //downgraded// security** relative to the defaults, and only **663** used NSC pinning. Separately, **8,606 of 1,098,479** apps targeting Android 7+ (8.67%) deliberately re-enabled trust in user-installed CAs — those are the apps you can still MITM with a user cert.
+  * {[oltrogge2021_mallory]}: of 1,335,322 free Play apps, 99,212 shipped a custom Network Security Configuration; of those, **88,174 (88.87%) //downgraded// security** relative to the defaults, and only **663** used NSC pinning. Separately, **8,606** apps deliberately re-enabled trust in user-installed CAs — those are the apps you can still MITM with a user cert. Mind the denominator: the paper reports this as "8.67%", which is the share of the **99,212 apps with a custom NSC**, not of the 1,098,479 apps targeting Android 7+ that the same sentence names (that share is 0.78%). Both numbers are in the paper; only one of them is 8.67%.
   * {[schmidt2023_iotflow]}: **385 of 9,889** IoT companion apps (3.89%) used pinning, detected from the NSC.
   * {[pourali2024_racing]}: pinning is not the only failure mode. **1,529 of 2,765 (55.3%)** Chinese-store apps had at least one of four certificate-validation defects, against **322 of 5,061 (6.4%)** Play apps — so which store you sampled changes the answer by nearly an order of magnitude.
@@ Line 197: / Line 213: @@
 ^ Tool ^ Latest ^ Verdict ^
 | **Frida** | 17.17.0, 2026-08-05((GitHub, [[https://github.com/frida/frida|frida/frida]]. Checked 2026-08-27.)) | **Current, and the field's default.** 0% of 2010–2015 ''appAnalysis'' papers, **33.3% of 2025–2026** |
-| **objection** | 1.12.5, 2026-06-02((GitHub, [[https://github.com/sensepost/objection|sensepost/objection]]. Checked 2026-08-27.)) | **Current.** A Frida front-end; 8 of its 10 uses in this corpus are pinning bypass |
+| **objection** | 1.12.5, 2026-06-02((GitHub, [[https://github.com/sensepost/objection|sensepost/objection]]. Checked 2026-08-27.)) | **Current.** A Frida front-end; 7 of its 9 uses among the 529 are pinning bypass |
 | **Magisk** | v30.7, 2026-02-23((GitHub, [[https://github.com/topjohnwu/Magisk|topjohnwu/Magisk]]. Checked 2026-08-27.)) | **Current.** How you get a system CA onto a handset |
-| Xposed | archived 2020-06-08((GitHub, [[https://github.com/rovo89/Xposed|rovo89/Xposed]]. Checked 2026-08-27.)) | **Dead.** Peaked at 10.2% of 2016–2020 papers, 2.2% in 2025–2026 |
+| Xposed | archived; last release v89 (2017-12-17), last push 2020-06-08((GitHub, [[https://github.com/rovo89/Xposed|rovo89/Xposed]] — repository flag ''archived: true''. Checked 2026-08-27.)) | **Dead.** Peaked at 10.2% of 2016–2020 papers, 2.2% in 2025–2026 |
-| LSPosed | v1.9.2, **2023-10-11**((GitHub, [[https://github.com/LSPosed/LSPosed|LSPosed/LSPosed]]. Checked 2026-08-27.)) | Repository still active, **no release cut in nearly three years** |
+| LSPosed | v1.9.2, **2023-10-11**; last commit on the default branch **2024-01-07**((GitHub, [[https://github.com/LSPosed/LSPosed|LSPosed/LSPosed]]. The repository's ''pushed_at'' is 2026-08-26 because that counts any branch; the default branch has not moved since January 2024. Checked 2026-08-27.)) | **Stalled.** No release in nearly three years and no default-branch commit in over two |
 | JustTrustMe | last release 2016; last commit 2024-09-02((GitHub, [[https://github.com/Fuzion24/JustTrustMe|Fuzion24/JustTrustMe]]. Checked 2026-08-27.)) | **Unmaintained**, and depends on the dead Xposed line |
 | SSL Kill Switch 2 | 0.14, 2019-12-03; last commit 2023-07-09((GitHub, [[https://github.com/nabla-c0d3/ssl-kill-switch2|nabla-c0d3/ssl-kill-switch2]]. Checked 2026-08-27.)) | **Unmaintained**; its own README claims support only to iOS 14.2 |
 | TrustMeAlready | archived 2019-09-23((GitHub, [[https://github.com/ViRb3/TrustMeAlready|ViRb3/TrustMeAlready]]. Checked 2026-08-27.)) | **Dead** |
-**4. You have to report what you lost.** Only **13 of 529** papers mention the Network Security Configuration at all; **71 (13.4%)** mention pinning; **33** describe bypassing it. Given that traffic interception appears in 110 papers, **most papers that intercepted traffic never wrote down what they could not intercept**.
+**4. You have to report what you lost.** Intersected properly, over the full text of the **110 ''appAnalysis'' papers that named a traffic-interception tool**: **44 (40.0%)** mention pinning at all, **22 (20.0%)** describe bypassing it, **6 (5.5%)** mention the Network Security Configuration, and **65 (59.1%) mention none of the three**. So a clear majority of the papers that intercepted app traffic never wrote down what they could not intercept — and the ones that did are concentrated in the last few years.
+==== Three things that will bite you that no paper warns you about ====
+  * **A proxy sees the whole device, not your app.** Play Services, the OS itself and every other installed app also talk. A per-app claim needs per-app flow attribution — the UID behind the socket, a Frida stack trace, or one app installed at a time on a clean profile. A narrow probe for a paper //describing// that step finds **1 of 529**, which is more a comment on how rarely it is written down than on how often it is done. {[rodriguez2025_settings]} attributes connections to SDKs via Frida stack traces precisely because the proxy log alone cannot.
+  * **QUIC bypasses a TCP proxy.** An app speaking HTTP/3 over UDP will simply not appear in mitmproxy unless you block UDP 443 to force TCP fallback, or terminate QUIC. A traffic measurement that does neither has a silent hole whose size it cannot report. **14 of the 529 papers mention QUIC at all.**
+  * **There is a no-root route, and the corpus mostly forgot it.** An on-device ''VpnService'' app captures traffic without rooting, which is how the Lumen/ReCon/AntMonitor line of work collected from real users' devices. **39 of the 529 papers name such a tool or the API; 8 describe the technique.** It cannot break pinning, and it changes your population from "apps you chose" to "apps your volunteers had" — but for a field study, or for any measurement where rooting the handset is not an option, it is the technique to reach for. Lumen itself is gone (see below); the approach is not.
 <WRAP tip>
-A defensible pipeline in 2026, and the one the corpus's recent traffic-measurement papers converge on: **Magisk-rooted physical handset → your root as a system CA → mitmproxy → Frida/objection to unhook pinning where needed → Appium or UiAutomator to drive**, with a per-app record of //downloaded, installed, launched, traffic captured, traffic decrypted, pinning detected//. ''mitmproxy'' is in 52 papers (9.8%) and rising; that record is what turns "we intercepted traffic" into a number.
+A defensible pipeline in 2026, built from the components recent papers most often combine — Frida and mitmproxy co-occur in 16 of the 191 ''appAnalysis'' papers since 2023, and the full named stack in 3, so this is a recommendation assembled from practice rather than a practice the field has converged on: **Magisk-rooted physical handset → your root as a system CA → mitmproxy → Frida/objection to unhook pinning where needed → Appium or UiAutomator to drive**, with a per-app record of //downloaded, installed, launched, traffic captured, traffic decrypted, pinning detected//. ''mitmproxy'' is in 52 papers (9.8%) and rising; that record is what turns "we intercepted traffic" into a number.
 </WRAP>
@@ Line 216: / Line 238: @@
 ^ Target ^ Papers ^ Share ^
-| ''other'' (outside the enum) | 234 | 44.2% |
 | ''mobile-app'' | 198 | 37.4% |
 | ''vulnerability'' | 113 | 21.4% |
@@ Line 240: / Line 261: @@
   * **Third-party SDKs are near-universal and the reported figure depends entirely on the detector.** {[kollnig2022_iphones]}, over random samples of 12,000 apps per platform, found **88.73% of Android and 79.35% of iOS apps** contained at least one tracking library, and **81.44% / 68.46%** contacted a tracking domain at startup. {[rodriguez2025_settings]} found **53.68%** of its Android sample embedded at least one Facebook SDK and only **6.79%** had disabled the SDK's advertiser-ID collection from its privacy-hostile default.
   * **Pre-consent transmission in apps is the mobile analogue of the web's pre-consent cookie result.** {[koch2023_enough]}: **3,013 of 3,654 analysed apps (82.5%)** contacted a monitored tracking endpoint before any interaction, **1,285 (35.2%)** sent a unique identifier, and only **146 (4.0%)** set any TCF string — so a TCF-based methodology ([[Privacy:TCF consent strings]]) covers almost nothing on mobile. See also {[nguyen2021_sharefirst]} and {[nguyen2022_freely]}.
-  * **Store-declared privacy is a measurable artefact and it is wrong a lot.** {[khandelwal2024_unpacking]}: **46.8%** of Play apps had a Data Safety entry as of 31 May 2023; **40%** changed it at least once across ten monthly snapshots; and of a subset of popular apps declaring no data sharing, **42%** shipped an advertising or analytics library. Only **55 of 529** corpus papers mention privacy labels or Data Safety at all — this is under-measured relative to how easy it is to scrape.
+  * **Store-declared privacy is a measurable artefact and it is wrong a lot.** {[khandelwal2024_unpacking]}: **46.8%** of Play apps had a Data Safety entry as of 31 May 2023; **40%** changed it at least once across ten snapshots between June 2022 and May 2023; and of a subset of popular apps declaring no data sharing, **42%** shipped an advertising or analytics library. Only **55 of 529** corpus papers mention privacy labels or Data Safety at all — this is under-measured relative to how easy it is to scrape.
   * **Static and dynamic views of the same app genuinely diverge.** {[schmidt2023_iotflow]} compared both on the 13 apps whose physical IoT devices it had, and got **54 domains and 281 paths statically against 40 domains and 160 paths dynamically** — static found more, because dynamic could not reach it. Do not assume the dynamic view is the ground truth; it is a different lower bound.
@@ Line 280: / Line 301: @@
 | Apple App Store (largest single spelling) | 11 | 2.1% |
 | F-Droid | 7 | 1.3% |
+**Datasets somebody else already collected.** ''pre-existing-dataset'' is the sampling method for 71 of those 400 papers (17.8%), and the page would be failing its own purpose if it did not name them. Beyond AndroZoo, the sources the corpus's own large populations draw on include **Drebin** and **Andrubis** (malware), the **Gamba et al. preinstalled-app dataset** and **Firmware Scanner** corpus, **Koodous**, **VirusShare** and the **AMD** dataset, **PrivacyGrade**, and the **Lumen** volunteer captures. Two of these are worth a warning: a malware dataset is not a sample of apps users have, and a 2014-era dataset used in a 2026 paper is a claim about 2014. Check the collection date before you inherit one.
 **How the sample was drawn**, for the 400 papers with a mobile-apps population: ''purposive'' 196 (49.0%), ''top-n'' 140 (35.0%), ''random'' 91 (22.8%), ''pre-existing-dataset'' 71 (17.8%), ''exhaustive'' 51 (12.8%), ''seed-and-crawl'' 38 (9.5%), ''convenience'' 35 (8.8%), ''stratified'' 28 (7.0%). Multi-valued, so shares do not sum to 100%. **"Top-//n// of a store chart" is the mobile equivalent of "Alexa top 1M"** and inherits every objection on [[Design:Website selection]] plus one more: the chart is per-country and per-day and there is no Tranco for it.
@@ Line 316: / Line 339: @@
 | mentions an LLM or GPT (case-sensitive) | 42 |
 | mentions store terms of service near scraping/downloading | 8 |
+| mentions QUIC | 14 |
+| names an on-device-VPN capture tool or the ''VpnService'' API | 39 |
+| describes the on-device-VPN capture technique | 8 |
+| describes attributing traffic to a specific app or library | 1 |
 ==== Methodology and limitations of these figures ====
@@ Line 336: / Line 363: @@
 ^ Practice ^ Status ^ Evidence ^
 | Hook the app with **Frida** (+ objection) | **Current, and the field's default.** | 0% of 2010–2015 ''appAnalysis'' papers → 33.3% of 2025–2026; Frida 17.17.0 released 2026-08-05 |
-| Hook with **Xposed** or an Xposed module (JustTrustMe, TrustMeAlready) | **Superseded.** | Xposed archived 2020; LSPosed's last release is 2023-10-11; corpus share fell 10.2% (2016–2020) → 2.2% (2025–2026) |
+| Hook with **Xposed** or an Xposed module (JustTrustMe, TrustMeAlready) | **Superseded.** | Xposed archived, last push 2020-06-08; LSPosed's last release is 2023-10-11 and its default branch stopped in January 2024; corpus share fell 10.2% (2016–2020) → 2.2% (2025–2026) |
 | **TaintDroid** for dynamic taint tracking | **Historical.** | 6.8% of 2010–2015 papers, **0% since 2021**, though 84 papers still //mention// it. It is a modified Android 4.x; it cannot run a 2026 app |
 | **smali / baksmali / dex2jar** as the decompilation step | **Superseded by jadx.** | 17.0% → 3.3%; jadx 0% → 13.3% over the same windows |
-| **Soot** as the analysis substrate | **Current, but check SootUp.** | Soot 4.7.1 (2026-02) maintained; SootUp v3.0.1 (2026-07) is the rewrite and where new development is |
+| **Soot** as the analysis substrate | **Current, but check SootUp.** | Soot 4.7.1 (2026-02-23) maintained; SootUp v3.0.1 (2026-08-07) is the rewrite and where new development is |
-| **FlowDroid** for taint analysis | **Current, and known-unsound.** | 2.15.1 (2026-02) maintained; missed >48% of executable injected leaks in {[bonett2018_discovering]}. Use it //and// validate |
+| **FlowDroid** for taint analysis | **Current, and known-unsound.** | 2.15.1 (2026-02-23) maintained; missed >48% of executable injected leaks in {[bonett2018_discovering]}. Use it //and// validate |
 | **LibRadar / LibScout** for SDK detection | **Abandoned, and still the corpus's most-used option.** | Last commits 2018 and 2019. Their signatures predate Android 11 |
 | Build your **own SDK signatures** and publish them | **Current best practice, and rare.** | {[specter2025_fingerprinting]} (723 families, 14,178 versions); {[rodriguez2025_settings]} cross-validates LibScout against Frida rather than trusting it |
@@ Line 347: / Line 374: @@
 | **Random UI events (Monkey)** as the exploration strategy | **The floor.** Still shipped, still used, still shallow. | 6.4% of papers; {[kong2019_testing]} is the survey of what else exists |
 | **LLMs for classification** (policies, UI text, labels) | **New in 2025–2026 and moving fast.** | ''classification.method = llm'' among ''appAnalysis'' papers goes 0% (pre-2021) → 0.5% (2021–2024) → **15.6%** (2025–2026). 90-paper denominator; do not over-read the level, but the direction is unambiguous |
-| **LLM-driven UI exploration** | **New, promising, one data point.** | {[lin2026_chameleoscan]} is the only paper in the corpus using an LLM to //get through the UI// rather than to classify text. One paper is not a practice |
+| **LLM-driven UI exploration** | **New, promising, one data point.** | {[lin2026_chameleoscan]} is the only paper we found in these seven venues using an LLM to //get through the UI// rather than to classify text. One paper is not a practice |
 | **''gplaycli''** to fetch APKs | **Abandoned.** | Last release 2020-03-10, last commit 2021-10-02 |
 | **''PlaystoreDownloader''** | **Archived 2024-07-27.** | Read-only repository |
@@ Line 379: / Line 406: @@
 <WRAP todo>
-  * **Nobody has re-measured the pinning-bypass success rate since 2022.** {[pradeep2022_comparative]} gives ≈51.5% of pinned Android destinations circumvented and ≈66.2% on iOS. Frida is now at 17.17.0. Repeating that single measurement would be cheap and would be cited by every mobile traffic paper thereafter.
+  * **We found no re-measurement of the pinning-bypass success rate since 2022 in these seven venues.** {[pradeep2022_comparative]} gives ≈51.5% of pinned Android destinations circumvented and ≈66.2% on iOS. Frida is now at 17.17.0. Repeating that single measurement would be cheap and would be cited by every mobile traffic paper thereafter.
   * **There is no maintained, validated third-party-SDK detector.** LibRadar and LibScout are the field's workhorses and both stopped in the 2010s. A maintained signature set with a published validation would immediately improve a large slice of the mobile privacy literature. {[specter2025_fingerprinting]} shows the scale of what is missing.
   * **How much does a mirror change the binary?** We found no study in these seven venues that systematically compares APKs from APKPure, APKMirror or Aptoide against the Play original by signature and content. 10 papers in ''appAnalysis'' name a mirror among the tools they used, and 46 mention some third-party APK/IPA mirror or downloader somewhere in the text, so this is not a hypothetical gap.