Re: Google Docs as capabilities as data

Fun fact:  If you try to e-mail a Google Docs link using gmail, and the
recipients won't have access, you will be prompted to grant them access.
 In theory, it could do this automatically.  This is how it should be:  by
e-mailing a document to someone, the user is sending a pretty clear signal
that they want the recipient to have access, so it should not be necessary
to separately consult the user about security.

I dislike apps that are not fundamentally communications apps but want to
send sharing e-mails on my behalf, because they usually give me very little
control over the formatting or context in which the message is sent.  I
usually want to weave my capabilities into a broader conversation, or at
least provide some context as to why I am sharing this document.  Yes, Docs
lets you include a personal message, but people are trained not to read
anything in HTML-heavy messages and skip right over it.  So, I much prefer
the integration to go the other way, with the communications apps being
responsible for recognizing capabilities and generating new revocable
webkeys for each recipient.  (Of course, gmail's support for this is based
on recognizing the recipient's Google identity by their email address and
adding them to the ACL, not generating webkeys...  oh well.)

-Kenton


On Tue, Jan 28, 2014 at 8:22 PM, Marc Stiegler <[email protected]> wrote:

> I send the below info from my hp email address, and apparently that email
> address is blocked from the list. So here it is again:
>
> 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
>
>
>
> On Mon, Jan 27, 2014 at 4:09 PM, Dirk Pranke <[email protected]> wrote:
>
>>
>>
>>
>> On Mon, Jan 27, 2014 at 3:11 PM, Stiegler, Marc <[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 J
>>>
>>>
>>>
>>> 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]] *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 <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
>>>
>>>
>>
>> _______________________________________________
>> 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
>
>

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