EDUARDO VILLASENOR: Hi, I'm Eduardo Villasenor, product
manager for the SDK runtime.
Today we'll share an overview of the Android privacy sandbox,
starting with a motivation for the effort,
followed by deep dives into the core technologies.
Privacy increasingly matters.
A recent Pew Research Center study suggests 72% of people
feel that almost all of what they do online
is being tracked by advertisers, technology
firms, or other companies.
And 81% of people say that the potential
risks they face because of data collection
outweigh the benefits.
Other studies suggest the majority of users
don't know how to protect themselves online.
People are concerned with what we call cross site or cross app
tracking.
Today, as we navigate our digital lives online,
our activities can be tracked across apps and websites,
and used to build digital profiles.
This enables, for example, a company
to effectively learn about my activities on different sites,
or mobile apps.
Today this tracking is commonly enabled through mechanisms
like third party cookies on the web,
or device identifiers on apps.
And while there are ways that we can control
some of this tracking, other tracking methods,
like fingerprinting, based on device or browser attributes,
are opaque, and not within our control at all.
So the Android privacy sandbox is
all about answering the question,
can we innovate to protect user privacy?
And if so, can we continue to enable
a thriving healthy mobile ecosystem?
We think the answer is yes.
The fundamental thesis of the Android privacy sandbox
is that protecting user privacy and enabling
a healthy mobile ecosystem are not a zero sum game,
and that the path forward is innovation.
So today we'll explore the first four
areas we are innovating in.
The SDK runtime, the Topics API, the FLEDGE API,
and the Attribution Reporting API.
And to speak to the SDK runtime, I'll hand it off to Nandana.
NANDANA DUTT: Thanks Eduardo.
Hello, I'm Nandana Dutt, engineering lead for the SDK
runtime, and I'm going to walk you
through a proposal for preventing covert tracking.
Currently all third party SDKs are
executed within the context of the app that includes it.
That is the Android application sandbox.
They inherit the same privileges and permissions
of the host app, as it allows access to the host app's memory
and storage.
This increase in code reuse has accelerated a vibrant ecosystem
of apps and SDKs, however this code reuse
has other implications that impact users and developers.
Users aren't always aware that the permissions granted
to the app are also available to any included third party SDK,
and users don't always know what the SDKs do with them.
App developers are responsible for everything the SDKs do,
including any data that's collected by the SDKs.
That's why we are building the SDK on time,
to limit the access of SDKs without undermining the benefit
to the developer community.
SDK runtime leverages Android's application
sandboxing to provide better isolation between SDK
and applications, across the two process boundaries.
Third party SDKs would run in the SDK runtime,
providing complete process isolation from the host
application, with full separation of data, storage,
memory, and permissions.
This offers the following benefits.
One, the user's data is protected
from undisclosed collection by SDK code.
Two, SDK distribution can be decoupled from application
distribution, and critical SDK updates
can be distributed directly.
Three, app developers can more confidently declare data usage
for their applications.
In addition, SDK runtime further restricts the data collection
abilities of SDK's.
There will be limitations on SDK's access
to permission, system services, external storage, ability
to load and execute additional code,
to communicate with other applications on the device,
and to run JNI code.
However SDKs, we'll be able to use the new platform
capabilities available via privacy preserving APIs.
Topics and FLEDGE.
Let's look at how to use SDK and SDKs runtime as an application
developer.
These APIs are available in our developer previews,
however they are subject to change until finalized.
To start out, specify the SDK runtime compliant SDK
in the application's manifest.
The load SDK call instructs a platform
to load the given SDK into the SDK runtime.
This should be ideally done just once at application startup.
Callback offers the handle for bidirectional communication.
Once the SDK is loaded, the application
can now communicate with it.
Send data provides an expressive API
to pass information to the SDK, similar to how
internet interactions work.
The application can invoke request surface package
to allow SDK to render media on its own views.
SDK run time offers tremendous benefits to user data privacy,
while sustaining an ecosystem where application developers
can thrive.
In order to support key use cases in the ecosystem,
our proposal includes privacy preserving API
that SDKs can use.
Let's take a look at these APIs.
To begin with, Amit will introduce
topics and FLEDGE APIs.
AMIT VARLA: Thanks Nandana.
I'm Amit, and next up are solutions
to help developers target users with the Topics API.
The Topics API is being built for developers
who want to deliver ads related to a user's interest,
like showing ads related to shoes for someone
who's interested in buying shoes.
The Topics API provides coarse grained non-sensitive interests
or topics inferred from a user's usage of their device.
By using topics determined on the device,
developers do not need to rely on cross app identifiers,
or share user data to determine the interests of a user.
Developers will be able to include topics
from their Topics API in their ads request.
The Topics API consists of multiple steps.
Apps are mapped to a public list of a few topics,
like sports or cooking.
On a weekly basis the device will
select a limited number of topics
based on the installed apps.
We may also include additional topics to noise the response
for additional privacy.
We will let users view and manage these topics
from their device settings.
When a developer calls the Topics API,
the device will return recent topics.
Developers may only get some topics from the API.
This will be determined by criteria
that prevent the information from being used to reidentify
a user across apps.
Here's an illustrative example on how calling the Topics API
will work.
The developer will configure topics manager
and call get topics.
On getting a successful result the topics
can be included in their ads request.
In addition to the Topics API, we've
proposed FLEDGE for Android, two APIs to support interaction
based targeting.
These apps are built for developers
who want to support use cases, including remarketing ads,
app install ads, and frequency capping.
The custom audience API will let developers register
a user for an audience group and associate relevant ads
with that group.
This information is stored locally on the device.
And the Ad Selection API will let multiple developers
run an auction with these audiences in a private trusted
runtime without sharing them.
Let's imagine that an app wants to reengage
with their users add that added items to a cart
but didn't complete their purchase.
After the user adds items to the cart in the app,
the developer will call the custom audience API
to register the user for a group say abandoned shopping cart.
When registering the user the developer
will include additional information
that will help them generate bids in the trusted runtime
of the ad selection flow.
This information can be updated daily.
Other apps will also register the user for custom audiences
based on interactions the user has in their apps.
When the user is in an app that wants to show an ad,
the developer will configure it and call the Ad Selection API.
The developer can choose who else will participate.
The ad selection flow will happen in a private trusted
runtime that has limited permissions
to prevent sensitive user information from being shared
outside of that environment.
Participating custom audience owners or their delegates
will run their custom logic to generate bids
for ads associated with custom audiences.
They can also filter out ads based
on factors, including how many times a user has seen the ad,
or if they already have an app installed on the device.
The developer that call the Ad Selection API
will then rank these ads with their own custom
logic and their own data.
The highest ranked ad will be the winning ad,
and will be shown to the user inside of that app.
Now I'll hand it over to Jon Markoff who will
talk about ads measurement.
JON MARKOFF: Thanks Amit.
Let's talk about measurement.
Hi, my name is Jon Markoff.
I'm a developer relations engineering manager
on the Android privacy sandbox, and I'm
going to walk you through the Attribution Reporting
API we recently announced.
Today it's very common to use cross party
identifiers such as the advertising ID and measurement
solutions.
We're building the Attribution Reporting
API to remove the reliance on ad ID,
while providing a solution for both
the attribution and conversion measurement
across Android and the web.
This new API will be useful when you
want to measure the performance of an ad campaign
that you are either running or serving.
This is important because the merchants
need to ensure that their ad campaigns are effective.
Do tweaks need to be made?
Should I spend more money?
The Attribution Reporting API aims
to answer these questions while providing better user privacy.
Let's look at the following example.
I'm browsing my morning news through my favorite news app,
and I come across an ad for a pair of shoes
that I think are really cool.
I haven't bought any new shoes in a while,
so I decide to click on the ad, which
takes me to the merchant's app selling the shoes.
The price is right, they have my size in stock,
and I decide to purchase the shoes.
The current measurement method sends
the news apps ad events the impression and click,
and the shoes app's purchase event to ad tech directly.
The ad ID links the ad events of both apps on the ad tech
server.
This means that the current ad tech provider can uniquely
identify this transaction, it knows
that you bought the shoes, how much you paid,
and potentially more.
Now let's take a look at how the ad impression, clicking
conversion, is reported using the Attribution Reporting API.
In the proposal the news app would register the ad click
with my phone.
Additionally, the shoe merchant's app
would also register the purchase with my phone.
Then the conversion would be attributed to the ad event
before leaving the user's device.
Additional noise would then be applied to the conversion
before being sent to ad tech.
The Attribution Reporting API supports two key use cases.
Event level reporting for optimizing
ad campaigns, and aggregate conversion information.
Event level reporting will provide information
about ad events that led to conversions.
This is important for building optimization models.
The details about conversions are
limited and noise to help protect user privacy.
Aggregate reporting both aggregates
and noises the data to provide higher fidelity information
than event level reports.
This allows for conversion measurement
without linking every ad and conversion
event to a unique device.
For example, a merchant may see a daily report of business
insights, including the amount of conversions
and the amount of money made.
The details of this conversion are
omitted so unique identifiers are not revealed.
We know this initiative needs input
from across the industry in order to succeed.
As a starter, if you haven't caught up
on the technical proposals for the SDK runtime
and the privacy preserving APIs, please check out the link
provided.
We've also started a developer preview program
that gives you an early look at the SDK system images
and docs for early assessments and testing.
We'll be iterating on it throughout the year.
There's also an issue tracker for feedback and questions
you may have about the initiative.
We are regularly sharing updates of the design and program.
Last but not least, please consider
signing up for email updates.
We've already heard from many partners about their interest
in working together to improve ads privacy on Android.
We invite more organizations to participate.
I'm Jon Markoff, and thank you for watching.