Hacker News Reader

Comment by cpursley | Hacker News Reader

Chicago? Last time I checked, that city is within the jurisdiction of the United States and not immune to national security gag letters.

No thanks.

Swiss based Wuala.com is a much better solution.

View on HN

Isn't switching from one closed source backup system to another closed source system overlooking the elephant in the room? These companies are legally required to rat you out when the government comes knocking (some even doing so without demanding a valid warrant, and profiting from LEO requests).

SpiderOak has been saying they "expect to make the SpiderOak client code open source in the not-distant future" [1] for years now, and their code still is not fully open-source. I completely understand their situation and know it's not always possible to fully open up the code, but I'm not able to overlook this deal breaker either.

Encrypt locally using only open source tools, then sync with whichever online backup/sync provider you like. It's the storage version of a 'dumb pipe', maybe we call it 'dumb containers'. Everything else is marketing bullshit which will evaporate once that first official demand for your data arrives.

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

Hey, SpiderOaker here!

While open-sourcing the desktop client isn't going as fast as we'd like, I'd like to point out that practically all current and future projects are open source on our GitHub (https://github.com/SpiderOak/), including our next-gen encryption system Crypton (which will eventually replace the data structures in the desktop client ANYWAY)

This is cool. Have you guys considered offering encryption as a service and let users pick their own data provider?

It's technically possible with Crypton. Note that the server-side components are under AGPL or commercial license; it's either pay fair or play fair.

I recently created a "petition" for SpiderOak to open source the client (and allow people to build it themselves from source) so that people can let SpiderOak know their thoughts. The petition signatures are sent to SpiderOak.

It's still available at the link below if any SpiderOak user (or potential customer) wants to use it to "show the numbers" on a single site (as opposed to scattered comments): http://www.change.org/petitions/spideroak-http-www-spideroak...

There's an online backup service called Cyphertite (cyphertite.com) that provides the sources for its client programs on all the platforms it supports. So I don't really see why SpiderOak, with its prominent proclamations of "zero knowledge", cannot walk the talk.

Of course, I understand that certain competitive advantages may take longer to provide in the open (until factors other than the client source code and backend architecture become competitive advantages). But I have to admit that SpiderOak has been dragging on opening up the source.

Edit: Let me also admit that I do like SpiderOak and the emphasis it places on privacy and in educating users about privacy. We need more services that strongly support what ought to be basic rights.

Thanks for your support and your efforts are much appreciated. We also agree that SpiderOak needs to be entirely open, and hope to have that completed within the next year. Everything new we've started in the last several years (including https://crypton.io/ and https://nimbus.io/ and a variety of other things on our GitHub) is GPL'd. Stay tuned!

You already have what you want. The source is here:

http://duplicity.nongnu.org/

Actively in development, stable, ready for enterprise use.

Yeah, buggy and unstable and just hangs when you throw large quantities of small files at it.

"It's the storage version of a 'dumb pipe', maybe we call it 'dumb containers'. Everything else is marketing bullshit..."

Ding!

If only there was such a provider that gave you the dumb pipe version of an offsite filesystem ... it's on the tip of my tongue ...

Hey I'm no expert, and have absolutely no evidence, but do know that there was an issue some years ago where the Swiss were allegedly strong-armed by the IRS into lifting their privacy restrictions [1] and [2]. The story, as I remember it, was that Swiss banks had to share information about US depositors with the IRS if the Swiss wanted to continue operating offices is the US.

While I trust the Swiss a lot more than I do anything in or from the US, I certainly wouldn't bet my life on it.

The links below are what a quick search yielded. Not much time to dig deeper at the moment.

[1] http://web.archive.org/web/20080611115027/http://www.treas.g...

[2] http://web.archive.org/web/20060717203642/http://useu.usmiss...

You're correct - but only with the big international banks. The tax issue is a different can of worms. At least there's a pretty good chance that NSA doesn't have a back door to wuala.

I don't know if they have a similar system for wired traffic, but the Swiss have one of the most extensive COMINT systems called Onyx http://en.wikipedia.org/wiki/Onyx_(interception_system) that primarily focuses on satellite. Regardless of US gov't pressure, I think it's a reasonable assumption the Swiss gov't has access.

Right. That mostly has to do with FATCA, the legislation Congress passed to try to get US persons/entities to stop hiding money overseas in tax shelters: http://en.wikipedia.org/wiki/FATCA

That might protect your "data at rest", but communicating with a foreign endpoint makes your "data in motion" even more vulnerable to NSA spying. http://www.zdnet.com/the-lunacy-of-trying-to-avoid-nsa-spyin...

It protects you against a certain kind of threat, namely the National Security Letter that can force a US-based company to install backdoors in their system while forbidding them from telling anyone that they have been forced to do so. If SpiderOak had been compromised by the US government forcing them to install a backdoor, they would be forbidden by law from telling anyone about this. They would not be allowed to remove the clauses from their service description that claim no-one is able to decrypt your data.

This is the special risk of dealing with US-based companies. They can be forced to install decryption backdoors or hand over their users' data while continuing to tell the users they are unable to do so. So you must assume no US-based service is truly secure.

I certainly understand the sentiment given recent events. :(

For what it's worth, SpiderOak Blue is often purchased by enterprise customers as a "private cloud", where an organization can run the server side components locally.

By the way, if I recall correctly, Wuala is owned by LaCie which is owned by Seagate, which is US based. IMO, open products are the solution. We're making it a priority.

What about BitSync, it strikes me as good option, but i'm no crypto guy. http://labs.bittorrent.com/experiments/sync.html

Bitsync is very good but it is not quite a dropbox clone as it lacks the ability to retrieve the files via web, it does very limited version control, it has a pretty rigid structure of sync'd folders (for instance you can't sync a subfolder of a folder you are already syncing). Some of those functions can be implemented using owncloud but this latter is still bit buggy and requires you to have server space.

It is not as polished as Dropbox yet, but since this is Hacker News one solution would be to have BitTorrent Sync running on a home server then you could just SSH/sFTP to retrieve files. I have a Raspberry Pi running 24/7 on my home broadband with DDNS + BitTorrent Sync on it.

That's my preferred option. I like my data to sit on my computers.

Just noticed the iOS app has dropped.

Might take a serious look at it now...

Valid point. Conversely though (I'm probably over simplifying here) wouldn't this require some sort of secret instructions in the encryption software to send the user's key to HQ? Wouldn't said transmission be detectable by logging traffic from the encryption program? Granted many won't do that but it would only take one person sniffing packets on their machine to reveal it.

The password would be a number of bytes. They could easily use stenography and hide it in an upload or download of the file. Or have an update that would weakly encrypt the data, or encrypt and decrypt to a key known to them, making it trivial to retrieve the data.

Without the source, their security is meaningless. You've just given a closed source application access to the network, and to your files. You've already lost the game.

Edit: Thinking about it, this is the real problem with encryption: the good is the enemy of the perfect. A 90% solution is worse than a half assed one, because you know not to trust the bad solution.

Looks like you were bitten by autocorrect (and meant steganography).

You only need to transmit the key once, and the timeframe for that is anytime between installation and the first request of the NSA.

That is a lot of regular ping message, directory listing, software update that can be overlooked in that period.

As another commenter pointed out that you voluntarily give the password if you use the web UI. Probably the same if you use a mobile client. So there is build-in room for honest mistake in their service definition.

So basically, you still need to trust a third party, and looking at the recent news, they are really out there to get you.

Another thing that nobody is talking about and at the heart of internet. What about all those SSL certificates ?

I use Wuala, but only because I think I can trust more Swiss than US based software company.

That being said, it's all about trust, since both are closed source and there's only trust that's left to the users.

I wish there existed an ubiquitous open source alternative.

I was typing another comment just as you posted this but making essentially the same point.

If you are using Linux, FreeBSD or Mac OSX you can use local open source encryption before your data touches the sync program (or even the online backup servers) with EncFS.[1] I'm using it with Dropbox and it is solid, easy to use and set up, and does efficient file-based encryption (so no re-uploading folders just because you changed a file inside).

Gnome desktops even have the Gnome EncFS Manager[2] if you want a GUI way to set it up.

[1]https://en.wikipedia.org/wiki/EncFS [2]https://bitbucket.org/obensonne/gnome-encfs/

Thanks for the info, but I said ubiquitous exactly because I need something that "just works" on each one of Windows, Linux, Android and iOS. And I'm not aware of any open source solution there, hence have to use Wuala.

Linux & OS X: encfs

Windows: encfs4win

Android: Cryptonite

iOS: Boxcryptor

Granted Boxcryptor isn't open source, but otherwise you get yourself a full encfs-compatible Dropbox stack.

IIRC, Boxcryptor isn't specific to iOS, I have it running on OSX at home, and I believe it also runs on Windows, though I've never had a reason to put it on my VM.

Sure, though the key redeeming point of the product would be that it's compatible with the (notably open-source) encfs.

There is Tarsnap. While it has licensing restrictions that prevent it from meeting the Free Software or Open Source definitions, the source code is available to study and build yourself. It's run by Colin Percival (cperciva here on HN, former FreeBSD security officer and designer of scrypt, bsdiff, and other useful tools), who many consider quite trustworthy. Data is stored on Amazon AWS, which you may not like, but since it's all encrypted client side all they can really do is traffic analysis.

The big advantage of Tarsnap is that it supports efficient encrypted deduplicated snapshots; it only stores block that have not been stored before, so you can have many versioned backups using much less space than they would otherwise.

Unfortunately, Wuala was bought by the French company LaCie. No idea where they have their data nowadays, but I'm guessing France, since LaCie made them give up P2P storage functionality, likely leading to a sudden higher storage demand.

Yeah I wish it was more common reaction to America based services. Especially for foreigners it's like putting public folder out there on the Internet which is fine for cat pictures but not really something you want any sort of private data on. One interface might be more shiny than the other or maybe one of the services offer few more GB's what's good is that when there are 100's or 1000's individuals who are in position to read your data at will at any moment.

Just sidestep the whole issue and encrypt the contents with a key only you know/possess. Then the choice is simply "who gives me the simplest offsite platform with the fewest layers of abstraction (preferably none) between my data and the underlying filesystem".[1]

Switzerland is not some magic amulet that solves these problems once and for all.

[1] You know who that is.

Won't syncing an encrypted file store result in a lot of sync churning each time you modify a file inside, because deltas won't work?

With a properly designed container, it should (and that's actually a feature, else you're much more vulnerable to traffic analysis). That's a tradeoff between security and convenience, IMHO.

I really don't think it matters what platform you use, as long as you use you own software to encrypt and do it locally, it doesn't matter much if someone else can access your cloud store. Personally, I use AWS because it's a mature platform with good support and the chances of me loosing data are astronomically slim. But as far as Amazon is concerned, I'm just uploading noise.

Reply on news.ycombinator.com