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

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!

[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!

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

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

[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: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:Chrome is Fast Because It's Lightweight!

[Anonymous Coward]

http://xkcd.com/322/

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.