What’s new in privacy

Hi, I’m Lindsey, from Privacy Engineering, and welcome to “What’s new in privacy.” Privacy is essential to everything we do here at Apple.

It is a fundamental human right, and we design our platforms to protect people. Apple and all developers create products that occupy a privileged place in peoples’ lives, which makes it our collective responsibility to stay in line with their expectations and choices.

Designing for privacy can be challenging.

We use the The Privacy Pillars to help keep us focused on what matters.

Apple’s Privacy Pillars are Data Minimization, On-Device Processing, Transparency and Control, and Security. Data Minimization means only collecting the minimum amount of data that is required to power a feature. On-Device Processing involves performing computations locally on device and avoiding potential exposures associated with server-side processing. Transparency and Control is about honoring a user’s autonomy by making it transparent what data about them is collected and giving them control over if and how it is used. Security is the foundation that provides the technical guarantees and enforcements for privacy protections. iOS 18 and macOS Sequoia put these principles into practice. They introduce new pickers that let people share only they data they want, upgrade platform protections to avoid accidental over-sharing, Clarify permission dialogs to clearly outline what data is shared.

And introduce new platform capabilities for improving user privacy.

First, I’ll talk about new pickers that allow people to share just the data they want without permission prompts.

They create in-context data sharing experiences, including customizable UI to fit right into your app, while minimizing the data shared. They system renders an out-of-process picker on the screen at the same time as an app, without the app being able to read it.

Information from the picker can be selected, and then just that piece of data is shared with the app. We already provide pickers for Contacts, Photos, and Journaling suggestions. iOS 18 introduces pickers for new data types. The first new picker comes with FinanceKit.

FinanceKit offers access to a new category of on-device data from sources like Apple Card, Savings for Card, and Apple Cash. You can build great financial management apps with transaction data. Multiple easy adoption mechanisms minimize the data you need to manage and protect. Personal financial history can provide insight into personal interests, habits, and life events, so these tools empower people to share data with your app without over-sharing years of their financial data.

First is the transaction picker. This is the best choice when your app needs to access a set of existing transaction records, and not a complete and updating history.

When you invoke the Transaction Picker, the system draws the picker on top of your app, where transactions are selected from the presented list or using search. For example, an expense app could allow people to track and submit reimbursement for job-related spending without sharing purchase history for personal items.

That gives people confidence to engage with your features without worrying about sharing sensitive information.

Second is the ongoing access control.

When your app requests access to all financial data, the operating system will present a list of all the eligible accounts. People can choose which accounts to share, and for each account, select the earliest sharing date.

This built-in mechanism means people have an additional layer of choice to tailor their experience if they do not need to share older, potentially sensitive data.

Your app will receive just the relevant data set without any additional work.

Requesting access to all financial data with the FinanceKit API is only the right option when your app needs access to ongoing financial data.

For example, it might be a good fit for a personal budget tracking app.

Unlike the transaction picker, it requires a successful application for the FinanceKit entitlement. FinanceKit allows your app to build useful experiences for financial data with the tools for people to tailor the information set they would like to share. Learn more about how to implement it in your app in “Meet FinanceKit”.

iOS 18 and macOS Sequoia provide a new picker to bring image generation to your app in a private, out of process UI with Image Playgrounds APIs.

The Image Playground API gives your app access to the system-provided, personalized, and on-device image generation capabilities also used in the Image Playground app. To include this in your app, present the Image Playground Sheet, and optionally provide inputs, such as a text prompt or image.

People can iterate over images until they find one that they like.

Only the final image they choose is shared with your app. Image generation and selection are hosted by the operating system, so there is no permission prompt and your app will only receive the result explicitly shared. These pickers select data stored on your device, but some apps need access to bluetooth and the local network in order to connect to accessories. We applied the same principles behind data pickers to create AccessorySetupKit, the most streamlined and privacy-preserving way to set up accessories. It combines several types of permissions into one out-of-process picker, gives your app Bluetooth and Wi-Fi access to relevant accessories, and provides new accessory management tools. AccessorySetupKit combines all the required permissions into one straightforward flow. This replaces 3 different permissions formerly required, including the Bluetooth pairing prompt, the Wi-Fi network join prompt, and the Bluetooth accessory pairing confirmation.

All of those prompts can cause confusion, or make people worry about using your app because of the broad permissions required. When an app pairs, for example, a camera, it needs to communicate with it over Bluetooth and connect to its Wi-Fi hotspot. AccessorySetupKit enables both of these in just one tap.

After pairing the camera, the Pal About app can connect to it via Bluetooth, but cannot discover devices that have never been paired to the app. This benefits user privacy without compromising your accessory experience.

The updated Bluetooth permission in iOS 18 helps people only grant full access when they really need to, making this new tool, which doesn’t require full access, especially useful. It also makes paired accessory management simple. Your app can rename a paired accessory and attach an asset in Settings.

Forgetting the device removes the accessory and its permissions entirely.

People can also unpair accessories in the new accessory menu, or share an accessory permission with another app. AccessorySetupKit is the best way to pair accessories in iOS 18. The experience is smoother and more intuitive, and the resulting privacy permissions are exactly what your app needs to work with an accessory.

Learn more about how to implement it in your app in "Meet AccessorySetupKit".

These pickers all offer enhanced user control and minimize the data that you need to collect in order to provide great features in your app. iOS 18 and macOS Sequoia also bring upgraded platform protections that may have consequences for your app. First, are some changes coming to introduce private wi-fi controls for MAC address rotation on iOS and to bring MAC address protection to macOS. As a reminder, a MAC address is a unique identifier for a piece of hardware that is used to route network packets between different devices associated with the same network.

A device’s MAC Address is not protected by current Wi-Fi security modes, and can be seen and tracked by all other nearby Wi-Fi devices, as well as all devices on connected networks, even if the network is otherwise secure.

The MAC address wasn’t designed to be a stable user identifier, but because it never changes, it can be abused to create user profiles for tracking.

Private Wi-Fi addresses now rotate on iOS, and the same protections now exist on MacOS, too.

iOS devices will continue, as before, to use random, per-network MAC addresses. When “Rotate Wi-Fi Address” is on for a network, the MAC address for that network will change approximately every two weeks.

If “Rotate Wi-Fi Address” is off, then the random address for that network will not change over time.

Addresses for forgotten networks always rotate after at most 24 hours.

For public networks, the Rotate Wi-Fi Address setting will default to a static rotating address, and otherwise, it will default to a random address. In iOS 18, in Wi-Fi settings, “Private Wi-Fi Address” is now “Rotate Wi-Fi Address” to reflect the expansion of its functionality.

It will now provide MAC address rotation in addition to random initialization.

The default state and behavior of the toggle is based on the type of the network a device is connected to. This same functionality, with the same rotation policies, is now in MacOS too. If your app uses the Wi-Fi address for network management, rate limiting, or other purposes, consider how your app will work with these settings.

Next are notifications and settings for extensions running on macOS.

They provide transparency and control over software that extends the functionality of your apps and your Mac.

People are familiar with apps, but they don't always realize that apps can include background components, or that those components might run even when the downloaded app is not open.

For example, downloading the Pal About app might include a Dock Tile extension, which can update the app icon in the Dock with today’s date while the app is closed, and the Pal About QuickLook generator, which gets triggered when previewing a document with QuickLook. Those extensions provide useful functionality; however, it is not always clear when extensions are included with an app installation or where they persist on the system. To make the invisible visible, macOS now provides a system notification when extensions are installed.

Extensions can still be disabled in Login Items & Extensions.

There is now support for additional types of extensions to also generate notifications and be controllable in settings.

Your extension will not be blocked from running unless someone disables it in the Login Items & Extensions settings window.

In addition, Cron is off by default, but can be re-enabled in the same settings window.

Login items and extensions for your app now live in one place in macOS System Settings.

This makes it easier to understand and control if and when your app is running.

If you have a system extension and give instructions on where to go to enable it, update them to point to General -> Login Items & Extensions.

Finally, Directory Services plug-in, legacy QuickLook plug-ins, and com.apple.loginitems.plist file are all no longer supported.

All these changes bring clarity to what is running on the system so that people are in control. Last, is app group data container protection on macOS, which brings the great protections of sandboxing to both groups of apps, and apps that aren’t ready to sandbox all of their data yet. App Sandbox ensures data access is always expected by restricting access to protected resources.

If one app tries to access another app’s container, a prompt is presented to allow or deny to access. In this example, Pal About has tried to access data from another app’s container, and a prompt was presented. Data outside of a container can be read by any un-sandboxed process, and your app may store personal data that your users trust your app with, but do not want to share with anyone else. Sandboxing provides people with the control to use your apps without worry. Now, the same protections for a single app can extend to shared containers for a group of multiple apps. In this example, Pal About Calendar and Pal About Mail can share data about contacts and events with an App Group Container.

This is a great way to share data between your apps while keeping it protected. Similar to app containers, a prompt will be shown when apps from other developers attempt to access your groups shared container, requesting their permission prior to the data being shared. In this example, a prompt appears when Example Team Cal tries to access Pal About Mail data in the shared Pal About container.

If you have an app that you are not ready to sandbox entirely yet, you can also use group containers to protect a subset of that data.

Consider whether your app stores data that is particularly sensitive, like browsing history or photos. You can store just that data in a protected group container, and it will have the same protection properties. In this example, Pal About Browser can protect the files containing browsing history while keeping networking and styling resources un-sandboxed. To avoid displaying prompts when your own apps need to access your teams container, make sure to declare the entitlement in your Info.plist, format your group identifiers correctly, and use only the appropriate Foundation API, containerURL (forSecurityApplicationGroupIdentifier:), to get the path to your shared container.

For more detail on implementation, visit the documentation for App Groups Entitlement.

Now I’ll hand it over to Chris to discuss permission changes and new platform capabilities.

Hi, I’m Chris with Privacy Engineering. With each update, Apple strives to improve APIs to help your apps and give people more control over access to their data, to help them be comfortable providing their personal information when your apps need it. This kind of control enables you to provide features that people love, by collecting only what you need. iOS 18 and macOS Sequoia improve transparency and control over access to Local Network, Bluetooth, and Contacts.

First, I’ll go over what’s changed with sharing Contacts in iOS 18.

People gather many contacts over time, and each of these contacts include a lot of information about the people they belong to. When people choose to share their contacts, your app gets ongoing access to all of them. iOS 18 provides more transparency about the information included in contacts, and more control by providing the option to select the contacts that are shared. For apps requesting ongoing access to more than a few contacts, for example, a messaging app that offers friend matching, the contacts prompt is now shown in two stages. The first asks if contacts should be shared or not, and if “Continue” is tapped, the second presents the option of providing limited or full access. iOS 18 automatically presents the new flow when your app requests access to Contacts, and doesn’t require that you adopt any new API. If your app offers a feature that allows people to search for contacts, like searching for mail recipients, iOS 18 includes a new way for your app to add contacts incrementally with the Contact Access Button.

Instead of a full-screen picker, this button fits within your own UI, and allows your app to show results for contacts that your app doesn’t have access to. Using the button requires only a tap. When a unique match is found, and the button is tapped, the contact is shared, giving your app exactly what it needs in that moment. It should be rare that any app would require full, ongoing access to Contacts. With the Contact Access Button, you can provide the full contact picker experience without requiring full access, and help people feel more confident sharing contacts with your app. To learn more about accessing contacts in iOS 18, watch "Meet the Contact Access Button". We took the same principles that we used to improve access to Contacts, and applied them to Bluetooth and Local Network Changes to the Bluetooth authorization prompt in iOS 18 bring focus on transparency about the types of data shared with Bluetooth access, and the potential privacy risks if access is abused. People might think that Bluetooth is just used to connect devices, but access to Bluetooth can reveal a lot, including where the device is, and even be able to uniquely identify that device for tracking.

Granting persistent access to Bluetooth is a big choice, and the new prompt clearly visualizes the data that will be made available to your app when permitted. The updated Bluetooth prompt now shows a map that indicates the current location of the device, as well as a sample of associated devices. Your clear usage string explaining how your app will use Bluetooth, and this additional information, will give people what they need to make an informed choice. iOS 18 shows the updated prompt without the need to adopt any new APIs.

Last, I’ll cover what’s new when requesting access to devices on the Local Network with macOS.

Access to the Local Network enables apps to scan for, and attempt to connect to, other devices on the local network. This can reveal that someone is at home, on a familiar network, or even insights into their habits, hobbies, and social circles. macOS Sequoia brings control over Local Network Access to macOS.

When your app attempts to access data from the local network, a prompt is shown. Ensure that your app and its processes only request access in a contextual moment, and that you have defined a clear, descriptive usage string in your info.plist, as people are less likely to allow access when prompted without context.

A good purpose string is the best way to build trust in your app, by describing exactly how you plan to use the data that your app collects, including the data that local network access provides. For all apps, if you have the Bonjour Services key in your Info.plist, or the Networking Multicast entitlement, then you must include a local network usage description, or access will be blocked. If your app or its dependencies include Bonjour browsing or advertising, custom multicast, custom broadcast, or unicast connections that rely on the local network, then these changes apply to you. For more information about local network privacy, check out the video "Support local network privacy in your app".

In addition to improving the way that prompts are presented when your apps request data from certain categories, iOS 18 and macOS Sequoia offer new platform capabilities that focus on privacy and security.

First, is a system feature that gives people a new way to protect sensitive apps and the information inside them. Sometimes people hand their devices to others, like friends or family, so that they can look at a photo or play a game, but want peace of mind that those people can’t get into sensitive areas of their phone. Letting someone lock an app provides that peace of mind while giving people a new way to protect private data such as messages, dating interests, and health information.

iOS 18 brings an additional layer of privacy by letting people lock and hide any app, and requiring authentication before access.

When your app is locked or hidden, the contents of your app are not accessible without authenticating with Face ID, Touch ID, or passcode first. This includes all entry points, such as tapping on an action from the share sheet. The contents of your app will not appear in other places across the system, like search, or notifications, so that others won’t inadvertently see sensitive information.

Another way that you can secure the personal data that lives in your apps is by adopting passkeys with automatic passkey upgrades. Managing the lifecycle of the many passwords that secure all of our accounts can be a tiring and repetitive process. Passkeys are a standards-based password replacement that are easier to use, far more secure, and resistant to phishing.

In iOS 18 and macOS Sequoia, apps can automatically upgrade existing accounts to use passkeys when signing in. Account security is essential to user privacy, so if your app protects accounts with passwords, we recommend that you add support for passkeys. With automatic passkey upgrades, your app can upgrade existing accounts automatically during sign-in. Passkeys work alongside passwords, so you don’t have to adjust your login flow to accommodate them By adopting passkeys, you provide people with a secure and easy way to sign-in, and take away the burden of having to keep track of another password. To learn more about Automatic passkey upgrades, watch "Streamline sign-in with passkey upgrades and credential managers".

Lastly, we’ve introduced tools for developers building apps with caller ID, who want to provide a great experience with Live Caller ID, without a server learning who’s calling. These tools were designed for privacy, and take advantage of both private relay and private information retrieval.

Our implementation of private information retrieval in Live Caller ID uses homomorphic encryption, which enables a server to make use of an encrypted value without decrypting it. The server computes on the incoming cipher text, evaluates for a match, and then returns transformed cipher text back to the requesting device and the results are displayed. Implementing Live Caller ID without revealing something as sensitive as an incoming phone number was not possible without private information retrieval. Adopting these tools allows you to provide timely information without compromising user privacy. Open source resources for configuring your server will be available late 2024. To learn more about using the Live Caller ID lookup extension, see documentation for "Getting up-to-date calling and blocking information for your app".

Each of today’s updates were designed for privacy, with the Privacy Pillars to keep us focused on what matters: handling personal data with the care it deserves, and building tools for you to do the same while providing apps that people love. Use pickers for things like accessories, contacts, and transactions, instead of relying on full access. Prepare for cases where users lock your app, and take advantage of Wi-Fi address rotation. Lean into new and improved permission flows, such as AccessorySetupKit for Bluetooth accessories, and the Contact Access Button. Finally, bring privacy and security improvements to your apps with new platform capabilities.

Thank you for joining Lindsey and I on the journey to great features, with great privacy, for everyone.