Re: Securing and taming an existing language

There are three documents about taming javascript and the document
object model (DOM) here:
   https://code.google.com/p/google-caja/source/browse/#svn/branches/es53/doc/domado
"DOMado" is a pun: the word means "tamed" in Spanish.

On Tue, Feb 24, 2015 at 9:29 AM, Marc Stiegler <[email protected]> wrote:
> For a taste of taming, the taming of the OCaml library for Emily is quite
> small and simple, see a very brief description of it at
> http://www.hpl.hp.com/techreports/2006/HPL-2006-116.pdf
>
> But the taming effort that is really informative is the one we did for E. I
> have been told by a couple of people that they really came to understand
> what taming was about by reading the tables supplied with E that specify
> which methods and constructors are allowed, and which are disallowed. Markm
> can tell you where to look to see that list. YMMV.
>
> --marcs
>
> On Mon, Feb 23, 2015 at 1:45 PM, Mark S. Miller <[email protected]> wrote:
>>
>>
>>
>> On Mon, Feb 23, 2015 at 10:41 AM, Bruce Mitchener
>> <[email protected]> wrote:
>>>
>>> Hopefully this is the right list for this question or set of questions
>>> ...
>>>
>>> I help maintain the Dylan language, http://opendylan.org/.  It is similar
>>> to Scheme, but with a CLOS-style object system, and was originally designed
>>> by various Common Lisp folks at Apple, CMU and Harlequin in the early 1990s.
>>>
>>> I'm interested in seeing what we could do to become friendly to object
>>> capabilities.
>>
>>
>> Awesome! I remember Dylan fondly.
>>
>>>
>>>
>>> I've following along with E over the last 17 years off and on and some of
>>> the other efforts. I've read the slides for
>>> http://dynamic-languages-symposium.org/dls-07/program/media/MarkMiller_2007_TradeoffsInRetrofittingSecurityAnExperienceReport_Dls.pdf
>>> ... I've also skimmed the paper on taming Pict
>>>
>>> I'm curious if there's a good place to start reading for how to:
>>>
>>> 1) subset a language to remove ambient authority
>>> 2) tame unprincipled libraries
>>>
>>> I realize that these are big, complicated tasks, but I'd like to evaluate
>>> whether or not this is a feasible direction for Dylan to move in.
>>
>>
>> We've now done this successfully a number of times, for very different
>> languages and libraries
>> <http://wiki.erights.org/wiki/Object-capability_languages>, so we should
>> more concrete lessons we could write down as a record independent of any one
>> of these efforts. I'm embarrassed to say that we have not made any such
>> record -- it is all folklore and experience, transmitted through
>> conversation. Where are you located (feel free to respond privately to
>> [email protected])? It would probably be good to assemble a group together
>> for such conversations.
>>
>>
>>>
>>>
>>> Along with the usual issues, Dylan has another interesting complication
>>> in that it is using the CLOS model of OO which is very different from that
>>> of Java, Smalltalk and C++. In the CLOS model, multiple dispatch is used and
>>> the methods (generic functions) don't "belong" to objects or classes. (It
>>> isn't really a message-passing OO.)
>>>
>>> Has there been any consideration of that sort of object system and model
>>> in the past with respect to object capabilities?
>>
>>
>> For CLOS itself, I'd say it is rather hopeless. But IIRC, Dylan has a
>> module system that forms an encapsulated scope, similar to Java's package
>> scope. Does this, or can this, for a basis for secure encapsulation? If so,
>> there's an implicit rights amplification hazard that can lead to confused
>> deputies, but not in a way that's necessarily fatal. I would start from
>> there.
>>
>> --
>>     Cheers,
>>     --MarkM
>>
>> _______________________________________________
>> e-lang mailing list
>> [email protected]
>> http://www.eros-os.org/mailman/listinfo/e-lang
>>
>
>
> _______________________________________________
> e-lang mailing list
> [email protected]
> http://www.eros-os.org/mailman/listinfo/e-lang
>



-- 
Mike Stay - [email protected]
http://www.cs.auckland.ac.nz/~mike
http://reperiendi.wordpress.com