Open source applications Terms of Service problem
From Facebook Developer Wiki
Contents |
How distributing an Open Source desktop application is hard within the Facebook Developer Terms of Service
Section 7 of the Facebook Developer Terms of Service prohibits disclosing an application's secret key to anyone else. The Open Source model centres around the distribution of the application in source code as well as binary form. Distributing the finished application therefore discloses the secret key, which contravenes ToS. Note the distinction between distributing an application and distributing a framework for the construction of applications without keys, which is unproblematic.
Consequences of the prohibition
Being unable to distribute the source code of the application with its secret key creates issues for someone wanting to develop and distribute a coherent open source Facebook application:
- The application cannot retain its identity, which is important for the application to have a social dimension.
- Other developers can't share the secret key under the ToS. Open Source development is usually carried out on a distributed basis, so group development on the same application would require sharing the secret key with other developers. These are often independent individuals working towards the same goal.
Working within the prohibition
One way to stay within the ToS and distribute the application is to distribute without keys and let the user enter them at run time. However, if every user has to register as a developer and enter their keys to use the application:
- the application becomes a swarm of apps sharing the same codebase with one user each,
- the applications has no social dimension:
- no viral propagation
- no way to usefully use platform features restricted to the set of application users - eg isAppUser, hasAddedApp, notifications.Send* without using a browser.
- there is a high barrier to using the application.
Another suggestion (from #facebook on Freenode) would be to create a proxy key server between the desktop app and the Facebook server, which would add the signature parameter to incoming requests, but this
- makes the problem worse by authenticating arbitrary requests
- requires maintenance
Creating a case for removing the prohibition
I (Wstephenson) would like to make a case for removing or rephrasing the prohibition on the disclosure of the secret key for desktop apps. To do so I will attempt to demonstrate two things: that the prohibition is ineffectual in the case of any desktop application, and that the potential for damage caused by desktop secret disclosure is low.
All desktop apps contain accessible secret keys
Closed source desktop applications also suffer from the key disclosure problem. It is trivial to extract strings including the secret key from the binary. If the author has taken steps to obfuscate the secret key this becomes only a little harder, but is within the everyday skill-set of most programmers.
Minimal potential for damage by desktop apps
The designers of the Platform API were aware of the above point, and limited the features available to desktop apps.
A modified version of a desktop application could act antisocially in the following ways:
- Modify the session user's profile FBML
- Notify spam the application's users, subject to the limits imposed by the platform. This is limited by the fact that the application can only discover whether the session user's friends are users of the application too, or spam randomly, which will exhaust the app's time-based call quota.
- Spam the session user's News Feed, subject to these limits:
- feed.publishStoryToUser only affects the session user's feed
- feed.publishActionOfUser uses feed points per friend of the session user so is rapidly exhausted.
- Harvest user info of the session user's friends. The info returned by users.getInfo is already a limited view of what is available using the FB web interface, and does not include any contact details.
- Spam the user's pending photo upload list with photos. These photos are not visible until manually approved and there is a limit on the number of pending photos allowed (see photos.upload, error code 325).
These malicious actions are limited in effect only to the session user or their friends, in which case they are tightly limited in number.
Since the desktop application would be obtained through the Directory, the scope for obtaining and installing a malicious program is limited to obtaining and using versions from an untrusted source.
Thus, any malicious effects caused by a rogue application will be localized to the few users running the subverted version, and can be stopped by cancelling the application's session in the Privacy page and preventing the app from starting another session.
It is my opinion that someone wanting to misuse the Facebook system would be able to do so more easily and effectively by either attacking a widely used FB website application, or by subverting a user's browser and using the web interface than by distributing a desktop app.
Another data point
The Flickr API ToS (which use the same auth model) do not forbid secret key disclosure.
Suggested solutions
- Remove the non-disclosure clause of the ToS for desktop applications (preferred)
- Acknowledge that all desktop applications disclose their secret key more or less easily, and modify the ToS to state that open source applications can distribute the secret key in an obscured form, ROT13 or similar. This is a figleaf solution, though.
- This has been done. The current version of the terms says, in section 7. Account Identifiers, Private keys are for your personal use only and you may not sell, transfer, lease, distribute, sublicense or otherwise disclose your private key to any other party, except when the private key is by necessity embedded in the source code of a client-resident Facebook Platform Application. (emphasis added). This is all that is being done at this point.
I've asked Jseligstein to bring this issue up at Facebook (mid June, Wstephenson).
