Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Apple Intentionally Crippled 3rd Party Browsers in iOS 4.3
- Thread starter SomeDudeAsking
- Start date
- Sort by reaction score
I'm going by what I've read. Until someone proves otherwise, I can only assume that UIWebView has different access than Safari, which makes sense given that the App Store relies on a UIWebView to access the system and install apps. Given that UIWebView has granular access to the system, it would only make sense that it is inherently less secure than Safari. I'm not arguing that someone can't write a JS exploit for Safari; the issue is that if UIWebView used Nitro, someone could write JS that is compiled into binary, which means the system is at a far greater risk (given UIWebView's granular system access).
But surely the only code being generated into those soon-to-be-executable pages is generated by Nitro so can't it at least ensure that only pages that relate to the code segments of the output are set to executable and that all variable and stack pages are not? can't it also make sure that its generated code never calls unpublished APIs or tries to execute data in the Javascript as code? Surely if iOS were opened up such that any process could set execute on any page then that is a wider security issue.
I hope that they do address this with sandboxing or something because this is about more than third party browsers, it's working against the entire iPad concept. My belief is that the iPad is supposed to be an internet-centric device and loads of third party apps have web access integrated as a fundemental part of their functionality (weather apps to view satelite imagary, facebook apps that follow a link, news reader apps that provide access to the source story. Basically pretty much any app that offers the ability to view a link without exiting the app and switching to Safari). It's going to be a real shame if all Apple's work in optimizing internet access only benefits 50% of the internet access being done on my device. (Actually, I use iCab so I'm stuffed right now but I'd say that almost half my access isn't direct from a browser, it's from things like Reeder and Friendly and a few other apps.)
- Julian
What you're saying doesn't make any sense.
The "App Store" app's ability to install new applications isn't in any way related to a UIWebView.
A UIWebView in the Twitter App poses no more or less risk to the system than Safari does.
yes...and atomic browser isn't made for desktops. the point was that when apple comes out with something new for THEIR browser, that feature obviously isn't going to work with the other browsers...they aren't apple. Who cares if the exact spec in question isn't better on the desktop version of safari? That isn't the point. The point is that, if it were all of the sudden better than the competition, the OPs comment would be akin to complaining that Apple made javascript better on safari, but not on firefox or chrome...it doesn't make any sense.
and I was under the impression that firefox and chrome CHOSE not to be on iOS, not that they were forced...other third party browsers exist, and mozilla even has an app that interacts with firefox. If they followed the App store rules and built a browser, it'd get approved. They just haven't chose to do that (yet)
Wirelessly posted (Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_1 like Mac OS X; en-us) AppleWebKit/532.9 (KHTML, like Gecko) Version/4.0.5 Mobile/8B117 Safari/6531.22.7)
You should take some time and learn hoe iOS apps work because you've just said the anti-thesis of the App Store.
dccorona said:
You should take some time and learn hoe iOS apps work because you've just said the anti-thesis of the App Store.
There is a subtle but notable difference between me not making sense and you not understanding. I've said what I need to say - I'll let you make up your own mind about what is really going on here.
I know how they work, thank you very much. And I know that if chrome built a browser that followed the dev agreement, it'd be accepted. They've never built one. Firefox opted to make a sort of desktop window of sorts, instead of a full browser. Apple isn't forcing them out of the app store, like the other poster suggested
Wirelessly posted (Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_1 like Mac OS X; en-us) AppleWebKit/532.9 (KHTML, like Gecko) Version/4.0.5 Mobile/8B117 Safari/6531.22.7)
They can't make their own browser, not with Apple forbidding them from using their own renderers and engines that give better performance and better security than what Safari gives. You think those other browsers in the App Store are actually "other" browsers? HA! They are all a crippled Safari running with a different skin.
dccorona said:
They can't make their own browser, not with Apple forbidding them from using their own renderers and engines that give better performance and better security than what Safari gives. You think those other browsers in the App Store are actually "other" browsers? HA! They are all a crippled Safari running with a different skin.
It makes sense because many of the third party browser shells are using Apple's Javascript engine, which is the only one that's allowed to execute.
Suddenly third parties like Atomic cannot compete with Safari speed, even though they're using Apple mandated code, because Apple wrote things in such a way that only their browser can trigger the JIT.
And it might stay that way. So it goes.
You seem totally unaware of Apple's prohibition against any app interpreting downloaded code (even Javascript in web pages).
That's why it's impossible to submit third party native browsers like full Opera, Chrome or Firefox. We only have either shells around Apple's WebView, or browsers that actually interpret code on a remote server.