OSNews: http://www.osnews.com/story/24542/Teacup_Meet_Storm_pt_V_iOS_4_3_and_Web_App_Performance Exploring the Future of Computing en-us Copyright 2001-2013, David Adams adam+nospam@osnews.com Tue, 21 May 2013 13:15:20 GMT http://www.osnews.com/images/osnews.gif OSNews.com http://www.osnews.com Comment by kaiwai http://www.osnews.com/thread?466845 http://www.osnews.com/thread?466845 What?! The Register talking out of their ass - wow, that's gotta be a first *rolls eyes*

Come on, really, the number of people citing The Register article as some sort of 'final say' when it comes to all things related to IT makes me cringe. The Register is little more than a glorified set of Slashdot posts being paraded as articles with the comments section being no better than clicking onto a Glenn Beck/O'Reilly fan forum (if such an entity exists).

The forum itself is a massive echo-chamber where the moderators only allow the views they agree with being approved before being posted. I've signed up and posted a couple of replies (in the comments section) pointing out where the article writers were incorrect (in a polite way) and found that my comments are never accepted - god forbid someone actually writing a constructive critique of where the article went wrong!Edited 2011-03-18 23:50 UTC Fri, 18 Mar 2011 23:49:00 GMT donotreply@osnews.com (kaiwai) Comments Comment by Kroc http://www.osnews.com/thread?466867 http://www.osnews.com/thread?466867 When Mozilla created first TraceMonkey, and then JaegerMonkey, they had to disable it for the JavaScript used in Firefox's chrome because that load of code was not programmed with JIT in mind since it used a wider set of APIs than vanilla JS and communicated with XPCOM components and C-interfaces. Firefox 4 now ships with it all switched on.

I see this as similar for the Apple situation. Running web code is one thing, but JavaScript used in WebUIViews in third party apps could be doing anything beyond the scope of typical JavaScript. What's more since JIT allows for a form of memory (of sorts), this could be used as a new, effective form of jailbreaking. Just add a web-page to your home screen and then run it -- the context changes because the code is no longer running inside Safari, but as its own app outside Safari.

We'll just have to wait and see what the next update from Apple does. Sat, 19 Mar 2011 08:33:00 GMT donotreply@osnews.com (Kroc) Comments RE: Comment by Kroc http://www.osnews.com/thread?466882 http://www.osnews.com/thread?466882
Running web code is one thing, but JavaScript used in WebUIViews in third party apps could be doing anything beyond the scope of typical JavaScript.


I've just been writing what's essentially an HTML5/JS/CSS3 app that runs inside a UIWebView on the iPad. The JS environment that you get inside UIWebView is essentially identical to what you will find inside MobileSafari. It cannot inherently do anything "beyond the scope of typical JavaScript".

There are two things available to help interaction between the UIWebView/JavaScript and native/ObjC environments:
* UIWebView provides stringByEvaluatingJavaScriptFromString, allowing native code to interact with the JS environment.
* UIWebViewDelegate provides shouldStartLoadWithRequest which allows URL requests to be intercepted by your ObjC code, allowing JS to trigger native actions.

This division ensures that the JS code can't do anything native directly. So technically the JS code doesn't do anything beyond the scope of typical JS, and thus this isn't quite the same situation as Firefox had.

As has been identified, the real problem Apple has is the security model of iOS. Processes can't arbitrarily mark code pages as being executable but as the JIT in Nitro requires this an exception is made for MobileSafari. Allowing any app using UIWebView to do this would allow them to download arbitrary binaries over the 'net and executed - a serious breach of the current security model.

WebKit2 allows for a Nitro JIT-enabled process, with arbitrary code execution enabled, to run alongside a regular app process running with the existing security restrictions. The UIWebView API can stay the same as it is right now, so existing apps would continue to work just fine. Sat, 19 Mar 2011 12:24:00 GMT donotreply@osnews.com (steve_s) Comments Comment by some1 http://www.osnews.com/thread?466912 http://www.osnews.com/thread?466912 > iOS, however, does not allow memory pages to be marked as executable.

If that was the case, it won't be able to execute any code. iOS doesn't allow making *writeable* pages executable.

> UIWebView they did not make this exception. It would defeat the purpose of the App Store review process.

How so? The only C code that runs there is Apple's C code. You can run the very same app from Safari with JIT.

The reason probably is that exception for Safari is a quick hack, and Apple didn't want to do this for anything else. Sat, 19 Mar 2011 16:14:00 GMT donotreply@osnews.com (some1) Comments RE: Comment by kaiwai http://www.osnews.com/thread?466951 http://www.osnews.com/thread?466951 The article, as it stands now anyway, is accurate. It has a typically sensationalist bent, but the facts given match the osnews article. Sat, 19 Mar 2011 23:56:00 GMT donotreply@osnews.com (stestagg) Comments RE: Comment by kaiwai http://www.osnews.com/thread?466973 http://www.osnews.com/thread?466973
What?! The Register talking out of their ass - wow, that's gotta be a first *rolls eyes*


LOL, I haven't read that site in years for this very reason. Sad to see they apparently haven't changed at all. Sun, 20 Mar 2011 07:27:00 GMT donotreply@osnews.com (WorknMan) Comments