Why Web Apps Aren’t Fast In iOS 4.3: Security

One of the most anticipated features in iOS 4.3 is Safari’s new Nitro JavaScript engine which gives web Apps massive performance gains. However, some criticized Apple for delegating which Apps can access the faster engine and are blaming the decision on a marketing ploy to drive App Store sales. This couldn’t be farther from the truth.

What Nitro Engine Does

The Nitro Engine is what iOS uses to decode Javascript and make it run on your iPhone, iPod or iPad. In a nutshell, Javscript code is translated then ran and the browser runs the interpreted code in a series of actions. As such, it plays a crucial role in the interaction a user has with a website and any speed improvements made to the engine are welcomed.

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

Following the iOS 4.3 update many cried foul that Web Apps saved to the Home screen saw a speed decrease and was a marketing ploy by Apple to drive developers to the App Store. This couldn’t be farther from the truth. Due to the security issues of running just-in-time compilation, Apple only allows Safari to access the new Nitro Engine. Web Apps on the Home Screen (Web Clips) and sites accessed from in-App browser (UIWebView) are not trusted by iOS to use Nitro Engine’s new Javascript 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

What’s so wrong about any Web App using just-in-time compilation to run? Apple changes how Javascript code is interpreted in Safari and trusts it to run as executable code – a privilege reserved for App Store and native iOS Apps only. John Gruber of Daring Fireball sums up the security issue best:

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.

About Tanner Godarzi

Tanner is tech-savvy with an eye for great content who is pursuing his Bachelors of Science in Web Design and Interactive Media from the Art Institute of California—Orange County. Tanner has been a freelance Blogger and Social Media consultant for over 4 years and contributed content for O'Reilly's "Big Book Of Apple Hacks." Tanner has blogged for industry notables such as Hadley Stern for Apple Matters, C.K. for Obsessable and gave insight about Social Media for The Blog Herald. Tanner resides in Huntington Beach and is a cycling enthusiast.

Comments

  1. It’s a wonderful theory. Pity it doesn’t hold water.

    Consider this: From a security standpoint, if there’s a hole where eeevil code can be run, it will be run there. Arguably, what’s worse is that Apple has made it more inviting to run that eeevil code by making it faster.

    So why is Safari allowed to do this? Does Safari have some magical way of preventing this eeevil code from running? Nope. So there’s a potential security hole.

    No, I don’t think that third-party Apps not being able to use the new engine is some kind of conspiracy. I think it’s more likely the case that Apple implemented this in Safari and hasn’t gotten around to figuring out how to move it out of Safari and into WebKit (so that other applications can use it) and how to automatically enable third-party Apps that use WebKit to mark pages as executable while still making sure Apps that don’t use WebKit are non-writable.

    But the whole concept that Apple is being security-minded by only allowing Safari to do this and not other Apps just doesn’t hold any water.

Speak Your Mind

*