[tahoe-dev] question about sharing...

[toby cabot]

Hi Greg,

Thanks for the speedy response - sorry it took so long to get back to
you.  Comments inline:

On Wed, Jun 01, 2011 at 01:52:19PM -0400, Greg Troxel wrote:
> toby cabot <toby at caboteria.org> writes:
> > I have a question about sharing files with other people and I can't
> > find the answer on the site but I hope this isn't a FAQ.  If I run my
> > own client with the web user interface, I imagine that I can share
> > files by simply giving someone a directory URL.  Could they then give
> 
> You should be clear on the difference between a URL to the gateway, and
> a URI which is a capability within tahoe.  URIs get encoded in URLS, but
> I'm getting fuzzy because I decided to stop using the Web User Interface
> for other than checking server connectivity etc. (because putting
> secrets in URLS in modern browsers seems like a bad idea).

It sounds like an important concept is that the URI to a file/dir is a
"secret".  I'll try to explain it and please let me know where I stub
my toe: "traditional" filesystem such as FAT/ext3/zfs/etc start at a
well-known "root" and allow users to explore the contents of the
filesystem from there.  Because the root is well-known, each user
would be able to do anything they wanted unless there were some sort
of inline permission check, so these filesystems implement "ACL"
permission checks to prevent users from doing things they can
discover, but are not permitted to do.  In other words, I can discover
a directory's existence, but I might not be allowed to read from it.

Tahoe-LAFS, on the other hand, has no well-known "root" - each
directory tree is identified by a secret URI which would be very
difficult to guess.  Each directory URI acts like the traditional FS
"root" in that users can browse down from it to see files in the tree
below it, but they can't browse "up" to see other trees within the
same FS.  Because users cannot discover things that they're not
permitted to, the traditional in-line permission checks implemented by
traditional FS's aren't necessary.

> > this URL to someone else, perhaps someone that I wouldn't want to see
> > the directory?  Is there an authentication component that I'm missing?
> 
> Yes, they could.  What you are missing is 
> 
> 1) that this is a capability system, not an ACL system.
> 
> 2) if you handed them a decryption key for normal data, they could grab
> and download the data.  They could then hand it out.
> 
> Basically, if you don't trust people to keep things secret, you can't
> share with them.  This isn't about tahoe, or rather tahoe has no magic
> bullet for this.

IOW, When I share a URI with someone, I place the same trust in them
that I would if I were to grant them traditional FS permissions on a
directory, and the ways in which they can honor or betray that trust
are similar.

> > If I give someone a URL to a directory can I later revoke that URL
> > somehow but still be able to access the directory myself?
> 
> No.  But you can move the files in it to a new directory and hope the
> original directory gets garbage collected.

I understand that a trust in in a traditional FS can be actively
subverted in the same way that it could in Tahoe-LAFS, but what about
mistakes?  Let's say, for example, that I want to respond to an email
and my reply has a capability URI in it, but I hit "reply all" by
mistake, or my crappy email client auto-fills "Jones, Fred" instead of
"Jones, Frank" and I don't realize before I send it.

If I realize I've made a mistake like this I'd like to be able to
correct it and know that it was corrected rather than hope for it to
be corrected at some unknown time in the future.

> But again, if they copied the data, you can't revoke that.

Sure, but let's say I realize what I've done before they've copied it.
>From what I've heard, with the traditional FS I can close the barn
door and know that it's closed.  With Tahoe-LAFS I can only ask for
the barn door to be closed at some point in the future.

> It's interesting that this comes up in tahoe much more so than in otheer
> filesystems.  People don't seem to ask:
> 
>   if I have a filesystem, and I let someone read a file, and then I
>   "chmod 700" it, how can I be sure they didn't keep a copy?  Isn't it a
>   bug that the filesystem doesn't enforce removing all their copies?
> 
> about other filesystems.

I don't ask that question because I believe that I know how
traditional filesystems work (but I might be wrong) since I've been
using them for a while and they've been around a lot longer than that.
Tahoe-LAFS, on the other hand, is new and interesting so I'm trying to
figure out how it works.  I tend to do that by comparison to things
I'm familiar with, so I start out with "oh, it says it's a file system
and I know about some other file systems so it probably works like
them."  It turns out that Tahoe-LAFS is pretty radically diffent than
Windows or Unix file systems in some really interesting ways.

Thanks again for helping me!