Apple Intentionally Crippled 3rd Party Browsers in iOS 4.3

[SomeDudeAsking]

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)

From the news that Apple is not allowing the embedded web views to use the new JavaScript engine in iOS 4.3, it can be seen that Apple is intentionally crippling all third party browsers in favor of only using pure Safari, which is a POS interface and feature wise. Apple is using it's draconian control to see to it that the already artificially handicapped third party browsers are not allowed to use the same engine Safari uses. Instead, third party browsers must use the much slower last gen JavaScript engine. And Apple forbid third party browsers like Atomic Browser from using anything but the last gen engine. This is completely unacceptable. Even at the peak of Microsoft's rein, they did not cripple other browsers. Apple is much worse than Microsoft ever was.

 

[lsvtecjohn3]

Cool story bro

You hate Apple so much but your always on this forum why is that?

 

[BaldiMac]

The non-conspiracy theory explanation.
http://daringfireball.net/2011/03/nitro_ios_43

 

[Interstella5555]

Do you even own an iPhone? If not, you must lead a sad, lonely lif to come here and continually talk smack about it. Remember, it takes just as much energy to hate as it does to love; perhaps your angst could be put to something more constructive.

 

[AdrianK]

I also love a good conspiracy theory, did you know that aliens built the pyramids?

 

[Sedrick]

The non-conspiracy theory explanation.
http://daringfireball.net/2011/03/nitro_ios_43

"The clear insinuation is that web apps running outside Mobile Safari have been made to run slower, but that’s not true. What happened with iOS 4.3 is that web apps (and JavaScript in general) running inside Mobile Safari have been made significantly faster.

The Nitro JavaScript engine is only available within Mobile Safari. Outside Mobile Safari — whether in App Store apps using the UIWebView control, or in true web apps that have been saved to the home screen — apps get iOS’s older JavaScript engine.

Put another way: nothing is slower regarding web apps or web page rendering in iOS 4.3 compared to 4.2 or earlier. If anything, everything is at least a little bit faster. But: the most significant performance improvements in iOS 4.3, particularly for JavaScript, are exclusive to Mobile Safari."

Emphasis mine.

 

[Daveoc64]

The non-conspiracy theory explanation.
http://daringfireball.net/2011/03/nitro_ios_43

Many people would question the need for iOS to have such a level of security in a UIWebView.

You can say something is in the name of "security", but it's far less likely IMO that if the user has pinned something to their home screen or if they are accessing it through an App that has been approved by Apple for there to be a security problem with a site viewed that way.

 

[michael.lauden]

Cool story bro

You hate Apple so much but your always on this forum why is that?

Instead of flaming him - why not expose holes in his 'views' in form of a rebuttal?

I.e:

When Opera was released in the App Store - why didn't you view it as 'crippling' safari?

or

When an update comes to Skyfire - why doesn't it apply to Safari?

or

http://goo.gl/dGxJb

kablamo

 

[xAnthony]

Apple doesn't want competition on it's own device. And why would they... So they do this to make their browser 'the best' and I don't really mind. Who uses third party browsers these days anyways...

 

[brock2621]

Every freaking day I get on here and SomeDude is cluttering up these forums with his stupid whining and crying like a little girl about how eeeevviilll apple is destroying the universe and has turned him into a unich.

I think you clicked the wrong bookmark Brah. Here, I'll help you out http://androidcentral.com/.

 

[Daveoc64]

Apple doesn't want competition on it's own device. And why would they... So they do this to make their browser 'the best' and I don't really mind. Who uses third party browsers these days anyways...

Well...nobody can, so your point doesn't really work.

Note: Yes there are other browsers for iOS, but Apple heavily restricts what they can do. They're either skins for Safari (with the previously mentioned performance limitations) or rely on Opera-style server rendering.

Neither really offers the user anything.

 

[xAnthony]

Well...nobody can, so your point doesn't really work.

Note: Yes there are other browsers for iOS, but Apple heavily restricts what they can do. They're either skins for Safari (with the previously mentioned performance limitations) or rely on Opera-style server rendering.

Neither really offers the user anything.

Can you blame them? I'm sure you would do the same if you were in their position. You want people using Safari, and not some browser they purchased from the app store.

Safari is a huge selling point to consumers. Consumers want the device to be fast, and they want Safari to work as promised. It's known as one of the best (If not the best) mobile browser on a phone. So I could see why they want to control that market and not just let anyone make an app that could replace it.

 

[milani]

From what I have read it's entirely because the new JS engine would be able to execute malicious code on its own. It's actually not a conspiracy theory, nor does it have anything to do with Apple intentionally crippling web apps - at least not to force people to buy apps in the App Store.

The reason is because the JS engine actually turns javascript into binary, which is - for practical consideration - the same as native code. So while a native app cannot use disallowed APIs or execute processes on its own because it is vetted before it enters the App Store, a website has no such restrictions. And, while the previous JS engine could not execute code on a system level, the nature of the Nitro engine does. Why does Apple allow the new engine on Safari? Because Apple trusts its own code - they aren't going to write an exploit into the app to be executed by javascript. Why not web apps on the homescreen? They don't run in Safari, they run in a UIWebView-based app called "Web" oddly enough.

Apple's current solution is to disallow UIWebView (web apps on the homescreen and other apps with browsers like the Facebook app) from using the Nitro engine; but that's a band-aid solution and Apple likely knows this.

The security risk is very real. Unfortunately, by building a better JS engine Apple created a new security problem for itself.

That said, there is a potential solution (well above my head) whereby Apple can compartmentalize the processes associated with the UIWebView, ensuring that malicious code cannot be executed on a system-wide level while still converting the JS into binary for instantaneous execution - in other words, it will put the UIWebView in a sandbox, to ensure that that code does not have access to the system (just like it didn't with the old JS engine). But that will take some time, and require some retooling of iOS (or so I've been led to believe).

I read all about it in this article: http://www.macworld.com/article/158643/2011/03/ios_nitro_explained.html#lsrc=twt_macworld

 

[SomeDudeAsking]

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)

From what I have read it's entirely because the new JS engine would be able to execute malicious code on its own. It's actually not a conspiracy theory, nor does it have anything to do with Apple intentionally crippling web apps - at least not to force people to buy apps in the App Store.

The reason is because the JS engine actually turns javascript into binary, which is - for practical consideration - the same as native code. So while a native app cannot use disallowed APIs or execute processes on its own because it is vetted before it enters the App Store, a website has no such restrictions. And, while the previous JS engine could not execute code on a system level, the nature of the Nitro engine does. Why does Apple allow the new engine on Safari? Because Apple trusts its own code - they aren't going to write an exploit into the app to be executed by javascript. Why not web apps on the homescreen? They don't run in Safari, they run in a UIWebView-based app called "Web" oddly enough.

Apple's current solution is to disallow UIWebView (web apps on the homescreen and other apps with browsers like the Facebook app) from using the Nitro engine; but that's a band-aid solution and Apple likely knows this.

The security risk is very real. Unfortunately, by building a better JS engine Apple created a new security problem for itself.

That said, there is a potential solution (well above my head) whereby Apple can compartmentalize the processes associated with the UIWebView, ensuring that malicious code cannot be executed on a system-wide level while still converting the JS into binary for instantaneous execution - in other words, it will put the UIWebView in a sandbox, to ensure that that code does not have access to the system (just like it didn't with the old JS engine). But that will take some time, and require some retooling of iOS (or so I've been led to believe).

I read all about it in this article: http://www.macworld.com/article/158643/2011/03/ios_nitro_explained.html#lsrc=twt_macworld

That is a load of bull crap. That guy has no idea in hell what he saying and is obviously a dumb writer trying to sound smart. The argument that Apple's browser is more secure and thus is specially allowed to run native code is down right false. It also misrepresents how JavaScript is compiled and run. In case you haven't noticed, Pwn2Own and even Apple's own iOS release notes show that there are more holes in Safari that a block of Swiss cheese.

 

[Apple 26.2]

That is a load of bull crap. That guy has no idea in hell what he saying and is obviously a dumb writer trying to sound smart. The argument that Apple's browser is more secure and thus is specially allowed to run native code is down right false. It also misrepresents how JavaScript is compiled and run. In case you haven't noticed, Pwn2Own and even Apple's own iOS release notes show that there are more holes in Safari that a block of Swiss cheese.

Isn't that the point? You made his case for him...

 

[Krevnik]

That is a load of bull crap. That guy has no idea in hell what he saying and is obviously a dumb writer trying to sound smart. The argument that Apple's browser is more secure and thus is specially allowed to run native code is down right false. It also misrepresents how JavaScript is compiled and run. In case you haven't noticed, Pwn2Own and even Apple's own iOS release notes show that there are more holes in Safari that a block of Swiss cheese.

Misrepresents how JS is compiled and run? Not really. A JIT is entirely different from an interpreter which is what WebKit used before Nitro. Interpreters don't compile anything, they execute the script directly. So you don't generate any new native code to execute on the processor. You can still exploit an interpreter because of it's complexity though.

A JIT does produce native code, because the whole point is to compile things into blocks of code that can be re-executed from the cache. To do this though, it is true that you need to mark pages as executable that were formerly data. You can do that on an app by app basis, but that won't let any dev come in and use the JIT since they need that exception to do it.

The more I read about Nitro and the iOS security model which uses DEP, the more it makes sense that this particular issue is "Won't Fix." With 5.0 coming up, they simply don't have the resources to fix this in 4.x and if there is a fix, it will come in 5.x due to the scale of work sandboxing the JS engine. It would probably mean adopting WebKit2 in iOS to pull it off, which isn't a bad thing.

What surprises me more is that Apple released the new engine before iOS 5 when they could do that scale of work.

 

[vincenz]

Gotta love the trolls

 

[milani]

That is a load of bull crap. ...

Yes, because a conspiracy involving a new javascript engine is far more likely to be the case.

What surprises me more is that Apple released the new engine before iOS 5 when they could do that scale of work.

I bet it was specifically released for the iPad 2. Apple wants the browser to be faster - so releasing a faster javascript engine now makes sense. Hopefully the JS engine is properly sandboxed in iOS 5.

 

[dccorona]

I know really. It's so unfair when apple comes out with a new version of safari, and firefox and chrome don't get any of the same new features! They're crippling them on purpose!

...so Apple made safari better, and the changes didn't apply to third party browsers...how is that surprising to you?

 

[Daveoc64]

Can you blame them? I'm sure you would do the same if you were in their position. You want people using Safari, and not some browser they purchased from the app store.

Safari is a huge selling point to consumers. Consumers want the device to be fast, and they want Safari to work as promised. It's known as one of the best (If not the best) mobile browser on a phone. So I could see why they want to control that market and not just let anyone make an app that could replace it.

This doesn't make any sense.

Allowing Firefox, Chrome or (a proper version of) Opera wouldn't stop Safari being a selling point, fast or the best browser.

If I was in Apple's position I would definitely allow other browsers (with their own engines on the App Store.

 

[Daveoc64]

I know really. It's so unfair when apple comes out with a new version of safari, and firefox and chrome don't get any of the same new features! They're crippling them on purpose!

...so Apple made safari better, and the changes didn't apply to third party browsers...how is that surprising to you?

Firefox and Chrome aren't allowed on iOS, so I don't know what you're talking about.

I think you're making a lame attempt at blindly (very blindly in this case) supporting Apple.

FYI, if you're talking about Javascript performance (which this thread is) on the Desktop, Safari is far behind Chrome and Firefox.

 

[Daveoc64]

Misrepresents how JS is compiled and run? Not really. A JIT is entirely different from an interpreter which is what WebKit used before Nitro. Interpreters don't compile anything, they execute the script directly. So you don't generate any new native code to execute on the processor. You can still exploit an interpreter because of it's complexity though.

A JIT does produce native code, because the whole point is to compile things into blocks of code that can be re-executed from the cache. To do this though, it is true that you need to mark pages as executable that were formerly data. You can do that on an app by app basis, but that won't let any dev come in and use the JIT since they need that exception to do it.

The more I read about Nitro and the iOS security model which uses DEP, the more it makes sense that this particular issue is "Won't Fix." With 5.0 coming up, they simply don't have the resources to fix this in 4.x and if there is a fix, it will come in 5.x due to the scale of work sandboxing the JS engine. It would probably mean adopting WebKit2 in iOS to pull it off, which isn't a bad thing.

What surprises me more is that Apple released the new engine before iOS 5 when they could do that scale of work.

Everything that you've posted is correct up to a point, however you're not assessing the risk accurately.

Safari lets people visit any site that the want to. You can visit this site, you can visit google.com or you could visit a site with malicious code.

In a Web App (or a Native app with a UIWebView), people have intentionally put these sites on their phone. It'd be much harder IMO for such an App to have a security issue.

If Apple has decided it's worth the security risk allowing Safari lower level permissions, it's MORE than worth the risk allowing Web Apps.

There's no logical reason for Apple to consider a site loaded in a UIWebView to be more of a risk than one opened in Safari.

 

[SomeDudeAsking]

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)

I know really. It's so unfair when apple comes out with a new version of safari, and firefox and chrome don't get any of the same new features! They're crippling them on purpose!

...so Apple made safari better, and the changes didn't apply to third party browsers...how is that surprising to you?

That's bull crap. In iOS, Apple specifically forbids other browsers from implementing their own engines. Everything is required to use the engine that Apple throws at you. There is no freedom.

 

[milani]

Everything that you've posted is correct up to a point, however you're not assessing the risk accurately.

Safari lets people visit any site that the want to. You can visit this site, you can visit google.com or you could visit a site with malicious code.

In a Web App (or a Native app with a UIWebView), people have intentionally put these sites on their phone. It'd be much harder IMO for such an App to have a security issue.

If Apple has decided it's worth the security risk allowing Safari lower level permissions, it's MORE than worth the risk allowing Web Apps.

There's no logical reason for Apple to consider a site loaded in a UIWebView to be more of a risk than one opened in Safari.

You missed the fact that UIWebView isn't part of Safari. It runs within an entirely different app called Web, which, it seems, does not have the same security measures in place. In other words, when running compilable JS in UIWebView, there is a possibility to access the system, whereas running the same compilable JS in Safari will not be able to access the system due to Safari's security restrictions and the fact that Safari cannot access the system.

In fact, UIWebView has to have system-level access. Why? Because various applications such as the App Store and iTunes are actually running in a UIWebView AND require system-level access. For instance, how would an app downloaded from the App Store install itself without system access? IWebView requires system access so that applications like the App Store and iTunes can function. The fact that it can be exploited was not an issue to this point because JS was not compilable; the new engine compiles JS into binary, which means you open the device up to an untold number of exploits.

So, the only solution is to sandbox the JS engine. And that is not an entirely easy task. Obviously it can be done, and in all likelihood it will be done, but don't expect to see an iOS update next week, either. The other solution is to write another web view that does not have system-level access; but the effect would probably be the same as sandboxing the JS engine - except that sandboxing the engine means that any potential (though certainly more difficult) Safari exploits can be avoided as well.

In either case, there really is no conspiracy theory here - unless you're into conspiracy theories in which case go nuts.

 

[Daveoc64]

You missed the fact that UIWebView isn't part of Safari. It runs within an entirely different app called Web, which, it seems, does not have the same security measures in place. In other words, when running compilable JS in UIWebView, there is a possibility to access the system, whereas running the same compilable JS in Safari will not be able to access the system due to Safari's security restrictions and the fact that Safari cannot access the system.

I've not seen anyone claim that Safari has any security restrictions that wouldn't apply to a UIWebView.

Safari allows the JIT compiler to mark memory pages as exectuable - this is the security issue.

There isn't anything that Safari is doing to mitigate the risk from that security issue.

There are things that they could do to mitigate the risk (e.g. Sandboxing), but they aren't happening with Safari in iOS 4.3