Apple’s privacy pillars in focus

Hi, everyone. I'm Lauren from Privacy Engineering, and welcome to "Apple's privacy pillars in focus." At Apple, we believe that privacy is a fundamental human right. Our devices are an important part of entertaining us and connecting us to one another, especially when we have had to stay connected from a distance. And what people share from within these experiences should be up to them. When people understand what happens with their data and are in control, they are more likely to engage with your experiences and let your app become a trusted part of their life. So, we have to work together to make sure that great features and great privacy aren't a tradeoff. This isn't always easy, so in iOS 15 and macOS Monterey, we are continuing to provide innovative tools that make it easier for you to protect people while building features that they will love. In this video, we will walk you through Apple's approach to privacy and introduce new technologies that make building new features while respecting people's choices as simple as ever.

Improving the privacy protections of your app can seem like a lofty goal, or you may not even know where to start, so we've simplified engineering privacy into a series of principles and related questions that you can ask yourself that guide how to design products.

So, what's our approach to privacy? At Apple, we have four fundamental privacy pillars. The first is data minimization, which requesting and only using data that you actually need. The second is on-device processing, which is processing data locally without sending it to a server. The third is transparency and control, which is providing people with a clear understanding and control over how their data is used. And finally, security protections help enforce the privacy protections on our platform. In practice, these guidelines translate to a series of questions that you can ask yourself about your features. For data minimization, do I need this data in order to make my feature great? For on-device processing, why does the server need visibility into this data? For transparency and control, what are we gonna use this data for, and how do we communicate that to people? And Finally, for security protections, how is this data protected in transit and at rest? Garrett and I will walk you through the new features that you can adopt to only collect the data that you need, protect your user's data, and a few technologies that may inspire you to think about new opportunities for privacy in your app. And then, Elliot will dive into how Private Relay works and how we applied the pillars to shape its design. Let's start with data minimization in iOS 15. The places that people go can reveal a lot about their lives. Your app may have great experiences that rely on location. But people may be skeptical of granting your app location access right away.

In iOS 13, we provided a new way for people to try out location features in your app by selecting Allow Once. But this experience can result in repetitive prompts. In iOS 15, there is a new way to build location-based features that more seamlessly blend in with your app's experience, while allowing people to choose when they share location. You can now add a Share Current Location button right into your app's experience. When people tap on it, your app will receive access to their location for that session, just like Allow Once. For many apps, only a few features may rely on location. Adopting the location button is a great way for you to build trust with people accessing location when they interact with the features that actually need it. When people tap this button for the first time, they'll learn how it works and select whether the app will have precise or approximate location.

The location arrow on the top left will then appear to signal to people that your app has received their location. Next time they tap a location button in your app, it will just work, without any prompts. The location permission is session-based and will last until they leave the app. This works just like allow-once access but is so seamless that it's a great replacement for while-in-use! Compared to while-in-use, location buttons let you offer a lower-commitment way for people to try out your location-based features. The button can be customized to fit in with the rest of your app by setting properties on the CLLocationButton. Some aspects of the button that you can customize include background color, text and location arrow color, and rounded corners. These location buttons are built to ensure that people intend to provide location to the app when the button is pressed. The consistent string and iconography enables them to be easily recognizable, and limitations on contrast, size, and shape ensures that they are visible. This means that iOS can confirm that the button was tapped directly. Location buttons are supported on watchOS, iOS, iPadOS, and macOS with Catalyst. Often, people have to make a big choice about location access right when they open your app. The location button gives people more precise control over when their location is used, while ensuring a more seamless user experience. Using the same technology as the location button, secure paste confirms that the paste button was tapped directly. Now, the OS can reliably distinguish user-triggered pastes from programmatic pastes that are initiated by the app.

In iOS 14, the paste-transparency notice let people know when apps access the pasteboard. This also helped you learn when an SDK included in your app may have accessed the pasteboard unexpectedly.

The transparency notice is no longer needed when people paste through the edit options. The notice will only be shown in the UI if the user did not initiate the paste themselves in the edit menu or through their keyboard. To improve your experience, shift towards only user-initiated pastes. If you need to access the pasteboard, you can use the data detectors to confirm that the content in the pasteboard is relevant to your application before you access it. The next pillar is on-device processing. On-device processing is a fundamental building block to core features, like Face ID, quick-type suggestions, and measuring blood-oxygen level. The main benefit of on-device processing is that you can build amazing features using sensitive data, without sending it to your server.

In iOS 15, we applied this principle to Siri in a big way. Siri is a great example of how we deliver powerful features with industry-leading privacy built in. From the beginning, Siri has always been designed to protect your privacy. Audio recordings are not stored by default. Your requests are associated with a random identifier, not your Apple ID. And we work to keep your personal information on your device. However, running large machine-learning models, like those used by Siri, typically requires racks of servers. But around the time we released iOS 12, we also added the Apple Neural Engine to our hardware. The Apple Neural Engine has enabled us to move more components of Siri on-device.

In iOS 13, we introduced the ability to generate the Siri Voice entirely on-device. This means that it became possible for Siri's response to your request to not leave your device.

In iOS 14, we introduced on-device keyboard dictation. This was the first high-quality speech-to-text model that we ran on-device. One concern that people still have with voice assistants is unwanted voice recording. To help address this concern, we are moving all automatic speech recognition models for Siri to run entirely on-device. By bringing on-device speech recognition to Siri, this means that, by default, the audio of your requests will not leave your iPhone or iPad. This new innovation is another step in the right direction for on-device processing. Moving Siri automatic speech recognition models on-device is a great example of how designing for privacy enables great new features. On-device processing means that Siri is incredibly fast. By no longer sending requests to the server and processing on-device, instead, Siri can respond to your requests faster. And now, you can even make some requests while offline.

The Apple Neural Engine has been a key part of moving more Siri processing on-device. In iOS 15, you can take advantage of the Apple Neural Engine, too. New in iOS 15, you can use the CreateML framework to train models right on an iPhone or iPad. Now, you can personalize models to each person who uses your app, leaving sensitive data, like photos, all on their device. Check out the Machine Learning team's talk, "Build dynamic iOS apps with the Create ML framework," to learn more. Next, Garrett will tell you about transparency and control on iOS 15 and macOS Monterey. Thanks, Lauren! Building clear transparency and understandable controls into your app can help you build trust with people. Knowing how you plan to use their email, photos, or health data, or who you plan to share it with gives people the comfort to explore your app's features and use your app more fully. So, today, we're going to talk through a number of examples of transparency and control on our platforms, making sure you know what steps to take for your app.

First, we'll talk about email-related transparency and control features.

You may have thought twice before providing your email address to a service before. People who use your app can have the same apprehension. They may be worried that their information will be shared with others or used to link their purchases or behavior across apps and websites. In iOS 13, Sign in With Apple introduced a new way to sign in to apps and websites, allowing people to hide their names or email addresses.

In iOS 15, these benefits are available everywhere, using Hide My Email with iCloud+. From Safari, where people can easily generate a new email address when filling in a form, to right in Mail, while composing a new message.

And these can come in from other channels. Anywhere you receive email addresses might have a Hide My Email address. When one of your customers uses Hide My Email, your email will land right in their inbox. Make sure to respect their decision and only request additional information, like their name, if needed for your experience. In order to make email rich and engaging, emails often contain remotely-hosted images. When a mail program displays one of those emails, remote images are fetched, revealing when, roughly where, and on what kind of device the mail was opened. Many marketing emails now include unique image URLs for each user, or even invisible pixels, specifically to link this information to people when they read their messages. This resulted in people choosing between text-only emails to preserve privacy, or rendering emails with full content, but revealing mail activity. In iOS 15, we're introducing Mail Privacy Protection. People can choose to have iOS privately load remote message content, hiding their mail activity. This is really cool! And it's great news for you. More people will read your emails, with all the images and visuals you included. If you've been using remote images to measure the impact of your campaigns, there are a few changes to be aware of. Since Mail content may be loaded automatically after delivery, the time of Mail viewing will no longer be correct. And since that content is loaded without revealing people's IP addresses and without detailed headers, the location and type of device reading the Mail aren't revealed. And you'll see your emails as being opened, regardless of if the user read it or not. Next up in transparency and control, we'll take a quick tour through focus and indicators.

New in iOS 15, if you have a communication app, you can assist people in Do Not Disturb or another Focus by requesting access to read their availability, then sharing that status within your app's experience. To request access to status, you'll need a NSFocusStatusUsageDescription key in your app's Info.plist, and the User Notifications Communication capability enabled in Xcode. For more information on Focus, check out "Send communication and Time Sensitive notifications." In macOS Monterey, we've complemented the camera indicator light with a recording indicator. Now, any time the built in microphone, or W1 or H1 audio device, is listening, people can see that with an orange dot in the status bar. Of course, part of building trust is not abusing it. Make sure your app runs the microphone only when it makes sense to people. As an example, if your app has a mute button, stop receiving audio from the system when muted. Make sure to test your app on macOS Monterey to make sure it behaves the way people will expect. Also, you can easily confirm that no third-party SDKs in your app are listening unexpectedly. Next, let's look at tools that provide transparency for recent app behavior.

App Privacy Report will enable people to understand what's going on with their everyday applications and will be available in an upcoming software update. It will reveal to people when your app accesses user data and sensors, such as Location, Photos, or Contacts and show who your app may be sharing data with by listing all the domains your app contacts, as well as the domains that websites accessed within your app contact.

App Privacy Report will be in Privacy Settings and can be enabled by people to better understand the apps they have installed. If people want to clear usage history, they can just turn it back off again. It's also important to note that App Privacy Report will not record ephemeral WebKit sessions by web browsers, such as Private Browsing Mode in Safari.

In iOS 15, Record App Activity provides export functionality for you to better understand your apps' behaviors. So, you'll want to grab the iOS 15 beta and turn on Record App Activity to get a head start on what people will see for your app in the App Privacy Report feature. Then, when you select Save App Activity, iOS will produce a JSON file. You should review the content of this JSON file to confirm your app behaves as expected.

So, let's take a look. The JSON will have a list of stream dictionaries, one for each time a binary accessed user data and sensors, like location or camera. Here's an example of a single access. First, search for all instances of the bundle IDs of all your app's binaries. From there, the timestamps can help you tie those accesses to your software behavior.

To see all the domains you've contacted, look below the section marker in JSON: there's a final dictionary. This uses bundle IDs for keys, so there's one dictionary for each of your app's executables. From there, you can see all domain contacts, when they were initiated, and if they were app or user-initiated.

Now, let me show you the difference between a connection by an app and a connection by a website. Connections made by SafariViewController and ASWebAuthenticationSessions are automatically tagged as connections by websites. You can also manually tag connections as being caused by a website if a connection is made on behalf of third-party content and isn't core to app functionality.

At standard layers, we've added an attribution enum to manually tag a connection. You'll need to specify "user." If you don't specify, connections will be marked as app traffic. This enum exists in NSMutableURLRequests, where you'll want to supply the MainDocumentURL, in NWConnection in the Network framework, and sockets. You can also tag connections via convenience methods in other Apple frameworks, such as LinkPresentation and AVFoundation. WKWebView has added new methods to pass an NSURLRequest, so you can tag your connections appropriately. For more info, see "Explore WKWebView additions." App Privacy Report exists to provide transparency on app behaviors. And Record App Activity is a great tool to help you understand what people will see when App Privacy Report becomes available in an upcoming software update. Your app should access only data the user would expect and at the times they would expect. This is another opportunity to really build trust with your users, as they can understand more of what your application does. Also, Record App Activity is a good way to better understand the behavior of the SDKs you've put in your apps and confirm their practices align with yours. Integrate Record App Activity into your QA passes, and confirm that only the data you expect to access is present in the App Activity JSON.

And for our final section of transparency and control, I'd like to walk through a few existing areas where we frequently see questions from developers.

In late 2020, Privacy Nutrition Labels went live. Labels are designed to bring transparency in a glanceable format. Knowing what your app will do with their data makes it easier for people to trust you and engage with your app. We know how hard building good privacy is and that the best work can be invisible. Your label is a place you can show off the hard work you do to protect people.

Labels need to be inclusive of all your practices, all features, and all OS versions per platform. Labels must line up with your App Tracking Transparency usage, which brings me to the next topic. App Tracking Transparency was announced at WWDC 2020 and was required beginning in spring 2021 with iOS 14.5. Now, people can chose whether they want to be tracked across apps and websites. This lets people more easily trust new apps, and existing ones, too. To request permission, you'll need to provide a purpose string explaining why you want to track. You can further explain by putting additional information ahead of that prompt. If you choose to take this approach, there are a few details to keep in mind. For example, you shouldn't pre-prompt with a yes or no. For more information, refer to our Human Interface Guidelines. Now, some things to keep in mind. Tracking is about linking user data across apps and websites for advertising purposes or sharing with data brokers. For the detailed definition, see the User Privacy and Data Use page. App Tracking Transparency is about more than the IDFA, or Identifier For Advertising. The IDFA is one way to track, but App Tracking Transparency requires you to ask permission for any tracking. As part of your app's functionality, you might collect names, email addresses, or other identifiers. Linking data using this information is also considered tracking. Fingerprinting, or the collection of multiple bits of information to generate a stable device identity, is disallowed by the developer program license agreement, even if people give you permission to track.

If tracking is denied, all app functionality must still be available. Make sure that your App Tracking Transparency usage is reflected in your Nutrition Label.

Many of you embed third-party SDKs to avoid reimplementing functionality or to take advantage of helpful third-party services. You need to be aware of what those SDKs are doing. You're responsible for the behavior of your whole app. If an SDK collects data, you need to put that behavior on your Privacy Label. If an SDK is going to track, you need to get people's permission before calling those methods. Many SDKs have documentation related to the Privacy Nutrition Label. You can also reach out to them to ask. We know that advertising is a key part of how our developers thrive, so we've been hard at work building privacy-preserving ad-attribution technologies. If you run ads in your app, pay for ads to grow your customer base, or work directly in the ad ecosystem, here are some of the improvements.

We added conversion values and the source apps when possible, hardened fraud resilience, provided credit for alternate advertising flows, launched privacy-preserving web attribution, provided accounting for lost conversions, further hardened our privacy protections, and now, with iOS 15, we've added a specific pingback to you so you can measure ad campaign performance without help from the ad network. For more information on all these changes, check out "Meetprivacy-preserving ad attribution." And that wraps up our tour through the transparency and control pillar and all the actions you'll need to take with your apps.

The final privacy pillar is security. Security is a vital part of some of the most well-known features on our platform, such as ensuring only the person that you are iMessaging can read your messages. As an example of how security enables privacy, the iMessaging privacy assurance is upheld by end-to-end encryption. If you use CloudKit for your app, we've got some new security measures in store for you. You have always been able to have CKAssets automatically encrypted at rest with CloudKit.

In iOS 15, we provide functionality so you're able to have other data types similarly protected with strong encryption by just calling a function. This means that where you were previously handling encryption of user data yourselves, now we will provide the encryption and key management for all data types stored in iCloud. We're now supporting strings, numbers, dates, CLLocation and Arrays.

And it's really easy! You just set the key value pair on the record using the encryptedValues API, and CKModifyRecordsOperation to save. And to retrieve the encrypted value, just call CKFetchRecordsOperation with the same encryptedValues property.

And now, I'll hand it off to Elliot to talk about Private Relay, and how the privacy pillars helped shape its design decisions. Thanks, Garrett! We use the internet throughout our lives to express ourselves, to connect us to work and school, order food, and to help us learn new things at developer conferences. Wi-Fi in a hotel, cellular on the go, and even the internet in our homes-- wherever you go, and whatever network you use, privacy on the internet has never been more important. Let's walk through my Sunday morning after recently moving to Cupertino. After drinking a pot of coffee, I sit down on my broken couch and decide it's time to get a new one. I like the couches at Apple Park, so I open my Mac and browse to Furniture Site in Safari to find some similar styles. As soon as I connect, Furniture Site has my IP address. Which can be used to determine which city I live in, so Cupertino is also added to my activity profile. Behind the scenes, Furniture Site, like many other websites, gathers information about me to share with data brokers.

Furniture Site contributes the data about my couch browsing and my IP address is used to combine all of the other bits of data collected about me from many other places. When combined, the bits and pieces form a comprehensive profile about what I do on the web.

Adding it all together, the profile that is built represents a very personal and up-to-date snapshot about who I am and what's going on in my life right now. My profile even includes personal details, like my email address, and even my home address that I shared to have a table delivered. I never provided some of this information intentionally or wanted it to be shared. This kind of browsing history can't be cleared or reset and isn't even stored on my own devices. Not only can this data be used to serve ads on other sites that I visit, it can be used to influence my behavior without me knowing.

Later on Sunday, I started researching lawn mowers on Lawn Mower Site. Using my IP address and other profile information, I was served an ad about the couch that I looked at. Two days later, I received a couch catalog in the mail from Furniture Site. Internet tracking doesn't always stay on the internet. With a detailed profile, tracking can transition to physical space. Tracking reduces trust and can lead people to limit what they do on your website. Networks and equipment makers are able to collect this type of information, too, even discover behavior patterns from people who use your website or app.

Technologies like TLS and encrypted DNS help protect behavior patterns and your users' data from being exposed to network providers. You should adopt these technologies. To learn more about how to use built-in ways to protect internet privacy in apps, check the "Enable Encrypted DNS" and "Boost performance and security with modern networking" videos from WWDC 2020. In iOS 15 and macOS Monterey, we are introducing iCloud Private Relay, a new internet privacy service. Included in iCloud+, Private Relay makes sure every internet connection you make is encrypted, and your IP address no longer identifies you or gives away your location to websites in Safari. And the best part, with Private Relay's unique design, no one, including Apple, can see both who you are and which websites you visit.

Let's briefly explore how Private Relay works when I shop for my new home. First, when making a connection to Furniture Site, two different Proxy operators in the Private Relay Network are randomly picked so that no single operator has control or can see the whole picture. The proxy that accepts my connection from the internet is called the Ingress Proxy. The Ingress Proxy prevents other servers from seeing my IP address and encrypts my internet traffic to prevent my network provider from knowing what I'm up to. The relay back to the internet is provided by the Egress Proxy, which prevents the Ingress Proxy from seeing what website I'm contacting.

Private Relay manages network access in a way that doesn't require identity or account information, using RSA Blinded Signatures. A cryptographic blinding operation, performed by my device, lets me redeem it for network access, without giving away any information about my account or who's making the connection.

Using the public key from the Token server, a Private Relay Proxy can quickly verify network access permission.

Before making a connection, the Private Relay Access Token Server provides a bundle of different tokens to my device.

This gives me access to any proxy operator I choose, whenever I need it.

To enforce the separation of information between the proxies I picked, the connection is built using multiple layers of encryption. The proxies remove layer-by-layer when the connection passes through. Only my device can decrypt every layer, which is required to know that I am accessing the Furniture Site.

When making the connection, the Egress Proxy randomly selects an IP address to use. This helps to prevent linking my couch search to my lawn mower search, or my recent table delivery. Over time, Private Relay connections are automatically created and reused to provide IP address tracking protection and good performance. The way Private Relay hides my IP address has one more privacy benefit. Since my home IP address can be geo-coded to my rough location, the Ingress Proxy can share that location with me. This lets me inform the Egress Proxy which group of IP addresses to choose between. This is a great example of great features and great privacy. Websites can provide local content in Safari, while my precise location stays hidden.

Remember, the Ingress Proxy is the only one that can see my IP address, The Ingress Proxy converts my IP address to the same IP-based area that lawnmower site would have seen, then returns an approximated version back. In this example, the Ingress Proxy sends back "Bay Area, California," which is forwarded to the Egress Proxy to help it pick from a group of IP addresses that are assigned to that general area. With a regional IP address, sites that I contact can still find nearby stores.

Let's visualize how this works. When I connect, both sites see connections coming from an IP address that maps to my general area. The dots on the map represent possible Private Relay IP address locations that are shared by everyone in the region.

When the "Use Country and Time Zone" option is selected in iCloud Internet Privacy settings, no hint is provided to the Egress Proxy.

So, it picks a random IP address from the group that represents the much larger region that belongs to the Ingress Proxy. As a result, websites will see connections being made from a broad regional area. The same set of IP addresses are used by everyone in the region.

With the more generalized location setting, the Lawn Mower Site can now see a randomized location, which, for me, can be places like Los Angeles instead of Cupertino.

Privacy on the internet gets even better when Private Relay and Hide My Email are used together to prevent websites from using your IP and email address to track your activity across the web. We've gone over how iCloud Private Relay demonstrates key concepts from our privacy pillars. The data minimization concept is illustrated by using unlinkable tokens for network access. Only devices are able to process and decrypt all of the encryption layers in a Private Relay connection. IP address protections enhance control over tracking on the internet. Layered encryption and strong security enforces control over who can access internet browsing content. Our privacy pillars have helped us every step of the way when designing iCloud Private Relay. Back to Lauren. Thanks, Elliot. Great features and great privacy becomes easier when we all work together. We hope that learning about the new improvements in iOS 15 and how Apple builds privacy into our products, like Private Relay, has inspired you to consider opportunities for innovation when building your app.

To better protect people's data, encrypt new assets in CloudKit. For seamless location-based features, adopt the Share Current Location button. Lastly, check your Record App Activity log to prepare for the App Privacy Report and ensure it aligns with your nutrition label. Apple builds tools with privacy in mind so that you can build great apps for anyone on the platform. Having an ecosystem where people are excited to explore new apps and try new features while feeling in control of how their data is being used relies on all of us doing our best work. iOS 15 and macOS Monterey provide more control and insight than ever before, and we're so excited to see what you build. [upbeat music]