[buymorechuck]

I suspect the reason is due to security concerns about running JIT executable code in 3rd-party apps. I have a harder time understanding full-screen web apps, however. Those should be running within some kind of full-screen Mobile Safari mode.

[happybuy]

Yes I believe when the SquirrelFish (now Nitro) JS engine was initially announced that it relied on allowing certain items in memory to become executable (most likely due to the JS interpretation and then execution) - and that due to the security model in iOS and the ARM processors this was not allowed.

In general I believe its good to not allow random bits of memory to become executable as it can easily introduce a large number of security and memory overflow vulnerabilities.

Perhaps as part of iOS 4.3, Apple has allowed Safari to circumvent this restriction but not any other application. Which would make sense because they control and are responsible for Safari, but to allow any application to circumvent this restriction could open iOS up to large security issues.

[blinkingled]

>Perhaps as part of iOS 4.3, Apple has allowed Safari to circumvent this restriction but not any other application.

Given Safari is the biggest attack surface and regularly falls prey to exploits they should also disable the JIT for Safari. (Most iOS exploits like the Pwn2Own ones, and jailbreakme.com ones are due to bugs in Safari.)

[czhiddy]

IIRC, the jailbreakme.com exploit relied on a flaw in libtiff.

[blinkingled]

Entry point was Safari though.

[russell_h]

I think this is the answer.

A JIT works by compiling some chunk of code into a section of executable memory, then jumping to that location. As I understand it, iOS hasn't previously allowed execution of code from "data memory" (various people were curious about this very thing when it was announced they were shipping a JIT). Presumably, the Safari process has some special flag that allows it to write to executable memory, but most other processes do not. My guess is that someone forgot to add this flag to whatever application handles "full screen" pages, although maybe there is a legitimate reason for this.

Edit:

An example of the curiosity I mentioned: http://twitter.com/mraleph/status/43030240175468544

[justincormack]

Probably time for Apple to start using the process sandboxing from Chromium in Safari. If you are running a jit you need to make data executable so it isnt going away. As Apple control the OS they should be able to design a good Javascript sandbox.

[rsfinn]

Actually, it looks like Apple's approach is WebKit2 <http://trac.webkit.org/wiki/WebKit2>, which will handle the UI/web process separation itself, allowing any client application to benefit (as opposed to Chromium's current approach).

Perhaps you just meant the UI/web process separation itself, but it's interesting to note that Apple is going for a more general-purpose solution.

[smcj]

When did apple start caring about security?

[dunham]

It's possible that only MobileSafari.app is signed with the entitlements needed to do JIT (write to executable memory segments?). The full-screen web apps open as separate applications and might not look like MobileSafari to the OS.

[comex]

Exactly-- only MobileSafari has the "dynamic-codesigning" entitlement, but full-screen web apps open in WebSheet.app. This is almost certainly an oversight. On the other hand, I doubt App Store apps will get that entitlement anytime soon.

[statictype]

Can't be security. From what I understood Web apps work in the browser but when bookmarked as home-screen icons, they don't use the new js engine (even though it's still running in Safari)

Benign explanation: some bug in safari

Tin foil hat explanation: Apple doesn't want web apps to be as good as native apps. This explanation kind of falls apart when you ask why they would bother boosting the js engine at all.