"Occasionally we detect an attack that requires us to augment those automated systems," said Eugene Zarakhovsky, software engineer at Facebook, in a blog post. "Specifically, we identify a malicious pattern, find all the apps that match the pattern, and then disable those apps. This normally results in thousands of malicious apps being disabled and improves our automated systems' ability to detect similar attacks in the future."
Facebook said that in this instance, it began with a broad detection pattern that correctly matched thousands of malicious apps. The problem was that it also identified and labeled legitimate apps as malicious. When it detected the error, Facebook said it stopped the process and worked to restore access. This took longer than expected because "of the number of apps and bugs related to the restoration of app metadata."
[ Facebook is only too happy to sort your news feed for you. Take control: read 5 Ways to Customize Facebook News Feed. ]
Developer platforms are a hotbed for malicious activity. In July, Apple said its developer portal was hacked, which put the personal details of 275,000 third-party developers at risk. Google has also struggled to keep its Google Play marketplace safe. Most recently, it came under fire after a study showed that 22% of its apps included adware. Although Facebook's incident did not threaten security or privacy, it was a nuisance for many.
App developers turned to a thread on Hacker News after discovering that their apps had suddenly been disabled. Facebook's developer advocate David Weekly replied to the thread, saying, "We have systems that block spammy apps that are 99.9% of the time really incredibly sophisticated and get a ~0% false positive rate. This is a case of the 0.1%."
To prevent this from happening again, Facebook says it plans to put two measures in place. The first is to "create better tools to detect overly broad patterns and put in place better processes to verify that all apps matched are indeed malicious." The second, Zarakhovsky wrote, will be to address the bugs and bottlenecks that made the recovery process slower than expected.