Well, nothing ever left Twitter's servers. The logs themselves would probably be uninteresting to outside parties and inaccessible.

I suspect that many more employees at Twitter have access to the logs, than have access to a super computer and pasword hashes.

I know I wouldn't trust my password with the number of people that have easy access to logs at other large(ish) tech companies.

I really can't imagine why "we didn't have to" was included in that tweet, at all. What other flaps like this have occurred that exposed my creds or personal data to large numbers of employees, that they didn't have and didn't choose to tell us about?

Even if true, best practice is to strictly restrict access to and create audit trails for reading raw logs from production.

Ideally, you'd only need to read raw logs tied to a test account, or, maybe your own personal accounts.

Stack traces and exceptions and the like can be anonymized and collated.

More employees at virtually every major web company have access to instances (and thus instance memory) than have access to supercomputer clusters, too. Every mainstream popular web application is fed a constant high-volume feed of plaintext passwords, right there in memory (or, in typical TLS termination environments, on the wire) to be read by a persistent attacker.

That's true for nearly every single internet facing service, no? A compromise resulting in point-in-time access to traffic is a bit different than a bug that creates a persisted historical record of every single user who signed in for a period.

Maybe I miss the point behind this comparison? I guess I'd understand more if I thought the number of folks with node access and log access were in the same magnitude at Twitter, or if the TLS stack persisted data over time.

Last year a contractor deleted the president’s account.

The fact it didn’t leave Twitter doesn’t mean everything is good. There are still a LOT of people who may have had some kind of access to this data.

Assuming everyone has access to the logs.

> Last year a contractor deleted the president’s account.

The fact that they undeleted it is strong evidence that he didn't have discretion in how he performed his job, and thus was actually an employee and not a contractor.

If my gardener leaves a rake on my driveway, I'll remove the rake. That doesn't make the gardener an employee.

I’m not sure how that follows. Are you suggesting they don’t keep backups or use a “deletion” flag temporarily, e.g. as part of spam account removal?

Indeed. I deleted my Twitter account recently, there was a message that data is retained for 30 days to facilitate un-deletion. I assume their internal process is the same.

>Well, nothing ever left Twitter's servers.

Nothing is known to have ever left Twitter's servers.

FTFY.

>The "we didn't have to" is a little jarring given the scale of this.

How come? I interpreted it to mean that no regulations required this, but they chose to anyway. Which is true.

There is very little to be gained or added from pointing out this was optional -- for some reason the CTO decided to make a point of it.

I think the tone matters. Particularly for matters like this.

To my ear (and many who replied to that Tweet) this reads as "we've decided to do you a favor." Which is very much not the case.

I see it more of "we may have kept it quiet, but we're not making secrets from you - it's indeed our open culture"

So Twitter found out they had a bug that caused them to store passwords in one of their databases in plaintext. Their response is just a generic 'hey maybe you want to store your password'.

Compare that to Github who just yesterday went through the exact same problem, except they're requiring users change their password. Their CTO didn't make some 'hey you should THANK US" claim.

Are they? I just signed in on a machine where I had signed out and got no prompt to change it. Is it only certain users?

Yup. Affected users were emailed 24 hours ago. Only affected people who initiated a password reset previously (I assume during a certain time frame?)

> During the course of regular auditing, GitHub discovered that a recently introduced bug exposed a small number of users’ passwords to our internal logging system, including yours. We have corrected this, but you'll need to reset your password to regain access to your account.

> GitHub stores user passwords with secure cryptographic hashes (bcrypt). However, this recently introduced bug resulted in our secure internal logs recording plaintext user passwords when users initiated a password reset. Rest assured, these passwords were not accessible to the public or other GitHub users at any time. Additionally, they were not accessible to the majority of GitHub staff and we have determined that it is very unlikely that any GitHub staff accessed these logs. GitHub does not intentionally store passwords in plaintext format. Instead, we use modern cryptographic methods to ensure passwords are stored securely in production. To note, GitHub has not been hacked or compromised in any way.

+1 Thanks for the details.

I think it's part of the problem of writing a statement to be read by a large number of people - it could be read as "There is nothing legally forcing us to do this, but we are doing us anyway as it is in the best interests of our users" (which is positive) OR it could be read as "We didn't have to do this; we did you a favour, but there might be situations where we don't disclose this" (which is fairly negative). FWIW, I think the former is the intent.

Personally, I'd probably just say "We felt that we had to disclose this to protect the interests of our users" (and not acknowledge that they might not, or that they had to make a decision to do so), or just say what they _are_ doing ("We are disclosing this in order to protect our users") and avoid the possibility that it is misinterpreted. I don't think there is anything to be gained by saying that they might not have done this.

It's kind of like pre-emptively defending yourself against an accusation that hasn't been made yet.

Regardless, it seems very defensive. A company that looks after their users "because they choose to" is a lot more suspicious than one where customer care is simply assumed to be inherent to the operation.