A Conundrum of Permissions

@misc{kelley2025a,
  title     = {A Conundrum of Permissions},
  author    = {Kelley, Patrick Gage and Cranor, Lorrie Faith and Consolvo, Sunny and Jung, Jaeyeon and Sadeh, Norman and Wetherall, David},
  year      = {2025},
  howpublished = {Keynote and Test of Time Award Talk, Symposium on Usable Security and Privacy (USEC), 2025},
  url       = {https://pgk.io/talks/2025-talk-a-conundrum-of-permissions-usec-test-of-time/},
}

I was invited to give this talk at USEC on behalf of my co-authors, as USEC recognized that this paper, which we published 13 years earlier, had gone on to have lasting impact. Below, is an approximate transcript of what I said, cleaned up for readability.

Hi everybody. So, since this is the test of time award, that means that I’m old. And what you’ll really see is that in 2012, when we published this paper, I was a not yet old, I was a young graduate student.

So I want to start with a little background. As you heard earlier today, we have been studying Android permissions since the dawn of time. And as a graduate student at Carnegie Mellon — when I joined the PhD program, we did not have modern smartphones. The iPhone had not come out yet, and Android was not a thing either.

So I spent the first several years of my PhD thinking about privacy labels, specifically privacy labels for websites. At the time, websites had privacy policies. Spoiler alert: they still do. The first couple of projects I worked on were about different ways to design privacy labels for websites. These are not all of the privacy labels for websites — you can’t even see all of this; if you want to see it, go look at my dissertation. There are a lot of standardized labeling efforts out there, and we looked at a lot of them — including nutrition facts for food, and the privacy facts labels that were built for banks and financial institutions — and how we could apply those to website privacy policies. But the problem with website privacy policies is partially that every website individually controls its own privacy policy. Their lawyers work on those policies, they post them, and they can say whatever they want. So even if you come up with a standard format like the one here on the right — which in lab testing worked extremely well, and helped people understand the privacy stature of the website and their data collection — there’s no (current) way to actually require that across the whole internet. And getting the US government at that time to regulate such a design was not going to work, nor was any of the rest of this. So effectively we knew we could design and better privacy policies for websites but there was no way to deploy them.

And so how did this specific paper come about, where we moved beyond websites to apps?

Well because this is a test of time keynote, and I get to talk about whatever I want, you’re going to get some deep cut stories. As a graduate student, I decided I should go do an internship. Sunny Consolvo, who is the third author on this paper, was at the time at Intel Labs Seattle. Back in the mid-2000s, Intel had a series of labs at universities — four of them around the country — joint labs Intel created in-partnership with and very close to universities. There was one at the University of Washington in Seattle, which is the one I joined for my internship, because I wanted to get some industry experience before I figured out what I was going to do next — and though I was quite confident I was going to go “be a professor,” – I figured I’d get some of that experience.

And on the very first day I joined, in January of 2011 — I was going to be there for the spring semester, January through May — they said, “Oh, we have a very important meeting now, all of the full-time research scientists have to go to this meeting.” And at noon on my first day as an intern, they announced that the Intel labs were shutting down. All of the full-time employees at the labs were told they no longer had jobs, or had to find new jobs within Intel. They’d have jobs for the next four months while the labs went through their shutdown process, but basically they all started updating their resumes and looking for new work. And I, the graduate student intern, was told: “Never mind about the project we thought you were going to do, that’s all been cancelled. Welcome to industry research. Go do something useful.”

And I said, “All right — I’m sort of interested in these permissions on smartphones. Because if you take all of the stuff I’ve been thinking about with designing website privacy policies, you actually only have two big companies you need to convince to change.” (There were actually three — Microsoft had smartphones at the time. Windows Phones, anybody? No.) There were only three big companies running smartphone app stores that people out in the world were buying, and this seemed like a much easier problem: if you have all of these apps in the market, they can just apply privacy labels, and then you only need to convince even one of these companies to do this thing. So I said, let’s do a study and see if that works.

From here on out, these are the original slides. You’ll note that the pictures of what Android looked like in 2012 no longer look like your modern smartphone. All of these images are dated — everything in this presentation is dated; enjoy that. And I’m not actually going to give you the original talk, because I assume you were all here in 2012 listening to it, and have read the paper many times since. Instead I’ll just give some commentary on what it was that we did. And also — I work at Google now, which runs Android. So nothing I say for the rest of this talk that besmirches the Android and Google Play ecosystem has anything to do with my current employer.

At the time there were 250,000 applications, which is not very many. And no application review — also not true anymore; we do in fact review the applications now, but at the time Google didn’t. People were downloading these apps and thinking, obviously they’re very safe and secure, Google must be checking every single one. No, that wasn’t happening.

So we did this interview study, where we wanted to understand from people the basic question of: are you worried about this app that you’re about to put on your smartphone? Do you even know how to be worried about your smartphone and the other things that are on it? And do you trust this developer with your information? Is there a security risk? And really also, is there a privacy risk? And were people able to answer these questions?

At the time — again, a lot of things have changed — Apple gave you no permission information on the iPhone, and Android did give you permission information, but this was before you could accept or decline things. Everything we were talking about in the earlier talks at USEC today, where you can say yes to things, or have it be somewhat contextual, or give partial access, or time-based access — none of that existed. You could see the list of permissions, and you could then decide if you wanted to download the app or not. That was it. And I promise all of these are real screens — these are not terrible color choices I made. I’m going to show you some mocks that I made later, and they’re going to kind of look like this, and I apologize. They wouldn’t look like this now, but this is what smartphone technology was in 2012.

All of this is real. You definitely had to click multiple times to actually get to this permission screen. It was unclear if anyone really looked at it — it was really not a part of things. You could rotate your phone and see it in landscape mode, and I apparently thought that was important at the time.

But in general these were just not good. The permissions interfaces have all sorts of problems: the information is hidden away, you can’t opt out of individual things, there’s no sense of importance, there was no sense of context, you couldn’t explain what the permissions were for — it just provided standard boilerplate language about what the permissions were.

So we did 20 interviews, partially in Seattle and partially in Pittsburgh — because I did go to Seattle, but then I left early and went back to Pittsburgh when the whole lab shut down, so we did them in two locations. And we asked them this series of questions.

In general, some people really liked Android and praised it for being open; others had had numerous device issues and couldn’t wait to switch. They did all sorts of things you would expect in terms of deciding when to install and buy apps. A lot of them just wanted free apps — since it’s free, they’d try it, and later delete it.

When we asked them specifically about the permission screens, many said they just didn’t understand what was going on. They were like, “I just look at the reviews and the rating — what is all this?” They trusted the reviews more, and they didn’t understand why the apps needed such access.

They were largely unconcerned about malicious applications — they believed Android was protecting them. They were concerned in general about technology; most refused to do banking on their phones. And they had tried some privacy tools or other app checkers, a few had installed anti-virus software, but largely they were not that concerned. Most said they would be interested in better app reviews, or an app that checks their phone for security risks or viruses.

We also asked them about specific permissions. One was a permission that was actually called “network communication: full internet access” — it just allowed the app to talk to the rest of the internet. These are some of the ways participants described how they would tell someone what this permission was. You can see a whole range of confusion, some amount of clarity, and a little bit of “why is it even a permission if this thing can go talk to the internet?”

The permissions have changed over the years. We did this for many of the permissions — we went through and tried to work down the list — and the permission lists themselves have changed over time, so again a lot of this is out of date.

The permissions were really written for and by developers, but they were being shown in a user-facing way. So there were things like “act as an account authenticator,” and people just really didn’t know what that was. “That freaks me out — what does that mean exactly, because I’m not quite sure.” Exactly the kinds of things you would expect to get for a novel, confusing, not particularly usable technology.

Overall we found they didn’t really understand permissions. The terms are at best vague, and at worst confusing, misleading, jargon-filled, and poorly grouped. It’s difficult for people to make informed decisions when installing new software on their phones. Largely, the permissions were ignored, with participants instead trusting word of mouth, ratings, and Android market reviews. And while participants stated they try to find good applications in the market, they believe they’re protected by oversight processes which do not exist.

So the conclusion of the study was that, in fact, users were not well prepared to make informed privacy and security decisions around installing applications from the Android market.

While we were doing this process, Android changed things. If you remember the screen from earlier — this is still a 2012 presentation slide — things were like green and orange. At some point they became teal; I don’t know why. And they also changed how the permissions were displayed, and you could click on them to get more information.

So they … clarified that “full internet access” by adding that “it allows an application to create network sockets.” And 13 years ago, I really liked pointing this out, because I thought this was ridiculous language to use for end users. It turns out it still is. This is bad. This is clearly a time where Google’s UX writers were not yet on these screens — we do not say “network sockets” to users anymore.

There were a few other details about malware in the store, and then I closed this talk. That was it. That was the whole talk. That was what you saw if you were at USEC in 2012. USEC in 2012 used to be co-located at the time with Financial Crypto, not NDSS, so Jean and I and maybe others were on the island of Bonaire that year — one of the Dutch Antilles, a lovely tropical island, at a resort called the Baha Flamingo Resort. I did have to look some of this up. We had a great time; you should really check it out. San Diego is nice too, of course.

So that was fine. That was a pretty standard, basic security usability study. So, why am I here? Why is this a test of time award? There are a few reasons. One is there’s a follow-up paper we did right after this. By the way — I didn’t mention this — the title of that paper, “a conundrum of permissions”: I thought I was being very clever, coming up with the plural noun group word, you know, like a “flock” of flamingos. I was like, a “conundrum” of permissions, because they’re just so confusing. It never caught on. So the next year we published this paper at CHI, called “Privacy as Part of the App Decision-Making Process.”

I’m not going to show all of the slides for that, though they mostly come in the same format. By that time we’d gotten a little clearer on what people were doing with their apps, and we had started grouping apps into a few different categories of why people get apps at all. At the time, especially on Android — and this is all Android-based still, because iPhones had permissions in the back end but there was no user-facing display of them — there were apps that came on the phone (there was a lot of Android bloatware at the time; depending on your provider there would just be tons of apps, and sometimes you couldn’t remove them); there were apps that come from a trusted or already-known brand; and there were apps that were picked from the market to fill a need. The idea was similar to websites: if you have an account with a bank, or you trust some news organization, you’re going to download that app regardless of what the permissions say. You’re not going to say, “Wow, my financial information is kept through Citibank, but I don’t like the permissions, so I’m not going to use the app.” That didn’t make sense. So really the permissions only came into play with that third category — the app where you just need your kid in the back of the car to stare at your phone for a little while, so you download some random thing; or you want to play a game to kill time; or you need a flashlight app, because those weren’t standard OS features yet, so there was a whole market of thousands of flashlight apps that collected all sorts of data. Those were the key moments where we hypothesized permissions might actually change decision-making behavior, and so we wanted to focus there.

The most relevant part of this CHI paper is that we did a design intervention. We said, okay, what if we designed this Privacy Facts box, this little checklist — based on what we had learned in the USEC paper. What if we took all the permissions and turned them into cleaned-up categories? Again, these aren’t real — there was no permission for health and medical information, and photos was more complicated than this at the time — but we simplified. What if we made an easy-to-understand set of permissions that users could make decisions based on, using some of our work on how to best design privacy labels, and said, this is the thing that should go into the app stores?

And so we had a short survey. We asked people how they pick apps. Permissions are relatively unimportant, (but not the worst!)

We did an interface test where we actually put those Privacy Facts labels into the store listings, and it turns out people were much better at choosing apps. I’m not going to show all the results from that. But then, in my dissertation defense, as I was finishing my degree, I said, “Great, we’re done, we’ve solved it. Check — we’ve solved website privacy policies. And check — we’ve solved permissions and app choice. All you need to do is give people this checkbox.”

This is also an actual slide — not with the pink background — from my thesis defense. Two more quick background stories now.

1. Here’s a photo of me 12 or 13 years ago, winning the ACM Student Grand Challenge for research, because again, people really liked those privacy policies.
2. The other story is that in my thesis defense — Sunny, who I interned with when the lab shut down, had since moved on to, in fact, Google. And when I was defending, presenting all of this work, the question she asked publicly, to my gathered defense, was: “These Privacy Facts labels are great, but Google and Apple are never going to do it. Why should we care? Why does this research matter?” And I was about to become a professor; I did not care about industry research. I said, “I don’t know — they should. The research shows that they work better. I don’t have a reason for why the lawyers are never going to do this. I don’t care.” And I passed the defense, so it was fine…

No one’s ever going to do this — but so what, I showed that it worked. So then time passed. I graduated from Carnegie Mellon, and I went and became a professor, because of course truly I was going to be an academic. I was an Assistant Professor at the Computer Science Department at the University of New Mexico for four years.

And I left the University of New Mexico for what I thought was going to be a quick break. There were problems at American universities — unlike now of course. I figured I just needed a quick minute to take a break from academia, and I’d go get that industry research experience that I never really got, because the lab shut down on my first day. I’ll join Google and just hang out there for a year. As it turns out, I am still employed by Google. It is now nine years later.

And one of the things that happened over those nine years was that in June of 2020, Apple announced privacy labels!!! There’s no timeline slide in this, so you’ll have to do the math visually. We published the USEC paper in 2012 and the privacy decision-making paper at CHI 2013, and all of that research was actually done in 2011 and 2012. So eight or nine years later, Apple was like, “What if we put privacy labels in the iPhone store?” And I was like, “Cool idea. What a great idea. No one could have known.”

This is what Apple’s privacy labels look like. And on the day they announced them, June 22nd of 2020, they actually made a little phone call — not to me, the Google employee, but to someone else who might have been a co-author on some of these papers — and said, “Hey, we’ve read all your papers, we really like them. In about an hour, we’re going to announce some privacy labels.” So: research impact. And they read our papers.

These two things look pretty alike. They did not give us any money or credit, but they did it right, and that alone is good. As a reminder, this is 2020 — it’s a pandemic, June 2020. I’m working at Google at the time, and Google has noticed that Apple has created these privacy labels. Google also noticed that it’s kind of based on some research paper that it turns out a couple of Google employees wrote. On the USEC paper there are six of us; three of us are currently, and were also then, employed at Google. None of us were employed at Google when we wrote the paper, but half of us are now.

And so they reached out and said, “Hey, Apple just did this thing. We have been saying for years that we think privacy labels are a bad idea in the Play Store.” That was Google’s stated public policy position — not mine. And that was the position until June of 2020. At this point, Google — the Android team specifically, which is not the team I work on — found me and said, “Hey, we heard you did this thing, apparently you work here. Could you tell us how to do it better than Apple?” And I said, “I can. You’re not going to like it.” And that was true. So in May of 2021, Google also announced what Google calls Data Safety Labels — they’re not privacy labels, they are data safety labels — and those launched a few months later.

Those also look really similar. You can scroll down, you can see different things, you can click on things, you can get more definitions. They look kind of like the various Android things they had before.

And there’s also a label when you’re on the main page — right above the reviews, you can see this short highlight view of Data Safety. Again, Data Safety labels — they’re not privacy labels; Google is not copying Apple. And again, they look really similar to what we did a decade earlier. That was nice. So the moral of this story is: do research that’s good, and then a decade later some company might implement it, because they want to compete on privacy in the market — and it has nothing to do with where you work or what you’re doing at the time.

There has been a lot of research — a whole resurgence — around privacy labels since then. This is a short highlight of some papers that I like, some by pass collaborators. As a person who works at Google these days, I have not really been doing any research to investigate our own labels, for all sorts of reasons — who would trust me? But there is really good research on this. And as you can tell from some of the titles, there’s a lot of skepticism around these labels. There’s a lot of “yes, sure, Apple has made the permissions displays better to read than what Android had a decade ago, but the labels aren’t necessarily doing a lot for users.”

And there are a bunch of reasons for this, some of which go back to the USEC and CHI papers: they’re still not doing the easiest things. You have a review score, 4.7 out of 5 or whatever, but there’s no privacy score, no privacy comparison. You’ve written out a bunch of words, but you haven’t made it actually easy to compare when you’re looking at apps. You’re not taking those privacy scores and feeding them into market decisions — you’re not increasing the rankings of privacy-preserving apps, apps that do less tracking. There are some differences in how Google and Apple have implemented things, and even papers about what happens when they don’t work. One of the very first — I think it was Mozilla, I don’t even know if it was a paper or just a blog post — looked at a bunch of apps and compared them to the privacy policies, and found: guess what, they don’t match. And again, from my point of view, this is fine. The whole point of these labels is for people who are really interested to dive deeper, to understand what these apps are doing, to have more transparency, and at some point to help consumers in the market make a choice. It is sometimes hard to get there.

At this moment, in the actual talk, I switched gears and talked about two other recent projects. Those aren’t relevant to the privacy labels award talk, so I’ve cut it off here, though they are still in the video if you want to go watch!