The Usability of Android Permissions

I recently ran two user studies to determine the effectiveness of Android permissions in practice. Our results are now available as a technical report: Android Permissions: Attention, Comprehension, Behavior. Android permissions are supposed to inform users of the risks of using applications. However, researchers have speculated that users ignore them. We decided to establish how well they actually work.

Here are our primary findings:

  • Attention. In both a self-reported Internet survey and observational laboratory study, 17% of participants paid attention during a given installation. 42% of laboratory study participants were completely unaware of permissions.
  • Comprehension. Only 3% of Internet survey respondents could correctly answer three multiple-choice comprehension questions. No lab study participants could correctly describe all of the permissions of familiar apps.
  • Behavior. A majority of Internet survey respondents and 20% of lab study participants say they have decided not to install an app in the past because of its permissions.

We categorized 20% of the lab study participants as “power users”: they sometimes look at permissions and scored reasonably well on our comprehension test. It’s possible that a small fraction of “power users” could write negative reviews when they encounter troubling permission requests, thereby protecting other users.

Our studies identified several factors that contribute to the low attention and comprehension rates. Here are two of them: Continue reading

Comments: Leave a comment
Categories: Mobile security, Usability

Give Me Your Best Guess

If you had to guess:

  1. What percentage of Android users know about permissions?
  2. What percentage of Android users look at permissions during installation?

This is a serious, non-rhetorical question. Please leave your guesses as comments.

Update: Interesting! I was curious about whether anyone actually had faith that the permission system works well. (It looks like the answer is no.)

Comments: 11 Comments
Categories: Mobile security, Usability

Research Methods: Pre-Testing A Survey With A Focus Group

Today, I tried out a new survey pre-test technique: a focus group. In the past, I’ve relied solely on individual feedback and pilot studies. It was a fantastic experience, and the feedback was much more detailed than what I have been able to get from one-on-one interviews and pilot studies.

Recruitment
I placed advertisements on Craigslist soliciting participants for the discussion. I offered $30 per person for an hour. About thirty people responded within a few hours, and I selected nine people who represented a diverse age range.

Format
After they signed consent forms, participants took the survey on their laptops. I gave each participant a notepad and asked them to take notes. Next, I kicked off the discussion with a round-robin ice breaker activity. The ice-breaker was effective at getting people comfortable. We then discussed each of the survey questions in order, with the survey projected at the front of the room. For each question, I asked: “Do you understand the terms used in the question?”, “Were you able to answer the question?”, “Are the options sufficient to express your opinion?”, “Was there anything else that you disliked about the question?” As necessary, I tailored each of these discussion points to the survey question that we were discussing.

Benefits of the focus group

  • The major benefit of a group discussion is that some people will bring up points that resonate with others, triggering additional comments that would not have come about in a one-on-one conversation. For example, one person said, “I don’t like X because of Y.” Another person replied, “It seemed strange to me, too, but I didn’t know why. You’re right. I really wish that it said Z instead.”
  • There were also several occasions where the participants disagreed. It was valuable for me to see both perspectives at once.
  • In one-on-one interviews, shy interviewees will answer questions monosyllabically or not at all. This is awkward in a one-on-one setting. In the focus group, it’s easy to ask, “Jane, I saw you shaking your head a little. What do you think of what Bob said?”

Continue reading

Comments: Leave a comment
Categories: Usability

Behavioral Advertising on TV

NBC takes on the topic of Internet privacy with this clip from Parks and Recreation.

“So it learns information about me? Seems like an invasion of privacy.”
“Dude, if you think that’s bad, go to Google Earth and type in your address.”

Comments: Leave a comment
Categories: Web security

When Apps Do Bad Things

Researchers have been working on tools (like AppFence) to help users control how their personal information is used by applications. Recently, some colleagues and I asked 25 Android users to tell us about their bad experiences with applications, to provide insight into whether there is real user demand for more control over how applications access and use their personal information.

We asked, “Have you ever uninstalled (or stopped using) an application because you didn’t like what it was doing with your personal information?” 6 of 25 people said yes:

  • Spam. Three people said that they’d uninstalled apps that sent them spam and/or used their accounts to send spam to others. For example, one person reported that an application had misused her Twitter account: “I logged on and it was posting crazy stuff like, ‘Oh! I just won $1000 while doing this or something’ … And I’m like, that definitely wasn’t me, it was the app.”
  • Social privacy. One person said that she didn’t like how an application shared information about her on Facebook. “I went on [app name] to buy tickets and if you went on Facebook you could see who bought tickets where and what their names are. So I chose not to buy tickets on [app name] because I didn’t want anyone to see where I sat if they went on to Facebook.”
  • Programming errors. Two people said that they had used applications with logic errors that affected their personal information. For example, “But what it did was, if I sent a text message to one person, it would send it to everyone in my list.”
  • General privacy. One person read a Wall Street Journal article that listed applications that share user data with other parties like advertising networks. “…I went through my phone and went through that list, and got rid of all of them except for one. … Shazam was the only one I kept, because the functionality. I know people are taking my stuff but functionality-wise I need that.”

Two other users said that they would uninstall applications if the applications misused their personal information, but they had no way of knowing how their data was being used.

Comments: 3 Comments
Categories: Mobile security, Usability

Advertising and Android Permissions

Recently, I had the opportunity to sit down and chat with a few Android users who aren’t computer scientists. One of the things that we talked about was advertising.  If a person mentioned using an app with ads, I asked, “Do you think the advertiser can use the app’s permissions?”  Twelve people answered this question:

  • Yes: 5
  • No: 2
  • I don’t know: 5

People were right to be confused by the question.  The correct answer is complex (check out the last paragraph of this blog post).  However, I wasn’t trying to test people.  Instead, I wanted to get a general sense of what people think the relationship is between ads, applications, and permissions.

Some people didn’t think the advertiser should get permissions:

  • “I gave these permissions to [app name]. No permissions to the ad.”
  • “They can have advertisements like TV has advertisements, a million people’s phones can have advertisements, but they shouldn’t have access to your phone just cause they have advertisements on them.  They shouldn’t get a permission at all.”
  • “I guess it’s possible, depending on their relationship with whoever made the app. But I couldn’t imagine why they would have permissions that would go through my phone state and identity. … I hope not.”

On the other hand, some people said that they think it’s reasonable for advertisers to get access to information about them via permissions:

  • “I’ve read that advertisers are sending people things on mobile devices based on, like– you might be near some store, so you might get something that pops up on your phone that says, ‘We’re giving a two for one deal today in the next two hours,’ or so.”
  • “They probably get at least location-based so they know where people are accessing it and where they’re downloading it from, how they’re getting to their ads most likely.”
  • “The advertisers could use what I look up on the Internet to better, I guess, suit the ads that they put in for my specific [ads]. When I’m searching for things if it has access to what I look for on the Internet, it could find and put ads that are similar to interests I’ve looked up on the Internet to my phone.”

These are just simple anecdotes, but I find them interesting.

It’s hard to gauge how people feel about advertising and permissions because they don’t understand Android permissions to begin with. For example, the person who mentioned Internet search history made that statement because he misunderstood an unrelated permission that does not give access to Internet search history.

Can an advertiser use an app’s permissions?
When you see an advertisement in an application, there are three parties.  First, there’s the application itself, which asks the user for permissions.  Second, there’s the advertising library, which is shoved into the application and therefore gains access to all of the app’s permissions.  Third, the advertising library displays the advertisement itself.  The advertisement can’t directly use any of the permissions, but the advertising library might share information with the company that is running the ad.  So if you see an REI ad while playing a game, you should know that the invisible ad library gets all of the game’s permissions, and it might share information like your location with REI.

P.S. Thanks to Elizabeth Ha, Serge Egelman, Ariel Haney, and Erika Chin, who interviewed users with me.

Comments: 2 Comments
Categories: Mobile security, Usability

Android vs iOS

Android malware has managed to sneak into the official Android Market for a few months at a time, but Apple’s review process has (thus far) prevented any iOS malware from entering the Apple App Store.

When I tell people this, I commonly get two questions:

  1. Does that mean iOS is better than Android?
  2. Should Google start reviewing all Android apps?

My answer is that security is only one part of the mobile application ecosystem. Apple’s reviewers filter out malware, but they also censor application developers for other reasons. If you are a security-conscious user who downloads lots of apps, then maybe iOS is “better” for you. If you want apps that let you tether your phone or view adult content, then maybe Android is “better” for you.

Regardless of one’s opinion about the tradeoff between security and freedom of development, I predict that problems with the app review process will arise in the next few years. App markets are growing rapidly, and the review process is slow and human-intensive. I don’t see how it can keep scaling up. For example: neither Apple nor Google could manually review the entire Internet. I think the security community needs to find better, automated ways to address the problem of mobile malware — but this will be hard to do until there is more mobile malware out there to study.

Comments: Leave a comment
Categories: Mobile security

Fortify Adds Android Permission Support

Erika Chin and I have been working with Fortify’s Security Research Group to integrate Android permission warnings into Fortify SCA. Specifically, Fortify SCA now warns Android developers when permissions are missing or unnecessary (i.e., when an application is over- or under-privileged). Here’s an excerpt from the Q4 release notes:

Google Android – Updated support now provides improved detection of underprivileged Android applications, including missing permissions for privileged API calls, as well as sending and receiving intents. In addition, Fortify now detects overprivileged Android applications that request unnecessary permissions. This update introduces three new categories related to privilege management.

Hopefully this will help developers avoid permission errors.

For those of you looking for a free alternative, Stowaway can tell you if your application has extra permissions. Stowaway has the advantage of working on binaries (i.e., libraries), but it doesn’t warn developers about missing permissions (which Fortify SCA does).

Comments: Leave a comment
Categories: Developer tips, Mobile security

Android Intent Vulnerabilities

A few months ago, Erika Chin and I manually reviewed 20 popular Android apps.  We found that 9 of the 20 (45%) have security vulnerabilities because of how they use Android’s message-passing system (known as “Intents”). I’m mentioning this now because I hope that Web Intents/Activities can be designed to help developers avoid these errors. Here are two example Intent vulnerabilities, excerpted from our MobiSys paper:

ICE: In Case of Emergency
“ICE: In Case of Emergency” is an application that can be launched from a locked screen by a paramedic in case of an emergency. It stores medical information such as medications, allergies, medical conditions, insurance information, and emergency contact information. ICE contains multiple exploitable Broadcast Receivers. One of their Broadcast Receivers can be used to exit any running application and lock the screen. Several of ICE’s Broadcast Receivers will temporarily remove the ICE widget from the locked screen, rendering ICE unusable.

ICE’s vulnerable Broadcast Receivers are accidentally public due to developer confusion over Android’s complexities. Two of ICE’s Receivers are registered to receive protected system broadcasts, which causes Android to make them public. ICE does not check that the received Intent has the appropriate system action, so an explicit Intent to the Receiver will trigger the same behavior as if the OS had sent the Intent. For example, ICE disappears when the operating system broadcasts an Intent with the BOOT_COMPLETED action; a malicious application could send an explicit Intent with this action to ICE and fool it into exiting. Additionally, some of ICE’s Receivers use broadcasts to pass internal noti- fications. The internal broadcasts have application-specific actions, e.g., com.appventive.ice.unlock_finished. This is a misuse of action strings. These components should be made private and invoked explicitly.

Nationwide Bus
Nationwide Bus is an Android application that gives bus location and arrival information for Korean cities. It uses public broadcasts for internal communication. The broadcasts are used to update map and bus state. One component fetches bus information from the server and then broadcasts the data, which is intended for an internal Receiver. This is a privacy violation if the user does not want other applications to know his or her location.

Two exported components expect bus data as input. A Receiver listens for the aforementioned broadcasts, and a Service in charge of bus arrivals is started with bus data. A malicious application could send these components Intents with fake bus information, which will then be displayed in the map as fake bus stations and arrival times. The developer should have used explicit Intents for internal communication, and the Receiver and Service should not be exported.

Comments: 1 Comment
Categories: Mobile security

Security Bugs in Google Chrome Extensions (And How To Avoid Them)

This post is co-authored by Nicholas Carlini, Adrienne Porter Felt, and Prateek Saxena. The data is part of a larger study that will be published later this year.

We reviewed 100 Chrome extensions and found that 27 of the 100 extensions leak all of their privileges to a web or WiFi attacker. Bugs in extensions put users at risk by leaking private information (like passwords and history) to web and WiFi attackers. Web sites may be evil or contain malicious content from users or advertisers.  Attackers on public WiFi networks (like in coffee shops and airports) can change all HTTP content.  We’ll show you how you can prevent attacks on your extension using Content Security Policy.

Vulnerabilities in Real-World Extensions
We manually reviewed 100 Chrome extensions (the 50 most popular and another random 50) from the official directory for security vulnerabilities.  We looked for JavaScript injection vulnerabilities in the cores of extensions (the background, popup, and options pages); script injection into a core allows the complete takeover of an extension.  27 of the 100 extensions contain one or more vulnerabilities in their cores, for a total of 51 vulnerabilities.  The set of vulnerable extensions includes 7 extensions with more than 300,000 users each.  We do not list all of the vulnerable extensions here because many remain unpatched.  The full report will be released in 6 weeks, to give developers time to patch their extensions.

We built attacks to confirm all of these vulnerabilities; two patched examples follow.

Example 1: Open Attribute 0.6
The Open Attribute extension helps users read the Creative Commons (CC) licenses of web sites.  In the typical use case, a user clicks on the extension’s browser action to see a web site’s attribution information.  Open Attribute embeds the site’s CC license in the extension’s popup window, using innerHTML.  A malicious web site could serve a fake CC license that includes inline scripts, or a WiFi attacker could insert inline scripts into a license provided by a legitimate web site like Wikipedia.  The inserted code then runs in the extension’s popup window with the extension’s privileges.  This bug was fixed in Open Attribute 0.7 by setting a Content Security Policy for the extension.

Example 2: Silver Bird 1.9.7.9
Silver Bird allows users to post and read Twitter messages without navigating to twitter.com, and it currently has over 200,000 users.  The extension makes an XHR to Twitter using either HTTP or HTTPS, based on the user’s settings.  It displays the retrieved messages in the core extension, using innerHTML in several places.  If a user were to specify an HTTP URI, a WiFi attacker could insert inline scripts into the XHR response.  Luckily, Twitter prevents its users from launching this attack by sanitizing user messages. This bug was fixed in version 1.9.8.4 by replacing innerHTML with innerText.

How To Prevent Core Extension Vulnerabilities
The vulnerabilities we found allow an attacker to take over an extension by injecting malicious JavaScript into the core extension. To prevent this, we recommend that developers adapt their extensions to use one of the following Content Security Policies:

default-src ‘self’; connect-src: *
default-src ‘self’; connect-src: *; script-src: https:
(For both, replace the wildcards with specific domain lists.) 

These defenses are extremely effective: adopting one of the recommended CSPs would prevent 96% (49 out of 51) of the core extension vulnerabilities we found.  These policies prevent the three ways JavaScript can be injected:  Continue reading

Comments: 27 Comments
Categories: Developer tips, Web security