Smartphone operating systems warn users when third-party applications try to access sensitive functions or data. However, all of the major smartphone platforms warn users about different application actions. To our knowledge, their selection of warnings was not grounded in user research; past research on mobile privacy has focused exclusively on the risks pertained to sharing location. To expand the scope of smartphone security and privacy research, we surveyed 3,115 smartphone users about 99 risks associated with 54 smartphone privileges. We asked participants to rate how upset they would be if given risks occurred and used this data to rank risks by levels of user concern. We then asked 41 smartphone users to discuss the risks in their own words; their responses confirmed that people find the lowest-ranked risks merely annoying but might seek legal or financial retribution for the highest-ranked risks. In order to determine the relative frequency of risks, we also surveyed the 3,115 users about experiences with "misbehaving" applications. Our ranking and frequency data can be used to guide the selection of warnings on smartphone platforms.

[hide abstract]

Android and Facebook provide third-party applications with access to users' private data and the ability to perform potentially sensitive operations (e.g., post to a user's wall or place phone calls). As a security measure, these platforms restrict applications' privileges with permission systems: users must approve the permissions requested by applications before the applications can make privacy- or security-relevant API calls. However, recent studies have shown that users often do not understand permission requests and lack a notion of typicality of requests. As a first step towards simplifying permission systems, we cluster a corpus of 188,389 Android applications and 27,029 Facebook applications to find patterns in permission requests. Using a method for Boolean matrix factorization for finding overlapping clusters, we find that Facebook permission requests follow a clear structure that exhibits high stability when fitted with only five clusters, whereas Android applications demonstrate more complex permission requests. We also find that low-reputation applications often deviate from the permission request patterns that we identified for high-reputation applications suggesting that permission request patterns are indicative for user satisfaction or application quality.

[hide abstract]

Application platforms provide third-party applications with access to hardware (e.g., GPS and cameras) and personal data. Many platforms use permission systems to protect access to these resources. The nature of these permission systems vary widely across platforms. Some platforms obtain user consent as part of installation, while others display runtime consent dialogs. We propose a set of guidelines to aid platform designers in determining the most appropriate permission-granting mechanism for a given permission. We apply our proposal to a smartphone platform. A preliminary evaluation indicates that our model will reduce the number of warnings presented to users, thereby reducing habituation effects.

[hide abstract]

Vulnerabilities in browser extensions put users at risk by providing a way for website and network attackers to gain access to users' private data and credentials. Extensions can also introduce vulnerabilities into the websites that they modify. In 2009, Google Chrome introduced a new extension platform with several features intended to prevent and mitigate extension vulnerabilities: strong isolation between websites and extensions, privilege separation within an extension, and an extension permission system. We performed a security review of 100 Chrome extensions and found 70 vulnerabilities across 40 extensions. Given these vulnerabilities, we evaluate how well each of the security mechanisms defends against extension vulnerabilities. We find that the mechanisms mostly succeed at preventing web attacks, but new security mechanisms are needed to protect users from network attacks on extensions, website metadata attacks on extensions, and vulnerabilities that extensions add to websites. We propose and evaluate additional defenses, and we conclude that banning HTTP scripts and inline scripts would prevent 47 of the 50 most severe vulnerabilities with only modest impact on developers.

[hide abstract]

Android's permission system is intended to inform users about the risks of installing applications. When a user installs an application, he or she has the opportunity to review the application's permission requests and cancel the installation if the permissions are excessive or objectionable. We examine whether the Android permission system is effective at warning users. In particular, we evaluate whether Android users pay attention to, understand, and act on permission information during installation. We performed two usability studies: an Internet survey of 308 Android users, and a laboratory study where we interviewed and observed 25 Android users. Study participants displayed low attention and comprehension rates: both the Internet survey and laboratory study found that 17% of people paid attention to permissions during installation, and only 3% of Internet survey respondents could correctly answer all three permission comprehension questions. This indicates that current Android permission warnings do not help most users make correct security decisions. However, a notable minority of users demonstrated both awareness of permission warnings and reasonable rates of comprehension. We present recommendations for improving user attention and comprehension, as well as identify open challenges.

[hide abstract]

In order to direct and build an effective, secure mobile ecosystem, we must first understand user attitudes toward security and privacy for smartphones and how they may differ from attitudes toward more traditional computing systems. What are users' comfort levels in performing different tasks? How do users select applications? What are their overall perceptions of the platform? This understanding will help inform the design of more secure smartphones that will enable users to safely and confidently benefit from the potential and convenience offered by mobile platforms. To gain insight into user perceptions of smartphone security and installation habits, we conduct a user study involving 60 smartphone users. First, we interview users about their willingness to perform certain tasks on their smartphones to test the hypothesis that people currently avoid using their phones due to privacy and security concerns. Second, we analyze why and how they select applications, which provides information about how users decide to trust applications. Based on our findings, we present recommendations and opportunities for services that will help users safely and confidently use mobile applications and platforms.

[hide abstract]

Under certain circumstances, consumers are willing to pay a premium for privacy. We explore how choice architecture affects smartphone users' stated willingness to install applications that request varying permissions. We performed two experiments to gauge smartphone users' stated willingness to pay premiums to limit their personal information exposure when installing new applications. We found that when participants were comparison shopping between multiple applications that performed similar functionality, a quarter of our sample responded that they were willing top ay a $1.50 premium for the application that requested the fewest permissions - though only when viewing the requested permissions of each application side-by-side. In a second experiment, we more closely simulated the user experience by asking them to valuate a single application that featured multiple sets of permissions based on five between-subjects conditions. In this scenario, the requested permissions had a much smaller impact on participants' responses. Our results suggest that many smartphone users are concerned with their privacy that are less likely to request access to personal information. We propose improvements in choice architecture for smartphone application markets that could result in decreased satisficing and increased rational behavior.

[hide 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 advertising libraries share permissions. Advertising-supported applications must request multiple privacy-sensitive permissions on behalf of their advertising libraries, and advertising libraries receive access to all of their host applications' other permissions. We conducted a study of the Android Market and found that 49% of Android applications contain at least one advertising library, and these libraries overprivilege 46% of advertising-supported applications. Further, we find that 56% of the applications with advertisements that request location (34% of all applications) 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 advertising 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 requesting privacy-sensitive permissions.

[hide abstract]

Android provides third-party applications with an extensive API that includes access to phone hardware, settings, and user data. Access to privacy- and security-relevant parts of the API is controlled with an install-time application permission system. We study Android applications to determine whether Android developers follow least privilege with their permission requests. We built Stowaway, a tool that detects overprivilege in compiled Android applications. Stowaway determines the set of API calls that an application uses and then maps those API calls to permissions. We used automated testing tools on the Android API in order to build the permission map that is necessary for detecting overprivilege. We apply Stowaway to a set of 940 applications and find that about one-third are overprivileged. We investigate the causes of overprivilege and find evidence that developers are trying to follow least privilege but sometimes fail due to insufficient API documentation.

[hide abstract]

Mobile malware is rapidly becoming a serious threat. In this paper, we survey the current state of mobile malware in the wild. We analyze the incentives behind 46 pieces of iOS, Android, and Symbian malware that spread in the wild from 2009 to 2011. We also use this data set to evaluate the effectiveness of techniques for preventing and identifying mobile malware. After observing that 4 pieces of malware use root exploits to mount sophisticated attacks on Android phones, we also examine the incentives that cause non-malicious smartphone tinkerers to publish root exploits and survey the availability of root exploits.

[hide abstract]

Modern browsers and smartphone operating systems treat applications as mutually untrusting, potentially malicious principals. Applications are (1) isolated except for explicit IPC or inter-application communication channels and (2) unprivileged by default, requiring user permission for additional privileges. Although inter-application communication supports useful collaboration, it also introduces the risk of permission re-delegation. Permission re-delegation occurs when an application with permissions performs a privileged task for an application without permissions. This undermines the requirement that the user approve each application's access to privileged devices and data. We discuss permission re-delegation and demonstrate its risk by launching real-world attacks on Android system applications; several of the vulnerabilities have been confirmed as bugs.

We discuss possible ways to address permission re-delegation and present IPC Inspection, a new OS mechanism for defending against permission re-delegation. IPC Inspection prevents opportunities for permission re-delegation by reducing an application's permissions after it receives communication from a less privileged application. We have implemented IPC Inspection for a browser and Android, and we show that it prevents the attacks we found in the Android system applications.

[hide abstract]

Traditional user-based permission systems assign the user's full privileges to all applications. Modern platforms are transitioning to a new model, in which each application has a different set of permissions based on its requirements. Application permissions offer several advantages over traditional user-based permissions, but these benefits rely on the assumption that applications generally require less than full privileges. We explore whether that assumption is realistic, which provides insight into the value of application permissions.

We perform case studies on two platforms with application permissions, the Google Chrome extension system and the Android OS. We collect the permission requirements of a large set of Google Chrome extensions and Android applications. From this data, we evaluate whether application permissions are effective at protecting users. Our results indicate that application permissions can have a positive impact on system security when applications' permission requirements are declared up-front by the developer, but can be improved.

[hide abstract]

Modern smartphone operating systems support the development of third-party applications with open system APIs. In addition to an open API, the Android operating system also provides a rich inter-application message passing system. This encourages inter-application collaboration and reduces developer burden by facilitating component reuse. Unfortunately, message passing is also an application attack surface. The content of messages can be sniffed, modified, stolen, or replaced, which can compromise user privacy. Also, a malicious application can inject forged or otherwise malicious messages, which can lead to breaches of user data and violate application security policies.

We examine Android application interaction and identify security risks in application components. We provide a tool, ComDroid, that detects application communication vulnerabilities. ComDroid can be used by developers to analyze their own applications before release, by application reviewers to analyze applications in the Android Market, and by end users. We analyzed 20 applications with the help of ComDroid and found 34 exploitable vulnerabilities; 12 of the 20 applications have at least one vulnerability.

[hide abstract]

We assess the risk of phishing on mobile platforms. Mobile operating systems and browsers lack secure application identity indicators, so the user cannot always identify whether a link has taken her to the expected application. We conduct a systematic analysis of ways in which mobile applications and web sites link to each other. To evaluate the risk, we study 85 web sites and 100 mobile applications and discover that web sites and applications regularly ask users to type their passwords into contexts that are vulnerable to spoofing. Our implementation of sample phishing attacks on the Android and iOS platforms demonstrates that attackers can spoof legitimate applications with high accuracy, suggesting that the risk of phishing attacks on mobile platforms is greater than has previously been appreciated.

[hide abstract]

Database-backed applications typically grant complete database access to every part of the application. In this scenario, a flaw in one module can expose data that the module never uses for legitimate purposes. Drawing parallels to traditional privilege separation, we argue that database data should be subject to limitations such that each section of code receives access to only the data it needs. We call this data separation. Data separation defends against SQL-based errors including buggy queries and SQL injection attacks and facilitates code review, since a module's policy makes the extent of its database access explicit to programmers and code reviewers. We construct a system called Diesel, which implements data separation by intercepting database queries and applying modules' restrictions to the queries. We evaluate Diesel on three widely-used applications: Drupal, JForum, and WordPress.

[hide abstract]

Browsers do not currently support the secure sharing of JavaScript objects between principals. We present this problem as the need for object views, which are consistent and controllable versions of objects. Multiple views can be made for the same object and customized for the recipients. We implement object views with a JavaScript library that wraps shared objects and interposes on all access attempts. The security challenge is to fully mediate access to objects shared through a view and prevent privilege escalation. We discuss how object views can be deployed in two settings: same-origin sharing with rewriting-based JavaScript isolation systems like Google Caja, and inter-origin sharing between browser frames over a message-passing channel.

To facilitate simple document sharing, we build a policy system for declaratively defining policies for document object views. Notably, our document policy system makes it possible to hide elements without breaking document structure invariants. Developers can control the fine-grained behavior of object views with an aspect system that accepts programmatic policies.

[hide abstract]

Browser extensions are remarkably popular, with one in three Firefox users running at least one extension. Although well-intentioned, extension developers are often not security experts and write buggy code that can be exploited by malicious web site operators. In the Firefox extension system, these exploits are dangerous because extensions run with the user's full privileges and can read and write arbitrary files and launch new processes. In this paper, we analyze 25 popular Firefox extensions and find that 88% of these extensions need less than the full set of available privileges. Additionally, we find that 76% of these extensions use unnecessarily powerful APIs, making it difficult to reduce their privileges. We propose a new browser extension system that improves security by using least privilege, privilege separation, and strong isolation. Our system limits the misdeeds an attacker can perform through an extension vulnerability. Our design has been adopted as the Google Chrome extension system.

[hide abstract]

Social networking APIs integrate third-party content into the site and give third-party developers access to user data. These open interfaces enable popular site enhancements but pose serious privacy risks by exposing user data to third-party developers. We address the privacy risks associated with social networking APIs by presenting a privacy-by-proxy design for a privacy-preserving API that is motivated by an analysis of the data needs and uses of Facebook applications. Our study of 150 popular Facebook applications reveals that nearly all applications could maintain their functionality using a limited interface that only provides access to an anonymized social graph and placeholders for user data. Since the platform host can control the third party applications' output, privacy-by-proxy can be accomplished without major changes to the platform architecture or applications by using new tags and data transformations.

[hide abstract]

Social networks have begun supporting external content integration with platforms like OpenSocial and the Facebook API. These platforms let users install third-party applications and are a popular example of a mash- up. Content integration is often accomplished by proxying the third-party content or importing third-party scripts. However, these methods introduce serious risks of user impersonation and data exposure. Modern browsers provide no mechanism to differentiate between trusted and untrusted embedded content. As a result, content providers are forced to trust third-party scripts or ensure user safety by means of server-side code sanitization. We demonstrate the difficulties of server-side code filtering - and the ramifications of its failure - with an example from the Facebook Platform. We then propose browser modifications that would distinguish between trusted and untrusted content and enforce their separation.

[hide abstract]