Re: Google Docs as capabilities as data

I think its a very good start, though there are some things that could use
some improvements:

1) "https://docs.google.com" : In order to prevent a man in the middle
attack, this part relies on a quite long list of certificate authorities.
Replacing the 'docs.' part with a hash-over-pubkey string could be a major
improvement there (assuming browsers or browser pluging could work with
it).

2) If you type "https://docs.google.com/doc" you probably notice some kind
of auto-complete showing your sparse-cap URL. Browsers don't look at urls
as caps-as-data, they do all kinds of stupid things with them (like using
them for auto complete, etc). The only way to fix this is I think making
browsers less stupid.

3) The "/document/d/10-qbHlInBNtlK3S9awzSTUbKyIkDZxEEr3sgD2VIga" part
containing the sparse-cap may very well end up in referrer headers sent by
the browser to sites referred from the document. Putting the sparse-cap
into the fragment section of the URL could be an improvement there.



On Mon, January 27, 2014 04:41, Jed Donnelley wrote:
> 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
> _______________________________________________
> cap-talk mailing list
> [email protected]
> http://www.eros-os.org/mailman/listinfo/cap-talk
>
>