4 ms·

You're mixing up executing JavaScript generally vs JavaScript with a JIT. Apple has specifically banned Just-in-Time (JIT) compilation, where JavaScript (or any

by varenc 3y ago

You're mixing up executing JavaScript generally vs JavaScript with a JIT. Apple has specifically banned Just-in-Time (JIT) compilation, where JavaScript (or anything) is translated into machine code, marked for execution, and ran directly on the processor. There are real security reasons for forbidding this[0]. All modern browsers use JIT compilation for JS since this is crucial for good performance. But a JIT isn't a requirement for running JS, it just makes things faster. You can run JavaScript without a JIT no problem, but there is a separate Apple ban on alternative browser engines. Ostensibly browsers are banned because without a JIT they'd very slow and lead to a bad user experience, though I'm doubtful this is the only reason. (You can try Safari with the JIT disabled by turning on Lockdown Mode) But there's nothing forbidden about interpreting code, as long as you don't generate machine code and try to mark pages of memory for execution. Practically this means scripting languages and nothing that's compiled or interpreted with a JIT. For example: with iSH, available on the app store, you can get a full virtual Linux environment and write all the JavaScript (via Node) or Python code you want: https://apps.apple.com/us/app/ish-shell/id1436902243 https://apps.apple.com/us/app/ish-shell/id1436902243 [0] I wrote another comment recently re: Apple/JIT and mention some of the security reasoning behind this, though I'm no expert: https://news.ycombinator.com/item?id=35695431 https://news.ycombinator.com/item?id=35695431

saagarjha 3y ago
There's not much of a security argument for forbidding a JIT.
- varenc 3y ago
  Interesting! I had assumed that if you could mark pages of memory as executable (for a JIT), that an app could use that to call all sorts of security/privacy sensitive private APIs they're usually forbidden from using. But maybe not? Or is iOS sandboxing just good enough it doesn't matter? (but at the minimum, it does still seem to nullify the app store review process if apps can introduce arbitrary new behavior/code after review)
  - saagarjha 3y ago
    You can do that anyways (i.e. by obfuscating the call so that review doesn’t find it). The sandbox (+entitlements) is supposed the be the actual security boundary here. A JIT makes bypassing review easy which is why they don’t like it but bypassing review is pretty easy already just by writing your code in JavaScript and downloading it from the internet so there’s not much technical merit to the policy.
rektide 3y ago
Long post. What you're saying may have some good to know particulars that I didn't get right. But the net is: the only performant way to run JS or any other non-pre-compiled (jit) language is banned. And there's separate bans altogether on browser engines even if running like dogs it were tempting. Because Apple sucks & is mean & a shit. These are both horseshit fuckery excuses. Cast these wads into the pit. It's all fuckery, & there's so many other security defense layers. These prohibitions are bad spirited jerks being bad and jerks.
- varenc 3y ago
  Hah sorry for the wall of text. Totally agree the real reason Apple bans browsers is not motivated by security, and them pointing at the JIT/performance is just the one plausible excuse. But besides alternative browsers, IMHO this ban does have valid security/privacy/anti-scam reasoning. If apps could mark pages of memory as executable, they could introduce arbitrary new behavior whenever they want. Though it sounds like iOS security is good enough that even than an app can't break out of its sandbox. But even with the sandbox, there's no point in the App Store review process if apps can completely change their code/behavior whenever. This dovetails into an App Store debate, but I think there is value in the idea of a review process. I'm sure there'd be way more predatory and malicious scam apps out there taking advantage of the tech-illiterate without app reviews. (Though I'm not saying Apple always does reviews right, or that they shouldn't allow app side-loading with less stringent requirements). Whoops wrote another wall of text.

by varenc 3y ago

saagarjha 3y ago

There's not much of a security argument for forbidding a JIT.

varenc 3y ago
Interesting! I had assumed that if you could mark pages of memory as executable (for a JIT), that an app could use that to call all sorts of security/privacy sensitive private APIs they're usually forbidden from using. But maybe not? Or is iOS sandboxing just good enough it doesn't matter? (but at the minimum, it does still seem to nullify the app store review process if apps can introduce arbitrary new behavior/code after review)
- saagarjha 3y ago
  You can do that anyways (i.e. by obfuscating the call so that review doesn’t find it). The sandbox (+entitlements) is supposed the be the actual security boundary here. A JIT makes bypassing review easy which is why they don’t like it but bypassing review is pretty easy already just by writing your code in JavaScript and downloading it from the internet so there’s not much technical merit to the policy.

rektide 3y ago

Long post. What you're saying may have some good to know particulars that I didn't get right. But the net is: the only performant way to run JS or any other non-pre-compiled (jit) language is banned. And there's separate bans altogether on browser engines even if running like dogs it were tempting. Because Apple sucks & is mean & a shit. These are both horseshit fuckery excuses. Cast these wads into the pit. It's all fuckery, & there's so many other security defense layers. These prohibitions are bad spirited jerks being bad and jerks.

varenc 3y ago
Hah sorry for the wall of text. Totally agree the real reason Apple bans browsers is not motivated by security, and them pointing at the JIT/performance is just the one plausible excuse. But besides alternative browsers, IMHO this ban does have valid security/privacy/anti-scam reasoning. If apps could mark pages of memory as executable, they could introduce arbitrary new behavior whenever they want. Though it sounds like iOS security is good enough that even than an app can't break out of its sandbox. But even with the sandbox, there's no point in the App Store review process if apps can completely change their code/behavior whenever. This dovetails into an App Store debate, but I think there is value in the idea of a review process. I'm sure there'd be way more predatory and malicious scam apps out there taking advantage of the tech-illiterate without app reviews. (Though I'm not saying Apple always does reviews right, or that they shouldn't allow app side-loading with less stringent requirements). Whoops wrote another wall of text.