Live data from Hacker News

Safari Vs Chrome iOS JavaScript Benchmark

pastebin.com

21–30 of 42 posts

Re: Safari Vs Chrome iOS JavaScript Benchmark

#21

Can someone explain how an application developer with access to webkit+Nitro could cause problems? Would the developer have to write a malicious app, or would a maliciously crafted webpage be able to exploit the OS?

iOS code signs all code that runs on the system. Compared to most other operating systems, this is a huge security win: without another exploit in that system, even a standard remote code execution vulnerability is useless. Nitro generates code at runtime, so it (by definition) needs to run unsigned code. With Safari, Apple can audit all the code necessary, but with third party apps, it would be easy for a developer to have their app exploited or even use the unsigned code ability to download new, possibly malicious code after the App Store review process.

Re: Safari Vs Chrome iOS JavaScript Benchmark

#22
post #16

What is the point of UIWebView, if it's meant to help developers write Javascript "native" apps, and yet it's 3x slower than a web app would be inside Mobile Safari? Doesn't that kind of defeat the purpose of UIWebView existing? I'm pretty sure Apple is leaving this as it is on purpose so Javascript apps don't start to compete on performance with ObjectiveC apps, and the security excuse they give is just the lazy one…

That is the reason of total control over their platform, and that's where industry is going - Microsoft is also imposing the same restrictions in Windows RT. That is quite sad, because it doesn't leave much freedom to the programmers, demoting them to just the "apps" coders, there is no place for hackers in its true meaning.

Re: Safari Vs Chrome iOS JavaScript Benchmark

#23
post #21

Can someone explain how an application developer with access to webkit+Nitro could cause problems? Would the developer have to write a malicious app, or would a maliciously crafted webpage be able to exploit the OS?

iOS code signs all code that runs on the system. Compared to most other operating systems, this is a huge security win: without another exploit in that system, even a standard remote code execution vulnerability is useless. Nitro generates code at runtime, so it (by definition) needs to run unsigned code. With Safari, Apple can audit all the code necessary, but with third party apps, it would be easy for a developer…

Except there are always exploits in signed code on that platform, in the form of jailbreaks.

It's a weak argument at best.

Re: Safari Vs Chrome iOS JavaScript Benchmark

#24

Earlier quoted context omitted.

It wouldn't surprise me to discover that Google's team did lots of their own performance tweaking and tuning to compensate for their disadvantage. I do love the responsiveness. Now their Gmail app on the other hand was painful for me to use.

The latest update to the GMail app for iOS is vastly improved.

How does it compare to Sparrow?

Re: Safari Vs Chrome iOS JavaScript Benchmark

#25
post #21

Earlier quoted context omitted.

iOS code signs all code that runs on the system. Compared to most other operating systems, this is a huge security win: without another exploit in that system, even a standard remote code execution vulnerability is useless. Nitro generates code at runtime, so it (by definition) needs to run unsigned code. With Safari, Apple can audit all the code necessary, but with third party apps, it would be easy for a developer…

Except there are always exploits in signed code on that platform, in the form of jailbreaks. It's a weak argument at best.

Yes, but users don't accidentally jailbreak their devices.

Re: Safari Vs Chrome iOS JavaScript Benchmark

#26
post #16

What is the point of UIWebView, if it's meant to help developers write Javascript "native" apps, and yet it's 3x slower than a web app would be inside Mobile Safari? Doesn't that kind of defeat the purpose of UIWebView existing? I'm pretty sure Apple is leaving this as it is on purpose so Javascript apps don't start to compete on performance with ObjectiveC apps, and the security excuse they give is just the lazy one…

> Well guess what. A lot of stuff poses security issues. But you have to balance that out with the features and usability you want to give to the user

Just imagine if Microsoft had done the same starting with Windows 3.1. How much innovation would it have killed?

I recently tried using Adobe AIR to make something, but unlike C# the AIR API is severely sandboxed and limited that even simple things like GetDC or CreateShortcut are just near impossible to implement. End result is I never really completed my app.. something which would have taken me an hour at most to do in C#.

This new trend of technology where everything is being sandboxed and scrutinized for approval in the name of security is really very sad for hacker culture.

Re: Safari Vs Chrome iOS JavaScript Benchmark

#27
post #16

What is the point of UIWebView, if it's meant to help developers write Javascript "native" apps, and yet it's 3x slower than a web app would be inside Mobile Safari? Doesn't that kind of defeat the purpose of UIWebView existing? I'm pretty sure Apple is leaving this as it is on purpose so Javascript apps don't start to compete on performance with ObjectiveC apps, and the security excuse they give is just the lazy one…

> What is the point of UIWebView, if it's meant to help developers write Javascript "native" apps

I'm not sure I buy the premise here. UIWebView is a class to help developers show web content in an app. That's all it was ever about.

> I'm pretty sure Apple is leaving this as it is on purpose so Javascript apps don't start to compete on performance with ObjectiveC apps

Why? Apple doesn't need to worry about this. Their platform-specific features mean that native apps will always win on user experience, regardless of performance. They don't need to hobble performance. Conspiracies sound cute to write about, and are fun to cook up, but it's much likelier that Apple just has better stuff to worry about.

They have a successful, widely-adopted solution for developers to create great apps for their platform.

They have a solution for users to have a great, fast browsing experience.

That's about all they need at the moment, in a world with finite time and resources. It's not Apple's goal to make every single nerdy desire or business model possible. It's their goal to sell a shitload of hardware by making users happy.

My mom isn't asking for super fast performance on a third party browser. She just wants her internet to work. Apple's already giving her that. QED.

Re: Safari Vs Chrome iOS JavaScript Benchmark

#28
post #21

Earlier quoted context omitted.

iOS code signs all code that runs on the system. Compared to most other operating systems, this is a huge security win: without another exploit in that system, even a standard remote code execution vulnerability is useless. Nitro generates code at runtime, so it (by definition) needs to run unsigned code. With Safari, Apple can audit all the code necessary, but with third party apps, it would be easy for a developer…

Except there are always exploits in signed code on that platform, in the form of jailbreaks. It's a weak argument at best.

So far, there have been two userland exploits of the iOS browser (Safari) since Apple implemented code signing in 2008, at JailbreakMe.com. Both of those required tons of extra work compared to what they would have required otherwise.

It's not a "weak argument", it's the reason why iOS is one of the most secure platforms out there, and way more secure than Android, Windows, (most) desktop Linux, and OS X. Other preventative technologies (e.g. ASLR, DEP/w^x, etc) are on those platforms, but none of them have the same kind of pervasive code signing that you see on iOS (and often video game consoles).

Re: Safari Vs Chrome iOS JavaScript Benchmark

#29

Earlier quoted context omitted.

Except there are always exploits in signed code on that platform, in the form of jailbreaks. It's a weak argument at best.

Yes, but users don't accidentally jailbreak their devices.

I'm not an expert at this so please correct me if I'm wrong, but if I remember correctly all I had to do to jailbreak my iphone was go to jailbreakme.com and click the button on it. That was it.

So it seems that if I can trick someone to click that button then it is possible for me to not only jailbreak their phone but also run any sort of malicious code afterwards (because instead of Cydia it can install just about anything).

Post reply on HN