<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><DIV><DIV><DIV><DIV>Okay.. a few points:</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Q. is an XSS worm on the way?</DIV><DIV>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.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Q. Only on the same host? I.e. - will you only be able to access the interface through 127.0.0.1?</DIV><DIV>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.)</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Q. javascript? on a phone? Isn't that going to suck down the power?</DIV><DIV>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.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Q. Did you just say you're going to put CORBA on my beautiful phone?</DIV><DIV>A. No. I was just using it as an example. &lt;soapbox&gt;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!&lt;/soapbox&gt;</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>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.)</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Q. Widgets. Why is it always Widgets?</DIV><DIV>A. Yes. I like widgets. jowles won't be a widget infrastructure, but 003, it's successor will be.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>On Apr 16, 2007, at 12:47 PM, Frank Coenen wrote:</DIV><BR class="Apple-interchange-newline"><BLOCKQUOTE type="cite">I agree. I don't fancy giving any acces to the phone from a remote location. Exept via SSH or something.<BR><BR>Locally 'installed' web-apps would be great though.<BR>http + CSS + javascript = widgets. (think of the Vista Gadgets, OSX and iPhone widgets, SuperKaramba) <BR>http + CSS + Javascript + some kind of plug-in that has excess to the phones hardware = widgets on steroids.<BR>Making it much easier to write applications (widgets) with exotic interfaces, you're no longer tied to OpenMoko/GTK+ toolkit. <BR><BR>It will of course drain more recourse's than native code, in stead of run time stuff like javascript.<BR><BR><BR><DIV><SPAN class="gmail_quote">On 4/16/07, <B class="gmail_sendername">Frank Coenen</B> &lt;<A href="mailto:franknstein666@gmail.com"> franknstein666@gmail.com</A>&gt; wrote:</SPAN><BLOCKQUOTE class="gmail_quote" style="margin-top: 0; margin-right: 0; margin-bottom: 0; margin-left: 0; margin-left: 0.80ex; border-left-color: #cccccc; border-left-width: 1px; border-left-style: solid; padding-left: 1ex"> I agree. I don't fancy giving any acces to the phone from a remote location. Exept via SSH or something.<BR><BR>Locally 'installed' web-apps would be great though.<BR>http + CSS + javascript = widgets. (think of the Vista Gadgets, OSX and iPhone widgets, SuperKaramba) <BR>http + CSS + Javascript + some kind of plug-in that has excess to the phones hardware = widgets on steroids.<BR>Making it much easier to write applications (widgets) with exotic interfaces, you're no longer tied to OpenMoko/GTK+ toolkit. <BR><BR>It will of course drain more recourse's than native code, in stead of run time stuff like javascript. <BR><BR><DIV><DIV><SPAN class="e" id="q_111fbeb09ed9b703_1"><SPAN class="gmail_quote">On 4/16/07, <B class="gmail_sendername"> Florent THIERY</B> &lt;<A href="mailto:fthiery@gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> fthiery@gmail.com</A>&gt; wrote:</SPAN></SPAN></DIV><BLOCKQUOTE class="gmail_quote" style="margin-top: 0; margin-right: 0; margin-bottom: 0; margin-left: 0; margin-left: 0.80ex; border-left-color: #cccccc; border-left-width: 1px; border-left-style: solid; padding-left: 1ex"> <DIV><SPAN class="e" id="q_111fbeb09ed9b703_3"> 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? <BR> <BR>Quite frightening in terms of security... An XSS dialer worm on it's way? :)  <BR><BR><BR>Cheers<BR><SPAN><BR>Florent<BR></SPAN><BR></SPAN></DIV><SPAN class="q">_______________________________________________<BR>OpenMoko community mailing list <BR><A href="mailto:community@lists.openmoko.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> community@lists.openmoko.org</A><BR><A href="http://lists.openmoko.org/mailman/listinfo/community" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> http://lists.openmoko.org/mailman/listinfo/community </A><BR><BR></SPAN></BLOCKQUOTE></DIV><BR></BLOCKQUOTE></DIV><BR><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">_______________________________________________</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">OpenMoko community mailing list</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><A href="mailto:community@lists.openmoko.org">community@lists.openmoko.org</A></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><A href="http://lists.openmoko.org/mailman/listinfo/community">http://lists.openmoko.org/mailman/listinfo/community</A></DIV> </BLOCKQUOTE></DIV><BR></DIV></DIV></BODY></HTML>