[cap-talk] Techtalk by Doug Crockford on "Gears and the Mashup Problem"

[Jed Donnelley]

On 9/28/2007 9:10 AM, Bill Tulloh wrote:
> On 9/19/07, Mark Miller <erights at gmail.com> wrote:
>> Doug Crockford will be giving a Google Techtalk  tomorrow, 9/20 at
>> 11am on "Gears and the Mashup Problem"
> 
> The video of the talk is now online at:
> http://video.google.com/videoplay?docid=452089494323007214
> 
> Bill

Thanks for the announcement Bill.  It was nice to be able
to hear the presentation that I was unable to attend.

I'd like to ask a question and make some comments about the
talk here to see if others understand aspects that escaped me:

1.  At 25m18s:

http://video.google.com/videoplay?docid=452089494323007214#25m18s

Doug says, "Conceptually everything <messages> is JSON text so
what gets sent between the modules is safe.  You don't have
leakage of capability."

Why is it that restricting messages to JSON text will insure
that there is no 'leakage' of capability?  Does no
'leakage' of capability mean no delegation?


2.  At 26M26s:

http://video.google.com/videoplay?docid=452089494323007214#26m26s

Doug says, "Having a mechanism like that we can mashup everything.
Everything becomes a mashup.  I think the power of that is going
to be huge and it will radically change the way we thing about
application development.  Operating systems were supposed to have
provided these services, but never got it right.  But I think that
by elevating this stuff to the Web we get the modularity boundaries
right and we get the functional boundaries right.  We get to mashup
everything securely.  That's really important because there's a lot
of money at risk."

This to me is the same argument that I've made so many times on
this list that creating a POLA environment on the Internet (web)
is the most effective first step in moving the capability/POLA
concept forward.


3.  My overriding reaction to this presentation, however, is one
of disappointment.  When Doug shows, for example, this mashup
picture at 27m03s:

http://video.google.com/videoplay?docid=452089494323007214#27m03s

he shows his vision of a mashup where applications running in vats
have connections to one another.

Perhaps Doug is thinking more and just presented a minimalist
view.  I believe that there are at least two crucial elements
missing from this picture:

Element #1:  Limited permissions associated with connections.

Having connections to all the applications could be
achieved by simply allowing them all to communicate
on the Internet.  Sure, you still have to find out what
their IP address is, but the communication could happen
that way.

What I believe is vital is the ability to stipulate
what permission is granted by any given communication
channel.  While applications can of course come up with
ad hoc mechanisms to give out limited authority channels
(a situation that we have now), without providing for
such a mechanism as a 'standard' provided by the
communication infrastructure we will continue to have
the fractured mess that we currently have that's unable
to effectively achieve "mashup"s.


Element #2: Related to the above is the dynamics of
setting up these limited authority connections.
It is this dynamic aspect of granting permissions
that I believe (as touched on in the Myths paper)
is crucial to effectively enabling "mashup"s.  I
believe that the only effective approach is to
be able to send such a permission in a message
along any existing channel - namely as a
delegated "capability" parameter.


Without these last two elements I don't believe any
mechanism for providing communication between vats
(e.g. as Doug proposes in his call for a solution
design summit) will be effective in enabling mashups.


4.  A member of the audience asked (at 29m58s:

http://video.google.com/videoplay?docid=452089494323007214#28m58s

) how you avoid the 'blame the user' security situation
with the vat communication mashup.  Doug says it will
be avoided by having finer grained relationships.  I
don't see how this answers the question.  In many ways
it would seem to make things worse.  Namely one might
imagine that the users would end up being asked many
more irrelevant questions.

Then Marc Stiegler got up (happy to see friends there)
and noted that we shouldn't be asking users about granting
all their authority, but rather asking about lesser
transfers of authority by giving an example about transfer
of some $s for toothpaste.  I'm afraid I also don't see
how MarcS' comments answered the question either.

I don't believe the whole "asking the user" notion is
well framed.  In fact one of the major problems that I
see with the OAuth mechanism is exactly this.  It starts
with a situation where I as a user have authority
over something (e.g. in their picture site to printer
site example) like my pictures and I want to grant read
access to one such picture to another service - the
printer service.  At the point I decide I want to use
the printer service to print the picture the fact that
I need to grant the printer service access to the picture
naturally forms in my mind.  I naturally know that I
need to do a delegation (e.g. just like taking such
a picture to a copy service in a store).

Why do I have to be 'asked' anything?  There are many
sorts of interfaces for such an act of delegation.  One
of my favorites is drag and drop - e.g. as seen in
CapDesk.  If I do such a drag and drop, I don't need
to be asked anything.

In the OAuth mechanism (as I understand it) I first have
to do my act of delegation (creating an unauthorized
token that is communicated to the printer "consumer"),
but then I have to be asked this absurd and redundant
question about authorizing such a token.  The act of
delegation should suffice.


I believe that without these to critical two additional
elements we will find ourselves still stuck (mostly)
in the same old %$&#.  If the sort of summit that Doug
seeks is pulled off, I hope these additional elements
are given adequate attention.

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