Hacker News new | past | comments | ask | show | jobs | submit login
Wuala: Secure Cloud Storage (wuala.com)
278 points by greyman on June 10, 2013 | hide | past | web | favorite | 191 comments

Seriously? Wuala is a service run by LaCie. LaCie is owned by Seagate, an American corporation. It doesn't matter where the servers are, because all the important decisions will be made in Cupertino, California.


Now, client-side encryption is a much more interesting aspect of their service, but is it worth the trouble if Wuala's clunky client takes 100 times longer than Dropbox to sync a file between two devices? Ditto for SpiderOak, JungleDisk, and every other backup/sync solution that I've used so far that boasts client-side encryption. And it wasn't due to Dropbox's deduplication, either. Some of them just talked lazily with the server for several minutes before they even started to upload/download any files.

> is it worth the trouble if Wuala's clunky client takes 100 times longer than Dropbox to sync a file between two devices

Is this some general FUD about encryption being slow, or an actual measurement?

Maybe all client-side encrypted solutions happen to be crappily implemented, but I don't think that client-side encryption would necessarily lead to something noticeably slower.

I have absolutely no intention to spread FUD about client-side encryption, and in fact I don't think Dropbox's speed advantage has anything to do with (lack of) encryption. Encryption shouldn't have any noticeable impact on sync speed, since modern CPUs can encrypt a file a hundred times over in the time it takes to upload/download it. I agree with you and suspect that it has more to do with crappy architecture.

Anecdote: SpiderOak takes 5 minutes synchronizing metadata with the server if I start it on a laptop that I only use occasionally. That's how long it takes for the client to find out what files I changed in my other machines in the meantime, including all the files that have nothing to do with this particular machine. Nothing gets synched during this time, and the client sometimes consumes a whole CPU core for extended periods. It's very annoying when I just want to see a few files that I know I changed in another machine. I understand that the protocol needs to be different if all the encryption is done by the client, but this is just ridiculous. Wuala is no better in my experience, although YMMV depending on your use case and filesystem structure. (I have over 50GB of data in my SpiderOak account, made up of a quarter million files. At one point I had over 100GB stored in there, and it was a PITA to sync any files at all.)

As an interesting comparison, Microsoft SkyDrive performs just as terribly as SpiderOak does when you give it a few hundred folders with ~100K files to sync, despite the fact that it does no client-side encryption. It just sits idle for half an hour or more, scarcely utilizing any network resources. I have no idea what it's doing. Maybe it does sleep(random()); between each upload. In any case, encryption isn't making it slow. It's just bad app design, bad protocol design, and perhaps overloaded servers.

Dropbox, on the other hand, immediately begins to upload/download my files, and once it's done scanning any large folders, its speed is only limited by the bandwidth of my Internet connection. When I need to do a presentation, I can just work on the .pptx file in my Dropbox on my desktop PC, take my laptop to the conference room, and expect the .pptx to be there as soon as I wake my laptop. That's the meaning of convenience. By the same metric, none of Dropbox's commercial competitors (perhaps with the exception of Google Drive, which I don't use) are even close to convenient.

SpiderOak cofounder here.

It's not really about the encryption directly; it's about the way the database design has to change to support zero knowledge (the server can no longer do the database work.)  Things like garbage collection have to happen client side.  Described in detail here:  https://spideroak.com/blog/20091026143000-why-and-how-spider...

FYI, when SpiderOak first starts running, like any backup software, it has to scan your filesystem to see what may have changed while it was shutdown, and that can take a lot of IO and CPU if you have many folders and/or many small files (hundreds of thousands).  (SpiderOak works with any folders you like, including externa/network drives, not just one folder like Dropbox.)  

In a profile, basically none of this CPU time is spent in the crypto module, just mostly for unserializing the per-folder journal to compare state.  SpiderOak does some optimizations with directory hashing to avoid having to open the journal to scan for specific changes in unchanged folders, but there are some situations where that optimization is defeated (such as if you remount a file system with changed gids, inode IDs, timestamps, etc.)  

Anyway, once it's running, it uses the operating system facilities on Linux/Mac/Windows to notice changes automatically so rescanning the whole backup selection after startup is not usually necessary.

In any case, thanks for your interest in SpiderOak. :)

Hello Alan,

I have a quick question for you which might be of interest to others as well:

Why isn't SpiderOak open source yet?

I've read your FAQ answer[1] on this, however it doesn't really give a concrete explanation, besides "soon" and "licencing concerns" which is definitely disappointing.

I currently use my own, EncFS based sync solution, however I'd love to be able to use SpiderOak, or a third party open source application which supported syncing with SpiderOak (if you'd ever consider exposing an API/Protocol which allowed such.)

This is the only reason I'm not using your service currently, however I love the concept and hope you'll take it into consideration. It's likely I'm not the only one with similar concerns.

[1]: https://spideroak.com/faq/questions/35/why_isnt_spideroak_op...

My hard drives are reasonably fast, so even with a quarter million files it doesn't take long to scan the filesystem. I have other backup software that scan the exact same folders and finish in less than 30 seconds. So I suspect that it's your journaling/unserializing system that takes up the bulk of the startup time.

Fortunately, I only need to start up SpiderOak once in a while, because nowadays I put my computers into hibernation instead of shutting them down and starting them up again. I also noticed that the more often I use SpiderOak, the less time it takes to start up, presumably because there's less delta to process. Also, as you said, once SpiderOak is up and running, it's relatively fast. Rest assured that the performance issues, although annoying, have not dissuaded me from renewing my SpiderOak Plus (100GB) account once again last month.

I also like the fact that SpiderOak's "Queue" and "Log" screens tell me exactly what it's doing at any given moment. Waiting becomes a lot more tolerable when I know what I'm waiting for. I hate backup tools that assume the user is too dumb to understand what's going on behind the scenes. Even Wuala's Upload/Download queue never seems to work properly.

Client-side encryption can be very fast when done right. For your use case a filesystem stored in the cloud might be a better solution, that way only the data you are using is downloaded to each machine and the writes are done immediately. Give ObjectiveFS[1] a try, the free preview is available for a few more days, and see how fast client-side encryption can be.

[1] https://objectivefs.com

Interesting, but an all-cloud solution would seem to be a better fit for servers with fat pipes (especially EC2) than for individuals with crappy residential connections. I have fiber at home, though, so I might try it out sometime.

I wouldn't go into technicalities because I can't - mostly because it's not my area of expertise and I've never looked into it deeply or maybe not even from the surface other than a user's perspective. The end user.

Wuala is seriously slow and clunky piece of software. Period.

"...is it worth the trouble if Wuala's clunky client takes 100 times longer than Dropbox to sync a file between two devices?"

I have no idea what the performance difference is (and clearly , neither do you), but the answer to your question is "yes". For some people, at least. It's a must-have feature for some people, not a nice-to-have-as-long-as-it-doesn't-inconvenience-me-too-much feature. Some people have data that they'd like to keep synced across systems that they simply can't keep in unencrypted form on a third-party server, no matter how much trust they have in the company that owns the service.

Of course, there are a bunch of different ways to keep your data secure and still have it be available to you on different systems, and non-open-sourced cloud storage with client-side encryption is still an imperfect solution, but it is a solution that is perfectly reasonable for many people.

BoxCryptor[1] has been my choice. I've been now using it on daily basis together with Dropbox and I'm satisfied. Boxcryptor works on the client side and stores the encrypted files on Dropbox folder as ordinary files. It is also possible to encrypt filenames. Boxcryptor comes from Germany.

The only drawback I have encountered is that Dropbox limits the path names to 255 characters. With encrypted file/folder names this can become an issue especially with some Java projects.

I think this really gives me the best of both worlds. Security for the files I think need it and the Dropbox infrastructure for syncing files.

[1] https://www.boxcryptor.com/

Yeah, tried that too. Also tried CloudFogger [1], which has a similar feature.

When it comes to performance, a layer of encryption on top of Dropbox is much better than any competing solution that has client-side encryption built into it, because you're still using Dropbox's awesome infrastructure and lightening-fast sync protocol.

But I ran into the same problem as you did. The 255-char limit sucks, and it's completely unnecessary because even Windows/NTFS allows you to use longer paths (up to 32KB) if you know which APIs to use. I suppose fixing this is not a priority for Dropbox because you normally don't run into it unless you use encryption, and Dropbox has no reason to encourage the use of encryption among their users.

[1] http://www.cloudfogger.com/

wuala isn't just doing client-side encryption, it is also doing reed-solomon coding.

Why not just store a TrueCrypt volume(s) in Dropbox?

Because TrueCrypt is not exactly "free and open source" software either.


"""It is challenging to create binaries from source code that match the official binaries bit-by-bit for purposes of verifying their integrity due to compiler options


There has been no known comprehensive review of the source code by a qualified cryptographer.[46][44] Thorough security code review and testing is hard, tedious, and painstaking work, and very few people have the skills to do it. There was, however, a functional evaluation of the deniability of hidden volumes in an earlier version of TrueCrypt by Schneier et al. that found security leaks.[47]"""

This is assuming the Government doesn't force Dropbox to install a keylogger on their client to get users TrueCrypt passphrases and possibly keyfiles.

If Dropbox bundled a keylogger with the Dropbox client, I'm pretty sure it would eventually attract some attention...

Who's to say they can't be convinced to push a one-off update to your account/machine. Perhaps a transitory one, to help cover their tracks?

The underlying problem is that you're trusting closed client software from a third-party. Once that is running on your system, arguably it's game over as far as what Dropbox or its like can and can't do to you.

(If you trust them, ok. But when documents state that "they're next", many of us start to wonder. And again, this isn't just access to a server. Through their client software, this is access to your machine, that you've already granted.

Admittedly, I'm describing the typical Dropbox user scenario and not where the client is manually applying -- or not -- each update, and somehow supposedly gaining insight into the capabilities of each update/version before doing so. And I'm also ignoring various forms of restricting the access of the Dropbox client, although if they really want you, they and parties using them would have extensive resources to apply to breaking out of such constraints.)

Very interesting and useful, not just for securing DropBox either.

FYI this article suggests to use encfs for an encrypted folder in your dropbox, this comment https://news.ycombinator.com/item?id=5855465 suggests that this might not be a wise choice, so you might want to (re)consider that part.

Thank you. I will read through this.

Let me take the opportunity to also thank you for writing up your email best practices. I hope to implement them or something similar for myself.

One of the challenges for me in all this is keeping up including with the implementation details. It feels akin to swimming upstream, with the current outpacing me.

Yeah, 4 years later when a whistle blower said something.

Storing an EncFS on Dropbox is another alternative, that doesn't depend on Dropbox' ability to recognize small changes in a huge single file.

It'd be better to use EncFS in this case, as it does per-file encryption. With TruCrypt, the whole volume file would need updating once you unmount it, if I understand correctly.

I like Boxcryptor since it encrypts each file individually rather than the whole volume. However, the file names are exposed.

encfs. Encrypts each file individually and file name are encrypted.

encfs sometimes generates very long path names, which runs against the 255-char limit that Dropbox imposes if you have any Windows computers linked to your account. Last time I tried it, the filenames were silently corrupted and much data was lost.

That's what I do, I have a small (100 MB) small volume sync in my DB, works like a charm :)

Because, as far as I know (I haven't used TrueCrypt too much), it will see the volume as a file and then you'll be syncing a huge, x GB file every time you make the smallest change within it.

That's not true. Dropbox uses librsync so small changes of big files yields small diffs, thus TrueCrypt volumes work just fine with Dropbox.

Speaking out of ignorance here: But aren't TrueCrypt volumes completely changed when you add/remove something? I'm thinking similarly to a hash: The slightest modification changes it completely.

But aren't TrueCrypt volumes completely changed when you add/remove something?

No, the crypto in TrueCrypt doesn't amplify the number of changed blocks. But it does disperse the changed blocks throughout the encrypted image, and this does result in higher bandwidth used during the sync (at least with DropBox). Here's an analysis I did a few years ago:


If that were the case, then terabyte-scale volumes would be prohibitively useless - and I know plenty of people with media volumes in TC.

That's not how it works - it would be inefficient to the point of uselessness to rewrite the entire file constantly, and my 100GB TrueCrypt volume is fast to save to.

"""Do you plan to open the source code?

Currently not. Opening the source code of Wuala would consume quite some time and effort, and commitment to maintain it. If you are a software engineer and would like to see how Wuala works, feel free to apply for a job at Wuala."""

ಠ_ಠ So.. an alternative, but not the solution we need.

And what would having the source code change?

Unless you host the data yourself, if you don't trust Wuala there is no guarantee the binaries you use are built from the source code you have.

You can see the client code and confirm that it actually encrypts all of the data and use your own copy rather than their binaries.

Technically if the client is not sending not encrypted data and encrypts without a foul, then nothing they can do on the server-side can cause leaking your data.

Just two ideas on top of my head:

Through auto updates you can make sure that you get the backdoored version or you can have an exploit within the software to allow "silent" remote updates (good luck finding that).

So well... Either you do it end to end, or you trust the third party.

Nobody sane wants software to auto-update, especially not security-relevant software. This is in particular true if you reviewed the source code of the software at one point in time.

Furthermore, for the software to be able to even auto-update, it would have to be able to change its own binary. I don’t know how this particular piece of software works, but it is possible to run FUSE ‘drivers’ as a user on Linux, with the binary safely sitting in /usr/bin, hence removing any possibility to auto-update (if you don’t do shady tricks like placing an ‘updated’ binary somewhere and changing the user’s PATH – and even that could – in theory – be avoided by mounting all user-writeable things noexec).

From http://www.wuala.com/en/download/linux:

> The package installs Wuala and registers our repository for further updates.

This is even more harmful that it sounds, as someone who has repo access (be it some evil staff member or, more possibly, inturder) may push not only malicious Wuala build, but any package with higher version number than in other repos (say, a linux-image-999.999 with a bundled rootkit) and if user was incautious it will be installed on system update.

That is not really auto-update (only if you enabled it system-wide) – and after reviewing the source code, which is necessary anyhow to make sure it is actually ‘secure’, you would then remove the file in /etc/apt/sources.list.d and be happy :-)

Use apt pinning

If there were a weakness in the client, it would be more likely to do with key management --- leaking a portion of the key (as Lotus Notes did once upon a time), generating keys from a non-obviously restricted set (viz. the infamous Debian "weak random generator" bug[1]), or possibly something more subtle. The presence of these behaviors might not be obvious from casual, or even careful, attention to the source code; the Debian thing was, by all accounts, just a bug, which nevertheless persisted for quite some time.

[1] http://www.debian.org/security/2008/dsa-1571

So.. an alternative, but not the solution we need.

Completely agree. We need 100% opensource client-side encryption tools.

And at least in this space (cloud backup), we already have it, thanks to HN's own cperciva:


Don't open source it. Just give read and build for personal use permission. That should be enough.

I don't think that I will be able to trust secure trough obscurity solution.

Or open up the protocol, for independent client implementations. With client-side crypto, the server doesn't matter much.

> "If you are a software engineer and would like to see how Wuala works, feel free to apply for a job at Wuala."

A non-answer if I've ever seen one.

What about someone who applies for a job at Wuala, gets rejected, but still wants to look at the source code?

And that's the only use case that bothers you?

You only need one counter example to poke a hole in a position.

I used Wuala for couple of years, when it was free and allowed earning a much larger quota by sharing own drive space to host other user's data. I used it to keep around 100GB of my personal data. Used to be good while it lasted. Encrypted, distributed, redundant. Then LaCie bought it and turned it into a Dropbox clone. Now I use AeroFS, also tried TorrentSync. Both a roughly equal. I just felt lazy changing from already running and tuned AeroFS to anything else. If you have 24x7 homeserver at home it is very hard to justify paying for storage at dropbox or skydrive or google. I built my homeserver on the latest Atom, so it is frugal (~10W) and completely silent (no fan, SSD). It's dualcore 2.1GHz and has enough grunt for simultaneous NAS, torrents, and plays 1080p mkv to the attached TV. No place for Wuala in this arrangement anymore.

It's still free, I don't pay a dime.

how much storage you've got there?

Hello there, Gianluca from Wuala here.

First, this is how Wuala works: You as an user place a file in the client. The file gets encrypted (including using your password and username) and then gets uploaded and split into different pieces. We are currently using AES-256 for encryption (and RSA 2048 fpr signature and key exchange when sharing a folder and SHA-256 for integrity checks). The password does NOT get transmitted and there is nothing like a master key or similar. That means in worst ever case if someone would have access to our servers somehow, they'd get a piece of encrypted data which is not readable and not decryptable (not even for us as the provider.

Secondly, some people tend to confuse security with anonymity. Wuala is secure, but how about anonymity? We have your email address, your username and we know how much storage space you have. As you see, that is not anonymous, but has nothing to do with the security of your files.

Are we planning to open source the code? Eventually yes, but as we already stated, this takes a lot of time and effort. Oh and yes, we are nice guys. Not because we're Swiss, but in general :)

Are you planning on allowing camera upload? I can't get people using your product without it...

we are planning camera upload yes :)

Hey Gianluca, I was under the impression the latest major revision of Wuala removed all distribution features, so files are no longer split into difference pieces. Instead they are now stored on your central servers.

No. We split our files and store them redundantly in our datacenters in Switzerland, France and Germany.

Hi Gianluca, What about when files/folders are shared? Is encryption dropped so anybody with a link can have access?

No, you can read everything regarding this matter here http://wualablog.blogspot.ch/2011/05/wualas-encryption-revis.... Regarding your question, you'll find your answer here http://www.wuala.com/blog/2011/04/wualas-encryption-for-dumm... (3. Sharing)

So basically the encryption key for the specific folder is in the shared url, and wuala servers decrypt the content to the user's browser. If sharing is disabled then a new key is created and used locally to decrypt/encrypt directly from the client. Thanks!

So honest question, but how is having your data stored in Switzerland (where Wuala is based) any different than having it in the US? Or is it just the promise of local encryption that makes it safer?

Some purported info about data protection for Switzerland:


> Restrictions on disclosure

The DPA does not permit the disclosure of sensitive data or personality profiles to third parties without lawful justification. The consent of the data subject can constitute a lawful justification. Breach of this prohibition is an offence if knowledge of the sensitive data has been gathered in the course of a professional activity requiring knowledge of such data and can be punished by a fine of up to CHF 10'000.--. If the fine is not paid, it can be replaced by imprisonment for up to 3 months.

And Wuala's own policy: http://www.wuala.com/en/about/privacy

> 6. Disclosure to third parties

Basically, your data is not transmitted to third parties. However, LaCie may release personal data if the law requires it to do so or in the good-faith belief that such action is necessary to comply with any laws or respond to a court order, subpoena, or search warrant or to protect LaCie's rights and interests. Furthermore, you expressly agree that LaCie can disclose personal data to identified third parties (e.g. owners of intellectual property rights) and/or government enforcement bodies in order to enforce the General terms and conditions, particularly in case of founded indications that the laws or the rights of a user or of third parties, particularly copyrights, other industrial property rights or personal rights, have been violated , insofar as such is necessary.

Due to the manner in which data is client-side encrypted (password-based keys, password not stored on their servers), they can hand your (encrypted) data to any government with no ability to decrypt it. Now, depending on the outcome of some cases before US Courts right now, you might be compelled to provide the password to unencrypt the data. It's also worth noting that the password-based asymmetric encryption schemes are less secure than the arbitrary key based ones, but still it's better than nothing. In my case, I'm sold by the fact that they provide more free storage than Dropbox and have a much better Linux client (based on a FUSE plugin, a much nicer architecture in general).

As it's closed source isn't it entirely possible that the client keeps copies of the keys that are accessible on demand from the server end (I guess that counts as a backdoor of sorts).

Open source is an incomplete defense against this - I don't know of a way of proving what software is running on a remote host.

>LaCie may release personal data if the law requires it [...] or to protect LaCie's rights and interests //

Isn't that one of those entirely vacuous sentences. Basically they have a disclaimer there that so long as it's in their interests to release it they can. So offer some money, "oh yes we're inclined to make money here's the data".

(Post above mentions that LaCie is owned by the American Corporation Seagate.)

I believe it's out of reach from the NSA letters. If it's encrypted and they don't have the keys it doesn't really matter, but I guess it looks good on a feature matrix.

I recently tried replacing Dropbox with Wuala because of privacy concerns. I failed, and in the process realized how successful Dropbox has been in creating an awesome user experience!

I'm still looking for a locally encrypted Dropbox-alternative. So if any of you are making one, please speak up :)

(Edit) I should specify that it was the user experience that made me give up on Wuala, and any proper Dropbox alternative would need to offer at least decent user experience. Looking forward to trying the alternatives you are suggesting :)

If you're concerned about your personal data, and not so much about targeted attacks against you, I'd say stay with Dropbox and just use EncFS.

You can do this on Linux (and presumably OS X, as well) fairly easily.

On Windows, there is a single-developer port of EncFS, which from what I've heard works fairly well: http://members.ferrara.linux.it/freddy77/encfs.html

A quick search turns up a guide which (at first glance) seems fairly comprehensive on how to set this up if you're unfamiliar with the way EncFS works: http://www.howtogeek.com/121737/how-to-encrypt-cloud-storage...

With that said, if you're worried about any highly confidential data, potential for watermarking attacks or plausible deniability, this is not the right solution for you.

If you're looking for a way to protect your data from dragnet surveillance, your provider, or low-level law enforcement interception, this is a great drop-in solution.

Playing the devils advocate here. What would stop the dropbox service from being able to collect the private keys on the user's computer?

Nothing. That's a risk you take when using any proprietary software, however.

I'd say the real world risk of this is (fairly) low, however if you're legitimately worried about it, you can use EncFS over a network share or FUSE file system, to your own systems. In which case you'd be using entirely open source software.

If you're that worried about security though, you'd probably be better off using a container based encryption method, anyway, as it wouldn't leak timestamps, file sizes and other data which could be sensitive. EncFS has some known issues with metadata leaking, but it's a decent solution for most general use cases.

Thumbs up to this. Been using the EncFS windows port for roughly a year with Google Drive with no issues. I was previously using TrueCrypt but the lack of differential sync was a killer on my TrueCrypt containers.

For Windows users: BoyCryptor 1.x is fully compatible with EncFS and features a GUI.

BoxCryptor is most definitely not fully compatible with EncFS - it doesn't even support the default filename encoding option that encfs uses.

Some older version supports that. Maybe they changed their license model, but it definitely had support for that in the past.

Yes, it was supported back when they used encfs, but now they've switched to their own internal rewrite which broke compatibility.

Ah, didn't know that. Thanks for the information!

On my "somebody should create this, and I might eventually" list is an open source, P2P, optionally server-backed, encrypted Dropbox replacement.

Bittorrent's Sync almost gets there, but isn't open source. I haven't really looked at it, but ownCloud might do what I want.

The ownCloud sync client for OS X pins one cpu core to 100% usage on my fairly new i7 mbp, which effectively drains the battery quite quickly if you don't notice.

Then it also seems to do a full scan of teh entire folder each time it sync's, if you then have for example your iPhoto library (usually a few GBs) there, the sync process will consume lots of CPU and tend to be out of date across devices.

I heard ownsync is really buggy. Havent tried it though.

Wuala used to be P2P (host other people's files to get more space for your files) until LaCie bought it.


I'd like to know more about this. Working on a encrypted FOSS alternative to conventional storage would totally be a perfect side project

Spideroak supposedly offers that, but it's still U.S. based. They haven't open sourced their client (they've stated they will) so it's hard to completely verify.

If you want to host it yourself there's Seafile but I haven't seen any in-depth review of it and it's Chinese-based (if that's a problem [for you]).

I really like SpiderOak I have been using them for more than two years. Resent update added a true dropbox experience. And most importantly it has a client for Linux, OSX, windows, ios and Android.

Syncany (http://www.syncany.org/) was supposed to be this locally-encrypted Dropbox-alternative. Unfortunately, it seems to be going nowhere slowly.

SpiderOak.com is nice. It's US-based, but its encryption is client-side, and they state that they never ever get the private keys, specifically to avoid being legally forced to decrypt and disclose info they store.

What about owncloud? http://owncloud.org/

It doesn't do local encryption before upload. There is an encryption plugin now, but it works server-side so you still have to trust the person running the server (which could be yourself, of course).

Immagine a net of people sharing Dropbox accounts where encrypted data is stored, and a decentralized encrypted network for handling the meta-data.

Wouldn't that be nice?

At this point: gpg keys shared among chains of trust. Need the file X? DHT consulted says the file is stored in accounts Y, Z and W (plus at your home - we don't want users to kill our files, right?). Take the file, decrypt it.

If you are on linux and if you don't think this method sucks... https://chanux.wordpress.com/2010/10/10/portable-encrypted-v...

I use Dropbox with Boxcryptor (https://www.boxcryptor.com/). It creates an encrypted drive/folder using a key of your own choosing.

We have a product coming out soon that's fully open source, self hostable (but also offered as a service), client-encrypted, and backed by Tent.

Mobile API?

It's powered by the Tent protocol (https://tent.io) so by definition, yes. The library is also open for anyone who wants to implement their own alternative, compatible apps, and alternative compatible libraries could be implemented since it's all just specific (documented) types of Tent posts.

Is tent designed for large-scale file storage? I always thought of it as an app.net/twitter alternative.

Tent is a protocol for decentralized event-based communication at scale. File sync is actually a medium-weight application in terms of the load it's designed for.

Of course, just like web servers, the server implementation and hardware it runs on has a lot to do with it. One of our top development priorities is building a very robust, scalable self-hostable server implementation to power apps like file sync and even more demanding applications.

I did the same switch, but didn't experience any specific problem. Actually I thought it was better done than Dropbox and had fewer sync issues.

We were looking at using AeroFS with our own servers, but it doesn't appear to support encryption on the server. I may be wrong about this?

AeroFS only stores data on clients (unless you run your own team server) and I think it has the option to store it encrypted there but could be wrong.

Exactly, running your own team server and backing up your own data. I'll have to contact them regarding the encryption options: if the team server can have the data encrypted it would be a winner for us.

I use Google Drive and Syncdocs (http://syncdocs.com). I does local AES256 encryption of any folder I want BEFORE uploading it to Google Drive

Spideroak or a private BitorrentSync setup are both good choices imho

git-annex has local encryption for specific remotes (i.e. you can add a remote and say ‘encrypt data before putting it there’, and then add another remote, such as a USB key, and don’t encrypt data on it). I haven’t used it in a while, but it is becoming more and more mature, methinks.

Sounds cool! I've been looking for a trustable Dropbox alternative so I don't have to manually encrypt the contents all the time. I'll download and try it out real q-

> Make sure Java [...] is installed.


I've been using it for almost a year now on my Windows, Linux and Android. Didn't have any issues so far. I would recommend the service to everyone concerned with privacy.

The only thing that one can be suspicious is whether they are transferring your key or not. But, at least they claim your data is safe and encrypted, while Dropbox, GDrive and similar services don't even pretend that they encrypt your data.

However, would still love to see an open source product like this that I can truly trust.

>> don't even pretend that they encrypt your data.

would it make you happier if they kept their services the same, but just pretended to introduce encryption? ;-)

>> don't even pretend that they encrypt your data.

> would it make you happier if they kept their services the same, but just pretended to introduce encryption? ;-)

No it wouldn't. What I wanted to say is that Wuala at least claims that they do client side encryption. I believe them, but someone else doesn't have to. So, data being safe with Wuala has probability between 0-100%, while data being safe with Dropbox has probability of 0.

I'm surprised that there isn't a "cloud encryption" software available yet. It shouldn't be a complex project to encrypt & rename -> upload // download -> decrypt & rename. You could store the original file names in the cloud in an encrypted sqlite database or something.

Here you go: https://www.boxcryptor.com/en/boxcryptor-classic

It's an offline application that runs on your computer that is transparent to your actions. You just use the drive BC mounts instead of where Dropbox tells you to use, the rest automatic.

Well, there's git annex.

  git annex initremote mycloudbox type=S3 encryption=my@gpg-email.com datacenter=EU
  git annex copy --to=mycloudbox myfile
  git annex whereis myfile
   whereis myfile (2 copies)
  	(...) -- here
        (...) -- mycloudbox
It also provides a nice Web UI (hosted locally) with colorful buttons, if that's your thing.

Well if that don't seal the deal!

It's from Lacie, so no thank you. I bought a Lacie drive and proceeded to copy all my stuff onto it. Before I could get comfortable with it (so within the first six months of purchase) and before I backed up my stuff, the drive failed. I contacted Lacie about it and they proceeded to try and sell me a service whereby they'd recover my data for €300. That would've brought my total spend on the drive up to around £400. I begged and pleaded with them, pointed out how unsavoury such a business practice was and all to no avail. The drive has just been sitting down since with the data unrecovered. Personal memories, music, films and professional data too. I've tried to recover the data but that didn't work and I honestly feel ripped off. As a result, I've vowed to never do business with Lacie again and to warn everyone of how unscrupulous they are. Beware of Lacie and their subsidiaries.

Well, they should have replaced the drive if it failed within 6 months. But expecting them to go to the lengths of recovering your data for free is a bit hopeful.

Hopeful yes, but no one expects a drive failure before even half of the warranty has expired surely?

The whole point of backups is that you should never expect a single hard drive to stay alive, no matter how young it is. Lots of hard drives with defects die early. For your own sanity, it is best to think of any data you have only one physical copy of as data that may not be there tomorrow. Personally I don't get comfortable until my most important data exists in two physical locations, so fire is not a risk.

You had 6 months and you didn't back-up your stuff? Why do you feel there is any blame to be laid at Lacie for this except for the mechanical failure which should have been under warranty? £300 is pretty reasonable for data recovery, it is only meant to be required when the user was dumb enough to not have a single backup. You put all your personal memories, music, films and professional data on one drive and expect sympathy? Learn from this, you are responsible for the safety of your data, have at least 2 backups.

$300 (which is even more reasonable. Otherwise +1.

Just to help you out in future, never ever have precious/important data on one drive, even if its raid. I could not sleep if I knew all my photos and work was on just 1 drive. I get paranoid if my data is in the same physical location.

Hard drives and other storage mediums fail all the time, this is not hyperbole, these devices are not designed for 100% ever. The companies work on the assumption that if they fail they will offer a replacement within warrenty, but expecting to get data recovery for free is not reasonable.

If I was you I would spend a thousand dollars on getting the data off and never making the mistake of keeping important data on 1 storage medium again. Whenever I meet someone who has all their precious data on 1 device like this I tell them that you might as well just throw all that data away now, thats how much you care about it.

Sorry if it hurts dude, just spend the money to have the platters recovered individually and never make the mistake again.

It's very pointedly not their obligation (nor even standard practice for any drive company) to go through the expensive process of recovering your data for you for free. Taking backups is your own problem and responsibility.

They should have offered to replace your drive, but no more. Hardly unscrupulousness.

Wuala has been around for years. Like 5+. Lacie just bought it. Don't conflate.

Edit, 4 years 10 months. Lacie merge in 2010

This is normal for Lacie. I've dealt with them in the past. They are a premium repackaging outfit of some of the lowest grade hardware you can get. They used to prey particularly on Mac users in the early 00's.

However, you should have backed up your stuff in more than one physical place and never assumed that the disk was entirely reliable.

Buy a quality drive enclosure and a quality hard disk, put them together yourself and make sure you have a half decent backup strategy.

Buy WD, Seagate, Samsung drive and have it fail, then try and ask them to recover your data for free.

One must always have at least two copies of any data one cares about and at least one off-site copy.

Or use BitTorrent Sync instead. I'm quite pleased with it and moved all my data off Dropbox.


Not Open Source either.

Company may be in Europe, servers might be in Europe, you might be in Europe. Nothing guarantees you that your data won't be routed through US where it can be tapped into. That's the primary issue for me with the whole PRISM scandal.

Data is encrypted client-side before being sent so I believe this is a non-issue.

It's a very non-non-issue: the client is closed source, for all we know it could do anything. Even if you listen on the data output to verify it's indeed encrypted, you still aren't able to tell whether your private key isn't transmitted alongside.

This isn't security, it's security by obscurity - in the best case, mind you.

Data being encrypted doesn't mean it can't be archived in that Utah data center. What capabilities they have there and what they do with it, we don't know. Substantial decryption breakthrough was hinted at in several reports, but what it is exactly - we have no idea.

>> Substantial decryption breakthrough was hinted at in several reports, but what it is exactly - we have no idea.

Could you provide a link to those hints, please?

This is the first one that comes to my mind: http://www.wired.com/threatlevel/2012/03/ff_nsadatacenter/al...

But “this is more than just a data center,” says one senior intelligence official who until recently was involved with the program. The mammoth Bluffdale center will have another important and far more secret role that until now has gone unrevealed. It is also critical, he says, for breaking codes. And code-breaking is crucial, because much of the data that the center will handle—financial information, stock transactions, business deals, foreign military and diplomatic secrets, legal documents, confidential personal communications—will be heavily encrypted. According to another top official also involved with the program, the NSA made an enormous breakthrough several years ago in its ability to cryptanalyze, or break, unfathomably complex encryption systems employed by not only governments around the world but also many average computer users in the US. The upshot, according to this official: “Everybody’s a target; everybody with communication is a target.”

Client side encryption is enormously better than no client side encryption.

Not to be cynic, but what prevents those guys from putting a backdoor as well? Yeah, sure, Swiss guys are good. Are they?

In the end, IMHO, the only software which can be trusted is the FOSS. From this perspective Dropbox is good: the client is open source. Of course nothing is encrypted in there.

Dropbox's client is not open source by any stretch of the imagination.


On the first I was like "ops, said bullshit"... but actually it seems like it's GPL.

That is only nautilus-dropbox (file manager integration) and the installer. Dropbox itself is distributed as a binary blob.

From this perspective, tarsnap is even better - http://www.tarsnap.com/bugbounty.html

Indeed. But at least there is no proof so far that they are doing it. However, France also monitors internet/com equipment, so it is indeed possible they will be required to put in a backdoor.

Still, FOSS solutions are indeed better from a security perspective.

Indeed it depends on their willingness to make a backdoor, US companies don't have that luxury anymore ...

A back-door in where, exactly?

The closed source binary blob?

Exactly, this is the point. If privacy is important for you, closed source software is not trustworthy, unless it's placed downline of encryption.

... or even in the Java runtime?

Oracle is supplying enough zero day exploits to have no need for backdoor.

I've been using this since the very early alpha status. It's a really nice storage solution with a very sophisticated technology too.

For anyone curious about the technology behind here is an early tech talk from one of the founders. It may be a little bit outdated now but still interesting: http://www.youtube.com/watch?v=3xKZ4KGkQY8

Despite thorough researches and testing, I have never been able to find a good alternative to Dropbox in term of seamless synchronisation of my files, and accessibility across all the platforms I use.

To secure my data, I just use BoxCryptor. It creates an encrypted volume within my Dropbox. It is free for non commercial use.

Have a look at BitTorrent Sync: http://labs.bittorrent.com/experiments/sync.html

One advantage is that there's no third-party storage of data involved.

Thank you, will have a look.

But how big is that volume? Shouldn't then Dropbox always upload the whole volume, even if you just made one change in one file?

The volume is as big as the data it contains.

Wuala is great, but the short summary is a bit misleading. There is a real risk of government agencies forcing LaCie to push you a client update that removes encryption, in an older version of their T&C / product info, this was mentioned explicitly.

I also don't buy the whole premise of US government - bad, EU governments - good.

When push comes to shove, governments everywhere will have no qualms about invading people's privacies en masse.

Human nature is the same everywhere. Power corrupts everywhere.

Switzerland is a non-EU country. Switzerland has a long tradition of civil liberties, rights and participation. This results in regular legally binding referendums on the one side and tax evasions from civilians of other countries on the other.

Like the time when Swiss banks conveniently decided to forget their tradition of "civil liberties and rights" and en masse turned over their clients confidential personal information and financial records to the US authorities? They've already acted like America's little bitch once, what makes you think they're not going to do the same again?

Switzerland recently increased cooperation efforts with EU countries on many, many issues. The geopolitical reality is that progressive (if glacially slow) solidification of the EU block is making it a politically as well as physically landlocked country. Such nations have clear limits in their independence in practice; to mention just one, any cable originating in Switzerland will inevitably have to pass through a EU country - worse, through a EU border, which allows for all sorts of shenanigans like the 2009 Swedish interception law.

The fact that they have been "good guys" until now doesn't say anything about the fact that they will be "good guys" forever.

This applies to good guys all over the world since ever. Btw, I did not state anywhere that I consider Switzerland as being the good guys. Applying qualities of character to a state is misleading IMHO.

I think there's an analogous between power and hardware/software failure.

When power is centralized corruption effects are worse, exactly like when software is centralized failure effects are worse. Distribution is the answer. Distribute power, in a way in which it cannot be exploited.

I'm not an expert in politics, but I guess that communism had this kind of principle, but it totally failed in implementing it.

Wuala is terrible. It is constantly eating up 30% of cpu when idling. Sometimes it doesn't sync at all for a few days. There is a "Use LAN" feature, but it doesn't work.

The problem here is: the people who has data (Wuala) also determine how the files are encrypted.

No box is ever unbreakable, however, the chance of breaking it is much bigger if you have the locksmith holding on to the box.

I've talked a little bit about this in my humble blog post not too long ago about a simplistic view of security in the cloud: http://vuongnguyen.com/personal-business-cloud-security.html.


There released an interesting paper regarding their key managment for multiple users, when they were a reserach project at the ETH.

Cryptree: A folder tree structure for cryptographic file systems - http://boga.googlecode.com/svn/trunk/res/Docs/wuala-cryptree...

I'm not a security expert neither do I understand cryptography hence the question: I assume they are not using the original password to encrypt data. They are generating a symmetric encryption key and encrypt it with the original password, storing it along with the encrypted data on their servers. The question is how secure the encryption on symmetric key? What if it is easily brutfocable?

We've been recommending this as an alternative to Dropbox where I work (in the UK) for a few years now, for exactly the reasons given in the title text. Yes, its a shame its Java-based, but they do have clients for Windows, Mac, Linux iOS and Android.

(No, I'm not connected to Wuala in any way, I don't even use the service myself, but as an alternative to Dropbox I think its a good one.)

Regardless of the service's value I found the security explanation on this page (https://www.wuala.com/en/learn/technology) to be a great example of clear communication about the differences between client-side encryption, SSL security, etc.

For what it's worth, what you need is:

-- a company with no connections to the United States. Ideally, it should be privately owned by a foreign individual known for strong privacy views and who has promised never to sell.

-- local encryption

-- open source ("trust but verify")

-- actually works

Wuala, from the comments here, meets only one of those four requirements.

Uh, just one? The way I count it's 2.5 out of 4.

It's a Swiss company, owned by LaCie (French) which is again owned by Seagate (US). So I would say that's half a point.

Data is en-/decrypted locally. There's a reason they don't have a web interface, but require you to use the client.

It's indeed not open source. Would be nice if it was.

And it actually does work. There's room for improvement (isn't there always?), but in my experience it's working well.

Another alternative is hubiC. It's run by OVH, perhaps one of the most "techno-geek" companies in Europe that you can find… I don't see them feeding content to governments without any reason.

In fact, they opened a DC in Canada and not the U.S. and one can guess why.

In fact, they opened a DC in Canada and not the U.S. and one can guess why.

Because it's culturally closer, I'd guess. OVH is a French company, and their Canadian data center is just outside of Montreal.

It requires Java?

Yes, just installed and then immediately uninstalled after I got the 'install java' prompt :(

It's not Wuala's fault, but forcing me to put java back on my desktop is a big hurdle. It's going to take an absolutely amazing piece of software to make me deal with that horrendous bug-ridden security hole again.

I don't trust the Java sandbox to protect me while running arbitrary code. So I don't use the Java browser plugin.

But I don't see how the desktop runtime is a security hole (you're running binaries you trust outside a sandbox) and I very much doubt it's any more buggy than your average Python, Ruby, Node.js, etc. runtime. Or, for that matter, your average native library.

Can you (easily) install one without the other? I know I can go around my browsers and disable the plugins after an install, but then I'm going to have to do the same thing each time there's a java security update and the runtime gets upgraded. Not to mention Oracle's crappy habits of bundling toolbars & other crud along with each security patch.

There's also Jottacloud (http://www.jottacloud.com/), a Norwegian Dropbox alternative.

Interesting. Anyone got any experience with Jottacloud they wouldn't mind sharing?

rsync.net. Zurich, Hong Kong. Warrant Canary[1].

Straight up unix filesystem (ZFS) so you can point duplicity[2] (or anything else) at it.

If you need something like dropbox, we are NOT for you.

We have special rates for HN folks. Email us.

[1] http://www.rsync.net/resources/notices/canary.txt

[2] http://duplicity.nongnu.org/

Problem with Wuala is that you can't access your data when you are offline, unlike DropBox, which stores an unencrypted version on your harddisk.

How about Dropbox + TrueCrypt + Automount? Files are decrypted in memory, files you need to share you can keep in unencrypted format.

I've been doing this with a small volume (1 MiB), but it always kept me wondering how much traffic a minor change in an encrypted volume causes - even a single bit flip should drastically change the container if the encryption is good. I wouldn't want to upload for an hour each time I see a typo in my files.

No. From the truecrypt FAQ [0]:

> The ciphertext block size used by TrueCrypt is 16 bytes (i.e., 128 bits).

Meaning one bitflip should only sync 16 bytes since dropbox only transmits deltas. Of course this now depends on dropbox' delta sync implementation.

From a quick google search [1]:

> For what it's worth, Dropbox claims to create hashes on every 4MB of each file. That way, if you change a contiguous 2MB of a 100MB file, it will likely only need to upload 4MB (or 8MB if you cross into a second 4MB block) to re-sync the file.

So worst case if a bitflip happens to change a truecrypt block that doesn't align with dropbox' chunks you're looking at around 8MiB. That's still quite an amout for a bitflip but i think it's feasible with todays connection speeds.

[0] http://www.truecrypt.org/faq

[1] http://serverfault.com/questions/52861/how-does-dropbox-vers...

I was thinking about this solution, and I also have a truecrypt drive (locally). But if you changed just one file in the truecrypted drive, shouldn't then Dropbox re-sync the whole encrypted drive?

Yes, that's correct. So if you have a 1GB TrueCrypt container the whole thing needs to be uploaded again.

Another annoyance is that you cannot change the size of a drive after you create it [1] and it doesn't shrink to fit the data either.

[1] http://www.truecrypt.org/docs/?s=issues-and-limitations


[citation needed]

Floodgate is opening up just like when Google shutdown it's reader. Let's see who will be the winner.

EncFS + Dropbox

Although this won't help if you get a rootkit in an update, since the source is closed.

Yeah, i'm sure the French would never have access to the servers in their country...

another dropbox alternative https://github.com/haiwen/seafile on you own servers

What about EncFS (or some other encryption) + Bittorrent Sync?

How does this compare to Tarsnap?

Way to be opportunistic!

5GB Free. Awesome!

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact