
Why the Nitro JavaScript Engine Isn’t Available to Other iOS Apps - danilocampos
http://daringfireball.net/2011/03/nitro_ios_43
======
tolmasky
_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.

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

~~~
tolmasky
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...".

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

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

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

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

~~~
joezydeco
Not just bypassing code signing, but the App Store approval process
altogether?

~~~
saurik
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)

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

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

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

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

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

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

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

------
blinkingled
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?

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

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

~~~
saurik
As someone who pulls this system apart constantly: this comment is dead on
accurate.

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

