4 ms·

Agreed, it's just got to work. We're working on an alternative: https://www.sync.com/your-privacy/ https://www.sync.com/your-privacy/

__jal 10y ago
Dunno why you're getting down voted. Sounds like great news to me! Will you have a Linux client? (I'm sure that's the least favorite question new services like this get.) I ripped Dropbox out by the roots on all of my systems some time back because of the contempt they display for their users. New, more privacy- and security-conscious services are nice (as are ones that don't break their users' machines and then go weaselly when caught). But I really want the option to use my own infrastructure for apps that want to store data somewhere remote. Especially for file-based services, the only argument for Dropbox is "because they're big and probably already installed"[2]. I'd deeply appreciate it if these sorts of apps would add a preference-pane for scp, at least. I have no idea if the crusty-folks-like-me market is big enough to constitute a noticeable bump in app store sales or not, but I promise, given two competing apps, I'll forgive a lot of other warts in and pay more for the one that lets me own my own data. [1] I know cloud is king, but there are a lot of us out here that want to own our own data, rather than having the cloud-overlords rent it back to us. The Omnigroup's apps are great examples of this - you can use their sync servers, but you can also (and I do) run your own WebDAV server for it. Works great, and I have paid the Omnigroup substantially more than any other single mobile app vendor for their apps. [2] Synchronization is difficult enough in some contexts that I completely get writing something more complicated there, but then we're not talking about Dropbox or their competitors anymore.
- jasonsync 10y ago
  We hope to get to a Linux client at some point, however, the demand for our Windows, Mac and mobile apps has been keeping us really busy. Our primary focus right now is on the platform, as the cloud is only king when it's stable, reliable and fast.
toddmorey 10y ago
Any plans for an API?
- jasonsync 10y ago
  We're in the planning stages.
lqdc13 10y ago
No Linux unfortunately.
aboodman 10y ago
I understand what you mean by "zero knowledge", but it bothers me when companies say things like "we can't access your data because it's encrypted client-side". If the service provider controls the code in the client (as you do), the fact is the service provider definitely can access the data, you're just choosing not to. I don't think there is much difference between encrypting client-side when you control the client, and encrypting server-side before storage. Either way you have encryption-at-rest.
- angry_octet 10y ago
  There is a difference, and its about how the data is going to leak out. If the access can only happen via a key stored on the client, the client somehow has to supply that to the attacker (whether an official attacker or not). If every user's key and data are stored on the server then a compromise of every (or any) user becomes much more feasible. There isn't really a problem of data at rest being stolen (except for laptops/cell phones/usb sticks), it is stolen while live. Overall though I would agree that you can't trust it much, because some code is downloaded from the server and then you trust that code (which can communicate with the server) with the key... Perhaps if it was in a local sandbox whose policies were enforced in a browser pref, or there was taint analysis applied to sensitive local data. In years to come people will snicker at how wide open and insecure things were back in 201x.
  - aboodman 10y ago
    If you store the keys, sure, that's less secure for sure. But just because you encrypt server side doesn't mean you store keys. What's the difference between: 1. Get key from user on client 2. Encrypt on client 3. Discard key 4. Discard unencrypted data 5. Send encrypted data to server 6. Store encrypted data and: 1. Get key from user on client 2. Send key and data to server over SSL 3. Encrypt on server in response handler 4. Discard key 5. Discard unencrypted data 6. Store encrypted data There are some differences, but I don't think it's clear which one is "better". I think it would depend on the details. Big picture: either way the developer sees the key and the unencrypted data. Either way, you are completely trusting the competence of the developer at implementing this scheme, and their trustworthiness with the key and unencrypted data. There is no such thing as "host-proof" encryption as long as the client is provided by the host.

__jal 10y ago

Dunno why you're getting down voted. Sounds like great news to me! Will you have a Linux client? (I'm sure that's the least favorite question new services like this get.) I ripped Dropbox out by the roots on all of my systems some time back because of the contempt they display for their users. New, more privacy- and security-conscious services are nice (as are ones that don't break their users' machines and then go weaselly when caught). But I really want the option to use my own infrastructure for apps that want to store data somewhere remote. Especially for file-based services, the only argument for Dropbox is "because they're big and probably already installed"[2]. I'd deeply appreciate it if these sorts of apps would add a preference-pane for scp, at least. I have no idea if the crusty-folks-like-me market is big enough to constitute a noticeable bump in app store sales or not, but I promise, given two competing apps, I'll forgive a lot of other warts in and pay more for the one that lets me own my own data. [1] I know cloud is king, but there are a lot of us out here that want to own our own data, rather than having the cloud-overlords rent it back to us. The Omnigroup's apps are great examples of this - you can use their sync servers, but you can also (and I do) run your own WebDAV server for it. Works great, and I have paid the Omnigroup substantially more than any other single mobile app vendor for their apps. [2] Synchronization is difficult enough in some contexts that I completely get writing something more complicated there, but then we're not talking about Dropbox or their competitors anymore.

jasonsync 10y ago
We hope to get to a Linux client at some point, however, the demand for our Windows, Mac and mobile apps has been keeping us really busy. Our primary focus right now is on the platform, as the cloud is only king when it's stable, reliable and fast.

toddmorey 10y ago

Any plans for an API?

jasonsync 10y ago
We're in the planning stages.

lqdc13 10y ago

No Linux unfortunately.

aboodman 10y ago

I understand what you mean by "zero knowledge", but it bothers me when companies say things like "we can't access your data because it's encrypted client-side". If the service provider controls the code in the client (as you do), the fact is the service provider definitely can access the data, you're just choosing not to. I don't think there is much difference between encrypting client-side when you control the client, and encrypting server-side before storage. Either way you have encryption-at-rest.

angry_octet 10y ago
There is a difference, and its about how the data is going to leak out. If the access can only happen via a key stored on the client, the client somehow has to supply that to the attacker (whether an official attacker or not). If every user's key and data are stored on the server then a compromise of every (or any) user becomes much more feasible. There isn't really a problem of data at rest being stolen (except for laptops/cell phones/usb sticks), it is stolen while live. Overall though I would agree that you can't trust it much, because some code is downloaded from the server and then you trust that code (which can communicate with the server) with the key... Perhaps if it was in a local sandbox whose policies were enforced in a browser pref, or there was taint analysis applied to sensitive local data. In years to come people will snicker at how wide open and insecure things were back in 201x.
- aboodman 10y ago
  If you store the keys, sure, that's less secure for sure. But just because you encrypt server side doesn't mean you store keys. What's the difference between: 1. Get key from user on client 2. Encrypt on client 3. Discard key 4. Discard unencrypted data 5. Send encrypted data to server 6. Store encrypted data and: 1. Get key from user on client 2. Send key and data to server over SSL 3. Encrypt on server in response handler 4. Discard key 5. Discard unencrypted data 6. Store encrypted data There are some differences, but I don't think it's clear which one is "better". I think it would depend on the details. Big picture: either way the developer sees the key and the unencrypted data. Either way, you are completely trusting the competence of the developer at implementing this scheme, and their trustworthiness with the key and unencrypted data. There is no such thing as "host-proof" encryption as long as the client is provided by the host.