Actually this makes sense. Already since recent iOS versions have started popping up an alert to grant access to local network resources per app, I've noticed this popping up on several apps that have no business mapping and fingerprinting my LAN. Including the Facebook app.
It's weird how a company can be so internally disconnected. This entitlement is a good privacy-preserving hurdle to prevent scummy apps from interfering with your local network and fingerprinting you. On the other hand, the on-device scanning of nudes in imessage and csam in iphoto is a total snitchware swatting-as-a-service piece of software which only serves to incriminate and harass the owner of the device. Such a shame.
The only problem I have with it is that the entitlement system controls both what you can submit to the App Store as well as what you can locally compile and install.
For example, you can't locally develop a VPN app until you ask Apple permission to develop a VPN app. Almost certainly this is to appease China, which I find particularly egregious.
Fonts also require an entitlement, but I'm not sure if it's just something you need a paid dev account for or if you need to specifically grovel to Apple as to why you need it. I doubt "I want to submit a pull request to iSH" would be considered a valid reason (but correct me if I'm wrong).
Even things like camera access in multitasking views are entitlements that your dev account needs to be preapproved for. In fact, it wasn't even something that Apple even publicly mentioned for a while - only Zoom had it until someone reverse-engineered their app bundle and found out about it.
Your comment nicely addresses the local network restriction, but the article already expresses understanding of this. Why the extra-stringent multicast thing?
If Facebook has no business using this permission why did App Store review approve it? Surely they must know what is going on in every app, that's why the App Store is so safe.
Could you explain your posture in the CSAM scanning thing? I'm not an apple user but the way I see it, it's not some sort of nudism / age detection mechanism where a very incopetent system could land you in jail for an old digitalized photo of yourself after a shower from 30 years ago when parents actually took those kinds of pics.
The way I see it, it just hashes them with whatever mechanism they came up with and there are additional mechanisms to verify it if for some fringe conincidence your cat pictures hash matches some CSAM hash which would be annoying but not the end of the world.
Now, in the other hand, let's say the snitch detects actual CSAM in someones phone, what's the problem? if it was sent without their consent an investigation can lead to who sent it, and if it was well, tough shit...
I know it sounds very 1984ish but honestly I don't think it's any worst than the kind of surveillance power google has with all their platforms combined (chrome, android, google, any web thing they didn't kill already).
I guess, what I'm asking for is for real arguments on why and how this truly violates privacy and to what extent it is problematic for a legit non CSAM consuming person.
I'm not trying to argue with you but to understand this point of view since I read so many comments against it but nothing that seriously made sense to me.
This is such an honor. I was starting to suspect no actual humans other than the developers and the managers work at FFANG at all given how hard it is to contact them. Perhaps in this case it is not a human either but a neural network of a sort.
Anyway, I believe everything should be done this way, through communicating with humans. Humans should study every ad and every app before it gets published (but I support side-loading for users willing to opt-out), humans should review every video before it gets de-monetized or removed, humans should communicate on every appeal. I would vote for a law mandating this.
PS: The more news of this kind the more I feel like buying an iPhone perhaps. I don't like how they restrict the users but I bloody adore how they restrict the apps (with exception of some cases like iDOS, terminal apps, alternative-engine web browsers etc - I certainly don't like Apple banning them).
It doesn't seem like the author is complaining about having to contact someone at Apple to have these permissions in an app you are building to distribute. If this was for distribution, that could have made sense, but apparently this request for permission is way before that: you need to contact them simply to be able to use the feature on your own device, without distributing it anywhere.
This is like being asked to get permission from IETF in order to run an HTTP server on your computer, it just doesn't make sense.
> Anyway, I believe everything should be done this way, through communicating with humans. Humans should study every ad and every app before it gets published
Why? This is actually one of the biggest complaints about the App Store review process, because it tends to produce a lot of inconsistent results if your app comes anywhere near the gray areas of the App Store guidelines.
Mandating human review for everything sounds like a good idea for those who imagine perfect, highly-skilled, consistent reviewers handling every step of every process, but that’s not how things work in the real world. You don’t actually want to legally mandate real humans handling every step of everything, unless you want to force everything back to the days of bureaucracy and endless back-and-forth communications to get everything done.
What you are describing sounds for me exactly like a bureaucratic nightmare.
> I don't like how they restrict the users but I bloody adore how they restrict the apps
Honestly, that brought me to go away from Apple. They reject apps randomly, allow terrible security holes that affect ALL applications over relying on safari mobile web views (Pegasus) and do nothing against scams (see discussions over family sharing):
https://news.ycombinator.com/item?id=28203361
I don't agree. Developers should be able to develop whatever app they want, and not the apps that Apple decides that can be developed.
Modern smartphone have a lot of potential that cannot be exploited only for policies. One example is network connections in general, it's so restricted that is barely usable. For example controlling the network interfaces is problematic. On iOS (and now also on Android) you can't tell the phone to connect to a particular Wi-Fi network, only to a network with a prefix and it's not even that reliable. Where that would be useful? Of course in an app that connects to some device that exposes a Wi-Fi AP.
I develop embedded devices and thanks to mobile phones network limitations everything has to pass trough a cloud. That is a big improvement for privacy if we ask Apple? I don't think so. But there are really no reliable ways to control something in your LAN. Well if you give Apple a ton of money to implement HomeKit by putting the Apple proprietary chip in your product of course, why do you think they impose this limitations?
If I bought an iPhone, I'd use it to call people. That's probably it.
Android phones are nice because they at least respect my pre-existing workflow. I can sync my Nextcloud server to keep my notes and photos distributed, I can install different shells to get work done on the go, Hell, I can even use it to send a firmware payload to my Nintendo Switch in RCM mode. It's my swiss-army knife for when it's impractical to carry a full Unix machine.
Ok, this is about Bonjour, which is pretty cool. David Abramson and I released a multiplayer Horse Racing game, called PocketJockey on iOS 2.1. During game play each device would play its local copy of the William Tell Overture. We used packet latency to synchronize tracks. You would then bounce up and down as though you were a jockey. If you bounced in time to the music your horse would go faster. There was an announcer that would announce the status of your horse, which was also in synch. Up to 4 players could be playing in the same room with the exact same music and announcer emanating from their pocket. All on the original iPhone. To use an overused term, the experience was "magical" That's what you can do with Bonjour.
So, what's the attack vector? A back door, perhaps? Bonjour requires a user approval dialog. A misleading title of the dialog may allow someone to connect. Maybe extract private data.
Imagine a peer-to-peer chat app. Say, in Hong Kong -- during a protest. Or in Kabul -- during an evacuation.
What's funny, is all these issues were raised when Apple rolled out Zeroconf (old name for Bonjour). Apple pointed out that it wasn't a vulnerability, and that not doing it was akin to punching people who came in the front door, while leaving illegal entry unattended.
I fell into this trap with our app. We have an iot app that controls 3 generations of hardware now. The first generation device is only visible via Netbios lookup, which runs afoul of this new multicast lockdown. The later 2 generations support Bonjour (mdns) lookup. Unfortunately we are still running into problems with customer routers that block or interfere with Bonjour service discovery, so we still fall back on Netbios even in current generation hardware. Luckily we have history with Apple so the approval was fairly straightforward, but I can't imagine what the process would entail for a new company/new product.
We "fixed" it with broadcast, it was the only way.
There are indeed a number of old routers out there that do not work with mDNS well. This is still a problem, but most <5yo routers seem to handle it okay (with the caveat that there are a number of cheap APs and extenders that are completely broken at basic TCP/IP when clients switch).
We use broadcast for device-to-device discovery, vs device-to-phone. It makes for noisy networks, but works better than mDNS on a wide range of hardware.
> 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.
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.
Apple is also sabotaging the Bluetooth Low-Energy standard, by blocking apps from registering certain standard service IDs. For example, iOS doesn't allow apps to provide a HID-over-GATT service, which could be used to implement HID-compliant peripherals (i.e. keyboard, mouse, game controller, etc.).
When you try to launch a BLE service with the required identifier, the framework simply throws an error: "The specified UUID is not allowed for this operation." :-)
This is why there are no Bluetooth keyboard/mouse/trackpad apps in the AppStore, while there are many on Android.
What bothers me even more, is that you need developer account (100$/year), and go through these manual reviews, if you want to develop and tests apps on simulator or your own iOS devices.
They already have manual review process for submitting apps to the App Store, so I don't understand why I would also need permissions before I start developing apps using restricted features.
My iOS developer story ended shortly after I attempted to start back in 2008. To run apps I’d written on a device I had to sign up and pay for an account, which I was ok with. Then my account was suspended until I proved who I was with a scan of a government issued document. As a non US citizen my ID had little protection so I said no. After a few months apple agreed and refund my $99. So I’ve never written for iOS. The upside was I made a small profit thanks to a swing in the exchange rate :)
I haven't renewed my Apple Developer subscription in a few years but I'm still developing and testing apps at home on the free tier. It hasn't been necessary to the subscription for a few years. Only if you plan to release to the App Store or want developer betas.
I may be in a niche scenario. But I do welcome some sort of restriction. On a large campus network running PIM sparse with 10kish Apple devices, multicast chews up a fair amount of CPU resources on network devices.
Not sure if this is the solution tho..that's out of my realm of expertise.
Apple is getting worse day after day. I'm still hoping that one day the EU Commission will finally go after them and force them to open up their stuff.
I know this is pure conjecture with regards to this particular situation, but I already had couple of clashes with operations people over use of multicast in my applications. They basically trying to tell me there is never valid case for multicast so they just outright filter it out everywhere with no possibility of enabling it.
I have to imagine this is related to the release of Matter, the smart home communication standard. Cutting off multicast cuts off a standard way existing network connected home automation devices work, forcing users to Matter and to ultimately buy into a new ecosystem.
It will also seriously harm their TV/AirPlay competitor Chromecast, right? I have to imagine that every app with a Chromecast integration is using multicast to discover devices, but I could be wrong.
I'm confused. Does he need this form's approval to compile on XCode and push over USB to his device, or does he only need it to submit to the app store?
Handling specialized permissions one at a time through specialized teams could make sense for distribution. allows the whole-app reviewers to not have to also become experts on multicast best practices/security and having a second reviewer handle that.
You need the permission granting before you can run it locally. It gets added to the provisioning profile that is used as part of the signing process, even when run through Xcode.
It's to prevent people bypassing this approval and distributing their app through other methods.
I like the idea of having to grant applications permissions to use multicast, and to make the suggested behavior be "deny permissions", but whatever this form is I don't like it.
In my case, filing the form was not enough: they then asked me by email for more info (IP addresses and ports used, a description of the protocol, etc...).
If you want to save a week of waiting, I suggest including all that info upfront in the form.
I think this might be to have some leverage against Google with Chromecast, Amazon with Fire stick, etc.
If they can make connecting to those devices a pain for developers, it will tip the balance in favour of apple TV and devices apple chooses to whitelist.
This reminds me when we were working on a business push notification app, much like WhatsApp business but back in 2015. Apple required users to allow push notifications for the app when installing. If a user disabled push notifications then it effectively stopped the app from working as it's sole purpose was to send push notifications. So to try combat users turning off push notifications without realizing what they had done, we would prompt them to say that turning off push notifications would stop the app from working. We submitted the app to the app store and Apple rejected the new version saying that we were forcing users to enable push notifications.
I remember being so frustrated with this process of trying to convince someone in Apple who just didn't seem to understand why this would make sense. They cited that it was a poor user experience but I can't imagine a worse experience than a messaging app that never received push notifications.
I hear this kind of complaining from greybeards all the time. And I have some sympathy having grown up in the early 90s when you legitimately could tinker with every aspect of your computer. I kind of miss that; I suspect I’d miss it more if I had more time.
But as a customer I appreciate this stuff. I need some shortcuts to be able to maintain reasonable opsec without dedicating my life to dodging surveillance. I’m ok if it makes applications harder to develop because there are plenty on the App Store already.
If you want a device that can run arbitrary code, Android exists. Laptops exist. You have options. I don’t want a device like that in my pocket, however. It doesn’t fit in my personal security model.
[+] [-] 0x0|4 years ago|reply
It's weird how a company can be so internally disconnected. This entitlement is a good privacy-preserving hurdle to prevent scummy apps from interfering with your local network and fingerprinting you. On the other hand, the on-device scanning of nudes in imessage and csam in iphoto is a total snitchware swatting-as-a-service piece of software which only serves to incriminate and harass the owner of the device. Such a shame.
[+] [-] kmeisthax|4 years ago|reply
For example, you can't locally develop a VPN app until you ask Apple permission to develop a VPN app. Almost certainly this is to appease China, which I find particularly egregious.
Fonts also require an entitlement, but I'm not sure if it's just something you need a paid dev account for or if you need to specifically grovel to Apple as to why you need it. I doubt "I want to submit a pull request to iSH" would be considered a valid reason (but correct me if I'm wrong).
Even things like camera access in multitasking views are entitlements that your dev account needs to be preapproved for. In fact, it wasn't even something that Apple even publicly mentioned for a while - only Zoom had it until someone reverse-engineered their app bundle and found out about it.
[+] [-] bjackman|4 years ago|reply
[+] [-] veeti|4 years ago|reply
[+] [-] l-albertovich|4 years ago|reply
The way I see it, it just hashes them with whatever mechanism they came up with and there are additional mechanisms to verify it if for some fringe conincidence your cat pictures hash matches some CSAM hash which would be annoying but not the end of the world.
Now, in the other hand, let's say the snitch detects actual CSAM in someones phone, what's the problem? if it was sent without their consent an investigation can lead to who sent it, and if it was well, tough shit...
I know it sounds very 1984ish but honestly I don't think it's any worst than the kind of surveillance power google has with all their platforms combined (chrome, android, google, any web thing they didn't kill already).
I guess, what I'm asking for is for real arguments on why and how this truly violates privacy and to what extent it is problematic for a legit non CSAM consuming person.
I'm not trying to argue with you but to understand this point of view since I read so many comments against it but nothing that seriously made sense to me.
[+] [-] swiley|4 years ago|reply
[+] [-] qwerty456127|4 years ago|reply
This is such an honor. I was starting to suspect no actual humans other than the developers and the managers work at FFANG at all given how hard it is to contact them. Perhaps in this case it is not a human either but a neural network of a sort.
Anyway, I believe everything should be done this way, through communicating with humans. Humans should study every ad and every app before it gets published (but I support side-loading for users willing to opt-out), humans should review every video before it gets de-monetized or removed, humans should communicate on every appeal. I would vote for a law mandating this.
PS: The more news of this kind the more I feel like buying an iPhone perhaps. I don't like how they restrict the users but I bloody adore how they restrict the apps (with exception of some cases like iDOS, terminal apps, alternative-engine web browsers etc - I certainly don't like Apple banning them).
[+] [-] karakanb|4 years ago|reply
This is like being asked to get permission from IETF in order to run an HTTP server on your computer, it just doesn't make sense.
[+] [-] PragmaticPulp|4 years ago|reply
Why? This is actually one of the biggest complaints about the App Store review process, because it tends to produce a lot of inconsistent results if your app comes anywhere near the gray areas of the App Store guidelines.
Mandating human review for everything sounds like a good idea for those who imagine perfect, highly-skilled, consistent reviewers handling every step of every process, but that’s not how things work in the real world. You don’t actually want to legally mandate real humans handling every step of everything, unless you want to force everything back to the days of bureaucracy and endless back-and-forth communications to get everything done.
[+] [-] callmeal|4 years ago|reply
Well, they only restrict apps for us peons. Companies with money can use undocumented apis no problem. Case in point:
https://www.macrumors.com/2021/05/09/zoom-ipad-camera-api-ac...
[+] [-] kgarten|4 years ago|reply
Have you seen Brazil? https://en.wikipedia.org/wiki/Brazil_(1985_film)
What you are describing sounds for me exactly like a bureaucratic nightmare.
> I don't like how they restrict the users but I bloody adore how they restrict the apps
Honestly, that brought me to go away from Apple. They reject apps randomly, allow terrible security holes that affect ALL applications over relying on safari mobile web views (Pegasus) and do nothing against scams (see discussions over family sharing): https://news.ycombinator.com/item?id=28203361
[+] [-] alerighi|4 years ago|reply
Modern smartphone have a lot of potential that cannot be exploited only for policies. One example is network connections in general, it's so restricted that is barely usable. For example controlling the network interfaces is problematic. On iOS (and now also on Android) you can't tell the phone to connect to a particular Wi-Fi network, only to a network with a prefix and it's not even that reliable. Where that would be useful? Of course in an app that connects to some device that exposes a Wi-Fi AP.
I develop embedded devices and thanks to mobile phones network limitations everything has to pass trough a cloud. That is a big improvement for privacy if we ask Apple? I don't think so. But there are really no reliable ways to control something in your LAN. Well if you give Apple a ton of money to implement HomeKit by putting the Apple proprietary chip in your product of course, why do you think they impose this limitations?
[+] [-] okasaki|4 years ago|reply
They could automatically approve/reject and store the form in case they need to review it later.
[+] [-] smoldesu|4 years ago|reply
Android phones are nice because they at least respect my pre-existing workflow. I can sync my Nextcloud server to keep my notes and photos distributed, I can install different shells to get work done on the go, Hell, I can even use it to send a firmware payload to my Nintendo Switch in RCM mode. It's my swiss-army knife for when it's impractical to carry a full Unix machine.
[+] [-] amelius|4 years ago|reply
Or perhaps we should just have fines in case things go awry. I mean, if it works, AI should be allowed. The problem is that it doesn't work.
[+] [-] musesum|4 years ago|reply
So, what's the attack vector? A back door, perhaps? Bonjour requires a user approval dialog. A misleading title of the dialog may allow someone to connect. Maybe extract private data.
Imagine a peer-to-peer chat app. Say, in Hong Kong -- during a protest. Or in Kabul -- during an evacuation.
[+] [-] cbsmith|4 years ago|reply
[+] [-] seanalltogether|4 years ago|reply
[+] [-] creeble|4 years ago|reply
There are indeed a number of old routers out there that do not work with mDNS well. This is still a problem, but most <5yo routers seem to handle it okay (with the caveat that there are a number of cheap APs and extenders that are completely broken at basic TCP/IP when clients switch).
We use broadcast for device-to-device discovery, vs device-to-phone. It makes for noisy networks, but works better than mDNS on a wide range of hardware.
[+] [-] saagarjha|4 years ago|reply
[+] [-] jannes|4 years ago|reply
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?
[+] [-] throw0101a|4 years ago|reply
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.
[+] [-] Terretta|4 years ago|reply
[+] [-] evilDagmar|4 years ago|reply
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.
[+] [-] jamil7|4 years ago|reply
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.
[+] [-] aaaaaaaaaaab|4 years ago|reply
When you try to launch a BLE service with the required identifier, the framework simply throws an error: "The specified UUID is not allowed for this operation." :-)
This is why there are no Bluetooth keyboard/mouse/trackpad apps in the AppStore, while there are many on Android.
[+] [-] watermelon0|4 years ago|reply
They already have manual review process for submitting apps to the App Store, so I don't understand why I would also need permissions before I start developing apps using restricted features.
[+] [-] markb139|4 years ago|reply
[+] [-] simonh|4 years ago|reply
[+] [-] yardie|4 years ago|reply
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] simondotau|4 years ago|reply
[+] [-] vlan0|4 years ago|reply
Not sure if this is the solution tho..that's out of my realm of expertise.
[+] [-] rock_artist|4 years ago|reply
They actually have big troubleshooting section for this cumbersome entitlement:
https://ableton.github.io/linkkit/
[+] [-] qalmakka|4 years ago|reply
[+] [-] jjgreen|4 years ago|reply
[+] [-] lmilcin|4 years ago|reply
I know this is pure conjecture with regards to this particular situation, but I already had couple of clashes with operations people over use of multicast in my applications. They basically trying to tell me there is never valid case for multicast so they just outright filter it out everywhere with no possibility of enabling it.
[+] [-] thedougd|4 years ago|reply
[+] [-] cmelbye|4 years ago|reply
[+] [-] oaiey|4 years ago|reply
[+] [-] HWR_14|4 years ago|reply
Handling specialized permissions one at a time through specialized teams could make sense for distribution. allows the whole-app reviewers to not have to also become experts on multicast best practices/security and having a second reviewer handle that.
[+] [-] chedabob|4 years ago|reply
It's to prevent people bypassing this approval and distributing their app through other methods.
[+] [-] blurbleblurble|4 years ago|reply
[+] [-] betterunix2|4 years ago|reply
[+] [-] koolhaas|4 years ago|reply
[+] [-] Jyaif|4 years ago|reply
[+] [-] withinboredom|4 years ago|reply
[+] [-] londons_explore|4 years ago|reply
If they can make connecting to those devices a pain for developers, it will tip the balance in favour of apple TV and devices apple chooses to whitelist.
[+] [-] Drewza|4 years ago|reply
I remember being so frustrated with this process of trying to convince someone in Apple who just didn't seem to understand why this would make sense. They cited that it was a poor user experience but I can't imagine a worse experience than a messaging app that never received push notifications.
[+] [-] wayoutthere|4 years ago|reply
But as a customer I appreciate this stuff. I need some shortcuts to be able to maintain reasonable opsec without dedicating my life to dodging surveillance. I’m ok if it makes applications harder to develop because there are plenty on the App Store already.
If you want a device that can run arbitrary code, Android exists. Laptops exist. You have options. I don’t want a device like that in my pocket, however. It doesn’t fit in my personal security model.