Re: Google Docs as capabilities as data

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.
>

Hi Jed, access with which access rights? It looks like you selected "Anyone
with the link can view", however the document itself asks readers comment.
I think you should change the Sharing settings to "Anyone with the link can
comment".



>
> 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
>



-- 
    Cheers,
    --MarkM

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