Build trust through better privacy

Hello and welcome to WWDC.

Hi, I'm Rohith, and I'm joined today by my colleague Brandon. Today, we're going to take you through how we build trust with our users through better privacy. I'll walk through our approach to privacy at Apple and then go through how we can apply our privacy principles to mitigate user tracking in our ecosystem.

So, what is our approach to privacy? At Apple, we have four fundamental privacy pillars that guide the products and features that we make. On-device processing-- processing data locally, without sending it to a server. Data minimization-- requesting and only using data that you actually need.

Security protections, which enforce the privacy protections on our platform. And transparency and control-- providing the user understanding and control over their data.

These four pillars help us build strong privacy protections into our features to continue building trust with our users.

Let's go through these one by one as I showcase how each influences changes that we've made this year, starting with on-device processing.

So, what is the benefit of operating on data without sending it off a user's device to a remote server? When you send data to a remote server, the user loses their ability to control who can access it, who the data will in turn be shared with and what the data may be used for. It additionally requires extra work to secure customer data against breaches or other threats.

But sometimes you need to collect data to train a machine-learning model.

So we're creating more ways to leverage Core ML to build and train models on-device. It's as easy as dragging and dropping these models into your Xcode project. And keeping data locally automatically takes advantage of the strong security protections we have on our devices.

We've been leveraging on-device learning for many of our features. Since iOS 13, we have been using private federated learning, or PFL, to build machine-learning models on potentially sensitive data.

PFL works by having devices send differentially private model updates instead of sending the user data. This way, we can build centralized models on our servers without ever having access to user data.

Last year, we used this technology to improve models for QuickType and Siri voice recognition from users who opt in to improve our products.

And this year, we're bringing new private federated learning use cases. We leverage the powerful Neural Engine in our chips, allowing us to improve machine-learning models without revealing user data to Apple or any third parties.

To learn more about using machine learning in your apps, check out the following talks.

Additionally, we have brought dictation locally to the device for many languages. So when you dictate on your phone, your voice data will be processed locally right on your device. And if you write apps that use dictation, you should specify to use the on-device dictation model to take advantage of this new technology.

This year, we also introduced a new HomeKit feature, face recognition, so that your cameras and video doorbells can let you know who is there based on the people that you've tagged in your Photos app or from recent visitors you identify in the Home app. If you opt in to this feature, your home hub will leverage on-device intelligence to recognize people who walk by.

On-device processing is essential to many of the new features we are introducing this year. You should look for new opportunities to use on-device processing and reconsider your existing features as our devices continue to become more powerful. This is a great tool to build trust with your users by minimizing the data that you send off the device.

Let me now hand it off to Brandon to talk more about our next privacy pillar, data minimization.

Thanks, Rohith. Privacy is about building trust with your users. One of the best ways to do this is use only the data you need to get the job done.

You can think of this as a careful balance between what data your app has access to and what it will use to deliver the feature.

Asking a user to share lots of personal information for features that will only take advantage of a little asks users to make a bigger choice than they might be ready for just to use that feature. Trust is built over time, and starting out by showing respect for users' data by asking for access to as little as possible is a great first step.

We know it's not always simple in practice, so this year we're introducing new tools that will make it easier for you to balance the amount of information your app has access to with a simple user experience. Today we'll talk about three types of data that are accessible in new ways in iOS 14: Photos, Location and Contacts.

Let's look at these in the context of a simple photo-sharing app.

The app needs access to Photos in order to pick the photo you want to share, Location, to find friends around you to share with, and Contacts, if you want to pick a friend to share with manually. Let's see how this might be implemented on iOS 13.

To select a photo to send, the user will be asked to give the app access to their whole photos library.

The app will ask for location permission to find friends in the area.

Or if a user wants to send the photo to a specific friend, the app will request access to all of their contacts, so the user can pick one to share with.

To look at the whole flow, this is a lot of access and a lot of user friction. To share a photo, the user had to answer three prompts, and in the process gave access to all of their photos, their precise location and all of their contacts. This is not great from a privacy perspective. While the user did have control over sharing their information, they couldn't use the core functionality of the app without saying yes to a lot of sharing.

It's also not great from a usability perspective. But we can do better. This year, we're introducing a few new technologies to help you improve this experience in your apps, starting with Photos.

For all apps that access the photos library on iOS 14, we're introducing the "Limited Photos Library." Users can give apps access to only a limited selection of their photos instead of their entire photos library. When the user taps "Select Photos," they can pick just what they want to share with the app.

This is the new prompt for all apps that ask for photos access on iOS 14. Please test your apps for compatibility, and for more information, check out the "Limited Photos Library" session. But this still requires a prompt, and we can do even better.

Most apps use only a small number of photos, like in this case, the photo you want to share with a friend.

PHPicker is a new framework that replaces UIImagePickerController that you can adopt to avoid prompting for photos access entirely. It features search and multi-select to help users find what they're looking for and doesn't require the user to grant Photos Library access.

PHPicker runs in a separate process from your app, but is rendered on top of it. Your app can't access the picker directly or take screenshots of the picker content. Only what the user actually selected is passed back to your app.

Unless your app has a strong need for access to all photos, such as to provide a backup service, you should use PHPicker. For more details on PHPicker, check out the "Meet the New Photos Picker" session.

So let's look at what that means in practice for our photo-sharing app. To pick a photo to share, the user is presented with the PHPicker, where they can select just the photos they want. This is a much faster user experience than going through a prompt and results in much better privacy.

Next, let's look at Location. In iOS 14, we're adding the ability for a user to share only their approximate location with an app.

Like Limited Photos Library, this is the new access prompt for all apps that ask for location on iOS 14. When the user taps the pill, the app will receive only approximate location updates.

Many apps today have features that are a natural fit for approximate location, like this photo-sharing app for finding friends in your area.

You can request approximate location by default when asking for location authorization