[Discuss] Insync vs Google Drive client

[blu at nedharvey.com (Edward Ned Harvey (blu))]

> From: MBR [mailto:mbr at arlsoft.com]
> 
> I don't doubt that this is true, but could you provide a pointer to where they
> openly state this?

Google Transparency Report: http://www.google.com/transparencyreport/userdatarequests/
Looks like approx. 60,000 govt requests per year, and approximately 70% of those resulted in Google handing over user data.

They also state in their terms of service that they search your content to provide you personally relevant ads and search results.  And they assist copyright holders to identify copyright infringing material, and they search user content for various other forms of illegal content.
Terms of Service: http://www.google.com/policies/terms/
Privacy Policy: http://www.google.com/policies/privacy/

The same is true of them all - Dropbox, Box, Google Drive, MS OneDrive - They all publish similar transparency reports and privacy policies/terms of service.  I was even able to find an article where Dropbox employees discovered illegal porn in a users' account, so even without a court order or subpoena, Dropbox voluntarily turned him in, and provided his Dropbox contents as evidence to be used against him.  http://www.deseretnews.com/article/865591432/Two-Provo-men-arrested-in-separate-child-porn-investigations.html 

No problem as long as you don't have illegal content, right?  Well, if the California Highway Patrol made a "game" out of swapping nude photos they obtained from peoples' cell phones under arrest, I have to say - If you can't trust the *cops* not to use your data illegally, can you trust untold thousands of employees at a giant corporation?  Is that what you're paying them for?  Why *should* you give them access to anything?  Are they doing your work for you?  Or maybe you just like personally relevant ads and search results...  http://rt.com/usa/199807-california-nude-photos-arrestees/ 



> Sounds like you've got an interesting? product, but how do you deal with the
> problem that caused Lavabit to shut down?

The problem with Lavabit was the fact that they temporarily had decrypted user data in memory.  An email arrives over the TLS connection, exists momentarily decrypted in server memory, and then they used the destination user's public key to encrypt the message so only the intended user was able to then decrypt it.  Since they temporarily had unencrypted user data in memory, they were in the position of being able to provide that information to law enforcement, and therefore obligated to do so (upon request).  If they had refused, they would be obstructing justice and hindering criminal investigation.

Synctuary is first and foremost, focused on absolute privacy.  It's a software product that you can either download yourself and operate on your own servers, or later this month we'll have the hosted version available, so we absolutely never have any access to any of your stuff.

According to the 3rd party doctrine, you forfeit your 4th amendment rights to privacy when you voluntarily allow a 3rd party to access your information.  Like sending a postcard through the mail instead of a letter in a sealed envelope.  It comes down to a "reasonable expectation of privacy."  This means cloud service providers are obligated to hand over your information upon request.  Since they're obligated by law to provide it, and they *will* provide it, and they don't want to move mountains (like Lavabit) every time they need to satisfy a request, it implies they have to make it *easy* and low-cost for themselves to access your information, as long as it's *possible* for them to access it at all.  The only alternative is to make it impossible for the 3rd party to access, which is what Synctuary does.

To keep users' data private, even from us in the hosted version, we're using CBCrypt, https://cbcrypt.org.  In a nutshell, CBCrypt is a library that runs on the client, which takes username, password, and other stuff, and converts them into a unique asymmetric keypair.  The only feasible way to get access the private key is to work forward through the rate limiting function (scrypt, the successor to bcrypt) and painstakingly guess the users' password in the most expensive possible way.  Even this can only be done, after first compromising the users' public key somehow.  This way, you're able to authenticate to the server without ever exposing your password or private key to the server, and you're able to encrypt all information stored on the server, while the server never has access to any decryption keys.

Even if another Heartbleed or Poodle cause the SSL/TLS channel to be compromised, even if a hacker somehow gains access to the server or the backups, even if an evil employee of Microsoft or Amazon (or they get hacked) has access to the disks where the data is stored, still the data and password and encryption keys all remain secure.  Your data is as secure as your password is unguessable.