Private Relay by Apple, Data Protection Middleware, and Proprietary Approaches vs. Standards

Apple’s latest IP address obfuscation feature and how the ecosystem might achieve similar data protections with standards

Key Takeaways

Apple continues to release privacy focused features
Private Relay is a lot like a traditional VPN, albeit baked into the operating system as opposed to a clunky aftermarket app
It’s not clear how many Apple iCloud subscribers will turn on Private Relay, but just because it might be low at first doesn’t mean that the trend of proxy middleware, including software which obscures true IP addresses, is going away or going to stall
Other proxies are being discussed in web and digital advertising circles, most notably, Microsoft’s PARAKEET
PARAKEET, an open standards proposal at the W3C, takes a much less blunt approach and arguably a much more thoughtful one while using a proxy server for its privacy and data protection qualities. This is a stark contrast to Apple’s posture that it only trusts itself to develop worthy privacy preserving technologies.
IAB Tech Lab will continue to watch platform developments and where we can, like with PARAKEET, influence them to be strong, scaled alternatives for privacy preserving digital advertising addressability going forward
We would love to see Apple actively engage the digital ads industry before OS changes with known impact on the ads ecosystem.

What happened?

During the same World Wide Developer Conference (WWDC) where Apple announced “Hide My Email” it previewed another new data protection feature called “iCloud Private Relay.” We wrote about Hide My Email a few weeks ago. Now we unpack Private Relay and similar efforts, look at their effects, and suggest alternatives to achieve similar outcomes with less unintended consequences.

In Apple’s words:

iCloud Private Relay is a service that lets you connect to virtually any network and browse with Safari in an even more secure and private way. It ensures that the traffic leaving your device is encrypted and uses two separate internet relays so no one can use your IP address, location, and browsing activity to create a detailed profile about you.

Techradar does a good job of breaking down Private Relay here. That write-up appears to be based on this video from WWDC. We won’t attempt to do a better job than Techradar at getting into the details. Instead, here’s a quick rundown of the feature with some hopefully digestible comparisons and explanations.

Private Relay is an Apple integrated spin on middleware very similar to a Virtual Private Network (VPN), which is by no means a new technology. VPNs act as a proxy for internet activity by hiding a user’s real IP address. Most VPN providers market their privacy traits, particularly for people who connect to the internet via public Wi-Fi, long known to be a security risk. Notably, VPN usage worldwide is on the rise and is said to have surged during people’s time at home during the COVID pandemic. What’s new here then is that Apple is packaging a VPN-ish feature in its widely used operating system. For now, it seems Apple is only offering Private Relay in certain regions—markets like China are excluded due to regulatory restrictions—to iCloud subscribers browsing on Safari and when apps call non-https servers. iCloud’s entry level pricing is $0.99 a month. Take stock of how VPN providers react.

This type of privacy move should by now come as no surprise. These days, Apple product announcements nearly always include new features intended to address user privacy concerns to set Apple devices and software apart from competitors. That trend is not limited to Apple. Readers of this blog are well aware of major changes to digital advertising stoked by people’s concerns about their data, regulatory reactions to those concerns and platform reactions to both. Privacy and its lesser referenced friend, data protection, cannot be ignored.

Why should you care?

One might consider the scale of Private Relay and assume it will be low. Analysts in 2018 estimated Apple had 170 million paying iCloud customers—not too shabby. However, Private Relay usage is likely not all net new IP address obfuscation as many iCloud subscribers may already use a VPN. Moreover, Private Relay is targeted mainly at Safari users (not all iCloud subscribers use Safari… I am a case in point) and also requires a user action to enable it. Still, Apple’s move is important because it sets the precedent for baking VPN-like functionality into an operating system and makes the technology more approachable to more users. Would Android follow suit? Google One, the company’s VPN, is not integrated by default, but it’s not a stretch to think a company already offering a pure play VPN might do something similar to Apple’s Private Relay in the Android OS.

Second, Private Relay, like one or two Privacy Sandbox proposals, is targeted at eliminating the IP address as a utility to maintain state on a user, particularly in web contexts. “Maintaining state on a user” means persistently being able to identify a user across contexts and importantly, time, on a device. Persistently being able to identify a user across contexts and time on a device is how most digital advertising ecosystem participants achieve reach measurement, frequency and recency control, segmenting, targeting, lookalike prospecting, and attribution. IP addresses are thus very often used in digital advertising, particularly in video and digital audio / podcasting channels where things like cookies and device IDs were either not available (cookies) or not nearly as prevalent (device IDs). Private Relay removes IP addresses as a persistent identifier for a user across time. It is unclear if the same proxy IP will persist across sites during a single browser session.

Third, IP addresses are widely used for their associated location properties. Many have called out issues arising if Apple doesn’t supply an approximately accurate IP address location-wise. However, Apple’s developer documentation shows they’ve thought of this. That’s good, for now, as a random proxy IP address can hurt organizations that use IP addresses for applying compliance rules. Consider these common use cases: using known California IP addresses for applying CCPA rules or restricting gambling ads delivery in various regions’ who disallow gambling ads. IP address location and ranges are also an input into identifying fraudulent practices.

Apple clearly intends to slow the usage of IP addresses for cross-site/time advertising uses on Safari. It’s not as clear though if Apple will decide to foreclose other ways IP addresses might be used to serve a person the right experience and comply with local regulations—with or without ads. The real issue here is that one company making decisions for the internet is not even close to ideal. This is why we’re so focused on driving forward change through standards.

Is there a better way?

Private Relay is not unique in its blunt edges. It looks like other VPNs with the main distinction being that it’s baked into Apple’s widely deployed operating systems instead of a user-installed app.

Could Apple have taken a different, balanced and non proprietary approach? We think so, and there’s a strong example.

A recent Microsoft proposal at the W3C offers similar data protection and privacy traits with a lot more thought given to supporting a healthier digital ads ecosystem. PARAKEET or “Private and Anonymized Requests for Ads that Keep Efficacy and Enhance Transparency” sounds a lot like Private Relay in the first four words of the acronym—Private and Anonymized Requests—but after that diverges into pragmatism and understanding, that which Apple’s Private Relay eschews—for Ads that Keep Efficacy and Enhance Transparency. This blog post will not attempt to give a detailed account of PARAKEET (and its optimization cousin, MaCAW). Instead we’ll hit the high points.

PARAKEET prescribes a proxy server mechanism, inserted between browser loads and ad requests that acknowledges real advertiser and publisher use cases, the technologies advertisers and publishers select, and that breaking those willy nilly is not only lazy, it’s harmful to vibrant competition and ad supported content. The proposal anonymizes publisher contexts, coursens the browser’s geo and other client specific browser information, supports advertisers who want to activate what they can infer from their site traffic, and employs differential privacy tactics to “enforce limits on the identifiability of user interest information and contextual signals sent in ad requests.” These data protection middleware properties deliver improved user privacy and have the potential to scale where Private Relay cannot due to the latter’s proprietary, MacOS/iOS integrated nature. The PARAKEET design seems to be gaining support from the broader web community, particularly because it does not centralize digital advertising auction dynamics like a related Google proposal: FLEDGE. One example of that growing interest is a new proposal for how the broader community might govern a proxy like PARAKEET: GARUDA.

Critically, PARAKEET (like Chrome’s proposals) is an open proposal. Moreover, Microsoft appears to be spending a significant amount of time listening to different market participants, inside and outside of W3C forums to arrive at a workable standard. I’ve witnessed many of these open meetings and seen Microsoft’s Edge and Ads team members actively seeking as much ads ecosystem input as they can get. It’s not shocking then that many different market participants are responding well to the designs. It isn’t lazy product development like Private Relay. It’s meeting a market where it is and attempting to chart a rational course for where it should go.

The IAB Tech Lab team continues to track various proprietary feature announcements and open proposal developments in the privacy and data protection realm. We’d love to see more creative proposals like PARAKEET that result in stronger digital data protections and privacy while acknowledging the need to mitigate impacts to advertising effectiveness and efficiency for brands—large and small—and monetization choices for content producers—large and small. We’re excited to see many of our members and the broader digital advertising ecosystem acknowledging the need to move beyond the status quo architecture digital advertising today. We’re equally excited to see major companies like Microsoft (an IAB Tech Lab member) take a pragmatic leadership position in advancing open technologies which balance privacy improvements with support for business operations for advertisers and content producers and their chosen vendors.

Privacy and data protection remain integral to the future of digital advertising and central to the IAB Tech Lab roadmap today and in the years to come. But technologies and standards to enhance privacy and data protection in digital advertising should be developed out in the open and ideally benefit more than just Apple’s paid iCloud users on Safari. Apple’s closed approach is predictable, but it’s not too late for Apple to sit down at standards tables—actively and in good faith—where a diverse set of stakeholders aim to enhance privacy and data protection in ways that recognize the legitimacy of the efficiencies marketers seek and competitive monetization content producers need to grow. Given its dominant position as a provider of devices and software that are used to access the web, Apple can play a constructive role in furthering privacy and data protection by collaborating with all constituents of the ecosystem and leading open development and deployment of technologies and standards—but they must put in the effort.