System, Method and Apparatus for Posing Leakage Queries in Free Text with Applications in Mobile Security
Publication Date: 2014-Jul-09
The IP.com Prior Art Database
This invention addresses the problem of characterizing the information-release behavior of a mobile application. A series of recent studies provides clear evidence that leakage of private information ? even by apps that are considered benign, for the purpose of advertisement, analytics, social computing, etc ? is extremely prevalent. We propose a novel interface, whereby the end user expresses privacy concerns in plain natural English. The user can then build an understanding of whether, and how, an app is handling sensitive information. This enables users to take informed decisions which permissions to grant an app and whether or not to install a given app based on a natural and general interface.
Page 01 of 3
Method and Apparatus for Posing Leakage Queries in Free Text with
Method and Apparatus for Posing Leakage Queries in Free Text with Applications in Mobile Security
Background. Mobile privacy is a growing concern. Mobile apps often demand access to sensitive pieces of data - such as the user's personal information, contacts and location - as well as sensitive system resources - such as the internet or the file system - which raises the threat of releasing private information in unauthorized ways.
As an example, the app may read the mobile device's unique hardware identifier (called IMEI) and release it through an HTTP request to a remote advertisement site.
A series of recent studies [PiOS, TDroid] provides clear evidence that leakage of private information - even by apps that are considered benign, for the purpose of advertisement, analytics, social computing, etc - is extremely prevalent. Many, if not most, of the top-popular apps on the Android and other markets release sensitive information in unintended ways.
While analysis tools [TDroid] and prevention tools [Xprivacy, Toggle] aim for general solutions for the leakage problem, it is often difficult to define exactly what data leakage is and when it occurs. As a simple example, consider an application that estimates battery life. If this application requires internet access, which it uses to compute a more precise estimate based also on similar devices in the vicinity while releasing the phone's hardware characteristics, then a given user may or may not perceive of this behavior as problematic. From one point of view, the app is releasing information only to improve its core functionality. Another viewpoint is that the app can manage, at least in principle, without needing access to the internet and without releasing any user-specific information.
Existing approaches are general. Automated approaches track flow of information from read points of sensitive data to release points [TDroid, DCLA]. Interactive tools let the user configure app permissions, thereby restricting the data and resources that an app has access to. In both cases, the challenge of understanding exactly what the app does, and whether the app's behavior is admissible, remains. To illustrate this, we return to our example above. An information-flow-based tool would classify the behavior of releasing phone identifiers as a leakage problem, where in some cases it may be desirable. Similarly, a user that has to decide whether or not the app should be granted the internet permission would not know how exactly the app uses the internet.
Summary. Because privacy is a grey zone, depending on user preferences and the exact circumstances in which a privacy threat arises, we believe that an interactive approach is valuable. However, asking users to manipulate programmatic entities such as permissions, which refer to code behaviors that the user does not understand and does not even have access to, is also of limited ut...