Motivation behind building this package (Why does it exist afterall?)
In iOS 6, Apple decided to change its strategy and introduced a new privacy-specific setting giving the user control over whether an App can access private data: the user is prompted the first time an App tries to access Contacts, Location, Reminders, Photos, Calendar and Social Networking accounts (Facebook, Twitter) and later, iOS remembers and follows the user preferences. A user can go to iOS 6 privacy-specific settings at any time and change his/her preferences. In our opinion, this is a decent step by Apple towards making iOS privacy friendly. However we believe that the set of data Apple considered as private in their iOS 6 privacy settings is still not exhaustive and it lacks some other kinds of private data. Moreover, we also believe that a user should be able to revoke access to internet for a particular app if he wants to do so. As a demonstration to Apple and others for its feasibility and usability, we came up with a software solution that enables user to have aforementioned control. Our privacy extension settings lets user choose:
The name of the device is usually set during the initial device setup and most of the time it contains the real name of the user. Moreover, even if the user does not set it to his/her real name, it might easily be used for tracking purposes since the device owner does not generally modify it after the initial setup. Therefore, we believe that a user permission is required before accessing it because our study reveals that a lot of third-party apps are surprisingly accessing the device name without user's knowledge even if there does not seem to be any obvious reason of doing so.
The API used to access UDID is obsolete in iOS 6 but Apps are still using it. New apps/updates will no more be able to use UDID after May 1 but it is still being used by Apps [Link To Article]. This necessitates its inclusion in private settings till it is not completely removed by Apple from iOS API.
We added Advertising Identifier in our privacy settings extension so that a user can choose to allow/deny access to it per-app basis. We believe that instead of putting it very deep somewhere in the iOS settings as is the case now, it should rather be put in privacy settings. Also, user should be able to choose to give access or deny access to it per-app basis as well; for instace, a user may allow access to Advertising Identifier for a particular free App while not allowing its access to paid Apps. This may be the driving force for developers to put free Apps on various App markets.
Lastly, in our privacy extension settings, we give control to the user if a particular App can access internet or not. We believe that it's very important because privacy breaches can be mitigated completely in the absence of internet connection for a particular app. There are a plenty of Apps, for example, vast majority of games, out their in the Apple AppStore which can be used without internet connection. Disabling internet connection for those apps would not only facilitate the increased user privacy but also reduced bandwidth usage. In addition, if one needs to use internet connection to do something specifically for a short period of time, (s)he might enable it for that short period of time and later, disable it again.
Below is a demo video explaining the functionalities of the package
Implementation specific details:
In our implementation of privacy extension settings, we don't really revoke the access to the private info (Device Name, UDID and Advertising Identifier) but rather pass a fake randomized value. This is due to the fact that Apple AppStore Apps are designed according to iOS API provided by Apple and they may not behave properly or crash if the access is just revoked. However, Internet access is revoked if user denies it at BSD socket level ensuring no way to bypass for a process/App.
The PrivacyExtension package for iOS 6 is an effort to extend the iOS 6 privacy settings. This package merely serves as a demonstration of its feasibility and usability. The package requires a modified iOS (iOS with system/root privileges and to be able to execute self-signed code) to be installed but we neither encourage people to modify their iOS software stack nor we take responsibility for any kind of bad/strange behavior caused.
In some countries, for example, France, it's illegal to modify the iOS software stack and we even recommend people residing in those countries to obey this.