Why the Nitro JavaScript Engine Isn’t Available to Other iOS Apps(daringfireball.net)
daringfireball.net
Why the Nitro JavaScript Engine Isn’t Available to Other iOS Apps
http://daringfireball.net/2011/03/nitro_ios_43
82 comments
That is not the argument that Gruber is making. That is his factual summary of the current situation.
The argument that is being made is that Apple currently considers it a security risk to enable the new Nitro Javascript engine for all applications, preferring instead to enable it only for Safari Mobile, and leave other applications using the older javascript engine.
Possibly forever, destroying web apps on the iPhone completely, or possibly just until Apple is able to sort out the security implications of having to mark in memory pages as executable.
You get to chose which scenario you think is most plausible.
The argument that is being made is that Apple currently considers it a security risk to enable the new Nitro Javascript engine for all applications, preferring instead to enable it only for Safari Mobile, and leave other applications using the older javascript engine.
Possibly forever, destroying web apps on the iPhone completely, or possibly just until Apple is able to sort out the security implications of having to mark in memory pages as executable.
You get to chose which scenario you think is most plausible.
Well, he's making multiple arguments, and that first one was an argument. My position is that it is a ridiculous one.
I am also not entering the discussion of native apps running UIWebView. I have zero comment on that (mainly because I'm disinterested in the subject).
My only comment is on home-screen web apps, which are 100% equivalent to opening the page on your browser. They deserve more privileges because the user had to make a decision to install them. It makes no sense to me whatsoever that a random advertisement loaded from some insecure URL on a web page is allowed to access Nitro and web cache, but a web app that I trust enough to install on my home screen is not.
Ironically, I'm actually pretty happy with this decision, because I believe all apps should be in the browser. I'm just telling it like it is when people make nonsensical arguments.
I am also not entering the discussion of native apps running UIWebView. I have zero comment on that (mainly because I'm disinterested in the subject).
My only comment is on home-screen web apps, which are 100% equivalent to opening the page on your browser. They deserve more privileges because the user had to make a decision to install them. It makes no sense to me whatsoever that a random advertisement loaded from some insecure URL on a web page is allowed to access Nitro and web cache, but a web app that I trust enough to install on my home screen is not.
Ironically, I'm actually pretty happy with this decision, because I believe all apps should be in the browser. I'm just telling it like it is when people make nonsensical arguments.
You are entering the discussion of native apps running UIWebView because (according to Gruber) that is exactly how home-screen web apps are implemented.
"My only comment is on home-screen web apps, which are 100% equivalent to opening the page on your browser."
From Gruber:
"Web apps that are saved to the home screen do not run within Mobile Safari. They’re effectively saved as discrete apps — thin wrappers around the UIWebView control."
"I'm just telling it like it is when people make nonsensical arguments."
Your failure to read and understand his arguments have made them sound nonsensical to you. This is not his fault.
"My only comment is on home-screen web apps, which are 100% equivalent to opening the page on your browser."
From Gruber:
"Web apps that are saved to the home screen do not run within Mobile Safari. They’re effectively saved as discrete apps — thin wrappers around the UIWebView control."
"I'm just telling it like it is when people make nonsensical arguments."
Your failure to read and understand his arguments have made them sound nonsensical to you. This is not his fault.
I initially thought you were just splitting hairs, but seeing as you've used this argument somewhere else in this thread I think this might be a genuine thought you have so I will take the time to explain why home-screen web apps are absolutely nothing like other native apps on the system, and actually essentially the same as loading a web page in MobileSafari. So for starters, let us observe that there are three instances where JS can run on iOS that we care about:
1. MobileSafari, from a web page loaded from a URL.
2. Home-Screen Web Apps, web pages loaded from a URL that the user then 'saves to the homes screen' which are loaded in some mysterious, but APPLE WRITTEN, "wrapper" process X.
3. UIWebViews within native apps that you buy on the App Store.
Now, my position is that (1) and (2) are for all intents and purposes the same, and (3) is possibly different. So, the whole argument about turning it off for UIWebView is that the interaction between native code and Nitro might offer an additional vector of security concern. Well, in both (1) and (2), there is no user native code. It literally just either downloads the JS off the web, or reloads it straight from the web. All the native code is written PURELY by Apple. So in a world where the only user modifiable code comes from the web, then clearly this is the same as where we started with MobileSafari. The additional thing to realize, is that unlike native apps (3), home-screen web apps (2) are NOT code signed, just like web pages (1). So that also nullifies the argument that allowing Nitro on home-screen web apps would go against Apple's code signing policies.
Hopefully that explains my thinking a little bit clearer.
Once again, I am very willing to believe that they had a deadline to meet, and turning it on for home-screen web apps got punted. That makes perfect sense. The security argument however falls flat on its face.
1. MobileSafari, from a web page loaded from a URL.
2. Home-Screen Web Apps, web pages loaded from a URL that the user then 'saves to the homes screen' which are loaded in some mysterious, but APPLE WRITTEN, "wrapper" process X.
3. UIWebViews within native apps that you buy on the App Store.
Now, my position is that (1) and (2) are for all intents and purposes the same, and (3) is possibly different. So, the whole argument about turning it off for UIWebView is that the interaction between native code and Nitro might offer an additional vector of security concern. Well, in both (1) and (2), there is no user native code. It literally just either downloads the JS off the web, or reloads it straight from the web. All the native code is written PURELY by Apple. So in a world where the only user modifiable code comes from the web, then clearly this is the same as where we started with MobileSafari. The additional thing to realize, is that unlike native apps (3), home-screen web apps (2) are NOT code signed, just like web pages (1). So that also nullifies the argument that allowing Nitro on home-screen web apps would go against Apple's code signing policies.
Hopefully that explains my thinking a little bit clearer.
Once again, I am very willing to believe that they had a deadline to meet, and turning it on for home-screen web apps got punted. That makes perfect sense. The security argument however falls flat on its face.
You seem to be missing a key point.
The way Apple implemented Home-Screen Web Apps was by placing a thin wrapper around a UIWebView.
Hence, Home-Screen Web Apps are not like Mobile Safari at all in actual implementation.
They are, instead, exactly like an iOS application developed by a third party developer who put a thin wrapper around a UIWebView.
Hence, they do not get the same special privileges as Safari Mobile.
That is a fact of their implementation.
The way Apple implemented Home-Screen Web Apps was by placing a thin wrapper around a UIWebView.
Hence, Home-Screen Web Apps are not like Mobile Safari at all in actual implementation.
They are, instead, exactly like an iOS application developed by a third party developer who put a thin wrapper around a UIWebView.
Hence, they do not get the same special privileges as Safari Mobile.
That is a fact of their implementation.
You seem to confusing facts with claims on a blog written by a third party. It's not hard to believe Web.app (the process which runs home screen apps) uses UIWebView or a close cousin, but neither you nor Gruber (or anyone on this site) has offered any evidence of that fact.
I find the fact that Web.app behaves exactly like every other application that uses a UIWebView to be very compelling evidence that Web.app is an application uses UIWebView.
The alternative appears to be that to create Web.app they went to all the trouble of reusing the Mobile Safari code, and then methodically went through and broke things such that it behaves exactly like every other application that uses UIWebView.
This would seem like an unreasonable way to get an application that behaves exactly like an application that uses UIWebView.
The alternative appears to be that to create Web.app they went to all the trouble of reusing the Mobile Safari code, and then methodically went through and broke things such that it behaves exactly like every other application that uses UIWebView.
This would seem like an unreasonable way to get an application that behaves exactly like an application that uses UIWebView.
I think Tolmasky's point was that, even though Web.app embeds the same UIWebView as non-Apple native apps, Web.app was written by Apple. Apple could enable Nitro JIT for Web.app because its native code was written (and audited) by Apple. The only third-party code executed by Web.app is JavaScript that is already assumed to be safe enough to use the Nitro JIT in Mobile Safari.
yes, I think it was.
It makes a heap of assumptions though, and feels kind of like a non-techie person saying "why dont you just whip up a GUI app to trace my IP". Enabling Nitro JIT for UIWebView for some applications without enabling it for every app in the app store is probably more difficult than toggling a switch.
It makes a heap of assumptions though, and feels kind of like a non-techie person saying "why dont you just whip up a GUI app to trace my IP". Enabling Nitro JIT for UIWebView for some applications without enabling it for every app in the app store is probably more difficult than toggling a switch.
They deserve more privileges because the user had to make a decision to install them
I think it is technically different, but on other systems, the HTML pages I put on my desktop have fewer privileges than the ones I load from web sites. (https://bugzilla.mozilla.org/show_bug.cgi?id=230606)
As to the subject at hand: one line of reasoning says that not allowing JIT-ting for home-screen apps is an oversight; home-screen apps apparently do not run in the Safari process. I guess there is no way to find out whether that is true. If Apple fixes it in the next firmware update, one could argue either that they fixed the problem, or that they stalled fixing it for as long as they could get away with, and I am sure the internet will be filled with such arguments, even if that next update appears tomorrow.
Finally, for UIWebView, a secure solution could exist: provide a system call that does "javascript source code in, executable code block out". I do not know whether that could be made performant enough, though, given that the JIT-ter must be very fine-grained, must update existing code blocks, etc. It definitely would be quite a bit of work.
I think it is technically different, but on other systems, the HTML pages I put on my desktop have fewer privileges than the ones I load from web sites. (https://bugzilla.mozilla.org/show_bug.cgi?id=230606)
As to the subject at hand: one line of reasoning says that not allowing JIT-ting for home-screen apps is an oversight; home-screen apps apparently do not run in the Safari process. I guess there is no way to find out whether that is true. If Apple fixes it in the next firmware update, one could argue either that they fixed the problem, or that they stalled fixing it for as long as they could get away with, and I am sure the internet will be filled with such arguments, even if that next update appears tomorrow.
Finally, for UIWebView, a secure solution could exist: provide a system call that does "javascript source code in, executable code block out". I do not know whether that could be made performant enough, though, given that the JIT-ter must be very fine-grained, must update existing code blocks, etc. It definitely would be quite a bit of work.
Edit: yay! you changed your post while I wrote mine.
Would you concede that there could be a security diff between JIT and not JIT?
All Gruber is arguing is:
1) that there is a significant difference in security
2) that Apple didn't release any JIT for webkit all this time [edit: since 2008] because of security concerns
3) that Apple did not go out of its way to remove JIT from those instances of webkit that occurr outside of Mobile Safari
4) that perhaps Apple is simply rolling it out gradually
I don't see how any of this is ridiculous or could be called "bending over backwards" unless you are pre-loaded with a bias against Gruber.
There goes what little karma I earned since 2008.
All Gruber is arguing is:
1) that there is a significant difference in security
2) that Apple didn't release any JIT for webkit all this time [edit: since 2008] because of security concerns
3) that Apple did not go out of its way to remove JIT from those instances of webkit that occurr outside of Mobile Safari
4) that perhaps Apple is simply rolling it out gradually
I don't see how any of this is ridiculous or could be called "bending over backwards" unless you are pre-loaded with a bias against Gruber.
There goes what little karma I earned since 2008.
2) They didn't release it, one imagines, because it is hardware specific, and originally written for x86 not ARM.
Are you saying you are not able to concede my original statement: that JIT vs NOT JIT does [edit: meant to say "could" instead of "does"] constitute a significant security difference?
You should read my other comments on this thread. All of them basically start with "yes JIT may be less secure". That is not the argument I am making: http://news.ycombinator.com/item?id=2338724
[deleted]
Elsewhere in the comments I'm reading HN folks who agree that there are security implications with having writeable code pages available to native apps, and that it's reasonable for some of the JIT stuff to appear in Mobile Safari and not in native apps (although there are other approaches Apple may pursue in the future).
Have you read these arguments? Do you disagree with them? Or are you saying something else?
Just trying to understand...
Have you read these arguments? Do you disagree with them? Or are you saying something else?
Just trying to understand...
For starters, my argument is only about MobileSafari (MS) and home-screen web apps.
If you read my other posts I think you'll see I have no issue with the idea that there may be a security issue with JIT. That is fine and acceptable.
What I have an issue with is the idea that MobileSafari is somehow the safest place to put it. If there is a security issue, then MobileSafari is clearly the absolute least safe place to put it (vs homescreen web apps), since any malicious web page has access to it. That includes random ads loaded on otherwise safe web pages. The user is not prompted when entering a web page if they want to use Nitro or not, so basically anything goes on the open web. If a security flaw is discovered in Nitro, I have only to place it on an ad that gets deployed to popular sites to take advantage of it. And Apple's only recourse is to issue an entire system upgrade and hope people update.
Home-screen web apps are thus at least as safe as MobileSafari, since they are literally just bookmarks that load web pages (in a different process and without chrome, but fundamentally the same, no access to any other native code or anything). They are in fact arguably more safe, because the user has to first grant it "home-screen" status. This is a sensible time to ask the user if this ONE app should deserve more privileges than the rest of the wild-west web. In other words, had apple done the opposite, ONLY allowing home-screen web apps access to Nitro, it would make a lot of security sense, especially because Apple could warn the user before they download the app saying "downloading this app gives it access to the special Nitro engine, which may be less secure...".
If you read my other posts I think you'll see I have no issue with the idea that there may be a security issue with JIT. That is fine and acceptable.
What I have an issue with is the idea that MobileSafari is somehow the safest place to put it. If there is a security issue, then MobileSafari is clearly the absolute least safe place to put it (vs homescreen web apps), since any malicious web page has access to it. That includes random ads loaded on otherwise safe web pages. The user is not prompted when entering a web page if they want to use Nitro or not, so basically anything goes on the open web. If a security flaw is discovered in Nitro, I have only to place it on an ad that gets deployed to popular sites to take advantage of it. And Apple's only recourse is to issue an entire system upgrade and hope people update.
Home-screen web apps are thus at least as safe as MobileSafari, since they are literally just bookmarks that load web pages (in a different process and without chrome, but fundamentally the same, no access to any other native code or anything). They are in fact arguably more safe, because the user has to first grant it "home-screen" status. This is a sensible time to ask the user if this ONE app should deserve more privileges than the rest of the wild-west web. In other words, had apple done the opposite, ONLY allowing home-screen web apps access to Nitro, it would make a lot of security sense, especially because Apple could warn the user before they download the app saying "downloading this app gives it access to the special Nitro engine, which may be less secure...".
I am not arguing with you, I was only trying to distinguish between saying "Gruber could possibly be right, but I think he is wrong" and saying "Gruber can't possibly be right, and he ought to know better."
The situation is complicated by the fact that he is reporting what Apple is doing and what he has been told is the motivation for doing so. So he could be right that Apple is doing this, but you assert that Apple is wrong. Or that Apple is doing this, but not for the reasons they give.
You assert that there is no vulnerability in home screen apps wrapping UIWebView that isn't in Mobile Safari, and thus there is no downside to granting writeable code page permission to home screen apps. Ok, I think I understand what you are saying, why you are saying it, and what you would do in Apple's shoes.
The situation is complicated by the fact that he is reporting what Apple is doing and what he has been told is the motivation for doing so. So he could be right that Apple is doing this, but you assert that Apple is wrong. Or that Apple is doing this, but not for the reasons they give.
You assert that there is no vulnerability in home screen apps wrapping UIWebView that isn't in Mobile Safari, and thus there is no downside to granting writeable code page permission to home screen apps. Ok, I think I understand what you are saying, why you are saying it, and what you would do in Apple's shoes.
His point is that HomeScreen web apps (for lack of a better term) are fundamentally exactly as secure as MobileSafari.
Even a technical argument is somewhat hard to fathom, since it should be a trivially simple thing to enable, but given that none of us can see the code it's at least possible.
As far as native apps with embedded UIWebViews, this is a believable technical argument, though it isn't obviously true either. In other words, the political argument isn't significantly less likely than the technical one.
Even a technical argument is somewhat hard to fathom, since it should be a trivially simple thing to enable, but given that none of us can see the code it's at least possible.
As far as native apps with embedded UIWebViews, this is a believable technical argument, though it isn't obviously true either. In other words, the political argument isn't significantly less likely than the technical one.
From Gruber:
"Web apps that are saved to the home screen do not run within Mobile Safari. They’re effectively saved as discrete apps — thin wrappers around the UIWebView control."
"Web apps that are saved to the home screen do not run within Mobile Safari. They’re effectively saved as discrete apps — thin wrappers around the UIWebView control."
What the GP is arguing is that web apps pinned to the home screen are no different from those same web apps viewed in a browser and therefore, there doesn't seem like there should be any security issue involved in it.
Someone (who I think works on Cydia - the Jailbreak App Store) commented about this further down:
Of course, this means that there is no real good reason why Apple has disabled Nitro for full-screen web applications (that I at least yet understand), and so I'd expect that this was frankly just a silly oversight
Someone (who I think works on Cydia - the Jailbreak App Store) commented about this further down:
Of course, this means that there is no real good reason why Apple has disabled Nitro for full-screen web applications (that I at least yet understand), and so I'd expect that this was frankly just a silly oversight
The "home screen bookmark" app is based on MobileSafari, but clearly isn't the same code base. I understand that your company would benefit from improved offline app performance, but it's likely that developer time and patience will fix the problem.
If you read my later reply, you'll see that I actually prefer the way things are, I just don't like misinformation. I am perfectly capable of accepting that its a matter of engineering time to get this to work. What I am not OK with is the notion that Safari is somehow a "trusted" app where this is not a security concern, whereas a home-screen web app is a security concern. There is no such thing as a trusted browser, any random malicious ad loaded in an iframe can have access to Nitro. Home screen web apps are necessarily just as safe or more safe than web pages.
From Gruber:
"Web apps that are saved to the home screen do not run within Mobile Safari. They’re effectively saved as discrete apps — thin wrappers around the UIWebView control."
Apple clearly believes that there are important security risks associated with their Nitro Javascript Engine.
I have no trouble at all believing that they have been able to mitigate those concerns for Safari Mobile by using a solution that is not appropriate when applied to any arbitary App that may choose to include a UIWebView.
"Web apps that are saved to the home screen do not run within Mobile Safari. They’re effectively saved as discrete apps — thin wrappers around the UIWebView control."
Apple clearly believes that there are important security risks associated with their Nitro Javascript Engine.
I have no trouble at all believing that they have been able to mitigate those concerns for Safari Mobile by using a solution that is not appropriate when applied to any arbitary App that may choose to include a UIWebView.
"Web apps that are saved to the home screen", despite being "thin wrappers around the UIWebView control", are not "any arbitary App that may choose to include a UIWebView".
If they can make it work for Mobile Safari, they can make it work for a "thin wrapper" without working for all UIWebViews.
If they can make it work for Mobile Safari, they can make it work for a "thin wrapper" without working for all UIWebViews.
really? It seems to me that there are clear technical differences.
Im interested in your thoughts though, how would you allow one arbitarily large set of applications with arbitary names to use the Nitro Javascript engine via UIWebView, and still ensure that no third party developer could enable the ability on their own applications?
The way I would do it for a single application is enable a special case for it in the underlying OS....
Im interested in your thoughts though, how would you allow one arbitarily large set of applications with arbitary names to use the Nitro Javascript engine via UIWebView, and still ensure that no third party developer could enable the ability on their own applications?
The way I would do it for a single application is enable a special case for it in the underlying OS....
Make the template app static, sign it with whatever special permissions MobileSafari has. (I'm assuming that some special permission is needed, signed by apple.)
Instantiate the app by copying it and placing the files related to the specific instance (manifest, html, cached files) in the standard mutable data directories (Documents, Cache, ...), which wouldn't affect the signature. (The name of the app and icon would have to excluded from the signature.)
If this is how things work now, I wouldn't be surprised if the lack of Nitro was just an oversight on Apple's part (i.e. they forgot to give the template app the right permissions). If home page web apps are granted a special exception to the usual app-signing, I could imagine that they can't give them these permissions without leaking them to everyone.
Instantiate the app by copying it and placing the files related to the specific instance (manifest, html, cached files) in the standard mutable data directories (Documents, Cache, ...), which wouldn't affect the signature. (The name of the app and icon would have to excluded from the signature.)
If this is how things work now, I wouldn't be surprised if the lack of Nitro was just an oversight on Apple's part (i.e. they forgot to give the template app the right permissions). If home page web apps are granted a special exception to the usual app-signing, I could imagine that they can't give them these permissions without leaking them to everyone.
I'm not sure why I read John Gruber anymore. I get my hopes up that perhaps I'll see some of the smart, incisive that I remember from years ago, but instead I see another pretty baseless apology for Apple's behavior. He may actually be correct in this case, but it's hard to take him seriously given that he seems to bend over backwards to interpret Apple's actions as charitably as possible. This post is certainly more defensible than his recent defense of Apple's 30% application revenue power-grab, but I am skeptical that it was written in any better faith.
With every thing he writes like this, he's behaving more like a fanboy and less like a reliable source of information. It's a bit sad.
With every thing he writes like this, he's behaving more like a fanboy and less like a reliable source of information. It's a bit sad.
You can't read Gruber in the same context you did five or six years ago. At this point he's an established journalisty blogger who depends on a network of sources, some of whom are within Apple Inc. That means, like most working journalists, he needs to consider the tone he takes with any individual article vs. what that article is going to do to his network of sources. The result is his writing still contains the smart incisive analysis it always has, but he also has to bend over backwards to make sure he's presenting what the the internal Apple take on the situation is. Compared to what you or I might say about Apple's behavior over a few beers, yeah, he comes off sounding like an apologist, but compare his coverage to what other in-the-tank tech writers say about Apple and he still comes off as an independent voice covering the company AND someone who can provide a level of context other people can't (details on Nitro's implementation)
100% agreed, his treatment of Apple here and in other articles reads like an Animal Farm'esque quote. If he wants to be Apple's PR department, that's fine, but his masquerade as "independent journalism" strikes me as pretty disingenuous. Which is a shame, because I think he's an very insightful writer who puts a lot of work into his articles.
'"Ah, that is different!" said Boxer. "If Comrade Napoleon says it, it must be right."'
'"Ah, that is different!" said Boxer. "If Comrade Napoleon says it, it must be right."'
So, even if he's right, he's wrong?
If I'm looking for the most reasonably explanation for Apple's behavior that still manages to cast them in a good light, I'll read Gruber. If I'm looking for the most reasonable possible explanation, full stop, I'll read elsewhere.
A broken analog clock is only right twice a day.
His reasoning seems shaky to me. Assuming this new JS engine is a security risk (it's not really, but lets pretend) you're not protecting anyone by making it Safari-only. It'd be like leaving all your ground-floor windows wide open, whilst locking your front and back doors in hopes that it will discourage burglars.
If the new JS engine is a security problem either fix it or remove it. Compromise helps no one.
If the new JS engine is a security problem either fix it or remove it. Compromise helps no one.
Apple can't turn on the ability to do executable, dynamically written to memory pages just for their library: they'd have to turn it on for the entire process, at which point you could also do crazy things like download native code and execute it, bypassing the entire concept of their "codesign" mechanism.
Parent's credentials include Cydia, so this is probably the most valuable comment we're going to see in this whole thread.
Thanks for weighing in, sir – this was just the expert opinion I was hoping to see.
Thanks for weighing in, sir – this was just the expert opinion I was hoping to see.
Not just bypassing code signing, but the App Store approval process altogether?
The application that is downloading and executing code would itself have to be signed, so this doesn't get around the App Store approval process: the bootstrap app could be loaded by anyone with a developer certificate, but then they can just sign anything they want that runs as a normal process.
The effects this would have are in:
a) security (although codesign is a fundamentally flawed system due to return-oriented programming techniques and is frankly just security theatre at this point)
b) meta-store fronts (Apple would have to be much more careful about approving applications that downloaded other applications at runtime; Apple could revoke these, though, and you can already do stuff like this with interpreters, although you might not want to bother)
and, I'd say most importantly, c) JITs (suddenly there would be no technical obstacles to having good versions of Java, Mono, or even Flash; and given that the contractual obligations they added got so much pushback that they were removed, we /would/ see good versions of Java, Mono, and even Flash)
The effects this would have are in:
a) security (although codesign is a fundamentally flawed system due to return-oriented programming techniques and is frankly just security theatre at this point)
b) meta-store fronts (Apple would have to be much more careful about approving applications that downloaded other applications at runtime; Apple could revoke these, though, and you can already do stuff like this with interpreters, although you might not want to bother)
and, I'd say most importantly, c) JITs (suddenly there would be no technical obstacles to having good versions of Java, Mono, or even Flash; and given that the contractual obligations they added got so much pushback that they were removed, we /would/ see good versions of Java, Mono, and even Flash)
Are home screen-pinned web apps separate processes? This makes sense for UIWebViews, but not for web apps pinned to the home screen.
Yes. In order for all of the existing mechanisms for managing things that look like apps to work in reasonably logical ways (launching the app, switching between apps, resource managing the app while it is in the background, isolating faults from the app, etc.), home screen web applications are each represented by Web.app.
On a similar note, in order for similarly interesting behaviors to work with iAd (home button acting as "close", address space isolation to keep your process from messing with the ad, etc.), there is an application that backs them called WebSheet.app that also causes these to be in separate processes.
Of course, this means that there is no real good reason why Apple has disabled Nitro for full-screen web applications (that I at least yet understand), and so I'd expect that this was frankly just a silly oversight (and I may know more about what reasoning went into this when I get around to pulling apart how Apple grants MobileSafari this privilege).
On a similar note, in order for similarly interesting behaviors to work with iAd (home button acting as "close", address space isolation to keep your process from messing with the ad, etc.), there is an application that backs them called WebSheet.app that also causes these to be in separate processes.
Of course, this means that there is no real good reason why Apple has disabled Nitro for full-screen web applications (that I at least yet understand), and so I'd expect that this was frankly just a silly oversight (and I may know more about what reasoning went into this when I get around to pulling apart how Apple grants MobileSafari this privilege).
I wonder if running the Javascript environment in a separate process could be a workable compromise.
It's not the JavaScript engine that's the security risk, it's that in order to run the new JS engine, the app running it has to be able to execute code from writable memory. This is where the security risk lies, and it has always been forbidden, for all apps. Safari can get an exception, since Apple obviously trusts its own code not to be malicious. But 3rd party apps still won't be allowed to execute arbitrary code from memory, so any apps embedding a UIWebView to present a browser can't get the performance improvements of the new engine.
The only real question is why Apple's own app that's used to display those saved-to-home-screen webapps didn't get an exception alongside Safari. My guess is that the Nitro engine is built directly into Safari and that the UIWebView control (which is used by webapp viewer app) simply can't use it at all, regardless of ability to execute writable code. I'm sure this will change, either the viewer app will get rewritten, or UIWebView will get its own sandbox etc. They probably just didn't have the time to do that yet.
The only real question is why Apple's own app that's used to display those saved-to-home-screen webapps didn't get an exception alongside Safari. My guess is that the Nitro engine is built directly into Safari and that the UIWebView control (which is used by webapp viewer app) simply can't use it at all, regardless of ability to execute writable code. I'm sure this will change, either the viewer app will get rewritten, or UIWebView will get its own sandbox etc. They probably just didn't have the time to do that yet.
It's not the JS engine that's the security problem. It's that the JS engine requires allowing apps to mark pages as executable. Executable pages opens up a whole another vector of attacks that have nothing to do with dangerous JS apps.
That doesn't make any sense. It requires allowing the JIT to mark pages as executable. But that's exactly the same as the browser. There should not be any new security vector exposed that's not already there from the browser.
The new vector is that, in Safari's case, Apple audited the code that calls the JIT.
If UIWebView could JIT, somebody would write an app that dumps the JITs code (I assume that ARM does not have the ability to mark pages as 'executable, but not readable') and run it on a development system. From there, (s)he would figure out what the JIT does to make data executable. That knowledge could be used in an app that can execute code that Apple hasn't seen.
Of course, that app would need to pass the app store approval process to be useful, but that should not be hard.
A way around this is to move the JIT to the kernel or to a different process. I would guess that that would hinder performance so much that, in typical usage, JIT-ting becomes too expensive to speed up things. Alternatively, Apple could not have spent the time to do so (yet).
If UIWebView could JIT, somebody would write an app that dumps the JITs code (I assume that ARM does not have the ability to mark pages as 'executable, but not readable') and run it on a development system. From there, (s)he would figure out what the JIT does to make data executable. That knowledge could be used in an app that can execute code that Apple hasn't seen.
Of course, that app would need to pass the app store approval process to be useful, but that should not be hard.
A way around this is to move the JIT to the kernel or to a different process. I would guess that that would hinder performance so much that, in typical usage, JIT-ting becomes too expensive to speed up things. Alternatively, Apple could not have spent the time to do so (yet).
A way around this is to move the JIT to the kernel or to a different process. I would guess that that would hinder performance so much that, in typical usage, JIT-ting becomes too expensive to speed up things
Having the hosted browser in a different process shouldn't be too expensive. That's what Chrome and IE do. When you open up a UIWebView and process gets spun up that hosts the JIT (amongst the other plubming for the browser) and the host just has a window where the rendering takes place. This also fixes a whole host of other security problems hosting a browser in process.
Having the hosted browser in a different process shouldn't be too expensive. That's what Chrome and IE do. When you open up a UIWebView and process gets spun up that hosts the JIT (amongst the other plubming for the browser) and the host just has a window where the rendering takes place. This also fixes a whole host of other security problems hosting a browser in process.
Chrome and IE run on systems with faster processors and Gigabytes of RAM. RAM, especially is tight on iOS devices.
I also guess that some iOS apps will want to overlay stuff on their web views, postprocess the data, register callbacks, etc. Supporting such use might be a bit of work that Apple hasn't done yet.
I also guess that some iOS apps will want to overlay stuff on their web views, postprocess the data, register callbacks, etc. Supporting such use might be a bit of work that Apple hasn't done yet.
But aren't they within the same process? (I'm asking an honest question - I know nothing of iOS internals).
Doesn't that imply that the JIT has privileged access to pages that other code within the same process does not? As saurik (who knows about these things) mentions elsewhere, Apple can trust Safari to not tamper with the executable pages - can they trust 3rd party apps?
Home-screen based web-apps being another question entirely.
Doesn't that imply that the JIT has privileged access to pages that other code within the same process does not? As saurik (who knows about these things) mentions elsewhere, Apple can trust Safari to not tamper with the executable pages - can they trust 3rd party apps?
Home-screen based web-apps being another question entirely.
They might be in the same process. I guess they don't do process isolation for hosted browser controls? If not, they should. Otherwise the app stack is always at risk of running arbitrary javascript in process.
I'm not sure which I'd rather see - Gruber being proved wrong (again), or a whole class of new remote "visit this site to jailbreak your iPhone" exploits...
No one knows for sure either way yet. So wouldn't most people's opinion on the subject be inherently lacking in the 'reliable source of information' department? He usually provides links to the other side of any given argument. Isn't it really up to the reader to decide what they believe? I tend to agree with him on this one because web apps on 4.2 weren't exactly impossibly slow and unusable. The performance increases in 4.3 are nice but it doesn't really make any huge difference to someone's ability to write good web apps today. Apple could have just removed the ability to launch web apps from the home-screen entirely if they wanted to. Why would they be so sloppy at executing a grand anti-competitive conspiracy?
He had an explanation quite a while back (he kinda shifted gears) which I parsed as him saying he wasn't going to spend as much time being a link roll with snippets of commentary, into spending more time on his long-form pieces. (No idea what my search terms would be to find it)
Perhaps his best work was when he distilled the ecosystem down into a fantastic stream of links, a brilliant and hard-working focused aggregator/editor.
Bit more of a bloviating opinion columnist now-a-days. And I guess his biases are brought to the front more.
Understandable though. Everyone is converging on his range of primary sources and editorially crowd-sourcing it in realtime.
I'll still be frequenting his site. It's still quality. You just read with a bias-aware filter like you do any other news source.
Perhaps his best work was when he distilled the ecosystem down into a fantastic stream of links, a brilliant and hard-working focused aggregator/editor.
Bit more of a bloviating opinion columnist now-a-days. And I guess his biases are brought to the front more.
Understandable though. Everyone is converging on his range of primary sources and editorially crowd-sourcing it in realtime.
I'll still be frequenting his site. It's still quality. You just read with a bias-aware filter like you do any other news source.
Man. I totally agree with you but you knew you were going to sacrifice some karma for saying this.
What really disturbs me is not the nitro JS performance part but this (from the register article):
Not only is this a much worse consequence and far more damaging than slower javascript, it's not addressed by any of the arguments I have heard about security. How does anybody explain this as a consequence of marking memory pages non-executable?
I will be very interested to see whether Apple fixes this and how quickly they do it. If they fix it urgently then I will recall the cynic hound-dogs within me. But if they let this lag for months then it seems pretty clear to me that they are just cynically closing down any attempt to route around the app store, if only by ensuring nobody will try to do so due to the chilling effect of knowing such apps could be broken for months at a time.
What's more, such "home screen web apps"
can't use various web caching systems,
including the HTML5 Application Cache,
which means they can't be cached to
run offline.
Not only is this a much worse consequence and far more damaging than slower javascript, it's not addressed by any of the arguments I have heard about security. How does anybody explain this as a consequence of marking memory pages non-executable?
I will be very interested to see whether Apple fixes this and how quickly they do it. If they fix it urgently then I will recall the cynic hound-dogs within me. But if they let this lag for months then it seems pretty clear to me that they are just cynically closing down any attempt to route around the app store, if only by ensuring nobody will try to do so due to the chilling effect of knowing such apps could be broken for months at a time.
As far as I know there was a bug on 4.2.1 where home screen web applications marked with a specific flag couldn't use the HTML5 Application Cache. Maybe they didn't get to fixing this in 4.3, but on 4.2.1 there was a reasonable-ish workaround.
Look, I hate Apple as much as the next guy (maybe more so: I mean, I've dedicate my life to messing with them), but the random rumor mongering surrounding tiny actions that they perform needs to stop.
Like, the HTML5 Application Cache? That code is horribly broken. I started using the HTML5 Application Cache in Cydia (and am now sufficiently "down that road" that I'm launching with this, hell or high water), but WebKit's implementation's barely works, and I don't think it is reasonable for people to be holding Apple quite to task on whether this feature happens to be working in every scenario.
I mean, seriously: when you start going through the WebCore code history and public bug tracker teasing apart what is going on, you find that the developers working on with some of these issues (and there are still critical show-stopper bugs that have only been noticed a few months ago, as well as ones that are still open) actually claim "no one understands this system", something you really believe when you see the massive unstable state machine that surrounds it.
It is therefore entirely plausible to me that the reason the app cache isn't working in apps with some random meta flag is solely because of one of the numerous queue bugs in WebKit's appcache logic that totally wedge the mechanism (even crashing it at times) if things happen to reload in the wrong order.
Look, I hate Apple as much as the next guy (maybe more so: I mean, I've dedicate my life to messing with them), but the random rumor mongering surrounding tiny actions that they perform needs to stop.
Like, the HTML5 Application Cache? That code is horribly broken. I started using the HTML5 Application Cache in Cydia (and am now sufficiently "down that road" that I'm launching with this, hell or high water), but WebKit's implementation's barely works, and I don't think it is reasonable for people to be holding Apple quite to task on whether this feature happens to be working in every scenario.
I mean, seriously: when you start going through the WebCore code history and public bug tracker teasing apart what is going on, you find that the developers working on with some of these issues (and there are still critical show-stopper bugs that have only been noticed a few months ago, as well as ones that are still open) actually claim "no one understands this system", something you really believe when you see the massive unstable state machine that surrounds it.
It is therefore entirely plausible to me that the reason the app cache isn't working in apps with some random meta flag is solely because of one of the numerous queue bugs in WebKit's appcache logic that totally wedge the mechanism (even crashing it at times) if things happen to reload in the wrong order.
It's been working for a long time to suddenly just break now ... when Apple just happens to be exercising some particularly anti-competitive practices against other players who might conceivably use it as a workaround.
Like I said - if they jump on it and fix it I'll say fair enough - anything can get broken in the rush to put out a new release (especially with a high profile new device involved - one can hardly expect they would be delaying release of iPad2 because of something like this). So we will see what happens. However until I see it fixed or some kind of indication that it will be I remain highly skeptical.
Like I said - if they jump on it and fix it I'll say fair enough - anything can get broken in the rush to put out a new release (especially with a high profile new device involved - one can hardly expect they would be delaying release of iPad2 because of something like this). So we will see what happens. However until I see it fixed or some kind of indication that it will be I remain highly skeptical.
I don't know why they said that. I still can run http://code.google.com/p/pjs4ipad/ on an iPad 1 with wi-fi shut off with 4.3 (8F190). It works after a shutdown, power-up cycle too.
It's not just the Register, Ars http://arstechnica.com/apple/news/2011/03/confirmed-some-web... makes the same claim, but it works on my desk ;)
It's not just the Register, Ars http://arstechnica.com/apple/news/2011/03/confirmed-some-web... makes the same claim, but it works on my desk ;)
Saurik answered it, but it turns out that clearing Safari's cache will show that offline webapps are broken: http://technologizer.com/2011/03/16/the-trouble-with-iphone-...
The explanation does actually derive from a security concern. Apps are sandboxed on the file system, so they can't access the cache. If apps were given access to the shared cache, they could pollute it.
Of course there are plenty of ways that Apple could address this problem, just as there are plenty of ways that Apple could address the non-executable pages problem.
Of course there are plenty of ways that Apple could address this problem, just as there are plenty of ways that Apple could address the non-executable pages problem.
If it's a security concern then it's a very strange one. Apps are certainly sandboxed, but they've always been able to access their own files before. And this offline cache has been working for a long time. It's a very strange thing if they suddenly claim this is a security problem now.
Gruber: It is not an oversight or a bug, or the result of a single person at Apple wishing to hinder the performance of web apps.
Ars: Apple is aware of the issues, which are currently filed as bugs... are marked "not to be fixed by exec order,"
Well, this ought to be interesting.
Ars: Apple is aware of the issues, which are currently filed as bugs... are marked "not to be fixed by exec order,"
Well, this ought to be interesting.
I don't have any idea where the truth lies, here, but it's worth pulling the whole paragraph:
But according to Matt Asay, who is vice president of business development for mobile Web framework maker Strobe, Apple supposedly has no plans to fix them. Instead, they are marked "not to be fixed by exec order," suggesting that a higher up at Apple is preventing engineers from fixing the problems.
"Supposedly" and "suggested" let Ars weasel out of determining the truth of these assertions. Unless Apple has suddenly turned absurdly transparent, I have a hard time believing that this guy actually has any inside knowledge. On the other hand, he certainly has an incentive to bring pressure on Apple to make his business work better.
But according to Matt Asay, who is vice president of business development for mobile Web framework maker Strobe, Apple supposedly has no plans to fix them. Instead, they are marked "not to be fixed by exec order," suggesting that a higher up at Apple is preventing engineers from fixing the problems.
"Supposedly" and "suggested" let Ars weasel out of determining the truth of these assertions. Unless Apple has suddenly turned absurdly transparent, I have a hard time believing that this guy actually has any inside knowledge. On the other hand, he certainly has an incentive to bring pressure on Apple to make his business work better.
AFAIK strobe is made up mostly of ex-apple people - furthermore, they knew about the "bugs" at least a month ago - Charles Jolley was talking about them at the most recent sproutcore nyc meetup. I don't think it's unreasonable to believe the truth of these assertions.
I don't see how these two points are mutually exclusive.
It very well could be an executive order not fix it because of the security issue.
It very well could be an executive order not fix it because of the security issue.
The problem is that if the issue never gets fixed then native apps using a webview will never see this performance improvement. Which means in order to stay competitive Apple must continue to develop nitro. Which means they'll either develop nitro in parallel with the old JS engine, or they'll let the webview stagnate. Marking an issue as "dont fix" is very scary indeed for the web on iOS.
If they're indeed marked "don't fix", that's probably because they are intentional. They aren't bugs.
[deleted]
It seems like there might be some justification for restricting Nitro from UIWebView because then you have to trust a third party app... but a webapp launched from the home screen is completely controlled by Apple's apps just like if you launched it from Safari (except less annoying). Surely these home page webapps can be treated just like Safari?
<cynical>Unless, of course, you want to discourage their development</cynical>
<cynical>Unless, of course, you want to discourage their development</cynical>
> but a webapp launched from the home screen is completely controlled by Apple's apps just like if you launched it from Safari
Not quite. In essence, a native app using UIWebView is created on the fly, and past that point it acts just like a standalone app. Only real-deal Safari gets the exception.
Not quite. In essence, a native app using UIWebView is created on the fly, and past that point it acts just like a standalone app. Only real-deal Safari gets the exception.
ok, but it's created by iOS so surely can be trusted just like Safari?
The thing is, and I believe Gruber himself has pointed this out regarding Microsoft's past transgressions, you don't need a Simpsons style committee of evil for this stuff to happen. You just need a normal corporation filled with employees smart enough to know what's in the financial interests of their employer, and that sticking to those interests aids their own career progression.
Bugs and difficult to solve issues arise in all sorts of code. Just by prioritising what you work on and fix you can hose your competitors both within or outside your ecosystem. In this case, extra speed for Mobile Safari was clearly more important to Apple than extra speed for mobile apps that compete with their native apps.
Bugs and difficult to solve issues arise in all sorts of code. Just by prioritising what you work on and fix you can hose your competitors both within or outside your ecosystem. In this case, extra speed for Mobile Safari was clearly more important to Apple than extra speed for mobile apps that compete with their native apps.
This is a design issue that is basically unsolvable unless Apple fully rethinks the iOS security model. In the current model, you can't give a library separate permissions than the process in which it was loaded - that's the gist of it. This has nothing whatsoever to do with Security as Gruber is spinning it to be - not directly at the least. As with Flash the real reason seems to be bypassing control.
I suspect RIM's security model allows them to do package / API specific permissions and prevent the app from doing things such as mmap(... PROT_EXEC) - anyone familiar with BB Security/Permissions model - care to comment?
I suspect RIM's security model allows them to do package / API specific permissions and prevent the app from doing things such as mmap(... PROT_EXEC) - anyone familiar with BB Security/Permissions model - care to comment?
But why is it a good idea to have a saver web view outside of Safari when Safari remains wide open?
Maybe they think that people are aware that the web is generally less safe and act accordingly? And they don‘t want someone to smuggle that unsafeness into apps? (The homescreen webapps are more or less just collateral damage if you take on this view.) That’s the only somewhat plausible explanation I can think of and it doesn’t make all that much sense.
Maybe they think that people are aware that the web is generally less safe and act accordingly? And they don‘t want someone to smuggle that unsafeness into apps? (The homescreen webapps are more or less just collateral damage if you take on this view.) That’s the only somewhat plausible explanation I can think of and it doesn’t make all that much sense.
Maybe the problem is that Nitro requires that an app have special permission to mark pages as executable. Apple may be comfortable giving this permission to Safari (or any if their apps, for that matter) but not comfortable giving it to third party apps. Along the same lines, it could be that apps saved to the home screen don't get Nitro because there is a special exemption low in the system for Safari, and they haven't yet worked out how to roll it out to the thin apps that are created when you save something to the home screen.
As someone who pulls this system apart constantly: this comment is dead on accurate.
Because if I write an app for iOS, I can't mess with Safari's address space. But if I have a UIWebView in my address space and I can use it to get a hold of memory pages with their executable bits marked, I could use that to do all manner of things that are normally forbidden.
Then why not allow at the home screen web apps to use Nitro? The entire app is within the UIWebView and controls nothing outside of it. I fail to see how a home screen web app is any different than one within MobileSafari.
That's a reasonable question, and for all we know, the failure of Nitro in that use case may well be a bug.
[deleted]
To say that Apple does not allow writable executable pages for security reasons is to ignore the bigger reason Apple does not allow modifiable code: Apple does not want apps to have writable executable pages because then an app could implement an app store.
This is such a ridiculous argument, and Gruber chooses to lead with it. So, according to Gruber, if 10 years from now everything else on iOS got crazy faster (including Mobile Safari), but web apps on the home screen remained the same speed as they do today, then Apple still wouldn't be hampering them. How can anyone even read the rest of the article after this?
But, if we do, we find the security argument is equally frivolous when it comes to home-screen web apps. There is nothing less secure about a home screen app (which is just a glorified bookmark) than MobileSafari. MobileSafari is connected to the web, which means they're already allowing anything access to Nitro. If anything, there would be a much better argument for ONLY allowing home-screen web apps, because the user is implicitly stating they trust it more (than any random page you might be redirected to).
Beyond all this, I am willing to believe the "hey, it'll come with time" argument. But we should just say that, not bend over backwards to manifest false reasons.