How to preempt data exfiltration on iOS?

Any component that is not local to the iPhone will struggle to do per-app blocking correctly because the information about what app is doing the communication is lost once you leave the iPhone. So you do want a solution on the iPhone itself.

Indeed. Why not get your friend to sign up and answer questions directly? since that information is likely to be needed.

I think we need specific accurate information on that.

I think it may be a recent change. Apple has recognised that there is a market for controlling how other companies rape your privacy while still doing it themselves. :joy:

Indeed - and we never will. Only Apple knows what it actually implements in response to a “deny”.

My guess is that it is better than that. However I can’t see exactly how one would define “personal information” in a way that would allow a robust implementation.

Yes but downloading map tiles is not the same as uploading personal information - albeit that downloading map tiles does admit the possibility of leaking your location, by inference.

That’s interesting. Do you happen to know if there any open-source firmware stacks that can do that? (Not that open-source means free of vulnerabilities, but at least it’s a step in the right direction.)

I’ve asked for more details from my friend who made the claim about “personal information” blocking. I ran a quick test myself on the latest iOS but found no such behavior, just the usual permissioning questions when installing a new app. But more to the point, I agree with your assessment that we’ll never know what “personal information” means anyway. Considering how bastardized Apple Private Relay is, vs. even a low-end VPN, it seems that one shouldn’t maintain any faith that it materially contributes to privacy. It’s typical architecture astronaut blather: make the interface so abstract that the user no longer knows what the controls actually accomplish, then claim that it’s superintelligent and “just takes care of you”. I suppose I should have realized this in the first place, but if I get any more info back on it, I’ll share it here. And your implied point is correct that uploading map tile fetches (or any other seemingly trivial content) would be leaking personal information (although not necessarily location), while it might not leak “personal information” in the Apple PR sense.

OpenWRT can use a whitelist.

1 Like

After a lot of back-and-forth with my friend, it has finally dawned on me that the allowlist, denylist, and Blokada approaches are all hopeless. It basically comes down to the unpredictability of network addresses, especially across app updates. I didn’t fully appreciate this until we went through the whole exercise and also looked into the router approach. I was also unable to turn off automatic updates, which is a problem if one is trying to implement a learn-once policy.

One can’t even use a separate phone, practically speaking, because it would need to connect to the other one in order to obtain data to manipulate, such as photos to edit. (Bluetooth transfer is garbage. Let’s not even go there.) It would thus be necessary to go through USB to a desktop or laptop, which is totally awkward. Well, maybe one could put the “bad” phone on a captive local network, while the “good” one is connected to the real internet most of the time or the the local network when sharing is required. Still damn awkward.

Realistically, what’s needed is nothing short of per-app network access blockage. I’d like to get that message to Apple, if for no other reason than just to hear their justification for why this shouldn’t be implemented, but I can’t get it to them because their account registration process requires deanonymization. If anyone here can do that, go ahead and post a link to your discussion thread, or link them back to this one so they can see how two-faced they look for saying that they support user privacy, while rolling out the red carpet for data exfiltrators. I don’t think they’re dumb enough not to have considered this, but I’m stumped as to why they wouldn’t have gone this route when clearly they can do it for WAN. “Don’t worry because the App Store contract prohibits unauthorized exfiltration” would be late-night comedy material, so I hope they don’t fall back on this.

1 Like

Still better than nothing. Besides, it gets costly to shuffle domains all the time. Blocking domains isn’t a silver bullet, sure, but its still effective, particularly if you keep your lists updated.

AFAIK Blokada doesn’t provide the ability to track domain accesses or block them in a custom way. All it does is allow one to select from a list of block lists made by others, which isn’t likely relevant to whatever random apps one has installed. There’s no interface provided by which one might do that for oneself, which would require (1) discovery by app monitoring and (2) appending some wildcard form of the offending domain accesses to one’s block list.

It does provide a way to turn on logging if using their VPN, but it sounds like doing so enables logging at their end as opposed to locally on the phone. None of this is actually explained, so I told my friend just to give up. Maybe I should have continued down that route? But if I did, how would I then convert those domain observations into a block list that I could tell the app to use? It’s so menu-oriented, it’s awful. There’s no “custom filter” button anywhere I can see. (To be fair, I’m going on screenshots here, so please correct me if I’m wrong and he needed to scroll down or something.)

I haven’t used blokada in a while, but @amarok I believe uses it. Perhaps he has the answers to your questions.

1 Like

Here are some of the blocking options (including options to block any website, or any app on your device):


Many well-known public blocklists that can be toggled on or off:

Network blocking options:

And the connection log shows every outgoing connection, allowed or blocked, in real time; these are connections from the OS or from any app that’s running (including from websites visited in the browser). You can manually add any connection you want to disallow:

2 Likes

Ah ha! Now I think I know what’s going on. You’re taking screenshots on Android and assuming that they just apply to iOS as well. But they don’t because iOS is fatally insecure garbage. When you go to the “Advanced” menu on iOS, you get only the blocklists. You can’t monitor anything (unless you enable upstream logging, barf) or create exceptions like you can in your version. I even looked at some other similar apps and none of them can do anything on a per-app basis, no doubt because iOS aggregates all the traffic before allowing a VPN service (Blokada in this example) to hook it.

Evil hunk of turd. Someone with access to Apple support needs to bitch about this. I call it the “Exfiltrate the Kitchen Sink” vulnerability.

And by the way, thanks for the screenshots. That cleared up a lot of confusion.

I’m not assuming anything; I was merely showing the app I use. :wink:

P.S. The issue with iOS appears to be related to this: https://teddit.net/r/blokada/comments/ql3tbe/is_blokada_totally_broken_on_ios_now/

Blokada seems to be moving to a cloud solution for iOS: https://blokada.org/#about

1 Like

Thanks!

“Solution: Sold iPhone.”

That seems to have fixed the issue.

4 Likes