[General] [Ann] Lively kernel 0.8 is out!

[Mark Miller]

Dan, as you know, I'm eagerly looking forward to seeing a system that
brings together the strengths of our respective projects. We would
both like to see lightweight, interactively created active content
become as prevalent and easily shared as html text is today. As
section 2 <http://google-caja-discuss.googlegroups.com/web/caja-spec.pdf>
argues, I believe security problems have been the fatal flaw which
killed most previous attempts at active content. Caja gives us a basis
for addressing these security problems. Lively gives authors a medium
for creating active content worth sharing.

However, your recent message has me concerned that Lively is deviating
ever farther from programming patterns that can be secured. Before
making these changes, what thought was given to their possible
compatibility with object-capability security?


On Feb 1, 2008 12:59 PM, Dan Ingalls <Daniel.Ingalls at sun.com> wrote:
> 1.  The entire Morphic architecture has been converted to wrap host
> SVG objects instead of extending them.  This was done in such a way
> as to change almost nothing at the level of most applications.  The
> major benefit afforded by this change is compatibility, since many
> JavaScript implementations do not support the ability to extend host
> objects.

Good. The Caja effort has made the same decision regarding DOM and
other conventional browser host objects.


> 2.  We have adopted a class system derived from prototype.js ver 1.60
> and extended with built-in support for serialization and copy
> constructors.  These conventions make it much more natural to use
> classes and class inheritance in JavaScript (the .subclass() method
> and $super optional parameter).

The Caja group has been puzzling over the extent to which Caja can
support the programming patterns that Prototype encourages. Our
conclusions so far are that Class.addMethods can't be rescued, and
that Object.extend is problematic at best. OTOH, Figures 7 and 8 of
<http://google-caja-discuss.googlegroups.com/web/caja-spec.pdf> show
the recommended Cajita inheritance pattern which seems to have all the
virtues of Smalltalk's, including even a proper "super", while
remaining friendly to object-capability principles. See also Figures
14 and 15 for an inheritance pattern that's more familiar to
JavaScript programmers, still Smalltalk-like, and adequately friendly
to object-capability principles.


> 6.  We have the beginnings of a reflective model for execution state.
> If one sets Config.debugExtras = true, most methods are wrapped with
> a function that keeps track of the stack with method names *and* even
> the arguments.  This can be tested by, eg, typing
>         Function.showStack()
> in any textMorph, selecting it and evaluating it with alt-d.  This
> should result in the stack being printed to the console with method
> names and argument values.

Are you thereby providing ambient access to the ability to reflect on
one's caller? What security properties do you imagine might survive
the availability of such an operation?

As you heard me say at OOPSLA, Squeak-E failed because Smalltalk code
was not facing a hostile environment, so the Smalltalk community never
became willing to sacrifice anything else they value for the sake of
security. I have no argument with that. If that's the right tradeoff
for Lively, fine. But please make the choice with your eyes open.

-- 
Text by me above is hereby placed in the public domain

    Cheers,
    --MarkM