5 ms·

But its absolutely not true that this is enforced consistently. My iPhone currently contains three full programming language interpreters from the App Store---

But its absolutely not true that this is enforced consistently. My iPhone currently contains three full programming language interpreters from the App Store---one for JavaScript, one for Python, and one for Clojurescript. I know one of those can make arbitrary network requests because I've done it, and I think the other two can as well. So how is that different from iSH? Apple has approved a bunch of apps that can go get third party code and run it.

fiddlerwoaroof 6y ago
I think JavaScript/Clojurescript is the exception because they control the runtime and JIT: whether or not you buy their explanation, I think the reason they state is that this is to enable sandboxing. This is at least plausible to me: to have effective sandboxing, you need to restrict the APIs that a device can call, which means blocking the ability to generate and run arbitrary machine code on-device.
- josephcsible 6y ago
  > This is at least plausible to me: to have effective sandboxing, you need to restrict the APIs that a device can call, which means blocking the ability to generate and run arbitrary machine code on-device. This isn't true. You can sandbox arbitrary machine code by restricting the process it runs in (this is how seccomp works on Linux).
- roblabla 6y ago
  > to have effective sandboxing, you need to restrict the APIs that a device can call, which means blocking the ability to generate and run arbitrary machine code on-device. Please, no, this is not how security and sandboxing works at all. Otherwise, the moment you have an arbitrary code vulnerability, you'd get full access to everything. The way effective sandboxing works is by giving a process a set of capabilities/permissions, what have you, that is enforced by the kernel. Those permissions can be "can I open files", "can I talk to the camera subsystem", etc. Then, even if you somehow manage to generate the right function call at runtime, the call will fail. And to be clear, this is how apple's own security works.
  - fiddlerwoaroof 6y ago
    Wouldn’t you have this as part of a defense in depth strategy? Apple’s public vs. private APIs and similar things seem to indicate that at least part of their security model involves static analysis of binaries and only allowing a set of approved APIs.
    - saagarjha 6y ago
      Apple's static analysis to detect private API usage is not very clever; you can get around it with some fairly trivial tricks.
    - roblabla 6y ago
      No, it's not a security mechanism period. Public/Private APIs aren't part of the security model, it's a way to prevent app breakage in their ecosystem due to applications using unstable APIs.
- yoz-y 6y ago
  But iSH isn’t running arbitrary machine code, it’s a x86 emulator running Linux inside. It’s more sandboxed than a JS runtime, which actually does compile down to machine code.
musicale 6y ago
It really isn't. You can definitely download code into Scriptable and Pythonista, although I don't think they have package managers.
- enos_feedler 6y ago
  You've just said it. The difference is the package management. What Apple is defending here is the notion of a store around apps/containers. Apple does not want to provide leaks/wedges into other app ecosystems through native apps. Safari is the only way.
- saagarjha 6y ago
  Not out-of-the-box, but users have created scripts that bootstrap package managers into those apps similarly to how iSH users have.
interpol_p 6y ago
This is a wall I have hit with App Review quite a few times You have to stop viewing the apps from a technical perspective. App Review is _intentionally_ non-technical, as frustrating as that is for us developers. They enforce App Store policy from a non-technical standpoint I produce an app which can download and run code, and was rejected many times through App Review. I was able to point to many other apps which _technically_ also downloaded and ran code — but the difference, to App Review, was entirely in the appearance (my code was text based, it "looked like code" and not like Scratch's visual programming, or nodes, or whatever) I disagree with the App Review decision in this instance, but I think they are enforcing policy consistently. It just looks random to those of us with enough technical experience to look past the visuals and to the implementation
- saagarjha 6y ago
  We'd be happy to include your experiences when we talk to Apple about 2.5.2 if you'd like to share them with us. (I work on iSH, so you can either use the email on my profile or any of the other ways to contact the iSH team.)

fiddlerwoaroof 6y ago

I think JavaScript/Clojurescript is the exception because they control the runtime and JIT: whether or not you buy their explanation, I think the reason they state is that this is to enable sandboxing. This is at least plausible to me: to have effective sandboxing, you need to restrict the APIs that a device can call, which means blocking the ability to generate and run arbitrary machine code on-device.

josephcsible 6y ago
> This is at least plausible to me: to have effective sandboxing, you need to restrict the APIs that a device can call, which means blocking the ability to generate and run arbitrary machine code on-device. This isn't true. You can sandbox arbitrary machine code by restricting the process it runs in (this is how seccomp works on Linux).
roblabla 6y ago
> to have effective sandboxing, you need to restrict the APIs that a device can call, which means blocking the ability to generate and run arbitrary machine code on-device. Please, no, this is not how security and sandboxing works at all. Otherwise, the moment you have an arbitrary code vulnerability, you'd get full access to everything. The way effective sandboxing works is by giving a process a set of capabilities/permissions, what have you, that is enforced by the kernel. Those permissions can be "can I open files", "can I talk to the camera subsystem", etc. Then, even if you somehow manage to generate the right function call at runtime, the call will fail. And to be clear, this is how apple's own security works.
- fiddlerwoaroof 6y ago
  Wouldn’t you have this as part of a defense in depth strategy? Apple’s public vs. private APIs and similar things seem to indicate that at least part of their security model involves static analysis of binaries and only allowing a set of approved APIs.
  - saagarjha 6y ago
    Apple's static analysis to detect private API usage is not very clever; you can get around it with some fairly trivial tricks.
  - roblabla 6y ago
    No, it's not a security mechanism period. Public/Private APIs aren't part of the security model, it's a way to prevent app breakage in their ecosystem due to applications using unstable APIs.
yoz-y 6y ago
But iSH isn’t running arbitrary machine code, it’s a x86 emulator running Linux inside. It’s more sandboxed than a JS runtime, which actually does compile down to machine code.

musicale 6y ago

It really isn't. You can definitely download code into Scriptable and Pythonista, although I don't think they have package managers.

enos_feedler 6y ago
You've just said it. The difference is the package management. What Apple is defending here is the notion of a store around apps/containers. Apple does not want to provide leaks/wedges into other app ecosystems through native apps. Safari is the only way.
saagarjha 6y ago
Not out-of-the-box, but users have created scripts that bootstrap package managers into those apps similarly to how iSH users have.

interpol_p 6y ago

This is a wall I have hit with App Review quite a few times You have to stop viewing the apps from a technical perspective. App Review is _intentionally_ non-technical, as frustrating as that is for us developers. They enforce App Store policy from a non-technical standpoint I produce an app which can download and run code, and was rejected many times through App Review. I was able to point to many other apps which _technically_ also downloaded and ran code — but the difference, to App Review, was entirely in the appearance (my code was text based, it "looked like code" and not like Scratch's visual programming, or nodes, or whatever) I disagree with the App Review decision in this instance, but I think they are enforcing policy consistently. It just looks random to those of us with enough technical experience to look past the visuals and to the implementation

saagarjha 6y ago
We'd be happy to include your experiences when we talk to Apple about 2.5.2 if you'd like to share them with us. (I work on iSH, so you can either use the email on my profile or any of the other ways to contact the iSH team.)