Apple’s Private Relay. A first step towards Mixing for the Masses

June 8, 2021

Yesterday Apple announced a new privacy protecting service: iCloud Private Relay. Very roughly speaking it appears to be a VPN seasoned with some poor man’s mix networking, hiding your IP address from the websites you visit, while Apple doesn’t learn which sites you are visiting. I think Private Relay is a very pragmatic approach that offers a significant privacy improvement to users of any online service, albeit only to those users that have an iCloud+ subscription. But taking this idea a small step further, pushing it down the stack and implementing at the Internet layer itself, the privacy of all Internet users would be protected.

How does Private Relay work?

I could not find any detailed technical specifications, but the following quote from Apple’s press release describes the essence nicely:

When browsing with Safari, Private Relay ensures all traffic leaving a user’s device is encrypted, so no one between the user and the website they are visiting can access and read it, not even Apple or the user’s network provider. All the user’s requests are then sent through two separate internet relays. The first assigns the user an anonymous IP address that maps to their region but not their actual location. The second decrypts the web address they want to visit and forwards them to their destination. This separation of information protects the user’s privacy because no single entity can identify both who a user is and which sites they visit.

According to this Apple WWDC video, Private Relay is built in into both iOS 15 and MacOS Monterey. It is only available to iCloud+ subscribers, and must be explicitly enabled. It is limited to HTTP (i.e. web based) traffic only, and only applies to Safari web browsing, DNS queries, and a small subset of app traffic (that uses http or https). The first (‘ingress’) relays are operated by Apple. The second (‘egress) relays are operated by a (yet unspecified, but assumed to be somewhat trusted) content delivery network. Interestingly enough, the IP addresses of the ’egress’ (second) relays are publicly known, which allows web sites to block connections from users browsing with Private Relay enabled. Moreover, the IP addresses of the egress relays are associated with particular regions or cities.

Some more details of how Private Relay works are presented in another WWDC video. To limit access to iCloud+ users without tracking the actual users that use Private Relay, devices obtain blindly signed access tokens with which they can prove the right to use Private Relay to the ingress relay.

Private Relay uses layered encryption (like Tor): a device encrypts outgoing HTTP(S) packets first against the key of the egress relay, and then once more against the key of the ingress relay. (Note that if the website uses TLS, the actual request itself is already encrypted using the key of the website.) The ingress relay peels off one layer of encryption, and forwards the result to the egress relay (substituting its own IP address as the source of the traffic in the process). The egress relay peels of another layer of encryption before sending the original HTTP(S) packets to the web server. Response packets are sent back over the reverse path (the egress and ingress relays keep track of where to forward them to) adding a layer of encryption with each hop. The device peels of both layers of encryption to obtain the original response from the website.

The egress IP address is randomly chosen (to prevent cross site user tracking) and is reused by other users over time. The device informs the egress relay about its rough location (essentially what could have been derived from the original IP address, as determined by the ingress relay), which it uses to (randomly) choose an egress IP address that corresponds to this region. Users can switch this feature off and instead opt to share a much larger region, namely the current timezone they are in.

Why is this relevant

Private Relay is not as good as Tor, because it uses a shorter circuit (two instead of three relays), and crucially puts Apple in control of the ingress relay. It still offers some important privacy property that is sorely needed on the Internet today: hiding the IP address of the device that connects to a website, without relying on a single trusted entity. This is better than using a VPN, where the VPN server still gets to link the IP address of the device with the URL or IP address of the website it visits.

Breaking the link between the IP address of the device and the website (or any other online service) it connects to is crucial to prevent tracking of users across the Internet. Such IP based tracking breaks the privacy properties of many privacy friendly protocols, like Attribute Based Credentials, anonymous payment schemes, etc.: even though the high level protocol completely shields the identity of the user from the service, the server still gets to see the IP address of the user! Many such privacy friendly protocols therefore disallow such IP address based tracking, but of course it would be even better if such tracking is not possible in the first place. With Private Relay, such privacy friendly protocols not only protect privacy in theory, but also in practice.

The next step: Mixing for the Masses!

However, so far this privacy protection in practice is only available to Apple users, that have an iCloud+ subscription, and only applies to HTTP traffic. That is way to restrictive!

We need a radical scale up of Private Relay and implement “Mixing for the Masses” instead: by pushing it down the stack and implementing it at the Internet layer itself. For example by letting all consumer grade ISPs serve as ingress relays, and some backbone providers or Internet exchanges serve as egress relays. Or by allowing any pair of Internet routers to be (automatically and randomly) selected for this role. Moreover this practical mixing approach should be applied to all network traffic (like VPNs do), and not jut HTTP(S). That would protect the privacy of all Internet users.

In case you spot any errors on this page, please notify me!
Or, leave a comment.