His reasoning seems shaky to me. Assuming this new JS engine is a security risk (it's not really, but lets pretend) you're not protecting anyone by making it Safari-only. It'd be like leaving all your ground-floor windows wide open, whilst locking your front and back doors in hopes that it will discourage burglars.
If the new JS engine is a security problem either fix it or remove it. Compromise helps no one.
Apple can't turn on the ability to do executable, dynamically written to memory pages just for their library: they'd have to turn it on for the entire process, at which point you could also do crazy things like download native code and execute it, bypassing the entire concept of their "codesign" mechanism.
The application that is downloading and executing code would itself have to be signed, so this doesn't get around the App Store approval process: the bootstrap app could be loaded by anyone with a developer certificate, but then they can just sign anything they want that runs as a normal process.
The effects this would have are in:
a) security (although codesign is a fundamentally flawed system due to return-oriented programming techniques and is frankly just security theatre at this point)
b) meta-store fronts (Apple would have to be much more careful about approving applications that downloaded other applications at runtime; Apple could revoke these, though, and you can already do stuff like this with interpreters, although you might not want to bother)
and, I'd say most importantly, c) JITs (suddenly there would be no technical obstacles to having good versions of Java, Mono, or even Flash; and given that the contractual obligations they added got so much pushback that they were removed, we /would/ see good versions of Java, Mono, and even Flash)
Yes. In order for all of the existing mechanisms for managing things that look like apps to work in reasonably logical ways (launching the app, switching between apps, resource managing the app while it is in the background, isolating faults from the app, etc.), home screen web applications are each represented by Web.app.
On a similar note, in order for similarly interesting behaviors to work with iAd (home button acting as "close", address space isolation to keep your process from messing with the ad, etc.), there is an application that backs them called WebSheet.app that also causes these to be in separate processes.
Of course, this means that there is no real good reason why Apple has disabled Nitro for full-screen web applications (that I at least yet understand), and so I'd expect that this was frankly just a silly oversight (and I may know more about what reasoning went into this when I get around to pulling apart how Apple grants MobileSafari this privilege).
It's not the JavaScript engine that's the security risk, it's that in order to run the new JS engine, the app running it has to be able to execute code from writable memory. This is where the security risk lies, and it has always been forbidden, for all apps. Safari can get an exception, since Apple obviously trusts its own code not to be malicious. But 3rd party apps still won't be allowed to execute arbitrary code from memory, so any apps embedding a UIWebView to present a browser can't get the performance improvements of the new engine.
The only real question is why Apple's own app that's used to display those saved-to-home-screen webapps didn't get an exception alongside Safari. My guess is that the Nitro engine is built directly into Safari and that the UIWebView control (which is used by webapp viewer app) simply can't use it at all, regardless of ability to execute writable code. I'm sure this will change, either the viewer app will get rewritten, or UIWebView will get its own sandbox etc. They probably just didn't have the time to do that yet.
It's not the JS engine that's the security problem. It's that the JS engine requires allowing apps to mark pages as executable. Executable pages opens up a whole another vector of attacks that have nothing to do with dangerous JS apps.
That doesn't make any sense. It requires allowing the JIT to mark pages as executable. But that's exactly the same as the browser. There should not be any new security vector exposed that's not already there from the browser.
The new vector is that, in Safari's case, Apple audited the code that calls the JIT.
If UIWebView could JIT, somebody would write an app that dumps the JITs code (I assume that ARM does not have the ability to mark pages as 'executable, but not readable') and run it on a development system. From there, (s)he would figure out what the JIT does to make data executable. That knowledge could be used in an app that can execute code that Apple hasn't seen.
Of course, that app would need to pass the app store approval process to be useful, but that should not be hard.
A way around this is to move the JIT to the kernel or to a different process. I would guess that that would hinder performance so much that, in typical usage, JIT-ting becomes too expensive to speed up things. Alternatively, Apple could not have spent the time to do so (yet).
A way around this is to move the JIT to the kernel or to a different process. I would guess that that would hinder performance so much that, in typical usage, JIT-ting becomes too expensive to speed up things
Having the hosted browser in a different process shouldn't be too expensive. That's what Chrome and IE do. When you open up a UIWebView and process gets spun up that hosts the JIT (amongst the other plubming for the browser) and the host just has a window where the rendering takes place. This also fixes a whole host of other security problems hosting a browser in process.
Chrome and IE run on systems with faster processors and Gigabytes of RAM. RAM, especially is tight on iOS devices.
I also guess that some iOS apps will want to overlay stuff on their web views, postprocess the data, register callbacks, etc. Supporting such use might be a bit of work that Apple hasn't done yet.
But aren't they within the same process? (I'm asking an honest question - I know nothing of iOS internals).
Doesn't that imply that the JIT has privileged access to pages that other code within the same process does not? As saurik (who knows about these things) mentions elsewhere, Apple can trust Safari to not tamper with the executable pages - can they trust 3rd party apps?
Home-screen based web-apps being another question entirely.
They might be in the same process. I guess they don't do process isolation for hosted browser controls? If not, they should. Otherwise the app stack is always at risk of running arbitrary javascript in process.
I'm not sure which I'd rather see - Gruber being proved wrong (again), or a whole class of new remote "visit this site to jailbreak your iPhone" exploits...
If the new JS engine is a security problem either fix it or remove it. Compromise helps no one.