http://techcrunch.com/2010/09/14/google-engineer-spying-fire...;
That was three years ago though...a lot may have changed about Google's infrastructure...I'm thinking, for example, whatever work has been done to unify login systems between Google Apps, GMail, Youtube, and of course, Google Plus. Presumably, as complexity has arisen, so has the need for better access-control infrastructure, which would (hopefully) prevent someone even at Eric Schmidt's level to lose his wits and trample around in the system without many, many flags going off first.
So with that said, that's why I'm skeptical (in the layman sense of, this is all more complicated than I can dream of) that this surveillance alleged in the PRISM reports could occur with just a few dedicated employees in the know (or a few moles).
It's not just the data transfer that has to go unnoticed, but the successful navigating of the access control infrastructure. And even if Google were to be completely in cahoots with the NSA and built a backdoor, wouldn't there have to be a testing suite that would make sure whatever normal changes to Google's code base also didn't inadvertently restrict (or reveal) the back door logic? And then wouldn't there also have to be at least one layer of oversight to make sure that that testing suite itself was maintained but otherwise unnoticed?
But I'm speaking as a layperson here who thinks that the kind of infrastructure Google has would require a framework that would make backdoor access awkward to implement. Just so many things could break across all of Google's servers, otherwise...like this fun incident that most people probably still remember, if you happened to be awake early one morning 3 years ago:
http://googleblog.blogspot.com/2009/01/this-site-may-harm-yo...
> If you did a Google search between 6:30 a.m. PST and 7:25 a.m. PST this morning, you likely saw that the message "This site may harm your computer" accompanied each and every search result. This was clearly an error, and we are very sorry for the inconvenience caused to our users. > > We periodically update that list and released one such update to the site this morning. Unfortunately (and here's the human error), the URL of '/' was mistakenly checked in as a value to the file and '/' expands to all URLs. Fortunately, our on-call site reliability team found the problem quickly and reverted the file.