Android 11 is here, and while the early developer previews and beta builds have shown us most of what is available, there is a lot behind the scenes that changed. Many of those changes have to do with user privacy, which is something that affects us all.
The changes themselves don't seem like major additions to what has become the most used operating system in the world, and that's by design. The team working on user privacy had the tough job of giving us more control and being proactive through the OS itself without anything feeling complicated or disruptive.
To get the full story on what was changed and some of the thoughts that went into those changes, which you can read in detail in our Android 11 review, I sat down with Google Product Manager and privacy specialist, Charmaine D'Silva, for a discussion about what it all means and how it all works.
The most important thing we all should know is that Android has been built from the ground up to protect user privacy. It doesn't seem that way sometimes with all the data Google collects about us, but we have the choice to opt-out of that collection and if we don't the data is anonymized — to Google's computers, we're just a random number.
Right from the start, Android has been designed with privacy at its core. Over the last three years, we've really pivoted to making sure that the features we actually build are things that users desire. Previously when we built privacy features, most things were under the hood; this is the way we actually structured the operating system. Things weren't so much in front of the user because honestly if you think about it, privacy can be pretty overwhelming.
The most forward-facing privacy features in Android 11 are changes to permissions and adding the "one-time" permission for apps that use location, your camera, or your microphone. This is an extension of Android 10's "while-in-use" permission for background location that allowed you to prevent any app from tracking you while you weren't using it.
Google looked at user data and approached the idea of adding more user control to some critical privacy features in Android 11:
As users changed their position on wanting to control things more rather than have things be taken care of for them by default we shifted our approach to be able to meet users' needs as well. We're adding more controls in front of the user, giving them more choice, and with each release, we're slowly ramping up how many choices and options we give to the user. That's completely intentional. We never want to overwhelm the user with so many options that they don't really know which choice to make so we're very mindful of what choice we put in front of the user.
Google says that a lot of people are actually using these new features, too, far more than in previous years.
What we've been seeing, surprisingly and much to our delight, is that users are actually exercising these choices very very frequently. This gives us the confidence to actually build more of these types of features moving forward. If you saw looking back at Android 10, one of the major changes we made with that particular release was actually adding the "while in use" location permission.We were definitely apprehensive whether or not people would understand what "while in use" would mean and would they actually use it. Overwhelmingly, we saw that most users actually choose that option more than 50% of the time compared to the other options. This was a clear indicator to us that users generally want to have more granular controls and are more mindful and thoughtful about choosing the "while in use" option for background location.
For one-time permissions, Google is focusing on three specific use cases: microphone, camera, and location.
Because of the great feedback Android 10's control over background location received, Google decided to provide even more control through the use of "one-time" permissions that allow you to let an app do a thing only while you're using it this time. The permission to continue using a feature or having access to it is not granted after you close it:
We kind of built onto that kind of approach with Android 11 and expanding on what we did with background location we added a one-time permission as a new prompt to this release. It's the same sort of concept but if you're thinking about using an app and it doesn't need this permission all of the time. Say, for example, you're in a situation where you're trying to share your location with your spouse or with a friend through a chat app. A chat app doesn't need to know your location all of the time but in this one instance, you want to deliver that location. We wanted to give people the granular control of a one-time-only permission as well.We thought about it and there were three permissions that really stood out that actually have those use cases: microphone, camera, and location. We ended up building a one-time permission for all three for these exact reasons. There may be instances where you want to an app have one time access to these permissions. We're seeing that people are using these options pretty frequently in the Android 11 Developer Previews and Betas. It's that same concept where we're adding more choice to the user with granular controls via the scope of the permission or when it comes to how temporal that permission is as well.
Another major change under the hood for Android 11 is that an app that hasn't been used for 39 days can have its permissions automatically revoked. If this happens you'll get a system message telling you about it, and you can, of course, re-enable permissions the next time you use the app.
D'Silva explains that this is one of the times that Google decided to be proactive rather than let a user handle the task because Android permissions aren't easy waters to navigate:
The amount of action to revoke a permission is pretty onerous and not something most users can do easily. This gives a user the ability to try a feature or make sure they are comfortable with an app because they can just enable it for a single use-case and never have to worry about it again. This is something that really went into our thinking when designing the one-time permission feature.There are so many times we actually interact with apps and use them because at that moment it's really important. As we move away from that situation, that app may not be something you use all the time so we use the same type of thinking for permission revocation. Say you visit a new city and you need to use an app for ride-sharing or visit local attractions. When you leave, people usually don't go back and delete these apps very frequently if they have a phone with a lot of storage. That app may still have access to all the permissions you granted, which were completely appropriate and relevant at the time. But if you aren't really using that app it shouldn't have access to these permissions any longer.
Giving users additional prompts wasn't the best strategy, according to Google.
In this particular case, we actually wanted to make sure that we take the stance of doing all the clearing up on behalf of the user proactively and let them know that we've done the cleanup and automatically revoked the permissions. Do we burden the user and ask them, "Hey do you want to revoke this permission?" or let them not have to think about it. In this particular case, we decided to just pull away all the permissions and then notify the user that these particular apps no longer have these permissions.
Android apps have access to a lot of different permissions. So many that it's almost impossible to keep track of why any particular app would need any particular permission.
With Android 11, Google really focused on revoking old permissions that hadn't been utilized in a while.
I asked if there were any particular permissions that received special attention because of their potential for privacy abuse and if Google paid any extra attention because of user data about how apps behave on our phones:
Any permission that needs to be granted is a sensitive permission. This is why we always prompt the user for consent before we give an app access to that data. Since you asked about user data, there isn't really a bias among permissions where rejection rates are a lot higher on say location than they are for storage. That's not the case, and in fact, all the data we have tells us that across the board rejection rates are pretty much the same for all permissions. People are equally sensitive to all of these permissions.What we have seen though is that rejection rates really increase if a user doesn't understand why an app needs a permission. So what we've seen is that it's not about what the permission is, it's the concept of if you're giving up something in return for something that has value. Value exchange is really fundamental to the user, so if they understand that they really have to give access to the camera, for example, because they want to have a video call, that value makes sense. But if they have to give the same access to something like a calculator (I hope there is no app that does this!) then that value exchange doesn't make sense. So what we see through our data is that a mismatch in the value exchange is when rejection rates go up.
I also asked if the general belief that half of Android users always just click yes while the other half always click no when presented with permission dialogs was true. I know plenty of people, especially tech writers, have this conception (including yours truly) but it turns out it's really not the case:
You would think that's true and I actually had that hypothesis so I went to our data analysis team and ran that through them. Honestly, the data does not show it. There are obviously trends where some people are more cautious about location or other more sensitive permissions but I've yet to find evidence that a core group of people say "yes" to everything. People are definitely stopping to think and exercising their right to say no to an app or permission.
I am pleasantly surprised by this and love hearing how actual data dispels any notion that many users just don't care. Next, I asked about what Google was doing to make sure users aren't frustrated by seeing dialogs that ask for permissions as the types of changes we see in Android 11 are expanded:
Going back to when we introduced one-time permission there was apprehension that while we wanted to give users choice, now we're going to have more popup dialogs that make things feel less seamless. But everything we've seen is just that people are excited about having more choice, and actually thinking about what they are consenting to.We're really mindful that the list of permissions isn't something massive that's hard to understand. We want to keep things succinct and precise so that it's scoped appropriately.These are also the kinds of things the Play team has been thinking about more. Should a calculator app ask you to use the camera if it has no business asking? The Play team launched the SMS / Call Log policy and the intention is exactly the same: an app that has no business asking for the SMS and call logs shouldn't be asking for it. As much as we can filter through Google Play making sure the right apps ask for the right permissions, then allowing the user to have choice on top of that, I think that's the best experience. A part of not being overwhelming is that you want to filter down the noise.
I know that many "advanced" users have asked for the same sort of privacy checkup that Google offers for your account on the web be made available for our phones. D'Silva says Google decided to be more proactive, knowing the data would show users wanted to have unused app's permissions revoked based on Android 10's background location reminder:
We've definitely talked about it and you probably saw something like this happen in Android 10. We did this background location reminder that basically said, "Hey, remember you gave this app access to background location, do you want to continue that?" This was also very successful and we got a pretty high kill rate of those permissions and that notification; more than 76% of users actually ended up changing the location permission to deny or only while in use.Fast forward to this year and the revocation system is actually the checkup. We had to consider if we wanted to ask people up front then make them choose like the privacy checkup, or do we want to make that choice for them. Eventually, as we thought about it more, we wanted to take a stronger stance on this. An app you haven't really used has no business doing that (keeping permissions). In this particular case, we wanted to be more opinionated and tell the user "Hey we have taken this permission away because you aren't really using it."It's easier for a user to grant a permission back to an app than it is leaving them with one more question.
Because of its controversial history, I had to ask about Scoped Storage. Scoped Storage is a big change in how apps store and share data that is also a big boost to user privacy. I asked about any developer pushback and how involved the privacy team was in its development.
Scoped Storage is very much a part of my team because it is 100% a privacy feature. The intention of Scoped Storage was because as things evolve we want to be more mindful of what gets shared and being able to give people more choice about it. Restructuring in Android 10 was definitely ambitious and we learned a lot through the process.We adjusted the plans based on developer feedback, and so far with Android 11 things have gone very smoothly and I think the developer community has embraced the change and are happy with being part of our process. We've taken all the feedback they gave us in Android 10 and tried to address it through changes in our plans. So far it's been pretty smooth.Android 10 was definitely a learning experience. It was a massive shift, so we learned through the process. And definitely we want to give a shout out to the developer community who really helped us come up with a good solution for Android 11.
I asked how the team worked to make sure that none of these changes would make our experience using Android worse. For example, would automatically revoking permissions be able to break older apps (we all use a few) and what Google did to make sure the experience was still as good as ever when it comes to installing and using third-party applications?
As much as I like to be as far-reaching as possible when it comes to privacy, we do have to take a step back and make sure that don't break experiences in the process. So with auto-revocation one of the requirements for it to be on by default is that the app has to be targeting the Android 11 release.There are some completely legitimate reasons that you would never interact with an app, such as a safety app. In some cases, there is a reason to engage the user or provide a toggle in the settings, in other cases there isn't. That's a very fine balance and we want to make sure that we push privacy forward but we also don't want to break legitimate use cases.The only way an app not written to target Android 11 would be in a state of auto-revocation is if the user went in and actually turned on auto-revocation for it.
My final question was partially in jest but I know it's also the same question all of us have: Any sneak peeks into features for Android 12?
Nope. But D'Silva did suggest that everyone with any ideas be sure to forward them to Google because they all want to keep giving us the features we want to see whenever they can.
The company isn't going to change how it tracks users — again, it's anonymously collected and you are but a number only a computer recognizes — but it is more mindful of making sure we know how we're sharing our data, and more importantly, how to not share it when we don't want to.
I want to thank everyone at Google who made this possible and especially Ms. D'Silva for taking time out of her busy schedule to have a chat about privacy with me. I left the meeting feeling like Google understands how important privacy is to all of us, even if some of us care more than others.
