[tahoe-dev] Proposed short description of tahoe-LAFS for personal backup

Zooko Wilcox-O'Hearn zooko at zooko.com
Thu Jun 14 18:03:52 UTC 2012


On Tue, Jun 12, 2012 at 7:44 PM, Saint Germain <saintger at gmail.com> wrote:
>
> tahoe-LAFS is not really a backup software but rather a storage solution.

How about:

"""
Tahoe-LAFS is not just a backup tool, but rather a distributed file
system. It also comes with an integrated backup tool.
"""

>  The primary objective is to secure your data, either for
> privacy or for safety (against damage). To do so, it stores your
> encrypted data (encrypted at the source) on several machines organized
> in a network with a configurable policy (specifying K=2 and N=5 for
> instance, will spread your data on 5 machines, 2 of which need at least
> to be available to access your data).

Nicely written.

> A few remarkable points:
>  - I like its "paranoid" approach. The idea is to trust no one (and especially not your online storage provider)

This is fine and I don't think you need to change it, but for your
information whenever I see the word "trust" a little warning flag goes
up in my brain, and I go back and mentally rewrite the sentence
without the word "trust". This is because that word combines two
things: 1. Whether you think a person or tool is going to fail or
betray you, and 2. Whether your system relies on that person or tool
operating correctly and loyally.

A lot of the architecture of Tahoe-LAFS is focused on question 2 and
the interference of question 1 just confuses everyone. If you think
about question 1 then you'll sometimes end up choosing the wrong
answer for question 2.

For example: think of Least Authority Enterprises. As a company, we
don't want our users to think that we are weak or malicious -- that we
are likely to fail or to betray our customers to someone else. But, we
very much want our customers to be *invulnerable* to us, so that *if*
we were to fail or to betray our customers to someone else, there
would be very little damage that we would be able to do.

If you use the word "trust", then it is hard to explain why you don't
want to give LAE your encryption keys. Does that mean you think we are
dishonest? Don't you trust us?

If you force yourself not to use the word trust, then you can usually
rewrite the sentences to be in terms of "reliance" or "vulnerability"
instead of trust, and suddenly the confusion about question 1 vs.
question 2 disappears. Why do you withhold your capabilities from LAE?
Because you don't wish to be vulnerable to a failure or betrayal at
LAE. Because you don't want the safety of your backups to *rely on*
the continued security of LAE's servers and the continued loyalty of
its employees.

Doing that transformation on your sentence above would give something like:

"""
I like its "paranoid" approach. The idea is that no one (not even your
online storage provider) should have read or write access to your
backups.
"""

>  - Don't need any redundant PAR2 checksum, given that the data are

By the way, zfec is an alternative to PAR2.

https://tahoe-lafs.org/trac/zfec/browser/zfec/README.rst

zfec is much more efficient than PAR2 for some settings. (See the
benchmarks in the README.rst.)

I don't know of anyone who is actively using zfec's command-line tool
in the way that one uses PAR2's command-line tool, though. There are
lots of people using zfec as a library inside other tools.

Looking forward to reading your article! Maybe I'll painfully struggle
through the first 10 words in French and then get my Francophone wife
to read it to me. :-)

Regards,

Zooko



More information about the tahoe-dev mailing list