[cap-talk] Initial draft Caja design doc

[Jed Donnelley]

On 10/11/2007 6:41 PM, Mark Miller wrote:
> Caja is hereby open source under the Apache license 2.0.
> 
> The Caja development site is at
> http://code.google.com/p/google-caja/

I chose to start with this:

> The initial draft design doc is at
> http://google-caja.googlecode.com/files/caja-spec-2007-10-11.pdf
> At the moment, much of the substance appears only in the tables in the
> back, sorry.

Here are some comments as I read:

1.  Not surprisingly I like the introduction up to the
paragraph that starts (pg. 2):
_________
Web apps leverage this success. To the browser,
the page on which a web app resides is a document,
and the web app itself is simply active content within
that document. But to the user, a web app is an ap-
plication managing yet other documents on the user's
behalf. For example, when the user interacts with
webmail, the documents of interest are email mes-
sages. Likewise for groups, blogs, chat, docs and
spreadsheets, wikis, and more.
_________

Then you define this term "passages":

"Let us refer to the documents managed by web apps
as 'passages', to distinguish them from the web pages
on which they appear."

I think I can understand the bind you are in there.
However, "passages"??

What about just "content".  "Content" seems to me
a vague enough term that it would suffice without
having to introduce a term like "passages" that seems
to me likely to result in more confusion.

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.>

2.  I'd suggest describing your choice of the name
'Caja' (box in Spanish, etc.) at least briefly when
you first introduce the name.  That would give people
a greater likelihood of remembering it.  I also think
you should provide some pronunciation guidance
when you introduce the 'Caja' term (e.g.
"Kaha" as with Baja - if that's really it).

3.  By the time I got to the third page I think I'd
come to understand your use of the colored/numbered
circles with the arrows between them.  I think this
could use a bit of explaining up front when you
introduce the figure (which I like).  Something like
saying, "In the remainder of the paper we refer to
the various architectural mechanisms for authority
using the numbers above.  We reference mechanisms
that can drive architectures from one area of the
above graph to another as with the arrows above,
e.g. 4 -> 3, 4 -> 5, 3 -> 5, etc."

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?  In
that sense they have inadequate authority.  Wouldn't
the powerbox in that case allow them to move close
to least authority 3 -> 5??  I think this relates
to my "overall" comments at the end - possibly I'm
not understanding something here.

6.  You introduce, "Other documents will explain Caja's
sanitization of the remaining elements of active web
content: HTML, CSS, and the DOM and other APIs provided
by browsers to Javascript. We refer collectively to the
subset of these accepted by the Caja translator as Caja
web content."

Might this be Caja's web "passage"s?  As I suggested,
I prefer the 'content' term throughout.  I'm a bit
puzzled by "DOM and other APIs" being included above.
How do such APIs fit as content/passages?

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?
That is, that Caja programs can run with excess authority
when it is inappropriately given to them until the
execution environments are tightened?  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.

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. <again
relates to my 'overall' comments later>

8.  Generally I don't understand the context for the
Javascript specific problems section.  Are you trying
to describe how Caja copes with these problems in the
sections or not?  It seems generally not.  If that is
the case I suggest saying so up front - but then when
do you deal with those problems?


Overall - There is something I don't understand about
the basic thrust of the paper.  Of course I understand
the safe Javascript subset idea - however problematic
that may be (which I'm not competent to comment on).
I understand the focus on resolving the flapping
between too much authority and too little authority
(Figure 1) by providing an opportunity for both
to transition to least authority.  Good idea.

What leaves me somewhat puzzled is this:  I can see
how, as with your OS/machine analogy, you can provide
tighter object execution environments within a
looser Javascript framework.  However, what I don't
see that you have addressed is how to get least
authority access to objects injected into a
sandboxed Javascript execution environment.

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?  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.  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.

> The untested first stab at a Caja runtime library that corresponds to
> this spec is at
> http://google-caja.googlecode.com/svn/trunk/src/js/com/google/caja/caja.js
> 
> Feedback appreciated!

There is my first crack.  Good luck with this effort
MarkM!!

--Jed  http://www.webstart.com/jed/