The Single Vigilante Behind Facebook's 'Real Name' Crackdown

Molly McHugh sends this story from Daily Dot: When Facebook issued an apology this week for suspending user accounts that had what it alleged to be fake names, it pinned the whole debacle on one person. This "individual," Facebook reasoned, sewed confusion into its flawed reporting system—intended to protect against bullying and online abuse. Facebook Chief Product Officer Chris Cox explains that Facebook was caught “off guard” by a lone actor who reported “several hundred” accounts as fake. According to our source, who claims to have spent "hours and hours" systematically reporting Facebook users from the drag community and beyond, thousands of accounts were suspended—and they've been at it for weeks. ... Given the timing and the accounts suspended, they believe that they are in fact the mystery "individual" who threw a wrench into Facebook's system, noted in Facebook's explanation of the events. "Considering the hours and hours I spent reporting accounts over the course of the past month, it is likely that I am."

Comments

Re:What an asshole

[Teresita]

The late unlamented Fred Phelps and his crew took any expression of disgust and outrage against him as evidence they were doing the Lord's work. That's how these folks think.

Re: What an asshole

[TheDarkMaster]

On Brazil we simply do not break the name when using it on a local created software, is always the full name on a single field. (And is anoying for us using foreign software in this detail)

TF upgrades, fixes and regressions

[fyngyrz]

I'm truly sorry you chose to make that post anonymously. Spot on, and amusing at the same time. I would have enjoyed making sure I took special note of future postings if I knew who you were. Well, kudos anyway. :)

The rush to "do" underlies a great deal of our problems from incompatible OS upgrades, bugs left behind to fester, the rug being yanked out from under previously working applications, and functionality going missing -- or crazy -- or sideways -- in existing user applications. There are methodologies that can resolve all of these things the vast majority of the time, but very few software developers at any level use them. Much harm results.

<RANT>

Primary among them, NEVER remove or change the stated design behavior of an existing function. If you have a better idea, add a new function with a new stated design behavior. Leave the previously existing one alone; if necessary, point out that it won't work with "new stuff", if indeed that is the case. Then stop. If an already existing function is not behaving as the stated design behavior says it should, change it until it does.

Pro tip: If "upgrading", if whatever "enhancements" you created make something stop working or degrades how it works in an existing application that used the function according to its stated design intent, it's about 1000000:1 that it's your fault AND that you shouldn't have done whatever you did.

It doesn't matter if you're an OS programmer, an application programmer, a PD library maintainer, or what. If and when you screw up existing stated design behavior, you have not created an "upgrade", you have created a "fuckyougrade" and somewhere, someone, or more likely many someones, are contemplating dragging you through a fire ant hill after dousing you with some other ant hill's characteristic pheromones.

</RANT>