Skip to content

iOS15 and IP Address Obscurification

Note: This post was originally set to publish around the release of iOS15. I decided to do further testing and investigation before publishing. I am now happy to present the entire thing.

On September 20th, 2021 at 1 PM Eastern, iOS15 and iPadOS15 were released for general availability. The general release affects the analytic and data space in a number of key ways, but I want to cover the impact to use of the IP Address in this blog post as I expect this to be the most disruptive to certain kinds of advertising and reporting on the web. You may be asking, what Mail Tracking Protection? That’s covered on a different blog post and affects email marketing specifically.

The Announcement

Originally announced at WWDC and in a press release issued by Apple, the ability to restrict the use of IP Address as part of Intelligent Tracking Prevention showed in the Safari 15 beta.

Added IP address hiding from known trackers which users can enable in Safari Preferences.

https://developer.apple.com/documentation/Safari-Release-Notes/safari-15-beta-release-notes

However following the release, it would seem that this feature is enabled by default in Safari for anyone who upgrades to iOS15, iPadOS15 or MacOS 12.

iCloud+ Subscribers may see a different result for ‘Hide IP Address’ such as ‘From Trackers and Websites’ depending on if they opted to use the Private Relay feature (see below).

How it works

Originally, I expected this to leverage Webkit’s innate machine learning algorithm to classify the trackers as the explainer covers. This turns not to be the case and but I was able to find some clarity and correct this misconception over a twitter discussion.

So instead of the machine learning, we have to reference DuckDuckGo’s tracker radar feature. Starting in Safari 14 as part of iOS14 Safari gained the ability to display a Privacy Report similar to the one below.

Simo Ahava had a excellent writeup of the feature which you can read here. In contrast to the more disclosure aspect of iOS14, in iOS15 the results of this tracker check will result in the identified resources having the the user’s real IP Address hidden via the same mechanics that power the other new feature in iOS15, Private Relay. This is reflected in the new disclosure which is a part of Safari v15.

Based on testing, it seems that the IP Address Hiding feature (shown above) that it relies on the same network logic that Private Relay relies upon. In short, the browser calls a server, which forwards it to another server, and ultimately the desired web address. This means that Apple can’t see where you are trying to go, and where you are trying to go can’t see where you are. Apple has a good WWDC video which explains the private relay network in depth that I recommend reviewing for a detailed overview.

Enabling Private Relay will apply to:

  • Safari Browsing
  • DNS Queries
  • A small subset of App traffic

It will not apply to:

  • Local Network connections
  • Private Domains
  • Network Extensions and VPNs
  • Proxy Configurations

So it would seem, that the default behavior known trackers (as identified by DuckDuckgo) inside of Safari, will mask the IP Address for DNS Queries related to identified domains. The advanced behavior of Private Relay extents this to all DNS Queries issued over the web for the above mentioned software.

At the time of writing there is no known way to easily identify the traffic routed this way via the developer tools, the Webkit team has a bug in the backlog to address this. You can get a list of the URLs which are identified by the Tracker Radar by clicking on the shield to the left of the URL as shown below.

So you can see the above domains are not getting the users real IP Address, while target.com itself is. Depending on what Target may be using the domains for, this may interfere with marketing, targeting or visitor stitching efforts.

What this means

While Apple’s press release claims that the IP Address Hiding is part of Intelligent Tracking Prevention (ITP), the IP Address cloaking seems to be specific to Safari in contrast to the rest of ITP, which affects all Webkit browsers. With that being said, Safari is not an insignificant amount of the web ecosystem. At the time of writing, Statcounter lists Safari as being nearly 55% of mobile web traffic and 36% of overall web traffic in the USA. So this is more than just ‘noise’ that can easily be dismissed via filtering out Safari traffic from reporting.

As far as to the impact on Marketing and Optimization systems – the basic result is geo-location and geo-targeting is going to be less accurate. Anything that relies on a reverse IP Address lookup in order to approximate location won’t be quite as accurate when the user is in Safari (or one of the other related systems). Apple itself in the announcement video goes as far as to say not to rely on IP Address any further as a means of user identification.

How inaccurate is going to depend on where you are, and where the nearest exit point of Apple’s relay network is located. For me, I’ve ‘jumped’ a few miles down the road, or 30 miles over to the next city. So targeting wise, it’s likely only going to be a problem if you are relying on IP Address for ZIP Code level targeting. The system is supposed to keep the traffic inside of state borders so in the USA you don’t have to worry about suddenly being subject to seeing traffic appear to increase from out of state.

In real terms, using the IP Address for identification is difficult at best even in the best of scenarios due to how internet traffic flows around networks and the mobility of things like Smartphones. If you are comparing where your brand site thinks users are compared to where an advertiser who is affected thinks they are – you’re likely to end up with a delta where you and the advertiser disagree on where the user actually is.

If you are trying to target/report on rural customers, there is a greater chance that they’ll appear to advertisers as being in the next nearest metro area, which may ultimately impact specific types of advertising campaigns or analytics measurement.

Private Relay

Private Relay is a beta feature that users (in most countries) can enable (directions) as part of their iCloud+ subscription to mask which IP Address is seen to remote systems (not just trackers).

It works largely the same way as above in the default setting of maintain general location. Users with this setting will have Safari traffic routed through the network to a nearby exit point.

However, should the user select country and time zone, it means what it says and someone could move dramatically as a result. For example, I could be in Michigan, enable the feature and appear as if I am in Maine. The two states are both in the eastern time zone and both part of the United States (but are roughly 16 hours apart by car). This may cause some features which rely on reverse IP Address lookup (such as A/B Testing and Consent Management) to not fire as intended when using geo-fencing segmentation. For my friends in Canada, you could appear to move from Ontario (where you are) to Quebec (where you appear to be), and be served French instead of English by sites using regional language detection by IP Address lookup.

The dialog warns this may cause some websites (which rely on things like IP Address) to issue security challenges more often which may force additional steps when attempting to log-in, and so it may be good for Customer Service teams to be aware of this behavior when assisting with technical support.

Users whom wish to turn off this feature after enabling it can do it in the same area of iCloud settings, but will get the following prompt:

Which, personally speaking, doesn’t exactly inspire the most confidence when disabling the feature.

Controversy

Some communication carriers (particularly in Europe) have decided to disable Private Relay on their networks according to 9to5Mac. In a open letter via The Telegraph the carriers made claims that:

Private Relay cuts off networks and servers from accessing “vital network data and metadata” and will have “significant consequences in terms of undermining European digital sovereignty”. They say it will also impact “operator’s ability to efficiently manage telecommunication networks”.

https://9to5mac.com/2022/01/10/european-carriers-seek-to-block-iphone-private-relay-feature/

Which, personally speaking, seems kind of far fetched and seems more in line with the desire to ban encryption and encrypted DNS we’ve seen voiced in countries like the United Kingdom and the United States.

Certainly hoping through multiple servers before connecting to a website has advantages in privacy (and does make certain DNS content filters unreliable) but there’s also a slight performance loss in terms of how quickly the page loads from the user’s point of view due to the extra latency involved in routing through multiple servers. In real terms however, the Private Relay network isn’t much different than Virtual Private Network software in common use today and banning private relay specifically wouldn’t stop someone determined to mask their experience due to the prevalence of VPN services available globally.

Network Level Changes Required

Until this point we’ve been looking at the features from the point of view of the users. However if you administrate a network you can enable (or block, I suppose) the Private Relay feature by following the directions on Apple’s support page. You may wish to do this if you wanted to enable DNS level filtering (as commonly seen in parental content controls).

Apple has also made available a list of possible endpoints from which users may exit the network.

Published inA/B TestingAnalysisBrowser UpdatesMobilePrivacySecurity