[tahoe-dev] filerock, SpiderOak, mega, "BitTorrent Share", Dropbox, dedupe

[Uncle Zzzen]

On Tue, Jan 29, 2013 at 12:43 AM, Zooko O'Whielacronx <zookog at gmail.com>wrote:

> On Fri, Jan 25, 2013 at 12:51 AM, Uncle Zzzen <unclezzzen at gmail.com>
> wrote:
> >
> > I've been looking at https://www.filerock.com/ and although I have some
> reservations (server isn't open source, reasons to believe they collect
> statistics - e.g. web interface has google analytics, etc.) it's still
> interesting as something I could tell granny: "use this, it's pretty safe"
> (tried this with LAE and she's still recovering :) ), so any insight about
> them is welcome.
>
> Wow, this raises a lot of responses in me:
>
> 1. Hey, cool, I haven't seen this company before. They advertise
> client-side crypto and publish (even open source?) the client. That's
> good competition for LeastAuthority.com!
>
> 2. Last I heard, the Tahoe-LAFS Software Foundation had google
> analytics on https://tahoe-lafs.org. Was that taken down? If not, can
> I see the resulting statistics?
>
> It's not the same (although it's still ok to fill a wee bit of shame),
because filerock have it on their equivalent of the WUI.
Not sure whether anything could leak that way (I'm sure there are people at
google who know much more about this than me :) ), but it shows that - at
least to some extent - analyzing my "anonymous information" *is* their
business, and that's a bit of "bad taste".

3. I hope your granny recovers quickly. :-) I do *so* wish for a
> Dropbox-like-GUI for Tahoe-LAFS! That's the only metaphor that really
> works for people like your granny. Hm, I see that we don't even a trac
> ticket for it! Added to my TODO list to create a trac ticket. (Heh.)
>
BTW, one interesting thing regarding "dropbox functionality" is that
they've found a simple way to avoid race conditions: only a single client
is allowed at a time. They have a notion of "session", and when you connect
your "magic folder" client, it would tell you "you're already on web. log
you out from there?" (also works in the other direction).

This solution is not only problematic (confines you to a single machine at
a time), but also isn't applicable for Tahoe-LAFS (no "sessions"), but it
shows that we *could* reduce functionality in order to overcome the
race-condition problem (e.g. a "magic folder" has only a single read/write
user and the rest are read-only). Being "exactly like dropbox" is not
necessarily a prerequisite.



> 6. Of course, just to be clear, even though I approve of the invention
> of more open-sourced, client-side encryption, I would not advise you
> to rely on filerock for something very valuable or dangerous, just
> yet. It is *very* hard to get this stuff right, and most new tools
> have critical bugs in them. I haven't looked at the filerock source
> code. (And in fact, perhaps I should not do so, as it might arguably
> enable them to make copyright claims against anything I write after
> that.)
>
Sure. I meant "granny" literally ;)


> Wait! Hold on a minute. In Tahoe-LAFS, by default, you have maximal
> confidentiality about the contents of your files. There is no
> deduplication, by default, between separate gateways, so none of the
> leakages of confidentiality that you mention here are a threat.

Cool. If it's optional, I'm relaxed (I guess it was a bit hotheaded of me
to assume MLE was proposed as the new Tahoe-LAFS encryption standard).


> Your UI suggestion sounds like an interesting alternative. One major
> issue with Tahoe-LAFS deduplication is that (a) few people understand
> it, and (b) few people know how to control it. Maybe having two
> folders, one for "files which I want to share deduplication with
> everyone in the world" and the other for "private files" is the
> solution.
>
> Or maybe there's no point in separating the concept of "keep the file
> contents private but deduplicate the files with everyone in the world"
> from the concept "publish the readcap to everyone in the world"! In
> that case, the two folders should be "Public" and "Private".

This seems very intuitive to me.


> Feedback on metaphors and use-cases is welcome! Everyone please post
> about how you use file-sharing, sync, backup, etc.
>
One thing I'd like to see is a prefab lafs-rpg-like gateway. I have one
(needed a vps for that), and don't know what I'd do without it.
This is one functionality of dropbox/filerock/etc. that doesn't come
out-of-the-box in Thaoe-LAFS: the ability to send someone I don't trust a
URL of a read-only version of a file or folder. This interface doesn't need
to copy the WUI. It can look mega-slick, have themes and bells and
whistles, contain a "you can have a storage like this yourself" ad, etc.

This is a lot more important for my use case than bi-directionality. I
don't mind being the only one with write permissions. If a friend wants to
share files with me, she can have her own cloud storage (whether LAE or
something else) and send me a read-only URL.


> (Except I'm less concerned about SpiderOak suing me for copyright violation
> since -- heh heh -- they use some of my GPL'ed source code (zfec) in their
> proprietary servers.)
>
:)



>
> Oh, and another similar thing that is a big deal on twitter right now
> is the new service from Mega (formerly Mega Upload (sp?)).

>From talk about it at liberationtech mailing list, people say this thing is
poorly written security-wise, as in rotten-to-the-core (much worse that
what diaspora got on their first release). I hope that the end result would
be people understanding that there *are* secure cloud hosting services out
there, but mega is not one of them (unless they do a complete rewrite), but
people might also end up believing "secure cloud hosting doesn't work" :(.
The fact that mega is widely discussed right know should be used into
driving messages like "mega doesn't deliver, but there are [pretty] safe
alternatives, and this is how you can figure out how safe". Unfortunately,
I suck at PR, and these are tough concepts, but the opportunity is there.


> It shows that there are some customers who are okay with read-cap-in-URL!
>
Yes. Having someone heavy teach the public that is indeed priceless :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20130130/3cc42d13/attachment.html>