Can We Stop The Ads? Taxonomy and Characterization of Smartphone Splash Ads and Existing Countermeasures
Study of 108 ad-defense implementations finds only one tool blocked splash-ad navigation across ten popular apps, and it required Accessibility permission.
The paper taxonomizes smartphone splash ads — full-screen ads at app launch that trick users into trigger mechanisms such as moving the phone — and analyzes 108 documented advertising defenses for deployment barriers. Many defenses require device rooting, jailbreaking, runtime code injection, or application modification; others need extra permissions, rule maintenance, compilation, or payment. In evaluating 13 configurations of 11 tools across 10 popular apps, only one prevented ad-triggered navigation across all ten apps, requiring Accessibility permission and leaving ads visible roughly one second before dismissal. Documented harms include delayed emergency response, driver distraction, and degraded accessibility for vision-impaired users.
- Only one of 13 tested tool configurations blocked navigation across all 10 apps
- Defenses often need rooting, jailbreaking, code injection, or app modification
- Splash ads delay emergency response and harm accessibility
- Authors urge smartphone makers to provide more regulated ad-handling platforms
Full article214 words · extracted from arxiv.org · click to collapse
Splash ads are full-screen advertisements that pop up and appear as the first interaction page when users start an app, often tricking users into unknowingly activating certain trigger mechanisms, such as moving the phone to redirect users to other profit-driven third parties. So far, splash ads have already caused significant real-world impacts, ranging from significantly delaying emergency response to distracting drivers, as well as degrading accessibility of apps to vision-impaired users. We analyze 108 documented implementations of advertising defenses to examine their applicability to splash ads and the requirements users face when deploying them. Our analysis identifies substantial deployment barriers, including device rooting or jailbreaking, runtime code injection, and application modification. Options without these requirements can still involve additional permissions, rule maintenance, source compilation, or payment. In our evaluation of 13 configurations of 11 tools across 10 popular apps, only one tool prevented the target ad-triggered navigation across all ten apps. It required Accessibility permission, and ads remained visible for approximately one second before dismissal. Other tested configurations failed to prevent navigation or, in some cases, left host apps unable to launch or stuck on the ad page. We further analyze the outstanding challenges and pos- sible future directions, highlighting the urgent need to incentivize smartphone manufacturers to provide more friendly and regulated platforms.
Text extracted automatically; images, tables and formatting may be missing. Original: https://arxiv.org/abs/2609.17316