[PDF](+73👁️) Télécharger DTIC ADA584780: AdDroid: Privilege Separation for Applications and Advertisers in Android pdf

iHJIUf


AdDroid: Privilege Separation for Applications and

Advertisers in Android



Paul Pearce
Adrienne Porter Felt
Gabriel Nunez
David Wagner


Electrical Engineering and Computer Sciences
University of California at Berkeley


Technical Report No. UCB/EECS-2013-59

http://www.eecs.berkeley.edu/Pubs/TechRpts/2013/EECS-2013-59.html

May 14, 2013









Form Approved
OMB No. 0704-0188


Report Documentation Page


Public reporting burden for the collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and
maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information,
including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington
VA 22202-4302. Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to a penalty for failing to comply with a collection of information if it
does not display a currently valid OMB control number.


1. REPORT DATE

14 MAY 2013

2. REPORT TYPE

3. DATES COVERED

00-00-2013 to 00-00-2013

4. TITLE AND SUBTITLE

AdDroid: Privilege Separation for Applications and Advertisers in

Android

5a. CONTRACT NUMBER

5b. GRANT NUMBER

5c. PROGRAM ELEMENT NUMBER

6. AUTHOR(S)

5d. PROJECT NUMBER

5e. TASK NUMBER

5f. WORK UNIT NUMBER

7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES)

University of California at Berkeley,Electrical Engineering and

Computer Sciences,Berkeley,CA,94720

8. PERFORMING ORGANIZATION

REPORT NUMBER

9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES)

10. SPONSOR/MONITOR’S ACRONYM(S)


11. SPONSOR/MONITOR’S REPORT
NUMBER(S)


12. DISTRIBUTION/AVAILABILITY STATEMENT

Approved for public release; distribution unlimited

13. SUPPLEMENTARY NOTES

14. ABSTRACT

Advertising is a critical part of the Android ecosysteml many applications use one or more advertising
services as a source of revenue. To use these services, developers must bundle third-party, binary-only
libraries into their applications. In this model, applications and their adver- tising libraries share
permissions. Advertising-supported applications must request multiple privacy-sensitive per- missions on
behalf of their advertising libraries, and ad- vertising libraries receive access to all of their host appli¬
cations’ other permissions. We conducted a study of the Android Market and found that 49% of Android
applica- tions contain at least one advertising library, and these libraries overprivilege 46% of
advertising-supported appli- cations. Further, we nd that 56% of the applications with advertisements that
request location (34% of all applica- tions) do so only because of advertisements. Such pervasive
overprivileging is a threat to user privacy. We introduce AdDroid, a privilege separated advertising
framework for the Android platform. AdDroid introduces a new adver- tising API and corresponding
advertising permissions for the Android platform. This enables AdDroid to separate privileged advertising
functionality from host applications allowing applications to show advertisements without re- questing
privacy-sensitive permissions.


15. SUBJECT TERMS


16. SECURITY CLASSIFICATION OF:

17. LIMITATION OF
ABSTRACT

18. NUMBER
OF PAGES

19a. NAME OF
RESPONSIBLE PERSON

a. REPORT

unclassified

b. ABSTRACT

unclassified

c. THIS PAGE

unclassified

Same as
Report (SAR)

14


Standard Form 298 (Rev. 8-98)

Prescribed by ANSI Std Z39-18






Copyright © 2013, by the author(s).

All rights reserved.

Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, to
republish, to post on servers or to redistribute to lists, requires prior specific
permission.



AdDroid: Privilege Separation for Applications and

Advertisers in Android


Paul Pearce, Adrienne Porter Felt Gabriel Nunez

Computer Science Division Sandia National Laboratory*

University of California Berkeley gnunez@sandia.gov

{pearce, apf}@cs.berkeley.edu


David Wagner
Computer Science Division
University of California Berkeley
daw@cs.berkeley.edu


ABSTRACT

Advertising is a critical part of the Android ecosystem—
many applications use one or more advertising services as
a source of revenue. To use these services, developers
must bundle third-party, binary-only libraries into their
applications. In this model, applications and their adver¬
tising libraries share permissions. Advertising-supported
applications must request multiple privacy-sensitive per¬
missions on behalf of their advertising libraries, and ad¬
vertising libraries receive access to all of their host appli¬
cations’ other permissions. We conducted a study of the
Android Market and found that 49% of Android applica¬
tions contain at least one advertising library, and these
libraries overprivilege 46% of advertising-supported appli¬
cations. Further, we find that 56% of the applications with
advertisements that request location (34% of all applica¬
tions) do so only because of advertisements. Such pervasive
overprivileging is a threat to user privacy. We introduce
AdDroid , a privilege separated advertising framework for
the Android platform. AdDroid introduces a new adver¬
tising API and corresponding advertising permissions for
the Android platform. This enables AdDroid to separate
privileged advertising functionality from host applications,
allowing applications to show advertisements without re¬
questing privacy-sensitive permissions.

1. INTRODUCTION

The Android Market [2] has given Android developers
an avenue to rapidly develop and distribute applications
directly to consumers. Mobile advertising services such as
AdMob [1] and Millennial Media [22] play a key role in this
ecosystem by allowing developers to generate revenue from
advertisements. These advertisers distribute libraries that
make it easy for applications to request advertisements and
display them in their user interfaces.

Before developers can distribute an Android application,
they must identify and declare what permissions their ap¬
plications need. The installation process shows these per¬
missions to users if they choose to install the application.
However, the Android security model does not provide any
special support for advertisements. This means that there
is no way for the user or the operating system to differen¬
tiate between the permissions necessary for the host appli¬
cation and those needed by advertising libraries. A simple
advertisement-supported application (e.g., a game or cus-

*Work done while at the Computer Science Division, Uni¬
versity of California Berkeley.


tom ringtone application) must request multiple privacy-
sensitive permissions unrelated to its functionality just so
it can display advertisements. Advertising libraries often
require permissions for network connectivity, location in¬
formation, and phone state. 1 Since developers include the
advertising library as part of the application, applications
can use the permissions needed for advertising libraries,
and vice versa. This is an instance of overprivileging : the
advertising libraries require applications to take on addi¬
tional privileges that they otherwise might not need. More¬
over, these additional permissions have serious implications
for user privacy.

The current advertising model results in the following
classes of threats:

• Advertisers may track users without their knowledge.

• Untrusted applications may have access to unneces¬
sary private data, such as the user’s location.

• If an adversary exploits a buggy application, the be-
nign-but-buggy application may inadvertently leak or
expose sensitive information to attack.

• Malicious or opportunistic advertising networks could
abuse the permissions of their host applications.

• Applications frequently requesting sensitive permis¬
sions, or permissions unrelated to the application’s
functionality, can train users to ignore permission
warnings [13].

• Advertising libraries have been observed download¬
ing code over HTTP and dynamically executing it at
runtime [14].

To combat these threats we propose AdDroid , an exten¬
sion of the Android platform that provides special support
for advertisements. In AdDroid, the host application and
the core advertising code run in separate protection do¬
mains. We accomplish this privilege separation by mov¬
ing privileged functionality into a new Android system
service. Application developers may incorporate adver¬
tisements into their application by invoking the AdDroid
advertising application programming interface (API). Ap¬
plications using AdDroid no longer need privacy-sensitive
permissions just to display advertisements.

1 Applications need phone state to obtain the phone’s In¬
ternational Mobile Equipment Identity (IMEI). Developers
can use the IMEI as a unique customer identifier.



? D ill! ■ 11:15


To understand the potential value of AdDroid, we an¬
alyzed a set of 964 real-world Android applications col¬
lected from the Android Market. We found that 49% of
applications contain at least one advertising network li¬
brary. We also found that application developers over¬
privileged 46% of advertising-supported applications (23%
of all applications) by one or more permissions as a di¬
rect result of their use of advertising libraries. Further,
we found that 27% of advertising-supported applications
receive both Internet connectivity and location informa¬
tion, even though the application needs neither for its
functionality. This particular combination of permission
overprivilege is potentially sensitive because it allows ap¬
plications to track a user’s location without their knowl¬
edge. Lastly, we found that 34% of all applications (56%
of advertising-supported applications) that request loca¬
tion do so only because of advertisements. With AdDroid,
27% of advertising-supported applications would no longer
need Internet access, 25% would no longer need location
information, and 8% would no longer need phone state in¬
formation. Overall, AdDroid would reduce overprivileging
in 46% of advertising-supported applications.

Contributions. The contributions of this work include:


| m Apps

Brightest Flashlight F

GOLDENSHORES TECHNOLO...



PERMISSION


Storage

Modify/delete SD card contents y

System tools

Prevent phone from sleeping y


Your location

Coarse (network-based) location, fine
(GPS) location -s


Tap to learn more. citibank'!


* ■ *

Display Settings

0 Camera LED
0 Screen




Figure 1: At left, an application’s requested per¬
missions are shown as part of the installation pro¬
cess. At right, an example of an advertisement (top
of screen) in an application.


• We identify and detail the problem of advertising-
related overprivileging, including a detailed model of
the threats faced by users and developers (Section 2).

• We design and implement AdDroid, a solution to the
threat of advertising overprivilege that applies priv¬
ilege separation to advertising libraries (Sections 3
and 4).

• We measure the threat of advertising overprivilege
and the impact of AdDroid with an advertising and
overprivilege measurement study performed on ap¬
plications from the Android Market (Section 5).

2. BACKGROUND

To frame the problem, we describe the Android permis¬
sion system and explain how mobile advertising currently
works. We then explain how the current system leads to
privacy and security threats from legitimate advertising
networks, gray ware, benign-but-buggy applications, mali¬
cious advertising networks, and vulnerable advertising net¬
works.

2.1 Android Permissions

Android employs an install-time permission system to
alert users to the privacy and security ramifications of in¬
stalling an application. A permission gives an applica¬
tion the ability to perform a specific privacy- or security¬
relevant action. For example, the INTERNET permission
controls communication with remote servers, the REC0RD_-
AUDIO permission provides the ability to record audio with
the microphone, and the ACCESS_FINE_LOCATION permis¬
sion permits access to the phone’s GPS location. An ap¬
plication cannot perform a given operation unless it has
the related permission.

In order to gain permissions, applications must first re¬
quest them. Developers determine (e.g., via testing) the
permissions that their applications require, and then they


bundle their applications with the appropriate list of per¬
mission requests. Different applications request different
sets of permissions, based on their functionality.

The Android installer asks users to grant these permis¬
sion when they install the application. After initiating the
installation process, the system shows the user the list of
permissions that the application requests. Figure 1 shows
a screenshot of the permission authorization process in the
Android Market. The user implicitly accepts the permis¬
sion requests by choosing to complete the installation pro¬
cess. Permission authorization is all-or-nothing; the user
must accept all of the application’s permission requests or
cancel installation. Once installed, these permissions will
be available to the application each time it executes.

2.2 Advertising Libraries

Advertising networks serve as middlemen between ap¬
plication developers and advertisers. The advertising net¬
works supply developers with advertising libraries, and de¬
velopers place the libraries in their applications. The li¬
braries provide APIs for inserting advertisements into the
application’s user interface and handle the fetching, ren¬
dering, and tracking of advertisements. These libraries are
responsible for 65%-75% of energy usage in free applica¬
tions [23].

In Android all parts of an application—including the ad¬
vertising libraries—have the same permissions. This has
two consequences. First, an advertising library can use
all of the permissions that its host application requests.
Second, an application that includes an advertising library
must request all of the permissions that the advertising li¬
brary requires. Figure 2 shows the relationship between
advertising libraries, applications, and the Android per¬
mission system. Android system services perform privi¬
leged operations. Applications access these services via
inter-process communication (IPC), and the system ser¬
vices will only perform operations that applications have
permissions for. While Android system services are able to
perform operations unconstrained by Android application,











Figure 2: Diagram showing how advertising cur¬
rently works in Android. The example application
uses two advertising networks. Each advertising
library access the privileged Android system ser¬
vices via IPC. The Android system does not dis¬
tinguish between different parts of an application.

they do not run as “root.” 2

Certain permissions are commonly associated with ad¬
vertising libraries. Advertising libraries load advertise¬
ments from remote servers, which requires the INTERNET
permission; they may also use the ACCESS_NETWORK_STATE
permission to determine whether the phone has access to
the Internet. To support location-specific advertisements,
applications must request one of the LOCATION permissions
(either GPS or network location). Some advertising net¬
works use the READ_PHONE_STATE permission to obtain the
phone’s IMEI, which can serve as a unique customer iden¬
tifier. Advertising networks publish documentation that
instructs developers to include these permissions in their
lists of required permissions.

2.3 Threat Model

Besides potentially training users to ignore sensitive per¬
mission requests [13], five threats arise from the Android
advertising ecosystem:

• Legitimate advertising networks. Studies suggest that
a majority of users have experienced discomfort shar¬
ing personal information such as location and brows¬
ing history with advertising networks [20, 17, 5]. The
purpose of the Android permission system is to in¬
form users about what personal information they will
share with a third party, but Android users are cur¬
rently unable to tell which permissions advertising li¬
braries use. Consequently, users are unaware of what
information applications or advertising libraries are
sharing with advertising networks and are unable to
object to advertising libraries’ permission requests.
While users can usually identify whether an applica¬
tion contains advertisements, this may only become
apparent after they install and use the application.
More importantly, users can not tell what informa¬
tion (e.g., location) the application is sending to ad¬
vertisers.

• Gray ware. In some situations, users may trust adver¬
tising networks more than the application. For exam¬
ple, consumers might be willing to share their loca¬
tion with Google’s advertising network but not with

2 One can think of the Android system services as running
with the permissions of a traditional Linux process.


unbranded games. Currently, there is no way for a
user to identify what data they give to the untrusted
application versus what data they give to the adver¬
tising network. Consider the case of the unbranded
game requesting location permissions. There is no
way to determine if the game is taking that location
information and using it in some way contrary to the
user’s privacy, or if a reputable advertising network
is using the location to serve location relevant adver¬
tisements.

• Benign-but-buggy applications. The more permissions
a user grants to an application, the more damage it
can do if exploited [25]. If an overprivileged appli¬
cation contains bugs, an attacker could make use of
these additional privileges to track users, exfiltrate
data, and violate user privacy. A buggy application
could also unknowingly leak private information it
had access too.

• Malicious advertising networks. An unscrupulous ad¬
vertising network could supply application develop¬
ers with a malicious library that abuses the permis¬
sions requested by host applications. Although we
are unaware of existing malicious mobile advertising
networks, malware has appeared in the Android Mar¬
ket [11], and malicious advertising partners have col¬
laborated with botnets in other settings [21]. A less
severe variant of this threat is an opportunistic ad¬
vertising library that uses aggressive, borderline-legal
marketing techniques. An example of an opportunis¬
tic threat would be a library that collects users’ phone
contact lists to send spam. Opportunistic advertis¬
ing libraries that check for and use their host appli¬
cations’ permissions have been seen in the wild [14,
27].

• Vulnerable advertising networks. Advertising librar¬
ies have been observed downloading code over HTTP
and executing it [14, 27]. This behavior could turn a
legitimate advertising network into a malicious one if
the user is connected to an unsafe wireless network.

In each of these threats, providing applications and ad¬
vertising libraries with unfettered access to each other’s
permissions poses significant danger.

3. PROPOSAL

We propose to use privilege separation [24] to address
the threats outlined in Section 2. In general, privilege sep¬
aration involves placing the privileged components of the
application in a different protection domain from the rest
of the application, and assigning a different set of permis¬
sions to each domain. In this context, we suggest placing
the privileged parts of the advertising library in a sepa¬
rate protection domain, and assigning it a separate set of
permissions.

We begin by exploring two traditional solutions for privi¬
lege separation: separation within a process and separation
between processes. Then, we explain why these solutions
are inadequate in the context of Android advertising. We
then present an alternative solution, our system AdDroid.





























3.1 Privilege Separation Within A Process

A natural approach is to introduce a finer-grained per¬
mission model, where an application can consist of multiple
protection domains, each with its own code and associated
set of permissions. It is tempting to assign each Java class
to its own protection domain, with all protection domains
running in the same virtual machine and process. This
would let the advertising library exist in the same process
and Java runtime as the rest of the application, but with
different permissions. Under this proposal, method calls
between the library and application remain unchanged be¬
cause they are in the same virtual machine, yet the adver¬
tising library and application have their own permissions.

Unfortunately, there are two technical problems with
this solution. First, some applications include native li¬
braries, which can arbitrarily violate the integrity of the
virtual machine running in the same process [10]. Second,
the Dalvik virtual machine (which executes Android Java
code) does not support isolation between portions of code
within the same virtual machine, which would be neces¬
sary to prevent one part of an application from interfering
with or altering other parts of the application. Java in¬
cludes a reflection library that explicitly allows other code
to violate code encapsulation and integrity running in the
same virtual machine. Consequently, we do not think it
is feasible to separate the privileges of an application and
its advertising library within a Dalvik virtual machine or
process.

3.2 Privilege Separation Between Processes

Another approach is for advertising libraries to exist as
separate, standalone applications. These advertising appli¬
cations would run in separate processes from the user ap¬
plication. When a user installs an application with adver¬
tisements, the user-selected application would install the
appropriate advertising application. User-selected appli¬
cations would either interact with advertising applications
via existing IPC mechanisms, or the Android system would
have to be modified to allow the user-selected and advertis¬
ing applications to share the screen [7]. Advertising appli¬
cations would consist of the current advertising library and
shim code to proxy information to and from the target ap¬
plication. The user-selected and advertising applications
would each run with their own sets of permissions. As
we envision it, user-selected applications would request a
new ADVERTISING permission in order to display advertise¬
ments, and the system would allow advertising applications
to use permissions associated with advertising such as IN¬
TERNET or LOCATION.

Unfortunately, there are numerous hurdles to implement¬
ing this approach on the Android platform, including:

• Users who do not want to look at advertisements
might uninstall the advertising applications. This
would hurt developers and companies that rely on
advertising revenue. Application developers expect
users to “pay” for free (i.e., subsidized) applications
by viewing advertisements.

• The ADVERTISING permission is necessary to warn
users that the selected application transmits data to
an advertising network through an advertising ap¬
plication. However, it would be difficult to enforce
this permission. Once a user or host application


has installed an advertising application on a phone,
other user-selected applications could communicate
with it to load advertisements. Advertising applica¬
tions could refuse to service user-selected applications
that lack the ADVERTISING permission, but this relies
on the advertising applications to enforce the permis¬
sion requirement. Since advertisers have an incentive
to show advertisements to as many applications as
possible, they are incentivized to not enforce these
permissions. The Android Market could refuse to
list advertising applications unless they abide by this
constraint, but this would require periodic audits of
advertising applications.

• The Android platform would need to be extended
to support install-time dependencies between appli¬
cations so that advertisement-supported applications
could list an appropriate advertising application from
their preferred advertising network as a prerequisite.
The platform would also need to support runtime ap¬
plication dependencies. This would require changes
to the Android platform, the Market, and the user
interface for application installation. Such changes
could present unforeseen abuse opportunities. There
is also a potential for reliability and security con¬
cerns if the market must manage separate advertis¬
ing applications for all possible advertising networks.
Each phone would need to maintain copies of the
versions needed by all of the installed applications.
This presents significant logistical obstacles for de¬
ployment.

• The Android Market would need to prevent the dis¬
tribution of impostor advertising networks. An im¬
postor advertising network would collect all of the
information sent to it without paying the developer
and without the privacy policy of a reputable adver¬
tising network.

Consequently, we believe the solution of standalone adver¬
tising applications will not suffice. Therefore we present
a modified and extended IPC approach which leverages
existing infrastructure in the Android platform.

3.3 Our Proposal: AdDroid

We propose AdDroid, a solution which integrates adver¬
tising into the Android platform. In this solution, adver¬
tising networks do not provide advertising libraries at all.
Instead, the Android API is extended to support advertis¬
ing. The extended Android API relays advertising meta¬
data from applications to advertising networks, fetches ad¬
vertisements from advertising networks’ servers, and han¬
dles user interface events. Applications provide the API
with configuration data to identify which advertising net¬
work^) to fetch advertisements from, as well as contextual
information about the advertisement. This modification to
the Android platform introduces a model similar existing
system services, and relies on mechanisms already in the
platform.

We also propose the addition of two new permissions:
ADVERTISING and L0CATI0N_ADVERTISING. Applications
wishing to take advantage of AdDroid would request one
of these permissions, which would give them access to the
new advertising API calls. Advertising-supported applica¬
tions would not need to request additional permissions for




Figure 3: The AdDroid design. Key components
include a userspace AdDroid library that adds ad¬
vertising support to the public API, and a support¬
ing AdDroid system service that communicates
with the advertising network’s Internet servers.

advertising (e.g., LOCATION) because all of the privileged
advertising-related operations would be performed by Ad¬
Droid on behalf of the application. Applications requesting
these permissions will not have unfettered access to In¬
ternet, location, or phone identifying information. These
permissions will only grant them access to parts of the
advertising API.

Figure 3 shows a system overview of AdDroid. The An¬
droid SDK now includes additional advertising-related API
calls which are supported by a new system service. All of
the advertising-related code that does not require special
permissions resides in the Android SDK and does not need
to be trusted by the privileged Android components. Ad¬
vertising functionality that requires permissions (e.g., con¬
necting to the Internet) is implemented in the new service,
which can perform privileged operations. The advertising
system service is only accessible to applications with the
appropriate ADVERTISING or LOCATION_ADVERTISING per¬
missions. In our proposal, all of the advertising-related
code that requires privilege is trusted enough to be part of
a system service because it has been written or reviewed by
the Android development team. Consequently, it is safe for
privileged advertising code to execute as a system service.

This solution mitigates our five threats as follows:

• Legitimate advertising networks. The advertising per¬
missions inform users when applications make use
of advertising. In particular, the L0CATI0N_ADVER-
TISING permission informs users when applications
include location-aware advertisements. Armed with
this information, users can make informed decisions
about which applications to install, given their per¬
sonal privacy preferences.

• Grayware. In AdDroid, applications can include ad¬
vertisements without needing the LOCATION or READ-
_PHONE_STATE permissions. This enables users to dis¬
tinguish between applications that use permissions
for their own purposes and applications that use per¬
missions for advertising. For example, a person con¬
sidering an unbranded game would know that the


game developer is collecting his or her information
for a purpose other than displaying location-aware
advertisements. We expect that our proposal would
significantly reduce the number of applications that
ask for Internet, location, and identity permissions,
which would make the permissions more notable and
therefore more effective. If these applications only
requested the advertising related permissions, they
would have no access to Internet, location, or phone
identification information.

• Benign-but-buggy applications. Since applications no
longer need to request permissions for their advertis¬
ing libraries, many will have fewer permissions. This
means that a buggy application will be less likely to
have Internet, location, or phone state permissions,
thus reducing the impact of any vulnerability or bug
in the application.

• Malicious advertising networks. In our model, ad¬
vertising networks do not provide any code directly
to developers choosing to use AdDroid. As such,
malicious advertising networks would not be able to
leverage application permissions to collect excessive
amounts of user data or perform undesirable opera¬
tions.

• Vulnerable advertising networks. Since applications
would no longer embed advertising libraries in their
applications, advertising libraries cannot introduce
vulnerabilities into applications.

As such, we believe AdDroid addresses the privacy and se¬
curity concerns about advertising identified in Section 2.3.

In addition to improving privacy, AdDroid provides other
benefits. Uniting advertising networks under a common
API would decrease developer overhead, particularly for
applications that use multiple advertising networks. In
turn, this gives advertisers more potential customers, as
every developer would be able to opt-in to advertisements
using a familiar, standardized API. The creation of an AD¬
VERTISING permission also allows the Android Market to
become advertising-aware. The Market could allow users
to sort applications based on whether they include adver¬
tisements. Additionally, the Market could support a fea¬
ture that allows users to switch to the paid version of an
application (e.g., if the user does not like the advertise¬
ments in the free version).

Section 4 discusses the AdDroid implementation in more
depth. Section 5.6 discusses AdDroid’s ability to support
multiple advertising networks further.

3.3.1 Existing Applications and Libraries

AdDroid does not prevent the continued use of the ex¬
isting bundled library model. Applications and advertising
networks that do not use AdDroid simply do not receive
the benefits of the system. Existing applications and ad¬
vertising networks will continue to function normally. In
the long term, we would expect the benefits of AdDroid
and changing user expectations to entice developers to mi¬
grate their applications and advertising libraries.

3.3.2 Limitations

The AdDroid proposal has two drawbacks. First, the
Android development team would need to implement Ad-








































Droid and incorporate the functionality of existing adver¬
tising libraries into the Android API. However, we show in
Section 5.6 that advertising functionality is relatively sim¬
ple to support. Second, existing advertising networks are
currently able to declare and update their APIs at their
own pace, independent from Android release cycles. Un¬
der AdDroid, advertising networks would be constrained
by the advertising support in the Android SDK. For small
configuration changes, such as adding new advertising net¬
works to AdDroid, the Android Market could disseminate
signed configuration update files that describe advertis¬
ing networks’ web service APIs. However, larger changes
to advertising networks might require platform updates.
Since AdDroid does not preclude the use of the existing
model, advertisers or developers unhappy with these lim¬
itations can simply not use the system. The AdDroid so¬
lution is less agile than traditional models, but we believe
the security gains and ecosystem advantages outweigh the
loss of flexibility.

4. IMPLEMENTATION

We implemented our AdDroid proposal to illustrate its
details and demonstrate its feasibility. AdDroid consists
of three parts: a userspace library that is part of the An¬
droid SDK, a new Android system service, and Android
permissions. Our proof-of-concept implementation of the
AdDroid prototype integrates these three components into
the Android Open Source Project, version 2.3.3 (Ginger¬
bread).

4.1 AdDroid Library API

The AdDroid userspace library provides developers with
a public API, i.e., the classes and methods that developers
invoke when writing applications. It supports the insertion
of advertisements into applications’ user interfaces and re¬
lays data between the application and the AdDroid system
service. The library includes a new user interface element
to display advertisements (an “AdView”), callback listen¬
ers, and support for a wide range of user tracking data. 3

After surveying various advertising networks, we based
the design of the API on the AdMob advertising SDK.
AdMob is well-designed and supports most of the features
of other advertising networks. Starting with the AdMob
API, we made changes to generalize the API and extend
it to other advertising networks. The AdDroid library al¬
lows developers to specify which advertising networks they
would like to use, and allows use of multiple advertising
networks in one application. A separate advertising net¬
work can be specified for each AdView, providing great
flexibility. The AdDroid API is the same for all appli¬
cations, regardless of which advertising network they use.
Appendix A contains detailed description of the AdDroid
API and sample usage.

Since the AdDroid library exists in userspace, it runs
with the host application’s permissions. We do not make
any assumptions about what permissions the host appli¬
cation has. Furthermore, a grayware application could ar¬
bitrarily tamper with the userspace library. Consequently,

3 Applications often ask users for information such as their
gender, which they then share with advertising networks.
This data is distinct from the user data stored by the op¬
erating system.


the AdDroid library does not perform any privileged oper¬
ations. Whenever an application requests a new advertise¬
ment, the library makes a f etchAd IPC call to the AdDroid
system service which in turn performs the necessary privi¬
leged operations. Although the AdDroid userspace library
does not perform any privileged operations, it contains the
majority of the advertising functionality.

When a user clicks on an advertisement an OnClick-
Listener is invoked, spawning a web browser directed to
the advertisement’s target URL. This action is how adver¬
tising services and applications track advertisement clicks.
Launching a web browser is only one of several possible
desired actions. Other behaviors can be added as needed
by advertisers.

4.2 AdDroid System Service

The AdDroid system service runs with other Android
system services as part of the Android system service pro¬
cess. This service’s only job is to receive advertising re¬
quests from applications via the AdDroid userspace library
and return advertisements. When the AdDroid system ser¬
vice receives an advertisement request, it establishes a net¬
work connection to the appropriate advertising network,
transmits data to the advertising network, and stores the
resulting advertisement. The AdDroid library then makes
a follow-up IPC call to the AdDroid system service to re¬
trieve the advertisement.

The data sent to the advertising network during the
transaction might include configuration information (e.g.,
the application’s customer number or the size of the re¬
quested advertisement), tracking data collected by the ap¬
plication, or advertising context-specific information spec¬
ified by the application. If the application has the LOCA¬
TION. ADVERTISING permission, then the advertising net¬
work will also receive the phone’s current location. Some
advertising networks also request the phone’s unique iden¬
tifier. Our current prototype sends the telephony ID (i.e.,
IMEI, MEID, or ESN), but a full implementation could
supply advertising networks with an alternate identifier.
Alternatives include the ANDROID.ID (a unique ID that
is not tied to the carrier), the android, os .Build. SERIAL
field, or another identifier that is application-specific rather
than device-wide.

4.3 Android Permission Changes

Applications should only be able to fetch ads through
the AdDroid system service if they have the ADVERTISING
or LOCATION.ADVERTISING permissions. To enforce this re¬
striction, the AdDroid service verifies its caller’s permis¬
sions. The ability to verify caller permissions from within
Android services is part of the core Android security model,
which we leverage.

We protect the fetchAd IPC call with our new adver¬
tising permissions. The ADVERTISING permission gives ap¬
plications the ability to call fetchAds and request generic
advertisements based on data supplied by the application.
When applications use LOCATION.ADVERTISING in addition
to ADVERTISING, applications may request that fetchAds
sends location information to the advertisers as well. Fig¬
ure 4 shows how the permissions appear to users during
installation of our prototype. 4 Screenshots are provided
for illustrative purposes; UI design is beyond the scope of

4 These screenshots show the installation screen for manual




*?* D illl i 12:35 I


(P Hello, Ad World!


Do you want to install this
application?


Allow this application to:

✓ Advertising

Retrieve ads from ad networks, Transmit
your location to ad networks


Figure 4: Installation screens of two applications
requesting the new AdDroid permissions. The
text of these permissions is for illustrative purposes
only. Designing effective warnings is an open re¬
search problem [13].


this paper. Designing effective permission warnings that
correctly convey security information to users is a problem
in itself [13]. We leave it as an interesting open problem
for usability experts how best to communicate this infor¬
mation to users.

4.4 Code Size

We found that AdDroid required relatively few modifica¬
tions to the existing Android Open Source Project, version
2.3.3. The AdDroid userspace library required 560 new
source lines of code including blank lines and comments
(SLoC), and the new Android system service required 255
SLoC. Additionally, we modified or added 66 SLoC to the
existing system to add support for the framework, system
service, and new permissions. We flashed and tested the
system on a GSM Samsung Nexus S unlocked consumer
phone.

5. MEASUREMENT STUDY AND
ADDROID EVALUATION

We analyzed a set of 964 Android applications to evalu¬
ate the real-world impact of AdDroid on applications and
advertising. We performed a static permission analysis
on the applications to determine the permissions used by
the host applications and their libraries; Section 5.1 ex¬
plains our methodology and Section 5.2 describes our data
set. We then present results on how often applications re¬
quest permissions solely for advertising (Section 5.3) and
how many advertising libraries have access to dangerous
permissions that are not necessary for advertising (Sec¬
tion 5.4). AdDroid would remove all of the overprivilege
identified by this measurement study. In Section 5.5 we
investigate the permissions commonly used by advertisers.
In Section 5.6, we discuss how difficult it would be for de-

installation, rather than for an installation from the An¬
droid Market. This is because we did not want to place an
application in the Android Market solely for these screen-
shots.


velopers to switch to AdDroid.

5.1 Methodology

We used Stowaway [10] to perform a permission anal¬
ysis of 964 real-world applications and their advertising
libraries. Our set of applications consisted of the 764 most
popular free applications, the 100 most popular paid appli¬
cations, and the 100 most recently added or updated free
applications from the official Android Market in October
2010.

The first step of our measurement study was to split each
application into two parts: the application itself, and any
advertising libraries packaged with the application. We
disassembled applications using Dedexer [6] and then used
namespaces to separate advertising-related code and XML
hies from the main application. For example, code in the
com. admob. android. ads namespace belongs to the AdMob
advertising library. We focused our study on applications
that contained advertising libraries. Next, we ran Stow¬
away on the applications and their affiliated advertising
libraries, which resulted in a list of permissions used by
each application and its advertising libraries.

Stowaway’s permission analysis can be imprecise. Dead
code (i.e., code that will not run during normal execu¬
tion) can cause Stowaway to falsely report that an appli¬
cation uses a permission, or Java reflection can cause it
to falsely report that an application does not use a per¬
mission. To validate Stowaway’s results, we manually re¬
viewed 25 applications’ use of the INTERNET permission.
We randomly selected 25 applications from the set of top
free applications with advertising libraries. We manually
exercised their user interfaces in an emulator while record¬
ing all network communication with Wireshark. Using the
Wireshark traces, we determined whether the applications
use the Internet to communicate with advertisers, other
parties, or both.

5.2 Data Set Characteristics

473 of the 964 applications (49%) contain libraries from
at least one advertising network. We found advertising li¬
braries from nine advertising networks in the 473 applica¬
tions: AdMob, AdSense, AdWhirl, Flurry, Medialets, Mil¬
lennial Media, MobClix, Quattro Wireless, and ZestAdz.
Our data set includes multiple versions of each advertis¬
ing library because developers do not always update their
applications to include the latest versions. Some applica¬
tions use multiple advertising libraries. Table 1 shows the
popularity of each advertising network and the distribu¬
tion of advertisements across free and paid applications.
Unsurprisingly, free applications are more likely to contain
advertising libraries: 16% of the top paid applications in¬
clude advertising libraries, compared to 50% of the top free
applications and 72% of th
Lire la suite

• Taille
  648.21 KB
• Nombre de pages
  15