Re: Google Docs as capabilities as data

Google Docs has supported "share-by-link" basically since its inception.  I
spent some time on the "sharing team" that owned this, although this
functionality existed before I joined.  AFAIK, the people who devised it
didn't know anything about capabilities and essentially re-invented a weak
variant of them by accident.

The approach works reasonably well and is popular.  However, compared to a
"real" capability-based sharing model, Docs is hamstrung by the fact that
there is no way to have multiple URLs pointing to the same underlying
document.  At the owner's choice, knowing the URL grants edit, comment, or
view rights.  You can't create one URL for edit rights and another that is
read-only.  In fact, once you've assigned edit rights to the URL, it is
impossible to share the document read-only with anyone, even explicitly by
identity, because in order to open the document they must visit the URL,
and they therefore get whatever access the URL grants.  You also can't
change the URL if it leaks (although you can always create a new copy of
the document).

Of course, this also means you cannot create different URLs for different
recipients.  So, you have no way to distinguish the people you share with.
 In fact, Google login doesn't even save you here.  Even if the users who
access your link are logged in, you don't get to see their identities in
Google Docs unless you have explicitly added them to the ACL (or, for
enterprise users, if they are part of your organization).  The reason is
that otherwise it would be too easy to harvest someone's Google identity by
tricking them into clicking on a link back to your doc.

The consequence of this is that share-by-link is seen as "somewhat
insecure", only suitable for medium-sensitivity documents.  Some Google
security people (or engineers who fancy themselves as security people)
would like to see this mode eliminated.  Fortunately, it is far too popular
among users for that to happen.  (Although from what I hear, the usage is
bi-modal -- some users "get it" and use share-by-link for everything,
others don't get it and avoid it.)

There is a general assumption that this is just the way things are -- that
there's no way to make share-by-link more accountable.  I spent a few years
trying to convince people that we could do better, but people generally
aren't that interested in listening because this isn't perceived as a
pressing issue.  To be honest, given that they had already developed a
fairly convoluted identity-based security model that could cover most use
cases, it's hard to make an argument that developing a stronger
capability-based sharing model would be worth the investment for Docs.

Interestingly, there is a second form of accidental capabilities in the
Docs sharing model that most people (even at Google) don't know about:  if
you go into the sharing dialog and enter an e-mail address that is not
connected to any Google account, an e-mail will be sent to that address
containing a secret URL known as an "invite token".  Each address you enter
receives a different token.  When the recipient uses the token, they are
prompted to log in with their Google account and to reveal their identity
to the sender.  If they choose to do so, then their Google identity is
added to the ACL and annotated to indicate the e-mail address to which the
original invite was sent.  In order to support mailing lists, a single
invite token can be exercised multiple times to add multiple identities to
the ACL.

Sadly, the only way to create an invite token is by having it sent to
someone.  You can't generate an invite token with an arbitrary petname and
then copy/paste the URL into an IRC session.  I suppose you could set up a
non-Google e-mail address to represent the person, have an invite sent to
that address, then go retrieve the e-mail yourself and copy/paste the
URL...  but that's convoluted, and they still have to log in with a real
Google account before they can access your doc.

Google is not the only company to implement capabilities as data.  The
approach is popular among startups trying to be "viral" because it makes
sharing so easy.  Etherpad -- and derivatives like Hackpad -- use
share-by-link as the *only* access control mechanism.  But generally they
have the same problems as the Google approach -- there is only one secret
URL per document.

In any case, yes, capabilities-as-data are widely used and popular on the
net today.  However, the implementation is not usually strong enough to
replace identity-based sharing, and there is resistance to making it any
stronger as most developers still don't "get" capabilities.

-Kenton


On Sun, Jan 26, 2014 at 7:41 PM, Jed Donnelley <capability-iCFHVraI1K1Wk0Htik3J/[email protected]>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
>

_______________________________________________
cap-talk mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/cap-talk