What Mobile Ads Know About Mobile UsersSooel SonGoogleDaehyeok KimKAISTAbstractWe analyze the software stack of popular mobile advertising libraries on Android and investigate how they protectthe users of advertising-supported apps from maliciousadvertising. We find that, by and large, Android advertising libraries properly separate the privileges of the adsfrom the host app by confining ads to dedicated browserinstances that correctly apply the same origin policy.We then demonstrate how malicious ads can infer sensitive information about users by accessing external storage,which is essential for media-rich ads in order to cachevideo and images. Even though the same origin policyprevents confined ads from reading other apps’ externalstorage files, it does not prevent them from learning that afile with a particular name exists. We show how, dependingon the app, the mere existence of a file can reveal sensitiveinformation about the user. For example, if the user hasa pharmacy price-comparison app installed on the device,the presence of external-storage files with certain namesreveals which drugs the user has looked for.We conclude with our recommendations for redesigningmobile advertising software to better protect users frommalicious advertising.I.IntroductionMany mobile apps rely on advertising for at least part oftheir revenue. An advertising-supported app typically incorporates multiple advertising libraries (AdSDKs). Whilethe app is running, each AdSDK fetches ads from itsservers, where they have been uploaded by advertisers, anddisplays them to the app’s user.Business imperatives are driving the development ofmobile advertising technology. To increase users’ rePermission to freely reproduce all or part of this paper for noncommercialpurposes is granted provided that copies bear this notice and the fullcitation on the first page. Reproduction for commercial purposes is strictlyprohibited without the prior written consent of the Internet Society,the first-named author (for reproduction of an entire paper only), andthe author’s employer if the paper was prepared within the scope ofemployment.NDSS ’16, 21-24 February 2016, San Diego, CA, USACopyright 2016 Internet Society, ISBN 23407Vitaly ShmatikovCornell Techsponse to their ads, advertisers demand that AdSDKssupport media-rich, active ads with JavaScript, images, andvideo. Consequently, modern AdSDKs provide facilitiesfor MRAID (Mobile Rich Media Ad Interface Definitions),including local caching of ad content. Furthermore, mobileads are fetched dynamically and often originate from otheradvertising networks, exchanges, brokers, and auctions.Redirection, obfuscation, and proliferation of activecontent with new features make it difficult for AdSDKsto analyze or sanitize the content of the ads they serve.Therefore, AdSDKs must treat each ad as potentiallyuntrusted and isolate it to prevent it from damaging theuser’s device or extracting sensitive information.AdSDKs on Android solve this challenge by applyingprivilege separation. They show ads in a separate instanceof the embedded WebView browser that does not have thesame permissions as the host app and the AdSDK. For thepurposes of this paper, we assume that WebView correctlyenforces the same origin policy and prevents JavaScript inmobile ads from reading any content from other origins,including local files on the device.Our contributions. We study mobile ad isolation in fourpopular Android AdSDKs (AdMob, MoPub, AirPush andAdMarvel) and investigate what a fully confined, privilegeseparated mobile ad can learn about the user of thedevice on which it is displayed. In contrast to prior work,which focused on threats presented by malicious apps andadvertising libraries, the capabilities of our attacker arevery restricted. We assume that all apps on the user’sdevice are benign, AdSDKs are benign as well, and theattacker cannot monitor or modify the user’s networkcommunications. The only attack vector available to amalicious advertiser is an ad-supported app that runs on theuser’s device and displays the attacker’s ads in a confinedWebView instance.On modern Android devices, external storage is a sharedcache where multiple apps store their files. As mentionedabove, mobile ads need access to external storage, too, inorder to cache videos and images. That said, when thesame origin policy is enforced correctly, JavaScript in amalicious ad cannot read external-storage files belongingto other apps (although we demonstrate an exception in apopular AdSDK, which has serious privacy consequences).The standard same origin policy, however, does notprevent an ad from determining whether a resource with

a particular name exists on the device. We explain howa malicious ad running in any Android AdSDK can usethis “local resource oracle” to infer sensitive information—which medications the user is taking, the user’sgender preference in dating, his or her social circle, andeven identity—if the user has been using certain apps onhis or her device. Many apps cache files with predictablenames in external storage in a way that depends on theuser’s in-app activities: a pharmacy shopping app cachesimages of the drugs that the user has searched for, adating app caches the profiles that the user has lookedat, etc. By attempting to load certain external-storagefiles and seeing which loads succeed, a mobile ad caninfer sensitive information about the user even though itcannot read the loaded files. We also demonstrate how theleakage of location information combined with the deviceidentifier in one of the AdSDKs in our study enablesmalicious advertisers to construct partial trajectories ofusers’ movements.We conclude with our proposed short-term defense andlong-term recommendations for re-designing the Androidadvertising software stack to better protect mobile usersfrom malicious advertising.II.Fig. 1: Mobile advertising ecosystemA. ParticipantsFigure 1 shows a highly simplified overview of themobile advertising ecosystem. The three main participantsare mobile app developers or publishers, AdSDK providers(mobile advertising services), and advertisers.Advertisers or their agencies upload advertising creatives as text, images, URLs, JavaScript, or HTML to theadvertising networks managed by AdSDK providers. Asmentioned above, app developers integrate AdSDKs intotheir apps. While the app is running, each AdSDK sendsHTTP(S) requests to the servers of its advertising networkand receives creatives written in HTML, JSON, or XML.AdSDK then displays the received creatives within WebView instances [51]. Each creative delivered and displayedon a mobile device is called an advertising impression;impressions are one of the measurement units used tocharge advertisers. Section III describes the software stackused to support this advertising model on Android.AdSDK providers play an essential role in connectingadvertisers and app developers. Providers release AdSDKlibraries and maintain advertising servers, which servemany types of advertising creatives, including banner andfull-screen impressions. To maximize the click-throughrates of their impressions, advertisers seek to enrich users’experience by making impressions more dynamic andresponsive. To this end, AdSDKs have started to support mobile rich media advertisement interface definitions(MRAID) [26]. MRAID allows advertising creatives tobe written in HTML and to invoke a limited set ofJavaScript methods that require native-level functionalities.For instance, an MRAID advertising creative can invokemraid.storeP icture to store images on a mobile device.As Figure 1 illustrates, a creative delivered to mobiledevices is not identical to the creative that was submitted by an advertiser. AdSDK providers rewrite thecreatives and add extra functionalities for interacting withusers. For instance, AdMob adds a button that lets usersturn off interest-based advertisement or report offensiveadvertising impressions. Furthermore, AdSDK providersinsert trackers into creatives (see Section II-C). Trackersnotify advertisers or AdSDK providers whether deliveredcreatives are indeed displayed on users’ devices.Mobile advertising ecosystemMobile advertising helps developers of mobile appsobtain revenue without directly charging users. Therefore,advertising is a key component of the mobile app ecosystem. Mobile advertising is typically integrated into mobileapps via an advertising library or SDK (AdSDK), whichfetches and displays mobile ads while the app is running.Over 41% of apps in the Google Play Store include atleast one mobile advertising library [6], and it is commonfor a single app to include several libraries from multipleadvertising providers [37].An Android AdSDK is a typically a third-party JARlibrary, which is intended to be included into the app’scode with minimal changes and whose business logic isopaque to the app’s developer. The code of an AdSDKruns with the same privileges as its host app. If the AdSDK,or the ads it is fetching and displaying, need a particularpermission, the app must request this permission from theuser even if it is not needed by the app’s core functionality. Some AdSDKs abused these permissions to collectpermanent device identifiers or sensitive information aboutthe user [22, 46]. As we explain in Section III-C, theinformation collected by the AdSDK is typically used bythe advertising service internally to decide which ads toshow, but most of it is not disclosed to the ads, nor to theadvertisers who created these ads.In the rest of this section, we explain the trust relationships between apps, AdSDKs, and advertisers, and listthe information that may be available to an AdSDK whenchoosing ads to show to the user.2

B. ThreatsIdentifierGAIDFor the purposes of this paper, we assume that themobile apps and the AdSDKs are benign, but advertisersare untrusted and their impressions may contain maliciouscontent. The attacker’s capabilities in this model are significantly weaker than in the prior literature on the securityand privacy of mobile advertising (see Section VIII),which focused on threats from malicious apps and abusiveAdSDKs. That said, advertising-supported mobile apps arevery popular, thus a malicious advertiser has many moreopportunities to have his creatives displayed on users’devices than a malicious app creator, who must evade appstore filters and convince users to install his apps.This threat model is realistic in today’s mobile advertising ecosystem. In the U.S. and Europe, apps usually comefrom trusted app stores, are vetted by platform providers,and installed voluntarily by users. AdSDKs are typicallydeveloped and deployed by trusted advertising servicessuch as AdMob and MoPub, which have their reputation atstake and are thus incentivized to ensure that their AdSDKsdo not abuse the permissions granted to them.Advertising impressions, on the other hand, often passthrough multiple layers of brokers, auctions, and exchangesbefore arriving to users’ devices. Because of this indirection, the exact origin of a given ad may be opaque.AdSDK providers depend on real-time monitoring andmanual review to prevent malicious advertisers from serving offensive or malicious creatives, but these measuresare not perfect. Filtering dynamic, active content such asJavaScript is notoriously difficult, thus it is not alwaysfeasible for advertising services to ensure that all mobileads they serve are free of malicious content, especially ifthe content in question is stealthily snooping on the userrather than actively trying to install malware.Therefore, modern AdSDKs treat ads as untrustedcontent and confine them to ensure that they cannotaccess sensitive information on the devices where theyare displayed. In Section III, we describe the technicalconfinement mechanisms used by AdSDKs.Android IDIMEIIMSIMAC addressDescriptionUser-resettable 32-digit alphanumericidentifier64-bit number randomly generated whendevice is set up for the first time [5]15-digit decimal identifier representingGSM or LTE device15-digit decimal identifier representingmobile subscriber identity48-bit number assigned to the device’sWi-Fi network entPermanentPermanentTABLE I: Android device identifiersidentifiers are permanent and cannot be controlled by theuser (Android ID is semi-permanent because it can be resetonly when the device is restored to its factory setting).Since August 2014, Google Play developer program policyrequires Android apps to use GAID [2]. However, GAIDis only available on mobile devices that have the GooglePlay service installed, and many Android devices withoutthe Google Play service still use permanent identifiers.Device identifiers play a key role for counting userclicks and advertising impressions served to the user. AdSDKs attach identifiers to HTTP(S) requests that they sendto their providers’ advertising servers, enabling the latter tolink requests coming from the same device. Some AdSDKsalso make device identifiers available to the advertisingcreatives they display, enabling the trackers embedded inthese creatives to send the identifiers to advertisers. Thesetrackers are implemented using JavaScript or image DOMelements (tracking pixels).AdSDKs typically need access to geolocation and external storage on the device. Location is used to servegeotargeted advertising because the GPS coordinates fromthe device’s onboard sensor are more accurate than theapproximate location inferred from the device’s IP address. Many AdSDKs attach location data to advertisingrequests [46]. External storage is needed by media-richadvertising creatives to cache video and image files. Fromthe user’s viewpoint, requests for these permissions comefrom the mobile app itself. The user cannot tell whetherthe app intrinsically requires these permissions for its corefunctionality or is requesting them for the benefit of oneof several AdSDKs integrated into the app’s code.We investigated four popular AdSDK to determine whatinformation they (1) send to AdSDK providers and (2)make available to advertisers. For this study, we integratedeach AdSDK into an Android test app following theprovider’s integration guidelines and then used a proxyserver to analyze advertising requests sent by the AdSDK.Table II shows the results of our study. Observethat MoPub lets advertisers collect both the locationand the device identifier [33], although fine-grained location is available only if the host app has the ACCESS FINE LOCATION permission. MoPub asks developers to request ACCESS COARSE LOCATION onits behalf, not ACCESS FINE LOCATION, but an appmay still require fine-grained location for its core functionality. Since GAID is pseudonymous, in theory usersC. Information collected by AdSDKsBoth advertisers and advertising services commonly“track” users, i.e., link activities performed by the sameuser in order to build detailed user profiles, learn users’interests, and better target their advertising.In the conventional Web ecosystem, tracking is oftenperformed using third-party cookies [32], although thereare several other mechanisms [1, 35]. In the mobile ecosystem, advertising impressions are displayed not in conventional Web browsers but in WebView instances integratedinto mobile apps. Because WebView instances hosted bydifferent apps do not share cookies or any other browserstate, AdSDK providers rely on device identifiers [27].Table I shows common identifiers used by AdSDKs onAndroid. Google Advertising ID (GAID) is a pseudonymous identifier that can be reset by the user. The other3

Information sent to AdSDK providers (AdSDK) or advertisers (Ads)AdSDKFine LocAndroid IDH(Android ID)AdMob [4] MoPub [33]AdSDK, AdsAdSDKAirPush [36]AdSDKAdSDK, AdsAdMarvel [3] AdSDK Ads, Ads GAIDModelAdSDKAdSDKAdSDK , Ads , Ads AdSDKAdSDKH(IMEI)AdSDKAdSDK, AdsAdSDK, AdsAdSDK, AdsInformation sent only if Google Play Services are present on the device.Information sent only if Google Play Services are not present on the device.TABLE II: Tracking information available to advertisers and AdSDK providerscan reset their identifiers to avoid tracking. We don’tknow whether users are aware of this or do in fact resetthis identifier. In any case, location itself is a strongdeanonymizer [20, 31, 55]. Furthermore, on devices without Google Play Services, fixed hash values of permanentAndroid identifiers are used instead of GAID. Wheneverlocation is paired with a semi-permanent or permanentidentifier, the advertiser can infer the device’s trajectory(see Section VI-E).III.Advertising software stack on AndroidA. AdSDKs and WebViewDevelopers of ad-supported mobile apps integrateAdSDK code into their apps and request permissionsneeded by AdSDKs. When the user runs an ad-supportedapp, the included AdSDK fetches advertising creatives bysending a GET or POST HTTP(S) request to its provider’sservers. As explained in Section II-C, AdSDK may attachdevice identifier and location to these requests.Depending on the AdSDK, the response from the servermay be in JSON, XML, or HTML. AdSDK extracts an advertising creative from this response. AdSDK then createsa WebView instance and loads the extracted creative intothis instance. WebView is an Android class designed todisplay webpages inside apps [51].Figure 2 shows a banner impression from the AdMobAdSDK and an interstitial impression from the MoPubAdSDK, both displayed within WebView (and deliberatelyblurred).Fig. 2: Examples of mobile advertising impressionsin access control for external storage. First, reading external storage requires the READ EXTERNAL STORAGE permission (implicitly granted by WRITE EXTERNAL STORAGE). Second, each app has its owndirectory on external storage, allowing it to manage itsdata without any storage permissions. Apps with the READ EXTERNAL STORAGE permission can read datafrom the directories managed by other apps, but cannotwrite into them.MoPub, AirPush, and AdMarvel all instruct app developers to request WRITE EXTERNAL STORAGE sothat their AdSDKs can function properly. This automatically grants the READ EXTERNAL STORAGE permission. Furthermore, READ EXTERNAL STORAGEis one of the top four permissions requested by apps inpopular categories [39]. Therefore, we assume that mostad-supported mobile apps can read external storage.B. External storageIt is critical for AdSDKs to reduce latency when delivering advertising creatives to mobile devices and to minimizenetwork data usage. AdSDKs thus need to cache files,images, and advertising videos on the device. They useexternal storage for this purpose.Android supports devices with external storage [16],typically an SD card. External storage is protected by thepermission system. Prior to Android 4.4 KitKat, readingdata from external storage did not require any permissions; writing required the WRITE EXTERNAL STORAGE permission. Android 4.4 made two major changesC. Mobile ad isolationAs explained in Section II-B, mobile ads must betreated as potentially malicious. Even prominent Internet sites have been affected by malicious advertisingimpressions [48]. Furthermore, many AdSDK providers,including AdMob, MoPub, and AdMarvel, serve ads overHTTP. Therefore, a man-in-the-middle attacker can injectmalicious code into ads as they travel over the network.4

loaded in this manner can embed local files,1 subject tothe standard SOP for cross-origin resources. Conceptually, this is very similar to a cross-domain GET, whichis pervasively used in conventional webpages. Althoughembedding is allowed, SOP does not allow JavaScript fromone origin to read content from another origin. Therefore,assuming that WebView correctly enforces SOP, JavaScriptin advertising creatives can load—but not read!—local fileresources. This seemingly safe design is directly based onthe standard Web browser security model.Prior to Android 4.1 Jelly Bean, WebView consideredall file-scheme URIs to belong to the same origin. Technically, this is not a violation of SOP because Section 4in RFC 6454 specifies that the treatment of file-schemeURI origins is implementation-specific [8]. For example,Firefox treats two different file URIs as the same originonly if one is the other’s child directory, Internet Explorertreats all file URIs as the same origin by default, andChrome treats each file URI as a unique origin [11].Therefore, prior to Android 4.1, any ad loaded by anAdSDK could access any file owned by the host app andany file in external storage. Since Android 4.1, WebViewby default treats each file-scheme URI as a unique origin.AdSDKs may change this default setting by enablingsetAllowFileAccessFromFileURLs or setAllowUniversalAccessFromFileURLs [50]. The former allows HTMLcontent loaded from any file URI to access all resourcesfrom any file URIs. The latter allows HTML contentloaded from any file URI to access all resources regardlessof their origins. In either of these cases, if the host apphas the READ EXTERNAL STORAGE permission, anyHTML content loaded in a WebView created by an AdSDKcan read any file from external storage. In particular,if the AdSDK loads a malicious ad, JavaScript code inthis ad can steal local files using AJAX requests viaXMLHttpRequest.Fortunately, with one exception (see Section IV-B),modern AdSDKs do not change the default setting ofWebView. Therefore, malicious ads can only load, but notread, local files on the device.Fig. 3: Overview of Android advertising stackBecause AdSDKs have the same privileges as their hostapps, they must ensure that the ads they display cannotenjoy these privileges. To this end, AdSDKs confine adsin separate WebView instances, as shown in Figure 3.WebView instances created by different processes do notshare any state, such as cookies, even if they displaycontent from the same origin. Furthermore, WebViewenforces the standard same origin policy [8, 42] on thedisplayed content. An advertising creative displayed in aWebView can interact with the host app through exposedbridge objects [19], but an AdSDK can restrict whichbridges are available in its WebViews.In this architecture, WebView instances still share theapplication process with their host app. There are researchproposals such as AdDroid [37] and AdSplit [43] thatimpose stronger privilege separation between the AdSDKexecution environment and the host app. All of the vulnerabilities described in this paper would still be present andexploitable even if the Android OS and AdSDKs deployedAdDroid or AdSplit.Table III describes all methods for loading HTMLcontent into a WebView instance. loadUrl fetches HTMLcontent from a given URL; unless the URL is a file-schemeURI, this content cannot access local files via file-schemeURIs. loadData loads specified HTML content with thedata-scheme origin; access to local files is blocked.loadDataWithBaseURL loads the data string with thegiven baseU rl origin. Unless baseU rl is a file-schemeURI, loaded content and local files have different origins.Nevertheless, the same origin policy (SOP) allows contentfrom one origin to embed content from another origin, including image elements. Therefore, HTML and JavaScriptIV.Inference mechanismsIn this section, we explain the mechanisms that mobileadvertisers can use to infer sensitive information about theusers to whom their ads are shown.A. Attack modelAs explained in Section II-B, we focus on threats frommalicious advertisers, as opposed to malicious apps or abusive advertising libraries. In contrast to attacks that exploitadvertising to entice victims to install malware [29, 48],in our model the attacker’s goal is to collect sensitiveinformation about users.1 Android 5.0 Lollipop does not allow the embedding of local resourcesif baseU rl starts with https://.5

WebView member methodFunctionalityvoid loadUrl (String url)Loads urlvoid loadData (String data, String mimeT ype, String encoding)(String baseU rl, String data, String mimeT ype,void loadDataWithBaseURLString encoding, String historyU rl)Loads data using a data-scheme URLLoads data using baseU rl as its originTABLE III: Methods for loading content into WebViewreturns false.The WebView instance enables setJavascriptEnabled. The WebView instance enables setAllowFileAccess. The WebView instance precedes Android 4.1, orelse the WebView instance enables either setAllowFileAccessFromFileURLs or setAllowUniversalAccessFromFileURLs. (Since Android 4.4 KitKat) The host app has theREAD EXTERNAL STORAGE permission.We found that the AdMarvel AdSDK satisfies theWebView-related conditions even on post-4.1 Android, i.e.,it allows files loaded by ads to access any file on the device.This enables any ad shown in an AdMarvel-supported appto steal local files from external storage.Figure 4 shows a sample exploit. First, the victimdownloads trigger.html to his device by visiting theattacker’s webpage. The victim then opens an ad-supportedapp whose AdSDK, such as AdMarvel, shows ads in aWebView instance that satisfies the above conditions. Thefetched advertising creative embeds an iframe whose srcproperty is the file URI of the downloaded page—see Ln 4in the top section of Figure 4. The attack payload initiatesXMLHttpRequest to local resources, receives byte streamswith the data, and exfiltrates them to the attacker’s domain.Mobile advertisers typically have some control over theselection and number of mobile devices on which their adsare shown. For example, they can bid through differentadvertising networks and specify the user profiles theywish to target. The number of victims is related to thenumber of ads served and the duration of the advertisingcampaign, both of which depend on the attacker’s budget. B. Reading local filesThe attack described in this section depends on theAndroid version and exact AdSDK used to show themalicious ad. Prior to Android 4.1 Jelly Bean, WebViewtreated all file URIs as the same origin (see Section III-C).Since Android 4.1, each file-scheme URI has a separateorigin by default. Nevertheless, AdSDKs can change thisdefault setting of WebView via setAllowFileAccessFromFileURLs or setAllowUniversalAccessFromFileURLs.Neither requires user permission.The attacker first entices the victim to download anHTML page that holds malicious payload. For example,the attacker can set up a webpage that causes Chromeand Firefox mobile browsers to automatically downloadthe malicious file without user’s consent [23].Once the payload page is present on the user’s device,the attacker’s ad invokes the payload by opening thispage within the same WebView where the ad is running.To do this, JavaScript in the ad can create an iframepointing to the downloaded page via a file-scheme URI,or else change window.location to this URI. WebViewcalls shouldOverrideUrlLoading to check whether thehost app has registered a callback to intercept URI loading.If the answer is “false,” WebView loads the payload page;otherwise it delegates the URI to the host app. After the adhas successfully loaded the page, JavaScript in the payloadcan steal any local file that belongs to the same file-schemeorigin and that the host app is allowed to read.The following summarizes the conditions under whicha malicious ad can directly read files from the device’sexternal storage. Victim automatically downloads a malicious payload page by visiting an attacker-controlled website. A mobile app on the victim’s device includes anAdSDK that displays the attacker’s ad. To display the attacker’s ad, AdSDK loads it in aWebView instance using loadDataWithBaseURLwith a scheme other than https:// for baseU rl. There is no shouldOverrideUrlLoading callbackdefined for the WebView instance, or the callbackC. Inferring the existence of local filesWhen an AdSDK uses loadDataWithBaseURL to loadan advertising creative via a scheme other than https://in Android 5.0 or any scheme in pre-5.0 Android, thecreative’s HTML code can embed local files as DOMelements. The origin of the code is baseU RL, the firstargument of loadDataWithBaseURL. All AdSDKs inTable V use null or their own domain names as baseU RL.Therefore, the origin of any advertising code they load isdifferent from the origin of the local files.SOP thus prevents advertising code from reading thecontents of cross-origin resources such as local files, butit does not prevent advertising code from embedding thesefiles as image, audio, or video elements. This is thestandard browser security model, enforced correctly. It iscommon for conventional webpages to include iframes,images, etc. from a different origin (without being ableto read them). In fact, few modern websites would work ifSOP prohibited the embedding of cross-origin resources.This key feature of the Web programming model appears fairly harmless in its original Web context but hasinteresting privacy consequences when translated to the6

Malicious advertising creative123456for mobile advertising, all AdSDKs from Table IIenable setJavascriptEnabled. The WebView instance enables setAllowFileAccess (default is true). (Since Android 4.4 KitKat) The host app has theREAD EXTERNAL STORAGE permission.The local resource oracle exploits a subtle but crucialdifference between the mobile and Web security models.On the Web, public resources can typically be retrieved viacross-origin requests. For sensitive resources, the recipientof a cross-origin request can perform access-control checksor ask the user’s browser to enforce the same origin policyby sending back cross-origin resource sharing (CORS)headers. Local files are cross-origin resources, too, butthere is no entity that can request or perform access-controlchecks. Therefore, Web browsers including Chrome, Firefox, and Safari strictly forbid accessing file resources fromfetched Web pages. On the other hand, embedded browsercomponents such as WebView allow this file access to giveapp developers more flexibility.In contrast to the Web, on mobile devices the mereexistence of a

Mobile advertising helps developers of mobile apps obtain revenue without directly charging users. Therefore, advertising is a key component of the mobile app ecosys-tem. Mobile advertising is typically integrated into mobile apps via an advertising library or SDK (AdSDK), which fetches and displays mobile ads while the app is running.