5 ms·

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 a

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.
  - Someone 16y ago
    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 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.
  - bandushrew 16y ago
    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.
ynniv 16y ago
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.
- tolmasky 16y ago
  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.
  - bandushrew 16y ago
    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.
    - detst 16y ago
      "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.
      - bandushrew 16y ago
        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....
raganwald 16y ago
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...
- boucher 16y ago
  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.
  - bandushrew 16y ago
    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."
- tolmasky 16y ago
  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...".
ra88it 16y ago
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.
- boucher 16y ago
  2) They didn't release it, one imagines, because it is hardware specific, and originally written for x86 not ARM.
  - ra88it 16y ago
    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?
    - deleted 16y ago
      [deleted]
    - tolmasky 16y ago
      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 http://news.ycombinator.com/item?id=2338724

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.
- Someone 16y ago
  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 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.
- bandushrew 16y ago
  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.

ynniv 16y ago

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.

tolmasky 16y ago
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.
- bandushrew 16y ago
  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.
  - detst 16y ago
    "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.
    - bandushrew 16y ago
      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....

raganwald 16y ago

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

boucher 16y ago
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.
- bandushrew 16y ago
  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."
tolmasky 16y ago
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...".

ra88it 16y ago

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.

boucher 16y ago
2) They didn't release it, one imagines, because it is hardware specific, and originally written for x86 not ARM.
- ra88it 16y ago
  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?
  - deleted 16y ago
    [deleted]
  - tolmasky 16y ago
    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 http://news.ycombinator.com/item?id=2338724