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

[Mark Miller]

[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