<b></b>Hello Brian,<br><br>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...<br>
<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
* Tahoe is very carefully designed to protect the integrity and<br>
confidentiality of the data stored therein. If you don't have the<br>
filecap/dircap, you can't read the file.</blockquote><div><br>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?<br>
<br>I am asking since average user wont even know what they are, not to mention if he "have" them.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
* However, there are some maintenance tasks that cannot yet be performed<br>
without a readcap.</blockquote><div><br>Aha, another cap... maybe we need a dictionary? Is there a Wiki somewhere for this project? I have the feeling it would be usefull...<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
In particular, to measure how much space is being used<br>
by a given directory (and its children), we need to traverse all the files<br>
and directories and add up their sizes. In addition, to perform file<br>
checking and repair, we need to get a repaircap for each object, and<br>
currently directories can only be repaired with writecaps.</blockquote><div><br>+1<br> <br>[...snip...]<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
And once we implement DSA-based mutable files (with traversal caps),</blockquote><div><br>+1<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Customers who maintain private directories</blockquote><div><br>Is that any dir that is created with tahoe create-alias/add-alias withour specifying <a href="http://allmydata.com">allmydata.com</a> rootcap obtained from <a href="https://www.allmydata.com/native_client.php">https://www.allmydata.com/native_client.php</a> ?<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> can either grant us<br>
the traversal cap (so we can do check+repair on their files for them), or<br>
they will be obligated to perform periodic file checking/repair on those<br>
private files by themselves.</blockquote><div><br>I assume that "repair" of files assume that original file still exists somewhere?<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Finally, as a consumer-oriented backup service, </blockquote><div><br>Glad to hear that :-)<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
most of our customers expect<br>
us to be able to recover their files for them even if they've forgotten their<br>
<a href="http://allmydata.com" target="_blank">allmydata.com</a> password. The usual authority model is that if you have the<br>
same credit card that is paying for the account, and if you can receive email<br>
at the main account address, then you get to see the files. For this reason,<br>
most of our customers expect us to hold on to their rootcaps, even though<br>
that means we have the ability to see their files.</blockquote><div><br>I would say that this thinking does not apply to most of youir clients that make a living with or from there data.<br><br>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.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Once Accounting and traversal caps are done, we can give our customers a<br>
choice between password-recovery and privacy. The installer will have a<br>
checkbox that explains the options and lets them choose whether to give us a<br>
rootcap or not.</blockquote><div><br>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?<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
But, in the meantime, if you want to buy storage space from <a href="http://allmydata.com" target="_blank">allmydata.com</a> but<br>
also want to make sure that <a href="http://allmydata.com" target="_blank">allmydata.com</a> can't see the contents of your<br>
files, then you need to supply a second layer of encryption. The duplicity<br>
plugin described by Francois is an excellent way to do this, although of<br>
course you won't be able to use the <a href="http://www.allmydata.com" target="_blank">www.allmydata.com</a> webdrive to view the<br>
unencrypted contents.</blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Some backup schemes will aggregate files together in a<br>
way that makes differential backups more difficult or less efficient.. I<br>
don't know how duplicity works, but I'm sure there are some schemes that<br>
would provide the properties you're looking for.</blockquote><div><br>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. <br>
<br>
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?<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I hope that explains some of our design decisions and what your current<br>
options are..</blockquote><div><br>It certanly does, and thank you for that. It would make a great content for a Wiki page :-)<br><br>Cheers,<br>Andrej <br><br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
cheers,<br>
<font color="#888888"> -Brian<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Andrej Falout<br>AU: +61 (410) 463 735 NZ: +64 (21) 0256 6825 US: +1 (360) 488 0970<br>