5 ms·

Why the Nitro JavaScript Engine Isn’t Available to Other iOS Apps

65 points by danilocampos 16y ago

aphyr 16y ago
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.
- deleted 16y ago
  [deleted]
- danilocampos 16y ago
  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.
  - kanja 16y ago
    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.
- sammcd 16y ago
  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.
  - Me1000 16y ago
    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.
- ra88it 16y ago
  If they're indeed marked "don't fix", that's probably because they are intentional. They aren't bugs.
stephenjudkins 16y ago
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.
- tjogin 16y ago
  So, even if he's right, he's wrong?
  - stephenjudkins 16y ago
    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.
  - abraham 16y ago
    A broken analog clock is only right twice a day.
- spamizbad 16y ago
  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.
  - bigiain 16y ago
    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...
ugh 16y ago
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.
- msbarnett 16y ago
  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.
  - jevinskie 16y ago
    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.
    - msbarnett 16y ago
      That's a reasonable question, and for all we know, the failure of Nitro in that use case may well be a bug.
- brownleej 16y ago
  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.
deleted 16y ago
[deleted]
tolmasky 16y ago
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. 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.
- bandushrew 16y ago
  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.
  - bandushrew 16y ago
    Edit: yay! you changed your post while I wrote mine.
  - tolmasky 16y ago
    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.
hopeless 16y ago
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>
- lukifer 16y ago
  > 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.
  - hopeless 16y ago
    ok, but it's created by iOS so surely can be trusted just like Safari?
ZeroGravitas 16y ago
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.
zmmmmm 16y ago
What really disturbs me is not the nitro JS performance part but this (from the register article): 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. I can live with my app being a little slower; after all, I don't really even contemplate writing performance sensitive apps as off line web apps anyway. I can NOT live with my apps not working, being unreliable, or taking ages to load because the user went through a tunnel or tried to use it on a plane. 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.
- wzdd 16y ago
  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.
  - zmmmmm 16y ago
    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.
- saurik 16y ago
  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.
blinkingled 16y ago
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?
mcculley 16y ago
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.

65 points by danilocampos 16y ago

aphyr 16y ago

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.

deleted 16y ago
[deleted]
danilocampos 16y ago
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.
- kanja 16y ago
  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.
sammcd 16y ago
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.
- Me1000 16y ago
  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.
ra88it 16y ago
If they're indeed marked "don't fix", that's probably because they are intentional. They aren't bugs.

stephenjudkins 16y ago

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.

tjogin 16y ago
So, even if he's right, he's wrong?
- stephenjudkins 16y ago
  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.
- abraham 16y ago
  A broken analog clock is only right twice a day.
spamizbad 16y ago
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.
- bigiain 16y ago
  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...

ugh 16y ago

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.

msbarnett 16y ago
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.
- jevinskie 16y ago
  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.
  - msbarnett 16y ago
    That's a reasonable question, and for all we know, the failure of Nitro in that use case may well be a bug.
brownleej 16y ago
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.

deleted 16y ago

[deleted]

tolmasky 16y ago

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. 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.

bandushrew 16y ago
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.
- bandushrew 16y ago
  Edit: yay! you changed your post while I wrote mine.
- tolmasky 16y ago
  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.

hopeless 16y ago

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>

lukifer 16y ago
> 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.
- hopeless 16y ago
  ok, but it's created by iOS so surely can be trusted just like Safari?

ZeroGravitas 16y ago

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.

zmmmmm 16y ago

What really disturbs me is not the nitro JS performance part but this (from the register article): 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. I can live with my app being a little slower; after all, I don't really even contemplate writing performance sensitive apps as off line web apps anyway. I can NOT live with my apps not working, being unreliable, or taking ages to load because the user went through a tunnel or tried to use it on a plane. 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.

wzdd 16y ago
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.
- zmmmmm 16y ago
  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.
saurik 16y ago
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.

blinkingled 16y ago

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?

mcculley 16y ago

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.