I know what Hanlon's razor is, and I can guarantee you FB Engineering knows what a rollback is and how to know whether you need one or not. I'm not sure where you're getting the idea that they're that stupid.
Would applying such a 'rollback' involve replacing facebook.com email addresses with the original external domain addresses in the contacts list on the devices affected by the write-over issue?
If so: Facebook have taken private data and placed it in a central location
Yes, a (hypothetical) "complete rollback" would involve replacing removed data. Sure, data privacy would be a concern, but it's beside the point that rolling this back would necessitate un-overwriting.
Only Violet Blue has said that they don't have a complete rollback as best I can tell from the CNET article.
I would guess the only thing they can't undo would be the time that has passed. If any data Facebook ever had on any of their users (such as their primary email address [edit: at any point in time]) was ever lost, they wouldn't have as much to sell to their customers!
She didn't say they didn't have a rollback plan, she was saying there's no way to undo the damage they've already done. She's not privy to their internal plans, it was a metaphor.
Rolling back the change won't get people's time or email back, or undo the damage to facebook's reputation.
That would make sense giving her the benefit of the doubt, thanks. The transition to metaphor was pretty blurry in the article title.
As I pointed out elsewhere, they can just forward the email to the intended address as an unwelcome MTA, so I disagree with your statement that they can't get people's email back. I agree on the time and reputation points though. However, I don't think any rollback has ever gotten those back, so 'rollback impossible' because it can't do what any rollback has ever done seems disingenuous.
As silly as it sounds, this almost sounds like a job for Git. In that case, you could simply revert a single commit, and have the user resolve the conflicts. For that to work well though, you'd need to keep separate "repositories" for phone/Google/Facebook/whatever addresses and merge them locally, which could get very ugly for end users.
Thanks for sharing your perspective. Just to make sure we're on the same page, you are arguing that FB engineering was 100% aware of the consequences of automatically switching primary email address to @facebook.com for users who had setup that functionality, including overwriting email addresses in phone contact lists and capturing email unintentionally sent via those modified contact lists?
This is certainly within the realm of possibility and indicates that you hold the team's technical ability in high regard. If it is indeed true, I would wonder what percentage of the folks involved in the implementation actually thought about it and how high/wide the issue was escalated. I have certainly been in situations where after-the-fact I found out that something I had been a part of shipped with known bugs/features I didn't know about that I would have raised a lot more concern over.
My line of thought is that they knew it would change phonebooks and that they weren't putting whatever resources necessary into creating a process for rollback. Given the nature of Facebook and it's technology, I'm not even sure there is anything they could have done, but it's de rigeur to know if this is the case. It's not even about high regard, but by minimum standards. If you know you can't rollback you go full steam ahead.
If you've never worked someplace where they have dedicated staff for source control, that fact alone might give you an idea at the level of expertise involved here. It's nobody's first time at the rodeo, and setting the sync API on the change (as described below) wasn't just slipped in by an intern.
You finding out after-the-fact and still having an opinion about bugs shipping in code you contributed to only reinforces my point: someone made the decision to go ahead anyway.
