Transcript
[ Crowd Sounds ]
[ Applause ]
>> Hello, everyone.
My name is Georgios Kontaxis,
and together with Katie Skinner,
we are both very excited to be
here, today, to tell you about
Privacy and your Apps.
We are members of Privacy
Engineering, Apple, and we work
with teams across the company to
deliver privacy into our
products.
Here, at Apple, we care about
privacy.
And this quote from Tim Cook
reflects our philosophy.
We believe that privacy is a
very basic foundation for a
great app ecosystem.
We think that great apps should
offer the best user experience,
while respecting user privacy.
So, today, you will hear some
best practices to design your
apps with privacy in mind.
If you have existing apps, you
will be very interested in
updates to our platforms which
might affect you.
And you will learn about some
exciting new privacy features
that Apple is launching, this
year.
We know that your apps may rely
on user data to deliver great
features.
So, it is important that you
explain to your users how you're
using their data, so they
understand what is going on and
they feel comfortable engaging
with your app.
Also, you need to get their
consent in the right context.
For example, as they're about to
use a feature that relies on
their data.
iOS has built-in mediation
mechanisms for transparency and
consent, and you should consider
how you can best take advantage
of them.
iOS also offers users control
over their privacy.
So, your apps need to handle
cases based on the different
privacy decisions the user might
make, including changing their
mind at a later time.
Here's an example of how Maps is
using the iOS built-in
mechanisms to prompt for the
user's location.
As you can see, when prompting
Maps will clearly explain the
use cases, navigation, nearby
search results, and estimated
travel times.
And if the user chooses not to
grant access to their location,
Maps is able to handle that
gracefully and provide a subset
of its features.
If a user allows Maps the user
location, they will be aware
each time that happens, because
there is an indicator in the iOS
status bar to let them know.
And they can always go to
Settings, Privacy, Location
Services, see that Maps is using
their location and perhaps,
revise their decision.
We also, know that your apps may
rely on identifiers, for
example, to personalize the user
experience or to keep track of
feedback.
At the same time, your users
might wonder whether their
actions in your app are tied to
their device or to their person.
Luckily, there are great ways to
offer privacy friendly choices,
so that users are comfortable
engaging with your apps.
Specifically, identifiers can be
random, they can be anonymous,
they can be short-lived, and
they can be easy to reset.
And iOS offers built-in API for
you to be able to generate such
identifiers.
So, you should adopt those
instead of building your own.
As an example, consider the
Universally Unique Identifier.
It is a random 128-bit value,
which you can generate using the
Swift code, shown here.
And as you can see, three
consecutive calls using this API
will return three random
unrelated values.
And for example, you could
leverage the UIDs to generate
short-lived identifiers.
For example, you can associate a
new UUID with each session in
your app.
Another example is the vendor
identifier.
It is a more stable identifier,
because it is consistent across
all apps associated with the
same team.
As you can see, here, in the
example table, two apps that
belong to the same team all
generate the same vendor
identifier, while a third app
belonging to a different team
will have its own.
Also, keep in mind that if all
apps belonging to a particular
team are uninstalled from the
user's device and later
reinstalled, they will get a new
identifier.
Now, let's talk about collecting
data to enable your features.
Collecting data can be a
benefit, but also, carries
risks.
So, users might be uncomfortable
giving too much of their data,
if you do not sufficiently
justify the purpose.
And also, consider the burden on
your end to manage all that data
and keep it safe.
So, you should consider
aggregating data, summarizing
it, and extracting only the
information you need.
As an alternative, think whether
a sample of the data would
suffice, or whether you can
process the data on device
instead of sending their all
values to your server.
And later in this talk, you will
hear about some great new ways
to process data on device, using
iOS hardware and software.
Collecting raw data might reveal
additional information about the
users.
And as mentioned, this is
information that neither your
users nor you might want to
have.
As an example, consider you have
a new feature in your app, and
you're going to collect feedback
to see how successful it is.
So, you could instrument your
app to send back a timestamp to
your server each time the users
engage with your feature.
And that would give you the
information you're after.
But if you were to plot that
data over a timeline, you could
also learn that user one is a
morning person, because all of
their timestamps are in the
morning.
And user three opens your app at
night.
So, another way to collect this
information would be to say,
''Well, I will have my app count
the total number of times that a
particular user engages with my
feature, and send that count
back to my server, once a day.''
And that is a more privacy
friendly way to learn the same
information about the feature,
whether it's a customer or not.
But if you pay attention, you
might realize that now you know
that user one likes your feature
the most, among your users.
And that's not the question you
were trying to answer.
So, if you were to rephrase the
question as, ''How many users
engage with my feature more than
ten times a day?'' you could
have your app send back to your
server, a Boolean flag, yes or
no, whether the user has
exceeded that threshold within
the day.
And on your end, on the server,
you could calculate the
percentage of users that have
exceeded the threshold.
In this particular case, 66%.
Keep that percentage on your
server, keep track of it over
time as it changes, to
understand how your feature
behaves, and discard any user
specific data.
So, now let's go over some
updates which might affect your
apps.
I mentioned, earlier, that when
apps ask for access to user data
iOS will prompt users for their
consent.
And there are cases where we
think that users need as much
information as possible to make
this decision.
And your app is responsible for
providing this additional
context.
This additional context is in
the form of Purpose Strings.
And Purpose Strings are included
in the prompt shown to the user
by iOS.
Purpose Strings are defined as
keys in the Info.plist file of
your app.
And you can define those keys in
Xcode, like so.
Keep in mind that those keys are
mandatory.
So, if your app is missing a
Purpose String and tries to
access related data, it will
terminate with an error message
indicating which key is missing.
In iOS 10, these are the cases
where Purpose Strings are
required.
And in iOS 11, we are making
changes to Location, Photos, and
we're adding a Purpose String
for Core NFC.
Core location has enabled great
features in your apps.
Users appreciate being able to
navigate the world and find
interesting places through their
iOS device.
At the same time, we want users
to always be in control of their
privacy.
So, in iOS 10 apps can ask for
access to the user's location at
all times, or while the app is
in use.
In iOS 11 users will be able to
choose the When In Use option at
all times.
[ Applause ]
What this means for you, is that
your app will have to account
for cases where the user's
location is not available to
you.
And you need to define
additional Purpose Strings for
the When In Use option.
As a reminder, when asking for
the user location make sure you
do it in a meaningful way.
Make sure you prompt after the
user has engaged the feature
that requires their location, so
they understand why they're
being asked for their location.
When you prompt, make sure your
Purpose String provides the
necessary information for the
user to make a good decision.
And if possible, try asking for
When In Use, and escalate to
Always after the user has some
time to experience your feature.
If you have an app on iOS 10
that does not support the When
In Use option, this is the
prompt the user will see when
they upgrade to iOS 11.
As you can see, they can choose
the When In Use option, but
there is a warning that the app
does not natively support it.
If you have an app on iOS 10
that does support both the When
In Use and the Always option,
this is the prompt you will see.
Both Purpose Strings will be
included in the prompt shown to
the user.
You should update your apps to
feature a single Purpose String.
And you can do that by defining
a single key in your Info.plist
file, and use the Always and
When In Use key.
So now, let's talk about Photos.
The user's Photos library
contains a lot of information.
And we want you to be able to
leverage that information to
deliver great features.
At the same time, we want to
maintain a high level of user
privacy.
So, this year, we're adding two
new ways for your apps to
interact with the Photos
library.
Specifically, users will be able
to open a photo in your app
without the need for you to
prompt for access to their
entire Photos library.
So, this will make them more
comfortable using your app,
because they will have better
control over their data.
We're also, adding a Write only
access to the Photos library.
So, for example, if there's a
game that wants to save a
screenshot of the user
achievements, it can prompt for
Write, but not Read access to
the Photos library.
And users might be more willing
to grant that request.
And because of these changes,
when users upgrade their devices
to iOS 11, existing apps will
re-prompt for access to the
Photos library.
If you want users to be able to
take advantage of this ability
to open Photos in your app
without being prompted, you can
adopt the Out Of Process Image
Picker, and to find out more,
please visit the Photos session.
This is a great way to add a
photo in a user's profile or use
a photo in some other rare
action in your app.
Now let's look at the Write 0nly
case.
There is a prompt and a Purpose
String, so if you want to adopt
this, you need to decode the
Purpose String.
And make sure you provide enough
information for the users to
decide whether they want to use
this feature.
Now, let's talk about Core NFC.
CoreNFC is a new and exciting
iOS 11 framework, which allows
your app to use NFC reader modes
to interact with nearby NFC
tags.
So now, you can use NFC tags in
your app in novel and
interesting ways.
To adopt CoreNFC, you need to
declare the corresponding
Purpose String and provide the
necessary context.
And this Purpose String will be
included in the prompt shown to
the user every time your app
invokes CoreNFC.
Now, let's talk about the watch.
We want your apps to be able to
do more with the watch.
So, this year, we're expanding
the use of the microphone.
Today, in iOS 10, your app can
ask for microphone access, and
following the user's consent, it
can start recording audio while
in the foreground.
In the new version of watchOS,
you will be able to keep
recording while in the
background.
And if you stay in the
foreground you will be able to
use the new API to record audio
without showing the built-in UI.
Because we want users to always
be aware that their microphone
is active, if your app is in the
background, there will be an
indicator on the watch face.
And if the user taps on the
indicator your app will enter
the foreground.
Let's talk about Music.
We want your apps to be able to
take advantage of Music and
create great features.
So, part of this experience is
having a frictionless way to
authenticate the user while
respecting their privacy.
So, for example, if an app were
to ask for the user's password
to Music, that would be a
privacy concern.
Instead, apps should leverage
the fact that the users are
already signed into Music on
iOS.
And iOS has a built-in mediation
mechanism for giving your apps
access to a Music token.
Following the user's consent,
you can get that token and use
it to access output APIs to
retrieve personalized and
non-personalized information.
For example, search the iTunes
catalog or get information about
the user's library.
And remember, because the user
will have control over which
apps get this token, make sure
you provide the necessary
context in the Purpose String
for users to understand what you
want to do with it.
Now, let's talk about Safari
View Controller.
Safari View Controller is a
great way for users to browse
the web in your apps.
And in iOS 10 Safari cookies and
website data were available in
SVC instances, in Safari View
Controller instances, in your
apps.
This will change.
Now, in iOS 11 users will be
able to use an account to log in
a website in your app and
perhaps, use a different account
if they want to, to log into the
same website in Safari, or some
other app.
And we think that gives users
more control.
Specifically, what this means is
that Safari and Safari View
Controller instances will have
separate data stores for cookies
and other website's data.
And what this means for you and
your users, is that they will
still be able to browse the web
in your app the same way as
before.
But they may have to login,
again, to some of the sites they
visit.
This is what it looks like.
So, for example, I have
Apple.com cookies in Safari, and
I have different cookies in your
app.
So, this concludes the updates.
At this point, I would like to
invite Katie onstage to tell you
all about some exciting new
privacy features that Apple is
launching, this year.
Katie.
[ Applause ]
>> Thank you, Georgios.
Now, I'm going to focus on some
new privacy features, as well as
provide an update on
differential privacy, that we
introduced last year.
I'm going to start with on
device processing.
Now, On-Device processing has a
lot of benefits.
One of the first ones, is it
enables your functionality to
run anywhere your users are.
Whether they're at the beach,
like this, or on an airplane
flight, or even in areas of poor
cellular connectivity.
It also, avoids network latency,
as depending on where your users
are, this may take longer than
the actual processing that you
want to accomplish.
The speed of our devices, your
iPhones, our iPads, it keeps
increasing and increasing.
The iPhone 7 is 120 times the
processing power of the original
iPhone.
So, think through the different
tasks that you once thought were
not feasible on device, and you
should reconsider.
Now, as you all are at the
privacy session, I'm going to
talk a little bit more about the
privacy related benefits of
On-Device processing.
One of the first ones is access
to user data.
So, there are many different
types of sensitive data on
device.
And when you're clear to your
users about how you plan to use
that data.
Like for instance, if you tell
your users that the photo that
you take, if you apply a nice
halo on it, maybe a filter, that
stays on their device.
Until they choose to share it
with another user, or maybe back
it up with you.
Then, users are going to be more
likely to want to grant you
access to their data, and feel
more comfortable about it.
On-Device, you can also take
advantage of all the different
security features that are built
into our platforms.
These are things like data
protection, the Keychain, that
allow you to more securely take
care of user's data, without you
having to implement it,
yourself.
Now, in past developer sessions,
they're a great resource for you
to go and learn more about these
security features.
I would encourage you to go
check out ''Protecting Secrets
With the Keychain''.
It's a great place to start.
Now, when you're using and
keeping the data on device, that
means you don't have to write
code to send that data to your
server.
You don't have to write code to
securely manage and make sure
that, that data on your server
is secure.
Now, you all know the less code
you have to write, that means
the less bugs.
And the less bugs are less bugs
that an attacker can take
advantage of.
Because a data breach is very
serious, and there are a lot of
consequences.
But one of the consequences is
the loss of user trust.
Now, technologies like this can
help you avoid that, as well.
Now, I'm going to talk about
four new frameworks that allow
you to do these common tasks on
device.
Now, any type of processing that
you do within your app, you can
move to on device.
But here are four frameworks
that make it easier.
The first one is CoreML, Core
Machine Learning.
Now, this allows you to have a
simple interface to load and run
pretrained models.
There a lot of different models
that it supports.
But one of them is neural
networks.
The second framework I'm going
to talk about is VisionKit.
Now, VisionKit allows you to
identify faces within a photo,
as well as do scene
classification, and group photos
by the contents of the scene and
time.
One of the ones that I'm most
excited about is ARKit.
I think augmented reality is a
place where there's lots of
exciting things to come.
And I can't wait to get it in
all of your hands, to see what
kind of experiences you guys
create for our users.
Now, ARKit can allow you to
locate the device, as well as
items in the real world.
And then, it allows you to
augment on top of a camera
stream.
Now, lastly, we have NLP,
Natural Language Processing.
This allows you to identify what
language a customer may have be
entering text with, then.
And it also allows you to do
tokenization, as well as named
entity recognition.
Now, I'd encourage you to go
check out the talk introducing
CoreML, later this afternoon.
This will provide an overview of
the different features available
that you can take advantage of
on device.
Next, I'm going to talk about a
new framework available in iOS
and tvOS.
It's called Device Check.
Now, there are many developers
who are currently using a
variety of techniques to try to
identify devices.
Now, they may be trying to
identify and answer questions
like, ''Has this device received
a free trial?
Has this device participated in
fraudulent activity?'' Or, ''Has
this device done something that
is against your app's developer
guidelines?'' Now, in order to
achieve that goal, many
developers, though, I'm sure
none of you in this room, may be
collecting lots of information
in order to associate some state
with that device.
Now, to do that, they may be
collecting lots of information
like, how's the device set up?
What information is stored on
it?
And these developers may not
want to have this level of
information.
All they want to do is associate
some state with that device, in
particular.
Now, DeviceCheck allows you to
associate state with the device.
And this is done in a privacy
friendly way that you can
achieve without collecting
unnecessary information.
Now, DeviceCheck allows you to
store two bits of information,
as well as a timestamp
associated with one device.
And this is per team ID.
So, you can store 00, 01, 10, or
11.
And it's up to you to think
about what this means to your
application and your app logic.
Now, this information will be
maintained by Apple through
until you reset it, or you
update the state.
So, this means it will be stored
by Apple through deletion of
your app, reinstallation of your
app, through erase all contents
and settings, as well as
transfer of that device between
users.
Now, we know users sell devices
to others.
We know they transfer them to
other siblings or other people
they know.
So, this information will be
maintained through that.
Now, as I mentioned before, it's
up to you to figure out what
these states mean to you.
So, an example would be for app
A, if a user has completed a
free trial they will be assigned
state 01.
Now, you could have a different
app, app B.
And that same information, that
same state that a free trial has
been assigned or completed could
be assigned 11.
It's up to you to make that
decision.
Now, I want to go through the
flow and make sure you guys
understand how this works in
practice.
So, let's say there's an app
that's a news app.
And like I said before, it
grants a seven day free trial.
So, when my free trial is
completed the app wants to set
my state to 01.
So, first thing it's going to do
is query for a device check
token on device, send it to
their app server, and then via
server communication set the
state and send it to Apple.
So, send over the token and the
state that wants to be set.
So, then I decide that maybe I'm
not a huge fan of that news app,
anymore.
I want to delete it.
But then, I miss it couple of
weeks later, so I decide I'm
going to reinstall the app.
On launch, that app wants to
decide, ''should that user or
that device be given another
free trial''?
So, query for the token, send it
to the app server the same way,
and this time query for the
state of the device.
So, then because that device was
last set as 01, it will be sent
back to the app server.
And at that point it's the app's
job to figure out what to do,
next.
Should that device be granted
another free trial?
Should that device be granted,
maybe, a shorter trial?
Or no trial at all?
It's up to you to make that
decision.
So, as I said before, devices
can transfer between users.
So, let's say I sell my device
to Georgios, because I want a
different phone.
I want a new gold one, this
time.
So, then Georgios wants to
install the same app.
He likes the same news app.
So, it's going to query for the
token the same way, send it to
its app server, and then, query
for the state.
Again, 01 will be returned.
And this case, Georgios has not
gotten a free trial.
So, you need to think about how
to handle these type of cases.
Now, make sure that you have a
way that customers can reach out
or escalate if they are
experiencing issues with this.
And they need to come and reach
out to you, because at Apple, we
don't have any idea what these
states correspond to.
So now, I'm going to quickly go
through what a sample query
could look like.
As you can see, here's the
device token, the transaction
ID, which you generate, as well
as a timestamp.
Then, here's the response from
Apple with the state.
And then, if you want to update
the state, again have the device
token, your transaction ID that
you generate, as well as the
timestamp and the state you want
to set.
When you're using DeviceCheck
make sure to think through these
best practices.
Make sure you handle the case
where devices are transferred
between users.
A device's behavior can change
over time.
Additionally, think about the
recency of the data.
If the state was set a year,
ago, maybe that means something
different to you than if it was
this month.
This should be part of your
app's logic, but not the sole
source.
And think through how you
represent this state in the UI.
When Georgios goes to launch the
app for the first time, you want
to have a fresh experience for
him.
So, make sure you think through
that.
Now, you should be using
platform supported identifiers.
These are the application
identifier, the vendor
identifier, as well as the
advertising identifier.
We will continue to remove and
to remove entropy on our
out-of-the-app sandbox.
And as we have before, we will
continue to identify areas of
entropy and put them either
behind user control or remove
them.
Next, I'm going to talk about
Intelligent Tracking Protection.
This year, we're working to
reduce cross-web tracking.
Now, since the beginning, WebKit
and Safari have been leaders in
user privacy.
One example of this is blocking
third party cookies by default.
Now, I want to get this out
there, that Intelligent Tracking
Protection is not about blocking
content.
That's not what this technology
is.
It dynamically detects online
tracking across the sites that a
user visits.
And using an on-device
classifier, it will identify
tracking domains.
Once a tracking domain is
identified, then it will isolate
the third party cookies, as well
as website data for that
website.
And then, periodically, that
data will be purged.
Now, if the user interacts with
that domain, that is taken as a
signal that the user is
interested in that website.
And then, that website will be
whitelisted.
So, let's go through an example.
So, if example.com is identified
as a tracker, and the user
visits site 1, that embeds
example.com, example.com will
set the cookie foo.
Now, a user goes to site 2,
which also embeds example.com,
but here, example.com does not
have access to the cookie foo.
So, then it will set cookie bar.
And then, over time these
cookies will be purged.
Now, no cookies will be deleted
from first party websites.
Additionally, if the user
interacts with your website via
click, a tap, entering a form,
then note it will be
whitelisted.
You should not rely on storage
if the user does not interact
with your website.
And this is an important one to
understand; if your analytics
package relies on third party
cookies, they may be affected.
So, what we're trying to
achieve, here, is that users
only have long-term persistent
tracking and cookies from sites
that they actually intersect
with.
They actually interact with.
And then, all the other tracking
as the user navigates and visits
websites will be proactively
removed.
Lastly, we have an update on
Differential Privacy.
So, Differential Privacy was
launched on iOS and macOS, last
year.
Since then, we've collected
millions of privately donated
data per day, and it allowed us
to build user features with
privacy.
Now, I want to talk about two
new use cases, this year.
The first one is collecting what
data is commonly stored in
HealthKit.
Now, one of the challenges of
working on sensitive features,
or features that have sensitive
data, is you want to understand
how those features are being
used.
You want to understand what's
resonating, where users are
falling into issues or errors
are occurring.
But you know that collecting
data about what they're actually
interacting with may have more
information than you really
need.
So, one example here is, if you
collect what type of data, what
data types the user has stored
on their device, things like
blood glucose.
Things like Workout, that could
convey other additional
information about their health
or about any conditions they
have, or how active they are.
And we don't really need that
level of information.
So, that's why it's so exciting
to have Differential Privacy at
Apple, because we can still get
information to continue to
iterate and build our features,
while respecting user privacy.
So, last year in the Privacy
session at the Developer
Conference, Julian [assumed
spelling] did a great job
deep-diving into how
Differential Privacy works at
Apple.
Basically, we collect privatized
donations like emoji, and as
more and more users contribute
these privatized emojis, we
learn what are the most popular
emojis.
But the key part here, is we
learned nothing that's
associated by an individual
user.
For more information about how
Differential Privacy works at
Apple, I would encourage you all
to look at our session from last
year's Developer's Conference.
So, this year we're applying the
same process to health data
types.
So, we will learn the most
popular health data types, but
with learning nothing about the
individual user.
The second case is trying to
learn websites that either are
very slow or take up a lot of
battery life.
We all want a fast, speedy web.
But we don't necessarily want to
learn everything that a user is
visiting.
That's a lot of information
about that user, depending on
their web searches.
So, this is another example
where we get to use Differential
Privacy to then, reach out to
these developers who maybe, have
issues or are writing slow
sites.
So, then we can improve the web
for everyone.
Now, in summary, we are all here
today, and listening online and
here this week in an effort to
build great features for our
users.
Make something that our users
will love.
Make something that our users
think is fun, or maybe makes
their lives easier, their jobs
easier.
And what I want you to take away
from the past 40 minutes, is
several techniques and concepts
that you can apply within your
own app.
The first one is consent and
transparency.
Make sure to think about what
you're saying in your Purpose
Strings and be clear to your
users.
Also, adopt While In Use
location.
Together, we can build a healthy
app ecosystem, and DeviceCheck
is part of that.
We want to build a healthy web
for everyone, and Intelligent
Tracking Protection is a key
part of that.
With Differential Privacy, we're
building features and learning
how to build better features,
while protecting user privacy.
Now, one of the great things
about my job at Apple is I get
to work with a bunch of
different teams.
And everyone's working so hard
to build fantastic features and
APIs for you guys to take
advantage of, that will make our
users be delighted.
And that same passion, I get to
apply and work with great people
to apply to building privacy in,
from the start.
And making sure that we all are
building great features and
respecting users' privacy.
And what I want you to take away
from this is a bit of
inspiration.
Go home, work with the teams
that you have, and go build
great features that will
surprise and delight, but with
user privacy.
[ Applause ]
Now, for more information,
please go to this link.
And we mentioned a lot of topics
during this talk.
And so, I'd encourage you to go
check out some of these related
sessions, including the CoreML
one that's later this afternoon.
Thank you, very much.
And have a great Developer
Conference.
[ Applause ]