A very sweet solution?

| Comments (3) | SYSSEC
It appears that at least initially the iPhone will not have instant messaging, though SMS will "look like" instant messaging (cf. bacon juice vs. lemonade). Because the iPhone is semi-extendable, people are working to close this gap. Unfortunately, since all you can do is write Web apps, this has some limitations. The most important of which is, well, let him tell it:

Log in with your AOL IM account. No data is logged, but all of your information does pass through my server. I am not harvesting any information. This app is server intensive, so I'm limiting sessions to 10 minutes for now.

Obviously, having all my IMs go through somebody's server is pretty weak. Yeah, yeah, I know. I should be using crypto, and I already trust AOL, etc., but that doesn't mean I want to bring another person I have to trust into the loop. Unless I've missed something, this is a pretty inherent limitation of the design decision to only let you write Webapps and to sandbox them in the usual Webapp way. It works fine as long as your goals are limited, but as soon as you want to write something that (for instance) is a generic network client, you're hosed.

Here's Steve Jobs from WWDC:

And so you can write amazing Web 2.0 and AJAX apps that look and behave exactly like apps on the iPhone, and these apps can integrate perfectly with iPhone services. They can make a call, check email, look up a location on Gmaps... don't worry about distribution, just put 'em on an internet server. They're easy to update, just update it on your server. They're secure, and they run securely sandboxed on the iPhone. And guess what, there's no SDK you need! You've got everything you need if you can write modern web apps...

It's probably worth taking the time to unpack the sandboxing issue a bit. The sandboxing used in Java (and Javascript) has two major purposes: (1) to stop the applet from being a threat to your computer and (2) to stop the applet from being a threat to your network. So, when Java won't let an applet write to the disk, that's protecting your computer. When it won't let you connect to anyone other than the originating host (the same origin policy), that's to stop your computer being used to attack other computers on the network. The classic example of this is some applet which you download to your computer (behind the firewall) and then connects to hosts which would be firewalled off from a host on the public Internet.

But of course, if you want to write a real app (an IM or mail client, say), connecting to hosts other than the one you downloaded from is an absolute necessity—unless, that is, you think it's really cool that when you download Exchange you can only send mail to people at Microsoft. So, the idea with sandboxing is that there are a large (surprisingly large, actually) class of tasks that don't need quite so much functionality and that you can then connect to sites that do those tasks without having to think "should I give this program the right to write files onto my disk". But it should also be clear that this isn't the only class of tasks that people want their software to perform. which is why people want to be able to load applications on their computers, even if that whole code signing thing didn't work out as well as we hoped. It's just that you want to have to take positive action before allowing a more powerful app onto your computer (or phone). To the extent to which 3rd party iPhone apps are restricted to the Webapp sandbox, the device is only marginally extensible and that's not really that sweet.

Next: what sort of sandboxing makes sense for a device of this type?


The sandboxing depends on the objective...

Since the objective is to allow the cellphone company to keep charging discrimatory pricing based on traffic intent (EG, ~80 Mb/$ for bulk best-effort data, but .2 Mb/$ for SMS messages which can actually be worse-than-best-effort), the same origin sandboxing is the perfect policy.

After all, an IM client, at 80 Mb/$ would really hurt the income of the phone company when they could have you sending SMS instead.

Its also why I'm NOT going to get an iPhone. Any device with that much CPU and communication should run a real SSH if I'm going to use it. Thanks to the "you can't install apps, period" policy, that is not going to happen.

[...] even if that whole code signing thing didn't work out as well as we hoped.
Whaddya mean "we", white man?

generic well cialis http://generic.20six.de >generic cialis states

Leave a comment