Privacy and Your Apps

Session 702 WWDC 2017

Protecting user privacy is a core principal in the Apple ecosystem. Learn what that means for the way you design and implement your apps, and learn about privacy-related changes, including new APIs, in the next versions of iOS, macOS, watchOS and tvOS.

[ Background 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 at 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'll 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 that 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 different privacy decisions the user might make, including changing their mind at another time.

Here's an example of how Maps is using the iOS build-in mechanisms to prompt for the users' 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 the user allows Maps to use the location, they will be aware each time it happens, because there's an indicator in the iOS status bar to let them know.

And they can always go into setting, privacy, location services, see that Maps is using their location and perhaps revise their decision.

We also know 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 feel 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 a swift code shown here.

As you can see, three consecutives calls using this API, will return three random, unrelated values.

And for example, you can leverage UUIDs 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, will 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 devices 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 don't 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 will suffice, or whether you can process the data on the device instead of sending their own 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 need 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 users engage with the feature.

And the app would give you the information that you're after, but if you were to plot that data over a timeline, you would also learn that user 1 is a morning person because all of their timestamps are in the morning.

And user 3 opens your app at night.

So, another way to collect this information would be to say, well I will have my app count the full number of times that a particular user engages with my feature, and sent 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 successful or not.

But if you pay attention, you might realize that now you know that user 1 likes your feature the most among your users.

And that's not the question you were trying to answer.

So, if you rephrase the question as how many users engage with my feature more than 10 times a day, you could have your app send back to your server a booleon 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 percent of the 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 purposes 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're making changes to location, photos, and we're adding a purpose string for CoreNFC.

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 to use option at all times.

[ Applause ]

What this means for you is that your app will have to account for cases where the users' location is not available to you.

And you need to define additional purpose strings for the when to 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 with the feature that requires the 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 a 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 maybe 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 [inaudible] file.

And that is the always and When In Use key.

So, now let's talk about photos.

The users 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 with iOS 11, existing apps will re-prompt for access to the photos library.

If you want your users to be able to take advantage of this ability to open photos in your app without being prompted, you can adopt the added process image picker, and you find out more, please visit the photo session.

This is a great way to add a photo in a users' profile, or use a photo in some other rare action in your app.

Now, this is in the write-only case.

There's a prompt and a purpose string.

So, if you want to adopt this, you need to declare the purpose string and make sure you provide enough information for the user to decide whether they want to use this feature.

Now, let's talk about CoreNFC.

CoreNFC is a new and exciting iOS 11 framework, which allows your app to use NFC reader mode 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 users' consent, it can start recording audio while in the foreground.

In the new version 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 a 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 go in 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 Music with token.

Following the users 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 users' library.

And remember, because you have control over which apps get this token, make sure you provide the necessary context in the purpose string for the users to understand what you're going to do with it.

And now, let's talk about Safari Controller.

Safari 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, we consider 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 us 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, in Safari you consider 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 log in 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 on stage 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, our iPhones are 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 devices 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 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 now 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 a 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 are 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 the camera stream.

Now, lastly we have NLP, Natural Language Processing.

This allows you to identify what language a customer may have, be entering text within.

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 DeviceCheck.

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 advice done something that is against your apps 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 is 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, device check 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 2 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, re-instillation 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 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 can 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 7-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 to 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, maybe I'm not a huge fan of that news app anymore.

I want to delete it.

But then I miss it a couple weeks later, so I decide I'm going to reinstall the app.

On launch, that app wants to decide should I be giving that user, or that device be given another free trial?

So, query for the token, send it to 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 in this case Georgios has not bought 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 can 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 devices' 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.

They should be part of your apps logic, but not the sole source.

And think of 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 entropy 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.

Note, 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 white listed.

So, let's go through an example.

So, if example.com is identified as a tracker, and the user visits site one, that embeds example.com, example.com will set the cookie foo.

Now, a user gores to site two, 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 a click, a tap, entering a form then it will be white listed.

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.

The 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 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 and developer conference, Julian 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 learned what are the most popular emojis.

But, the key part here is we learned nothing that's associated about 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 developers 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 had issues or 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 it's 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 and 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 mention 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 ]

Apple, Inc. AAPL
1 Infinite Loop Cupertino CA 95014 US