[e-lang] [cap-talk] Initial draft Caja design doc

bryan rasmussen rasmussen.bryan at gmail.com
Sat Oct 13 03:56:55 EDT 2007

for an example of a powerbox examine Chickenfoot
I've suggested before that they should have  a means of providing
capabilities or at least sandboxing for the system. It was passed on
to firefox itself as an issue to provide user enabled sandboxing of
extensions and there I suppose died a quiet death - I know I don't
have the time to do it, and probably nobody will until it becomes an
actualized problem.

Bryan Rasmussen

On 10/13/07, Mark Miller <erights at gmail.com> wrote:
> [Narrowing down to just e-lang]
> Hi Jed, thanks for the comments! Mostly I reply simply by revising the
> text. Remaining issues below.
> On 10/12/07, Jed Donnelley <jed at nersc.gov> wrote:
> > I'll imagine passages -> content through out the
> > the rest of the paper and see if I notice any
> > problems. ... <I noticed a case where you use
> > the term 'content' somewhat separately, but
> > nothing that jumped out at me regarding a
> > real need for the 'passages' term.  I'd like
> > to hear a bit more justification for such a
> > new term.>
> But "content" is a mass noun, like "water" whose singlular refers to
> an indistinct quantity. I hate "passage" myself, but I would like a
> count noun whose singlular refers to an individual unit. Please keep
> the suggestions coming. Did I mention that I *hate* "passage"?
> > 4.  When you first note the "powerbox" term I think
> > it's fine to have the references, but I think at least
> > a parenthetical definition/description is needed.
> > E.g. 'an interface that can allow a user to introduce
> > access to objects into a least authority execution
> > environment that doesn't yet have access to them.'
> >
> > 5.  Hmmm.  If I've been understanding your use of
> > the colored numbers and arrows, then I think there is
> > an error in their use in the paragraph where you
> > introduce the 'powerbox' term (page 3 third paragraph).
> > In the sentence there, "A web app, on detecting the
> > presence of a powerbox, could offer to edit a local
> > file chosen by the user 2 -> 6.  Shouldn't that
> > be 3 -> 5?  That is, didn't you argue earlier that
> > web apps don't have access to local objects?
> Unless a browser extension makes a powerbox available to web apps.
> Unlike web apps, browser extensions do run with the user's full
> authority (at 2). A web app that detects that such a powerbox is
> present can, by asking the powerbox (to ask the user), obtain access
> to a local file (at 6).
> > I'm a bit
> > puzzled by "DOM and other APIs" being included above.
> The DOM is a substantial additional library provided by browsers. In
> order for Caja to enable safe active web content, we must specify a
> tamed form of this API. The present document deals only with the
> Javascript library speced in ES3, which doesn't include the DOM.
> > 7.  When on page #3 you say, "To facilitate
> > development, it is easy to write a Caja program
> > so it can run correctly whether it is run as a Caja
> > program or run directly as an untranslated Javascript
> > program."
> >
> > are you noting this more as a transition mechanism?
> Yes.
> > That is, that Caja programs can run with excess authority
> > when it is inappropriately given to them until the
> > execution environments are tightened?
> Yes.
> >  In that case
> > it might be worthwhile to note that such Caja programs
> > are not able to access that excess authority - as I
> > believe is the case if I'm understanding correctly.
> No. When a Caja program is run as an untranslated Javascript program,
> it has the full authority that Javascript programs running in that
> environment have, whatever that is.
> Once again, think of Caja as the "user mode" subset of the Javascript
> "instruction set". If you take a program that was allegedly written to
> run in user mode, but you run it in system mode instead, it might
> still work. But you should no longer assume it is running with reduced
> authority.
> > 7.  Regarding the OS/machine analogy - e.g. when you
> > say, "When a Caja object A invokes an object B
> > written directly in Javascript, the operations
> > provided by B serve the role of system calls."
> >
> > Doesn't this depend on the environment the Javascript
> > is running in?  I usually think of Javascript as
> > running in a browser sandbox.  In that case it seems
> > neither the Javascript object nor the Caja object
> > have access to any significant authority.
> The Javascript does indeed (typically) not have any authority that
> would conventionally be considered interesting, ushc as the local file
> system. However, Javascript running on my gmail page has the authority
> to delete my gmail inbox. The browser, by preventing the user from
> giving web apps local authority + preventing the user from being able
> to deny the web app the authority to call home, left the web apps no
> choice but to place their user's valuable assets on their site of
> origin. This is the point of the (3)->(4) transition. Regarding their
> ability to do what their user may do at this origin site, untranslated
> Javascript running in the browser sandbox on a web page has
> undiminished authority.
> > You mention the powerbox concept, but are there
> > means available for injecting, say, access to
> > a single local file into a sandboxed Javascript
> > environment with any sort of a powerbox?
> Yes. When you install a browser extension, you grant it all of your
> authority. It may then provide web apps whatever subset of this
> authority it wishes, such as the authority to edit an individual file.
> >  If so that would seem to me to provide most of the
> > value that web app programmers would like to have
> > in Javascript - regardless of the finer grained
> > mutual suspicion that you hope to be able to
> > provide with Caja.
> Both are valuable. Which one is "most" depends on what you value.
> >  If not (I haven't heard of
> > such a Javascript powerbox mechanism) then I
> > don't see how you can get access to local objects
> > into your global Javascript environment to that
> > access can be safely communicated between Caja
> > objects.  If you are proposing to provide such
> > a mechanism, I didn't see it.
> It won't be concretely proposed in this document. We should make that clear.
> Thanks!
> --
> Text by me above is hereby placed in the public domain
>     Cheers,
>     --MarkM
> _______________________________________________
> e-lang mailing list
> e-lang at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/e-lang

More information about the e-lang mailing list