[e-lang] Invited talk: Tradeoffs in Retrofitting Security: An Experience Report

[Mark Miller]

I have been invited to give a talk at this years Dynamic Languages
Symposium <http://www.swa.hpi.uni-potsdam.de/dls07/>, co-located with
OOPSLA 2007.

Together, we've now learned enough from our various attempts at
retrofitting ocap security into existing memory-safe languages. Rather
than talk about work I've been directly involved in, I thought instead
I'd try to summarize the work of our community, and summarize some of
the lessons we've learned.


Tradeoffs in Retrofitting Security: An Experience Report

In 1973, John Reynold's and James Morris' Gedanken Language retrofit
object-capability security into an Algol-like language. Today, there
are active projects retrofitting Java, Javascript, Python, Mozart/Oz,
OCaml, Perl, and Pict. These represent a variety of approaches, with
different tradeoffs regarding legacy compatibility, safety, and
expressivity. In this talk I propose a taxonomy of these approaches,
and discuss some of the lessons learned to date.



Note that my mention of Javascript is hopeful. I expect we will have
progress on this front to talk about by then.

I hope representatives of most of the active efforts are available
here on e-lang and interested in refining a mutually agreed taxonomy
of approaches. Perhaps it would be good to use our wiki for the
process?

Simply to get the ball rolling, here's a proposed start:

Object granularity, static verification, library import taming, new
library wrappers
    Joe-E, Emily, Backwater?

Object granularity, dynamic sandboxing by scope manipulation, library
virtualization
    W7, CaPerl?

Language-engine granularity, platform sandboxing, virtualizing
per-sandbox ambient authorities
   J-Kernel (& Java Isolates?), Brett's Python work, anticipated
Javascript work?

New design & engineering, but similar in spirit
   Gedanken, E, Oz-E, Squeak-E? / Tweak Islands?

Anyone have any idea how Oleg & Shan's "lightweight static
capabilities" relate? Is this just use of ocap ideas in a non-ocap
language, or can these be used somehow to turn their base language (ML
& Haskell) into an ocap language by using their type systems?

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

    Cheers,
    --MarkM