You’d probably just call it “local network access” or something similar.
Most people are not running local DNS services which a device without this permission could use to probe the local network, so it’s a fairly accurate description for the majority of users I would think?
Well it can certainly help the app to get a coarse location - if it matches an existing network fingerprint (when you visit back the same network or it was scanned by other user before). This is also why you need location permissions on Android for Bluetooth or Wifi direct access.
You can do this without multicast, at least for the period of time that the listening app is allowed to run in the background (around a couple minutes, unless there are other entitlements at play), by just listening for connections on the loopback address using a regular socket.
> Did a bunch of apps specifically abuse multicast networking?
My first thought was: how does multicast IP traffic interact on cell networks?
IPv6 makes heavy use of multicast (e.g., NDP), and a lot of mobile network are now IPv6-only (clients do no get IPv4 addresses), and so if apps can start sending tracking to "everyone" on the network (or a particular base station), could that cause problems.
Cellular networks don’t quite work like this. Your mobile data connection is actually a point-to-point tunnel to a gateway somewhere in the provider packet core, so you don’t really just “leak” multicast packets to other devices on the same cell.
Even in many enterprise Wi-Fi networks, it’s quite common to see either client isolation or multicast filtering in place (in part because multicast traffic is often sent at a very low data rate and that can have unintended side effects).
My limited knowledge of multicast from working with network software a while ago was that it’s local network only, and udp and you needed to “subscribe” to get the broadcast messages. There was also a keep alive component which is a little different from normal UDP.
I wrote a tool to help debug the system by subscribing and then dumping the messages. Perhaps this the problem Apple has with it?
My understanding was a lot of routers didn’t support multicast, I know we had some issues with our network configuration.
Yep. I've noticed a couple apps that recently updated suddenly wanted to scan the network. One arguably, if you squint, might have had a legitimate reason; the other obviously didn't.
I assume some surveillance library recently changed to start asking for it, but am not sure.
I deleted both and realized it has been a while since I've watched my phone over an intercepting proxy; time to sweep for bugs again.
I don't know about iPhones specifically, but I know I used to sigh and grit my teeth every time I'd debug something networking-related while I was at a public coffee house or something, and there's all those apple laptops, broadcasting the user's registered name on the local network for lord only knows what reason.
They may well be trying to stop something equally stupid happening where someone decided it would be a good idea to blast the user's name and phone number out over the local network.
Yeah kinda random. Doesn't something similar exist if you want to download content from a domain without TLS from within an iOS app?
I vaguely remember needing to fill something out to explain why I needed users to be able to load content from http (user generated content in an app). But it makes a bit more sense in that case.