[ Music ]
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
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,
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,
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.
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.
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
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
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,
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
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.
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.
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
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.
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
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
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?
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
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
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,
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
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
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.
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.
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
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].
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 10.
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
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 10 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
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.
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 10.
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
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.
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 10 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.
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 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
So, what's going to happen to your app
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 10
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.
So what does this all mean for you?
Well there's some awesome new features in iOS 10 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
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.
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
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
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 10.
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
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
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
Here are some related sessions you might want
to check out this week.
Looking for something specific? Enter a topic above and jump straight to the good stuff.
An error occurred when submitting your query. Please check your Internet connection and try again.