Powering and Protecting Online Privacy: iCloud Private Relay and Information for Akamai Customers
In 2021, Apple launched iCloud Private Relay, a new service designed to protect users’ privacy on the internet. Akamai was very excited to be a part of delivering this service, and through a series of separate linked blog posts, we will explain how the service works and what Akamai customers can do to ensure the best possible experience for iCloud Private Relay end users. In this post, I’d like to provide a high-level overview of the project as well as a discussion of what this means for Akamai customers.
In subsequent posts, we will discuss Akamai’s Oblivious DNS over HTTPS (ODoH) service and infrastructure as a service (IaaS), which supports Private Relay.
First, what is Private Relay?
iCloud Private Relay allows users with iOS 15, iPadOS 15, or macOS Monterey on their devices and an iCloud+ subscription to connect to the internet and browse with Safari in a more secure and private way. Private Relay has a unique dual-hop architecture that is designed to ensure that no single party has access to both who the user is and what sites they are visiting.
It leverages two separate internet relays (ingress proxy and egress proxy) operated by separate parties to separate the IP address that can be used to identify an end user from the name of the website that the user is accessing. More details about this unique routing architecture can be found in this tech sheet.
As noted above, Akamai supports Private Relay with multiple in-house and infrastructure services. Private Relay leverages Akamai’s highly distributed compute platform for fast performance, while maintaining a separation of data and operation to ensure that no single party can have end-to-end visibility of the traffic.
Akamai built new managed services to provide egress proxy service based on the Multiplexed Application Substrate over QUIC Encryption (MASQUE) protocol and ODoH service to keep DNS queries private. Additional information on the egress proxy and ODoH can be found in this tech sheet from Apple.
Akamai customers will not see any changes in how their service is billed, but may notice some changes in traffic patterns and how the service is delivered, as described below. Website and network operators may see increased traffic from Akamai servers as a result of Private Relay usage.
What to expect with Private Relay
The majority of website owners won’t need to make any changes to support Private Relay; however, it is important that they understand the traffic patterns that they will see from Private Relay to provide users with the best possible experience. Despite many differences, some changes in traffic may seem similar to existing services such as virtual private networks (VPN), carrier grade NATs (CGN), secure web gateways (SWG) or other proxy services. Some of the main areas of difference include:
Network address translation (NAT) of client IP addresses, mapping local private addresses to public ones before transferring the information, to maintain individual privacy
Private Relay egress IPs will be visible to servers instead of the client IP.
Because the egress IP for a given client will change over time, embedding IP addresses in authentication tokens is discouraged even more than it already was. Learn more.
Services that rely upon specifically tracking or identifying the client or destination IP address — such as zero-rating or client auth based on IP address — may no longer work as expected, and alternate factors should be used.
Shielding client DNS requests and client traffic destinations from the local network
Delocalization of client traffic
The source IP address will reliably indicate client country and time zone, and will hint at client city/general location by default but will not indicate the end user.
The Akamai EdgeScape geo-IP database is already updated with the Private Relay IP geolocation feeds, and we encourage customers to make sure that any third-party geo-IP feed that they are using is also updated to use the latest feed.
IPv6 source addresses have finer granularity than IPv4 on some egress proxy operators, so server operators are encouraged to enable IPv4+IPv6 dual-stack to obtain a more accurate client location.
Higher adoption of QUIC and IPv6 in the last mile even when origins don’t support them can result in improved end-user performance and more efficient routing
Fraud and anti-abuse is built into the service; clients to the service are authenticated with blind signatures and have rate-limited access to the service in ways that should reduce abusive access by bots
At Akamai, we are excited to see the development of new services like Private Relay that increase end-user privacy and help reduce fraud and abuse without negatively impacting application performance. In the next post in this series, we will provide more detail around the Akamai ODoH service.