Apple Disputes Browser Speed Findings, Says Mobile Safari's the True Contender

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.'"

Comments

Chrome

[webmistressrachel]

1st post, so Chrome must be fastest...

Oh hell.

[revscat]

This is turning into a Big Deal, isn't it?

So, Mobile Safari proper uses Nitro and has seen some good performance improvements. For reasons unknown, these changes didn't make it into apps that use UIWebView.

You don't have to be Nostradamus to see what debate that "reasons unknown" part is going to cause.

1) Apple is evil and trying to cripple web performance so that people buy apps
2) It's a bug and/or simply didn't make into iOS 4.3 because it wasn't prioritized.

Re:Oh hell.

[Drakino]

Once iOS gains WebKit 2, this issue should go away. Development activity is pretty rapid right now, so there may be a big push to have this done for iOS 5. A story on Ars indicates bugs about web apps not using the new Nitro engine were closed with "not to be fixed by exec order". Based on that, I'm guessing the following occurred:

Apple execs wanted web browsing to be faster on iOS, by taking advantage of the same tech that is being used to accelerate browsers on the desktop. They also wanted to maintain the secure environment in iOS, and bring more security to the OS X side. WebKit 2 had been in development internally for a little while, and was opened up to the public for contributions in April 2010. Google, and others have been making major contributions to it, and development is proceeding.

Apple also had plans to release the iPad 2, along with an eventual iPhone 5 and new iPod Touch featuring dual core processors. iOS 5 is too far out, so iOS 4.3 had a lot of development effort spent on making MobileSafari faster. Because WebKit 2 wasn't ready, security wasn't ready to open it up to the world, and the decision was made to do what they could in the time frame allowed, and make it open to other developers later.

The "not to be fixed by exec order" is likely in place to prevent engineers from wasting time on trying to bring new improvements to old frameworks, and instead keeping engineers focused on finishing iOS 5, possibly with WebKit 2 in time for the iPhone 5 release this summer.

Apple is a hardware company (as far as where the majority of their profits come from), and so software development relating to iOS will always be driven by hardware release cycles. They may slip features from software, but key pieces have to be in place to meet the hardware cycle. It's looking like March will be new iPad time, June for iPhones, then September for iPods. iPads will debut new CPUs, iPhones will debut new major iOS releases and some other features (gyroscope, possibly NFC, etc), and iPods will just be a phoneless iPhone. Each release comes with a new iOS, iPad being a final point release of the previous iOS, iPhone being the new one, then iPods gaining the first point release of the new OS.

Re:Oh hell.

[MBCook]

John Gruber had a good analysis 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).

Re:Oh hell.

[alostpacket]

You don't have to be Nostradamus to see what debate that "reasons unknown" part is going to cause.

Yeah but if you were Nostradamus, the predictions would be much more fun.

Quatrain XI: The searching metal man roze to fell the mighty apple. Chrome, Fire, and Foxes all rejoiced at the silence atop the buffering hills.

Re:Oh hell.

[Hope Thelps]

That's the executive order, that they won't reduce the security (my speculation/interpretation).

That doesn't appear to make any sense.

Normally you'd expect it to be the exact same code running the embedded web apps as running the browser apps, just no chrome. i.e. you'd expect it to be Apple's code running, with whatever security Apple has written into it.

How does not displaying the chrome give rise to a security risk? If there's a security vulnerability from running your javascript using Apple's engine then that risk is identical with or without the chrome - isn't it?

Real reason

[Anonymous Coward]

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.

Re:Real reason

[bongey]

4.3 has address space randomization , which is why the pwn2own exploit doesn't work any more.

Not Reasons Unknown!

[VirginMary]

It has been covered that the reason is that Nitro compiles ECMAScript down to ARM machine instructions and then sets the memory region that contains the compiled code to be executable. This is a dangerous ability for arbitrary apps to have and that's why right now only Safari on iOS 4.3 has this capability. No stupid conspiracy theories are needed here. And it's not a bug either.

Re:Not Reasons Unknown!

[Anonymous Coward]

So what you're saying is that Mobile Safari does something dangerous and exploitable, and that it's not a bug, it's a feature?

Just want to make sure we're on the same page here.

Re:Not Reasons Unknown!

[MoonBuggy]

Presumably Apple is happy that, being the people who wrote the entire OS in the first place, they can implement this behaviour securely in Safari. They don't have the same faith in giving that ability to any random app developer, who could end up creating a difficult to spot vulnerability via the API either by malice or ignorance.

Re:Not Reasons Unknown!

[Nightlight3]

Native apps (including those running UIWebView) already use native ARM machine instructions as they wish (you can set compiler to to compile into pure native ARM instructions or write ARM assembly code if you want; Apple only controls which system APIs developers can access, which they can do from JS->machine compiled code equally well). So that "explanation" doesn't make much sense. It is more likely that they merely rushed the iOS upgrade out before their programmers had finished the porting to UIWebView.

Re:Not Reasons Unknown!

[SiMac]

The problem is not using ARM instructions. The problem is where those ARM instructions are. The iPhone presumably uses something like the NX bit 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:Not Reasons Unknown!

[SiMac]

Wow. That doesn't sound safe. First thought was guess the 5 sec Apple pown to ownage will be even quicker with this?

Seriously, anybody have any comments on the safety of this / what prevents a small bug in Safari from easily becoming arbitrary code execution?

Or even the possibility that some special javascript doesn't even need a Safar bug, just this feature to do evil stuff on the device?

JavaScript gets compiled to ARM instructions, and those ARM instructions get executed. You can't just put ARM instructions in a webpage and expect it to run. Barring a bug in the Nitro JIT, it's perfectly secure. Any JIT (including V8, JaegerMonkey/TraceMonkey, and the JVM), on any platform, necessarily has the same potential vulnerabilities. If the JIT is written properly and doesn't attempt to execute code in the parts of RAM that contain data from untrusted sources, it's not a problem. Most desktop platforms are much worse because they allow execution of code anywhere in RAM, in any application, regardless of its source. (Ever heard of a buffer overflow?)

Re:Not Reasons Unknown!

[SiMac]

No. Google's JIT is just as insecure. The problem is not in the implementation, it's that you need to disable the NX bit on an area of memory to run a JIT at all. There is no workaround to this, unless the JIT isn't actually a just in time compiler.

Re:Not Reasons Unknown!

[Random Destruction]

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:Not Reasons Unknown!

[tlhIngan]

The problem is not using ARM instructions. The problem is where those ARM instructions are. The iPhone presumably uses something like the NX bit 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.

I believe this to be the case. It may also explain why IOS 4.3 is 3GS and later, excluding the iPhone 3G. I believe the ARMv7 architecture introduces the NX bit into the platform, something that the ARM11 used in the original iPhone and iPhone 3G don't have. The 3GS uses a Cortex A8 and the iPhone 4 is a Cortex A8 derivative CPU, which means they have NX support. This would mean that no, IOS 4.3 will not run on the iPhone 3G.

The other thing is, IOS 4.3 probably also runs Safari in an even more locked down user account - there's root, and mobile (apps run under this user account). Safari may be set to run under an even stricter sandbox that's chroot and has no permissions anywhere else or even alter any files via standard permissions, a la nobody. Apps won't have access to that since there's probably little the account can actually do. This way the attack surface via Safari is minimal as the native code can't really run amok without finding a local root kernel exploit.

Re:Not Reasons Unknown!

[node 3]

It's part of the iOS security model. You're right that this model can be hacked. It's commonly referred to as 'jailbreaking'.

However, if the user never jailbreaks their iOS device, this security model remains in place. There's also always the potential for remotely exploitable flaws, but that's no different than any other network-capable OS. By confining the new javascript implementation to Safari, Apple is blocking local exploits.

Also, it's technically feasible that WebKit2 can allow third-party access to the new engine without compromising iOS's security model.

Universal benchmark

[countertrolling]

Farmville, right?

What do people want

[fermion]

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.

Re:What do people want

[farnsworth]

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".

Re:What do people want

[bigNuns]

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.

Re:What do people want

[farnsworth]

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/

Re:What do people want

[bigNuns]

Those are numbers based on a keynote speech and are full of assumptions. Pretty much each number comes with a "assumed" or "suggests." Anywhere you have seen real numbers and not ones made up based on somethine steve jobs said in a keynote? Not to be rude or anything but Steve Jobs has basically been caught on more than one occasion of, how should we say.... bending the truth.

Re:What do people want

[farnsworth]

Fair enough, but you can also read the transcript where Apple CFO Peter Oppenheimer tells shareholders pretty much the same exact thing. I guess he could be lying, but that would be a much more serious thing than telling tall tales at a press event.

Re:What do people want

[UnknowingFool]

Every time I hear someone grouse about how no one really knows about how much Apple makes on the App or Music store, I ask them if they ever read the quarterly earnings or attend the financial conference calls. They never do but they still insist that Apple must be making gads of profit even though they've never looked at the public data that Apple provides and tried to figure it out for them selves.

For instance for the fiscal year 2010, Apple reported $4.9B in revenue for the iTunes store. At most Apple took $1.5B in revenue for themselves after the artist/holder cut. Between January 2010 and February 2011, Apple sold over 4 billion songs. For arguments sake they only sold 3 billion for the fiscal year. That's 8.3 million songs a day. While not every song is a transaction, that's a lot of transactions. And that's just counting the music. There were probably thousands of movies a day. So for $1.5B a year, Apple had to pay for all the bandwidth, servers, credit card fees, etc and serve up 8 million songs a day and tens of thousands of movies. I would argue that Apple probably makes some profit but it isn't a lot.

Re:Safari is fast, it's UIWebView has no Nitro.

[larry bagina]

if "slow" means "the same speed as they were two weeks ago when we weren't complaining about how slow they are", then, yes, they run at the same speed they did two weeks ago when nobody was complaining how slow they were. If you have a 10 terrabyte porn collection, you don't lose porn just because your friend has a 15 terrabyte porn collection.

Re:Safari is fast, it's UIWebView has no Nitro.

[RyuuzakiTetsuya]

UIWebView is still pretty fast. 2 seconds versus 3 seconds is nothing to sneeze at. I'd still take it over say Trident, or whatever they based WP7's JS engine on.

I doubt that it's about not biting into app store revenue, app revenue just simply doesn't make up a huge portion of Apple's revenue. Getting hardware into people's hands is.

That's not the problem.

[pavon]

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.

Sour grapes from Blaze.io

[Bogtha]

This, claims testing firm Blaze.io, is news to the world.

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.

If you really want to know more, read this...

[DavidinAla]

John Gruber of Daring Fireball carefully lays out the situation in this post from a couple of days ago. I know that a lot of people like to make up all sorts of conspiracy theories and bizarre motives when it comes to Apple, but the truth is a lot more interesting and a lot less sinister: http://daringfireball.net/2011/03/nitro_ios_43

Re:If you really want to know more, read this...

[Alistair Hutton]

While Gruber may be right on this he is still the dick who concocted the widely quoted fantasy as to why cross compilers were definitely bad for iOs consumers and Jobs was so right to ban them give that Apple only do things that are good for the consumer blah, blah fucking blah.

He was suspiciously silent when Apple un-banned cross compiled apps. Which is a shame. I was desperate to know why cross compilers were suddenly good for consumers in a way that didn't reference the EU investigation on the issue that was teed-up to start the following week.

Re:No doubt related to the JS brouhaha

[icebraining]

No, ars is talking about the red herring of security, if it can run things of the net, it can run things from the local drive at least as safely

The difference isn't the origin, is the app running the code. They trust Safari to JIT and keep unknown code from the net contained, but not the any random app.

Re:Chrome is Fast Because It's Lightweight!

[Anonymous Coward]

http://xkcd.com/322/

Re:Mobile Safari's caching and asynchronous loadin

[omfgnosis]

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

What were those guys thinking?

[satuon]

I don't understand why they decided to compare the embedded browsers. "Ya, we'll go and compare Android and iPhone browser. But we won't compare the real browser, cause that would be too boring. Instead we'll compare the embedded browser, so if our assumption that it's the same turns out to be wrong, we'll become a laughing stock."

Seriously if I were doing this test, it would have never even occured to me NOT to use the real browsers in the first place.

Sensationalism and sloppy from the start

[YoopDaDum]

If you look at Blaze blog entry, you'll find this gem:

On average, Android 2.3 was a 52% faster than iPhone 4.3, with a median load time of 2.144 seconds vs. iPhone’s median load time of 3.254 seconds.

If it were relevant (which is not the case as it's supposed to compare web browsers), then the iPhone would be 52% slower than Android. Which is equivalent to say that Android would be ~34% faster then the iPhone, not 52% faster (for this, Android would need to complete in less than half the time of the iPhone). I guess that it's not politically correct to use the negative version (iPhone is slower), but then it's hard to resist using the higher number right? ;)
Interestingly, this has been reused by all news sites without anyone spotting the error. If Paulos makes a refresh of his "Innumeracy" book, I suggest this as an new example of how people lack fluency with basic computations.

I have neither iPhone nor Android phone (although I offered an iPhone to my wife, and would be more likely to buy an Android phone for me), and I don't care much about such differences. So I would consider myself quite neutral to this discussion. But it feels like the Blaze announcement was sensationalistic and a bit sloppy from the start. Anyway, it certainly worked in getting publicity, and that's probably all they cared for.

Re:Chrome is Fast Because It's Lightweight!

[webmistressrachel]

My last troll put paid to his "fat bitch troll". Look it up, there's pics and everything. But hey, he doesn't need to, I'm pretty damn sure he was there - the comment is almost verbatim!