The Brown PLT Blog
Social Ratings of Application Permissions (Part 1: Some Basic Conditions)
Posted on 18 May 2013.Smartphones obtain their power from allowing users to install arbitrary apps to customize the device’s behavior. However, with this versatility comes risk to security and privacy.
Different manufacturers have chosen to handle this problem in different ways. Android requires all applications to display their permissions to the user before being installed on the phone (then, once the user installs it, the application is free to use its permissions as it chooses). The Android approach allows users to make an informed decision about the applications they choose to install (and to do so at installation time, not in the midst of a critical task), but making this decision can be overwhelming, especially for non-expert users who may not even know what a given permission means. Many applications present a large number of permissions to users, and its not always clear why an application requires certain permissions. This requires users to gamble on how dangerous they expect a given application to be.
One way to help users is to rely on the expertise or experiences of other users, an approach that is already common in online marketplaces. Indeed, the Android application marketplace already allows users to rate applications. However, these reviews are meant to rate the application as a whole, and are not specific to the permissions required by the application. Therefore the overall star rating of an application is largely indicative of users’ opinions of the functionality of an application, not the security of the application. When users do offer opinions about security and privacy, as they sometimes do, these views are buried in text and lost unless the user reads all the comments.
Our goal is to make security and privacy ratings first-class members of the marketplace rating system. We have begun working on this problem, and will explain our preliminary results in this and a few more blog posts. All the experiments below were conducted on Mechanical Turk.
In this post, we examine the following questions:
- Will people even rate the app's permissions? Even when there are lots of permissions to rate?
- Does users’ willingness to install a given application change depending on when they are asked to make this choice - before they’ve reflected on the individual permissions or after?
- Do their ratings differ depending on how they were told about the app?
We created surveys that mirrored the data provided by the Android installer (and as visible on the Google Play Web site). We examined four applications: Facebook, Gmail, Pandora, and Angry Birds. We asked respondents to rate the acceptability of the permissions required by each application and state whether they would install the application if they needed an app with that functionality.
In the first condition, respondents were asked whether they would install the app before
or after they were asked to rate the app’s individual permissions. In this case, only Angry
Birds showed any distinction between the two conditions: Respondents were more likely to install
the application if the were asked after they were asked to rate the permissions.
Overall, however, the effect of asking before or after was very small; this is good, because it
suggests that in the future we can ignore the overall rating, and it also offers some flexibility for
interface design.
The second condition was how the subject heard about the app (or rather, how they were asked to
imagine they heard about it). Subjects were asked to imagine either that the app had been recommended
to them by a colleague, that the app was a top “featured app” in the app store, or that the
app was a top rated app in the app store. In this case, only Facebook showed any interesting results:
respondents were less likely to install the application if it had been recommended by a colleague than
if it was featured or highly rated. This result is particularly odd given that, due to the network effect
of an app like Facebook, we would expect the app to be more valuable if friends or colleagues also use it.
We would like to study this phenomenon further.
Again, though this finding may be interesting, the fact that it has so little impact means we can set this
condition aside in our future studies, thus narrowing the search space of factors that do affect how users
rate permissions.
That concludes this first post on this topic. In future posts we’ll examine the effect of branding, and present detailed ratings of apps in one particular domain. Stay tuned!
Aluminum: Principled Scenario Exploration Through Minimality
Posted on 13 May 2013.Software artifacts are hard to get right. Not just programs, but protocols, configurations, etc. as well! Analysis tools can help mitigate the risk at every stage in the development process.
Tools designed for scenario-finding produce examples of how an artifact can behave in practice. Scenario-finders often allow the results to be targeted to a desired output or test a particular portion of the artifact—e.g., producing counterexamples that disprove an assumption—and so they are fundamentally different from most forms of testing or simulation. Even better, concrete scenarios appeal to the intuition of the developer, revealing corner-cases and potential bugs that may never have been considered.
Alloy
The Alloy Analyzer is a popular light-weight scenario-finding tool. Let's look at at a small example: a (partial) specification of the Java type system that is included in the Alloy distribution. The explanations below each portion are quoted from comments in the example's source file.
abstract sig Type {subtypes: set Type}
sig Class, Interface extends Type {}
one sig Object extends Class {}
sig Instance {type: Class}
sig Variable {holds: lone Instance, type: Type}
fact TypeHierarchy {
Type in Object.*subtypes
no t: Type | t in t.^subtypes
all t: Type | lone t.~subtypes & Class
}
fact TypeSoundness {
all v: Variable | v.holds.type in v.type.*subtypes
}
Alloy will let us examine how the model can behave, up to user-provided constraints. We can tell Alloy to show us scenarios that also meet some additional constraints:
run {
some Class - Object
some Interface
some Variable.type & Interface
} for 4
Alloy always checks for scenarios up to a finite bound on each top-level type—4 in this case. Here is the one that Alloy gives:
This scenario illustrates a possible instance of the Java type system. It's got one class and one interface definition; the interface extends Object (by default), and the class implements the interface. There are two instances of that class. Variable0 and Variable1 both hold Instance1, and Variable2 holds Instance0.
Alloy provides a Next button that will give us more examples, when they exist. If we keep clicking it, we get a parade of hundreds more:
|
|
|
Even a small specification like this one, with a relatively small size bound (like 4), can yield many hundreds of scenarios. That's after Alloy has automatically ruled out lots of superfluous scenarios that would be isomorphic to those already seen. Scenario-overload means that the pathological examples--the ones that the user needs to see--may be buried beneath many normal ones.
In addition, the order in which scenarios appear is up to the internal SAT-solver that Alloy uses. There is no way for a user to direct which scenario they see next without stopping their exploration, returning to the specification, adding appropriate constraints, and starting the parade of scenarios afresh. What if we could reduce the hundreds of scenarios that Alloy gives down to just a few, each of which represented many other scenarios in a precise way? What if we could let a user's goals guide their exploration without forcing a restart? It turns out that we can.
Aluminum: Beyond the Next Button
We have created a modified version of Alloy that we call Aluminum. Aluminum produces fewer, more concise scenarios and gives users additional control over their exploration. Let's look at Aluminum running on the same example as before, versus the first scenario that Alloy returned:
|
The 1st Scenario from Alloy |
|
Compared to the scenario that Alloy produced, this one is quite small. That's not all, however: Aluminum guarantees that it is minimal: nothing can be removed from it without violating the specification! Above and beyond just seeing a smaller concrete example, a minimal scenario embodies necessity and gives users a better sense of the dependencies in the specification.
There are usually far fewer minimal scenarios than scenarios overall. If we keep clicking Next, we get:
|
|
Asking for a 4th scenario via Next results in an error. That's because in this case, there are only three minimal scenarios.
What if...?
Alloy's random, rich scenarios may contain useful information that minimal scenarios do not. For instance, the Alloy scenarios we saw allowed multiple variables to exist and classes to be instantiated. None of the minimal scenarios illustrate these possibilities.
Moreover, a torrent of scenarios--minimal or otherwise--doesn't encourage a user to really explore what can happen. After seeing a scenario, a user may ask whether various changes are possible. For instance, "Can I add another variable to this scenario?" More subtle (but just as important) is: "What happens if I add another variable?" Aluminum can answer that question.
To find out, we instruct Aluminum to try augmenting the starting scenario with a new variable. Aluminum produces a fresh series of scenarios, each of which illustrates a way that that the variable can be added:
|
|
|
(The newly added variable is Variable0.)
From these, we learn that the new variable must have a type. In fact, these new scenarios cover the three possible types that the variable can receive.
It's worth mentioning that the three augmented scenarios are actually minimal themselves, just over a more restricted space—the scenarios containing the original one, plus an added variable. This ensures that the consequences shown are all truly necessary.
More Information
To learn more about Aluminum, see our paper and watch our video here or download the tool here.
A Privacy-Affecting Change in Firefox 20
Posted on 10 April 2013.Attention, privacy-conscious Firefox users! Firefox has supported private browsing mode (PBM) for a long time, and Mozilla's guidelines for manipulating privacy sensitive data have not changed...but the implementation of PBM has, with potentially surprising consequences. Previously innocent extensions may now be leaking private browsing information. Read on for details.
Global Private-Browsing Mode: Easy!
In earlier versions of Firefox, PBM was an all-or-nothing affair: either all currently open windows were in private mode, or none of them were. This made handling sensitive data easy; the essential logic for privacy-aware extensions is simply:
if (inPBM)
...must store data only in memory...
else
...allowed to save data to disk...
(For the technically curious reader, there were some additional steps to take if extension code used shared modules: they additionally had to listen to events signalling exit from PBM, to flush any sensitive data from memory. This was not terribly hard; trying to "do the right thing" would generally work.)
Per-window Private Browsing: Trickier!
However, in Firefox 20, PBM is now a per-window setting. This means that both public and private windows can be open simultaneously. Now, the precautions above are not sufficient. Consider a session-management extension, that periodically saves all open windows and tabs:
window.setInterval(3000, function() {
if (inPBM) return;
var allWindowsAndTabs = enumerateAllWindowsAndTabs();
save(allWindowsAndTabs);
});
Most likely, this code internally uses Firefox's
nsIWindowMediator API to produce the enumeration. The
trouble is, that API does exactly what it claims: it enumerates
all windows—public and private—regardless of the
privacy status of the calling window. In particular, suppose that
both public and private windows were open simultaneously, and the
callback above ran in one of the public windows. Then
inPBM would be false, and so the rest of the
function would continue, enumerate all windows, and save them: a clear
violation of private browsing, even though no code was running in the
private browsing windows!
This code was perfectly safe in earlier versions of Firefox, because the possibility of having private and public windows open simultaneously just could not occur. This example demonstrates the need to carefully audit interactions between seemingly unrelated APIs, features, and modes—ideally, mechanically.
Takeaway Lessons
Private browsing “mode” is no longer as modal as it used to be. Privacy-conscious users need to take a careful look at the extensions they use—especially ones that observe browser-wide changes, like the session-manager example above—and double-check that they appear to behave properly with the new private-browsing changes, or (better yet) have been updated to support PBM explicitly.
Privacy-conscious developers need to take a careful look at their code and ensure that it's robust enough to handle these changed semantics for PBM, particularly in all code paths that occur after a check for PBM has returned false.