If the data is sensitive, you should be encrypting it anyway before passing it along to a third party thatr has no business looking at it. If the data isn't sensitive enough to encrypt, why do you care where Google keeps it?

I can't control the sender (can't ask all of them to send the emails exclusively in encrypted form) and there's no warranty that the message is not intercepted while in transit (actually, with this crazy ISP data retention laws popping up everywhere, high chances that the messages are actually intercepted).

Just because the people in charge of your bonus are unreasonable does not suddenly mean that shipping the data off is suddenly reasonable. You might choose to make an unreasonable choice for personal financial gain, but from a data security standpoint, it's still unreasonable.

Even Google doesn't believe that it doesn't matter where the data is. When Kazakhstan said all.kz domains had to be hosted in that country, Google just walked away from providing Kazakh-tailored search. "If we were to operate google.kz only via servers located inside Kazakhstan, we would be helping to create a fractured Internet," said Google senior vice president for engineering Bill Coughran.

I hesitate to agree with Gartner about anything, but you can't trust that Google won't not only turn over your data to any jurisdiction that asks, but will likely cooperate with and not try to contest virtually any sort of court order or even law enforcement request. With a government-agency level of threat model, though, you shouldn't be storing information on computers that are ever hooked to the internet.

To the average person, sending it off to a third party is as secure, if not more, than on their own personal computer. It is more likely to have backups, and the if it's a reputable third party, they will only use your data for advertising, not for emptying your bank account, which is what might happen if you get a keylogger on your computer.

Really. There is a surprising number of people who don't have backups.

If the data
isn't sensitive enough to encrypt, why do you care where Google keeps it?

Sensitive or no, Google has no right to snoop on your data.

Besides, what may not be sensitive when you've got it, can become sensitive when someone else has got it.

For example: you and a friend both own half of a secret password. One piece alone is worthless, so you don't mind if Google knows your half. Similarly, your friend doesn't care if Google knows his half. Result: Google knows both halves.

What's true for passwords is also true for people's information profiles in general. Company A might know where you buy diapers, company B knows what movies you watch, company C knows your address, etc.

Google will just hand it over to any Federal agency, pretty much on a whim, because said agency heard a rumor that your farts smell like a terrorists, and they will snoop on your data. Spank you very much Patriot act.

And all this talk of encryption is laughable for the same reason(like THEY don't have the keys to the commercial encryption "castle"?), unless you are willing to go well above and beyond any semi-standard keylength (like 4096+) to at least offer some level of difficulty.

The only problem is that algorithms deal quite badly with encrypted data. Your solution is only viable if you want to store the data and do nothing else with it, what I'd have to say, is a quite bad architecture. You'd better saving everything into/dev/null.

The issue is that you cannot work with encrypted data - you have to decrypt it first. Which means either decryption in the cloud, or forced download of entire databases to each client.

Latter is not an option for most cases of work, and former is the problem that OP raises. Encryption is not a defense against cloud provider if cloud provider has the keys to decrypt. It only provides protection against man in the middle attack.

Actually you can encrypt the data itself, but not the database. Basicly the client side would have to send, I want the address, email and phone number for person whos hash value = (hash key), the cloud looks up the hash, sends back the information in encrypted form associated with that hash, decrypts it, then uses it for whatever is needed. Upon changing it, the client encrypts it before updating the cloud. The server would not know the actual data unless they got the encryption key. the downside to this wo

If the data is sensitive, you should be encrypting it anyway before passing it along to a third party that has no business looking at it. If the data isn't sensitive enough to encrypt, why do you care where Google keeps it?

Realistically speaking, how are you going to get your employees to never use the built-in save function in their apps?

My understanding, correct me if I'm wrong, is that the "save" button will essentially work as a button that uploads a document to the cloud. Each separate app would need its own built-in encryption and decryption if it's going to be practical from a user perspective.

Sure, because if the data is encrypted, the only people who can get into it are those with gigantic server farms. (Like Google)

Besides, who would be interested in random encrypted data? It would be cost prohibitive to decrypt data to peek at it, unless there are advances in supercomputing. (Which google is actively working on)

The only company which would want to do that is one which has a business model built on collecting and monetizing private data (See: Google)

Yep. I can't see any reason why people should care about where they store cloud data.

So, if Google's advanced supercomputer can crack a billion keys/second and they have 1 billion computers at their disposal to do the cracking, it would only take them around 1 x 10^17 years to crack your data.

Of course, now that you've figured out their plan, they're going to have to kill you, and they will surely do so within 1 x 10^2 years.

Even if the data is encrypted, if you're using a virtual server in The Cloud, then the server requires the key to decrypt it, and anyone with access to that virtual machine can then read the data.

Encryption would only make the data safe if you're reading it back from The Cloud, processing it, and sending updates back to The Cloud. Which would seem an odd way to do things unless you want to have access to the same data from multiple sites around the world.

I think he has misunderstood his friend. What his friend was probably driving at is that you can do statistical analysis on data that has been "anonymized" through the encryption or removal of personally identifying information such as name address and credit/loyalty card info. You are correct, properly encrypted data should be hard to differentiate from a random bit stream.

Even if the data is encrypted, if you're using a virtual server in The Cloud, then the server requires the key to decrypt it, and anyone with access to that virtual machine can then read the data.

Then don't do that -- obviously if your cloud provider has both your encyption key and encrypted data, they can decrypt the data.

if your data is so sensitive that you're worry about it residing on a disk drive in Nigeria, then you should probably be just as worried when it resides on a disk drive in your own datacenter in NYC - someone can steal it either way regardless of local laws.

Encryption would only make the data safe if you're reading it back from The Cloud, processing it, and sending updates back to The Cloud. Which would seem an odd way to do things unless you want to have access to the same data from multiple sites around the world.

Many applications have sensitive data that a few people should have access to, and non-sensitive data that the world can see.

Encryption would only make the data safe if you're reading it back from The Cloud, processing it, and sending updates back to The Cloud. Which would seem an odd way to do things unless you want to have access to the same data from multiple sites around the world.

It's not and odd way to do things. It's very rational. If you use your own encryption, it works just like any other encrypted file. The server can't read it, because you never give it the key.

And you don't need to have to want access from around the world. You can simply want access from more than one computer or device. Even in the same home, you might want to have a file that you can open from any computer. And even if you only have one computer, the cloud makes for a good backup.

"Even if the data is encrypted, if you're using a virtual server in The Cloud, then the server requires the key to decrypt it, and anyone with access to that virtual machine can then read the data."

I made this same argument at work (Fortune 10 company), nobody had apparently thought of that - not only does your 'cloud' application need the key, but we also outsource most of the coding to India, Mexico, etc. If you lay off one of those people (or, uh, 'end their contract') they could potentially walk with the key and post it on the 'net, giving millions of potential hackers the key to get to your 'cloud data' (this holds even if your app is internal using the cloud only for data storage).

Why do your developers have the encryption key to the production database? No single person should have access to the complete key. And you should rotate keys regularly so even if someone does steal your key, it has a limited lifetime.

Sure, because if the data is encrypted, the only people who can get into it are those with gigantic server farms. (Like Google)

This is a classic failure to perform risk analysis. There are risks associated with any data management plan. Storing the data on hosts maintained by your company can be extremely dangerous, especially if maintaining that environment isn't part of your company's core competency. All too often, companies find out that what they thought was a knowledgeable CTO was really just winging it, and hoping the IT staff they hired knew more than they did.

People have been criticizing Google based on "what if" scenarios for years now.

But the reality is that it would only take 1 single case of Google digging into someone's private data (ie. unencrypting private data) and the media would jump on it and google would lose 90% of its business almost overnight.

That doesn't make them safe, but I really cant see why Google would want to take that risk.

People know that Google use their data for the purposes of profiling them and re-using the data in targetted advertis

I'm sorry, but on the trust scale, Google, who has yet to lie to me, wins big over Gartner, who lies through their teeth every time they review a product. I still recall Gartner recommending WinME. 'Nuff said there....

I don't trust Google with my sensitive data because I assume it will be analyzed, packaged, and sold to marketers and advertisers. I have some faith that it is anonymized first, but even still I don't like it and you have to wonder how anonymous the data actually is.

I don't trust Google with my sensitive data because I assume it will be analyzed, packaged, and sold to marketers and advertisers. I have some faith that it is anonymized first, but even still I don't like it and you have to wonder how anonymous the data actually is.

I would rather retain 100% control of access to my data.

If you think any company will NOT sell any data they can regarding you on the free market you are living on cloud cuckoo land. Companies all exist to turn a profit, and if data regarding you is profitable then you can be sure they will sell it.

The problem here is that, while Gartner is indeed utterly useless, their opinion is also unnecessary to determine that Google is oozing nonsense.

Different jurisdictions have different laws on the books about what data are considered specially protected, what data are an open book for the local feds, and what data require some sort of judicial approval(and to what degree that approval is a serious consideration or a simple rubber-stamp). Therefore, the jurisdiction in which your data are located(or where your outsourcing partner has offices large enough that the local feds can motivate them to comply) is part of rather than opposed to worrying about the privacy and security of your data.

Google certainly doesn't seem to be the worst when it comes to rolling over and wagging their tail for any jackboots who come calling; but anybody who thinks that they put up extra-legal resistance to any of the major powers in which they operate is, shall we say, under the influence of excessive optimism...

Um, but Google *is* definitely lying to you. You don't need to compare reputations. What Google is saying is simply, obviously wrong: that you can trust them with read/write access to your data. Sure, if your data is something that would be of minimal value, there's no harm in it leaking. But if your data is sensitive, then unless Google is willing to indemnify you for whatever damages you'll be liable for if the data leaks, you have a fiduciary responsibility not to store your data on a Google server. And as far as I understand it, Google is not willing to indemnify you for that (realistically, how could they?).

So independent of anything Gartner says, what Google is saying is at the very least misleading for the application they are talking about. The sense in which Google is right is that if you aren't taking any precautions to protect the security of your data, either because you can't afford to or because you don't know how to, then it may well be no *worse* for you to store your data on a Google server. But if that's the case, you don't care about security anyway, so Google's entire claim is moot.

By now when I see that Gartner is at one point of an argument, the other party immediately gains points for acting against Gartner. It's starting to be like Godwin's law; once Gartner chooses your side, you loose:)

How do you take action against people who do you arm in foreign jurisdictions?

Where is the control and accountability in such situations?

When it came to proprietary software, the oft brought up issue was "who do you sue" or"who can you blame when something goes wrong"? Well, that question applies to all formsof outsourcing too, including all of this "Cloud" stuff.

*sigh*. Okay. I thought it was obvious why this "story" is not quality discussion material, but I'll explain.

The article is presented as if its subject is Eran Feigenbaum's claim that "Professionals should worry about security and privacy of data, rather than where it is stored." But instead the article is a potpourri of quotations and facts unrelated to the main problem with the claim, which the article totally ignores. Any article on the subject of this claim needs to in some way establish that security and privacy can make location irrelevant, and I would expect the supporting statements of the article to do this, but nothing in the story even approaches this basic aspect of the claim. Instead, it is filled with a number of superficially-seemingly-related-but-ultimately-off-topic anecdotes.

After presenting Feigenbaum's main claim, the article presents a "supporting argument" by Feigenbaum: "He cited a meeting in Europe where he had tracked an email sent within an office as it bounced through five countries. In this circumstance, Feigenbaum said, security trumps data sovereignty." So email currently goes through a lot of countries when it is sent from one person in an office to another, where it is likely in plain text and can be read by any number of corporate and government entities. The only way this could possibly be construed as supportive of Feigenbaum's point is if read as "Email currently goes through many nations and it is secure enough". If read with any understanding of how the email system works, it undermines Feigenbaum's point.

Then the article has Michael Cloppert "support" the argument with the same type of claim: "I'm not convinced that the data location issue is a problem - after all, packets are routinely routed around the world irrespective of the export status of their content". Again, the argument is "this is what we're doing now, therefore it is secure enough". Actual security of information going through various nations is not addressed.

Then it presents the "other side" of the argument: There is no way you can know how Google is handling your data even though they assure you they are doing it well. And their contracts have lots of language that could excuse them from legal liability if that is not the case.

Then we go back the argument supporting Feigenbaum's main point. "He said customer data can only be accessed on a need-to-know basis". This does not support 5he argument that privacy and security make location irrelevant. "[L]ess than two per cent of Google staff had entered its top secret data centres". This does not support the argument that privacy and security make location irrelevant. "Google also stamped each hard drive with unique barcodes that allowed the company to track the lifecycle of data stored on each disk." This does not support the argument that privacy and security make location irrelevant.

Then we are presented with this: "But it did not encrypt data at rest, and had no immediate plans to introduce the protection." This makes it sound like location is very important to security and privacy--that someone could entire a facility by force and read the data.

The article acheives nothing other than quoting a single-sentence, questionable claim. It presents the claim, then a number of partially related statements that are presented as "discussion" of the claim but that actually have very little to do with it. I wouldn't be surprised if the article twists what Feigenbaum actually said for sensationalistic purposes.

Security and privacy of data are affected by where the data is stored.

I may disagree about privacy, assuming encryption is secure within reason. But security of data is meaningless without access to data. "Yes, my data is super secure. It's locked inside a nuclear strike-proof vault inside Mt. Storm. Of course, it is a pain in the ass to retrieve the tapes and disks every time I need to update the database or apply a patch to the git repository or send someone a copy of the documentation." How does that help anyo

Obviously, it is Feigenbaum's job to exude nonsense where required; but the notion that worrying about where something is stored isn't part of(much less opposed to) "worry[ing] about security and privacy of data" is transparent absurdity.

Where data are, in part, determines what laws(and de-facto uses and abuses of power) they are subject to or subject to the protection of. In a number of cases(including the not-exactly-economically-insignificant case of EU businesses working with American cloud entities...) it might even turn out that storing certain sorts of data in some jurisdictions means that a given entity is in violation of data protection laws at home because the data protection laws are insufficiently strong where they are storing data.

Things like whether or not you are getting hacked by lulzsec are, of course, also important; but(until Google transforms itself into a cypherpunk utopia or sprouts a formidable nuclear deterrent), location is right up there with hackers in determining how likely your data are to be absconded with against your wishes. And(unlike hackers) you can't really code your way past the feds...

I don't think the Google exec is listening to himself. If I am concerned with the security and privacy of my data then where it is stored and who has access to it are going to be pretty close to the top of the list of thing to be concerned about. Google still might be an ok place for it, but exec's saying things like this make me more than a little uneasy.

I didn't hear anything about Sony having their data outsourced. It didn't seem to do any good to keep sensitive data on their own servers. I think the lesson here is that all data on any networked device is at risk.

...does impact on security (real and perceived, which impacts on trust).

One can say that it is more important to trust the provider of the data storage than to trust the location. What makes any particular location untrustworthy if not the security that one can bring to bear? One provider may simply not be able to be as disciplined with their security protocols than another, while being in an area that is deemed to be more secure...like comparing Palo Alto and Namibia.

Given the number of breaches (most unreported ones by employees and former employees), it seems that hosting it elsewhere is the least of our problems. In fact, if done right, it's likely that it's more secure elsewhere because that makes it harder for the number 1 breacher (employees) to get to it.

Yeah, yeah, I know, we are supposed to ignore what actually happens and instead focus on targeted corporate breaches like anyone really cares what we do for a living.

for la-de-da things yea who cares, when your trying to get stuff done and you cant cause your document is on the cloud, which is experiencing outages, or your internet just shat on itself then yea I care where my durn spreadsheet is when someone is breathing down my neck asking for a shipping update from Indonesia

"He said businesses should worry about security and privacy of data, rather than where it is stored." -- but those aren't separate concepts. Should I worry about security if my data is located at Sony corp? Or privacy if my data is on Facebook? security and privacy is very much a function of "where", and of: "who buys out the company next". The only where where one might have some sense of security or privacy is on a drive that you control.

The US has already proved it will do whatever it wants, unwarranted, in the name of Intellectual Property Protection. What's to stop another country from doing the same thing for any number of warrant-less reasons and never giving the data back?

If that's the case why doesn't Google store its data with Amazon or Microsoft? I'm sure both Amazon and Microsoft will give Google a deal on data storage.

I think because it's more expensive and has higher latency. For a small business, Amazon S3 is much cheaper than an enterprise storage system and if you use availability zones and regions wisely, you can end up with an extremely robust storage system for not a whole lot of money.

But when you already have datacenters across the country and require petabytes of storage, it's generally cheaper to buy your own storage directly rather than buy from a intermediary... or even create your own cheap storage systems

First, it may actually be a legal requirement keeping the date in a certain jurisdiction. And second, any law enforcement or TLA access to the data will be governed by the laws of the place the date is physically stored. If the Google people do not understand that, one more reason to not hand your data to them.

Its not about securing data. Its not even about Google mis-using demographics.

Its about privacy and business value.

Most businesses are valued based on their assets, stock on hand and good will. Good will is a measure of the number of customers who continue to use the business regularly.

Good will is typically measured by looking at the CRMs and counting the number of client files that are active. Take that away, and you can no longer measure good will.

So, why does Cloud computing threaten good will? I'm glad you asked. Many consumers continue to conduct business with a particular company because 'they have my records'. Its not some kind of corporate blackmail. Its easy for the customer to continue to do business with the people that know them. This customer knowledge is held in corporate CRMs.

As soon as it becomes widely known that all CRM data is in the Cloud, there will be a gradual transition (thanks to FOI laws) of the ownership of the data moving back to the individuals instead of residing with the companies. Microsoft's HealthVault is case in point. When my medical records are owned by ME instead of owned by my doctor, I can choose to get healthcare anywhere.

There are great arguments in favour of the concept. Client service will improve out of sight when it is the yardstick for comparing companies (instead of possession of CRM data). However, show me one businessman who is prepared to give his goodwill into Google's custody, and I'll show you a big risk-taker.

Googles example of an intraoffice message being routed around the world is a classic strawman argument. It's not the individual intraoffice messages that might bounce outside the data centre (possible due to a.forward on an individual account) that worries me. That's a needle in a haystack (although the searching algs are getting much better). It is the fact that the entire storage of read and unread (i.e. webmail,imap) ends up on a server that may be in a different legal jurisdiction (and for my University, it is a different legal jurisdiction). Or, if you adopt google docs, all of your documents are stored in google's servers (and without encryption to boot!!). One US court subpoena, warrant or NSL, and all your data is vacuumed. Even though some recent cases have strengthened the notification requirement, you have to fight the subpoena or warrant in a US court under US law.

If you are just using google as a disk drive, then you can encrypt your data, but if you are actually using the google services, forget it.

"Your data"? Everyone from Facebook to the telecoms thinks of it as their data. And when the gov't comes knocking, they are unmotivated to defend it on your behalf. If they stood up for your rights, they'd expose themselves to punitive measures.

Even though some recent cases have strengthened the notification requirement, you have to fight the subpoena or warrant in a US court under US law.

Or move it offshore. Where the data center owner is less beholding to gov't thugs. And knows how to tell them to "blow it out their ass" in seven languages when they come asking.

"Your data"? Everyone from Facebook to the telecoms thinks of it as their data. And when the gov't comes knocking, they are unmotivated to defend it on your behalf. If they stood up for your rights, they'd expose themselves to punitive measures.

Uh, so it's "their" data, right up until the point they are questioned about "their" data, and then suddenly, it's not "theirs" anymore?

Don't get me wrong, you bring a valid point in that they will NOT allow themselves to get tangled up in legal issues that doesn't really involve them, but if that's the case, then the line needs to be drawn more clearly. Either you deal with the fact that it is MY data and NOT yours, or you take 100% responsibility of "your" data. I grow tired of legal loopholes and conve

Uh, so it's "their" data, right up until the point they are questioned about "their" data, and then suddenly, it's not "theirs" anymore?

Oh, its still "theirs". But they don't have any regard for it's security. So when the FBI comes asking, its "Sure. You can have it. Glad to be a patriot and help out. And thanks for not having the IRS audit our entire board of directors."

What Google, Facebook, Comcast, et al. are trying to avoid is creating a fiduciary [wikipedia.org] relationship with you over your data. They don't want an obligation to protect it on your behalf at their expense. So its "their" data to hand over. Until the kiddie porn is found. Then its

The EU can't allow their stuff to be hosted in the US where unwarranted and secretive searches are the norm. The US won't allow their stuff to be hosted in the EU because they can't trust the individual states to do the same to them.

The only solution is client-side encryption where Google etc. hosts only encrypted data and can't have access to the keys. There are projects that are working on this but this means the 'cloud' won't be hosting everything but a more hybrid approach is necessary.

Until we have one world government, differing laws on data privacy mean you have added considerable complexity for the savings of using their cloud. Maybe it is a worthwhile trade-off, maybe not. But he is silly making such a blanket statement. If you work for a company that contracts with the US Government you may be aware of ITAR and the various rules about where data can be stored.

In general, to me, the cost savings is far over shadowed by the increased risk. Even if you mitigate the risk by doing your homework and picking a state with laws that you agree with...you've just spent quite some time and money on that research.

1. If it's sensitive then it shouldn't be on the internet in any manner including hosting. 2. Knowing your legal rights is relevant, and that requires knowing where your data is hosted. If beach pictures of your wife violate Iranian law then they shouldn't be hosted in Iran. 3. Known risks. If you work for a European aircraft builder and you're trying to beat out a major American aircraft builder for a large contract then you best not host your trade secrets in the USA.

The main concerns about data location and sovereignty ARE privacy and security. These two viewpoints aren't opposed. Sure, worrying about the location of your data//for its own sake// is silly. The big reason people worry about where their data is is WITH WHOM it is: whether they can be trusted not to snoop it, sell it, carelessly lose it, or cave to a subpoena or DMCA takedown. That's the whole point.

I think I'll trust the Google's opinion about the safety/security/availability of "The Cloud!" when one of two things happens:

1) Google turns out the lights in all their data centers and moves their entire operation into someone else's cloud service.

Or

2) Google is willing to trust their entire existence to the integrity of their cloud service. This means that Sergey, Eric, Larry, and all their employees turn over stock ownership. They hand over the keys to the buildings, the data centers, the networks, the

Split each byte of data up and store parts on 10-15 different clouds. That way you have redundancy (if several clouds go down you still have enough data from the others to reconstruct your data) and security (if an attacker compromises any cloud they won't be able to get your data).

oh please, for the love of god don't suggest this, i don't think i can handle the next marketing wave of CloudRAID or RAIDCloud.