<br><br><div class="gmail_quote">On Tue, Jan 29, 2013 at 12:43 AM, Zooko O'Whielacronx <span dir="ltr"><<a href="mailto:zookog@gmail.com" target="_blank">zookog@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Fri, Jan 25, 2013 at 12:51 AM, Uncle Zzzen <<a href="mailto:unclezzzen@gmail.com">unclezzzen@gmail.com</a>> wrote:<br>
><br>
> I've been looking at <a href="https://www.filerock.com/" target="_blank">https://www.filerock.com/</a> 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.<br>

<br>
Wow, this raises a lot of responses in me:<br>
<br>
1. Hey, cool, I haven't seen this company before. They advertise<br>
client-side crypto and publish (even open source?) the client. That's<br>
good competition for LeastAuthority.com!<br>
<br>
2. Last I heard, the Tahoe-LAFS Software Foundation had google<br>
analytics on <a href="https://tahoe-lafs.org" target="_blank">https://tahoe-lafs.org</a>. Was that taken down? If not, can<br>
I see the resulting statistics?<br>
<br></blockquote><div>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.<br>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" <i>is</i> their business, and that's a bit of "bad taste".<br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3. I hope your granny recovers quickly. :-) I do *so* wish for a<br>
Dropbox-like-GUI for Tahoe-LAFS! That's the only metaphor that really<br>
works for people like your granny. Hm, I see that we don't even a trac<br>
ticket for it! Added to my TODO list to create a trac ticket. (Heh.)<br></blockquote><div>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).<br>
<br>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 <i>could</i> 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.<br>
<br></div> <br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
6. Of course, just to be clear, even though I approve of the invention<br>
of more open-sourced, client-side encryption, I would not advise you<br>
to rely on filerock for something very valuable or dangerous, just<br>
yet. It is *very* hard to get this stuff right, and most new tools<br>
have critical bugs in them. I haven't looked at the filerock source<br>
code. (And in fact, perhaps I should not do so, as it might arguably<br>
enable them to make copyright claims against anything I write after<br>
that.)<br></blockquote><div>Sure. I meant "granny" literally ;)<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Wait! Hold on a minute. In Tahoe-LAFS, by default, you have maximal<br>
confidentiality about the contents of your files. There is no<br>
deduplication, by default, between separate gateways, so none of the<br>
leakages of confidentiality that you mention here are a threat.</blockquote><div>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). <br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Your UI suggestion sounds like an interesting alternative. One major<br>
issue with Tahoe-LAFS deduplication is that (a) few people understand<br>
it, and (b) few people know how to control it. Maybe having two<br>
folders, one for "files which I want to share deduplication with<br>
everyone in the world" and the other for "private files" is the<br>
solution.<br>
<br>
Or maybe there's no point in separating the concept of "keep the file<br>
contents private but deduplicate the files with everyone in the world"<br>
from the concept "publish the readcap to everyone in the world"! In<br>
that case, the two folders should be "Public" and "Private".</blockquote><div>This seems very intuitive to me.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Feedback on metaphors and use-cases is welcome! Everyone please post<br>
about how you use file-sharing, sync, backup, etc.<br></blockquote><div>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.<br>
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.<br>
<br>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.<br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>(Except I'm less concerned about SpiderOak suing me for copyright violation<br>
since -- heh heh -- they use some of my GPL'ed source code (zfec) in their proprietary servers.)<br></blockquote><div>:)<br><br></div><br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Oh, and another similar thing that is a big deal on twitter right now<br>
is the new service from Mega (formerly Mega Upload (sp?)).</blockquote><div>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 <i>are</i> 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" :(.<br>
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.<br>
 <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It shows that there are some customers who are okay with read-cap-in-URL!<br></blockquote><div>Yes. Having someone heavy teach the public that is indeed priceless :)<br>
</div></div><br>