4 ms·
All processes (at least, ones in the App Store) are already sandboxed, as are Safari and Web.app (although the latter two are sandboxed more heavily than ones f
by Xuzz 15y ago
All processes (at least, ones in the App Store) are already sandboxed, as are Safari and Web.app (although the latter two are sandboxed more heavily than ones from the App Store, since Apple knows exactly what things they might want to access). However, since Nitro is run in-process (as is WebKit as a whole), it can't be too sandboxed, or the app that's using it wouldn't be able to do a lot of the things that a native app can do.
It's a tradeoff between functionality and security with the sandboxes, and right now (for native third party apps) Apple has gone with functionality (address book access, camera access, etc).
- stephth 15y agoInteresting, thank you. So what would be the security implications of allowing Nitro to create code dynamically within a sandboxed process? AFAIK, only compiled code (ObjC,C,C++) can call private APIs, and the app review process guards against that; so what could a Nitro process do that compiled code couldn't?
- sdkmvx 15y agoAny (machine) code can call private APIs, so it's simply a matter of getting/hacking Nitro to generate the correct machine code to do it. I think that's what they would worry about. Remember Jailbreakme.com? It was PDF (and kernel, so no sandbox could have helped) I believe, but a real problem to consider if you can get custom code running.
- jchrisa 15y agothe gist is that in a 3rd party compiled app, they wouldn't be able to tell if it was nitro turning data into code, or some part of your app recompiling itself. they don't like your app recompiling itself, they want updates to come through the app store ecosystem.