Transcript
[ Music ]
[ Applause ]
>> Hello everyone and welcome
to Engineering Privacy
for your Users.
I am Julien from
Privacy Engineering
and I'm super excited
to be here today.
Do you ever wonder how
to learn from your users
without creeping them out?
Do you ever argue with your
team over which controls
and transparency to others
in order to gain user trust?
Well to answer these questions
today we're going to go
through privacy technologies
that we adopt
through privacy technologies
that we adopt
and how you can adopt them too.
As many of you know we at Apple
care deeply about privacy.
Just last year Tim Cook quote.
"People have entrusted us with
their most personal information.
We owe them nothing less
than the best protections
that we can possibly provide."
I mean it's not just Tim, all
of us at Apple from the top
down believe that privacy is
important to gain user trust.
In order to build
a healthy ecosystem
that protects your data.
So privacy engineering, we're a
team that works with many teams
across Apple in order to build
privacy into our products.
And year after year we
learn that best products
and services are those
that respect user privacy
without compromising
the user experience.
They are great services
that have amazing features,
They are great services
that have amazing features,
and also respect user privacy.
They encourage users
to engage with your app
by offering transparency,
control, consent,
but also securing the
data, minimizing the data
that you collect and limiting
the use of the data you collect.
As more and more
sensitive information is put
on our devices, we believe
that privacy is becoming
a more valuable commodity
and it's worth your investment.
But privacy is also more
than just a set of rules
as they said here,
it's an opportunity
to do smarter engineering.
To consider other
types of designs
for the benefits of our users.
For example, it encourages
you to do more on the device,
to bring the intelligence
down to the device
for faster user experience and
less stress on the network.
So it encourages you to only
collect the data that you need
in order to improve
your services.
So today we're going to
talk about identifiers,
So today we're going to
talk about identifiers,
how to collect data tied
to those identifiers,
which kind of controls
and transparency to offer
to your users, as well as
meaningful choices and how
to build privacy into your app.
Let's start with identifiers.
Many of you every day rely on
identifiers in order to get
to know your users and analyze
their behavior over time.
And this is great, after
all great stories start
with good identifiers.
But, if you track everything
that your users do all the time,
it creates an uncomfortable
atmosphere for your users,
sort of a chilling effect
where people start to wonder,
if I tap on this link
is that link going
to be tracked back to me?
And as soon as your users
hesitate you start to lose them.
Identifiers are very
helpful in order
to build customized
services are essential to get
to know your users and offer
them useful predictions.
to know your users and offer
them useful predictions.
But if you use them for too long
to track everything you start
to build creepy suggestions that
may put your users at unease.
Identifiers are also super
helpful in order to fight fraud
and to prevent and
detect malicious use
as early as possible.
But they do not justify
collecting data indiscriminately
from all your users.
So what can you do?
Well there are a number of best
practices that we recommend.
First of all, favor
short-lived identifiers.
You don't systematically
need to make use
of persistent identifiers
that never change.
So you can make them change
automatically over time,
or make it very easy
to reset them.
Stick to random identifiers
instead of always
and systematically using
somebody's username,
email address, or phone number.
Most of the time
you don't need that.
And ask yourself do I really
need to authenticate my users,
or is it enough to have
an anonymous session,
an anonymous experience
with my users.
an anonymous experience
with my users.
By following some of these
best practices you're going
to make it very easy for your
users to engage with your app
without having to worry
about their privacy.
So let's have a look
at some examples.
In our own products we seek to
adopt these very techniques.
So for example in Spotlight
and Maps we have identifiers
that change periodically
automatically
so users can engage with
these products without having
to worry about their privacy.
We customize the experience
of both for those products
within those session where
identifiers are the same.
We also seek to make it easy to
reset identifiers at any time.
So for example, in Siri, it's as
simple as toggling off Siri off
and on and you get a new
identifier it can start
over again, you're in control.
We also generally seek to
identify sessions and not users,
because most of the time
that's all that we need
to provide our services.
We also want to make it easy
for you to have this kind
We also want to make it easy
for you to have this kind
of techniques and
adopt these techniques.
So we have a number of APIs
that allow you to generate,
very easily generate
identifiers.
So for example, the universally
unique identifier's API is just
a simple line of code
in Swift, and allows you
to create an identifier
whenever you call it.
So a quick example, if you call,
whenever you call this
API you get a new 128-bits
random numbers.
It's such a large
number that this is going
to be a globally unique random
number whenever you call it.
So if you call it again,
you get another number,
call it again etcetera.
So then it's up to you
to decide what to do
with this random number.
You can use it to identify
objects, sessions, or users.
But what if you're looking
for something more stable,
you're not looking to
generate an identifier,
but you want to access one.
Well the vender IDs
here for that.
The problem it solves for you is
that it can just access this
API, it provides an identifier
for a device, it's very easy
then to customize your services,
for a device, it's very easy
then to customize your services,
you don't even have to
create an identifier.
And the way it works is
whenever you call this API
for a certain app,
for a certain vendor,
you will get the same
string returned back
to you, the same UUID.
So if you have the two
apps on the App Store,
made by the same vendor,
they can access the same UUID
and this just makes
it easier for you
to customize your
services across your apps.
Now, an app from a different
vendor will get a different
UUID altogether.
Note that users have
control over these
by uninstalling your apps.
Another stable identifier
persisted
by the operating system
is the advertising ID.
This one is to be used for
advertising purposes only
and the way it works is
whenever an app calls this API,
it will be able to
identify and get a UUID
for the current device.
And so this number will
be constant over time,
unless the user decides to reset
it, or turn it off altogether.
unless the user decides to reset
it, or turn it off altogether.
So in summary there are a
number of APIs that we provide
and each have a different
code it's about either
about generating an identifier
or accessing identifier
persisted by the system.
In addition to identifiers
for the system,
there are network identifiers.
So whenever you scan in
order to try to connect
to a Wi-Fi network, you reveal
you MAC Address for everyone
to see and that can be a
location privacy issue.
So in iOS 8 we changed
the behavior of scanning
so that we start using locally
administered MAC Addresses
that change over time
automatically, which is great
for your privacy, you
don't have to do anything,
because we make it much harder
for people to track you.
And we're very glad and proud
to adopt this technique not only
on iOS, but on macOS as well.
So if you're a Wi-Fi lender
and you have some equipment,
we encourage you to not
only test your equipment
with iOS seeds, but
also macOS seeds.
You must have heard of messages
and support for app extensions.
You must have heard of messages
and support for app extensions.
This is a super cool feature
and it is privacy friendly.
So app extensions will not be
able to access your context,
what they will see is
a random UUID instead.
And that UUID will be different
for each app extension
and in each chat.
So it's super privacy friendly.
Now, even if you're
not trying to access
or generate identifiers, you
may just be collecting some data
that looks innocuous.
But the problem there is that
by putting this data together,
you might actually end
up with a persistent
and stable device fingerprint
or an implicit identifier.
And that can be a problem
in case of data breech.
Where you thought your
data was anonymous
and then some researchers
out there showed
that actually it was very easy
to identify users in there.
So you don't want to be in that
situation so you should seek
to minimize the data
you collect.
And we also try to
help you there.
We seek to build a strong and
secure Sandbox that protects you
We seek to build a strong and
secure Sandbox that protects you
and your app from
malicious third parties
and also protects you from
unintended user fingerprinting.
So what we do there is we
provide you with strong
and amazing APIs
to build features,
but we provide a protection
and we limit the set of APIs
that could be used
for fingerprinting.
So for example, this year
we duplicated some APIs
that could be used
for fingerprinting
and we also whitelisted some
properties that are helpful
for you and blacklisted
other properties
that could be used
for finger printing.
So in summary what does
this all mean to you?
Identifiers are great,
but we recommend
that you favor short-lived
ones whenever possible
and that you also stick to OS
provided APIs in order to access
or generate identifiers.
We think that the users will
find it easier to engage
with your app and to
contribute their data.
So talking about data, let's
look at data collection.
Many of you every day
collect data from new users.
Many of you every day
collect data from new users.
And this is very helpful to
do a data-driven approach
to product development.
And this is super cool.
Now one day, you may end up in a
weird situation where you learn
so much about your
users that you know more
about them then they
know about themselves.
And that's weird.
So ask yourselves how would you
feel if they knew all the data
that you had about them?
Would you feel embarrassed?
What if you had to collect
this data from your dad,
or your mom, or your siblings?
Data is as much a
benefit as a risk.
And you need to balance
these two.
So what can you do?
We recommend you put in
place privacy friendly data
collection practices.
And in particular, instead of
collecting speculative data,
just grabbing everything you can
because maybe you have some use
in the future, try to stick
to key performance indicators
and collect data for those.
Here is a number of techniques
that you can adopt to do so.
Bucketing, sampling
and aggregation.
Let's look at bucketing.
The idea of bucketing is to
only collect the level of detail
that is sufficient
for your needs.
So, let's say you
wanted to know,
how often are your users
opening your in-app settings?
So we ask this question
for a particular user.
So it's quite simple, you
just implement a counter
and you look and you measure.
So let's say for this user,
test user, you went 86 times
on a given day to
your app settings.
So this information is helpful
right because it tells you
that maybe something is wrong
with your configuration.
Maybe you want to make
something more discoverable.
But do you really
need to collect this
with this level of precision?
Would it be sufficient to only
collect that somebody went
to your in-app settings
more than 50 times?
That would also give
you the same information
that maybe there's
something to improve
that maybe there's
something to improve
and to further refine
within your app.
But what if you're
interested to learn,
not just about a specific user,
but about a trend of users.
Well, you can just collect
and ask the same
question to all users.
And so you will say how often
do my users open in-app settings
on a given day?
Well it turns out like
if you're interested
to collect the average
you really don't need
to collect this data from
all of your users in order
to get good statistically
significant estimates
of the average.
It turns out if you only collect
data from 0.1% of your users,
you get a good estimate
of an average.
In fact, if you collect
from 10% of your users only,
your estimate is as
close as 0.1 precision.
So you really don't need to
systematically collect data
from all of your users
depending on what kind
of performance indicator
you're looking to collect.
But what if you're looking
to collect some data
that's very sensitive?
to collect some data
that's very sensitive?
Something that you really
shouldn't be collecting
in the first place.
But you're interested to learn
about it, what could you do?
Well, what if there was a
technology that allowed you
to learn from the crowd while
protecting individual data.
Well there is such a technology
and it's called differential
privacy.
So, differential privacy
is one of the safest ways
for users to donate their data.
It is one way to learn
from the crowd while
protecting individuals.
It provides strong
and mathematical
guarantees of privacy.
And this year we are
adopting it in iOS and macOS.
So, before I get
started here two things.
First, we believe that
this is yet another tool
in our privacy toolbox.
We have a number of tools
that we use for privacy
and this is a very exciting
one and promising one.
Second, this is going
to be a quick intro
Second, this is going
to be a quick intro
into a fascinating
technology and I'll do my best
to inspire you and get
you excited about it.
So let's get started.
I said it gives you strong
mathematical guarantees.
So let's start with
some theorems.
No, I think we can try to do it
and get the idea another way.
So the idea is there's some
data, something sensitive,
and you add noise to it and
you get some privatized data.
And then you can aggregate
that privatized data
to extract some signal.
So let's say an example, how
many hours did I work last week
to prepare these slides.
So it was a busy week, so
let's say I worked 128 hours.
So, I can add noise to that and
then what that means really is
that I change this number to
something that looks different.
So let's look a little bit more
about what I mean by noise here.
So, disclaimer this is
a simplified description
but that's going to give you
the gist of how it works.
So I have this number 128, and
we'll compute a projection,
So I have this number 128, and
we'll compute a projection,
it's sort of a hash
that I compute.
So what I do is a print a
very long vector full of zeros
and I only write one
1 at position 128.
So it's a huge vector full
of zeros, there's only one 1.
Then by noise, what I mean
is I'm going to flip some
of these zeros and
some of these ones.
So some zeros are
going to become ones.
And some ones are
going to become zeros.
The trick here is that zeros
have slightly more probability
to remain zeros than
to become ones.
And ones have slightly
more probability
to remain ones than
to become zeros.
So this is one way to
obscure your data prior
to sharing it with Apple.
It's another thing that's an
interesting observation here,
is that if I were to
obscure your data twice,
even if it's the same number,
each time it will give
me a different result.
And unlike a typical hash
function, I cannot try
And unlike a typical hash
function, I cannot try
to do a dictionary
attack to try to figure
out what this value
corresponds to.
So this is all done
locally on your device.
So, this is all done
locally on your device prior
to sharing it with Apple.
So, in this example let's
say I want to know the amount
of hours people worked
at Apple last week,
so I worked 128 hours, Jessie
48 hours and Timmy 130 hours.
So we collect all of this
from all Apple employees
and the noise is added
locally on device.
And what Apple ends up
with is a cloud of binary
and noisy vectors,
where individually these vectors
are pretty much useless to us.
But we're able to combine them
together and average the noise
out and learn some
statistical properties.
For example, here the average
number of hours people worked
at Apple last week was 41 hours.
So the way we do that
is we actually sum
up all these vectors
and then we normalize.
And then we look at column
by column whether there is a
statistically significant value
by column whether there is a
statistically significant value
that is larger than random.
So why is this cool?
So we think it's really
cool because it's one way
to learn popular
items privately.
You can learn averages, the
presence of certain attributes,
or even frequencies
such as histograms.
And this is done in a way
where each individual
contribution is private.
Is kept private from Apple.
We can only learn
from aggregate.
But you might ask yourself what
happens if I'm the only one
that is contributing data here?
At some point maybe a user will
become an aggregate in itself.
Well, to avoid this
issue we used the concept
of privacy budget that restricts
the number of contributions
that can be made by any certain
device during a period of time.
We also don't have any
identifiers at all associated
with this information.
And we permanently delete
the data from our servers.
So let's have a look
at an example.
So let's have a look
at an example.
Say we wanted to learn
popular emoji's across people
that are opting in to
diagnostics and usage data
that we collect from customers.
So when people will start
to use their keyboards
and use emoji's we will
observe that locally on device,
and then Julien here,
Jessie and Timmy
which contributed their
data noised up locally
on device prior to
sending it to Apple.
And what happens is as more and
more people share their data,
we're able to extract
some information such as
which ones are the most popular.
So what's cool here is that one
use case we can then reorder the
UI to reflect that.
And we can come and do
better predictions on device.
And so this year we're
adopting this technology
in four types of use cases.
We're using it for
emoji's, as just discussed,
we're also using
it for new words.
So when we learn
words that are not
in our local dictionary,
such as slang.
We also use it for
Deeplinks where we can see
which Deeplinks are
popular within apps in order
to promote them in Spotlight
and also for Lookup Hints.
to promote them in Spotlight
and also for Lookup Hints.
So this is super exciting.
And we're looking forward to
collecting this with privacy.
But this is only collected
from people that have opted
in into diagnostic and usage.
So if you are not opted
in that path line,
we're not collecting
that data from you.
So you are in control.
So in summary what does
this all mean for you?
Well we think that differential
privacy is a very promising
technology in order
to do privacy friendly
data collection.
We're very excited to adopt
it this year on iOS and macOS
to do crowd-driven insight
at scale, with privacy.
We don't use any identifiers,
we don't collect any
raw measurements.
This is yet another tool
in our privacy toolbox.
And we hope to use it more and
more in the future in order
to build our future features.
We think that your
users will care
because they will see the length
at which we're willing to go
because they will see the length
at which we're willing to go
in order to protect
user privacy.
So we hope this is
going to encourage you
to develop privacy
friendly practices as well.
In order to speak to
transparency and control.
I'd like to invite
Jessie on stage next.
Thank you [applause].
>> Hi.
I'm Jessie.
I'm also on the privacy
engineering team.
I work on privacy on for
products such as Apple Music,
photos, and education.
So Julien went into great
detail to talk to you
about how you can identify your
users and collect necessary data
about them in order to
build great features,
but in a privacy friendly way.
So in addition to that it's
also important to be transparent
to your users about
these identifiers
and the data that you collect.
When you do they have
a better understanding
of their privacy
controls within your app.
And when users have that
better understanding,
you gain their trust and you
encourage their engagement
within your app.
So one way that we're increasing
transparency and control is
with advertising in iOS X.
So now in news and in the
App Store users are able
to see this blue Ad button
on any advertisement.
When they click on it
they see more information
about why they're
seeing this ad.
So when you and other developers
are purchasing advertisements,
you pick specific
targeted groups of users
to target your advertisements
to.
Well now users are able to
scroll through about this ad
to see exactly what,
which groups they fell
into for this advertisement.
In addition, users can also
go to privacy in Settings,
Advertising, View
Ad Information.
And we are being completely
transparent to them.
About all the user data we
have about them to serve
as advertisements in news
and in the App Store.
And this will be
available in a later seed.
So a way that we give users
control in advertising is
through Limit Ad Tracking.
So, as Julien talked
about earlier we have the
advertising identifier
about earlier we have the
advertising identifier
and you can use this
to track users
for advertising purposes
only on our platform.
When users toggle the
Limit Ad Tracking flag on,
this is signaling to us that
they do not want to be tracked
for advertising purposes.
So in iOS x we're taking
this a step further.
So when a user enables Limit
Ad Tracking the advertising
identifier becomes
a UUID of all zeros.
It is now technically
supported in code
that when a user enables
Limit Ad Tracking,
we cannot track them using
the advertising identifier.
Now if a user disables
Limit Ad Tracking,
your app can get access to
a new random identifier.
So you may be wondering, can
you still show advertisements
to users with Limit
Ad Tracking on?
Well of course you can.
You can show contextual
ads within your app.
Things that make
sense in the context.
You just cannot track them
using the advertising identifier
if they have Limit
Ad Tracking enabled.
And remember that it forbidden
to cache the advertising
identifier in your app storage
to cache the advertising
identifier in your app storage
as this does not give
users proper control
over resetting it.
So, what does this
all mean for you?
Well, there's an increase in
transparency for ad serviced
to users in news
and in the ad store,
and Limit Ad Tracking is now
technically supported in code.
We know that when users are able
to make these types of choices,
like enabling Limit Ad
Tracking this empowers them
to make good privacy decisions
that are right for them.
Another way that we give users
the ability to make these types
of decisions are
through consent alerts.
So in iOS, macOS, tvOS, and
watchOS, users have the ability
to decide which apps get access
to certain protected
classes of data.
Now protected classes of data
are things such as calendar,
contacts, photos, HomeKit.
So the first time that
your app requests access
to this protected class
of data and calls the API,
iOS shows an alert
like this one.
iOS shows an alert
like this one.
And at this point the user
has the ability to decide
if your app should
get access or not.
When the timing and the context
of the question makes sense,
the user can make the choice
that's right for them.
We call this a just
in time alert.
I want to talk to you
about all the new features
that we have this year, that
also have privacy settings
and consent alerts
along with them.
The first is the media
library privacy setting.
This give access to Apple
Music subscriber status,
subscriber store front,
adding content to a playlist,
and now reading from
the Media Library.
We know that users'
Media Libraries
and Apple Music subscription
information is extremely
personal and can be identifying.
So we want users to have
the ability to decide
which apps get access
and which don't.
Now if your app got access to
the Media Library in iOS 9.3,
you will continue to
have access in iOS X.
you will continue to
have access in iOS X.
So how do you know if
you already have access?
Well with most of
the protected classes
of data we have what's called
an authorization status API.
It has a little bit
of a different name
with each protected
class of data.
But this is the example
for Media Library.
So you can call this API and get
back one of these enum values.
If you see notDetermined
this can happen
from one of two reasons.
Either one, you haven't asked
yet, or two, you've asked
for access to this
protected class of data
but since then the user has
reset their privacy settings.
If you see denied, this means
that the user said don't allow.
They do not want your
app to have access
to a certain protected
class of data.
And at this point you
have a few options.
You can take the user down a
different route in your app
and show them all the
features that they can use
without giving you access to
this protected class of data.
Or, you can open up the
privacy settings for your app.
And at this point the user
could possibly make a different
And at this point the user
could possibly make a different
decision if they so choose.
Now if you see restricted,
this can happen
for one of two reasons.
Either one, there's a parental
restriction set on this device,
saying that your app cannot get
access to this protected class
of data, or two, this
app is supervised,
maybe it's in an education mode,
or an ed enterprise context.
And the device administrator
has said
that your app cannot get access
to this protected class of data.
And of course if you see
authorized you're good to go.
So we have some other
awesome new features
that also have privacy settings.
Another one is speech
recognition.
So this allows your app to
send in audio files to Apple
to be transcribed into text.
Now the reason that we want
users to have the ability
to decide which apps get
access and which don't is
because we want them
to understand
that if they grant your app
access you may be sending audio
files that are theirs
to be transcribed
into text from Apple.
You can request access to this
ahead of time with this API.
You can request access to this
ahead of time with this API.
We also have SiriKit.
This is really exciting.
Users can now make
requests in Siri
that are completed
with your app.
But in order for Siri
to understand what types
of request a user might make,
your app must first send
up contextual information
to Siri
about the user, and
about your app.
And we want users to have
the ability to decide
which apps send up this
contextual information to Siri
about them and which don't.
So you need to request
access to this ahead of time,
before any Siri requests
can be made.
And you can do this using the
request Siri Authorization API.
You also probably heard
about the TV Provider
single sign on feature.
Now, this allows
enabled television apps
to request access to a user's
subscription information
and sign them into
their app automatically.
Now, because this is
only for enabled apps,
reach out to your WWDR partner
manager if you're interested
in becoming one of these apps.
And everything you loved about
photos on iOS is now on tvOS
as well, and same with HomeKit.
And both of those also have
privacy settings, on tvOS.
So, in addition to these
awesome new features,
we also have some updates to
how your app requests access
to certain protected
classes of data.
So in 2014, we started requiring
all apps that requested access
to location to declare
so ahead of time
and to declare a purpose string.
We find that users
are more likely
to make the choice
that's right for them
when they understand why an
app needs access to location.
So, in iOS X we are
extending this
to all protected
classes of data.
So if your app is accessing
any of these protected classes
of data you will need to
declare so ahead of time
in your app's info
plist along with a clear
and meaningful purpose string.
So take a moment,
look at this list.
So take a moment,
look at this list.
Think is my app accessing any of
these protected classes of data?
How many of your apps
are accessing one?
Yeah. How about two or three?
Okay well you're going to need
to declare that ahead of time
in your app's info plist.
And if you're a tvOS developer,
these four protected classes
of data are available for
you to request on tvOS.
And you'll also need to
declare that ahead of time
in your aps info plist.
Now, I'm going to
quickly go through all
of the purpose string
key values,
key names that you'll need to
put in your app's info plist.
Now, you don't need to
write them down right now.
Because they'll be
available for you
in the development
documentation and in Xcode.
So, let's say you have the
next best disco light app.
The first time a user downloads
your app they can scroll
through the various features
and look at what they can do.
And then the first
time that they go
and add their first disco
light, at this point,
when it makes sense, your app
will request access to HomeKit.
when it makes sense, your app
will request access to HomeKit.
When the timing and the context
of the question makes sense,
the user will see the
consent alert show.
And at this point you have
the ability to write a clear
and meaningful purpose string
to go in that consent alert.
I'm going to show you now how
you can easily add your purpose
string using Xcode.
So you go to your app's
target, Info section,
custom iOS target
properties, add a new key.
In this case we're going
to choose privacy
HomeKit usage description.
And at this point we're
going to write a clear
and meaningful purpose string.
So we're going to put
this will allow you
to create disco light
shows using HomeKit.
When the context and
the timing makes sense,
the user now sees why we
need access to HomeKit.
And they're more likely to
make the choice that's right
for them.
So, what's going to
happen to your app
if you don't declare
access ahead of time?
if you don't declare
access ahead of time?
Well your app's going to crash.
So, to preserve privacy any
app built on or after iOS X
that attempts to request access
to a certain protected class
of data must declare so ahead of
time in their app's info plist.
If you don't, your
app is going to exit.
So, your user will just see
your app exit on screen.
But this is the error that you
will see in the Xcode console.
It will tell you exactly
which protected class
of data you tried to access
and which key you need
to go add to your info plist.
Now, the reason that we crash
your app is because in the event
that your app was compromised
and you did not intend
for your app to request access
to this protected class of data,
we do not want your
app to get access
to any data you did
not intend it to do so.
And remember your
app is responsible
for any third party libraries
that you build into your app.
So be mindful that when
you choose those libraries
that they do not breech
your user's privacy.
that they do not breech
your user's privacy.
So what does this
all mean for you?
Well there's some awesome new
features in iOS X and tvOS.
And they also have
privacy settings.
You need to declare it ahead
of time that you're going
to request access to a
certain protected class of data
in your app's info plist.
And having a clear
and meaningful purpose
string will help users make
better decisions.
So in addition to these
awesome new features,
we also have some changes
to some existing frameworks,
to help you build in privacy
to your app from the ground up.
So first I want to talk about
some changes to pasteboard.
You can now set the expiration
time and a local only value
to any values you put
on the pasteboard.
Setting the expiration time
will make it so the value put
on the pasteboard
will be removed
after that date,
or on that date.
And setting the local
only value to true,
will exclude those values
from the universal clipboard.
will exclude those values
from the universal clipboard.
So here's an example, in
this case we have a UIImage
that we're going to
put on the pasteboard,
along with the string
"Hello, world."
We're going to set
the expiration time
to 120 seconds from now.
And we're going to set the
local only value to true.
So in two minutes, this
value will no longer be
on the pasteboard.
And, these values cannot
be pasted using the
universal clipboard.
So why would you
want to do this?
Well, if you know for a fact
that a user is copying
something really sensitive,
such as a password or a phone
number, or an email address
and you don't think it should be
on the clipboard for very long,
set the expiration time.
And if you don't think it's
appropriate for those values
to be used in universal
clipboard,
set the local only
value to true.
We've made a couple more
changes to pasteboard.
The first is that all named
pasteboards will be defaulted
to non-persistent and
setting the persistence
to non-persistent and
setting the persistence
of a pasteboard will cause
a deprecation warning.
In addition, trying
to get an item off
of the find pasteboard will
yielded an empty object
with no value.
And we really want
to encourage you
to use shared containers
instead of pasteboards
when you're trying to share
information on different apps
on the same device that are
all within your one team.
It's a much more
secure way to do it,
than putting items
on a pasteboard.
So a lot of your apps also
integrate with Core Spotlight.
And we have a couple of
things we want to talk to you
about today as well when you're
integrating Core Spotlight
into your app.
The first is that every
user tap should not result
in an NSUserActivity
being published.
You don't want to flood the
system with a bunch of events
that don't make sense
for the user.
Only really significant
events you think they'll want
to go look back for later.
And do not set eligibleFor
PublicIndexing to true
if the data is sensitive
user data.
You also probably heard
about our new support
for widgets in iOS X.
So when a user enables
a widget, it's available
on the home screen,
and the lock screen.
So because of this,
I want to talk to you
about some best practices.
Things that you can do when
you're creating your widgets
to remember that they're also
available on the lock screen.
So the first is that you
should evaluate the sensitivity
of data you put in your widget.
If you don't think
it's appropriate to be
on the lock screen, don't
put it in your widget,
or engineer a way for
it to not be there
when it's on the lock screen.
Make sure that the data is
consistent and predictable.
So when I enable
your widget today,
do I expect to see
something similar tomorrow?
How about a month from now?
It's okay if it's not
the same data every day,
but I should understand what
type of data could be there.
And remember that its data
that is file protection
type complete,
will not be available
on the lock screen.
So I want to show you an example
of what we're doing today
So I want to show you an example
of what we're doing today
with the Find My Friends widget.
On the lock screen the
location is not available.
We know that the location
of your friends is
extremely sensitive
and should not be
available on the lock screen.
So we have a string that
says unlock to view location.
And the location is not there.
Then once I use touch ID
to unlock my device,
we show the location.
Consider doing something like
this if you think that some
of the data in your
widget could be sensitive.
So Julien and I talked
to you about a lot
of different things today.
We started out by
talking about identifiers.
The real root of how
you identify your users
within your app.
And how you should favor
short-lived identifiers
and OS provided identifiers.
And we talked about how when
you're collecting data in order
to build your features
you should do it
in privacy friendly ways
such as bucketing, sampling,
or using new technology such
as differential privacy.
And how when you give users
transparency and control
And how when you give users
transparency and control
over those identifiers and
that data, you gain their trust
and you encourage
engagement in your app.
And that when you let
them make decisions
about their privacy
this empowers them
to make good privacy decisions
that are right for them.
And of course we showed you
some awesome new features
and some great tools to
help you build privacy
into your app from
the ground up.
For more information about
our talk you can visit this
web page.
Here are some related
sessions you might want
to check out this week.
Thank you.
[ Applause ]