Thursday, June 17, 2010

facebook's developer verification isn't that bad an idea

earlier this month ryan naraine penned a post critical of facebook's latest effort to crack down on rogue facebook applications.

facebook plans to force app developers to verify themselves either by submitting a phone number or credit card information - essentially to establish a less anonymous identity.

ryan naraine contends:
While this is clearly a step in the right direction, this won’t stop rogue apps from wreaking havoc on the social network.
and he suggests:
Instead of these minor roadblocks, Facebook needs to implement some sort of code signing or code inspection process for every app that’s submitted to its platform.
while he is right that developer verification won't stop rogue apps, what he apparently fails to realize is that NOTHING will really stop the rogue apps, short of closing the application platform to the outside world entirely. preventing web-based malware is comparable to preventing traditional malware that runs on the desktop - there is no panacea, no magic bullet that will make the problem go away.

code signing, for example, can also be bypassed by the serious criminals. don't believe me? we've already seen examples of malware getting digitally signed by gatekeepers of the sort ryan naraine likely has in mind, and the reason is easily deduced - digital signing protects against malicious alteration of legitimate content, but it has no intrinsic strength against malicious parties getting their own content signed. the people who do the signing aren't qualified to determine the safety of the code, and that's not what a signature establishes anyways, it establishes the authenticity of the code.

likewise code inspection is not going to work because facebook just doesn't have the expertise necessary to determine the safety of the code running on it's platform. even if it developed that expertise, it wouldn't scale, and scalability is important. especially when you consider that the malicious facebook developers appear to be taking a page out of traditional malware creator's playbook and going for volume as a means of compensating for the disabling of individual apps.

verifying or certifying the developer instead of the code means that for a malicious developer to continue using a volume-based strategy he'd need to establish a fake identity for each copy of his rogue app. while facebook hasn't set the bar for this very high, it is higher than it used to be and in so doing makes the strategy more expensive for the attacker. additionally, with this framework facebook could easily make it harder or more expensive in the future without changing all that much besides the verification process itself.

it seems clear to me that developer verification will do some good. there will always be room for improvement, regardless of what approach one takes, so let's not pretend like there's a perfect solution out there and facebook is making a mistake by not choosing it - there isn't and they aren't. we'll see how the bad guys adapt to this countermeasure soon enough and then we can start dreaming up new countermeasures for their countermeasures. like the war against desktop malware, web-based malware is going to be another game of cat and mouse / measure-countermeasure - that much was inevitable.