[General] P2P network security vs browser client security was: [Ann] Lively kernel 0.8 is out!
ALT Mobile DEV
dev at altmobile.com
Thu Feb 7 11:50:39 CET 2008
thank you for your insight. It's always a pleasure to learn
alternative view points. My comments are embedded:
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"
>> 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
[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
LK. Unless LK implemented some type of defensive programming in each
of its APIs-- and somehow was able to stop direct manipulation of the
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
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
> 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
> 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
>> So unlike in the Smalltalk and Java worlds where you build almost
>> everything from scratch, LK has to rely on other technologies for its
>> 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
> 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
> Text by me above is hereby placed in the public domain
More information about the lively-kernel