Google Plans Service to Store Users' Data Online

achillean wrote this morning with a link to the Wall Street Journal, announcing plans we've all seen coming for a while: an online data storage service from Google. Though the article doesn't come out and call the project 'gDrive' or anything like that, it does indicate the service could be available within the next few months. "Google's push underlines a shift in how businesses and consumers approach computing. They are increasingly using the Web to access applications and files stored in massive computer data centers operated by tech companies such as Salesforce.com Inc., Microsoft Corp. and Google. Such arrangements, made possible by high-speed Internet connections between homes, offices and data centers, aim to ease users' technology headaches and, in some cases, cut their costs."

A very old idea

[Rob T Firefly]

This shouldn't be a surprise to anyone. It's Google, and it's one of the oldest ideas on the Internet which they haven't yet done; before the dot-com bubble burst there were at least half a dozen sites that claimed to provide an online "drive" of sorts - X-drive and E-drive are ones that come to mind, I think they advertised on the radio. Going further back, I remember using an online storage service on CompuServe in 1995 or so.

Re:User-centric Encryption needed

[BlueParrot]

Technically they don't actually need to implement any form of encryption other than SSL for the transfer. There's already plenty of tools arround for users to encrypt their files, and truecrypt can even create an entire filesystem inside a single encrypted file. Thus all google really needs to do is to not prevent users from uploading files they have encrypted themselves. The client-side tools already exist, no need to reinvent the wheel.

AES security and crypto in general

[Beryllium Sphere(tm)]

As the old saying goes, if you count on crypto to solve all your problems you don't understand crypto and you don't understand your problems.

The point that your data can and will be attacked while it's in plaintext is well taken. A networked machine running a web browser (the Sendmail of the 21st century) is a low security device, even with a good operating system. Google for "Scarfo", the mobster who was using PGP but also had an FBI keylogger on his computer.

As regards AES, though, we've got good reason to think it's resistant to cryptanalysis. The NSA is also in charge of protecting government secrets from foreign snoops and has approved AES for protecting classified data.

The low security of a workstation cuts both ways in an argument about gDrive: because your data is already at risk sitting on your hard drive, storing it encrypted on gDrive might not be any worse.

Security without threat modeling is like bricks without straw. What are we protecting data against? Loss, primarily. I trust Google's backups more than I trust mine (but I'd tell a client to look for a provider willing to sign an SLA). Unauthorized copying by crackers? AES should be an adequate control to cover that risk. Subpoenas? An attorney with two brain cells to rub together will subpoena the decryption keys, so no help from AES there. Vacuum-cleaner style mass government surveillance, looking for keywords like "Tibet" or "Falun Gong"? AES should prevent that. Government criminal investigation? You could (in the US) argue that surrendering the keys would be self-incrimination and end up paying a lawyer lots of money to argue the point for years. Expensive and undependable security, but then in a criminal investigation there's not much security difference between gDrive and your local machine anyway.

If you have security needs you should do an analysis like that last paragraph, only longer. For lots of people encrypted files on gDrive might be just fine.

Re:Amazon S3

[NickCatal]

rsync doesn't work with S3, but s3sync [s3sync.net] does

Re:Amazon S3

[Jon_S]

If you check the linux forums for Jungle Disk, there are lots of people having problems with the rsync over an S3 bucket mounted through WebDAV. The problem seems to be in the webdav implementation, but its a problem nonetheless.

But I hadn't found that s3sync before. That sounds like it would do the trick. Thanks Nick for the tip.

Now my only problem would be the lousy 256 kbps or whatever uplink I get with my Verizon DSL. I wouldn't mind the slow uplink but saturating the uplink also saturates the downlink (1.5 Mbps). I could never figure that out. Sure, go ahead and discourage P2P with slow uplinks, but why does that have to make the connection almost unusable to the rest of the family surfing the net or me listening to streaming radio? I actually don't do P2P, but do a lot of cartography and am always uploading large image and/or PDF files to webservers.

Re:Useless to me w/Rogers

[krayfx]

i still find that reasonable than the joke of a broadband offered by BSNL/ India. We have a 2 Mbps link with a cap of 400MB datacap, and if you exceed the base limit - you are charged 25 cents an MB! and rack up 15-20 dollars suppose you download the ubuntu ISO. Of course, the package is very cheap at 6 dollars.

512 kbps unlimited bandwidth goes for 50 dollars and 256 kbps for abt $25. i know, kinda sucks, but its getting better all the time. a few years back, many villages that did not see any kind of connectivity are now plugged, 256/ 512 kbps - which is good. Metropolitans have Wimax with similar schemes (256/ 512, and similar pricing).