1. A deeply intellectual corporate cultural, with 70% of its workforce having PhDs (I don't know if this is still true.) This includes the "20%" concept, whereby all Google staff is given free-reign to research what interests them 1 day out of 5. Google, to me, recalls the days of business-as-research-endeavor, the era of Xerox Parc and Bell Labs and the intellectual energy they represented.

You mean the Bell Labs which allowed their staff to do whatever interested them five days out of five? Sorry, there's no comparison. Google is business-to-make-money, not business-as-research.

A few mailboxes (20 out of 200) had the wrong mail migrated into them. We don't even know the source of this problem yet, but the university could very well have TOLD Google to put sally.smith's e-mail into sally.jones' new mail box.

This isn't a google apps security problem. Please RTFA and get off your high horse.

No, why don't you RTFA and get off your high horse. According to an article linked from TFA, Google acknowledged the problem was on their end, and an earlier comment from a Brown sysadmin indicates that Google upgraded their migration tool right before this happened. It may have "only" been 20 out of 200 accounts, but the problem is squarely Google's fault; stop blaming the Brown sysadmins.

My impression is that this incident is a fuckup at the customer end of things

No, according to this article, "The problem was on Google's end. They acknowledged a bug," and according to this comment, Google had upgraded their IMAP migration tool right before this happened.

Sounds like a case of insufficient testing on Google's part before rolling out the new version of their tool.

SSL is not supposed to be preventing MITM nor is it supposed to be for identifying purposes.

I disagree. Why else does SSL have certificate signing capabilities? SSL even has client-side certificates for client identification, though it isn't widely used in HTTPS. In order for any asymmetric cryptosystem to work you need to exchange public keys, and you always have to establish some kind of trust system for those keys.

We have other technologies for that like PGP but the internet relies on anonymity so you're never 100% sure that you're going to talk to the correct persons.

Hence the need for SSL.

Even with PGP, your initial communications will have to be trusted (eg. you personally hand over or get a key) or any subsequent communications will be compromised. SSL doesn't even go that far because every communication is viewed as an initial communication. If the certificate is re-signed or changed to another CA the next day, your browser will not complain as long as that CA is in it's trusted root certificates.

This is a fault of how the key management in SSL has been implemented in web browsers, but says nothing about the technology itself. Two examples of systems using SSL with better (but less convenient) key management systems are OpenSSH and OpenVPN.

It's the browsers fault and the CA's as well (with VeriSign the biggest) by asserting that SSL certificates can be used to authenticate an entity rather than a communications.

There's a middle ground between "entity" and "communications." Yes, it is very difficult to verify that a certificate is being issued to the entity "Bank of America," but it should not be hard to verify that you're issuing a certificate to the domain name www.bankofamerica.com. And the latter is all you need to protect against MITM.