[tahoe-dev] Privacy of data when stored on allmydata.com

[Andrej Falout]

**Hello Brian,

thank you very much for detailed explanation. My comments below, inline.
Please be aware that I am new to all this distributed file system thingy,
and apart from being an IT professional, I am more of a humble user on your
dev list...

 * Tahoe is very carefully designed to protect the integrity and
>   confidentiality of the data stored therein. If you don't have the
>   filecap/dircap, you can't read the file.


Should I read this as "user needs to have additional copies of
'filecap/dircap' thingy" or he will not be able to restore if they are lost
on the PC that created backup?

I am asking since average user wont even know what they are, not to mention
if he "have" them.


>   * However, there are some maintenance tasks that cannot yet be performed
>   without a readcap.


Aha, another cap... maybe we need a dictionary? Is there a Wiki somewhere
for this project? I have the feeling it would be usefull...


> In particular, to measure how much space is being used
>   by a given directory (and its children), we need to traverse all the
> files
>   and directories and add up their sizes. In addition, to perform file
>   checking and repair, we need to get a repaircap for each object, and
>   currently directories can only be repaired with writecaps.


+1

[...snip...]

And once we implement DSA-based mutable files (with traversal caps),


+1


> Customers who maintain private directories


Is that any dir that is created with tahoe create-alias/add-alias withour
specifying allmydata.com rootcap obtained from
https://www.allmydata.com/native_client.php ?


> can either grant us
> the traversal cap (so we can do check+repair on their files for them), or
> they will be obligated to perform periodic file checking/repair on those
> private files by themselves.


I assume that "repair" of files assume that original file still exists
somewhere?


> Finally, as a consumer-oriented backup service,


Glad to hear that :-)


> most of our customers expect
> us to be able to recover their files for them even if they've forgotten
> their
> allmydata.com password. The usual authority model is that if you have the
> same credit card that is paying for the account, and if you can receive
> email
> at the main account address, then you get to see the files. For this
> reason,
> most of our customers expect us to hold on to their rootcaps, even though
> that means we have the ability to see their files.


I would say that this thinking does not apply to most of youir clients that
make a living with or from there data.

Also, I'd like to emphasize that your abbility to see the files is not the
biggest reason for this requirement; in my case, it is the possibility of an
attacker getting into your system, that is of most concern, and then there
are legal requirements, such as personal data privacy, and the fact that,
for example, it would be ilegal for me to make ANY data about ANY Australian
person available to ANY organization outside Australia without a permit, and
is actually a cryminal offence. There are few more issues here, but you get
the picture.

Once Accounting and traversal caps are done, we can give our customers a
> choice between password-recovery and privacy. The installer will have a
> checkbox that explains the options and lets them choose whether to give us
> a
> rootcap or not.


That would be great. Dont forget to mention the need to have additional
copies of whatever-caps storred on additional machine, in order to be able
to restore data if installation disk is lost?


> But, in the meantime, if you want to buy storage space from allmydata.combut
> also want to make sure that allmydata.com can't see the contents of your
> files, then you need to supply a second layer of encryption. The duplicity
> plugin described by Francois is an excellent way to do this, although of
> course you won't be able to use the www.allmydata.com webdrive to view the
> unencrypted contents.

Some backup schemes will aggregate files together in a
> way that makes differential backups more difficult or less efficient.. I
> don't know how duplicity works, but I'm sure there are some schemes that
> would provide the properties you're looking for.


As mentioned in my response to François, this is not a sollution in my case,
as a) it requires at least third of the disk space to be free to create
encrypted tar file, and b) it will require a  download of complete initial
full backup, plus potentialy several direfential backups, just to restore a
single file.

I will follow closely the discussion on upcoming sollutions proposed, but
this seems a bit in the future. I am wondering when can we hope for
Accounting and traversal caps to be implemented, and if plugging in some
sort of on the fly encryption to FUSE mounter such as blackmatch would be a
quick fix?


> I hope that explains some of our design decisions and what your current
> options are..


It certanly does, and thank you for that. It would make a great content for
a Wiki page :-)

Cheers,
Andrej



>
> cheers,
>  -Brian
>



-- 
Andrej Falout
AU: +61 (410) 463 735 NZ: +64 (21) 0256 6825 US: +1 (360) 488 0970
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://allmydata.org/pipermail/tahoe-dev/attachments/20090205/8892af69/attachment.htm