Google's Gdrive Raises Instant Privacy Concerns

An anonymous reader writes "The rumor mill is already raging over the potential functionality and capacity for Google's online storage service we talked about earlier this week (the company says 'it makes sense' to put all its Web apps under the same umbrella). But Internet rights advocates are now crying foul over liability issues, a probable lack of encryption and a cash-cow model that could scan all your personal data for advertising keywords. From the article: "'Google would be wise to offer users an option to encrypt your information,' says Nimrod Kozlovski, a professor of Internet law at Tel Aviv University. 'It really needs to have really detailed explanations of what the legal expectations are for storing your info.'""

Encryption as a double edged sword

[pwnies]

First off, if you're that concerned about your data being secure, you probably should just store it on a personal webserver and encrypt it yourself.
That being said, I really don't see this as a major concern for Google in relation to the success of Gdrive. A large percentage of people today really don't care about whether or not their personal data is scanned an analyzed, as proven by the information people list on social networking sites like facebook, myspace, livejournal, etc.
So the real question here is whether or not Google (and the small percentage of users that would use encryption) would benefit enough from this feature to offset the time needed to develop it and the hassles that will come along with it. I think that alot of the users wont realize that if Google encrypts their data with the password that the users provide, then there will no longer be that friendly "Forgot your password? Let us reset it for you." button. People will then be constantly complaining that they can no longer access their data if they forgot their password and had it reset (Because the data is encrypted based on their old password obviously). The only way that Google would be able to recover that data for the user is a.) by brute forcing it, or b.) by using precomputed hashes in a rainbow table format (though something tells me that Google is smart enough to use salts and this wouldn't be an option). Realistically, even Google doesn't have the resources to go around brute forcing people's passwords. This means the only real way that Google could encrypt the data would be to store their passwords as plaintext in case the user forgot it, which is really just providing security as the cost of losing alot more security. All in all I don't see the process being beneficial for Google or the users.

No, Google does NOT need to use encryption

[Sycraft-fu]

Because that's not useful. If they encrypt your data for you, guess what? They have the key! If you want your data safe from them, YOU need to encrypt it. That's just how it works. If you send your data in the clear to someone else and then they encrypt it for you, that means they can get at your data. Same deal is you send them data and the encryption key as well (see AACS). The only way to give it to them, but not let them at it is for you to encrypt it yourself, and to not give them the key. Then and only then can you be assured that while they have a copy, they can't read it.

Seriously people, get Truecrypt, it isn't hard.

Re:*snerk*

[Anonymous Coward]

I'm not sure where Nimrod got such a bad rap -- as king of Assyria he was anything but a dork.

And his surname is KosloWski, not KosloVski, as it is in the fine summary.

For Encryption...

[epiphani]

Use truecrypt. Open, GPL, quick and easy.

Re:you have the choice

[skeeto]

encrypt your data you choose to store online with them

I can think of at least one interesting way to set this up using FUSE [sourceforge.net]. Once this service becomes available, someone writes a FUSE filesystem for it. Then you use encfs [sourceforge.net] to mount an encrypted filesystem on top of the mounted gdrive. Viola! Mount a gdrive locally and hide its contents from Google too.

Re:Wrong.

[Paul Rose]

Maybe I'm just completely mising your point, but:

This is patently wrong. Why can't I supply them with a public key that they use to encrypt,

Because if they are doing the encryption then they have the plaintext.

They store two copies, the text that they encrypt and allow you to read, and the plaintext that they mine for info.

Re:That's a real name?

[waztub]

Actually, Nimrod is a fairly common Israeli name. It's from the Bible.

Re:For Encryption...

[cromar]

For the lazy [truecrypt.org] :)

Looks pretty cool, but I am guessing that it couldn't be used in conjunction with gDisk. Also, "only" Windows and Linux are supported.

Re:For Encryption...

[Mazin07]

You'd have to create a local encrypted "container" (which is a filesystem in itself), fill it with data, and then put it on your gDiskDriveSpaceBox.

It's like storing a safe at the rental storage unit.

Re:Encryption as a double edged sword

[nahdude812]

The idea behind encryption is that even Google shouldn't be able to read your data. If Google holds both the encrypted data and the key, then it is barely different from having it stored unencrypted, but you get to keep your "Forgot the password to my data" option. If Google can't read your data (as is being suggested in the article), then it also can't give you access to it when you forget.

Re:you have the choice

[skeeto]

EncFS does all the work for you. You can either go with the default settings or you can choose "paranoid mode" and it cranks everything to the max. Example,

$ encfs /tmp/enc /tmp/raw

Creating new encrypted volume.
Please choose from one of the following options:
enter "x" for expert configuration mode,
enter "p" for pre-configured paranoia mode,
anything else, or an empty line will select standard mode.
?>

Standard configuration selected.

Configuration finished. The filesystem to be created has
the following properties:
Filesystem cipher: "ssl/blowfish", version 2:1:1
Filename encoding: "nameio/block", version 3:0:1
Key Size: 160 bits
Block Size: 512 bytes
Each file contains 8 byte header with unique IV data.
Filenames encoded using IV chaining mode.

Now you will need to enter a password for your filesystem.
You will need to remember this password, as there is absolutely
no recovery mechanism. However, the password can be changed
later using encfsctl.

New Encfs Password:
Verify Encfs Password:

Just had to hit enter, then make up a password.

Re:For Encryption...

[PopeRatzo]

Truecrypt is a really nice solution, not necessarily to gDrive (although it might be), but to protecting your privacy generally.

But I suggest you get it quickly. I believe that as soon as some "killer" encryption app that is user-friendly(for non-techies) and secure comes along, we will see efforts to outlaw private, personal use of encryption.

There's a guy named Zimmerman who can tell you just how badly the government would like to make it against the law to encrypt data or communications. And the idea that he got in trouble just because foreign countries could get hold of pgp is simply a flimsy excuse. There have already been cases where the personal use of encryption alone has been used as probably cause for the search and seizure of person and property.

Sure, I'm a paranoid, but that doesn't change the fact that the corporate authoritarians who are running our government are engaged in a full-court press to take away our freedom and our privacy. And they are succeeding at an unprecedented rate.

I hope one of you out there comes up with a simple app for encrypting data that works well with gDrive. And thanks, cromar, for the link to Truecrypt. I played with it a while back, but now I see that it's been improved to the point that I'm going to use it on all of my external storage.

eCryptfs

[omnirealm]

When Google provides a Linux filesystem (either native or via FUSE), people can use eCryptfs [sf.net] to prevent Google from reading the contents of their files. eCryptfs stacks on top of other filesystems and encrypts the data.