This is not a part of the vulnerability rewards program? Why?
http://www.google.com/about/appsecurity/reward-program/
(I work for Google.)
When I was at Google Sydney a few years ago for an internship, the AC died prompting an interesting response. The server temps were rising to unsafe levels and the AC wasn't expected to come back in time. The MacGyver solution was to buy portable AC units and pump the heat into the coder's workspace. That was a distinctly unpleasant afternoon =]
If the machines weren't important for production or productivity I'm certain they'd save us the hassle and shut them down. If nothing else, abuse of this office's AC system could severely impact the productivity of the office and spring dozens of people into action.
Whilst not under the usual purview of the rewards program, I'd still think it's noteworthy of recognition.
The aircon was clearly over capacity then, and there were portable air conditioners scattered around the floor I was on, with flexible ducting feeding up to the return ducts in the ceiling.
I assume they've fixed that by now, I know they've gone through at least on remodel since.
For example, we don't want physical security or the police second-guessing the intent of someone trying to sneak into one of our buildings - so we set a very clear scope for the program, pragmatically focusing on our user-facing applications and excluding things such as attacks on our facilities and corporate infrastructure. It's a broad exclusion, but it's hard to come up with something finer-grained yet clear enough.
In the same vein, we ask researches that they don't go after any systems unless it's perfectly clear that the application is owned and operated by us - for example, because it's in an IP range registered to us. Again, while this may be more limiting than we'd like, it protects the community against overly litigious parties if the system proves to belong to somebody else.
In several unusually serious cases, we have made case-by-case exceptions and have paid external researchers for nominally non-qualifying bugs; but it's a tricky balance, and we use this power very cautiously.
Source: I authored a good chunk of the current rules for Google VRP ;-)
However, this case is different. While it was absolutely an attack on Google's infrastructure, it was discovered through a vulnerable external web service. Even though the control panel application is not a Google product, it stores user passwords in clear text as decoding it seems to be trivially simple. At the very least, Google should be responsible for picking third party vendors that store passwords using one-way hashes ;).
If you ask me, this should be one of those special cases!