4 ms·

The APIs won’t change with alternative app stores. Asking permission for using gps or camera or … can still be enforced. Just like on macOS.

by vimy 5y ago

milderworkacc 5y ago
That’s a good point, but the behaviour I’m talking about is enforcing the optionality of those functions in order for the app to work. I might be wrong about this (not a dev, just play one on the internet) but Apple has the power to say that in order to submit an app to the App Store, user location/contacts/photos/whatever must not be required to be turned on for the app to work. ie. Apple enforces your ability to use WhatsApp without giving up microphone access. Without that model, yes, permissions are still granular. But WhatsApp can tell you to turn all of them on, or you can’t use the app. To me, that’s not a meaningful difference to the “just don’t install it” crowd’s preferred suggestion.
- DenisM 5y ago
  Worst case Apple can feed those apps a random location, supplemented with a random film roll and address book.
  - g_p 5y ago
    This approach sounds a lot like that used by XPrivacy, and its successor, XPrivacy Lua, both for rooted Android with the Xposed framework. They allowed you to spoof responses to a huge range of API calls that revealed sensitive data, by hooking function calls in the underlying OS, and returning arbitrary or random values, which could be a subset of the full valid set of values. That approach works pretty well if you test it robustly and ensure your dummy responses are valid according to the API spec. Something I always feared was that apps would try to detect this and refuse to run if you didn't have any contacts or photos, or had folders on your SD card that they could not access, but I'm not aware of this ever really having materialised, beyond banking apps and some online games using Google's device attestation, which didn't really play nice with the Xposed framework.
bradknowles 5y ago
Not really. If there’s an alternative App Store, then apps in that store can use private APIs and there’s nothing Apple can do to stop them. If there is only one App Store and it’s run by Apple, then if an app tries to use private APIs, then Apple can kick them out of the App Store. This really is an all or nothing deal. Once you jailbreak your device, or allow an alternative App Store, it’s game over for that device.
- vineyardmike 5y ago
  > there’s nothing Apple can do to stop them You can runtime check the binary calling the API, you can sandbox the binary so it can't access the API at all. I'm sure apple has tons of plans to limit this.
  - g_p 5y ago
    Arguably an approach that assumes there can be a hostile store operator would create a more secure and private product, as Apple would rely less on private entitlements and APIs in plists, and more on either technical measures to control access to these APIs, or actual security across them. There's antitrust potential around private APIs and entitlements, like the background video access given to zoom before it was available to other developers. Arguably the "green dot" status bar warning approach helps alert users to abuse of this API, and a permission prompt before first use would let users choose. Sandboxing binaries more than at present would also improve the general security posture of the device - I'd want my app sandbox to be secure even if a rogue app gets onto the device, and such a security posture would arguably better secure iOS for all users. I could see a need to namespace keychain and team IDs and similar with a secure identifier (like the public key of an alternative app store's signing CA key), to protect keychain and other information from spoofed apps, but again this kind of change would arguably better harden iOS for everyone. The less that platform security relies on trusting someone else to validate and sign a plist, the safer the more secure the platform will be for users even of the default store.
g_p 5y ago
To truly open up iOS, by my understanding, Apple would need to remove the requirement for notarisation of binaries. This would mean they'd also need to sort out their entitlements system, given an app can use entitlements to say it isn't sandboxed. That was the root cause of a recent exploit, where differing parsing logic allowed an app to get signed while declared as unsandboxed. (https://siguza.github.io/psychicpaper/ https://siguza.github.io/psychicpaper/) One approach could be to namespace installed apps based on the store ecosystem which installed them. Assuming platform level permissions for access to user data are enforced by the platform and can't be worked around via the manifest file, this would ensure apps can't move around outside of their "store" sandbox and access the data of other apps. More ideally, Apple would move away from signing a plist that gives an app special access, towards the user prompts like those for contacts access etc. And where possible, use portals to give granular access to selected resources like photos (or selected contacts).
- kbenson 5y ago
  > To truly open up iOS, by my understanding, Apple would need to remove the requirement for notarisation of binaries. Or extend the notarization system such that adding another store adds another notarization authority to check. There's no technical reason Apple can't provide a close to seamless experience for other app stores, there have always been incentives to not do so though. Even if this bill were to pass, I don't think we'd see smooth use of external app stores, but not because it's technically impossible, but because it takes effort and the incentives for Apple are still to not put any effort into it that isn't strictly required, beyond not leaving the perception of their security in shambles.
  - g_p 5y ago
    Absolutely - there's few technical barriers here. I thought about the idea of supporting multiple notaries, but concluded that the current system is too reliant on the notary system for platform security, since the signed app's permissions statement is taken "as-given". A redesign of this would certainly enable a seamless experience - just namespace apps by their store, and the official app store becomes one of many stores, sitting inside a namespace based on their public key hash. I regretably concur - the non technical barriers would go up. I could envisage some convoluted process to add a store (that would make installing a provisioning profile seem like a walk in the park, even though actually a provisioning profile might be the best technical example this could be done!), followed by a whole list of restrictions imposed on apps from alternative stores - no Apple pay access clearly, probably no NFC hardware access (wouldn't want someone able to use that hardware they paid for!!), no keychain access (to protect you). Perhaps no photo reel access and no doubt no iCloud access, and no ability to bypass background task restrictions to build your own cross device data sync ecosystem. Being able to plug in an alternative to iCloud would certainly also be nice (so you don't need their cloud storage to use data sync and other nice-to-have features some people use, like backups), but I just don't envisage it happening. Making that kind of on-device, app-facing API pluggable would be the right technical approach... But no doubt iCloud would remain the "only" storage provider, for non-technical reasons.
brundolf 5y ago
To an extent. Maybe the system can still block location access, for example, but it can't force the app to gracefully degrade without it. A future version of WhatsApp could lock you out until you give it location, contacts, calendar, phone call log. There are lots of soft-rules that Apple enforces around permissions that are still really beneficial. For example: the new "you have to be up-front about all usage of user data" would be nearly impossible to enforce at a technical level. If all the apps that don't want to comply can just leave, you may find yourself relying on Apple services even more than you do now, because nobody else will respect their rules.
- fy20 5y ago
  > If all the apps that don't want to comply can just leave, you may find yourself relying on Apple services even more than you do now. Or more likely what's gonna happen is the 95% of users who care more about having WhatsApp than privacy, will install the Facebook app store and get the apps from there.

The APIs won’t change with alternative app stores. Asking permission for using gps or camera or … can still be enforced. Just like on macOS.

by vimy 5y ago

The APIs won’t change with alternative app stores. Asking permission for using gps or camera or … can still be enforced. Just like on macOS.

milderworkacc 5y ago

That’s a good point, but the behaviour I’m talking about is enforcing the optionality of those functions in order for the app to work. I might be wrong about this (not a dev, just play one on the internet) but Apple has the power to say that in order to submit an app to the App Store, user location/contacts/photos/whatever must not be required to be turned on for the app to work. ie. Apple enforces your ability to use WhatsApp without giving up microphone access. Without that model, yes, permissions are still granular. But WhatsApp can tell you to turn all of them on, or you can’t use the app. To me, that’s not a meaningful difference to the “just don’t install it” crowd’s preferred suggestion.

DenisM 5y ago
Worst case Apple can feed those apps a random location, supplemented with a random film roll and address book.
- g_p 5y ago
  This approach sounds a lot like that used by XPrivacy, and its successor, XPrivacy Lua, both for rooted Android with the Xposed framework. They allowed you to spoof responses to a huge range of API calls that revealed sensitive data, by hooking function calls in the underlying OS, and returning arbitrary or random values, which could be a subset of the full valid set of values. That approach works pretty well if you test it robustly and ensure your dummy responses are valid according to the API spec. Something I always feared was that apps would try to detect this and refuse to run if you didn't have any contacts or photos, or had folders on your SD card that they could not access, but I'm not aware of this ever really having materialised, beyond banking apps and some online games using Google's device attestation, which didn't really play nice with the Xposed framework.

bradknowles 5y ago

Not really. If there’s an alternative App Store, then apps in that store can use private APIs and there’s nothing Apple can do to stop them. If there is only one App Store and it’s run by Apple, then if an app tries to use private APIs, then Apple can kick them out of the App Store. This really is an all or nothing deal. Once you jailbreak your device, or allow an alternative App Store, it’s game over for that device.

vineyardmike 5y ago
> there’s nothing Apple can do to stop them You can runtime check the binary calling the API, you can sandbox the binary so it can't access the API at all. I'm sure apple has tons of plans to limit this.
- g_p 5y ago
  Arguably an approach that assumes there can be a hostile store operator would create a more secure and private product, as Apple would rely less on private entitlements and APIs in plists, and more on either technical measures to control access to these APIs, or actual security across them. There's antitrust potential around private APIs and entitlements, like the background video access given to zoom before it was available to other developers. Arguably the "green dot" status bar warning approach helps alert users to abuse of this API, and a permission prompt before first use would let users choose. Sandboxing binaries more than at present would also improve the general security posture of the device - I'd want my app sandbox to be secure even if a rogue app gets onto the device, and such a security posture would arguably better secure iOS for all users. I could see a need to namespace keychain and team IDs and similar with a secure identifier (like the public key of an alternative app store's signing CA key), to protect keychain and other information from spoofed apps, but again this kind of change would arguably better harden iOS for everyone. The less that platform security relies on trusting someone else to validate and sign a plist, the safer the more secure the platform will be for users even of the default store.

g_p 5y ago

To truly open up iOS, by my understanding, Apple would need to remove the requirement for notarisation of binaries. This would mean they'd also need to sort out their entitlements system, given an app can use entitlements to say it isn't sandboxed. That was the root cause of a recent exploit, where differing parsing logic allowed an app to get signed while declared as unsandboxed. (https://siguza.github.io/psychicpaper/ https://siguza.github.io/psychicpaper/) One approach could be to namespace installed apps based on the store ecosystem which installed them. Assuming platform level permissions for access to user data are enforced by the platform and can't be worked around via the manifest file, this would ensure apps can't move around outside of their "store" sandbox and access the data of other apps. More ideally, Apple would move away from signing a plist that gives an app special access, towards the user prompts like those for contacts access etc. And where possible, use portals to give granular access to selected resources like photos (or selected contacts).

kbenson 5y ago
> To truly open up iOS, by my understanding, Apple would need to remove the requirement for notarisation of binaries. Or extend the notarization system such that adding another store adds another notarization authority to check. There's no technical reason Apple can't provide a close to seamless experience for other app stores, there have always been incentives to not do so though. Even if this bill were to pass, I don't think we'd see smooth use of external app stores, but not because it's technically impossible, but because it takes effort and the incentives for Apple are still to not put any effort into it that isn't strictly required, beyond not leaving the perception of their security in shambles.
- g_p 5y ago
  Absolutely - there's few technical barriers here. I thought about the idea of supporting multiple notaries, but concluded that the current system is too reliant on the notary system for platform security, since the signed app's permissions statement is taken "as-given". A redesign of this would certainly enable a seamless experience - just namespace apps by their store, and the official app store becomes one of many stores, sitting inside a namespace based on their public key hash. I regretably concur - the non technical barriers would go up. I could envisage some convoluted process to add a store (that would make installing a provisioning profile seem like a walk in the park, even though actually a provisioning profile might be the best technical example this could be done!), followed by a whole list of restrictions imposed on apps from alternative stores - no Apple pay access clearly, probably no NFC hardware access (wouldn't want someone able to use that hardware they paid for!!), no keychain access (to protect you). Perhaps no photo reel access and no doubt no iCloud access, and no ability to bypass background task restrictions to build your own cross device data sync ecosystem. Being able to plug in an alternative to iCloud would certainly also be nice (so you don't need their cloud storage to use data sync and other nice-to-have features some people use, like backups), but I just don't envisage it happening. Making that kind of on-device, app-facing API pluggable would be the right technical approach... But no doubt iCloud would remain the "only" storage provider, for non-technical reasons.

brundolf 5y ago

To an extent. Maybe the system can still block location access, for example, but it can't force the app to gracefully degrade without it. A future version of WhatsApp could lock you out until you give it location, contacts, calendar, phone call log. There are lots of soft-rules that Apple enforces around permissions that are still really beneficial. For example: the new "you have to be up-front about all usage of user data" would be nearly impossible to enforce at a technical level. If all the apps that don't want to comply can just leave, you may find yourself relying on Apple services even more than you do now, because nobody else will respect their rules.

fy20 5y ago
> If all the apps that don't want to comply can just leave, you may find yourself relying on Apple services even more than you do now. Or more likely what's gonna happen is the 95% of users who care more about having WhatsApp than privacy, will install the Facebook app store and get the apps from there.