My Customers Are Not The Customers of my Application Platform

Imagine the following scenario:

There are various reasons why an item of content might be objectionable, such as:

The important issue is not just that someone objects to the content, but that someone might be held legally responsible for it.

And herein lies the rub, because there are three parties who might be held responsible for providing the content, i.e.:

In fact any or all of these parties could be held responsible. But the party that can be held most directly responsible is the Application Platform Provider, because, among other things, they will own the relevant IP address.

If the content is sufficiently objectionable, and the legal risk is sufficiently great, then the Application Platform Provider will wish to un-post the content as quickly as possible.

And there is only one way for them to do that, which is to disable the whole Application. (The recent events involving a global takedown of Blogetery by their hosting service is an example of this type of situation.)

And if that happens, all the Users of the Application will have their service suspended, until such time as the Application Provider can determine the owner of the Objectionable Content and fix the problem so that the Application can be re-enabled.

The Solution

If I'm an Application Provider, I want a way to protect my Application Platform Provider from the legal risks of my Users' Content, which doesn't require the Application Platform Provider to suspend service for all my Users.

A simple solution is for the Application Provider to set up a limited TakeDown Admin Account which enables the Application Platform Provider to determine ownership of published content and to either unpublish specific content items, or suspend a user (and therefore unpublish all of that user's content).

A Pre-Defined TakeDown Admin

In the case of an application platform such as Google AppEngine, which itself directly provides user authentication, this can be as simple as a standard platform user, e.g. it might be a user with an ID such as takedown-admin@google.com. The AppEngine could even include a method in the API to determine that a user has takedown admin rights.

Given the existence of such a takedown admin, it is then up to the Application Provider to add functionality to the Application which displays to that user information about content items, ownership of content items by application users (who don't necessarily have to be users as defined by the Application Platform), and provides UI for disabling either specific content items or specific users.

Other Implementations

In the more general case, an Application Platform may not provide any pre-defined user database within which a takedown admin user can be included. However, one of various "standard" global user authentication schemes could be used to specify a takedown admin for an Application Platform, i.e. an OpenID, or an email address (to which specific login details would be emailed by the Application Provider).

The Business Case

For anyone hoping to use an application platform such as Google AppEngine to provide a service which might be used by a large number of users, such a facility is almost essential.

If the only way Google can disable content provided by one of my users is to disable the account of my other 10,000 users, then it becomes difficult for me to guarantee any reasonable level of service to those 10,000 users, regardless of how reliable Google AppEngine might be. But if I give Google the ability to rapidly disable individual items of objectionable content, then this risk is removed. (And also, I don't need to be available 24/7 to deal directly with takedown requests coming from Google.)

Of course there is still the issue of finding out the cause of the complaint, and passing that information on to my user, and determining between myself, Google and the user whether the complaint is valid. But that kind of issue is going to happen whether or not an Application is hosted on an Application Platform or not.