Apple App Store: Difference between revisions

Line 43:

== Sandbox ==

You might not like app sandboxing, but it's a powerful security feature used on all modern platforms. The reality is very few apps need more than a few basic permissions. [[wikipedia:Flatpak|Flatpak]] on Linux also sandboxes apps, and it seems to work great! Still, it's completely fair that there should be processes for doing things beyond what the sandbox allows. You see some of this with permission prompts - does a flashlight app ''really'' need access to your contacts? (Apple has been burned by [https://www.theverge.com/2012/2/14/2798008/ios-apps-and-the-address-book-what-you-need-to-know apps abusing ~~their kindness~~] before.)

You might not like app sandboxing, but it's a powerful security feature used on all modern platforms. The reality is very few apps need more than a few basic permissions. [[wikipedia:Flatpak|Flatpak]] on Linux also sandboxes apps, and it seems to work great! Still, it's completely fair that there should be processes for doing things beyond what the sandbox allows. You see some of this with permission prompts - does a flashlight app ''really'' need access to your contacts? (Apple has been burned by [https://www.theverge.com/2012/2/14/2798008/ios-apps-and-the-address-book-what-you-need-to-know apps abusing user data] before the current permission system was built out.)

It can go further than this. As we established in previous sections, an app can be given more access to features of the system using entitlements. These come in a few flavors:

Line 53:

There have been [https://gizmodo.com/researchers-uber-s-ios-app-had-secret-permissions-that-1819177235 exceptions] where Apple quietly gave a company access to private entitlements anyway, raising eyebrows.

On iOS, you also can't be ''more'' secure than the default sandbox. That might seem crazy, but it's pretty important for security in a variety of situations. On macOS, there are several entitlements you must declare to decide whether you're allowed to access certain types of user data at all. Android ~~echoed~~ this design from the very start - you can't even do ~~fairly~~ fundamental things like access the internet without declaring it in your manifest. It makes it very ~~clear~~ what the app ~~intends to do~~.

On iOS, you also can't be ''more'' secure than the default sandbox. That might seem crazy if you're not a developer, but it's pretty important for security in a variety of situations. On macOS, there are several entitlements you must declare to decide whether you're allowed to access certain types of user data at all. Android used this design from the very start - you can't even do fundamental things like access the internet without declaring it in your manifest. It makes it very explicit what the app's intentions are.

iOS has one sandbox used by all App Store apps. System apps, and App Store apps developed by Apple, are allowed to expand or reduce their sandbox permissions as needed. Third-party apps do not get the right to expand or reduce their sandbox permissions at all. This is clearly less secure. To take the example of Playgrounds again, while it's allowed to run your code from a separate process executing in an ultra locked down sandbox with very few permissions, competing apps such as Pythonista must run your code ~~entirely~~ in the same sandbox and address space as the main app process. The Python interpreter crashing would therefore crash the entire app, possibly losing work. In the worst case, a vulnerability in third-party code could give access to all data stored by/accessible to the app. If that third-party code could run in its own limited sandbox, the risk is significantly reduced.

iOS has one sandbox used by all App Store apps. System apps, and App Store apps developed by Apple, are allowed to expand or reduce their sandbox permissions as needed. Third-party apps do not get the right to expand or reduce their sandbox permissions at all. This is clearly less secure. To take the example of Playgrounds again, while it's allowed to run your code from a separate process executing in an ultra locked down sandbox with very few permissions, competing apps such as Pythonista must run your code in the same sandbox and address space as the main app process. The Python interpreter crashing would therefore crash the entire app, possibly losing work. In the worst case, a vulnerability in third-party code could give access to all data stored by/accessible to the app. If that third-party code could run in its own limited sandbox, the risk is significantly reduced.

The only known workaround is to execute the code via JavaScript, as Apple's JavaScriptCore engine runs in a heavily sandboxed process. This requires you to port the code to JS, which may be a lot of work, or just not viable. You wouldn't want to run the Python interpreter inside JavaScript - the performance would be terrible!

@@ Line 43: / Line 43: @@
 == Sandbox ==
-You might not like app sandboxing, but it's a powerful security feature used on all modern platforms. The reality is very few apps need more than a few basic permissions. [[wikipedia:Flatpak|Flatpak]] on Linux also sandboxes apps, and it seems to work great! Still, it's completely fair that there should be processes for doing things beyond what the sandbox allows. You see some of this with permission prompts - does a flashlight app ''really'' need access to your contacts? (Apple has been burned by [https://www.theverge.com/2012/2/14/2798008/ios-apps-and-the-address-book-what-you-need-to-know apps abusing their kindness] before.)
+You might not like app sandboxing, but it's a powerful security feature used on all modern platforms. The reality is very few apps need more than a few basic permissions. [[wikipedia:Flatpak|Flatpak]] on Linux also sandboxes apps, and it seems to work great! Still, it's completely fair that there should be processes for doing things beyond what the sandbox allows. You see some of this with permission prompts - does a flashlight app ''really'' need access to your contacts? (Apple has been burned by [https://www.theverge.com/2012/2/14/2798008/ios-apps-and-the-address-book-what-you-need-to-know apps abusing user data] before the current permission system was built out.)
 It can go further than this. As we established in previous sections, an app can be given more access to features of the system using entitlements. These come in a few flavors:
@@ Line 53: / Line 53: @@
 There have been [https://gizmodo.com/researchers-uber-s-ios-app-had-secret-permissions-that-1819177235 exceptions] where Apple quietly gave a company access to private entitlements anyway, raising eyebrows.
-On iOS, you also can't be ''more'' secure than the default sandbox. That might seem crazy, but it's pretty important for security in a variety of situations. On macOS, there are several entitlements you must declare to decide whether you're allowed to access certain types of user data at all. Android echoed this design from the very start - you can't even do fairly fundamental things like access the internet without declaring it in your manifest. It makes it very clear what the app intends to do.
+On iOS, you also can't be ''more'' secure than the default sandbox. That might seem crazy if you're not a developer, but it's pretty important for security in a variety of situations. On macOS, there are several entitlements you must declare to decide whether you're allowed to access certain types of user data at all. Android used this design from the very start - you can't even do fundamental things like access the internet without declaring it in your manifest. It makes it very explicit what the app's intentions are.
-iOS has one sandbox used by all App Store apps. System apps, and App Store apps developed by Apple, are allowed to expand or reduce their sandbox permissions as needed. Third-party apps do not get the right to expand or reduce their sandbox permissions at all. This is clearly less secure. To take the example of Playgrounds again, while it's allowed to run your code from a separate process executing in an ultra locked down sandbox with very few permissions, competing apps such as Pythonista must run your code entirely in the same sandbox and address space as the main app process. The Python interpreter crashing would therefore crash the entire app, possibly losing work. In the worst case, a vulnerability in third-party code could give access to all data stored by/accessible to the app. If that third-party code could run in its own limited sandbox, the risk is significantly reduced.
+iOS has one sandbox used by all App Store apps. System apps, and App Store apps developed by Apple, are allowed to expand or reduce their sandbox permissions as needed. Third-party apps do not get the right to expand or reduce their sandbox permissions at all. This is clearly less secure. To take the example of Playgrounds again, while it's allowed to run your code from a separate process executing in an ultra locked down sandbox with very few permissions, competing apps such as Pythonista must run your code in the same sandbox and address space as the main app process. The Python interpreter crashing would therefore crash the entire app, possibly losing work. In the worst case, a vulnerability in third-party code could give access to all data stored by/accessible to the app. If that third-party code could run in its own limited sandbox, the risk is significantly reduced.
 The only known workaround is to execute the code via JavaScript, as Apple's JavaScriptCore engine runs in a heavily sandboxed process. This requires you to port the code to JS, which may be a lot of work, or just not viable. You wouldn't want to run the Python interpreter inside JavaScript - the performance would be terrible!