What Nitro Engine Does
Nitro Engine’s newest improvement is just-in-time compilation which runs code as if it were an App on your iOS device. This allows iOS to delegate more resources to the Javsacript now turned Binary code to run much faster. However, this opens a number of security issues which Apple has been keen to avoid.
Why Some Web Apps Can’t Take Use The Nitro Engine
Third party Apps, despite them being approved, are not trusted by Apple to run code that could potentially compromise the OS when not handled correctly. The only App able to do this is Safari.app not Web Apps not directly accessed within Safari.app or run in another browsing layer. Allowing untrusted Apps to use the new Nitro Engine would fundamentally compromise the security of iOS and negate the security measures Apple has in place when it clears code safe to run on your iPad, iPhone or iPhone.
The Pitfalls Of Free Access
A JIT requires the ability to mark memory pages in RAM as executable, but, iOS, as a security measure, does not allow pages in memory to be marked as executable. This is a significant and serious security policy. Most modern operating systems do allow pages in memory to be marked as executable â€” including Mac OS X, Windows, and (I believe) Android1. iOS 4.3 makes an exception to this policy, but the exception is specifically limited to Mobile Safari.
Itâ€™s a trade-off. Most OSes allow marking memory pages as executable for performance reasons. iOS disallows it for security reasons. If you allow for pages of memory to be escalated from writable to executable (even if you require the page be made permanently read-only first), then you are enabling the execution of unsigned native code. It breaks the chain of trust. Allowing remote code to execute locally turns every locally exploitable security flaw into a remotely exploitable one.
In its simplest form, Apple is taking extra precautions to not compromise security over speed.