[General] P2P network security vs browser client security was: [Ann] Lively kernel 0.8 is out!

[ALT Mobile DEV]

Hi Mark,

thank you for your insight. It's always a pleasure to learn  
alternative view points. My comments are embedded:


--Zaid

ALT Mobile

http://altmobile.com/Home.html (web site)
http://web.mac.com/altmobile (official blog)



On Feb 7, 2008, at 2:13 AM, Mark Miller wrote:

> On Feb 6, 2008 5:44 PM, ALT Mobile DEV <dev at altmobile.com> wrote:
>> I think that there may be some confusion as to the intent of LK...
>> perhaps mine. Despite Dan's hallowed past, LK does not intend to
>> create a new runtime/VM. LK's stated intent is to program the browser
>> using the browser's environment sans plug-ins (if possible). "Zero"  
>> as
>> in zero install. So that's the browser's JavaScript with a few 3rd
>> party libraries such as Prototype.
>
> Hi Zaid,
>
> I believe we have the same understanding, but there may be a minor
> terminology issue. Certainly, LK seeks zero install, and using the
> browser environment as is sans plugins, just as you say. Caja also
> seeks these attributes.
>
> However, it may be more slippery than it appears whether either LK,
> Caja, or indeed any comprehensive JS library constitutes a new
> runtime/VM. All create a new programmable level of abstraction on top
> that provided by the browser. To the extent that this new level of
> abstraction seems self contained, so that one can use it without a
> detailed understanding of how it is mapped onto the browser's
> platform, it does, in effect, a new platform/runtime/VM. But whether
> or not LK or Caja should be described in this way, both LK and Caja
> would benefit if LK were written in the Caja-compliant subset of
> JavaScript.
>

[ZAID] I apologize... I disagree with this premise because LK is by  
definition not a sealed environment where apps are "certified" like in  
the mobile world. LK requires Prototype and even if it didn't, a  
developer can use all of JavaScript at anytime to manipulate most of  
LK. Unless LK implemented some type of defensive programming in each  
of its APIs-- and somehow was able to stop direct manipulation of the  
SVG and JavaScript objects--  isn't this just making LK into a  
security R&D prototype with no possible commercial viability?

I honestly believe that a more pressing security and feature issue for  
the LK team is centered around networking and cross-domain support. I  
just announced on Tuesday our Dynamic Mashup Server as part of our  
support for the Comet (HTTP Streaming/Push) implementation done by Sun  
in Grizzly. What I didn't mention in the press release is that I built/ 
tested the functionality against LK clients. What that means is that  
any LK client can be updated/synchronized from a Dynamic Mashup Server  
en-mass. So with the new LK serialization capability we can have  
scalable shared sub-worlds across the internet.


But as you know, the paramount issue in this is the same origin server  
issue and trusting the server. Cross-domain support has been solved on  
the client in Flash, Opera Widgets, and will be addressed in FireFox 3  
(and HTML5).  It's good that Stephen Uhler  is associated with the LK  
team since he did an interesting proxy implementation in Brazil.


So what will LK do? go the Flash or Java Applet route? create a web  
server plug-in? use Apache's solution? implement that proxy back door  
server that was in the LK .7 code? Or just skip shared worlds because  
they introduce a whole range of network security issues far more than  
just browser programming.

If the LK team doesn't get this write, then only trivial network apps  
will be written for LK because confidential or personal information  
(aka social apps) will not be shared because they do not trust the LK  
server. If the LK team implements dynamic, state-full inspection and  
verification during sub-world sharing using Caja-like technology, then  
that's where LK becomes more than just a single user or small-group  
JavaScript and SVG programming environment.


So, I would like you to consider that maybe getting the network  
security model done correctly is more important than ensuring that LK  
itself and personal morphlets are secure. So my vote is to secure on  
sharing sub-worlds to deny XSS and script injection, etc. but not the  
execution within the browser.


>
>> Please correct me if I'm wrong but the most successful implementation
>> of Caja is on Google's servers to provide a sandboxed runtime for
>> widget/gadget execution. The Apache implementation seems to follow
>> this server-side pre-processing approach.
>
> You are completely correct today, and you are mostly correct for the
> foreseeable future: The full Caja translator is written in Java, not
> JavaScript, and is too large to consider downloading to the browser.
> As a result, Caja itself cannot support the LK style of self-contained
> live programming environment within the browser *for Caja code*.
>
> To address these very kinds of concerns, we have defined a small
> subset of Caja called Cajita. Cajita is no less useful, expressive,
> convenient, or secure a programming language than Caja. However, it
> leaves out so much of JavaScript that one would only recommend it for
> new code. Caja is a much larger subset of JavaScript in order to be
> friendlier to old JavaScript code. Cajita is sufficiently small that
> we expect to port the Cajita->JavaScript portion of the translator
> into Cajita, in which case we can support live programming (and eval)
> of Cajita code safely, purely within the browser.
>
>

[ZAID] I think we agree if by "support live programming (and eval)"  
only refers to remote sub-worlds/morphlets and whatever is the unit of  
transmission/sharing.


>> So unlike in the Smalltalk and Java worlds where you build almost
>> everything from scratch, LK has to rely on other technologies for its
>> success since at it's core LK is just a JavaScript library with an  
>> SVG
>> UI toolkit (and some cool networking stuff in the future).
>
> Of these other technologies, how much of their code could be within
> the scope of LK's browser system, and subject to live reprogramming?
> Within the constraints of the existing browser platform, I think the
> answer must be essentially none. The code that appears in LK's
> browsers will almost all be new code anyway. Were the code in LK's
> browsers in Cajita, and were we to realize our fantasy of a
> browser-side Cajita translator, then the LK browsers could eval it
> live, as LK currently does for JS code. Since Cajita (like Caja) is a
> subset of JavaScript, this can be explored today, without waiting for
> Cajita to be ready.
>
>

[ZAID] sure, but to what aim? A limited availability security  
prototype? LK can accomplish far more and can solve the security issue  
on sharing sub-worlds/morphlets because when LK goes P2P (peer-to- 
peer) via an LK server you're really introducing unknown live code.  
The normal LK code is coming from a server to which you contacted  
since that's the normal web browser-to-server client-server stuff.

P2P LK is the only new aspect that needs to be secured IMO. But the LK  
team will decide according to its SunLabs mandate.


I would also like you to consider implementing Caja in Single-Site  
Browsers (SSB) such as Mozilla Prism and Todd Ditchendorf's WebKit  
implementation of the SSB concept. First, they make wickedly fast LK  
clients. We call them the ultimate mash-up client because they are  
built to support browsing a single site or mash-up and can't interact  
with other sites. So in this context, Caja moves the browser into a  
really secure platform. . Fast and secure.


>> I'd appreciate any corrections to my understanding of LK and Caja
>> since as a mash-up vendor we are exploring Caja's potential and are
>> already developing for LK.
>
> Glad to hear it; both are wonderful news!
>
>
>> thanks for making this an open forum.
>
> You are quite welcome. Openness is always my first choice.
>

[ZAID] thanks again for the opportunity to correspond with you and I  
think that my opposition is to when and where we enforce security:  
constantly in the browser or on the server only when sharing among  
strangers.

> -- 
> Text by me above is hereby placed in the public domain
>
>    Cheers,
>    --MarkM