Google tests encryption to protect users' Drive files against government demands | Hacker News Reader

Google tests encryption to protect users' Drive files against government demands

news.cnet.com

57 pointsdeclan62 comments

When I first set up my Drive account it wasn't the U.S. government I was worried about, it was Google itself. That's why I put all of the files I wanted to sync in an encrypted image (which you can create with Disk Utility on Mac OS X) and then uploaded the image. Also, to avoid re-uploading the whole shebang (which is more than a GB) I use a sparse bundle disk image which means that if I modify a single file only a small portion of the image will be re-synced with Drive.

I do the same thing, but with Truecrypt and Dropbox.

Hmm, does sparse bundle work well with TrueCrypt? Any consistency issues when sync'ing with Dropbox?

I didn't use a sparse bundle, just a TrueCrypt container. It uses the full space allocated on disk, and I've rarely had an issue (1-2 times over 4 months) with Dropbox syncing.

Thanks. I research more, and seems that TrueCrypt still does not support sparse bundle, so that's still a no go. The only option is to do what you did, sharing a full container.

But if you have a big container (say, 1GB or so), it has the drawback of re-syncing the file back-and-forth. And if you have multiple devices (including mobile, etc), this would easily became a nightmare.

That's a bummer. I love TrueCrypt for local encryption of filesystems and containers, but I wish I could use as a lightweight, on-the-fly, encryption of files. Particularly dropbox and other cloud-based storage.

Good idea. Sparse bundle gets around the fact that Google don't use block level delta sync with drive yet.

I use trucrypt + dropbox combination because DropBox has delta sync, but your way makes Drive also a good option.

The same Google whose new strategy - only two months ago -involved disabling the ability to use off-the-record on Gtalk by default in chat? Or using third-party OTR plugins (with real encryption) by replacing gtalk XMPP with Google Hangout?

http://news.en.softonic.com/google-chat-history-can-no-longe...

> One of the features of Hangouts that was really emphasized at I/O, was that you will no longer have to worry about losing anything. Chats are kept, and everything you share, like photos, is put in folders and stored.

> was that you will no longer have to worry about losing anything. Chats are kept, and everything you share, like photos, is put in folders and stored.

Let us help you by monitoring you better and recording everything you do. For your convenience and protection of course.

You know, I didn't like them. Now I despise them. They said that with a straight face. They could have just you know, not say anything, or say Facebook is doing all this stuff we can't fall behind we need this data on your because we want to target ads better or we have to comply with government regulations. That's fine. I understand that. But telling people how this is for their convenience is really demeaning.

> But telling people how this is for their convenience is really demeaning.

I see your intention here, but I think you've stepped out of touch with the vast majority of users here, and I don't mean the "people just want to share their lives on facebook, privacy be damned" kind of way.

"Chats are kept, and everything you share, like photos, is put in folders and stored" really is a feature that people want. Not being able to set a default for do/don't save all chat history should be fixed, but what you quote really is for convenience.

I search over my gtalk history all the time, as just as much useful information is in there as is in my email. I don't use the Google+ picture auto-upload, but I do use the Dropbox one, so that all the pictures I take with my phone are automatically uploaded to my dropbox folder and available on all of my computers. Those things are really convenient, and I love not having to have to think about them; they're just there when I do need them. I don't see how that could be possibly construed as only motivated by ad revenue and government regulations.

What needs to come along with those features:

1) easy to disable/enable with good granularity (per feature, per contact, altogether, etc)

2) possible to secure client-side if I want to

3) government needs to demonstrate probable cause to get warrant to get access to what is not secured client-side

4) I need to be notified within a reasonable amount of time of a warrant being served

none of those things preclude these kinds of "nothing is ever lost" features.

3) Fisa's 3-hops rule just means that you have to have an acquaintance that has an acquaintance that has an acquaintance that is on some investigative list for said warrant to apply to you.

yes, I'm certainly not claiming that those needs are met by the situation that we have now.

  > Or using third-party OTR plugins (with real encryption)
  > by replacing gtalk XMPP with Google Hangout?

Has this actually stopped working for you? On my account, Gtalk still works fine with XMPP, including OTR chats in Pidgin.

XMPP is still supported for now in Gtalk. But Google is moving away from XMPP.

Google Hangout is substantially more functional than gtalk. For example, my Class of 2017 group does 10-way hangouts most weeks to get to know each other, something which really wasn't possible with gtalk, which facilitates one-way calls between contacts. Hangouts provides a semi-private room that more people can join, and all sorts of silly things to like watching YouTube together. It's not a conspiracy to prevent you from using encryption. That's just absurd.

If you need XMPP and OTR, run Openfire on a VM. I just deployed this internally at work and we love it.

FWIW, the Google Hangout(Talk) has an option to "Turn history off". Whether or not you trust that is a different story.

The complaint is that there used to be an option to make history off by default, which no longer exists. Every chat must have its history manually disabled.

If it's not client-side encryption (where only you know the password and the stuff is encrypted on your machine before it is sent), then it's a non-starter. The government can just order Google to bypass the protections for their suspect.

I understand that's your legal theory. The article says, however, that remains an "unanswered legal question" in the United States, according to Jennifer Granick at Stanford's CIS.

And even if it's client-side encrypted, unless the client is open source there's no practical way to know whether there are backdoors, or whether a future update adds backdoors.

If they control the code they can bypass the protections for their suspect as well.

I've already lost all faith in Google.

I recommend Spider Oak as a replacement for Google Drive.

Also, don't forget Bittorrent Sync.

Be aware:

  from:	 ... <support@spideroak.com>*
  date:	 **** 2013
  subject:	 Re: [SOS #xxxx] A question about zero knowledge

  Sorry for the delay in getting back to you. Zero-knowledge
  applies only when using the SpiderOak client. When logging into the
  website with your password, you are giving the primary encryption key to
  our servers. We work hard to ensure that this key is kept safe (for
  instance, by only keeping it in memory and never writing it to disk),
  but to maintain absolute privacy, you should use only the client.

Google: the company may be taking a different approach by performing the encoding and decoding on its servers.

Spider Oak: I wish there were some open source cloud client similar to True Crypt. Something that were really easy to use, working on every system and open source. Spider Oak's client seems to be still mainly a closed source product.

I'm actually hacking right now on a personal project that might be relevant. It eschews the 'sync' metaphor and focuses more on the 'share' metaphor, though - it is not so useful for files that change frequently, but pretty robust for sharing arbitrary sets of files or data between a group of users. (It will also include user and access management).

The whole thing currently sits on top of BitTorrent although I suspect I'll end up writing a forked implementation at some point to support some extensions I'm working on.

Active, dynamic syncing is great for some kind of data but not so important for others, and I feel like that's the hurdle that needs to be overcome. More interesting to me is painless, fast, robust, and configurable sharing of relatively static data. (Some versioning may be included but it won't be a first-class system.)

Have you tried duplicity [0]? It encrypts the archives using GnuPG, uses two separate keys - one for encryption, the other for signing, and can store the backups using a multitude of protocols [1]: > Currently local file storage, scp/ssh, ftp, rsync, HSI, WebDAV, Tahoe-LAFS, and Amazon S3 are supported, and others shouldn't be difficult to add.

It is libre software and cross-platform. A number of front-ends address the issue of ease-of-use.

[0]: http://duplicity.nongnu.org/ [1]: http://duplicity.nongnu.org/features.html

I prefer Tarsnap.

cperciva posted why Tarsnap was more secure and cheaper than Duplicity a while back:

https://news.ycombinator.com/item?id=459334

Syncany looks promising. It's open source, includes client encryption and support for multiple options of storage(google,amazon,rackspace,ftp and others),and it's only 8K loc of java.

Of course it would still need a security review.

Yep, no matter how much PR bullshit they spew out, no one resonable is going to trust them with sensitive data.

I want to like SpiderOak, but transfers are painfully slow, and their OS X interface is horrible.

Do you ever notice that your Mac's camera and microphone do not have a physical off-switch?

Just like 1984.

Neither do most PCs. And even when they do, they're often implemented in software.

Which is part of why the NSA guide to securing a machine recommends that you decide whether or not you actually need the camera and microphone, and if not, you open the case and physically cut the cables.

Where is this guide?

http://www.nsa.gov/ia/mitigation_guidance/security_configura...

In addition to being a signals intelligence agency, NSA is also responsible for IT security for the federal government (and, to some extent, the nation). While it's possible they leave some of the more interesting tricks out of the public versions of these guides, their publication is in line with NSA's advice and assistance on open-source cryptography, etc.

Neither does my Sony all in one, my ThinkPad or my three Nokia phones and you're singling out the mac?

You're right: Sony, ThinkPad, and Nokia are therefore also systems of slavery.

How hard can it be to manufacture a product with an off-switch?

I'm guessing you never supported an environment where laptops had hardware switches for the WiFi card. I can't even begin to quantify the amount of support time that wastes.

If a users asks for something to happen (like a Skype call) it should just happen. To end-users, having multiple points at which the functionality they want can be switched off is just frustrating, and it costs manufacturers call center time and customer satisfaction.

The paranoid can tape over cameras and cut mic cables if they feel it's really necessary.

You really might want to consider whether "slavery" is the appropriate word for switches implemented in software.

http://sourcefednews.com/xbox-one-is-watching-you/

That is by design, not for the sake of convenience.

We have these things called transistors which allow us to turn things off these days.

It's been a long time since we had the big red IBM XT flip switch.

Even my calculator doesn't have a physical off switch.

I guess they didn't have masking tape in 1984.

Try JottaCloud. Their customer service is painfully slow, but their servers are not. Supposedly you're out of NSA's reach as well, but I'm not sure on that. Currently that's the service I'm using, but I still encrypt my files.

I had a look at JottaCloud, but was put off by a few things:

1) The location of their servers in Norway; I'm based within the EU, but quite far from Norway, and Norway doesn't scream great connectivity to me in the same way Britain, France, or Germany does;

2) Their FAQ seems a bit slapdash, e.g. "What kind of servers are my data stored on? Linux";

3) As with most other storage providers, there is no mechanism preventing the provider from accessing your files, or sharing them with third parties, no matter how much you trust them.

Last time I was using Drive, I ran into a trouble of re-synching my files with Drive after a crash. I had copy of my files on a hard drive which I was able to bring back in. I reinstalled Google Drive to learn that Google has no way to avoid the resync (ultimately making duplicates). So I gave up on Drive altogether. Their encryption efforts won't be winning me back.

"PRISM. The utility collates data that the companies are required to provide under the Foreign Intelligence Surveillance Act -- unless, crucially, it's encrypted and the government doesn't possess the key."

Couldn't they just use a hand-wavy encryption like a caesar cipher that meets the legal requirements without actually making storage any harder?

We use an app called Syncdocs to encrypt everything locally with AES256 before uploading it encrypted to Google Drive. It is simple to setup and seems to work well.

http://www.syncdocs.com/how-to-set-up-google-drive-encryptio...

Syncdocs and Boxcryptor are quite similar. What I like about Syncdocs is it enables EncFS for the folders selected to be encrypted, too.

Does anyone know of a good way to use Google Drive from Linux securely? I'm currently sitting on a 1TB Drive account with nothing really to do with it. I tried fuse-google-drive and it was so broken it was unusable.

At least BoxCryptor[1] is available for Linux. I've been using the classic version on Windows for a while. Maybe there are also similar open source solutions available for Linux.

On Windows BoxCryptor classic creates a virtual drive which you use to access the files. The actual files are stored as encrypted in Dropbox/GDrive folder. BoxCryptor can also encrypt file names.

Benefit from this approach compared to for example TrueCrypt is that works really nicely with the syncing features of these cloud storage systems as the files are still stored as individual files.

[1] https://www.boxcryptor.com/en/download

I'm not sure how Google Drive works for synchronization, but if it does like for Dropbox (automatic filesystem sync) than you could use EncFs or git-annex with encryption enabled.

Ah, I should be more specific: My issue is with accessing Google Drive on Linux at all, let alone with my data encrypted. An encrypted rsync-style remote with git-annex would be ideal of course.

I'm going to give insync a look, though I'm not thrilled about paying for something to access cloud storage that I'm not paying for.

I am using https://www.insynchq.com and it works really well.

SpiderOak is the best solution ... client side encryption and fully secured with zero-knowledge policy ....Bye Bye Drive, Skydrive & DropBox :)

If google handles the communications channel, and the "encryption" software, they still have access to everything.

This sounds like an ad for Google, including the Microsoft and Verizon bashing. The truth is that Google 'needs' to see the messages, all you other info and documents in clear text to serve ads and mine them. That's their business model and they aren't about to change it.

Oh and as other said, NSA can force them to do what Microsoft did.

There are no ads in Drive. You pay for storage, that's how it makes money.

This would mean that Google would not be able to data main user data for relevant ads. If Google wants to take small free from the encryption, I would be OK with that.

It would be also nice to have option where my data is begin stored (again for a fee if necessary). I would like mine in their Finnish data center.

Putting your data on Google's servers in Finland won't save it from the NSA. Google's headquarters are in the US, and so Google complies with "legal" US Government data requests. Your data is subject to US Government subpoena, FISA warrant, etc. if it's stored on Google's property--wherever that property happens to be.

That's incorrect. Companies must follow laws of each country. Chinese companies can't follow orders from Chinese courts if they break US laws when they operate in US.

Besides, Google has local company in each country that runs business there.

Does google data mine Drive? I always thought the monetary incentive was through the cloud storage tiers.

> If Google wants to take small free from the encryption, I would be OK with that.

You shouldn't have to pay a company to make sure they don't share your data. That is, in essence, what you're suggesting: you pay google, they encrypt your data and when the government comes a-knocking, it's safe. It's like a hack in a broken system

That may be true, but the broken system is the government, not Google. Google appears (being the operative word...) to simply be doing what they can in the current system.

However, I think you somewhat sidestepped hannibal's point. My impression was that he was saying that just by putting your files in drive for google to mine, you are effectively paying google. If they encrypt your files, it's akin to them discontinuing their monthly fee (or whatever) for the service.

So sure, if you're already paying a fee for a service then maybe you shouldn't need to pay extra for the luxury of privacy (make no mistake, privacy is a luxury these days), but Google encrypting their revenue stream means you are substituting the ad fee for the encryption fee. Seems fair to me.

As long as I use Gmail and Google drive for free (and I'm using Adblock), they have to monetize the service they provide to me somehow.

I would like to have clear option of being fed advertisements and being profiled for profits and paying for service.

Reply on news.ycombinator.com