Apple Disputes Browser Speed Findings, Says Mobile Safari's the True Contender 155
An anonymous reader writes "Apple has hit back over claims that the browser shipped with its iPhone, iPod Touch, and iPad devices is significantly slower than Android's equivalent, calling the independent testing 'flawed.' 'They didn't actually test the Safari browser on the iPhone,' Apple's Kerris argues. 'Instead they only tested their own proprietary app, which uses an embedded Web viewer that doesn't actually take advantage of Safari's Web performance optimisations.' This, claims testing firm Blaze.io, is news to the world. 'Embedded browsers are expected to behave, for the most part, the same as the regular browser,' the company stated, defending its methodology. 'However, Apple is now stating that their embedded browser, called UIWebView, does not share the same optimisations MobileSafari does.'"
Real reason (Score:4, Informative)
If they allow apps to use UIWebView with Nitro they would need to allow all those apps to mmap(PROT_EXEC,) on pages, download code and stick on to the pages and execute it - bypassing Apple's control.
Now will come a multi process WebKit2 (a la Chrome) that will allow them to only give executable page permission to WebKit2 process and apps can just do IPC to it.
That's not the problem. (Score:5, Informative)
The problem isn't with the intentional ARM code written by the applications. It is with code injected into the application (via an exploitable bug, like a buffer overflow) by malicious software. Setting noexec on data pages and nowrite on code pages is a security feature that prevents a large class of remote exploits, by ensuring that only the original code is executed.
Compiling code on the fly should only be allowed on applications that have been carefully scrutinized for bugs, not every crappy app with an embedded web-browser. Even enabling it for Safari is risky, but is a lower attack surface than enabling it for any and all apps.
Re:Not Reasons Unknown! (Score:5, Informative)
The problem is not using ARM instructions. The problem is where those ARM instructions are. The iPhone presumably uses something like the NX bit [wikimedia.org] to segregate data from code. Because of the way a JIT works, it needs to be able to execute code in the data area of memory. Allowing every app to do this would effectively eliminate the additional security that the NX bit provides.
Re:Oh hell. (Score:5, Informative)
John Gruber had a good analysis [daringfireball.net] of all this. Basically, the embedded UIWebView didn't change in speed between 4.2 and 4.3, but Safari did. The fact that outside apps didn't speed up has been called "Apple slowing down" other apps.
The new JS engine (Nitro) uses JIT, which needs writable, executable pages in memory. In iOS 4.2 and before, this didn't exist because of security concerns. In 4.3, it exists, but only for MobileSafari. Because of this, UIWebView in other applications can't use JIT, which is where the performance gains came from.
So it's a security thing. Apple has decided to error on the side of security here. That's the executive order, that they won't reduce the security (my speculation/interpretation). Android isn't being as pedantic about it. Gruber suggest it could be possible (in a future update) to run the JIT in a separate process, so the main process doesn't need the wrire/execute pages to keep security. It's a good idea, it'd be nice if Apple did it. I'm not sure it matters that much.
So the problem with this comparison is that instead of MobileSafari, they used something using UIWebView, which doesn't have the permissions to do JIT. Thus it's an unfair comparison, in that users will see faster speeds than they are reporting (since users will use Safari, they have no choice).
Sour grapes from Blaze.io (Score:5, Informative)
No, it's not news to the world, it's news to Blaze.io. It was already widely reported that UIWebView didn't support the latest Safari speed boost days before their study was published [slashdot.org].
Re:What do people want (Score:5, Informative)
At first Apple wanted apps through safari. This might have been good as the Apps would work on any device, and Apple would have no lockin. But developers and users wanted native apps. So we have the App store, with lockin, and large cuts for Apple.
So what do we have now. Natives Apps that run in he browser. If lockin and Apple rules are such an issue, then why no run he app in a browser? Probably because most develpers like the lockin and he profit opportunities i provides. They my bitch about Apple, but they are not exacty running away.
If you look at the docs and the API that Apple provides for iOS, it's very clear that it was always their intention to provide a mechanism for native apps. Perhaps it was not ready when the first iPhone shipped, or perhaps there is some other reason. But it is not conceivable that the SDK/AppStore/etc was created in under a year due to developer demand.
We don't have "native apps that run in the browser". We have a Cocoa class called UIWebView which native apps can use to render html. There are all kinds of valid reasons for an app to do this. Sure, there are some apps that are *only* a UIWebView with static URLs, but they are the exception not the rule. And I'm pretty sure those are quick to be uninstalled. What we do have is the ability for a user to add a bookmark to their home screen, which basically creates an iOS app with an embedded UIWebView.
There are theories that the API, and therefore "URLs on the home screen", don't use the improved Nitro JS engine because it uses JIT, and would be susceptible to script poisoning attacks, since the App author has full access to the processes memory space. There are theories that Apple is putting this JITing out-of-process, which would mitigate or obviate these attacks. This seems to be the reason that apps that use UIWebView get the older, slower JS engine.
In any case, this has nothing to do with lockin, or profits for Apple. If you look at the actual numbers, you will see that the AppStore is a break-even affair for Apple. The only reason they have it is because customers want it, therefore it makes their hardware "more better".
If you really want to know more, read this... (Score:5, Informative)
Re:What do people want (Score:4, Informative)
If you look at the actual numbers, you will see that the AppStore is a break-even affair for Apple.
How does one go about doing this? Everything I have read has been speculation. As far as I can tell, no numbers have actually been released.
http://tech.fortune.cnn.com/2010/06/23/app-store-1-of-apples-gross-profit/ [cnn.com]
Re:What do people want (Score:4, Informative)
Re:Not Reasons Unknown! (Score:4, Informative)
So surfing the net can open iOS to exploits?
That wouldn't be anything new. I jailbroke my iphone4 by going to a website.
Re:Mobile Safari's caching and asynchronous loadin (Score:4, Informative)
No, there's more to it than that. UIWebView cannot compile arbitrary code, but Safari's JavaScriptCore (Nitro nee "Squirrelfish Extreme") does. http://arstechnica.com/apple/news/2011/03/confirmed-some-web-apps-not-seeing-ios-43-javascript-speedup.ars [arstechnica.com]