Hacker News Reader

Comment by saagarjha | Hacker News Reader

I'm honestly curious why this specific thing got trapped behind manual review. Did a bunch of apps specifically abuse multicast networking?

View on HN

I believe there must be more to this story.

Maybe it is possible to abuse multicast for tracking/fingerprinting in some way and that's why Apple is locking it down to approved apps.

It would have been unfeasible to show a permission dialog. How would you even begin to explain multicast to the average user in 1-2 sentences?

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.

Could it be used by apps to communicate with other apps on the same device?

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.

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?

I'm pretty sure my mother would have to ask me what “local network access” meant.

Also, there is nothing mom would install that would legitimately require this permission ...

multicast => communicate and find devices on your local network

I guess one sentence is enough ;=)

(Sure it's not perfect in it's explanation, but that's basically what it boils down to in it's usage.)

> 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).

That’s a interesting point (IPv6)

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.

What happens on IPv6 is a interesting question.

https://en.m.wikipedia.org/wiki/Multicast

>so if apps can start sending tracking to "everyone" on the network (or a particular base station), could that cause problems.

Then simply drop multicast packets? That's also what your ISP does with them.

Yes, a bunch of apps specifically abuse multicast networking, Bonjour discovery, etc., to tie to you.

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.

Reply on news.ycombinator.com