Re: Google Docs as capabilities as data

The UI would be indistinguishable for the recipients of delegation: in the current system, the general way people receive access is to get a clickable webkey in an email. In the upgraded system, people would get a clickable webkey in an email. No change.

For the senders of a delegation, the sending would also be similar: in PubShare, you type in the email address for a recipient (or pick from a list) and click Send. This is one of the choices in the Docs UI today (though not presented as well as I think it could be). The real noticeable difference would be in the revocation. Currently there is a button for “revoke everyone”. This would be replaced with a list of names, each of whom had a separate revoke button. I think this UI would be more pleasant because it would be less scary: from personal experience, when you “revoke everyone”, you are left with a nagging suspicion that there is someone you wish you could leave alone, if only you could remember who you sent it to. Very scary. Presenting the list of users eliminates the uncertainty, which is a big payoff for using a little more screen real estate. Again, you can see this in the PubShare video on YouTube.

--marcs

From: [email protected] [mailto:[email protected]] On Behalf Of Dirk Pranke
Sent: Monday, January 27, 2014 4:10 PM
To: General discussions concerning capability systems.
Subject: Re: [cap-talk] Google Docs as capabilities as data



On Mon, Jan 27, 2014 at 3:11 PM, Stiegler, Marc <[email protected]<mailto:[email protected]>> wrote:
Jed,

First, I am delighted that you found the Docs ocaps links useful. It’s nice when occasionally the tech one talks about actually demonstrates its worth ☺

Kenton has laid out the issues at great length with Docs ocaps, the reasons they disappoint me. I will just call out one highlight. The thing that most amazes me about the Docs ocaps, and the ocaps in the other products floating around (and there are a bunch of them now) is that you have no way of remembering who all you sent the link to, much less a way of revoking one person without revoking everyone. Such an ability to see the list of authorized people and to revoke them individually is recognized as so fundamental, no one would consider shipping an ACL system without it. Upgrading the ocaps in Docs so that everyone gets their own webkey and they can be revoked separately should not be very difficult; I did a very fancy version for PubShare (you can watch the video on YouTube), and even the fancy version was not very difficult.


Perhaps this is because once you actually have to add the UI to manage revocation (and the UI to manage individuals, groups, and all that other fun stuff), the advantages of webkeys (and other easily transferable caps) don't seem to great (at least from a user experience point of view)?

-- Dirk


--marcs

From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Kenton Varda
Sent: Monday, January 27, 2014 1:25 PM
To: General discussions concerning capability systems.
Subject: Re: [cap-talk] 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 <[email protected]<mailto:[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]<mailto:[email protected]>
http://www.eros-os.org/mailman/listinfo/cap-talk


_______________________________________________
cap-talk mailing list
[email protected]<mailto:[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