At Apple, we believe that privacy is a fundamental human right, and protecting people's privacy is at the center of everything we do. Discover how our engineering teams build privacy into all of our products and developer frameworks, and learn about the technologies and patterns you can adopt in your apps to build trust and protect your customers.
Hey there, I'm Justin from Privacy Engineering, and welcome to "What's new in privacy." At Apple, we believe that privacy is a fundamental human right, and protecting people's privacy is at the center of everything we do. You want people to love your app and make it part of their life. Building a great feature is how you get their attention, and building with privacy is how you maintain their trust and your place in their life. When people understand what data is collected about them and how it's used, they're more likely to fully engage with your app or service instead of choosing an alternative.
At Apple, we've prioritized great features and great privacy for the people who use our products, and we want to help you deliver this to your customers too. At Apple, we approach this goal of great features and great privacy with a set of actionable patterns, the privacy pillars. These are a great guide for you as well on how build privacy into your app. The first is data minimization. Use only the data needed to build the feature. Next is on-device processing. If the feature requires sensitive data, use the power of the device to avoid sharing it with the server. Third is transparency and control. If sensitive data is sent off device, make sure people understand what is sent, how it's used, and give them control. Finally, security protections. Protect sensitive data in transit and at rest, both on and off the device.
In this video, I'll talk about some platform changes that will impact you, some new privacy-enhancing features that you should adopt, and an important new feature with privacy impact.
First, I'll talk about some changes coming to the platform that will impact your app. iOS 16 and macOS Ventura include several important changes: a new device name entitlement that restricts access to the device name; the location indicator now shows app attribution in Control Center; improvements to Gatekeeper that verify the integrity of notarized apps in more places; launching Mac apps at login now notifies people of additions and has a simplified API; legacy Pasteboard access now requires permission.
I'll start with changes to device name access. To make it easier to identify devices, the user's name from their Apple ID account is included by default as part of the device name on iOS. Before iOS 16, the UIDevice API allowed apps to access the user-assigned device name. To better align app access of this value with user expectations, the UIDevice.name API will return the model of the device rather than the user-assigned name, regardless of how people customize it.
We understand that some apps have multi-device experiences that utilize the device name, like making it clear to people where a document was last edited.
If your app uses multi-device features and makes this visible in your app's UI, you can request the entitlement to access the device name. Even with this entitlement, sharing the device name with third parties other than cloud-hosting service providers is not permitted.
Next is updates to attribution for location use.
When apps use location, iOS displays an arrow in the status bar.
In iOS 16, swiping down from the Control Center indicates which app is using location. Make sure that your app only uses location when expected to avoid surprising people.
Now I'd like to talk about the Mac. Gatekeeper checks the integrity of newly-downloaded apps. In macOS Ventura, Gatekeeper will now check the integrity of all notarized apps, not just quarantined apps.
First, apps need to be properly signed. Starting with macOS Ventura, if your notarized app is no longer validly signed, it will be blocked by Gatekeeper on first launch. You should sign all your executables and bundles and ensure that their signatures stay valid when you make changes to your apps. In addition to an integrity check, Gatekeeper will also prevent your app from being modified in certain ways.
The most common way apps are modified is for updates. Apps validly signed by the same developer account or team will continue to be able to update each other. This will just work.
To allow another development team to update your app or restrict updates to only your updater, you can update your info-plist. For example, here, Unrelated App can allow Pal About to update it with just a plist change.
Simply add the NSUpdateSecurityPolicy you want to allow. Within NSUpdateSecurityPolicy, add “AllowProcesses”, a dictionary mapping team identifiers to an array of signing identifiers. In this example, the policy allows any process with the signing identifier com.example.pal.about signed by Pal About's team identifier to update your app. If an app is modified by something that isn't signed by the same development team and isn't allowed by an NSUpdateSecurityPolicy, macOS will block the modification and notify the user that an app wants to manage other apps. Clicking on the notification sends people to System Settings, where they can allow an app to update and modify other apps.
To prepare for macOS Ventura, you should sign the executables and bundles for your app and make sure those signatures remain valid after updates. Enumerate any updaters you use and adopt an NSUpdateSecurityPolicy. Remember that if your app tries to modify other apps outside the policy, users will need to allow this.
Next, I'll talk about launching apps at login on the Mac. In macOS Monterey and earlier, when someone logs into their Mac, apps can run at login using launch agents or daemons. This is convenient as it allows apps to run menu helpers, check for software updates in the background or synchronize data across multiple apps.
Sometimes when a user logs into their Mac, apps that aren't relevant open and may be in their way. In addition, apps or other software can access sensors or data like location. It is not always clear to people that this is happening, as what's running may not be visible. And for developers, it's not always clear which mechanism to use to launch at login: daemons, agents, service management…? With macOS Ventura, this is much simpler.
In macOS Ventura, you can use a new, single API to launch your app, launch agent or daemon at login. Your app will be allowed to launch at login by default, and users will be notified. If your app requires a daemon with elevated permissions, it will require admin approval to enable.
Clicking on the notification opens the Login Items pane in System Settings, where people can manage apps that launch on their system. The top portion controls apps that run at login, and the bottom portion controls other items that run at login. This pane now controls different ways apps can run at login, including agents, daemons, SMLoginItems, and apps that add themselves to open at login. Here's how you can use this new API.
The service management framework makes it easy for you to launch resources at login. Since all agents and daemons live inside your app bundle, you don't need to use an installer to write launch agents or create cleanup scripts anymore, and this works in Mac App Store apps too. Call the SMAppService API from your app to control when people get the notification and what your app icon looks like in Settings.
Next is pasteboard access.
Previously, a transparency notice let people know when apps accessed the pasteboard when they had not pressed paste in the edit options.
In iOS 16, the system confirms intent for all access to pasteboard items written by other apps. If your app continues to access values for pasteboard items using the UIPasteboard API, the system will display a modal prompt. There are three ways to avoid this prompt appearing in your app. The first is to use the edit options menu. The second is to use the keyboard shortcut. In the “Features to adopt” section, I'll talk about the third option, the new UIKit paste controls.
Those are the privacy changes coming to the platform that you need to know about. In addition, there are a few new privacy-enhancing technologies that make it easier for you to build seamless experiences with privacy into your app.
I'll start by talking about UIKit paste controls.
Add UIKit paste controls to your app experience so people can intuitively provide access to their pasteboard by pressing a button. Adopting UIKit paste controls allows pasting without an edit menu, keyboard shortcut or system prompt. The system confirms intent by verifying the button was visibly displayed and tapped. Customize these buttons to fit with your app's interface. Change the rounded corners or change the color of the text, icon or background. Just be sure the button has enough contrast and isn't hidden behind other elements or it won't work. Make sure to test that your paste buttons work as you expect.
Another tool to create a seamless experience while minimizing data access is media device discovery. Apps today use a wide range of streaming protocols, with custom discovery and communication logic.
To stream media using one of those protocols before, apps needed permission to access the local network, and often Bluetooth. This permission is needed because knowledge of all devices is required to manage device selection but this provides access to more information than is necessary and poses a fingerprinting risk. Media device discovery lets your app stream to selected devices without having to present network or Bluetooth access prompts. Streaming devices appear right in the same picker as AirPlay, and apps only see the device picked to stream to. This works thanks to DeviceDiscovery extensions.
This extension can search for local network and Bluetooth devices but is sandboxed separately from the app, so it can't send scan results back. This means no broad permission is needed for the app to access the local network or Bluetooth since the app doesn't see the whole network. Instead, the extension can only send the discovered accessories to the DeviceDiscoveryExtension framework.
The DeviceDiscoveryExtension framework presents the list of discovered devices in the picker, and after a selection is made, the system enables communication with the selected device. No other permissions are needed.
Protocol providers should create an app extension with DeviceDiscoveryExtension, extend AVRoutePickerView to handle user selection callbacks, handle user-selected networking devices in your protocol, download the sample app and extension to learn more. App developers should contact their streaming protocol provider to implement a DeviceDiscoveryExtension. Media device discovery is an opportunity to build great features with great privacy. Your app gets to access exactly the data it needs to stream - discovery is simple and prompt-free, and people get great network privacy. This is a win for everyone. Just like media device discovery provides permission to access only the devices needed without prompts, the PHPicker API provides permission to access only the photos needed without prompts. PHPicker is on the Mac now with macOS Ventura and the watch with watchOS 9. Update your Mac and watch apps to access photos without prompting users for access to all photos.
Next is private access tokens, which are a powerful tool to prevent fraud without CAPTCHAs getting in the way.
Private Access Tokens replace CAPTCHAs and are built using blinded tokens that allow website or API developers to recognize legitimate devices without being able to track those devices. Apple doesn't know what websites a device fetches tokens for, and the servers receiving the tokens don't learn the identity of the device sending the token. Private Access Tokens are part of the Privacy Pass IETF open standard and are the same technology we use to verify the authenticity of Private Relay users. To learn more, check out the video, "Replace CAPTCHAs with Private Access Tokens." Now I'll go over Passkeys.
Passwords are at the center of authenticating accounts and keeping personal data secure but they have serious issues. They're hard to remember, so people make them simpler or reuse them across multiple sites. And they can be phished.
Passkeys enable a more robust authentication solution and use the same instantly familiar UI style and biometric verification as password autofill.
Passkeys are built on public key cryptography, so the value the server stores can't be weak, and if it's revealed, it doesn't matter because it's truly public. Because passkeys are inherently linked to the website they correspond to, they can't be phished. For more information on implementing passkeys, there's a full video, "Meet Passkeys.” Those are the exciting and important privacy updates for you to adopt! One more important thing I want to talk about is a new privacy tool in iOS 16 called Safety Check. Safety Check is designed to help people in domestic or intimate partner violence situations review and reset access they may have granted to others previously.
Safety Check helps in the following ways: It stops sharing data with people by turning off location sharing in FindMy and stopping sharing in Photos, Notes and Calendar. It stops sharing data with apps by resetting system privacy permission for all third-party apps. It helps you sign out of FaceTime and iMessage on your other iCloud devices to ensure Messages and calls are sent only to the device in your hand. It walks you through signing out of other iCloud devices to ensure other devices can't receive updates on location from FindMy, Photos, calendars, etc. It helps you change passwords for both the device and iCloud account. And trusted phone numbers for iCloud two-factor auth. And it helps you manage emergency contacts to make any changes as needed. All these things together help people with threats to their personal safety control access to their data.
There are two ways to use Safety Check. The first is Emergency Reset, for crisis situations when you need to immediately reset access across people and apps.
The second is Manage Sharing & Access, which provides more fine-grained control over each capability of Safety Check.
Emergency Reset lets you quickly take action across all people and all apps and disables access to FaceTime and iMessage on your other devices. Then you are walked through securing your iCloud account to the device in your hand and reviewing your emergency contacts and trusted devices. Manage Sharing & Access lets you review person by person and app by app to review who you're sharing with. You can sort this by name or the type of information you're sharing. This is a great tool to understand and control your sharing with a particular person. It also can help you find an app with sensitive permissions installed by someone with access to your device.
Quick Exit is available in all Safety Check flows and quickly lets people exit the flow if they're concerned someone might see what they're doing. Pressing it returns them to the home screen, and the next time they enter settings, they'll be back on the main settings page, not in Safety Check. Safety Check helps people in domestic or intimate partner violence situations take back control of their private data. Privacy isn't just about making a decision in the moment you share data, but also being able to understand and change that decision at any time. This is just one example of how Apple designs for privacy. Designing for privacy in your app will help you build and maintain trust with your users. iOS 16 and macOS Ventura bring many new technologies to help you on this journey. Prepare for new platform updates like UI device name changes and Gatekeeper improvements. Adopt media device discovery extensions, UIKit paste controls, Private Access Tokens, and Passkeys. Thanks for joining me today. We can't wait to see how you build great features and great privacy into your app.
Looking for something specific? Enter a topic above and jump straight to the good stuff.
An error occurred when submitting your query. Please check your Internet connection and try again.