Was Facebook's Terms-Of-Service Response to Jerk.com Adequate?

FacebookFB, like its users, was victimized by Jerk.com according to the Federal Trade Commission’s complaint. As detailed in Part 1, from 2009-2013  Jerk.com  published pictures and information from Facebook profiles that Jerk.com had no right to use.

From Facebook’s perspective, it was victimized by an app developer who violated its terms of service, damaging Facebook’s users. Facebook’s users were damaged not simply because the information was taken, but because Jerk.com made it nearly impossible to get their information off the web.

Facebook uses both manual and automated screening to identify problems, and apparently the process works:  Facebook discovered the problem sometime before March 2012. That is when Facebook sent Jerk.com a cease and desist letter. Facebook also disabled “some” of Jerk.com’s Facebook apps for violating Facebook’s terms.

Related: Link to Part I

That would have ended the pipeline for data theft, so long as the remaining active Jerk.com apps couldn’t be abused as the disabled ones were. But those steps were ineffective at solving the problem Jerk.com already created, because neither resulted in the improperly obtained information being removed.

Taking Contract Breaches ‘Seriously’

As a general matter, Facebook told Benzinga: "We take breaches of our terms seriously. We applaud the FTC and will continue to work with them as they pursue Jerk.com and others that seek to abuse people who use our service".

But what does that mean? In January 2012—around the time that Facebook learned about Jerk.com—Facebook was collaborating with the Washington Attorney General to take on Adscend Media LLC, who were “clickjackers”. On January 26, 2012Facebook filed suit against Adscend, as part of a joint legal strategy with the Washington AG.

Why didn’t Facebook sue Jerk.com around the same time, seeking to enforce their terms of service? The current version of those terms include:

“II.12. You will delete all data you receive from us concerning a user if the user asks you to do so, and will provide an easily accessible mechanism for users to make such a request. We may require you to delete data you receive from the Facebook API if you violate our terms.”

That provision is so basic, surely the version of Facebook’s terms of service in effect at the time contained it or something similar. So why didn’t Facebook sue to enforce it?

Unlike Facebook users, Facebook itself has deep pockets for the kind of potentially very expensive litigation involved. As noted in Part I, a Minnesota law firm gave up trying to fight Jerk.com because of its litigate-until-victims-can’t-afford-to-keep-fighting-strategy.

The firm was so outmatched by Jerk.com’s pocketbook that it decided not to file a class action:

“We have considered a class action case, but determined we cannot spend our firm’s resources on such a large case at this time. While we are open to discussing representation of paying clients, we advise them that the battle will be long and expensive.”

But surely Facebook could afford to sue over such clear violations of its terms of service. So why did Facebook sue Adscend and not Jerk.com?

How Did Jerk.com Get the Data?

According to the FTC, Jerk.com was able to steal what they did because:

"Facebook permits third-party developers to integrate websites and applications with Facebook. Developers can access data for all Facebook users through Facebook's application programming interfaces (“APIs”), which provide sets of tools developers can use to interact with Facebook. Developers that use the Facebook platform must agree to Facebook's policies". (Bold added.)

What does the bolded language mean? What kind of data do Facebook developers get access to? As of publication, the FTC had not returned a call for clarification.

Pressed for comment, Facebook did not clarify, but it did say “developers may only access data from people who have authorized their app." Facebook reinforced this point by noting that its terms of service forbade improper data collection and use, specifically:

“II.1.You will only request the data you need to operate your application.

“II.2 You may cache data you receive through use of the Facebook API in order to improve your application’s user experience, but you should try to keep the data up to date. This permission does not give you any rights to such data.”

The key—and the problem—with this response is the word “may” in “developers may only access…”.

If the word was “can”, then users could feel safe their data was protected unless they authorized the collection of data. But the “may” relies on developers’ compliance with Facebook’s terms of service.

Facebook is too large to always succeed in screening out bad guys before any damage is done. Beyond the manual and automated screening it does, Facebook must rely on reactive strategies to deal with those that do ignore the rules.

Facebook used three with Jerk.com: cutting off miscreants, putting them on notice and demanding compliance, and working with law enforcement. But fundamentally reactive strategies only give comfort if they are pursued thoroughly.

How much longer did users’ data remain up on Jerk.com than it would have, if Facebook had sued after its cease and desist was ignored in early 2012?