Monthly Archives: May 2014

Flappy Bird: A New Model for Software Innovation?

Okay, I know that the title may already have some people scoffing, but bear with me for the moment. This is about more than just Flappy Bird.

Picture this with me, if you will: you have written an app. You have written an app, and its popularity has skyrocketed. The ad revenue has gone through the roof. Suddenly, you are accosted on all sides by people saying things about your app. You had no idea that this was going to happen: as far as you were concerned when you wrote it, it was just another idea you wanted to try out. There was nothing to distinguish it, for you, from any of the other ideas that you had had, none of which had ever made much money.

So, what to do? You are a lone developer. You don’t have a PR department, so you have no way of dealing with the media circus that is suddenly surrounding you. You don’t have a legal department or experience with lawyers, so you also have no way to deal with the legal issues that may be raised – for instance, claims from users about health effects, claims from intellectual property holders about potential violations – not to mention the fact that you may find that you remain personally liable for these things, even after you incorporate or sell the app (which is something that may crop up when dealing with things like the Google Play Developer Agreement).

A naive solution

So what can you do? Well, the obvious things to do are either to build a new company around it, or to sell the app to a company that is already well-placed to handle this sort of concern. However, the fact that the app was released through Google Play might make this somewhat hard.

There are three main problems that I am aware of:

1. You can’t transfer the app to another Google account without also transferring the signing key (which the receiving entity requires in order to distribute software updates).

If you use the same signing key for other apps that you have written, you will probably be very reluctant to transfer it, because doing so will, in principle, give the recipient the ability to issue updates for your other apps, as well as make use of certain Android resources that are shared between your apps – such as custom identity providers (which may be unique to your particular “ecosystem” of apps) – which, in turn, may make it impossible for you to meet your legal obligations to your customers.

It will also, perhaps more importantly, mean that you no longer have control over the key’s security. This will be important to you if you want to continue supporting your old apps (which are also effectively “tied” to their original key), ensure your customers’ security, and release new apps of your own that are tied into the same identity ecosystem.

Releasing the new app under a separate package name does “solve” the problem – but only at the cost of automatically losing all of its existing customers, which may quite probably defeat the purpose.

2. You can’t transfer the Ad Units to another Google account – which the receiving entity needs in order to receive your Ad revenue.

It is true that once you have transferred the app, you can issue an immediate software update changing the Ad Units to ones owned by the receiving entity. However, in general, it is not compulsory for users to accept updates, and I have heard horror stories of app developers’ revenue streams falling off dramatically after they have been required (because of upgrades to Google’s platform) to switch their existing apps to new Ad Units – presumably because many users do not accept the update, and therefore continue to use a version of the app that uses the old Ad Unit.

One reason why users might switch off automatic updates is to save on bandwidth charges. Once a user has done this, each update is effectively “opt-in” and many users will simply not bother.

3. You can’t transfer your liability to another entity, under the Google Play Developer Agreement. (At least, without getting special approval from Google – and good luck with that.)

This is a particularly nasty one. Let us suppose that company “A” wants to buy your app. Company “A” is in the business of managing and supporting apps, and is willing and able to accept full legal responsibility for it from that point forward, as part of the purchase deal.

Now, you also give company “A” the app’s source code as part of the sale, and at some point it will release an update to Google Play. However, suppose that 50% of the existing (active) users choose not to update, and therefore carry on using the app in its prior state. These users received the app before the transfer, and therefore, full legal responsibility for their use of the app rests with you, according to the Google Play Developer Agreement. Moreover, this responsibility is non-transferable, and so it remains with you, even after the transfer of ownership. If someone decides that the app is infringing their IP (for example), they will not only be able to sue company “A” – they will also be able to sue you.

Now, I can see simple technological solutions to points 1 and 2 (requiring action by Google, unfortunately), and I can see that in principle it should be possible for Google to implement a legalistic solution to point 3.

Technological solutions

My solutions to points 1 and 2 are as follow (in reverse order):

2. The existing signed app (apk file) already functions as, effectively, a signed “request” asking the Android OS to use a particular Ad Unit. The cryptographic signature certifies that the request is from the app’s owner. This helps to keep the system secure, preventing a third party from forging a “request” and redirecting the ad revenue to their own account. A new signed request, changing the Ad Unit, is at present created by uploading a new signed apk file (i.e. an app update). The “request” is then honoured on a per-user basis, when (or if) they decide to accept the update.

However, there is no technological reason to require this particular protocol. A better protocol might be to allow the owner to sign a “request” consisting of only the unique package name of the app, the old and new Ad Units, and a special identifying code indicating the type of request being made (e.g. “ReplaceAdUnit”) (plus a timestamp). So the request might look something like this:

1400251570 ReplaceAdUnit com.mycompany.myapp 8f3b24fc 332bce29

After this has been signed using the normal signing key for com.mycompany.myapp, and then uploaded to Google, all requests from this particular app to the Google Ads API requesting Ad Unit “8f3b24fc” can instead be served using Unit “332bce29”, from the request timestamp (represented by 1400251570) onwards until any further such requests are made. Any further requests can change the Ad Unit again by referencing Unit 332bce29 – and requests for 8f3b24fc, as well as 332bce29, will be redirected to the new Unit (and this can be repeated indefinitely – the Ad Units will form a chain that can be followed iteratively, always picking the newest record and checking for monotonically increasing timestamps).

1. The solution to problem 1 should now be obvious. Another type of signed request can be created. Instead of replacing the Ad Unit, this time the request is to replace the signing key – perhaps call it ReplaceSigningKey. The request then consists of this operation identifier, plus the unique package identifier of the app, and the fingerprint of the new key (plus a timestamp). From that moment onwards, all updates to the app, as well as (naturally) all further signed requests, must be made with the new key – the old one will no longer work (this is important because the entity you are transferring it to may not want you to retain the ability to release signed versions of their app). No connection is established between the new and the old key – the new versions of the app will be within a new “domain” as far as Android is concerned, just as usually happens when a different signing key is used. Again, this helps with transfer-of-ownership scenarios.

This also, incidentally, helps ensure key security by allowing you to expire your old keys (in case they have been compromised).

Unfortunately, this change probably requires changes to the Android OS on each individual device. I am not sure how feasible this would be. It may be possible to implement it through an update to the Google Play app.

Lessons

In the case of point 3, it is clear that Google is placing legal restrictions that are artificially restricting the rights of individuals and businesses through Google’s monopoly-position on the provision of this particular type of publishing contract. Google Play is currently one of the world’s largest markets for computer software, and individuals and businesses cannot simply decide not to publish through Google Play: it is a practical necessity for certain types of business activity in today’s changing world. Therefore, by failing to include provisions for reassignment of liability in their standard publishing contract, it could be argued that Google Play is here abusing its monopoly position.

What may not be so clear is that the same argument could be applied to points 1 and 2. In both cases, Google is failing to provide the necessary flexibility for its users to carry out their business activities with the freedom to isolate, buy, and sell, business units as appropriate, making their cloud data usage securely separate as and when it is found to be appropriate. It is therefore, effectively (whether intended or not), forcing its customers into a certain pattern of internal organization, as a condition of performing certain activities that are necessary to their normal functioning as businesses – which could also be seen as an abuse of its monopoly position.

Advertisements

Leave a comment

Filed under Law, Software industry