Hacker News Reader

Comment by aboodman | Hacker News Reader

I'm always a little tweaked when somebody pitching a client product says "we can't access your data".

Am I running your software in a process that has network access? Then you can access my data.

I understand the point you're trying to make, and I totally get that architecting a system so that unencrypted data doesn't leave my device is superior to an architecture where it does.

But I still must, ultimately, trust you, your competence, and your motivations. If I trust that you don't want to access my data, and have tried to architect your systems so that is hard to do, and are competent to do so, then I can trust my data is probably safe.

But that's not the same as it being physically impossible for you to access my data.

View on HN

In Tahoe-LAFS, it is actually a proven truth that, up to the level of cryptographic unguessability, server operators cannot read stored files without knowing the client-side key. If you can prove otherwise, then you can earn a spot in their hall of fame: https://tahoe-lafs.org/hacktahoelafs/

Tahoe-LAFS providers like Least Authority [1] and Matador Cloud [2] pride themselves on not being able to access your data.

[1] https://leastauthority.com/ [2] https://matador.cloud/

Like OP said, having that design is valuable, but you're still running someone's software on your computer.

With Tahoe LAFS, you're either downloading the pre-built binary or compiling from source. Either way, you're trusting the person who signed the binary/source or the person who hosts them.

This is similar to when Apple says they can't read your messages. Sure, they may not able to decrypt the data on their server, but they're in total control of the client software. They can get access to your messages.

I do think it's in Tahoe/Apple/etc's interest to NOT be able to see their data. For one, they said they can't and reputations are important. It may also be beneficial when dealing with law enforcement requests. So trusting them isn't totally unwarranted, but there's a lot there that isn't mathematics.

(You're never going to get to 100% math, but there are ways to get further. For example, someone might eventually write a Tahoe LAFS client that comes with a machine-checkable proof that it doesn't leak plaintext. You now need to trust the proof checker, but it's progress.)

The client could be open source; indeed the network protocol might even be simple. The client distribution or even implementation might be handled by third party. If for commercial reasons the provider wants a fancy shell and doesn't trust the open source or third party for that, they might consider a locally-untrusted (and possibly even remotely run) GUI that is a frontend for your local (trusted, open-source) backup engine.

I believe you can architect a solution such that it's easy enough to get a third party (or yourself) to verify it is safe and private, even in the face of a hostile backup provider (or more realistically, a backup provider that's met an opportunistic law enforcement agency waving a sternly worded letter).

If enough parties collude, they can still gain access to your data, but at that point I'm pretty sure the backups won't be the weakest link anymore.

I mean, you're still running an OS, and compiling with a compiler, installing and running software from a package distributor, and using a CPU with a management engine, and all those things might have backdoors too.

What do you want then? Only use software you've written yourself, on a non-networked computer?

Like I said, I don't think it's unreasonable to trust Apple or the Tahoe LAFS download server. I think they're improving the state of security and I would use those products. I just want people to be clear about the actual security properties of the whole system.

For example, people should know that blanket statements like "Apple cannot read your messages" are false. And your client/server protocol can be state of the art, but you still rely on the much-maligned HTTPS certificate infrastructure (among other things) to get the client bits.

Tahoe-LAFS is really awesome open project by great people with a rich history of solving complex problems.

If this space is interesting to you, spending a few days reading through their Trac is educational and rewarding! Highly recommended.

Trivia: One of the founders of LAFS went on to found Zcash, the (actually) zero knowledge crypto currency.

Yeah in that case Tahoe-LAFS and the storage providers are different entities. So if you trust the Tahoe-LAFS developers, then you don't need to trust the storage providers.

You wouldn't have to trust them if they made the client open source. It still baffles me that they're aren't doing that given that their entire sales pitch is about security and privacy and "no knowledge".

I'm a paying customer and I use SpiderOak for some non-critical backup/synchronization tasks but I refrain from using it for anything sensitive because of this.

I'd also like to be able to hack the client to remove all the cruft I don't need, it's not exactly pleasant to use currently. On linux I'd actually prefer a good CLI over the weird GUI we have now.

Thank you for the feedback and we'll be working on it!

FYI, many people do use SpiderOak exclusively from the command line. It's fairly scriptable.

Here's the command line options: https://spideroak.com/faq/how-can-i-use-spideroak-from-the-c...

Also, the source code for our other products (Encryptr, Semaphor) is published. SpiderOakONE was first developed in 2006 and open source business models were not so popular at the time. It's been much harder than I thought it would be to make SpiderOakONE open source but one glorious day we will get there. https://spideroak.com/solutions/semaphor/source

> I'm always a little tweaked when somebody pitching a client product says "we can't access your data".

If their privacy policy prevents them from accessing your data unless authorized, then this isn't an unreasonable statement.

Often a company needs data for a certain purpose, but there is no good technical solution for enforcing that. This is where privacy policies can benefit users, by providing a legal agreement to protect users beyond the abilities of the underlying technology.

If the service doesn't enforce end-to-end encryption of customer data, then it's a misleading statement.

How would you recommend phrasing it?

Your typical user is much more at risk with end-to-end encryption than with a well-architected SaaS product, since their likelihood of being a victim of some sort of easily preventable fraud is much more likely than them having their data misappropriated. (Think of how Gmail automatically handles con artists, phishing scams, viruses, XSS attacks, SPF/DKIM/DMARC, etc.)

Because of this, users tend to be better off having their data protected through a combination of technology and legal agreements rather than protected solely through technology, although this can be difficult to communicate.

E.g. how would you communicate to your (archetypal) grandmother that she's better off using Gmail than the same sort of setup as Edward Snowden, and make her feel safe doing so?

> Your typical user is much more at risk with end-to-end encryption

Not all e2ee products are created equal. I think your description is accurate for the PGP ecosystem, because for example it's hard to be sure you've got the right key from the key servers, and anyone who can use email can contact you. In fact most crypto folks I know believe email is an unsecurable platform.

However good e2ee systems provide strong Authentication of the data's origin, which is often more valuable than the encryption. In SpiderOak's Semaphor for example, a team admin approves new team members before they can communicate with other people on the team. It's explicitly a tool intended for safe internal communication with a specific in group, such as an enterprise team.

Whenever a non-technical salesman (or CS rep) tells me "we can't access your data", I usually smile and take it to mean "I personally don't have access to a GUI for sifting through your data". Not that such an interface it likely to exist at all, but that I don't trust them to know anything more detailed than that.

Right, that's why I think SpiderOak (and preferably the whole industry; Signal, WhatsApp, etc. are in the same boat) having a marketing term for this is important: "our product, if properly implemented, is designed in a way where nobody can build me that GUI" is meaningfully different.

Yeah, I wish there was a way to communicate this property.

Well it depends on if you can run the software in an isolated network. I can trust client software a lot more that can run on a machine isolated from Internet access. If someone pitches a product like that to me, then I can proceed without really having to trust them.

I said that -- "process with network access".

If I'm running your software, and there exists any channel by which that software can talk to you, then ultimately you can access whatever that software has access to.

"network access" is not the same as "Internet access". It seems pedantic, but there are very large networks with no connectivity to the Internet.

>But I still must, ultimately, trust you, your competence, and your motivations.

This is true about any entity that has access to your data, including your bank, health insurance, or any other organisation which you have an account with. It is true that they don't say they can't access your data though...

Regarding their motivation - having developed a system with end to end encryption for sensitive information, I can tell you that the worst thing from both a business and professional perspective would be a data security breach - that gives quite a lot of motivation to get things right...

Reply on news.ycombinator.com