Maybe the culprit is the technology and nasty tricks backing the "Find my device" feature? iOS devices will share their location (and potentially other data) with other nearby devices using a mesh network with certain frequency, even in Airplane mode. Also if the iPhone/iPad is powered off using the "power off" feature, the device will still be findable.
This capability is one of the strong selling points for consumers. The modern, average thief will often toss away these devices and settle with the rest of the loot because of this.
I'm aware of "Find My Device" that's a documented feature. Find My beacons go OUT
(your device tells others where it is). This is 84MB coming IN. Different thing.
Well, such traffic goes OUT somewhere and that somewhere is other iDevices so that's traffic coming IN for them, no?
I don't have evidence supporting either possibility other than the fact that there's indeed an obscure mesh network involved for "Find My" to operate. I hope this is the starting point to figuring out what their infrastructure does.
Yes, that is used to exchange information between iDevices. The "Find my" mechanism is proprietary and closed source, so you cannot categorically discard the possibility of iOS using such tunnel to send/receive/forward such information.
Yes it could be something else. But if we want to be rigorous, we cannot discard possibilities we aren't 100% sure about.
You are right... and being rigorous is the only path to trust. We can shift the issue from "what is it" to "why isn't it documented and why does status report inactive.
84.5 MB through utun2/IDS during stated isolation—benign or not—contradicts "wireless features turned off" and users have no verification path.
The "closed source" problem you identified is the core issue. So to be rigorous, plausible deniability ends where the telemetry contradicts the UI.
It is evident that Facebook does not QA the way they should. It would be nice if Apple added mechanisms that allow a dependency in an app to crash but allow the host app to continue to run regardless.
I think AD is probably the best (if not the single) reason to use MS boxes. It's quite a beast and you have to know its little tricks but hey, the same goes for any other solution of similar scale.
Former Senior Windows SysAdmin here --worked in large scale infrastructures and was the lead in a team dedicated to securing hundreds/thousands of servers.
My answer: No f*ing way.
I've seen too many times that pattern of "oh we fixed this security flaw on a patch tuesday only to realize it opened a backdoor in some other way". Securing Windows boxes is a pointless rat race. They have backdoors in them, guaranteed.
You have no idea what you're talking about. Apps use the Facebook library because a good portion of end-users want to be able to login with a Facebook button --or Google, or whatever that doesn't require them to create a user/password account. It's just that simple.
if (restrictiveParams[eventName] as! [String: Any])["test"] != nil
In Swift, now hopefully you wouldn't write this code but it's not entirely unlikely too. In fact the above Objective-C snippet is one of the few cases where Objective-C's forgiving `nil` behaviour doesn't save you from a crash.
This capability is one of the strong selling points for consumers. The modern, average thief will often toss away these devices and settle with the rest of the loot because of this.
Sounds like OP wasn't aware of this.