OpenMoko light web server

[Matthew S. Hamrick]

Okay.. a few points:

Q. is an XSS worm on the way?
A. not unless you make your interface susceptible to known web app  
vulnerabilities: XSS, SQL Injection, session hijacking, etc. Of  
course, it's very hard to disprove the existence of a vulnerability,  
but I can say what I'm doing to prevent it. 1) I'm going to run my  
code through an automated scanner. I recommend these things to  
everyone. They're great in helping you spot overlooked  
vulnerabilities. 2) I'm going to use an XML Post interface where the  
client constructs XML and each message is MAC'ed. What I don't have  
working yet is the hash chain code to prevent replay attacks. But...  
I am thinking about it. This helps prevent XSS because I don't use  
cookies. XSS tends to require a cookie-based login/session paradigm.  
I suspect it's still possible for a bad guy to mail you some  
javascript that could be executed in the same browser after you've  
logged in, so I won't discount the possibility. But I have actually  
been thinking about the security of this thing.

Q. Only on the same host? I.e. - will you only be able to access the  
interface through 127.0.0.1?
A. Hey! Where's the fun in that! One of the things I would like to do  
is have a platform where we can experiment with new ways of thinking  
about mobile devices. If you're frightened by the security  
implications... well... there's nothing I can do about that. But...  
I'll tell you what... I'll ship everything with defaults setup to not  
allow remote connections (so you would have to ssh in to change this  
default.)

Q. javascript? on a phone? Isn't that going to suck down the power?
A. in a word, yes. But I think the main problem will not be the added  
overhead of using javascript, it's going to be the frequent request /  
response. In the old days when we bundled ORBs with browsers, we  
could execute java (and presumably have a javascript interface) that  
would receive asynchronous messages from the server. Why is this  
important? Because the phone (on the other side of the http  
interface) is going to ring or receive an sms message or the signal  
is going to go up or down. And these are things that occur outside  
the context of a client request. So, if you want to see if the phone  
just rang, you have to keep pinging the web server every second or  
so, and if it responds with "I'm ringing," you fire off the  
javascript that draws the "I'm ringing" icon on the interface. All in  
all this is pretty substandard.

Q. Did you just say you're going to put CORBA on my beautiful phone?
A. No. I was just using it as an example. <soapbox>Everyone has this  
idea that CORBA is big and blobular and fat. Well... if you implement  
every stinkin' feature, it is. But IIOP with a Java or Smalltalk BOA  
can be implemented fairly easily and without bloat. And it can be  
made reasonably secure with IIOP over TLS or CORBASec level 2 if  
you're a masochist. I would like to use CORBA on one of my devices,  
and I probably will. But every time I mention it, people who have  
never used it wretch violently and wax poetic about SOAP. No... I'm  
going to do something much worse than CORBA, I'm going to use RPC.  
No... not XML-RPC, honest to God XDL/Sun/No way to secure it RPC. So  
there!</soapbox>

Okay.... I'm better now. But seriously, I think the added complexity  
of forcing a request/response model on top of an application that  
clearly must require support for asynchronous events is the worst  
problem we're going to face. I've sorta thought that a custom  
application, and not a browser, will be the primary consumer of the  
XML generated by jowles or 003 (003 is a follow-on to jowles.) So we  
might be able to take a few liberties with HTTP. Like keeping the  
HTTP connection up between requests and allowing the server to send  
responses that aren't bound to requests when asynch events occur.  
It's a hack, and it will probably break the javascript version of the  
interface, but hey! it's probably better than trying to get everyone  
on the list to put their brain-stems around CORBA (or even SOAP.)

Q. Widgets. Why is it always Widgets?
A. Yes. I like widgets. jowles won't be a widget infrastructure, but  
003, it's successor will be.


On Apr 16, 2007, at 12:47 PM, Frank Coenen wrote:

> I agree. I don't fancy giving any acces to the phone from a remote  
> location. Exept via SSH or something.
>
> Locally 'installed' web-apps would be great though.
> http + CSS + javascript = widgets. (think of the Vista Gadgets, OSX  
> and iPhone widgets, SuperKaramba)
> http + CSS + Javascript + some kind of plug-in that has excess to  
> the phones hardware = widgets on steroids.
> Making it much easier to write applications (widgets) with exotic  
> interfaces, you're no longer tied to OpenMoko/GTK+ toolkit.
>
> It will of course drain more recourse's than native code, in stead  
> of run time stuff like javascript.
>
>
> On 4/16/07, Frank Coenen < franknstein666 at gmail.com> wrote:
> I agree. I don't fancy giving any acces to the phone from a remote  
> location. Exept via SSH or something.
>
> Locally 'installed' web-apps would be great though.
> http + CSS + javascript = widgets. (think of the Vista Gadgets, OSX  
> and iPhone widgets, SuperKaramba)
> http + CSS + Javascript + some kind of plug-in that has excess to  
> the phones hardware = widgets on steroids.
> Making it much easier to write applications (widgets) with exotic  
> interfaces, you're no longer tied to OpenMoko/GTK+ toolkit.
>
> It will of course drain more recourse's than native code, in stead  
> of run time stuff like javascript.
>
> On 4/16/07, Florent THIERY < fthiery at gmail.com> wrote:
> If the GUI is web-based, then we can mix offline and online apps at  
> will, transparently ! Yet, if you want a "sexy" interface, you'd  
> want to use AJAX, right?
>
> Quite frightening in terms of security... An XSS dialer worm on  
> it's way? :)
>
>
> Cheers
>
> Florent
>
> _______________________________________________
> OpenMoko community mailing list
> community at lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>
>
>
> _______________________________________________
> OpenMoko community mailing list
> community at lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openmoko.org/pipermail/community/attachments/20070416/e1c1712d/attachment.htm