[MUSIC PLAYING]
PARUL SOI: Hi, everyone.
Hope you've been enjoying the day one of this summit so far.
I'm far away.
I'm part of the Google Play team.
SEB GRUBB: And I'm Seb, on the Android framework team.
Before we head out to lunch, we just
want to take a few minutes to talk to you about something
pretty important--
PARUL SOI: Privacy.
Specifically, we want to talk to you about certain practices
that you as app developers can adopt
to build products that continue to wow
your users, at the same time, protect their right to privacy.
We want Android to be a platform where
you can offer personalized experiences
and make the life of your user simple.
But, at the same time, privacy is important
and transparency, in terms of what data you're collecting
and how you're using it, is very important to be shared.
SEB GRUBB: So, to ensure Android can continue
to serve as a platform that allows developers to build
such experiences and protect users,
we have ongoing efforts that span multiple releases.
So the things we want to touch upon today are--
how your apps are accessing user data;
ensuring that your users have control
over data being accessed; and, most importantly,
that there is transparency into why the data is required
and how it is being used.
So we have a multilayered approach to privacy in Android.
Firstly, we focus on platform updates
to improve the APIs that are used by apps to access
personal information.
PARUL SOI: We then set up our Play policies
for keeping abuse in check and also ensuring
that a level playing field is provided
to the developers and a safe experience for our users.
SEB GRUBB: We've built out a [INAUDIBLE] layer
to identify early on when apps may be abusing
a user's personal information.
PARUL SOI: We also have human reviewers
so it's not just bots and AI, but actual people who
review these apps to make sure that a user's right to privacy
is always secured, and also ensure that the safe experience
is provided.
We also invest heavily to work with a community of security
researchers.
Please do check out these programs.
We have the Play Security Rewards Program
and Vulnerability Rewards Programs.
And, also, please feel free to drop by if you
want to know more about these.
SEB GRUBB: And, finally, we have Google Play Protect,
which helps users conserve the privacy and security.
PARUL SOI: So why are we here speaking to you today?
Because we feel privacy and security
is a partnership between the platform and developers as you.
You, as developers who actually build out these apps,
play a very vital role in the ecosystem.
You have the ability to advocate for better privacy
practices in your company and ways
to ensure that the team's vision of your product
is not compromised at the right of users' privacy.
For example, if you have a request
to collect certain bits of information
about a user from their device, a question always worth
asking is, do we really need it?
How do you plan to use it?
And are we still using it, in the instances
of historical data collection.
The reason is that it is actually not
very uncommon for certain information about a user
to be collected in guise of behavioral analytics, which
is actually never used, and is sometimes abandoned altogether.
SEB GRUBB: Some examples of data that we've
seen being collected includes IMEI, used
as a unique identifier for tracking users;
the list of installed apps, either to fingerprint a user
or to target ads to them; collecting
the location of an app open, or cellular network
information such as the name of a network or of a strength.
You probably don't always need such information.
So, for a few cases, we offer more privacy-conscious options.
So we encourage you to use them if they fit your use case.
Some examples include we encourage
you to use instance or Android ID instead of the hardware
identifiers such as IMEI.
If you're trying to confirm a user's phone number,
we encourage you to use a Play SMS retriever
API instead of the SMS permission,
which is not as granular.
You could also consider only requesting course location
instead of phone location.
And then, if you want to see if a user is in a call,
you could check for an audio focus,
rather than requesting a read phone state, which
gives out a lot more data.
PARUL SOI: And, lastly, you want to ensure
that your users are aware of what data is being collected
and how it is being used.
This is not just a best practice,
but is actually a requirement by Google Play policy.
A rule of thumb is that if a user is not aware
that some data about them is about to be collected
and for what purpose it is being used,
you are required to prominently disclose it to them
and get the permission to do so.
So the example that we have here--
the data is being collected off the installed apps
on a user's device for fraud prevention purposes.
So this needs to be prominently disclosed to the user.
And only after your user consents to it
should the data be transferred.
SEB GRUBB: In the latest Android releases
we've worked hard to offer more privacy-sensitive OS.
And we're going to walk you through a few of those changes.
In Android 9 we split up the call
log permissions from the phone permission group
into their own permission group--
call log-- to give users more transparency into what apps
are doing.
So if your app is reading phone numbers from a phone's state
broadcast change, we're now asking
you to request both a call log and a phone state permissions.
In Android 8, we dedicated a build serial static field,
replacing it with a build.get serial function, that requires
a read phone state permission.
If you're going to use it, please be sure you're
going to use it for valid purposes.
Because it's a Play policy violation
to use it for advertising purposes.
PARUL SOI: Speaking of limited access, a reminder--
apps running in the background on Android 9.0
will require the following restrictions--
you will no longer have access to mic or camera
in the background; sensors, such as accurate gyroscope,
directed on empty data.
If your app needs access to sensor events on devices
running Android 9.0, you will need
to use a foreground service.
And to further inform and protect the user,
the system will also add a visual aid
to your notifications when your services are accessing
the camera or the mic.
SEB GRUBB: Our Contacts Provider API
used to allow apps to collect data
about how often a contact was being contacted,
allowing other apps to glean information
about interactions not happening within their own scope.
So, as of January next year, a limited set
of contact fields and methods will be made obsolete.
These include fields relating to the last time a contact was
accessed or contacted.
So if your app is accessing or updating these fields,
we ask you to use alternative methods.
For example, you could fulfill certain use cases
by using private content providers
or simply storing data in your back-end systems.
PARUL SOI: This was a really brief talk about best practices
for privacy.
We hope that we've been able to offer you at least some insight
into how you can build apps that are conscious of users'
right to privacy and also compliant with all
our policies.
So as we've mentioned earlier, we definitely
believe that security and privacy
is a partnership between you, the developer,
and our platform.
So if you have any questions about it,
please do come find us at the office hours.
And I hope you all have a great summit
and have a great lunch as well.
Thank you so much.
SEB GRUBB: Thank you.
[MUSIC PLAYING]