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.
