Google Docs as capabilities as data

Cap-talk,

Isn't:

https://docs.google.com/document/d/10-qbHlInBNtlK3S9awzSTUbKyIkDZxEEr3sgD2VIgaY/edit?usp=sharing

effectively a capability as data?  The above is shared using the Google 
Docs mechanism that allows anybody with access to the above string to 
access the document.

I looked back through the cap-talk discussion to try to find relevant 
references for such sharing.  Here's what I found

On 1/8/2012 9:41 AM, Stiegler, Marc D wrote:
> Google Docs demonstrates that security geeks can screw up the ui just as effectively with ocaps.

What did you mean by the above Marc?

To me it seems that this capability as data sharing via Google Docs is 
to OCAPs something like the Web is to Xanadu.  Namely, it is about as 
much as one can do technically to effectively get the functionality of 
capabilities on an Internet scale.

I had a delightful experience this evening with my daughter (who's at 
Yale working on a proposal for work next year), her college roommate, my 
wife and myself where we were all simultaneously editing a proposal that 
was a Google Doc shared as above.  We had a Skype voice line also open 
for high level communication and task assignment, but most of the work 
was accomplished silently.  We were all able to see what the others were 
doing on our shared document.

On 1/4/2012 9:53 AM, Marc Stiegler wrote:
> Google also offers unguessable urls as an access control choice for
> Google Docs.

Right.  It seems to me to work well.  Where are the problems?

Also from the above:

> Anyway, using unguessable urls of the type used by Google and CACM and
> IEEE, you could rest easy knowing that you were not using modern
> waterken-style webkeys, which have the public key fingerprint in the
> domain name. That would be a nonstandard and radical leap toward a
> better future. Don't do that.

Is that practical at this time?  Does it add sufficient value to be 
worthwhile?

On 1/5/2012 11:30 AM, Stiegler, Marc D wrote:

> The Google Docs implementation of unguessable urls is comically 
> primitive. It is a good example of how to do 80% of the work and get 
> 10% of the value.

I'm not bothered by this.  It seems to me the user interface (sharing 
strings of URL .data as capabilities) and the essential value don't need 
to change.  If there are technical improvements that can happen behind 
the scenes, go for it.  Perhaps they will happen in response to security 
breeches?

I'd be happy to see additional features for documents that can be 
revoked and/or otherwise attenuated, but I'm not sure that such would 
provide sufficient value to justify the additional complexity to the 
user interface.  After all, one can always create a copy of the object 
and re share it to a smaller community - for objects that are 
documents.  More general types of objects may require more serious 
protection.

Has there been more discussion of such URLs as capabilities that I've 
missed?  I saw Waterken mentioned at some points in this discussion, but 
I'm not clear what it contributes at this point. Can someone enlighten me?

I'm delighted to see the progress that's been made in this space. To me 
it looks like capabilities as data is now an effective Internet 
reality.  To me this beats the hell out of having all sorts of separate 
environments for logins with separate sharing via ACLs, etc.

Maybe a next step (perhaps already implemented?) would be to use 
something like an svn back end for any such files, with a "blame" 
mechanism for every identity, etc.?  Horton for responsibility tracking?

There is of course much work to be done and improvements to be made, but 
to me this appears to be serious progress.

Woo hoo!

--Jed