Inferring apps' potential for undesired behaviour from the requested OS permissions - a Bayesian approach



Summary: App permissions are meant to inform users about the apps’ potential for undesired behaviour (not necessarily intentional on part of the developer). But the usual interpretation of permissions in isolation is flawed – permissions can be benign by themselves, but together with other granted permissions can create potential for undesired behaviour (e.g. READ_SMS is benign by itself, but if the app also has INTERNET permission then the users’ whole SMS history can be leaked to an external agent).

Background: we’ll be using the probability notation extensively below. The reader should make herself familiar with Bayes’ Theorem for inferring conditional probabilities.

We will refer to the set of permissions for an app by the vector  of binary indicator functions .

Now, the question we are trying to address is: what are the chances of an app causing undesirable behaviour(s) given the set of permissions requested by it?

Let us focus on an undesirable behaviour  (could be, for example, ‘crash the OS’, or ‘compromise user privacy’). Then, our problem statement is equivalent to saying “estimate ”.

Bayes rule (always) applies:

So, we need to estimate

Before we proceed further, notice that when comparing potential for multiple undesirable behaviours by the same app, the denominator in this expression is irrelevant since it is given for a particular app. And when comparing potential for a given undesirable behaviour amongst multiple apps, the  term in the numerator is invariant (since we are considering the same behaviour), but not the denominator because different apps will have different permissions requested.

Just so we are clear,

  : Likelihood of the app’s requested permissions configuration  being present in cases where apps indulge in undesirable behaviour , multiplied by the prior chance of any app indulging in the said undesirable behaviour and divided by the prior chance of app’s permissions configuration occurring.

Let us examine the broad properties of this relation for a moment, to see if it makes intuitive sense. First of all, the more unusual the permissions configuration (i.e.  is small), higher is the chance of the requesting app indulging in undesirable behaviour. And the more common the specific behaviour is in general (i.e.  is high), higher is the chance of our app doing it too. And the same with the chance of the given permissions configuration showing up in apps that exhibit the undesirable behaviour , i.e. high .

Moving on.

The three probability terms above are all measurable, at least in theory. Assume that there is a register somewhere of all released apps, the permissions they request* and what undesirable behaviours they exhibit (App stores directly provide information about the first 2 categories, but not the third - though star ratings can be used as proxy for desirability of apps’ behaviour, and in theory at least, user reviews can be parsed to provide a more granular information about apps’ behaviour).  With this information, we can simply count apps with the given permission set , and those with undesirable behaviour  (with and without permission set ) to obtain an estimate of all 3 terms above. But note that  and  are multivariate distributions with . A lot of data will be required to estimate these probabilities from the counts.

So, we simplify. The obvious simplification is to treat various permissions as independent of each other. Formally, . We proceed, though aware that this is not true (e.g. ). Permissions do tend to occur together. But because there are a lot of permissions, and also because we will always be working with a given set of permission statuses, we can fudge this. One way is to identify pairs of permission in the apps corpus that mostly occur together, and merge them into a pseudo permission. But we can only do this reliably if/when we have ‘enough’ data.

But with our assumption, the above relation becomes: . These terms can all be estimated from a moderately sized corpus of app descriptions and user feedback.

But the reality is that no such corpus is available to public at large (hooray for walled gardens!). So what should we do? Well, we can admit to the limits of our knowledge, and start making guesses. It is not that hard, and we can legitimately hope to get away with a lot of inexactitude, since we are only estimating the potential for an app to behave in an undesirable manner.

First of all,  (non-informative prior on a binary variable). Then  can be judiciously posited – e.g.  , while . Likewise, .

Btw, for completeness let us state that  

I am working on an enhancement to my launcher-like app, Apposite, to incorporate this information, so the user will be able to interrogate any installed app, and get a warning when new apps are installed.

*There is a distinction on Android between requested permissions and granted permissions. An app may request any permission, but it is up to the OS whether it will grant those permissions to the app. Likewise, and app could get permissions granted which it never explicitly requested (e.g. READ_CALL_LOGS on previous versions of the platform). I am of the view that only requested permissions should be considered for this analysis, and it is irrelevant whether permissions are granted or not. My reasoning is that requests are correlated to the developer’s intentions, while grants or denials would be automated.