♪ Mellow instrumental hip-hop ♪ ♪ Hi there!

I'm Michael from Privacy Engineering,

and welcome to "What's new in privacy.
" At Apple, we believe privacy is a fundamental human right.
To respect and protect it is all of our shared responsibility.
For this reason, privacy is a central component to how we approach designing new
and improved features at Apple.
Many products and services have become a central mainstay in all our lives, and so
you have become a vital partner in protecting people.
Providing a great privacy experience in your app, where people understand and
control what data is being accessed and for what purpose, helps them trust your
app, especially in sensitive parts of their lives.
The privacy pillars are a great guide for you when building privacy into your app.
You might have heard us talk about them before, as these are four central ideas we
use at Apple to think about the privacy of our products and services.
The first pillar is data minimization: use only the data needed to build a feature.
This applies throughout your app's architecture, from the amount of data features
accessed, to data shared with application servers, to data that might be shared
with third parties.
Second is on-device processing: tap into the power of the device to process data
locally and avoid sharing it with any servers.
Third, transparency and control is about making sure people understand the what,
why, when, and where of data access and processing, and to give them adequate
controls before that happens.
And also, enable them to change their mind later.
The last pillar is security protections: apply strong technical mitigations to
enforce the other pillars, such as end-to-end encryption.
To help you implement the privacy pillars in your app, I will tell you about new
tools with privacy-centric design that you can adopt, give the latest updates on
important platform changes for privacy, and finally, I will talk about how the
spatial input model on Apple's newest platform was designed to protect privacy.
I will start with new privacy-enhancing technologies coming to Apple's platforms
that make it easier for you to build great apps with great privacy.
This includes a set of new APIs that allow your app to obtain access to content
seamlessly, while giving users fine-grain control over sharing, as well as new APIs
to better protect communication with servers and people.
I will begin with improvements to the Photos picker, designed to provide low-
friction access to photos.
Over the years, our photo libraries have grown massively as more and more of our
precious moments are captured there, starting with embarrassing childhood photos,
to the last hiking trip.
For this reason, a fundamental way to build up trust in your app is to empower
people to make fine-grain decisions about which data they share with your app and
when they share it.
So if someone wants to use your app to share the most scenic photos from their last
trip, they can do so without granting your app access to all photos.
This is what the Photos picker allows you to do.
This API gives your app access to selected photos or videos, without requiring
permission to access the entire photo library.
And in iOS 17 and macOS Sonoma, you can fully embed the picker into your app for a
completely seamless experience.
Even though the photos look like they are part of your app, they are rendered by
the system and only shared when selected, so the user's photos always remain in
their control.
With the new customization options, you can choose whether you want to show the
picker without any chrome, like this, or as a minimal, single row of photos that
can be scrolled horizontally, or as an inline version of the full picker, with a
new Options menu, providing controls about sharing photo metadata, such as captions
or location information.
The Photos picker is a great and fast way to obtain photos, as you don't need to
worry about obtaining permission for accessing the entire library, or designing and
implementing a photo-picking flow.
Consider adopting the picker to individually access photos instead of requesting
full access.
For an in-depth explanation of the picker's new capabilities, watch the video
"Embed the Photos picker in your app.
" And in case you are developing an app that has a strong requirement for accessing
the full photo library, iOS 17 has a redesigned permission dialog that includes the
number of photos and a sample of what will be shared.
This helps people make the decision that is right for them about what to share.
Because the preferences might change over time, the system also periodically
reminds people if your app has full access to the photo library.
Next up is the Screen Capture picker, a new API in ScreenCaptureKit for macOS that
enables people to share only the windows or screen your app needs when screen
sharing, while providing a better experience.
Prior to macOS Sonoma, when a user wants to screen share their presentation in a
virtual video conference, they need to grant the conferencing app permission to
record the full screen via the Settings app, resulting in a poor experience and
risk of oversharing.
With the new SCContentSharingPicker API, macOS Sonoma shows a window picker on your
behalf where people can pick the screen content that they want to share.
macOS makes sure to only share the selected windows or screen as soon as they are
picked.
Because of the explicit action to record the screen, your app is permitted to
record selected content for the duration of the screen capture session.
This means your app is not required to obtain separate permission to capture the
screen or build its own screen content picker -- this is all handled by
SCContentSharingPicker.
To make sure that people are always aware, macOS Sonoma also includes a new screen
sharing menu bar item serving as a reminder that your app is recording the screen.
Keep this in mind and only record screen content when it is expected.
When clicked, the menu expands to provide a preview of the shared content.
This also allows quickly adding or removing screen content to the capture session
or ending it altogether.
SCContentSharingPicker also provides options for customization in order to adjust
it based on your app's needs, such as preferred selection modes or applications.
For more details, watch "What's new in ScreenCaptureKit.
" Calendar is another area that now enables seamless experiences in your app,
especially for apps that only create new events.
The calendar provides a detailed view into people's lives, such as doctor
appointments or flight information, which is why people may be surprised or even
say no when your app asks for access.
For apps that are only seeking access to write calendar events, this can result in
a failure to add events, frustration, and maybe even people missing a concert or a
good friend's birthday party.
In order to avoid this issue, there are two important changes to Apple's platforms
for Calendar access.
First, if your app only creates new calendar events, I have great news for you:
with EventKitUI, your app does not need any permission.
This is made possible by rendering EventKitUI view controllers outside of your app,
without any changes to the APIs or functionality.
Second, if you prefer to provide your own UI for creating events, there is a new
add-only calendar permission, allowing your app to add events without access to
other events on the calendar.
This is another great way to integrate your app's events into the user's day,
without them having to worry whether your app might be fetching content of their
calendar.
And, should your app need full Calendar access later, you can ask once to upgrade.
It is best to make this request when linked to user intent.
When asked at an unexpected time or for an unexpected reason, it might be rejected
and can degrade the experience in your app.
Help people understand why the access is needed, by defining a meaningful purpose
string.
In order to provide the benefits of write-only access to all apps, there are two
important things to remember.
If your app has been granted Calendar access previously, it defaults to write-only
permission on upgrade to iOS 17 or macOS Sonoma.
Similarly, if you are linking against an older version of EventKit and your app
asks for Calendar access, the system only prompts for write-only access.
In this case, when your app attempts to fetch Calendar events, the system
automatically asks to upgrade your app to full access.
For more information about how to integrate EventKit and EventKitUI into your app,
watch "Discover Calendar and EventKit.
" Next is the new Oblivious HTTP API, which helps you to hide client IP addresses
from your servers and potentially sensitive app usage patterns from network
operators.
Knowing when and which apps people use on a daily basis can provide deep insight
into their lives.
Because cellular and Wi-Fi network operators can observe what servers someone
connects to, they can observe their personal app usage and life patterns.
And some network operators may be interested in using their position to learn about
how people use your app.
This could be especially sensitive to them, such as dating apps or apps for
specific health conditions.
IP addresses are an essential element for communication on the internet; however,
the IP address can be abused to determine someone's location or their identity.
Exposure to IP addresses can result in additional challenges for you if you want to
implement features with anonymity guarantees in your app, such as client analytics.
Apple platforms now support Oblivious HTTP, or OHTTP for short, in order to help
you protect people's app usage and IP address by separating the who from what.
OHTTP is a standardized internet protocol that is designed to be lightweight,
proxying encrypted messages at the application layer to allow for fast
transactional server interactions.
With OHTTP, the network operator can only observe a connection to the relay
provider, instead of your application server.
The cornerstone of this architecture is the relay, which knows the client's IP
address and the destination server name, but none of the encrypted content.
It is assumed that the relay always sees connections to your application server, so
the only meaningful information the relay gains is the client IP.
The final connection to your application server is made by the relay.
When the relay is operated by a third party, no single party has full visibility of
the source IP, destination IP, and the content.
This also enables you to add technical guarantees to features where you don't want
to be able to identify or track users, such as anonymous analytics.
With OHTTP support, you have the chance to build stronger internet privacy
protections that impact people meaningfully.
Services like iCloud Private Relay already make use of OHTTP for its great
performance and strong privacy protections.
For example, Private Relay uses it to protect all DNS queries.
To learn more about how you can adopt OHTTP, watch the network relay video.
Adopting OHTTP also means you will need to think about how to replace IP addresses
in your system architecture -- for example, to perform real-user detection.
Refer to "Replace CAPTCHAs with Private Access Tokens" from WWDC22 to learn how to
replace IP reputation systems with a privacy-preserving alternative.
Encrypting DNS queries is another essential part of protecting app usage from
networks.
To learn how, watch "Enable Encrypted DNS" from WWDC20.
The last new tool is Communication Safety and the new Sensitive Content Analysis
framework, which utilizes on-device processing to help you protect children in your
app.
Apple platforms and the apps you build have become an important part of many
families, as children use our products and services to explore the digital world
and communicate with family and friends.
Communication Safety helps families to keep children safe, by warning children and
providing helpful resources if they receive or attempt to share photos that likely
contain nudity.
And it is important that these protections are applied throughout Apple's
platforms, as well as in your app.
To this end, Communication Safety expands beyond Messages to also detect sensitive
content when sharing via AirDrop, when leaving a message on FaceTime, when sharing
contact posters in the Phone app, and in the Photos picker.
We also make these features available to everyone, no matter their age, with
Sensitive Content Warning.
And now, with the new Sensitive Content Analysis framework, you can detect
sensitive content in your app too.
It taps into the same on-device technology with system-provided ML models, so you
don't have to share any content with any servers.
And with this framework, this is possible for you without having to deal with the
complexity of training large ML models and packing them into your app.
Integration into your app is possible with just a few lines of code.
To get started, create an instance of SCSensitivityAnalyzer.
You can check the analysisPolicy attribute to decide whether analysis is needed,
and what kind of intervention should be shown if the image or video contains
nudity.
Then, call the analyzeImage method with the URL of the photo, or the CGImage, that
you want to analyze.
For analyzing a video, call the videoAnalysis method instead.
This returns a handler, so you can track progress and cancel the analysis if
needed.
To obtain the analysis result, call hasSensitiveContent on the handler.
If isSensitive is true, the image or video likely contains nudity.
In this case, your app should provide its own intervention -- which can consist of
blurring or otherwise obfuscating the image or video -- and an option to view the
content.
Also, check the analysis policy to tailor the intervention depending on whether
Communication Safety or Sensitive Content Warning is enabled.
You can find more detailed design guidelines for interventions in the Apple
Developer documentation.
Those are the new APIs to adopt to offer great privacy in your app.
In addition to that, there are a few privacy changes to existing features on Apple
platforms.
This includes new ways you can protect data in your app as well as privacy
improvements for Safari and Safari app extensions.
First, our new privacy protections for macOS, designed to help you protect data in
your app from other apps on the same device.
Locations on disk like the Desktop, Documents, and Downloads folder have a system-
managed permission.
This ensures people are in control over when apps have access to their private
data.
This model works well for files that people directly interact with, like a project
presentation or a spreadsheet with a budget.
Some applications might store private data in different locations, such as a
messaging app that has a database of sent and received messages, or a notes app
with vacation plans.
These files are often stored in locations like the Library folder, or for App
Sandboxed apps, the app's data container.
macOS Sonoma gives users additional control over who can access their data.
Specifically, macOS ensures that they give permission before an app can access data
in an application data container from a different developer.
This can impact your application in two ways.
First, if your application stores data outside of system-managed data stores, adopt
App Sandbox in order to extend this new protection to data of your users.
Then, all files created by your app will be protected.
Apps that are already using App Sandbox get this new protection automatically.
Second, if your app accesses data from other apps, there are a few ways that you
can ask for permission.
Without any changes on your side, macOS Sonoma will ask for permission when your
app accesses a file in another app's data container.
The permission is valid for as long as your app remains open, and once the app is
quit, the permission resets.
You should only attempt to read other apps' files when it is expected.
If the timing of the prompt is surprising, or the purpose is unclear, your app's
access might be denied.
A meaningful purpose string will help people understand why your app is requesting
access.
There are a few alternative ways you can get explicit permission to access files
from other apps.
For seamless access to individual files and folders, use NSOpenPanel.
This shows the macOS file picker outside of your process, and your app can read or
write selected resources once the user confirms the selection.
NSOpenPanel also allows you to specify the path that is shown by default in the
picker to make the selection even easier.
For backup utilities or disk-management tools that have already been granted Full
Disk Access, no additional prompt will be shown at time of access, since people
have already chosen to allow these apps access to all files.
In addition, all apps signed with your Team ID can access data in your other app's
containers by default, without a permission prompt.
So if you release a new app that imports data from a previous version of your app,
this will work seamlessly.
However, there may be instances where you want to define a more restrictive policy.
For example, if you build a code interpreter such as an editor, browser, or a
shell, you might want macOS to ask for permission when this app accesses data from
a messaging app that you also developed.
To do so, you can specify an NSDataAccessSecurityPolicy in your app's Info.
plist, to replace the default same-team policy with an explicit AllowList.
When specified, listed processes and installer packages are permitted to access
your app's data without additional consent while other apps require permission.
Advanced Data Protection is another opportunity for you to protect data of your
users.
Advanced Data Protection was added in 2022, providing a way for people to enable
end-to-end encryption for the vast majority of their data stored in iCloud.
By adopting CloudKit, you can end-to-end encrypt data stored in CloudKit by your
app whenever someone enables Advanced Data Protection.
And this is possible without any changes required on your end, in order to manage
encryption keys, encryption operations, or complex and risky recovery flows.
To extend the great privacy benefits of Advanced Data Protection to your users, you
only need to follow a few steps.
First, make sure to use encrypted data types for all fields in your CloudKit
schema.
This includes CKAsset fields by default, and for most data types in CloudKit, there
is an encrypted variant, such as EncryptedString.
Then, you can use the encryptedValues API, to retrieve or store data on your
CloudKit records.
All encryption and decryption operations are abstracted away by this API for your
convenience.
As a result, your app's data receives the full benefit of security breach and
privacy protection that is available from Advanced Data Protection, whenever
someone enables this feature.
For an explanation of how you can adopt CloudKit in your app, including code
samples, watch "What's New in CloudKit" from WWDC21.
Next up are new fingerprinting and tracking protections in Safari Private Browsing
mode.
Safari is designed with privacy at its core.
Private Browsing Mode enables additional privacy protections in Safari, such as
making sure that when a tab is closed, Safari doesn't remember the pages you
visited, search history, or AutoFill information.
Private Browsing mode in Safari 17 adds advanced tracking and fingerprinting
protection, which includes two new protections for preventing tracking across
websites.
First, Safari prevents known tracking and fingerprinting resources from being
loaded.
If you are a website developer, make sure to test your website's functionality in
Private Browsing mode: focus testing on login flows, cross-site navigation from
your website, and use of browser APIs related to screen, audio, and graphics.
You can reload without advanced tracking and fingerprinting protections, to confirm
if a change in behavior of your website is due to the new protections.
Do this by right-clicking on the reload button on macOS, via the page settings
button on iOS, or by testing in Safari in normal browsing mode.
You can also open the Web Inspector to examine any output to the JavaScript
console.
Network requests that were blocked as a result of contacting known trackers show up
as a message beginning with "Blocked connection to known tracker.
" Another common method for cross-website tracking are unique identifiers embedded
into URLs, for example, in query parameters.
To give people control over where they can be tracked, another new protection is
removal of tracking parameters as part of browser navigation, and when copying a
link.
When a tracking parameter is detected, Safari strips the identifying components of
the URL, while leaving nonidentifiable parts intact.
Remember that ad attribution can be done without identifying individuals across
websites.
For example, Private Click Measurement is a privacy-preserving alternative to
tracking parameters for advertising attribution.
And it is now also available in Private Browsing mode for direct-response
advertising, where no data is written to disk and attribution is limited to a
single browsing context, based on a single tab.
This follows Safari's existing strict model of ephemeral browsing and separation of
tabs in Private Browsing.
For more information, check out the video "Meet privacy-preserving ad attribution"
from WWDC21.
The last platform change is the new permission model for app extensions in Safari.
With Safari 17, the permission model Apple pioneered for web extensions is coming
to app extensions as well.
This means that people are able to choose which webpages your extension is able to
access on a per-site basis.
We're also giving them control over which extensions can run in Private Browsing
mode.
To learn more about these changes to extensions and how permissions for your
extensions can be granted per-site, you can watch the video "What's new in Safari
extensions.
" The privacy principles behind new tools for developers and our platform changes
extend across all of the features we build at Apple, including the input model on
our new spatial computing platform.
The system is really simple to use: just look around, decide what you want to
interact with, and tap.
There are no new permissions, no extra work for every app developer, and no
worrying about apps tracking where you look.
The results are a great new product with great privacy.
Let's go through the privacy engineering approach to the development of eye and
hand control.
First, there are high-level goals the input model needs to achieve.
The input experience should be fast and fluid, enabling natural interaction with UI
elements.
It should give real-time feedback about what people are looking at in order to
provide confidence in interacting with UI elements of all kinds and sizes.
In addition, existing iPhone and iPad applications should work out of the box.
And last, it should not require new app permissions just for apps to receive basic
inputs.
Next are the privacy goals for the input model.
To prevent apps from learning sensitive details about your eyes, including medical
conditions, only relevant system components should be able to access the eye
cameras.
To enable permissionless access, apps should be able to work without learning
details about people's eyes or hands.
And what people look at can reveal what they're thinking, so it is important that
apps work without learning what people look at and only learn what they interact
with.
Let's go over the system Apple engineered to achieve all of these goals.
The internal and external camera data that measures eyes and hands for the input
system is processed in an isolated system process.
This delivers a measurement of where the eyes and hands are located to the eye and
pinch detection systems, and abstracts away complex camera processing from all
other system components, including your app.
The hover feedback system combines what is shown onscreen with the eye position to
determine what the user is looking at.
If they are looking at a UI element, the system adds a highlighting layer as it is
rendered.
This is done by the rendering engine outside of the app's process and only visible
to the person using the device, so they understand what they are looking at without
revealing any information to apps.
And as soon as a pinch gesture is detected, the system delivers a normal tap event
for the highlighted UI element to your app.
With this system architecture, the complexity of translating camera data into input
events is handled by the operating system.
This means, no changes are required to receive inputs on this new platform.
In addition to the default system behavior, UIKit, SwiftUI, and RealityKit make it
easy to tune these effects to match your app's design, with the same privacy
protections as system-provided UI elements.
You can change the type, shape, and what elements the hover effects apply to.
To learn more about how to adopt, watch "Meet SwiftUI for spatial computing" as
well as "Elevate your windowed app for spatial computing.
" This spatial input model is made possible by implementing the privacy pillars.
The system minimizes the amount of data each component of the system needs access
to.
All of the processing takes place on the device.
People have control, since only intentional interactions are shared with apps.
And where you look is protected using process isolation enforced by the operating
system's kernel.
By making privacy a core design goal, it is possible to deliver both great features
and great privacy.
We hope that learning about the new privacy changes across Apple platforms has
helped inspire you as they make it easier for you to build trust through great
privacy; minimize data accessed by your app with content-picking APIs providing
seamless user control; protect children in your app by adopting the Sensitive
Content Analysis framework with on-device processing.
And for protecting user data in your app, adopt security protections such App
Sandbox on macOS, and make sure to encrypt data in CloudKit.
Thank you for watching this video.
We can't wait to see what you build.
♪