11 ms·

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 c

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

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