[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]
