31–40 of 42 posts
There's raw performance, and there's usability. Both determine how fast you get your content. Where Safari wins out in performance due to restrictions on iOS, Chrome wins out in usability. The Omnibox, for example, recognizes my favorite sites after I type just a few characters. Plus, syncing.
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. Thei…
I'm pretty sure it's still the case that when you add a HTML5 app to your home screen (so your users see the icon instead of a bookmark in Safari) all of a sudden it doesn't get run on the Nitro JS engine anymore.
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 Create…
So I think you have the volume turned to 11 on the idea of it killing innovation.
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.
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 preve…
It has yet to be shown that code signing helps significantly to improve security. It relies too much on the competency of those that write said signed software. Measures like sandboxing are much more effective.
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…
I'm still unclear why it's safe for Safari to execute unsigned javascript, but not UIWebView. Thanks.
Earlier quoted context omitted.
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 preve…
Code signing is the reason why iOS and game consoles are closed platforms, so only the first party controls what you can run on it. They're just protecting their profits. It has yet to be shown that code signing helps significantly to improve security. It relies too much on the competency of those that write said signed software. Measures like sandboxing are much more effective.
Hah! I needed a good laugh today.
No, Apple has not blacklisted a developer's certificate that we know of to the extent that pre-existing apps on an arbitrary user's phone will stop working due to validation failure, but they have revoked certificates from developers that effectively prevent them from ever submitting another app to the store[1]. You're right that sandboxing is a stronger security measure in a general sense, but security isn't a black or white thing you can throw a single buzzword at and have all your problems taken care of. Code signing is an additional layer of protection for the average user so he/she doesn't download a fake AV program that grinds their device to a halt while offering to get rid of itself for the low price of $39.99. Yes, code signing also ensures that the manufacturer of the device can also get a cut of the profits of other people's hard work, but that is not it's only reason for existence and it doesn't always have to be employed as a revenue stream.
[1] http://www.forbes.com/sites/andygreenberg/2011/11/07/apple-e...
Earlier quoted context omitted.
> 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 Create…
All we are talking about here is a loss of performance in Javascript benchmarks. In every day usage you simply don't notice a difference between Chrome and Safari. So I think you have the volume turned to 11 on the idea of it killing innovation.
For example: The most important app for me is iBlacklist for iPhone. It prevents nearly 20 spam text messages for me daily, which directly translates into less annoyance and added productivity daily. Yet, Apple will never approve this app for general public.
Same for Microsoft's on{x}, which is a genius innovation imo but because of the recent inane app store policies trend, even Microsoft had to release it for Android only.
Earlier quoted context omitted.
> 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. Thei…
> 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 it's still the case that when you add a HTML5 app to your home screen (so your users see the icon instead of a bookmark in Safari) all of a sudden it doesn't get run on the Nitro JS engine anymore.
It is not the case.
http://arstechnica.com/apple/2011/06/ios-5-brings-nitro-spee...
Earlier quoted context omitted.
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…
I don't recall of ever hearing a story where someone accidentally jailbroke their phone, although I could be ill informed.
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…
Could you please expand on this a little: "With Safari, Apple can audit all the code necessary". I'm still unclear why it's safe for Safari to execute unsigned javascript, but not UIWebView. Thanks.