WWDC Quick Look 💓 By SwiftGGTeam
中文 EN 日本語
Get ready for iCloud Private Relay

Get ready for iCloud Private Relay

Privacy & SecuritySystem ServicesNetworking
Watch original video

Highlight

iCloud Private Relay is a built-in service of iCloud+ that prevents networks and servers from tracking user Internet activities through a dual-proxy architecture; developers can benefit automatically without modifying their code, but they need to ensure that the server stops relying on IP addresses to infer user location and identity.

Core Content

Before Private Relay, where were the privacy loopholes?

You connect to public Wi-Fi at a coffee shop and open an app. At this point, the Wi-Fi operator can see which domains you visited - because DNS queries are transmitted in the clear. This information is enough to paint a picture of your online habits.

The deeper problem is that the target server can see your real IP address. From this, the server can infer your approximate location and even associate your identity across different websites via your IP address—even if Safari’s smart anti-tracking blocks cookie association.

Private Relay’s dual-agent architecture

Apple’s solution was to introduce two separate proxy servers. The first proxy is operated by Apple and the second by the content provider.

Key design: No one party can see both the user’s IP address and the target domain name visited. Apple only knows who you are, but not what you access; the second agent only knows what you access, but not who you are.

（02:53）

Which traffic will go through Private Relay

In iOS 15 and macOS 12, Private Relay automatically applies to:

  • All web browsing in Safari
  • All DNS domain name resolution queries
  • Insecure HTTP traffic in the app (TCP port 80)

The following traffic is not affected:

  • Local network connection
  • Private domain connection
  • Network extension traffic using VPN or proxy

（04:15）

Detailed Content

Detect Private Relay status in code

While no additional code is required to enable Private Relay, you can find out whether a connection is proxied through the Modern Networking API.

URLSession mode:

let task = URLSession.shared.dataTask(with: url) { data, response, error in
    // Check metrics after the task completes
}

task.metrics { metrics in
    for metric in metrics.transactionMetrics {
        if let proxy = metric.proxyConnection {
            print("Connection used proxy: \(proxy)")
        }

        // Check whether Private Relay was used
        if metric.isProxyConnection {
            print("This request went through Private Relay")
        }
    }
}
task.resume()

Key points:

  • transactionMetricsArray containing detailed metrics for each network request -isProxyConnectionIdentifies whether the request is proxied
  • Accurate metrics data needs to be obtained after the request is completed

Network.framework method:

import Network

let connection = NWConnection(host: "example.com", port: 443, using: .tls)
connection.start(queue: .global())

connection.stateUpdateHandler = { state in
    switch state {
    case .ready:
        if let report = connection.currentPath?.availableInterfaces {
            // Check the connection establishment report
        }
    default:
        break
    }
}

Key points:

  • NWConnectionProvide lower-level network connection control
  • PassEstablishmentReportPossibility to check the timing of various stages of DNS resolution and proxy connection
  • Suitable for scenarios that require fine control of network behavior

Server-side adaptation

If your server relies on IP addresses for location determination, adjustments will need to be made.

Private Relay’s proxy IP addresses are mapped by city or region. Apple publishes a list of these proxy IP addresses and you can use the correct GeoIP database to map them to the general area.

But the core advice is this: Stop using IP addresses to infer location and identity.

// Recommended: explicitly request the user location
import CoreLocation

let locationManager = CLLocationManager()
locationManager.requestWhenInUseAuthorization()

// Use the location as needed after retrieving it
locationManager.startUpdatingLocation()

Key points:

  • CoreLocationBased on explicit user authorization, more accurate than IP inference
  • You can specify the required precision level to avoid over-acquisition
  • IP address geolocation is inherently inaccurate, especially on mobile networks

Notes for network administrators

After enabling Private Relay, there will be two obvious changes in network traffic:

  1. UDP port 443 traffic increased — This is the QUIC/HTTP/3 protocol used to communicate with Private Relay proxies. Make sure your firewall allows UDP 443.

  2. Clear text DNS queries are reduced — because DNS queries are sent encrypted to the proxy server.

For corporate or school networks, you can block the hostname of the Private Relay proxy server if all traffic needs to be audited. When the device connects, the user will be prompted: Disable Private Relay on the current network, or switch to another network.

（13:43）

Content Filtering and Parental Controls

If your app offers content filtering or parental controls, the good news is: your filters can still see traffic before it enters Private Relay.

Use the NetworkExtension framework’s content filtering API:

import NetworkExtension

// Register the content filter provider
let provider = NEFilterProvider()
// Filtering logic runs locally on the device and is not affected by Private Relay

Key points:

  • Content filtering is performed locally on the device, prior to Private Relay processing
  • useNEFilterProviderandNEFilterDataProviderImplement filtering logic
  • Refer to the “Meet the Screen Time API” session for specific implementation

Core Takeaways

1. Comprehensive audit of HTTP connections in the app

  • What to do: Check all uses in the projecthttp://URLs, all upgraded tohttps://- Why it’s worth it: Private Relay will proxy insecure HTTP traffic, but this is only intermediate protection; end-to-end encryption is the complete solution
  • How to start: Search for items inhttp://String, check Info.plist forNSAppTransportSecurityException configuration, remove one by one

2. Use Core Location instead of IP location

  • What to do: If the server infers the user’s location based on IP, useCLLocationManagerget
  • Why it’s worth doing: IP positioning is inaccurate and violates privacy; Core Location is based on user authorization and the accuracy is controllable
  • How to start: Add a location permission request to the page that requires location information, and pass the coordinates to the server instead of letting the server guess.

3. Add Private Relay detection for network debugging

  • What to do: Add metrics collection to the App’s network layer to mark which requests go through the proxy
  • Why it’s worth doing: Help troubleshoot network problems reported by users and distinguish whether they are caused by Private Relay or other reasons.
  • How to start: Add to existing URLSession callbacktask.metricscheck, recordisProxyConnectionstatus to log

4. Update the anti-fraud logic on the server side

  • What to do: If the server uses IP address for risk control or anti-swiping, add device-side verification as a supplement.
  • Why is it worth doing: Multiple users share the same proxy IP under Private Relay, and IP-based frequency limiting will accidentally injure normal users.
  • How to start: Introduce DeviceCheck or App Attest for device-level verification to replace pure IP-dimensional judgment

5. Enterprise Network Adaptation Guide

  • What to do: Prepare Private Relay compatibility documentation for enterprise customers
  • Why it’s worth doing: Enterprise networks usually have strict traffic audit requirements. Inform the configuration method in advance to reduce support tickets.
  • How to start: Explain in the help documentation the need to enable UDP 443 and how to configure the proxy hostname blocking policy

Comments

GitHub Issues · utterances