AI and Cloud Computing -- do they complete each other?

The problem with useful things in software, and perhaps useful things in general, is that they tend to become magnets for anything and everything remotely related. And then some. The old saw about AI is that it's everything we don't know how to do yet with computers. Larry Ellison's now-famous (instantly famous, really, rank having its privileges) rant fills in the rest of the picture:

The interesting thing about cloud computing is that we've redefined cloud computing to include everything that we already do. I can't think of anything that isn't cloud computing with all of these announcements.

In short: If it can't be done, it's AI. If it can, it's cloud computing.

Virtualizing buzzword compliance

The words of the day are "virtualization" and "cloud computing". The idea behind them is that actual computing -- CPUs crunching through instructions, databases being updated on permanent storage, nuts and bolts computing -- can happen in data centers instead of on people's desktops.

It's "virtual" because the chunk of computing resources you're using is not necessarily tied to any particular physical machine, much less the particular machine on your desktop, on your lap or in your handset. It's "cloud computing" because you neither know care where the actual computing is taking place. It's happening somewhere out in "the cloud".

I first heard someone talk about "the cloud" many years ago, back when bang paths still walked the earth. At the time I was accessing the internet, sort of, by dialing into a friend's system at his lab. That box was connected to more-connected boxes at the university, which in turn were connected to similar boxes at other sites, and so forth. In other words, to connect box A to box B, you had to know at least something about how to get from one to another.

Or, you could get a newfangled connection into "the cloud". If box A and box B both had such a connection, you could go directly from one to the other. Any intermediate connections happened "in the cloud". In other words, it was exactly the kind of connection everyone has today.

I first heard about virtualization even longer ago, though not under that name, in a high school class on business computing. And by business computing I mean COBOL, RPG, radix-sorting of Hollerith cards and similar specimens from adjoining strata. At one point we had a real live computing professional come in and explain to us how a real business computer worked.

He explained that it could be a problem to have, say, everyone trying to print on the same printer at the same time (and by printer I mean a beer-fridge-sized box chewing through wide-format green-and-white-striped fanfold paper). But, he went on, with a little magic in the operating system you could say "disk drive, you're a printer". The print job would sit in a queue on the disk drive until a printer was free and then it would print. If you had five paper-spewing beer fridges, you could divvy the work up among them without caring which one was going to actually print any particular job. Print spooling, in other words.

That was an eye-opener. The task of printing was separated from exactly where or when the printing took place.

At the same time, in a different class, I could dial into the "time sharing system" at the university and hook up to what looked like my own personal computer (and by hook up, I mean dial up at 110 baud by mashing a phone receiver into a foam receptacle). It ran whatever program I told it to, it remembered my files from last time, and so forth. Except it wasn't actually my own computer. I was really sharing one room-sized computer with everyone else and the computer's operating system was multitasking amongst us (here's a bit more from those days).

That seemed like a really neat trick, and it still does.

Now, you can read this sort of "nothing new under the sun" spiel one of two ways. One is "All this 'cloud computing' and 'virtualization' stuff was done years ago. There's nothing to it." The other is "The basic ideas behind 'cloud computing' and 'virtualization' are so old and useful we forget they're even there until someone drums up a marketing campaign to remind us."

I tilt toward the lattter.

Signing webmail

While looking up something on S/MIME, I ran across one of those little "hmm ... interesting point" points. How do you digitally sign webmail?

The problem isn't that mail sent through a web interface is somehow harder to sign. The question is who do you trust to do the signing. The whole point of webmail (and one version of "the cloud") in general, is that you can access it from anywhere on any device. The whole point of digital signatures is convincing everyone that only you could have done the signing. Two great tastes that don't go so great together.

If I only send mail from a particular box, I can just leave my private keys in a file on that box (password protected, of course) and use a mail client running locally. I tell the mail client my password, it fetches the keys and signs my message. This approach is as secure as my box and the firewall it sits behind.

If I'm in a cybercafe or using one of those airport internet kiosks that I've never, ever seen anyone use, I don't want to copy my secrets onto a local drive (assuming I even can) or otherwise hand them over to a the browser directly. You don't know where that thing's been.

The next candidate would be the webmail server. Hand it my keys, once, very securely. Then I log in to my webmail and send a message from wherever. The server signs it for me without revealing my secrets to the browser.

There are a couple of problems with that. One is that I'll need to be careful logging into the server. If the browser is actually a password-stealing trojan horse, then whoever is running it can grab my login and forge whatever they like under my identity. Another is that if the webmail server is ever compromised, the attacker doesn't just get my key, but a whole treasure trove of keys to go cracking for weak passwords. That's a problem for the people running the server, but it's also a problem for me since the server is a nice, big, visible target.

There are ways to make logins trojan-horse-resistant, for example smart cards that generate a fresh hunk of random digits every so often, but these are not widely deployed. The bottom line is that any server with your keys on it is only as strong as its authentication system, and most of those aren't that strong.

What would be better? The basic trust issues are clear enough, but the kind of mental ju-jitsu needed to think through all the various counter-measures and counter-counter-measures is hairy in the extreme. True black belts are relatively rare, and I'm not one of them. But from what I can tell an airtight solution would probably involve some kind of smart card that you could plug into the device you're actually using (the pocket-thing would be a candidate, but then, it could probably send signed mail directly). The server would then need a conduit through which it could send data up to the smart card and get signed data back.

And even then it would do well to check that what you signed was actually what it sent you.

What do I mean, "explicitly sign away"?

I previously said that one of the features of good online data storage is that anything you put there belongs to you unless you explicitly say otherwise (or perhaps better, storing something in the cloud doesn't alter the rights to it unless without specific instructions otherwise).

But hang on. The usual yada yada that everyone just clicks on to get to the good stuff generally contains very specific statements about rights to data. And you specifically clicked on that, right?

Legally (and keeping in mind that I'm not a lawyer), yes, accepting the yada yada commits you to whatever it says. So this isn't a legal matter. It's a matter of customer service until some regulation on license agreements says otherwise.

The point is that the usual yada yada really consists of two things:

• Stuff most people care about (or should), like what sorts of activity are allowed or prohibited, and who has what rights to what data.
• Stuff most people don't care about, but lawyers do, like governing law (what state or nation's laws apply), severability (if one section turns out to be legally unsound, the rest still stands), whole agreement (these are all the rules of the game; in particular, older versions of the agreement don't count) and so forth.

People like to brush off the second category as "legalese", but every clause is there for a reason, generally because there was an ugly dispute over the issue somewhere in the past. There are very seldom any winners in an ugly legal dispute.

Ideally, provisions in the first category would be shown prominently, with concise headlines and clear explanations under the headlines, and there would also be a clearly labeled link for "other legal considerations" (or "our lawyers made us put this here" or whatever). When I said "explicitly sign", I was imagining a situation where the "important" clauses were presented prominently and not mixed in with the "other legal considerations", as they often are.

It's still your responsibility if you accept an agreement that's unfavorable to you. This is really just about clearer signposts. I should also say that, as far as I can tell, most vendors make an effort to make license agreements painless and many make an effort to point out clauses that might be surprising. I don't think license agreements are in desperate need of overhaul or that the vendors' lawyers are out to get us. But there's always room for tweaks and improvements.

Who owns the cloud?

Along the lines of "the usual yada yada," NPR recently ran a story on the downside of storing important personal data -- email, pictures, schedules, secret recipes, whatever -- "in the cloud", that is, online somewhere, you neither know nor care where, conveniently managed and backed up by someone else.

They mention three main problems:

• Your provider could fold, taking your data with it.
• Depending on the terms of its yada yada, your provider could shut down your account for any number of reasons beyond your control. For example, a random person could tell them, without proof, that they think you're engaged in committing a crime.
• Again depending on the terms of the yada yada, the provider might share your data with anyone and everyone.

Now, without meaning to be harsh on anyone (when was the last time I scraped a copy of this blog?), these seem like problems one could anticipate, if only on the basis that in any sweet deal, there's got to be a catch someplace. But that doesn't stop them from being serious concerns.

The holy grail here is a service whereby your data is:

• Safe: It won't go away, barring disasters in multiple, geographically separated sites (in which case there are probably bigger fish to fry). You may lose access to it, whether because you don't have connectivity, or because your provider folded and the data is temporarily in escrow, or because you really are accused of a crime, or whatever.
• Secure: Only you can get at it. If you provider leaks your data, it's liable up to some fairly substantial point. If you lose your keys, you can have them replaced conveniently.
• Yours: You have the rights to whatever you store (provided you created it or otherwise had the rights to it in the first place) unless and until you explicitly sign them away. As I understand it, this is one of the key tenets behind personal datastores.
  

In most cases, providers are implicitly suggesting this kind of service, and since no one reads the yada yada, everyone is expecting it. Providers also have a strong incentive to make this level of service a reality. If it's too far off, word will eventually get out and fewer people will want to buy in. In particular, the chances of one of the major players folding and taking your data down, or simply losing large portions of it, appear fairly small. Not zero by any means, but fairly small.

On the other hand, there is probably room for a few well-placed regulations to help things along here. In particular:

• That data held by a provider that goes out of business should go into escrow and made available to former customers for a reasonable period.
• That data remains private unless specifically made public.