Apple App Store: Difference between revisions

Emayeah (talk | contribs)
m Flatpak just makes code distribution easier by bundling dependencies. Docker is a better example of sandboxing.
Emayeah (talk | contribs)
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. JIT also employs many more optimization techniques meant to improve performance, but all you need to know is that JIT is much faster than an interpreter.
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==
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:Docker_(software)|Docker]] 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 apps abusing user data before the current permission system was built out.<ref>{{Cite web |last=Bohn |first=Dleter |date=15 Feb 2012 |title=iOS apps and the address book: who has your data, and how they’re getting it |url=https://www.theverge.com/2012/2/14/2798008/ios-apps-and-the-address-book-what-you-need-to-know |url-status=live |access-date=16 Mar 2025 |website=[[The Verge]]}}</ref>)
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.


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:
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, etc, but can just as well also be guarding features Apple wants to keep to itself.
*'''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. 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.
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.