Hello, everyone. My name is Georgios Kontaxis, and together with Katie Skinner, we are both very excited to be here, today, to tell you about Privacy and your Apps. We are members of Privacy Engineering, Apple, and we work with teams across the company to deliver privacy into our products. Here, at Apple, we care about privacy. And this quote from Tim Cook reflects our philosophy.

We believe that privacy is a very basic foundation for a great app ecosystem. We think that great apps should offer the best user experience, while respecting user privacy. So, today, you will hear some best practices to design your apps with privacy in mind. If you have existing apps, you will be very interested in updates to our platforms which might affect you. And you will learn about some exciting new privacy features that Apple is launching, this year.

We know that your apps may rely on user data to deliver great features. So, it is important that you explain to your users how you're using their data, so they understand what is going on and they feel comfortable engaging with your app. Also, you need to get their consent in the right context.

For example, as they're about to use a feature that relies on their data. iOS has built-in mediation mechanisms for transparency and consent, and you should consider how you can best take advantage of them. iOS also offers users control over their privacy. So, your apps need to handle cases based on the different privacy decisions the user might make, including changing their mind at a later time.

Here's an example of how Maps is using the iOS built-in mechanisms to prompt for the user's location. As you can see, when prompting Maps will clearly explain the use cases, navigation, nearby search results, and estimated travel times. And if the user chooses not to grant access to their location, Maps is able to handle that gracefully and provide a subset of its features.

If a user allows Maps the user location, they will be aware each time that happens, because there is an indicator in the iOS status bar to let them know. And they can always go to Settings, Privacy, Location Services, see that Maps is using their location and perhaps, revise their decision.

We also, know that your apps may rely on identifiers, for example, to personalize the user experience or to keep track of feedback. At the same time, your users might wonder whether their actions in your app are tied to their device or to their person. Luckily, there are great ways to offer privacy friendly choices, so that users are comfortable engaging with your apps. Specifically, identifiers can be random, they can be anonymous, they can be short-lived, and they can be easy to reset. And iOS offers built-in API for you to be able to generate such identifiers. So, you should adopt those instead of building your own.

As an example, consider the Universally Unique Identifier. It is a random 128-bit value, which you can generate using the Swift code, shown here. And as you can see, three consecutive calls using this API will return three random unrelated values. And for example, you could leverage the UIDs to generate short-lived identifiers. For example, you can associate a new UUID with each session in your app. Another example is the vendor identifier. It is a more stable identifier, because it is consistent across all apps associated with the same team.

As you can see, here, in the example table, two apps that belong to the same team all generate the same vendor identifier, while a third app belonging to a different team will have its own. Also, keep in mind that if all apps belonging to a particular team are uninstalled from the user's device and later reinstalled, they will get a new identifier. Now, let's talk about collecting data to enable your features. Collecting data can be a benefit, but also, carries risks.

So, users might be uncomfortable giving too much of their data, if you do not sufficiently justify the purpose. And also, consider the burden on your end to manage all that data and keep it safe. So, you should consider aggregating data, summarizing it, and extracting only the information you need.

As an alternative, think whether a sample of the data would suffice, or whether you can process the data on device instead of sending their all values to your server. And later in this talk, you will hear about some great new ways to process data on device, using iOS hardware and software.

Collecting raw data might reveal additional information about the users. And as mentioned, this is information that neither your users nor you might want to have. As an example, consider you have a new feature in your app, and you're going to collect feedback to see how successful it is.

So, you could instrument your app to send back a timestamp to your server each time the users engage with your feature. And that would give you the information you're after. But if you were to plot that data over a timeline, you could also learn that user one is a morning person, because all of their timestamps are in the morning. And user three opens your app at night.

So, another way to collect this information would be to say, ''Well, I will have my app count the total number of times that a particular user engages with my feature, and send that count back to my server, once a day.'' And that is a more privacy friendly way to learn the same information about the feature, whether it's a customer or not.

But if you pay attention, you might realize that now you know that user one likes your feature the most, among your users. And that's not the question you were trying to answer. So, if you were to rephrase the question as, ''How many users engage with my feature more than ten times a day?'' you could have your app send back to your server, a Boolean flag, yes or no, whether the user has exceeded that threshold within the day.

And on your end, on the server, you could calculate the percentage of users that have exceeded the threshold. In this particular case, 66%. Keep that percentage on your server, keep track of it over time as it changes, to understand how your feature behaves, and discard any user specific data.

So, now let's go over some updates which might affect your apps. I mentioned, earlier, that when apps ask for access to user data iOS will prompt users for their consent. And there are cases where we think that users need as much information as possible to make this decision.

And your app is responsible for providing this additional context. This additional context is in the form of Purpose Strings. And Purpose Strings are included in the prompt shown to the user by iOS. Purpose Strings are defined as keys in the Info.plist file of your app. And you can define those keys in Xcode, like so.

Keep in mind that those keys are mandatory. So, if your app is missing a Purpose String and tries to access related data, it will terminate with an error message indicating which key is missing. In iOS 10, these are the cases where Purpose Strings are required. And in iOS 11, we are making changes to Location, Photos, and we're adding a Purpose String for Core NFC.

Core location has enabled great features in your apps. Users appreciate being able to navigate the world and find interesting places through their iOS device. At the same time, we want users to always be in control of their privacy. So, in iOS 10 apps can ask for access to the user's location at all times, or while the app is in use. In iOS 11 users will be able to choose the When In Use option at all times.

What this means for you, is that your app will have to account for cases where the user's location is not available to you. And you need to define additional Purpose Strings for the When In Use option. As a reminder, when asking for the user location make sure you do it in a meaningful way.

Make sure you prompt after the user has engaged the feature that requires their location, so they understand why they're being asked for their location. When you prompt, make sure your Purpose String provides the necessary information for the user to make a good decision. And if possible, try asking for When In Use, and escalate to Always after the user has some time to experience your feature.

If you have an app on iOS 10 that does not support the When In Use option, this is the prompt the user will see when they upgrade to iOS 11. As you can see, they can choose the When In Use option, but there is a warning that the app does not natively support it.

If you have an app on iOS 10 that does support both the When In Use and the Always option, this is the prompt you will see. Both Purpose Strings will be included in the prompt shown to the user. You should update your apps to feature a single Purpose String. And you can do that by defining a single key in your Info.plist file, and use the Always and When In Use key.

So now, let's talk about Photos. The user's Photos library contains a lot of information. And we want you to be able to leverage that information to deliver great features. At the same time, we want to maintain a high level of user privacy. So, this year, we're adding two new ways for your apps to interact with the Photos library. Specifically, users will be able to open a photo in your app without the need for you to prompt for access to their entire Photos library.

So, this will make them more comfortable using your app, because they will have better control over their data. We're also, adding a Write only access to the Photos library. So, for example, if there's a game that wants to save a screenshot of the user achievements, it can prompt for Write, but not Read access to the Photos library. And users might be more willing to grant that request.

And because of these changes, when users upgrade their devices to iOS 11, existing apps will re-prompt for access to the Photos library. If you want users to be able to take advantage of this ability to open Photos in your app without being prompted, you can adopt the Out Of Process Image Picker, and to find out more, please visit the Photos session.

This is a great way to add a photo in a user's profile or use a photo in some other rare action in your app. Now let's look at the Write 0nly case. There is a prompt and a Purpose String, so if you want to adopt this, you need to decode the Purpose String.

And make sure you provide enough information for the users to decide whether they want to use this feature. Now, let's talk about Core NFC. CoreNFC is a new and exciting iOS 11 framework, which allows your app to use NFC reader modes to interact with nearby NFC tags. So now, you can use NFC tags in your app in novel and interesting ways.

To adopt CoreNFC, you need to declare the corresponding Purpose String and provide the necessary context. And this Purpose String will be included in the prompt shown to the user every time your app invokes CoreNFC. Now, let's talk about the watch. We want your apps to be able to do more with the watch. So, this year, we're expanding the use of the microphone.

Today, in iOS 10, your app can ask for microphone access, and following the user's consent, it can start recording audio while in the foreground. In the new version of watchOS, you will be able to keep recording while in the background. And if you stay in the foreground you will be able to use the new API to record audio without showing the built-in UI. Because we want users to always be aware that their microphone is active, if your app is in the background, there will be an indicator on the watch face. And if the user taps on the indicator your app will enter the foreground.

Let's talk about Music. We want your apps to be able to take advantage of Music and create great features. So, part of this experience is having a frictionless way to authenticate the user while respecting their privacy. So, for example, if an app were to ask for the user's password to Music, that would be a privacy concern. Instead, apps should leverage the fact that the users are already signed into Music on iOS.

And iOS has a built-in mediation mechanism for giving your apps access to a Music token. Following the user's consent, you can get that token and use it to access output APIs to retrieve personalized and non-personalized information. For example, search the iTunes catalog or get information about the user's library.

And remember, because the user will have control over which apps get this token, make sure you provide the necessary context in the Purpose String for users to understand what you want to do with it. Now, let's talk about Safari View Controller. Safari View Controller is a great way for users to browse the web in your apps.

And in iOS 10 Safari cookies and website data were available in SVC instances, in Safari View Controller instances, in your apps. This will change. Now, in iOS 11 users will be able to use an account to log in a website in your app and perhaps, use a different account if they want to, to log into the same website in Safari, or some other app.

And we think that gives users more control. Specifically, what this means is that Safari and Safari View Controller instances will have separate data stores for cookies and other website's data. And what this means for you and your users, is that they will still be able to browse the web in your app the same way as before. But they may have to login, again, to some of the sites they visit.

This is what it looks like. So, for example, I have Apple.com cookies in Safari, and I have different cookies in your app. So, this concludes the updates. At this point, I would like to invite Katie onstage to tell you all about some exciting new privacy features that Apple is launching, this year. Katie.

Thank you, Georgios. Now, I'm going to focus on some new privacy features, as well as provide an update on differential privacy, that we introduced last year. I'm going to start with on device processing. Now, On-Device processing has a lot of benefits. One of the first ones, is it enables your functionality to run anywhere your users are. Whether they're at the beach, like this, or on an airplane flight, or even in areas of poor cellular connectivity.

It also, avoids network latency, as depending on where your users are, this may take longer than the actual processing that you want to accomplish. The speed of our devices, your iPhones, our iPads, it keeps increasing and increasing. The iPhone 7 is 120 times the processing power of the original iPhone. So, think through the different tasks that you once thought were not feasible on device, and you should reconsider.

Now, as you all are at the privacy session, I'm going to talk a little bit more about the privacy related benefits of On-Device processing. One of the first ones is access to user data. So, there are many different types of sensitive data on device. And when you're clear to your users about how you plan to use that data.

Like for instance, if you tell your users that the photo that you take, if you apply a nice halo on it, maybe a filter, that stays on their device. Until they choose to share it with another user, or maybe back it up with you. Then, users are going to be more likely to want to grant you access to their data, and feel more comfortable about it.

On-Device, you can also take advantage of all the different security features that are built into our platforms. These are things like data protection, the Keychain, that allow you to more securely take care of user's data, without you having to implement it, yourself. Now, in past developer sessions, they're a great resource for you to go and learn more about these security features. I would encourage you to go check out ''Protecting Secrets With the Keychain''. It's a great place to start.

Now, when you're using and keeping the data on device, that means you don't have to write code to send that data to your server. You don't have to write code to securely manage and make sure that, that data on your server is secure. Now, you all know the less code you have to write, that means the less bugs. And the less bugs are less bugs that an attacker can take advantage of. Because a data breach is very serious, and there are a lot of consequences. But one of the consequences is the loss of user trust.

Now, technologies like this can help you avoid that, as well. Now, I'm going to talk about four new frameworks that allow you to do these common tasks on device. Now, any type of processing that you do within your app, you can move to on device. But here are four frameworks that make it easier.

The first one is CoreML, Core Machine Learning. Now, this allows you to have a simple interface to load and run pretrained models. There a lot of different models that it supports. But one of them is neural networks. The second framework I'm going to talk about is VisionKit. Now, VisionKit allows you to identify faces within a photo, as well as do scene classification, and group photos by the contents of the scene and time.

One of the ones that I'm most excited about is ARKit. I think augmented reality is a place where there's lots of exciting things to come. And I can't wait to get it in all of your hands, to see what kind of experiences you guys create for our users. Now, ARKit can allow you to locate the device, as well as items in the real world. And then, it allows you to augment on top of a camera stream.

Now, lastly, we have NLP, Natural Language Processing. This allows you to identify what language a customer may have be entering text with, then. And it also allows you to do tokenization, as well as named entity recognition. Now, I'd encourage you to go check out the talk introducing CoreML, later this afternoon. This will provide an overview of the different features available that you can take advantage of on device.

Next, I'm going to talk about a new framework available in iOS and tvOS. It's called Device Check. Now, there are many developers who are currently using a variety of techniques to try to identify devices. Now, they may be trying to identify and answer questions like, ''Has this device received a free trial? Has this device participated in fraudulent activity?'' Or, ''Has this device done something that is against your app's developer guidelines?'' Now, in order to achieve that goal, many developers, though, I'm sure none of you in this room, may be collecting lots of information in order to associate some state with that device. Now, to do that, they may be collecting lots of information like, how's the device set up? What information is stored on it? And these developers may not want to have this level of information. All they want to do is associate some state with that device, in particular.

Now, DeviceCheck allows you to associate state with the device. And this is done in a privacy friendly way that you can achieve without collecting unnecessary information. Now, DeviceCheck allows you to store two bits of information, as well as a timestamp associated with one device. And this is per team ID. So, you can store 00, 01, 10, or 11. And it's up to you to think about what this means to your application and your app logic.

Now, this information will be maintained by Apple through until you reset it, or you update the state. So, this means it will be stored by Apple through deletion of your app, reinstallation of your app, through erase all contents and settings, as well as transfer of that device between users. Now, we know users sell devices to others. We know they transfer them to other siblings or other people they know. So, this information will be maintained through that.

Now, as I mentioned before, it's up to you to figure out what these states mean to you. So, an example would be for app A, if a user has completed a free trial they will be assigned state 01. Now, you could have a different app, app B. And that same information, that same state that a free trial has been assigned or completed could be assigned 11.

It's up to you to make that decision. Now, I want to go through the flow and make sure you guys understand how this works in practice. So, let's say there's an app that's a news app. And like I said before, it grants a seven day free trial. So, when my free trial is completed the app wants to set my state to 01.

So, first thing it's going to do is query for a device check token on device, send it to their app server, and then via server communication set the state and send it to Apple. So, send over the token and the state that wants to be set. So, then I decide that maybe I'm not a huge fan of that news app, anymore. I want to delete it.

But then, I miss it couple of weeks later, so I decide I'm going to reinstall the app. On launch, that app wants to decide, ''should that user or that device be given another free trial''? So, query for the token, send it to the app server the same way, and this time query for the state of the device.

So, then because that device was last set as 01, it will be sent back to the app server. And at that point it's the app's job to figure out what to do, next. Should that device be granted another free trial? Should that device be granted, maybe, a shorter trial? Or no trial at all? It's up to you to make that decision.

So, as I said before, devices can transfer between users. So, let's say I sell my device to Georgios, because I want a different phone. I want a new gold one, this time. So, then Georgios wants to install the same app. He likes the same news app. So, it's going to query for the token the same way, send it to its app server, and then, query for the state.

Again, 01 will be returned. And this case, Georgios has not gotten a free trial. So, you need to think about how to handle these type of cases. Now, make sure that you have a way that customers can reach out or escalate if they are experiencing issues with this. And they need to come and reach out to you, because at Apple, we don't have any idea what these states correspond to.

So now, I'm going to quickly go through what a sample query could look like. As you can see, here's the device token, the transaction ID, which you generate, as well as a timestamp. Then, here's the response from Apple with the state. And then, if you want to update the state, again have the device token, your transaction ID that you generate, as well as the timestamp and the state you want to set.

When you're using DeviceCheck make sure to think through these best practices. Make sure you handle the case where devices are transferred between users. A device's behavior can change over time. Additionally, think about the recency of the data. If the state was set a year, ago, maybe that means something different to you than if it was this month.

This should be part of your app's logic, but not the sole source. And think through how you represent this state in the UI. When Georgios goes to launch the app for the first time, you want to have a fresh experience for him. So, make sure you think through that.

Now, you should be using platform supported identifiers. These are the application identifier, the vendor identifier, as well as the advertising identifier. We will continue to remove and to remove entropy on our out-of-the-app sandbox. And as we have before, we will continue to identify areas of entropy and put them either behind user control or remove them.

Next, I'm going to talk about Intelligent Tracking Protection. This year, we're working to reduce cross-web tracking. Now, since the beginning, WebKit and Safari have been leaders in user privacy. One example of this is blocking third party cookies by default. Now, I want to get this out there, that Intelligent Tracking Protection is not about blocking content. That's not what this technology is.

It dynamically detects online tracking across the sites that a user visits. And using an on-device classifier, it will identify tracking domains. Once a tracking domain is identified, then it will isolate the third party cookies, as well as website data for that website. And then, periodically, that data will be purged.

Now, if the user interacts with that domain, that is taken as a signal that the user is interested in that website. And then, that website will be whitelisted. So, let's go through an example. So, if example.com is identified as a tracker, and the user visits site 1, that embeds example.com, example.com will set the cookie foo. Now, a user goes to site 2, which also embeds example.com, but here, example.com does not have access to the cookie foo. So, then it will set cookie bar. And then, over time these cookies will be purged.

Now, no cookies will be deleted from first party websites. Additionally, if the user interacts with your website via click, a tap, entering a form, then note it will be whitelisted. You should not rely on storage if the user does not interact with your website. And this is an important one to understand; if your analytics package relies on third party cookies, they may be affected. So, what we're trying to achieve, here, is that users only have long-term persistent tracking and cookies from sites that they actually intersect with. They actually interact with. And then, all the other tracking as the user navigates and visits websites will be proactively removed.

Lastly, we have an update on Differential Privacy. So, Differential Privacy was launched on iOS and macOS, last year. Since then, we've collected millions of privately donated data per day, and it allowed us to build user features with privacy. Now, I want to talk about two new use cases, this year. The first one is collecting what data is commonly stored in HealthKit. Now, one of the challenges of working on sensitive features, or features that have sensitive data, is you want to understand how those features are being used.

You want to understand what's resonating, where users are falling into issues or errors are occurring. But you know that collecting data about what they're actually interacting with may have more information than you really need. So, one example here is, if you collect what type of data, what data types the user has stored on their device, things like blood glucose.

Things like Workout, that could convey other additional information about their health or about any conditions they have, or how active they are. And we don't really need that level of information. So, that's why it's so exciting to have Differential Privacy at Apple, because we can still get information to continue to iterate and build our features, while respecting user privacy.

So, last year in the Privacy session at the Developer Conference, Julian [assumed spelling] did a great job deep-diving into how Differential Privacy works at Apple. Basically, we collect privatized donations like emoji, and as more and more users contribute these privatized emojis, we learn what are the most popular emojis.

But the key part here, is we learned nothing that's associated by an individual user. For more information about how Differential Privacy works at Apple, I would encourage you all to look at our session from last year's Developer's Conference. So, this year we're applying the same process to health data types. So, we will learn the most popular health data types, but with learning nothing about the individual user.

The second case is trying to learn websites that either are very slow or take up a lot of battery life. We all want a fast, speedy web. But we don't necessarily want to learn everything that a user is visiting. That's a lot of information about that user, depending on their web searches. So, this is another example where we get to use Differential Privacy to then, reach out to these developers who maybe, have issues or are writing slow sites. So, then we can improve the web for everyone.

Now, in summary, we are all here today, and listening online and here this week in an effort to build great features for our users. Make something that our users will love. Make something that our users think is fun, or maybe makes their lives easier, their jobs easier. And what I want you to take away from the past 40 minutes, is several techniques and concepts that you can apply within your own app. The first one is consent and transparency. Make sure to think about what you're saying in your Purpose Strings and be clear to your users. Also, adopt While In Use location. Together, we can build a healthy app ecosystem, and DeviceCheck is part of that.

We want to build a healthy web for everyone, and Intelligent Tracking Protection is a key part of that. With Differential Privacy, we're building features and learning how to build better features, while protecting user privacy. Now, one of the great things about my job at Apple is I get to work with a bunch of different teams. And everyone's working so hard to build fantastic features and APIs for you guys to take advantage of, that will make our users be delighted.

And that same passion, I get to apply and work with great people to apply to building privacy in, from the start. And making sure that we all are building great features and respecting users' privacy. And what I want you to take away from this is a bit of inspiration. Go home, work with the teams that you have, and go build great features that will surprise and delight, but with user privacy.

Now, for more information, please go to this link. And we mentioned a lot of topics during this talk. And so, I'd encourage you to go check out some of these related sessions, including the CoreML one that's later this afternoon. Thank you, very much. And have a great Developer Conference.