Get ready for iCloud Private Relay

♪ Bass music playing ♪ ♪ Tommy Pauly: Hi, I'm Tommy Pauly, and along with my colleague, Delziel, I'll be giving you an introduction to an exciting new feature in internet privacy.

iCloud Private Relay is a new service that prevents networks and servers from monitoring user activity across the internet.

And it's available as part of every iCloud+ subscription.

Private Relay not only protects users when they're browsing the web, but also adds protection to the traffic generated by your app to make sure you're not unintentionally leaking user information or exposing users to security attacks.

Today, you'll learn what iCloud Private Relay is and how it affects your app; how to ensure that your app works great with Private Relay; how to prepare your websites and servers; and, lastly, how to manage a network and monitor your traffic when Private Relay is enabled.

Let's get started.

Private Relay is built into iOS and macOS, so you don't need to do anything to adopt it from your app.

It's also important to understand that it won't always be affecting your app.

It will only apply when a user is an iCloud+ subscriber and has Private Relay enabled.

You're probably wondering, What does it actually do? Here's how things currently work without Private Relay.

When someone accesses the internet, anyone on their local network can see the names of all of the websites they access based on inspecting DNS queries.

This information can be used to fingerprint a user and build a history of their activity over time.

No one should be able to silently collect all of this information, whether it's a public Wi-Fi operator, another user on the network, or an internet service provider.

When connections reach the servers that run websites, those servers can see the user's IP address.

This allows the servers to determine user location without explicit permission.

Even worse, the servers are able to fingerprint user identity and recognize users across different websites, even when tools like Intelligent Tracking Prevention in Safari are preventing correlation via cookies.

These are big problems for user privacy, and in order to fix them, we need a new approach that has privacy built in by design.

iCloud Private Relay adds multiple secure proxies to help route user traffic and keep it private.

The proxies are run by separate entities.

One is Apple, and one is a content provider.

Now, when someone accesses the internet, only the client IP address is visible to both the network provider and to the first proxy.

The second proxy only sees the name the user is requesting and uses that to build the connection to the server.

It is critical to note that no one in this chain -- not even Apple -- can see both the client IP address and what the user is accessing.

The opportunities for fingerprinting have been removed.

This is privacy by design.

Private Relay uses the latest transport protocols and privacy-preserving authentication to ensure that every transaction is both secure and fast.

You can learn more about this technology in the “Apple's privacy pillars in focus” session.

Private Relay is focused on securing the most sensitive traffic on the system without impacting user experience.

In iOS 15 and macOS 12, Private Relay will apply to all web browsing in Safari, all DNS name resolution queries, and a small subset of traffic from apps.

Specifically, this will include all insecure HTTP traffic, such as TCP port 80.

If your app provides a content filter or a parental controls filter, it will still see traffic before it goes through Private Relay, so you can apply your filters just as before.

You can learn more about this in the "Meet the Screen Time API" session.

Not all networking done by your app occurs over the public internet, so there are several categories of traffic that are not affected by Private Relay.

Any connections your app makes over the local network or to private domain names will be unaffected.

Similarly, if your app provides a network extension to add VPN or app-proxying capabilities, your extension won't use Private Relay and neither will app traffic that uses your extension.

Traffic that uses a proxy is also exempt.

Next, let's cover what you need to do to make sure your app is ready to work well with Private Relay.

The great news is that for almost every app, you don't need to do anything new! Private Relay will just work.

However, there are some best practices you should know about.

Private Relay works no matter what networking API you're using.

For several years, we've recommended that your apps use modern APIs such as URLSession and NWConnection.

Now, you have one more reason to adopt them throughout your apps.

These APIs provide you the best tools to understand how Private Relay is applying to your traffic.

If you use URLSession, you can use the Network Xcode Instrument to inspect your tasks, even when they are going through Private Relay.

You can learn more about how to do this in the "Analyze HTTP traffic in Instruments" session.

And you can use metrics APIs in both URLSession and Network.framework to understand when your connections use Private Relay.

In TaskTransactionMetrics, you can check to see if your task used a proxy.

In NWConnection's EstablishmentReport, you can also inspect the timings of DNS name resolution and each stage of the proxied connection establishment.

Private Relay takes a big step towards making unencrypted and insecure HTTP connections a thing of the past.

You can join in this effort too! If you're still using insecure HTTP -- that's connections on TCP port 80 -- now is the time to change.

When Private Relay is enabled, these insecure connections will be proxied, which protects them from attackers on a local network between the client and the proxy.

However, it’s still best to have your connections be secure end to end for all users.

To do this, make sure your server supports TLS and change your URLs from http:// to https://.

Your app may have exceptions for App Transport Security to allow insecure traffic.

You can look at this list to audit what insecure traffic your app uses and remove these exceptions.

If your app provides functionality based on location, this is also a great time to make sure you're using APIs from Core Location instead of relying on servers inferring location from IP addresses.

IP address geolocation is often unreliable and inaccurate.

Core Location allows you to specify the precision of the location you need and is based on explicit user permission.

You can learn more about the latest enhancements to location access in the “Apple's privacy pillars in focus” session.

Once you've made sure your app is ready for Private Relay, try it out! Sign into an iPhone, iPad, or Mac with an iCloud+ subscription, and make sure Private Relay is enabled in the iCloud section of the Settings app or in System Preferences.

You can provide feedback with the tag "iCloud Private Relay" in the feedback app.

Now I'll hand it off to my colleague, Delziel.

Delziel Fernandes: Thanks, Tommy.

Hi, I'm Delziel Fernandes, and I'll be talking about how to prepare your server and manage your network with Private Relay.

If you have servers that your app relies on, or that user access in Safari, there are a few things you can do to prepare for Private Relay.

Your servers can identify connections that come in using Private Relay by recognizing the proxy IP addresses.

These proxy IP addresses may be shared by many users within a region.

Each address is mapped to a specific city or region.

So if you apply the correct geo IP mapping databases, your servers will still have the relevant information.

Private Relay guarantees that users can't use the system to pretend to be from a different region, so you can continue to enforce region-based access restrictions.

Details about the proxy IP addresses will be available as an article associated with this session.

Now let's take a look at network connections from devices using Private Relay.

When a device tries to access a server, it first sets up a network connection to the ingress proxy.

This connection is set up using an IP address assigned by the network provider.

The device then uses the ingress proxy to forward network requests to the egress proxy using the ingress proxy IP address.

The egress proxy then forwards these requests to the destination servers by choosing an IP address that maps to the device's city or region.

In general, your servers and websites should stop solely relying on client IP address to determine user location or identity.

If you need location access, consider requesting the user's location explicitly, and only at the granularity you need.

If you need to identify users, request a login or some other form of explicit identification rather than assuming that the IP address is tied to the identity.

Last, let's cover some tips for managing your network when Private Relay is in use.

If you're running a packet trace on your local network when Private Relay is in use, you'll see some new traffic patterns.

You'll now see a lot more traffic running on UDP port 443.

This is QUIC -- or HTTP/3 -- traffic that's being used to communicate with the Private Relay proxy.

You can make sure your traffic works well by allowing UDP port 443 on your network and by making sure your routers or Network Address Translators are tuned to handle it well.

You'll also see fewer cleartext UDP DNS queries on your network.

Let's go over a typical network connection request from a device when Private Relay is not in use.

When a device tries to access a server, it first sends a DNS query for the hostname of the server.

Once the hostname is resolved to an IP address, the device then connects to the IP address of the server using a transport protocol like TCP.

The device then performs a TCP three-way handshake with the server followed by a TLS exchange to set up a secure connection with the server.

But as you can see, without Private Relay, the hostname of the server and the IP address of the device connecting to the server are visible by simply observing packets on the network.

With Private Relay, the device first sets up a connection to the ingress Proxy using QUIC, or HTTP/3.

In packet captures, you will notice UDP packets sent to port 443 of the ingress proxy.

Once the network connection is established to the ingress proxy, access to a server is secured within the connection to the ingress proxy.

On the server end, there is no change in protocol.

The TCP/TLS exchange is similar to traffic without Private Relay.

The only difference is that the server sees the incoming connection from a proxy IP address instead of a device's IP address.

Most networks don't need to audit or monitor all user traffic.

However, if you run an enterprise or school network, your network may have policies that require intercepting all traffic.

To support this use case, you can block the hostname of the iCloud Private Relay proxy server.

Then, when a device connects to your network, the user will receive a prompt indicating that Private Relay is blocked on the current network.

They can then choose to either disable Private Relay for that network or switch networks.

Information about the proxy hostname will be available as an article associated with this session.

For parental controls, the best solution is to use content filter APIs provided by NetworkExtension framework.

This allows traffic to be audited on device even when Private Relay is enabled.

For more information on content Filter APIs, watch "Meet the Screen Time API" and "Network extension for the modern Mac" sessions.

To wrap things up, use modern secure networking APIs like URLSession in your apps; test your apps with Private Relay; and make sure your servers and websites work well when they receive connections routed through Private Relay.

Thanks for watching, everyone! ♪