6 ms·

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

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.

hueving 10y ago
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.
- aboodman 10y ago
  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.
  - hueving 10y ago
    "network access" is not the same as "Internet access". It seems pedantic, but there are very large networks with no connectivity to the Internet.
Alex3917 10y ago
> 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.
- ghughes 10y ago
  If the service doesn't enforce end-to-end encryption of customer data, then it's a misleading statement.
  - Alex3917 10y ago
    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?
    - rarrrrrr 10y ago
      > 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.
pitaa 10y ago
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.
- geofft 10y ago
  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.
  - aboodman 10y ago
    Yeah, I wish there was a way to communicate this property.
simias 10y ago
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.
- rarrrrrr 10y ago
  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-command-line 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 https://spideroak.com/solutions/semaphor/source
placebo 10y ago
>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...
BuuQu9hu 10y ago
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/ 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/ https://leastauthority.com/ [2] https://matador.cloud/ https://matador.cloud/
- aboodman 10y ago
  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.
- cakoose 10y ago
  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.)
  - powera 10y ago
    What do you want then? Only use software you've written yourself, on a non-networked computer?

hueving 10y ago

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.

aboodman 10y ago
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.
- hueving 10y ago
  "network access" is not the same as "Internet access". It seems pedantic, but there are very large networks with no connectivity to the Internet.

Alex3917 10y ago

> 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.

ghughes 10y ago
If the service doesn't enforce end-to-end encryption of customer data, then it's a misleading statement.
- Alex3917 10y ago
  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?
  - rarrrrrr 10y ago
    > 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.

pitaa 10y ago

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.

geofft 10y ago
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.
- aboodman 10y ago
  Yeah, I wish there was a way to communicate this property.

simias 10y ago

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.

rarrrrrr 10y ago
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-command-line 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 https://spideroak.com/solutions/semaphor/source

placebo 10y ago

>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...

BuuQu9hu 10y ago

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/ 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/ https://leastauthority.com/ [2] https://matador.cloud/ https://matador.cloud/

aboodman 10y ago
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.
cakoose 10y ago
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.)
- powera 10y ago
  What do you want then? Only use software you've written yourself, on a non-networked computer?