[cap-talk] [e-lang] Initial draft Caja design doc
Jed Donnelley
jed at nersc.gov
Wed Oct 17 17:24:42 EDT 2007
On 10/12/2007 5:22 PM, Mark Miller wrote:
> [Narrowing down to just e-lang]
Ah, the above messed me up a bit. I was expecting to see a
reply on cap-talk. Sorry to say that I don't follow e-lang
all that actively and in particular don't see it at home.
I knew you were vitally interested in the Caja project MarkM,
so I was surprised not to see a response from you. Finally
I thought to check last night in the e-lang archive and found
your message (below).
I'll respond fully on e-lang, though I do think this discussion,
certainly some aspects of it, would also interest cap-talk'ers.
> Hi Jed, thanks for the comments! Mostly I reply simply by revising the
> text. Remaining issues below.
<I'll just leave the remaining untouched for cap-talk'ers
and I'll respond on e-lang as per your apparent preference
MarkM. I guess I'll have to subscribe to e-lang from home>
> 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!
>
More information about the cap-talk
mailing list