Re: Google Docs as capabilities as data

Domenico Rotondi <[email protected]> Wed, 29 Jan 2014 10:15:20 +0100

Newsgroups	gmane.comp.capabilities.general
Message-ID	<[email protected]>

On 28 Jan 2014 at 20:22, Marc Stiegler wrote:
Hi all,
within the EU FP7 IoT@Work project (http://www.iot-at-work.eu/) we used
capabilities to manage access to a publish/subscribe service tailored for shop floor
events collection and dispatching.
In our system the both the generation of the access tokens (what you call webkeys)
and capability tokens revocation was completely distributed and managed using
standalaone applications anyone can install and use.
The logic in our system was to have a root capability token for each service/resource
created by the administrator of the service/resource and the existence of a trsut
relationship between the service and its administrator.
Starting from this root capability, the administrator (using the stand alone
application) can generates new capability tokens for other subjects, he/she trusts,
granting all or part of his/her rights (including the right to further delegate the 1+ of
the granted rights).
The generated tokens can be distributed to their owners using any means (even via a
public FPT service, being each token digitally signed and boud to a specific identity).
Each owner of a capability token can further frealy create additional tokens for other
subjects he/she trust granting a subset of the rights he/she owns (of course if his/her
token grants him/her the right to delegate).
There is no need, in our system, to centrally store all capability tokens, even if we are
forced to report in each token its whole authorization chain (i.e. the capability of the
delegator that contains its ancestor capability token, ...).
At the end the application service needs to be aware of a capability only when its is
used to access the service/resource!
For the revocation we used a similar distributed approach by using what we call
revocation requests that are submitted to a specific revocation service (which is
identified within the capability tokens). Each subject can create a revocation request
identifying which capabilities he/she wants to revoke (a revocation can ask to revoke
only capabilities that have as ancestor the capability of the subject signing the
revocation request). Even for the revocations the process is completely distributed
and, apparently uncontrolled, with the only constraint that the revocation must be
submitted to the duly revocation service. This service process the requests and
actually revokes the identified capabilities only if it has all the information to
ascertain the requestor is actually authorize to do so (i.e., the capabilities to be
revoked have the requestor's capability as ancestor).

This approch in our system simplifies the amount of things to be stored on the
service/resource manager side and requires only, or essentially, the ability to check
the correctness of the capability submitted with the service access request (and of its
delegation chain) + asking to the revocation service if the submitted capability is still
valid.
Further details are providing in this paper (on others mentioned in it):
* D. Rotondi, S. Gusmeroli, S. Piccione, “A capability-based security approach to
manage access control in the Internet of Things”, Mathematical and Computer
Modelling Journal, ISSN 0895-7177, 10.1016/j.mcm.2013.02.006

The advantage for us is that we take advantage of the trust relationships among the
subjects, we don't have to explicitly manage trust relationships, we don't need to
have things like federated id management contexts, and that, at the end, we have full
auditability of each access request (thanks to the explicit authorization chain in the
capability token presented with the access reuqest) and we always know who is
accountable for a delegation.
This approach, we know, cannot be useful in every context, but seems to us suitable
in many situations.
BTW the SW is provide as opne source
(http://code.google.com/p/txt-iot-technologies).

Sorry for the length email. Hoping this helps for the discussion.
Ciao
Domenico

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-qbHlInBNtlK3S9awzSTUbKyIk
DZxEEr3sgD2VIgaY/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