[MUSIC PLAYING]
SARA N-MARANDI: My name is Sara.
And I'm the product manager on Android permissions.
And I have here with me my colleague Philip,
who's a software engineer on permissions.
Over the course of the last two days,
we've had a chance to meet a number of you.
And we truly appreciate you taking the time
to come here, talk to us, tell us
your stories and experiences, and give us feedback.
Over the next 15 to 20 minutes, Philip and I
will provide you with an overview of the permission
changes that we introduced in Android 10.
And we'll share with you some of the best
practices that guide our product development process.
On Android, our goal is to give users more transparency
and control to their own personal information
that's being used by applications.
To that end, we have been working
to evolve Android to make it much more private.
In Android 10, we introduced over 50 privacy features,
making it our most privacy-friendly release
to date.
Just looking at permissions alone, for example,
we made a number of changes.
We made privacy and location top-level settings menu.
We introduced more granular location, as well as
added background location reminders.
And we made activity recognition a dangerous runtime permission,
and as well, we restricted access to on-device screen
content.
Looking at device identifiers, we
restricted access to dangerous hardware IDs,
as well, we randomize MAC address by default.
And finally, looking at background activity,
we have restricted background activities launching
from background, as well in Android 9,
we restricted access to background mic and camera.
This is just a small flavor of some of the changes
that we've made to Android, but today, we're actually here
to just talk about permissions.
So I'm going to hand it over to Philip,
who's going to go through more details about some
of the changes in Android 10.
PHILIP MOLTMANN: Thanks, Sara.
First, with Android 10, we wanted
to improve the user's understanding
of their current privacy configuration.
So we added a new top-level privacy setting
that links the user to the permissions management,
but also to privacy-related information,
like for example, their web activity and their ad settings.
Another privacy-related settings is this location setting.
In the location settings, you can find which app recently
used your locations, but also location proxies,
such as Bluetooth and Wi-Fi.
Users are very sensitive about sharing location data,
hence in Android 10, we allowed the users
to choose if they share their location data all the time
or only while using the app.
Let's look at some use cases.
If the app wants to tag a photo or tag a social media
post with location, the user clearly
knows it's using the app and knows how location is used.
If the app provides navigation, the user
might choose to temporarily use a different app.
In this case, we require the app to show a notification
to remind the user that your navigation component is still
actually using location data.
As you can see, I'm not showing any use cases
for background location.
We believe that background location use
cases should become quite rare.
Even if the app has a background location feature,
the user might still be uncomfortable with sharing
their location all the time with this app
and the user might deny the access.
Implementation-wise, if your feature
requires background location access,
you have to add an additional, we call it a,
modifier permission, in your manifest.
And this permission is a runtime permission.
And once it's granted, it grants background access
to the additional foreground.
So it means, in this case, coarse or fine location.
As you can see, we consider background location something
very special.
If your app is accessing location in the background,
we'll eventually, some day later,
show a notification reminder user
that user has the choice to deny background access.
There's two additional changes in Android 10
I want to talk about.
In Android 9 and before, activity recognition
was not considered user sensitive.
In Android 10, we consider it user sensitive.
Hence you get user's consent, you ask for runtime permission,
and the user can say yes or no.
This is the name of runtime permission.
And you ask for it like any other runtime permission.
Screen recording is another very sensitive topic for the user.
Hence we enforce user consent by requiring
all apps to go through the MediaProtectionManager API.
Let's see how it looks.
So in order to use this, you have to create a foreground
service with a specific type.
Then you start the foreground service.
Once the foreground service is connected,
you start the consent activity.
The user can then say yes or no.
Once a user says yes, you start the projection.
Let me hand it back to Sara to talk about the motivations
behind these changes.
SARA N-MARANDI: Thanks, Philip.
I'll spend the rest of this session talking about some
of the research we've done in this space
and describe how those insights actually
drive a lot of our product decisions and development.
So we know that most apps tend to request access
to permissions, usually all at once, or upfront,
or during onboarding.
But users have continuously told us
that they prefer, when an app asks for permission,
when they understand the reason for that permission.
And we can see that.
When we poll our users, we see that only 18% of them
have every single permission granted on their devices.
And when we ask them why they eventually grant a permission,
the top reason that they state is
that they want to use a specific feature of an app
or they want to experience a feature.
So this demonstrates that users are
more likely to share their data with applications when they
understand and get what the value of it is,
and if it sounds very logical to them.
And we also are seeing that users are
choosing the share less data.
So as we mentioned, we introduced the new changes
in location, more granular location permission.
And now, we're seeing, in our data,
that over half the users are selecting
while the app is in use.
And through our studies, we have learned that users actually
understand what while in use means,
and they're making their choice intentionally.
And finally, our data actually highlights
really high sensitivity towards mic and camera.
So as I mentioned, we actually removed access
to background mic and camera, but we never really indicated
that in the runtime permission.
So in our future release of Android,
we actually will change the wording to say while in use,
so the user doesn't have to worry about their data being
accessed in the background.
As I mentioned earlier, we have a set of best practices
that we like to share with developers.
I'll summarize some of them here today.
So first, we ask that you review your permissions.
Request the minimum permissions that your features need.
So, for example, check to see if there are alternative APIs.
If there are alternative APIs that give you the data
you need, please choose to use them, instead of permissions.
They tend to be much narrower in scope,
and hence more privacy-friendly.
We also ask to please request permissions in context
and for the use case.
So as we've illustrated, users are willing to share data,
but they just need to understand the perceived value.
Please pay attention to your permissions
required by libraries.
Your users don't distinguish between the data
that your app is using and the third party SDKs are.
So please understand the permissions
that your SDKs require.
And minimize the use of location, especially background
location.
As Philip has illustrated, really, access to foreground
is generally enough for most location use cases.
And also, design your app to work under the conditions
that you will have only while in use.
Because we've seen more than half
the users are selecting while in use,
and you may never actually have access to background.
And finally, we ask that you are transparent about the data
that you're using.
Let your users know why you need access to that data.
These best practices are based on principles and values that
drive our product development process,
and they will continue to drive how we innovate in this space.
And we really hope that you continue to work with us
and give us feedback in making our ecosystem safer
for all of our users.
That concludes our presentation today.
We'd love to hear from you.
I think we're going back upstairs.
We also have a sandbox.
If you haven't stopped by yet, we have another hour left,
so please do so.
And we'd love to hear your use cases, especially
if you have location use cases or whatever
it is, let us know about them.
We just want to understand your applications a lot better.
Thank you very much for spending the last few minutes with us,
and we really appreciate your time.
PHILIP MOLTMANN: Thank you.
[APPLAUSE]
[MUSIC PLAYING]