Sync.com claims it's end-to-end encrypted and that they can't decrypt your data stored on their servers. That's false.
Sync.com claims it's end-to-end encrypted and that they can't decrypt your data stored on their servers. That's false.
Posting here as I've seen Sync.com menitoned in the past in this sub. First, it's perplexing to see so many reviews online pointing out that Sync.com is end-to-end encrypted (e2ee) and that Sync.com does not have access to your unencrypted data, when at best what should be said is "it's closed source, and the company claims it's e2ee and zero-knowledge". But anyway...
I signed up to see if I can verify anything, and turns out you can verify that it's not e2ee and zero-knowledge. I uploaded a file, then shared it and Sync.com gave me a link that I can pass to friends. The link has no hash parts (that are seen only by the local browser), it looks like this:
https://ln5.sync.com/dl/XXXXXXXXXX/XXXXXXXX-XXXXXXXXXX-XXXXXXXXX-XXXXXXXXX
Putting that link in any browser gets you the unencrypted file directly - there is no password being asked.
The same URL is logged by the Sync.com server as well whenever someone requests it, hence not only can Sync.com also retrieve the unencrypted file themselves, but if it was stored encrypted then in order to produce that link that gets the unencrypted content, Sync.com must have access to your encryption key (synonymous with knowing your encryption password) ... so it can't be stated either that if you share files then those files lose e2ee somehow. What is clear is that Sync.com is not e2ee (unless your e2ee definition allows the host to know the encryption key).
Basically, it's at best server-side encrypted (like most of them are, or claim they are).
Always assume that a commercial service are always sensible enough to be able to scan your files contents for anything.
Legally, if they are hosting compromising things of any sort and don't report you for it they are in big trouble. So expect that.
Legally, if they are hosting compromising things of any sort and don't report you for it they are in big trouble. So expect that.
That's not true. What keeps Mega from being shutdown (like MegaUpload was previously), is that Mega is carefully following Australian and American laws - which do safe harbor cloud providers that host fully encrypted files.
Now, if Mega receives a copyright infringement report that includes the decryption key... then they are obligated to investigate. This is why pirated files hosted on Mega with the keys posted pubicly, are so often taken down.
It's not that Mega is decrypting the files on the backend, it's that content providers are searching for the keys and sending them to Mega when they find them.
Apple considered decrypting iCloud Photos, despite no legal obligation to do so, because of political pressure. They backed down when consumer/EFF pressure changed the narrative.
e2ee starts and ends with you.
Use rclone. If the service doesn't support it then it isn't worth it, even for free. There is no point wasting time discussing and inferring the behaviour of some opaque system you don't know what it does and most likely it doesn't do what it says on the tin.
I still hope to one day make a desktop OS do full system restore that uses rclone. Break system, buy new one, feed decypt key and server info during OOBE, click go. Desktop restored. Completely.
We can do it. We literally have the technology.
I was a user of Sync for many years. I stopped using them and started using Cryptomator to encrypt all my data after I noticed a few years ago that Sync.com removed all references and talking points on their website about end-to-end encryption.
That used to be their main selling point for using Sync over Dropbox. I stopped trusting the service after finding nothing on their website last year about encryption except a 2018 support PDF document mentioning end-to-end encryption that hadn't been updated in 5+ years.
It made me unsure if my data was encrypted anymore, so I started using Cryptomator along with Dropbox.
Seems to be a lot of misunderstanding and assumptions in that post.