Bob Balaban's Blog


    Bob Balaban


    "Clouds", the sequel

    Bob Balaban  June 24 2008 07:15:27 PM
    Greetings, Geeks!

    I was going to write a follow-up post to my "Clouds" article of about 2 weeks ago, and the focus was going to be some interesting aspects of "cloud" architecture: how it's different from "regular" client/server, how you use it differently, and what benefits you derive thereby. I'm still going to write that article, but not today. Today is still about cloud computing, but after looking at several of the replies to my earlier post, it's clear that many people see real problems with buying into the cloud model of computing, particularly with the fact that you're handing all your data over to someone else, and you may very well not even know where that data is being stored.

    Commentator Kerr points out (rightly) that companies give their data to 3rd parties all the time, so what's the big deal? (I'm paraphrasing)

    Commentator (and former Burton Group analyst) Karen Hobert usefully distinguishes between "web centric/saas" clouds and "data center centric" clouds. Google is, I think, mostly in the former category, whereas Microsoft Online, or IBM Strategic Outsourcing, say, are in the 2nd category. Yes, Google runs from data centers, but you don't know where they are (the locations are secret), there are many of them (the number is secret), and you have no idea in most cases which one (or ones) have your data.

    Kerr's point that others already have their hands on your data is true enough, but I would claim that in order to be successful as a business, companies like Google who want to "host" not only your apps, but your data and your email/application infrastructure as well need to convince their customers that they have certain things under control:
       - Reliability. If I give you my stuff, I need to be confident that I can get it back in good shape, whenever I want it.
       - Security. I need to be confident that nobody else can hack into my stuff
       - Privacy. I need to know that the holder of my stuff (Google, Amazon, whoever) is not reading it for their own purposes. It's ok to create a search index for authorized users to access, but you better not be mining MY stuff for aggregations, usage patterns, or anything else.
       - Locality. Many users of "cloud" services don't care where their data are stored. Others do care, some are required by law to care. Financially regulated companies, for example corporate auditors, are often required by law to keep their data stored within certain political boundaries (country, state, whatever). This is true in some states within the United States, and also for many countries within the European Union. Google offers to guarantee (for an extra cost, one imagines) that if a customer has this requirement, and if Google has a data center that meets the locality requirement imposed on the customer, then that customer's data will not be stored outside that data center.

    As an aside to that last point on Locality, I heard a Google executive remark during a presentation that Google is receiving a lot of requrests from non-U.S. customers for guarantees that their data will be stored only OUTSIDE the United States. The reason for this, of course, is due to the rather fascistic (my opinion) provisions of the USA Patriot Act, which allows certain government agencies (FBI, CIA, NSA, probably others) to snoop your data by simply declaring to the holder of that data (your ISP, your phone company, a public library you visit to use their books or computers) that they need to. AND, the provider of access to your stuff is PROHIBITED from notifying you that this intrusion has happened. [sarcasm]Real "land of the free, home of the brave" stuff, huh?[/sarcasm]. As usual, those who can will vote with their feet, the rest of us have to hope that a new regime will overturn this nasty law.

    One other legalistic implication of cloud computing I wanted to point out: today it is perfectly legal for companies to snoop employees email (traffic and/or repositories) and other files, so long as the company is the owner of the computer on which the data resides. This is true in most states within the U.S., and (I am told) throughout the E.U., and probably other places as well. Of course, it's much more of a speculation to try to guess how many companies actually take advantage of this legally permissable behavior. I'm sure some do. Others may only snoop when they have a real reason to: they're worried about a specific case of industrial espionage, perhaps, or maybe a crime is being investigated.

    Naturally, the normal reaction by the "sensitive" among us to this situation is to start (or continue) encrypting everything. But there are limits on this. In Notes, you can encrypt databases stored locally on your Client machine (laptop, say), but you can't encrypt the server replica of your mail database, because if you did, the server would not be able to deliver mail to it. You can encrypt all of your outgoing mail traffic in Notes pretty easily, but you're still reliant on your Notes-generated key to do so. Are you completely certain that your employer hasn't sequestered a pre-determined set of bits which are used in all keys? Really? You're sure? Well, it was well known in the 90's that Lotus did a deal with the U.S. Government to provide them with some of the bits used in all non-NorthAmerican keys, reducing the effectiveness of any keys used outside NAmerica, and thereby making it easy for U.S. government agencies to crack encrypted messages. In return, Lotus won the right to not have to have 2 separate security systems in Notes (one for the US one for everywhere else), and also got Notes removed from the list of "weapons" maintained by the Defense Department. Being on that list was awful, it (technically/legally, though it was rarely enforced) prevented people from taking computers containing the US version of Notes out of the country.

    Anyway, the real point I'm trying to work towards is this: do employers lose the legal right to snoop employees' data when they've outsourced data storage and applications like email to Google? The employer no longer owns the computers that the stuff sits on, Google does. So your employer may no longer have the right (or the ability) to read your email. Maybe that's a good thing (depends on whose side you're viewing the issue from, I guess). But consider the flip side: if all of your stuff is on computers owned by Google, does that give Google the right to snoop it, if they choose to? I'm not a lawyer, so I don't know. I suspect part of the answer lies in the terms of whatever agreement the employer and Google contract to. Perhaps Google will readily agree not to peek at your stuff in their data centers. But if they do anyway, are they obligated to tell you about it?  What is the enforcement mechanism?

    Yet another wrinkle: within some regulated industries, the law (such as Sarbanes/Oxley in the U.S., as one example) imposes so-called "Chinese walls" between certain groups of employees. This means that for some organizations, they must institute email tracking and archiving, AND they must prevent email from flowing between certain groups. Nobody in the trading department (for example) is allowed to send email to or receive email from anyone in the analysis department. I've worked on such security features for a couple of customers, generally with Notes/Domino you would write a special purpose Extension Manager plug-in to monitor the traffic and kick back "invalid" messages (there are other ways of doing it, too). In this situation the "security" code is not reading the message (though a copy is probably being stored away somewhere, in case it's needed later), it's only scanning the From field and the recipient lists, and looking for invalid pairings.

    Still, I don't think (as of now) that Google offers a service like this (they do offer archiving and other security/spam filtering features through their Postini acquisition), I could be wrong. If someone uses a company computer to commit a crime (download kiddie porn, perpetrate embezzlement or fraud, or whatever), the company may have to accept some liability. If you set up a scam site on Google Apps and cheat people by stealing credit card numbers, or something, does that make Google liable too, because you used their computers?

    The point is that when you shove everything into "the cloud" you give up a measure of control over your content and over your operations. The implications are sometimes subtle, but nonetheless important. Should be great for the lawyers!

    (ok, NEXT post on cloud computing will, I promise, get into the architecture/geeky stuff....)

    (Need expert application development architecture/coding help? Contact me at: bbalaban,
    Follow me on Twitter @LooseleafLLC
    This article ┬ęCopyright 2009 by Looseleaf Software LLC, all rights reserved. You may link to this page, but may not copy without prior approval.

    1Kerr  06/30/2008 4:46:30 AM   Clouds , the sequel

    Hi Bob,

    Clearly there are going to be issues with cloud computing and you've raised some interesting points. Companies interested in this approach are going to need to answer all these points and I agree that the "no mining" rule will be high on most priorities. The subtle legal implications are interesting, but will not be fully worked out until test cases have been heard.

    If the big cloud providers don't provide answers to these questions, then someone else will. Certainly there are good answers. If companies are happy to offshore huge amounts of manual data processing to third party companies in India, then I don't see the problem with more automated systems.

    There will always be examples of data that is just too sensitive that the risk of exposing it to a third party is just too great. How much that will be? Not very much. Not very much at all.

    2John Smart  08/11/2008 9:39:16 AM   Clouds , the sequel

    FYI: News of a 15 hour outage of GMail & Google Apps. { Link }

    3Bob Balaban  08/12/2008 7:19:59 AM   Clouds , the sequel

    Thanks John! Interesting article.