Apple App Store: Difference between revisions
m Flatpak just makes code distribution easier by bundling dependencies. Docker is a better example of sandboxing. |
added summary for less technical users |
||
(2 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
{{ToneWarning}} | |||
[[File:App Store (iOS).svg|thumb|150px]] | [[File:App Store (iOS).svg|thumb|150px]] | ||
Line 109: | Line 110: | ||
==JIT== | ==JIT== | ||
[[wikipedia:Just-in-time compilation|JIT]], which stands for Just-In-Time, is a method of code execution where code, instead of being compiled before being distributed (like an EXE), gets compiled into machine code in real time right before being executed. This method of code execution allows for much faster website loading times, faster emulation, faster program execution (with programs written in JavaScript, Python, Lua...) compared to interpreters, which instead translates code into machine code line by line, which is much, much slower | The following paragraph is highly technical, if it's too technical for you to understand all you need to know is that: JIT allows for extremely fast programs/apps and due to its fast nature it's used almost everywhere, and is a massive improvement over older code interpreters. | ||
[[wikipedia:Just-in-time compilation|JIT]], which stands for Just-In-Time, is a method of code execution where code, instead of being compiled before being distributed (like an EXE), gets compiled into machine code in real time right before being executed. This method of code execution allows for much faster website loading times, faster emulation, faster program execution (with programs written in JavaScript, Python, Lua...) compared to interpreters, which instead translates code into machine code line by line, which is much, much slower; JIT also employs many more optimization techniques meant to improve performance. | |||
Safari is allowed to use JIT to compile code from any site, same with Apple's [https://apps.apple.com/app/swift-playgrounds/id908519492 Playgrounds] app on iPad. Playgrounds bundles Apple's [[wikipedia:Swift (programming language)|Swift]] compiler, and shares backend code with the version of Playgrounds found in [[wikipedia:Xcode|Xcode]]. | Safari is allowed to use JIT to compile code from any site, same with Apple's [https://apps.apple.com/app/swift-playgrounds/id908519492 Playgrounds] app on iPad. Playgrounds bundles Apple's [[wikipedia:Swift (programming language)|Swift]] compiler, and shares backend code with the version of Playgrounds found in [[wikipedia:Xcode|Xcode]]. | ||
Line 122: | Line 125: | ||
==Sandbox== | ==Sandbox== | ||
Sandboxing is a powerful security feature used on all modern platforms, from Windows to iOS, and it's used because most programs need only a few basic permissions. While sandboxing is a great security measure, sometimes users may want to develop or create programs that run outside of the sandbox, with less restrictions. When a program needs extra permissions outside of what the sandbox normally allows, the user is prompted with a permission prompt, useful when some very basic programs (like a flashlight app) need access to sensitive information like contacts. | |||
As established in previous sections, a program can be given more access to features of the system using entitlements. These come in different types: | |||
*'''Completely safe''': Entitlements any developer can opt into, with little to no risk. | *'''Completely safe''': Entitlements any developer can opt into, with little to no risk. | ||
*'''Approval required''': Entitlements that might be more of a security risk to allow, e.g. giving considerably wider access to the system, or that Apple simply doesn't want to hand out to just ''anyone'' for competitive reasons. The developer must submit a request to Apple with evidence of why they need the entitlement. | *'''Approval required''': Entitlements that might be more of a security risk to allow, e.g. giving considerably wider access to the system, or that Apple simply doesn't want to hand out to just ''anyone'' for competitive reasons. The developer must submit a request to Apple with evidence of why they need the entitlement. | ||
*'''Private''': Entitlements that are never allowed for any app developer to use. Many of these are reasonably fenced off because they handle user data that is very risky, or bypasses permission prompts | *'''Private''': Entitlements that are never allowed for any app developer to use. Many of these are reasonably fenced off because they handle user data that is very risky, or bypasses permission prompts and so on, but can just as well also be guarding features Apple wants to keep to itself. | ||
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. | 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 | On iOS, you also can't be ''more'' secure than the default, strictest sandbox. 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 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. For example, it would be a nightmare if you can tap the wrong link in Safari and have a hacker easily steal your cookies from other websites. 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. For example, it would be a nightmare if you can tap the wrong link in Safari and have a hacker easily steal your cookies from other websites. If that third-party code could run in its own limited sandbox, the risk is significantly reduced. |