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?
Safari Vs Chrome iOS JavaScript Benchmark
21–30 of 42 posts
Re: Safari Vs Chrome iOS JavaScript Benchmark
#22What 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…
Re: Safari Vs Chrome iOS JavaScript Benchmark
#23Can 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…
It's a weak argument at best.
Re: Safari Vs Chrome iOS JavaScript Benchmark
#24Earlier 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.
Re: Safari Vs Chrome iOS JavaScript Benchmark
#25Earlier 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.
Re: Safari Vs Chrome iOS JavaScript Benchmark
#26What 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…
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
#27What 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…
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
#28Earlier 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.
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
#29Earlier 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.
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).
Re: Safari Vs Chrome iOS JavaScript Benchmark
#30http://trac.webkit.org/changeset/108309
http://wingolog.org/archives/2012/06/27/inside-javascriptcor...