Over the last few months, Pixalate’s AFAC (Ad Fraud and Compliance) research team has investigated invalid traffic (“IVT,” or ad fraud) in connection with iCloud Private Relay IP Addresses. Pixalate, in conjunction with Basis Technologies, has uncovered a widespread potential exploit - dubbed “iP64” - that Pixalate estimates may cost advertisers over $65 million in 2022 in the U.S. alone.
Our findings, presented in this post, show how ad fraudsters appear to be exploiting an unquestioning trust of Apple’s iCloud Private Relay IP Addresses - aided by the opacity of the ad tech supply chain. Pixalate is calling this ad fraud scheme iP64 because of the way in which apparent fraudsters seem to be inserting iCloud Private Relay IPv6 and IPv4 addresses into ad requests to masquerade the true source of the traffic.
Pixalate first reported on this phenomenon in August 2022, noting that 90% of purported iCloud Private Relay (iCPR) traffic may actually be invalid — i.e., traffic that is only pretending to be protected by iCPR.
Table of Contents:
How ‘iP64’ came to be
Pixalate believes the factors that contributed to the emergence of iP64 are as follows:
Apple’s claims about iCloud Private Relay fraud security
Apple has asserted that iCloud Private Relay traffic is safe from fraud. However, Pixalate has not found any guidance from Apple regarding its definition of “fraud” in this context.
For example, in the Developer page Prepare Your Network:
And in iCloud Private Relay Overview:
The absence of cautionary language accompanying these statements seems to encourage companies to blindly trust the iCloud Private Relay IP Address ranges as being fraud-free in all contexts. This messaging suggests that Apple may not have factored into the architecture (or its associated messaging) the role of the programmatic ad supply chain, including the reality that most participating entities are not in a position to establish direct connections to the end-user device.
Fraudsters appear to be inserting iCPR IP addresses to bid requests with expectations that a number of companies will blindly follow Apple’s guidance and add iCPR IP address ranges to their “allow lists.” According to Pixalate’s research, advertisers appear to be falling into this trap at an increasing and alarming rate. Pixalate has measured the rate of iP64 growing from ~10% in February 2022 to ~20% in August 2022 for iOS and MacOS X Safari traffic, and we project it will reach ~25% by December 2022.
Accounting for Apple’s “Hide My IP”
“Hide My IP” is a free privacy service provided by Apple that claims to automatically hide the end-user’s IP address from “known trackers” on iOS 15+. Hide My IP uses the iCloud Private Relay infrastructure (including the same IP addresses).
Pixalate verified we were not flagging legitimate iCloud Private Relay/”Hide My IP” traffic as invalid by:
What does the iP64 ad fraud exploit look like?
Pixalate took a closer look at the traffic that claimed to be from iCPR or Hide My IP sources and, as discussed in the earlier post, identified discrepancies between IPs detected on the device on ad delivery and what was declared in the bid request.
Distribution of traffic associated with iCPR IP Addresses
When we analyzed the individual sources of masked IP (Declared but not Detected Traffic), we could see that in many cases those devices demonstrated bot-like behavior, in addition to hiding behind the apparently falsely-declared iCPR IP addresses.
In the following example, Pixalate detected that the end-user device’s true IP came from T-Mobile, but the declared IP was from iCloud Private Relay.
True IPs demonstrate T-Mobile source
Regardless of whether Pixalate detected IPv4, IPv6, or both, from a user, we would see a mix of IPv4 and IPv6 iCPR addresses being declared in the ad request.
Pixalate has also detected end-user device IPs seen behind declared iCPR addresses belonging to known data centers from organizations such as Amazon AWS. In the below examples, Pixalate observed AWS data center IPs rotate through multiple websites while declaring to originate from iCPR.
Firefox requests claiming to have iCPR IPs
The above examples also show purported iCPR traffic coming from the Firefox browser, which is impossible given iCPR is only available on Safari.
Other than these simple examples, Pixalate measured other bot-like behaviors associated with these IP addresses that purported to be masked using iCPR IP addresses.
By using a Pixalate-created D3 graph to map out the connections between the masked iCPR impressions and the various domains seen in the traffic, Pixalate confirmed that the iP64 ad fraud exploit often impacts small groups of popular domains. When aggregating results across the iCPR addresses associated with iP64, bot-like clusters around a particular group of popular domains appear.
Top Affected Domains:
Bot-like behavior from purported iCPR sources
The D3 graph above shows a subset of iCPR IP addresses associated with iP64 (blue dots) and the domains they have visited (orange dots). This small cluster of domains are often the only domains visited by traffic coming from these iCPR IP addresses. This behavior is consistent with what is observed commonly in “bot rings.”
SPO + Basis Technologies Collaboration
One of the partners Pixalate worked with in this investigation was Basis Technologies. Together, Pixalate and Basis worked closely to break down the distribution of the misrepresented iCPR traffic across various sellers. Because it is difficult for buyers to identify iCPR IP addresses at bid request time, this seller analysis helped to work with the relevant traffic sources and address the problem.
We then analyzed the Supply Path Optimization (SPO) data to match iP64 traffic to sellers that appeared anywhere in the Supply Chain. Pixalate’s research team parsed the OpenRTB Supply Chain Object (SCO) from the bid request and viewed the traffic from a Supply Path perspective. In doing this, Pixalate found further correlation of this potentially fraudulent iCPR traffic going through certain sellers more than others.
In addition, looking at the SPO data, we found that traffic from a given user looked different when certain sellers were in the chain. An iCPR IP address would be declared when they were in the chain, and a normal IP address declared for the same user when such sellers were not in the chain - even when the impressions came in around the same time. This suggests that these sellers were impacted by iP64 more than others.
SPO analysis where only certain paths from a device claimed iCPR
This analysis – and insights gleaned therefrom – enabled Basis to work with those sellers to further examine and block this misrepresented traffic.
Solutions: How the digital ad industry can mitigate ad fraud from iP64
What is the best defense against this form of IVT? As discussed above, the challenge with this exploit is that bid requests in programmatic advertising often traverse through a chain of entities, and most of the entities after the first hop do not have direct access to the end-user’s device and its IP address. In other words, in most cases, they are not able to directly confirm, at bid request time, whether the end-user device’s actual IP address truly is an iCloud Private Relay IP address.
We believe that the best way to fight this type of IVT is to have a good understanding of the Supply Chain, analyze the sources of this form of IVT and work with those sellers to reduce potentially misrepresented traffic. Given the low volume of legitimate iCloud Private Relay users detected by Pixalate (1-2% of all Safari traffic as of August 2022), a potential near-term solution may be to add iCPR IP addresses to “block lists.” While this approach may result in blocking real iCPR users - true adoption numbers appear to be low enough that, in the near term, most companies would not see any material impact (other than IVT reductions). This path should be used based on the overall traffic composition and impact.
For more data related to this exploit (top iCPR IVT IPs, top associated data center IPs, and top pub domains impacted) download the list for free today.
If you have further questions on this post, about iCloud Private Relay in general, or our Supply Chain analysis capabilities, please reach out to us using this contact form.
Pixalate is neither asserting nor assigning culpability with our research and insights. Is it Pixalate’s belief that our readers may be interested in learning more about apparent ad fraud related to iCloud Private Relay IP Addresses. Pixalate’s opinions expressed herein are just that, opinions, which means that they are neither facts nor guarantees. In the context of the apparent ad fraud discussed herein, and per the MRC, “'Fraud' is not intended to represent fraud as defined in various laws, statutes and ordinances or as conventionally used in U.S. Court or other legal proceedings, but rather a custom definition strictly for advertising measurement purposes;” and “‘Invalid Traffic’ is defined generally as traffic that does not meet certain ad serving quality or completeness criteria, or otherwise does not represent legitimate ad traffic that should be included in measurement counts. Among the reasons why ad traffic may be deemed invalid is it is a result of non-human traffic (spiders, bots, etc.), or activity designed to produce fraudulent traffic.” Finally, brands, logos, and trademarks specified in this blog posting and related media are utilized merely for referential purposes, and such brands, logos, and trademarks remain the property of their respective registrants and owners, as applicable.
These Stories on Ad Fraud
Disclaimer: The content of this page reflects Pixalate’s opinions with respect to the factors that Pixalate believes can be useful to the digital media industry. Any proprietary data shared is grounded in Pixalate’s proprietary technology and analytics, which Pixalate is continuously evaluating and updating. Any references to outside sources should not be construed as endorsements. Pixalate’s opinions are just that - opinion, not facts or guarantees.
Per the MRC, “'Fraud' is not intended to represent fraud as defined in various laws, statutes and ordinances or as conventionally used in U.S. Court or other legal proceedings, but rather a custom definition strictly for advertising measurement purposes. Also per the MRC, “‘Invalid Traffic’ is defined generally as traffic that does not meet certain ad serving quality or completeness criteria, or otherwise does not represent legitimate ad traffic that should be included in measurement counts. Among the reasons why ad traffic may be deemed invalid is it is a result of non-human traffic (spiders, bots, etc.), or activity designed to produce fraudulent traffic.”