Solving Connectivity Problems Caused by Interlocking Apple Privacy Settings

Originally published at: Solving Connectivity Problems Caused by Interlocking Apple Privacy Settings - TidBITS

In its ongoing effort to protect users’ privacy, Apple has built a series of related technologies into macOS 12 Monterey, iOS 15, and iPadOS 15. Unfortunately, they can cause network connectivity issues, such that you might want to disable one or more. Here is how we think they work.

1 Like

A related setting, “Private Wi-Fi Address” has caused me lots of problems, at least in understanding my network. That changes the MAC address, which is what most routers use to connect IP addresses to actual physical machines. You can disable that on a per-WiFi basis, and I’ve turned that off for the home WiFi. (You’ll get complaints from iOS when you do that…)

It’s pretty easy to see what web servers are seeing for your IP address. You can do a Google search for “what’s my ip” or use one of the sites that shows your IP address.

https://www.whatismyip.com/
https://whatismyipaddress.com/

For example, if you use the Tor browser (which does something similar to Apple iCloud Private Relay), you’ll see a different IP address, that of a Tor exit node. From a Terminal window, you can use the host command to get info about that IP address. Here’s an example using an IP address as seen when browsing with Tor:

host 185.220.100.253

That yields this response which shows the above IP apparently belongs to a Tor exit server.

253.100.220.185.in-addr.arpa domain name pointer tor-exit-2.zbau.f3netze.de.

Doing this, you should be able to compare what happens with the various settings and from using different browsers.

Debugging why a connection fails is more complex, especially when you’re adding two (or three in the case of Tor) intermediates between you and the server you’re connecting to. Some servers will block connections from the Tor network or VPNs, and maybe they will start doing that with Apple’s intermediates as well.

I consider myself a reasonably competent network guy. But the complexity of this just blows my mind. I don’t know how Apple could expect anyone not a certified network engineer to comprehend this, and I’m guessing real network engineers already know how to set up proxies. This strikes me as a solution in search of a problem. I’ve built lots of those!
Think I’ll leave all that off.

2 Likes

I spent a couple of hours trying to understand this aburdly complex, poorly designed feature. The article here is by far the best one I’ve read.

I think there’s a logical error, though:
“You might need to turn off iCloud Private Relay, turn off Limit IP Address Tracking, and turn off Safari’s Hide IP Address setting but still want to keep Mail’s Hide IP Address option enabled.”

This wouldn’t work. The feature would be disabled in Mail too.

See Use Mail Privacy Protection on Mac - Apple Support for more clarity:
“Note: If you deselect the checkbox in Network preferences to limit IP address tracking for your Wi-Fi or Ethernet network, your IP address isn’t hidden from senders when using the network.”

Trackers and a loss of privacy online is a real problem and the motivation for these features. The complexity of this solution is due to the fact that the problem it is targeted toward was intentionally created and frequently refined by nefarious people.

Don’t agree. I use a VPN, uBlock Origin and an email provider with some built-in privacy protection. None of these is complicated.

The problem here, IMO, is very poor, almost Kafkaesque design and the fact that the information which Apple provides is scattered and inadequate.

Apple could simply provide system-wide basic VPN functionality with an on-off switch and add privacy settings to Safari and Mail. The network layer is not necessary. (Who wants to block email and website trackers in network A but not in network B?)

My guess is that 95+ out of 100 people have no idea how to set this up.

I don’t know if this pun was intentional, but it made me smile in any case :grin:

1 Like

Sometimes public WiFi networks are persnickety about what you can and can’t do with them (e.g., they block certain ports that may be used by these settings, or, such as in some countries, block traffic to all VPN services), so the ability to do this discretely by network isn’t such a bad idea.

I would just turn the VPN off. I wouldn’t want macOS to remember the public Wi-Fi anyway.

I think private Wi-Fi addresses are static for each network, though. It shouldn’t give you problems, although, yes, I too disable it on trusted networks, because reasons.

But Private Relay is a cluster. It doesn’t filter all traffic—only TCP port 80 universally, and all traffic from Safari. The selective options that are also available in Mail and Safari with full coverage in iCloud Plus turned off appear to be a subset of those HTTP requests for known trackers. Both types of coverage are then disabled completely on an interface-by-interface basis. The whole shebang runs over UDP port 443, which then means that many Wi-Fi hotspots de facto block it completely because, paradoxically, they only allow TCP ports 80 and 443 (web) and DNS. (OTOH, if you’re on a public Wi-Fi, you’re getting some de facto anonymity, but not privacy.) And the speeds, well, sometimes they leave a lot to be desired: my RSS reader lire sends a flurry of requests over HTTP, which with Relay on, grinds my whole device to a crawl.

I think what they should have done is just given iCloud Plus users full-coverage VPN that could fall back to TCP port 443 for encapsulation with options for setting which networks to use it on (in the same area of the UI), and have Mail’s and Safari’s tracker blockers use simple application-layer proxying to do the whole privacy thing. I mean, really, isn’t that what this is all about—keeping the adtech people at bay? You could, with a bit more engineering, implement a two-hop relay for all protocols and sites, albeit that it would be a bit more challenging, if that was thought important enough, but a VPN is already going to get you most of the way there today, with controls in your web browser. I’ve always run with remote images off in Mail. Plus of course a VPN is going to give you geoblock avoidance, which Apple can’t do because they’re in bed with the content industry. Worse, ISPs and governments (often in hock) can trivially target iCloud, because it’s big; unless Apple proposes to make this “on by default” and ensure that it works in spite of obstacles—and part of me hopes it might, to annoy authoritarian and acquisitive ISPs and governments everywhere—it is questionable how useful this can be as a long-term means of keeping your browsing habits out of the hands of data collectors.

There’s only one bright spot in the whole situation, AFAICT: IPv6. Because the application traffic terminates at IPv6-enabled proxies, turning on Private Relay gets you IPv6 access, even if you only have IPv4. Yay! The revolution is here!

2 Likes

Adam, thanks for this analysis!

I previously had “Block Remote Content” in Mail activated prior to Monterey. When I updated to Monterey, I switched this to “Protect Mail Activity”. I then began having all kinds of problems with Mail not loading message content correctly, even what you would think is simple text.

Turning off “Limit IP address tracking” on the network interface cleared all that up. I’m not too worried about turning that option off, since I run a Pi-Hole and unbound (using DNSSEC) on an entire network basis.

1 Like

I’m growing more and more suspicious of this as the root cause for Safari connectivity problems since Monterey. I was originally skeptical about a profile since it appeared to be happening only at work (where I need that profile to be able to connect to staff wifi at all), but after reading this article, I figured I’d just try turning off Sys Prefs > Network > Wifi > Limit IP Address Tracking. And presto, ever since I did that I had no more connectivity issues with Safari on work wifi. Then this morning as an experiment, I flipped that setting back on after I had connected to work wifi, and sure enough, after about 1 hr Safari could no longer connect to a local webpage here (while Firefox had no problems). Had to toggle wifi networks to get Safari to connect again.

However, I’m not 100% sure I’m ready to fully believe this is the lone culprit quite yet. For one, Safari’s own prefs still have “Hide IP address from trackers” [as an aside, why does Apple capitalize differently in Safari Prefs vs. Sys Prefs? — actually, a closer look reveals they’re inconsistent even within the Network Sys Prefs] selected—not sure if that’s a contradiction or relevant actually. For another, just toggling the Network preference “Limit IP Address Tracking” after the issue started, did not suffice to fix the connectivity issue. I still had to toggle wifi networks first. Perhaps, I’ll never know. But for now I’m tempted to just leave the Network pref toggled off and hope that was it.

I was having unusual issues with an Apple Mail email attachment from a trusted source, one from which I’ve received the same types of attachments before. Upon clicking the attachment, Safari refused to open the “file://…”. But it had opened the same type of attachment perfectly a couple of weeks ago.

Turns out, this type of file required “Limit IP Address Tracking” to be turned off in Network Preferences as detailed in this article in order to be opened properly. But the minute I’d read this article upon publication, I had done just that. So how did it get turned back on?

The timing makes me suspect the macOS 12.5 update I’d installed July 20 as the culprit. (I can’t prove it and have no evidence.) But I’m posting this in case others have a sudden Mail or Safari issue they thought they’d already solved. In my 12.5 installation at least, this was toggled back on without my input.

2 Likes

Thank you for posting this article. I’m a network guy so I generally know my way around these kinds of things, DNS etc. Apple has a way to “disable” private relay via some DNS entries. I have these on my home network, so I thought I was good to go. I did a fresh install of Ventura and some sites wouldn’t hardly load in Safari. Once I found the setting regarding “trackers” and turned it off, everything loaded fine.

What’s super disappointing is that there are so many places to touch to enable/disable/verify this. Seems more like something Microsoft would design. For me personally I’m going the all or nothing route. Either turn everything on “full blast” or turn it all off.

2 Likes

Just in case this helps anyone else: had a weird problem in which a new iPhone 14 would not allow me to connect with Kindle. In the course of trying to fix that, Amazon’s so-called tech support discovered that I couldn’t log into any Amazon app or even into Amazon’s home page via Safari. In all cases, I got an error message that I was not connected to the internet (but no problem with any other site). Eventually I was asked to do a full restore on the phone, which did not help. They had no further suggestions and told me to talk to Apple.

The Apple tech eventually had me going through a full examination of settings on the phone. The problem turned out to be that Private Relay under the iCloud settings had been enabled. Unfortunately, you can only turn it off temporarily for a specific website, so I have disabled it entirely and will reply on my VPN, which doesn’t cause a problem with Amazon.
For info on Private Relay—About iCloud Private Relay - Apple Support

OK, so oddly enough, after months of the “Protect Mail Activity” setting in Mail resulting in every message with external content appearing with the “content could not be loaded privately” warning, suddenly, this afternoon such email is loading without that warning, and with the external content! This happened once before (under Monterey…don’t think it’s ever worked for me under Ventura). I did no updates to anything, nor changed any settings. One moment (well the interval between Mail checks was probably on the order of a couple hours) it wasn’t working, then boom! all of a sudden it was. I would love to figure out what changed where that caused this to happen. And we’ll see how long it lasts this time…