With every thing he writes like this, he's behaving more like a fanboy and less like a reliable source of information. It's a bit sad.
With every thing he writes like this, he's behaving more like a fanboy and less like a reliable source of information. It's a bit sad.
'"Ah, that is different!" said Boxer. "If Comrade Napoleon says it, it must be right."'
If the new JS engine is a security problem either fix it or remove it. Compromise helps no one.
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.
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).
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.
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.
Thanks for weighing in, sir – this was just the expert opinion I was hoping to see.
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)
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).
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.
Perhaps his best work was when he distilled the ecosystem down into a fantastic stream of links, a brilliant and hard-working focused aggregator/editor.
Bit more of a bloviating opinion columnist now-a-days. And I guess his biases are brought to the front more.
Understandable though. Everyone is converging on his range of primary sources and editorially crowd-sourcing it in realtime.
I'll still be frequenting his site. It's still quality. You just read with a bias-aware filter like you do any other news source.