Yeah, I figured that was kinda self evident. We wouldn't leave any security holes open. I guess I can edit the blog post to clarify this without changing the meaning any.
Things like insecure SSL options (we knew that, but wanted to support older devices for a little longer - we've bitten the bullet and switched to SHA256 certs now, and turned off RC4)
They recommended a bcrypt hashing factor which isn't realistic for fast responses, it would have pegged a core for over a second.
A few things that were just testbed specific, and a couple of rate limits we had missed.
Some "internal details leaked in errors" - in two minds about that. Sometimes it helps debug. We mostly log the verbose error internally now and give the user a unique key that makes log grepping easy. Harder to self-help if you hit an error we didn't make a nice error code for yet though and you have tech clue.
