[MUSIC PLAYING]
ARTEM VOROBIOV: Welcome to this UK compliance
clinic for Google Play.
I'm Artem, Play Policy Consultation Manager
here at Google.
Today, we would like to share a common policy
issue that Android developers using your SDK
may experience when publishing on Google Play.
We know that users are concerned about privacy,
and consumers expect brands to invest more in it.
Play policies asides, research by Gartner
suggests that up to 75% of users will be directly impacted
by new privacy regulations by the end of 2024, which
is itself a reflection of growing regulatory and consumer
demand around privacy.
Google Play's teams strives to build
the most trustworthy and safe developers ecosystem.
And this is a part of our work to continuously enhance
the privacy experience and expectations
for our users, our developers, and all of the solutions
providers in the mobile app ecosystem.
In February 2022, Google announced an initiative
to build the Privacy Sandbox on Android,
with the goal of introducing new, more private advertising
solutions.
Those solutions will limit sharing of user data
with third parties and operate without cross-app identifiers.
In April 2022, Google launched Data safety section for apps
to be more transparent about the data collection
and use behaviors in Play.
And in May 2022 at Google I/O, we
announced the launch of Google Play SDK Index, a public portal
to help app developers make informed decisions about SDKs
they incorporate into their app experience.
And recently, we launched the SDK requirements
to give app developers one place to see all policies
requirements they must keep in mind when incorporating SDKs
into their apps.
If you haven't checked it out, I highly recommend you to do so.
During this conversation, we want
to encourage SDK providers to stay up
to date with Google Play policies
by covering some SDK behaviors that often cause apps
to violate our Play policies.
And who is the better to help me with this if not
one of our own Android security engineers, Brian, whose
team has reviewed many SDKs?
BRIAN EDMONDS: Hi, Artem.
It's great to be here today.
The privacy and security space is something
that we take seriously at Google.
And I'm eager to provide some more information
to SDK providers.
ARTEM VOROBIOV: Thanks, Brian.
Can you please highlight some common SDK
behaviors that may cause apps to violate our policies?
BRIAN EDMONDS: Absolutely.
One of the highest priority problems
we'd like to discuss today involves the mishandling
of personal and sensitive user data.
When app developers include an SDK in their app,
they must ensure that the SDK handles user data in a way that
respects user privacy and consent
and maintains strong security practices.
ARTEM VOROBIOV: One big part of that
is it's important for SDKs and apps to not access more data
than is required for the apps to function properly.
So what is the ideal way to do that, Brian?
BRIAN EDMONDS: Yeah, good question, Artem.
First off, apps must limit the access, collection, use,
and sharing of personal and sensitive user data acquired
through the app-to-app and service
functionality and policy-conforming purposes
reasonably expected by the user.
To best protect users' data and prevent a policy violation
from occurring, don't collect data
by default with the assumption that consent has been provided.
And, as a best practice for SDKs,
ensure that a mechanism exists for the app developer
to accurately initialize the SDK according
to this user-facing consent event.
ARTEM VOROBIOV: Please tell me more.
BRIAN EDMONDS: Sure.
SDKs should not assume that a user has consented
to any personal or sensitive data collection,
even if an application holds the permission
to access a given data type.
For example, if an application collects
data that is considered personal and sensitive,
a best practice for the SDK is to implement a mechanism that
allows app developers to signal to the SDK
that the user has consented to collection of this data.
For example, instead of SDK's collection location data,
as soon as the SDK's init function is called,
the SDK should wait to collect that data
until after the application has signaled to the SDK
that the user has consented to any collection of location
data.
ARTEM VOROBIOV: In other words, app developers
have to answer three basic questions
before starting to collect any user data,
including through an SDK.
First one, for what purpose am I collecting the data,
and is that purpose policy compliant?
Second one, do I need to provide a permanent disclosure
to my users and obtain their consent?
And if yes, third one, what type of data user
consent to collect or share?
BRIAN EDMONDS: You mentioned types of personal and sensitive
user data.
Does our policy say anything about this?
ARTEM VOROBIOV: Great question.
Our user data policy indicates that personal and sensitive
user data includes but isn't limited to personally
identifiable information, financial and payment
information, authentication information, phone
book, contacts, device location, SMS,
and call-related data, health data, Health Connect
data, inventory of other apps on the device, microphone, camera,
and other sensitive device or usage data.
All these data allows developers and SDK providers
to access a lot of information about users.
And that's why if SDK that is designed
to collect personal and sensitive user data by default,
we could ask app developers to provide sufficient evidence
demonstrating that their app meets the prominent disclosure
and consent requirements of this policy,
including with regards to the data handling via SDK.
BRIAN EDMONDS: Makes sense.
That's why it's important for SDK providers
to remember the following-- first,
limit your collection of personal and sensitive user
data only to policy-compliant reasons
and only to what is needed to offer the services provided
by the app.
Second, limit the access, collection, use, and sharing
of personal and sensitive user data,
handle it securely when it's collected,
and, most importantly, never sell personal and sensitive
user data.
ARTEM VOROBIOV: And if you are not
sure what do we mean by sale, please
check our user data and SDK requirement policies.
The links the articles are attached under the video.
What is another common behavior you
see lead to policy violations?
BRIAN EDMONDS: Good question.
Another example of a common violative practice
that we have observed historically
is the linking of identifiers.
And perhaps the canonical example of this
is an SDK accessing both a persistent identifier along
with personal and sensitive user data.
Next, the SDK may send them off of the user's device
to their web server.
ARTEM VOROBIOV: Oh, yes, that one.
Let's get deeper into linking of identifiers.
What are the most common examples, Brian?
BRIAN EDMONDS: Good question we often
see that personal and sensitive user
data is linked to what we call a persistent device identifier.
From a privacy perspective, this is problematic.
It allows for the targeting and reidentifying
of users, which is precisely the behavior
that most privacy-conscious users are worried about.
ARTEM VOROBIOV: And what are some examples
of persistent device identifiers?
BRIAN EDMONDS: Some examples are mobile device
unique identifiers, like IMEI, IMSI, build serial number,
SIM serial number.
And, Artem, we should probably explain
that it's not just personal and sensitive user
data that should not be linked to personal device identifiers.
ARTEM VOROBIOV: Great point, Brian.
In fact, our user data and SDK requirements policies state,
and I'm quoting, "persistent device identifiers
may not be linked to other personal and sensitive user
data or resortable device identifiers."
The S policies goes on to be even more precise
and explains that Android advertising
ID is considered a resortable identifier
and can be linked with persistent identifiers
for either advertising or analytics use case.
Except for rare exceptions referenced in the policies,
this behavior is not allowed and will
be considered a violation of Google Play policies
that could result in policy enforcement.
So, Brian, to summarize, what are
some of your recommendations and reminders to educate providers?
BRIAN EDMONDS: Sure thing.
Here are five of my best practices.
Number one, keep up to date with Google Play policies
to make sure your SDK does not cause apps to be in violation.
Number two, support the latest API security and data
minimization features to properly protect sensitive user
data.
Third, help your customers understand
what user data your SDK may collect
and the reason for its use.
This is so that app developers can
include this in their prominent disclosure and consent
to end users and in their data safety form
and in privacy policies where it applies.
Number four, it's a best practice
to implement a consent-checking mechanism the app can
call so that you aren't collecting data
inappropriately.
And number five, don't transmit multiple identifiers
to the same endpoint without first reviewing
the linkage of identifiers, restrictions
referenced in the Google Play policies.
ARTEM VOROBIOV: I think those are great practices, Brian.
Thank you so much for sharing your expertise with us.
And for our viewers, I hope the video
helped you better understand Google Play SDK requirements.
Please make sure to visit Google Play Policy
Center and our Google Play Developers Community,
where you can ask questions related to SDK requirements
and other Google Play policies.
Thank you, and until next time.
[MUSIC PLAYING]