Rational Survivability

By now you’ve undoubtedly heard that Google had a little operational hiccup.  I particularly enjoyed Craig Labovitz’s (arbor) account of “The Great GoogleLapse”

When a suite of services that account for a projected 5% of the entire Intertube’s traffic shits the bed, people pay attention.

Sometimes for the wrong reasons.

Conspiracy theories, rumors of the end of days and chants of “don’t trust the Cloud!” start to fly when operational issues such as the routing boo-boo that hit Google turn up.

The reality is that in the grand scheme of things, we should take the three salient points from this experience and move on:

1. Cloud services — even those with the scale, maturity and operational track-record of Google — still depend on fundamentally weak, insecure and unstable infrastructure that is easy to screw up.
   This is the premise for my upcoming Black Hat talk titled “Cloudifornication: Indiscriminate Information Intercourse Involving Internet Infrastructure.”
2. You ought to have a Plan B. That maybe difficult as it relates to Cloud-based SaaS application offerings and service which, by definition, tend to tie you to the platform/provider offering them.
3. This isn’t going to stop anyone from moving to the Cloud.  It may give people pause and they may spend a few more cycles evaluating what Plan B might mean, but it also pushes the agendas of hybrid architectures like Google’s NaCl and client-side hypervisors for “off-line” Cloud goodness.  All in all, it’s a nice reminder, but Cloud goes on.

The economic lubricant provided by the Astro Glide that is Cloud is just too compelling. If someone hasn’t factored potential widespread outages from single-sourced providers, shame on them; that’s poor risk assessment.

Yes, we’ve got lots of attendant issues to solve when it comes to Cloud.  Many of them, I have so soapboxed, are the same ones we’ve had for a long while.  To those of us who recognize the Internet Cloud for what it is, Google’s outage was simply an opportunity to order another Hoffachino.

What doesn’t kill us makes us…just as insecure and potentially unavailable due to some monkey pushing the wrong button as we’ve always been.

Besides, now we know that outsourcing your traffic to China is the sux0r.

So chill.  Learn from this.  Use it to form rational arguments about how to deal with this sort of thing when it does happen — because it’s going to again, just like it always has.  Remember?

Worse comes to worse, may I suggest one of these — it is the cure for all your woes anyway, right?

/Hoff

This will be a quickie.  

This is such a juicy topic and really merits a ton more than just a mention, but unfortunately, I’m out of time.

Google’s latest updates to the Google App Engine Platform has all sorts of interesting  functionality:

• Access to firewalled data: grant policy-controlled access to your data behind the firewall.
• Cron support: schedule tasks like report generation or DB clean-up at an interval of your choosing.
• Database import: move GBs of data easily into your App Engine app. Matching export capabilities are coming soon, hopefully within a month.

To me, the most interesting is the boldfaced item above…Google Apps access to information behind corporate firewalls*

From a Cloud interoperability and integration perspective, this is fantastic.  From a security perspective, I am as intrigued and concerned as I am about anytime I hear “access internal data from an external service.”

The capability to gain access to internal data is provided by the Secure Data Connector.  You can find reasonably detailed information about it here.

Here’s how it works:

SDC forms an encrypted connection between your data and Google Apps. SDC lets you control who in your domain can access which resources using Google Apps.

SDC works with Google Apps to provide data connectivity and enable IT administrators to control the data and services that are accessible in Google Apps. With SDC, you can build private gadgets, spreadsheets, and applications that interact with your existing corporate systems.

The following illustration shows SDC connection components.

The steps are:

1. Google Apps forwards authorized data requests from users who are within the Google Apps domain to the Google tunnel protocol servers.
2. The tunnel servers validate that a user is authorized to make the request to the specified resource. Google tunnel servers are connected by an encrypted tunnel to SDC, which runs within a company’s internal network.
3. The tunnel protocol allows SDC to connect to a Google tunnel server, authenticate, and encrypt the data that flows across the Internet.
4. SDC uses resource rules to validate if a user is authorized to make a request to a specified resource.
5. An optional intranet firewall can be used to provide extra network security.
6. SDC performs a network request to the specified resource or services.
7. The service verifies the signed requests and if the user is authorized, returns the data.

From a security perspective, access control and confidentiality are provided by filters, resource rules, and SSL/TLS encrypted tunnels.  We’ll take this apart in detail (as time permits) later.

In the mean time, here’s a link to the SDC Security guide for developers.

…and no, you’re firewall likely won’t help save you (again.) 

At least I won’t be bored now.

/Hoff

* The database import/export is profound also. Craig Balding followed up with his OAuth-focused commentary here.

“I do not think this means what you think it means…”

This isn’t a post specific to Google’s struggles with privacy, specifically, but rather the Electronic Privacy Information Center’s (EPIC) tactics in a complaint/petition filed with the FTC in which EPIC claims that the privacy and security risks associated with Google’s “Cloud Computing Services” are inadequate, injurious to consumers, and that Google has engaged in “unfair and/or deceptive trade policies.”  

EPIC is petitioning the FTC to “..enjoin Google from offering such services until safeguards are verifiable established” as well as compel them to “…contribute $5,000,000 to a public fund that will help support, research concerning privacy enhancing technologies.”

In reading the petition which you can find here, you will notice that parallels are drawn and overtly called out that liken Google’s recent issues to that of TJX and ChoicePoint.  The report is a rambling mess of hyperbolic references and footnotes which appears is meant to froth the FTC into action, especially by suggesting the overt comparison to the breaches of confidential information from the likes of the aforementioned companies.

EPIC suggests that Google’s indadequate security is both an unfair business practice and a deceptive trade practice and while these two claims make up the meat of the complaint, they represent the smallest amount of text in the report with the most amount of emotive melodrama: “…consumer’s justified privacy expectations were dashed…” “…the Google Docs Data Breach exposed consumers’ personal information…”  I can haz evidence of these claims, please?

While I’m not happy with some of Google’s practices as they relate to privacy, nor am I pleased with hiccups they’ve had with services like GMail and the most recent “privacy pollution” issue surrounding Google Docs, here’s an interesting factoid that EPIC seems to have missed:

Google Apps like those mentioned are FREE. We consumers are not engaging in “Trade” when we don’t pay for said services. Further, we as consumers must accept the risk associated with said offerings when we agree to the terms of service. Right, wrong, or indifferent, you get what you pay for and should expect NO privacy despite Google’s best efforts to provide it (or not.)

I could tolerate this pandering to the FTC if it were not for what amounts to the jumping the shark on the part of EPIC by plastering Cloud Computing as the root of all evil (with Google as the ringmaster) and the blatant publicity stunt and fundraising attempt by demanding that the FTC “compel” Google to bleed out $5,000,000 to a fund that would likely feed more of this sort of drivel.

If we want privacy advancements with Google or any Cloud Computing service provider, this isn’t the way to do it.

As my good friend David Mortman said “EPIC apparently thinks its all about publicity. They are turning into the peta of privacy.” 

I agree. What’s next?  Will we rename personally identifiable information to “information kittens?”

/Hoff

P.S. Again, I am not trying to downplay any concerns with privacy in Cloud Computing because EPIC’s report does do a reasonable job of highlighting issues.  My friend Zach Lanier (@quine) did a great job summarizing his reaction to the post here:

It’s almost as though EPIC need to remind everyone that they still exist

and haven’t become entirely decrepit and overshadowed by the EFF. The

document is well assembled, citing examples that most users *don’t*

consider when using Google services (or just about any *aaS, for that

matter). Incidentally, the complaint references a recently published

report from the World Privacy Forum on privacy risks in Cloud

Computing[1]. Both documents raise a few similar points.

 

For example, how many of us actually read, end-to-end, the TOS and

privacy policy of the Provider? How many of us validate claims like

“your data are safe from unauthorized access when you store it on our

Cumulonimbus Mega Awesome Cloud Storage Platform”?

 

I, for one, laud EPIC’s past efforts and the heart whence this complaint

emerges. However, like a few others, the request for enjoinment

basically negated my support for the complaint in its entirety.

 

[1] http://www.worldprivacyforum.org/pdf/WPF_Cloud_Privacy_Report.pdf),

— Zach Lanier | http://n0where.org/ | (617) 606-3451 FP: 7CC5 5DEE E46F 5F41 9913 1577 E320 1D64 A200 AB49

I find this case extremely fascinating on many levels.  From eWeek:

You can see the original story from the International Association of Privacy Professionals (IAPP) here.

The implications of this are quite profound as you can imagine.  CEO's and CFO's can be held accountable for crimes committed under their watch, so it's not too far of a stretch to see how privacy officers like Fleischer will have their feet held to the fire when subject to international law that takes a different perspective on the responsibilities associated with privacy than we might. 

How many indictments have we had in the U.S. for the release of information in corporate breaches?  The U.K.?

I'm not making a judgment call on this particular case because I certainly don't have all of the details, but it sets a very interseting precedent.

Imagine if you were a Chief Privacy Officer or perhaps a Chief Information Officer subject to this sort of scrutiny outside of the due care and stewardship requirements of the job in general.  If something bad happens, generally the worst thing that might occur is you lose your job.

Imagine if you were personally liable for the posting of content from millions of users globally and could be sentenced to share a shower and a cell with an angry Italian man who can't get a decent cappuccino.  I can't imagine what that would be like.

This may be the first time a privacy professional has been charged on behalf of the company he/she is employed by, but I will bet this won't be the last time it happens, either.

Besides the impact this can have on employees of providers of service, Google suggests it calls into focus larger issues of Net Neutrality:

An interesting argument for sure and one I can see being debated vigorously.  It's clear Google operates globally, so they must understand this sort of thing could happen.  What about Facebook (sorry, Chris) or MySpace?  What happens when Amazon is used to host data that is mishandled by someone.  What then?

Imagine what fun it's going to be when we're all cloudified and the mash-up frenzy makes the cross-pollenization of information today look orderly; who's responsible then?

What do you think?  Should privacy officers be liable for events like this?  Should CSO's/CISO's and Compliance Managers be liable when a breach occurs exposing protected information?  Think about that answer very carefully.

/Hoff

*You can find Peter Fleischer's blog here.

From the Department of "Oops, I did it again…"

Back in June/July of 2007, I went on a little rant across several blog posts about how Google was directly entering the "security" business and would eventually begin to offer more than just "secure" search functions, but instead the functional equivalent of "clean pipes" or what has now become popularized as safe "cloud computing."

I called it S^2aaS (Secure Software as a Service) 😉  OK, so I’m not in marketing.

Besides the numerous initiatives by Google focused on adding more "security" to their primary business (search) the acquisition of GreenBorder really piqued my interest.   Then came the Postini buyout.

To be honest, I just thought this was common sense and fit what I understood was the longer term business model of Google.  To me it was writing on the wall.  To others, it was just me rambling.

So in my post from last year titled "Tell Me Again How Google Isn’t Entering the Security Market?  GooglePOPs will Bring Clean Pipes…" I suggested the following:

In fact, I reckon that in the long term we’ll see the evolution
of the Google Toolbar morph into a much more intelligent and rich
client-side security application proxy service whereby Google actually
utilizes client-side security of the Toolbar paired with the
GreenBorder browsing environment and tunnel/proxy all outgoing requests
to GooglePOPs.
…
Google will, in fact, become a monster ASP.  Note that I said
ASP and not ISP.  ISP is a commoditized function.  Serving applications
and content as close to the user as possible is fantastic.  So pair all
the client side goodness with security functions AND add GoogleApps and
you’ve got what amounts to a thin client version of the Internet.

Now we see what Google’s been up to with their announcement of Chrome (great writeup here,) which is their foray into the Browser market with an open source model with heaps of claimed security and privacy functions built in.  But it’s the bigger picture that’s really telling.

Hullo!  This isn’t about the browser market!  It’s about the transition of how we’re going to experience accessing our information; from where, what and how.  Chrome is simply an illustration of a means to an end.

Take what I said above and pair it with what they say below…I don’t think we’re that far off, folks…

From Google’s Blog explaining Chrome:

…we began
seriously thinking about what kind of browser could exist if we started
from scratch and built on the best elements out there. We realized that
the web had evolved from mainly simple text pages to rich, interactive
applications and that we needed to completely rethink the browser. What
we really needed was not just a browser, but also a modern platform for
web pages and applications, and that’s what we set out to build.

…

Under the hood, we were able to build the foundation of a
browser that runs today’s complex web applications much better. By
keeping each tab in an isolated "sandbox", we were able to prevent one
tab from crashing another and provide improved protection from rogue
sites. We improved speed and responsiveness across the board. We also
built a more powerful JavaScript engine, V8, to power the next
generation of web applications that aren’t even possible in today’s
browsers.

Here come the GooglePipes being fed by the GooglePOPs, being… 😉

/Hoff

In July of last year, I prognosticated that Google with it’s various acquisitions was entering the security space with the intent to not just include it as a browser feature for search and the odd GoogleApp, but a revenue-generating service delivery differentiator using SaaS via applications and clean pipes delivery transit in the cloud for Enterprises.

My position even got picked up by thestreet.com.  By now it probably sounds like old news, but…

Specifically, in my post titled "Tell Me Again How Google Isn’t Entering the Security Market? GooglePOPs will Bring Clean Pipes…" I argued (and was ultimately argued with) that Google’s $625M purchase of Postini was just the beginning:

This morning’s news that Google is acquiring Postini for $625 Million dollars doesn’t surprise me at all and I believe it proves the point.

In fact, I reckon that in the long term we’ll see the evolution of the Google Toolbar morph into a much more intelligent and rich client-side security application proxy service whereby Google actually utilizes client-side security of the Toolbar paired with the GreenBorder browsing environment and tunnel/proxy all outgoing requests to GooglePOPs.

What’s a GooglePOP?

These GooglePOPs (Google Point of Presence) will house large search and caching repositories that will — in conjunction with services such as those from Postini — provide a "clean pipes service to the consumer.  Don’t forget utility services that recent acquisitions such as GrandCentral and FeedBurner provide…it’s too bad that eBay snatched up Skype…

Google will, in fact, become a monster ASP.  Note that I said ASP and not ISP.  ISP is a commoditized function.  Serving applications and content as close to the user as possible is fantastic.  So pair all the client side goodness with security functions AND add GoogleApps and you’ve got what amounts to a thin client version of the Internet.

Here’s where we are almost a year later.  From the Ars Technica post titled "Google turns Postini into Google Web Security for Enterprise:"

The company’s latest endeavor, Google Web Security for Enterprise, is now available, and promises to provide a consistent level of system security whether an end-user is surfing from the office or working at home halfway across town.

The new service is branded under Google’s "Powered by Postini" product line and, according to the company, "provides real-time malware protection and URL filtering with policy enforcement and reporting. An additional feature extends the same protections to users working remotely on laptops in hotels, cafes, and even guest networks." The service is presumably activated by signing in directly to a Google service, as Google explicitly states that workers do not need access to a corporate network.

The race for cloud and secure utility computing continues with a focus on encapsulated browsing and application delivery environments, regardless of transport/ISP, starting to take shape.   

Just think about the traditional model of our enterprise and how we access our resources today turned inside out as a natural progression of re-perimeterization.  It starts to play out on the other end of the information centricity spectrum.

What with the many new companies entering this space and the likes of Google, Microsoft and IBM banging the drum, it’s going to be one interesting ride.

/Hoff

Read a scary report from Google’s security team today titled "All your iFrame Are Point to Us" regarding the evolving trends in search-delivered drive-by malware downloads.  Check out the full post here, but the synopsis follows:

It has been over a year and a half since we started to identify web pages that infect vulnerable hosts via drive-by downloads,
i.e. web pages that attempt to exploit their visitors by installing and
running malware automatically. During that time we have investigated
billions of URLs and found more than three million unique URLs on over
180,000 web sites automatically installing malware. During the course
of our research, we have investigated not only the prevalence of
drive-by downloads but also how users are being exposed to malware and
how it is being distributed. Our research paper is currently under peer
review, but we are making a technical report [PDF] available now.  Although our technical report contains a lot more detail, we present some high-level findings here:

The
above graph shows the percentage of daily queries that contain at least
one search result labeled as harmful. In the past few months, more than
1% of all search results contained at least one result that we believe
to point to malicious content and the trend seems to be increasing.

Ugh.  The technical report offers some really good background data on infrastructure and methodology,  geographic distribution, properties and delivery mechanisms.  Fascinating reading.

/Hoff

A couple of weeks ago I blogged about the potential coming of the GooglePhone as follow-on to all things Google and their impending World Domination Tour™

The highlight of the GooglePhone rambling was my fun little illustration of how, if Google won the spectrum auction and became a mobile operator, they would offer free wireless service on the GooglePhone underwritten with ad revenues utilizing some unique applications of some of their new and existing services:

So, without the dark overlord overtones, let’s say that Google wins the auction.  They become a mobile operator —
or they can likely lease that space back to others with some element of
control over the four conditions above.  Even if you use someone else’s
phone and resold service, Google wins.

This means that they pair the GooglePhone which will utilize
the newly acquired GoogleFi (as I call it) served securely cached out
of converged IMS GooglePOPs
which I blogged about earlier.   If the GooglePhone has some form of
WiFi capabilities, I would expect it will have the split capability to
use that network connectivity, also.

…but here’s the rub.  Google makes it’s dough from serving Ads.
What do you think will subsidize the on-going operation and assumed
"low cost" consumer service for the GooglePhone.

Yup.  Ads.

So, in between your call to Aunt Sally (or perhaps before,
during or after) you’ll get an Ad popping up on your phone for sales on
Geritol.  An SMS will be sent to your GooglePhone which will be placed
in your GoogleMail inbox.  It’ll then pop up GoogleMaps directing you
to the closest store.  When you get to the store, you can search
directly for the Geritol product you want by comparing it to pictures
provided by Google Photos and interact in realtime with a pharmacist
using Google Talk whereupon you’ll be able to pay for said products
with Google Checkout.

All. From. Your. GooglePhone.

All driven, end-to-end, through GoogleNet.  Revenue is shared
throughout the entire transaction and supply chain driven from that one
little ad.

I got a ton of emails suggesting I was a little GoogleMad and that the blue/underlined section above was neither possible or sustainable from a business model perspective.  To address the former point regarding the technical possibility of what amounts to electronic parsing of audio — of course it is.  I’ve blogged about that before in my DRM/DLP/Watermarking discussions.

To the latter point regarding using this as a base for a business model, check this out from TechCrunch today:

The New York Times is reporting today on a new service called ThePudding that provides free, PC-based phone calls to anywhere in the US or Canada.

The big catch: computers in Fremont, CA will eavesdrop on and
analyze every word of your conversation so they can serve up
advertisements tailored to the topic at hand.

So all this takes is a move to a platform like the GooglePhone (what’s a "PC" today, anyway?") to enable this in the mobile market…looks like these guys were born to be bought!

Users initiate a phone call simply by visiting ThePudding’s website
(currently in private beta) and entering a phone number into the
browser. After the call begins, advertisements tailored to the
conversation will begin to appear on screen. The NYT has a good
screenshot of what these advertisements will look like here.

That’s the exact model I suggested in the underlined section above!  Quite honestly, with the "privacy specter" aside, this would be pimp!  It’s the natural voice-operated semantic web!

Phone conversations are monitored only by computers, not actual
human beings. The company also does not record any of the conversations
or log any of the topics discussed. Therefore, advertisements are
tailored to each particular phone call and not to trends in users’
calling behavior.

ThePudding has already experienced a fair amount of backlash, with some calling it
a terrible idea because users will not be comfortable enough with
allowing their phone conversations to be monitored. There is also the
concern that niche users will not be swayed by this completely free
offering, because they already pay very little for services like Skype. However, ThePudding may be a potential acquisition target for Skype itself, which may be interested in developing an ad-based revenue model.

While Skype is mentioned, I’d add a whole host of others to this list if they’re smart…

Despite the criticism, ThePudding does not seem all that different
to me from a privacy perspective than Gmail. If users are comfortable
with letting computers analyze their email messages and display
targeted advertisements alongside them, why won’t they be comfortable
with allowing the same thing with their verbal communications? Perhaps
there is an important psychological factor at play here that will
always make people unwilling to let strangers monitor what they
actually speak. But consumers are caring less and less about how much
information they provide online about themselves to unverified
companies, so it doesn’t seem implausible to me that with time many
people will overcome their anxieties about this type of service.

I totally agree.

While ThePudding is currently only available through the web browser
on PCs, the company has plans to expand into mobile (and to display
advertisements on the screens of handheld devices).

ThePudding is a service of Pudding Media,
which was founded by two Israelis with experience in military
intelligence and telecommunications. The company is based in San Jose,
California.

So whether it’s Google, Skype, Yahoo or Cisco, you can expect this technology to make its way into/onto communications platforms in the near future; it’s a natural extension of data mining…we get targeted ads today in search engines, unified communications is next.  i wonder who’s going to pony up the cash. I still bet on Google — it’s a natural integration into GrandCentral!

…still waiting for my GooglePhone, although the iPhone would be a pretty damned good platform for this, too 😉

/Hoff

P.S. Did you see that Google is now sinking it’s own transpacific oceanic fiber cable…

In response to my post regarding the CapGemini/GoogleApps relationship, in which I espoused the benefits of the upcoming service offering, Alan Shimel obviously forgot to take his meds as he referenced some bizarre military campaign reference in his post titled "Yesterday’s Argument, Tomorrow’s Solution."

I really tried to keep up with Alan’s logic in this post, but try as I might, I could not make heads or tails from Alan’s arguments in which seemed to contradict himself and ultimately make the same argument I did in my post.

As far as I can tell, Alan is suggesting that I’m out of touch with the realities of market economics and that security, privacy and compliance have no impact on the adoption of SaaS:

One of the classic mistakes that armies on the losing side make is
fighting the next war with the last wars weapons and tactics.  I am
afraid Mr Hoff is guilty as charged in talkingGoogle/CapGemini deal.  In case you have not heard, CapGemini will offer Google Apps to the one million strong corporate desktops that it services. 

Firstly, this announcement is less than 12 hours old.  I hardly see how I’m on the "losing" side of anything? I’ve been suggesting that Google is in a position to encroach upon and own multiple markets currently monopolized by titans.  Alan’s already disagreed with me on Microsoft vs. Google once before, but that’s not what this is about.  I really don’t understand what the heck he means by my supposed "guilt" in "taking the losing side."

Chris
does a nice job of explaining how CG will make money on this and some
of the advantages of Google Apps. However, Chris seems to side on the
camp of those who think that SaaS based, centrally managed applications
and the data that goes with it, will present compliance and security
concerns that could slow adoption. 

Um, yeah!  Want some electricity for that cave you’re living in!?  You’re not seriously suggesting that privacy, security and compliance do not hinder the adoption of technology and services are you, and more specifically, centrally-hosted applications and data?

I say poppycock to that.

I guess you are.

I heard the same thing about Qualys storing vulnerability data 5 years
ago and over the intervening time have seen that argument melt away
except for maybe in the federal government space.  In fact Qualys has
now become the tester of choice for PCI compliance in many cases.  But
beyond that, the whole issue of outsourcing application hosting brings
me back to my days at Interliant, an early entrant into the ASP
market.  We hosted Lotus Notes, PeopleSoft and other enterprise level
applications. As well as managed security (mostly checkpoint firewalls,
which was sold to Akiva).

Just so I understand this, Alan is ignoring the history of my blog and then attempts to shore up his point by citing the poster child of Security SaaS for the last 6 years or so, Qualys.  For those of who who read my blog regularly,
you already know that (1) I am a huge proponent of SaaS, and (2) I was
a Qualys customer and advisory board member.  Alan obviously doesn’t
recognize either of those points.

To wit, storing scrubbed and encrypted vulnerability data (as Qualys does) is
quite different than storing unparsed, unencrypted sensitive corporate data which is intended to be collaboratively shared. 

The issue has not melted away, Alan…in fact, it’s the impetus of probably half of the security industry’s income statements, including yours.

One thing that we learned the hard way at Interliant is that people will not outsource applications which they consider critical and core
to the business.  So for instance, if they were an accounting firm,
they would probably not outsource the hosting and management of their
accounting software.  However, critical, non-core applications are good
candidates for outsourcing.  I think for the most part, this is exactly
where the Google Apps fall.  I think the success of hosted CRM like
Salesforce.com also shows that people are willing to outsource
critical, non-core applications.

So there’s been no movement in the adoption of SaaS from your experience 6 years ago at Interliant?  Look, SaaS is certainly on the uptake and it’s bringing new and interesting avenues to market for services that range from hosted apps to security, but it’s far from ubiquitous and it’s certainly got its fair share of scale, security and privacy concerns to deal with.

Poppycock away all you like, but riddle me this, how is it that you do not
consider email, spreadsheets, presentations and documents "…critical
and core to the business?"  I dare you to turn off your email fora week and tell me it’s not critical.

Now the fact that it is Google
after all, raises in my mind anyway, two other issues. One is the
privacy of my data from Google.  Is Google going to use that to hone
the ad words they serve up to me?  The other is that as Google
continues to grow, will it suffer from Microsoft like "evil empire"
syndrome, where people attach dark aspirations to everything they do.
I guess we will have to see how this plays out.

You just contradicted yourself and reinforced the exact point I made!  So now you’re concerned about privacy and hosted data?  That’s what my post was about entirely.

SaaS does and will absolutely continue to drive privacy concerns, especially for the very reasons at the end of your argument you make such a big point about highlighting.  I even talked about this in this post here titled "On-Demand SaaS Vendors Able to Secure Assets Better than Customers?"

I can’t figure out what point Alan’s making here; he seems to agree and disagree with my posting in the same post.

/Hoff

Coming (securely?) soon to a managed enterprise desktop near you, GoogleApps.  As discussed previously in my GooglePOP post demonstrating how Google will become the ASP of choice, outsouring and IT Consultancy CapGemini
announced it is going to offer Google’s Apps as a managed SaaS desktop option to its corporate enterprise customers, the Guardian says today:

Google has linked up with IT consultancy and outsourcing specialist
CapGemini to target corporate customers with its range of desktop
applications, in the search engine’s most direct move against the
dominance of Microsoft.

CapGemini, which already runs the
desktops of more than a million corporate workers, will provide its
customers with "Google Apps" such as email, calendar, spreadsheets and
word processing.

…

"Microsoft
is an important partner to us as is IBM," said the head of partnerships
at CapGemini’s outsourcing business, Richard Payling. "In our client
base we have a mix of Microsoft users and Lotus Notes users and we now
have our first Google Apps user. But CapGemini is all about freedom,
giving clients choice of the most appropriate technology that is going
to fit their business environment."

Google’s applications such as
its Google Docs word processing and spreadsheet service allow several
people to work on one document and see changes in real time.

"If
you look at the traditional desktop it is very focused on personal
productivity," said Robert Whiteside, Google enterprise manager, UK and
Ireland. "What Google Apps brings is team productivity."

…If you’re wondering how they’re going to make money from all this:

CapGemini will collect the £25 ($50) licence fee charged by Google for its applications, which launched in February.

It
will make further revenues from helping clients use the new
applications, providing helpdesk services and maintenance. It will also
provide help with corporate security, especially for applications such
as email, as well as storage and back-up services.

CapGemini
expects customers to mix and match products, providing some users with
expensive Microsoft tools and others with cheaper and lower-spec Google
Apps.

You can check out the differences between the free and for-pay versions here.

Besides being a very good idea from an SaaS "managed services" perspective, it shows that Google (and global outsourcers) see a target market waiting to unfold in the corporate enterprise space based upon the collaboration sale.

What’s really interesting from a risk management perspective, continuing to ride the theme of Google’s Global Domination, is that Google’s SaaS play will draw focus on the application of security as regulatory compliance issues continue to bite at the heels of productivity gains offered by the utility of centrally hosted collaboration-focused toolsets such as GoogleApps.

Interestingly, Nick Carr points out that GoogleApps’ "outsourced" application hosting capability hasn’t caught on with the large corporate enterprise set largely due to "enterprise readiness," security and compliance concerns, a suggestion that Steve Jones, a Capgemini outsourcing executive who oversees the firm’s work with software-as-a-service applications, maintains is not an issue:

"[Carr] asked Jones about the commonly heard claim that Google Apps, while
fine for little organizations, isn’t "enterprise-ready." He scoffed at
the notion, saying that the objection is just a smokescreen that some
CIOs are "hiding behind." Google Apps, he says, is "already being used
covertly" in big companies, behind the backs of IT staffers. The time
has come, he argues, to bring Apps into the mainstream of IT management
in order to ensure that important data is safeguarded and compliance
requirements are met. Jones foresees "a lot of big companies"
announcing the formal adoption of Apps.

Remember, these applications and their data are hosted on Google’s infrastructure.  Think about the audit, privacy, security and compliance implications of that; folks that utilize ASP services are perhaps used to this, but the question is, what can Google do to suggest it’s hosting model is secure enough, after all, Hoff’s 9th law represents:

Since Google’s app. suite isn’t quite complete yet, Microsoft’s not entirely in danger of seeing it’s $12 Billion office empire crumble, but it’s got to start somewhere…

/Hoff