Android Privacy Guest Lecture

 Dr. Sai Teja Peddinti will talk today in terms of camera privacy. The lecture is about android permissions. Today we have a guest Speaker from Google and finished the PhD in NYU in 2015, and interned at Google for privacy joined full time with a PhD and been in Google since then. 

The lecture is reducing permission requests in Mobile Applications. This work was done with a few collaborator, and the project is about reducing permission for mobile apps. Google does multiple things to protect Android users and warns about unnecessary permission. It scan apps on the device for malware, and alerts whenever there is a malicious app on the device. This is focused on device security. Another thing that Google does is the Play policies, which further limiting developer's ability to abuse user sensitive data. For example there is policy changes when permissions are requested.  The third part is Developer Education, which is for example publishing best Practice Guidelines, discourage use of SDTP, etc. Android severely restricts developers strongly from using something. Financial apps need mechanism to detect fraud so they can user permanent identifiers. This warns developers about requesting unnecessary permissions.

Google has switched to a runtime permission level. If a location is request, the app will start to show popup data asking the user whether they want to accept or deny certain permission requests. The idea behind having this model is to protect the privacy of the Android. It restricts android user to sensitive data. You can always go back to the settings menu and subsequently change your permission. 

A major problem that comes up is that developers request a certain number of permissions but these apps have been requesting more and more permissions than they actually need. For example, a flashlight app can spy on you, etc. App permissions can be an all-access pass to your phone. There's no easy fix for this. Assess what permission is an app requesting. All of these tie to apps requesting many unnecessary permissions. 

Developers may want money. They need to be aware of the user privacy concerns. Third party libraries can give you detail on a crashing error, or earning money through ads, but these ad libraries, when you request permissions, will request in a file called manifest.xml where all of the permissions are accessed. As a result, you end up for 6-7 permissions instead of "2". Developers prefer to use default permissions if possible. Libraries have a way to request more permissions because more people make money. Many developers come from small to medium sized companies and 50% of developers come from companies that has fewer than 40 employees, and this probability is highly unlikely. You don't know if there are any problems in the legal or privacy side. 

People should earn money through a proper channeling. How do we incentivize developers? We need to get a consistent definition of what an unnecessary permission is.

Assume you have a functionality of multiple apps and compare the permission usages against functional apps. Try to see if there's a high likelihood that the permission is not needed for the app. What we do is play console is the web portal where the app doesn't work. We can surface a warning to the console to let developers know when other functionally similar apps are not requesting permissions. 

We let developer knows other apps are not requesting a permission, and say use the app that requests fewer permissions. This prompts them to try to get more installs in an app. "Your app is requesting the following permission which is used by less than x% of functionally similar apps: _________".

Ranks app based on the number of permission required (inversely, to the number of downloads). Also request users for permission. Do you actually need this? If so, explain it. If not, get it off. Many categories are too coarse. Another option is to user-co-click. The third option is to analyze the app description text using LDA* which is a topic analysis technique. 

Our approach is to identify groups for all apps in any language. Combine the app description and the user co-play patterns. Pump through Google translate to get English version. Given app a, give the apps that are closely flicked together by the user. Use deep learning to create an "embedding" *(vector presentation for multi dimensional space) for each lap. It uses NLP modelling.

We train a skip-gram language model, and concatenate each app token for the 10 most similar apps, and use a classifier for a softmax activation function. For example "chess" and "checker" are close to "board" "game" and "piece". 

In order to evaluate the similarity, we conducted a manual evaluation with similar apps. We want to look into the app description tasks and the user-clicked patterns in the raters. We ask if some pairs of apps are similar or not and see how the words are similar from 0 to 1. Google's app similarity approach has a score of 0.82, in comparison to simply using a user co-clicks, which yields an app similarity coefficient of 0.66. 

We developed an application and launched it as a privacy warning in August of 2017, and evaluated an app cutoff similarity. The big question is what threshold should we use to raise the privacy warning. To prevent desensitization, started with a conservative threshold of less than 1%, and then relax the threshold further to 3%. You have to request a permission that 99% of peers don't see this particular warning. Now, you can start warning more and more app developers when you relax something, and keep on relaxing the value. 

19,000 applications are shown warnings after 18 months post launch, a small percentage of the total amount of apps on the play store. Now this number is higher. Nearly 60% of permissions are removed and there were 55 billion impacts of app installed. 

Permissions are different from each other. There is a variation across permission tasks. We warned developers to remove "other permissions" which are  not warned about directly. Many permissions are actually removed after the launch (65%) which is a LOT. We wants to see if a particular use case will fit certain permissions. Do not use get account permissions unless you really need it. The recommended approach is to use an advertising id to get users what they want without being an offending device. 

We want to drive all the apps that have millions of installs. Apps in all play store categories removed permissions. 5% of removals happen within a day, and 50% occur within a 3-month time period. 25% of removals are immediate release and 70% take less than 10 version releases.

We saw 24% of warned developers revisited permissions by their unwarned apps, and they removed 60,993 permissions from 18,997 apps. Developers can see the negative user reviews and the negative press. These are possible reasons for removing permissions. 

There can be developer outreach issues such as console warnings, user  reviews, and changes to API. The control group without warnings have 9% of apps removing permissions. The warned apps have 59% of people remove certain permissions per app (that is unless it is entirely necessary.)

These apps might be receiving warnings, which the warnings are having some impact in changing the developer behavior to some extent. The warnings only reach some apps. There is a limitation that the approach does not flag a warning, and the thresholds are updated in the future. 

To conclude, developers are responding positively to policy warning, and permissions are affecting millions of devices. You can magnify the amount of impact that you can have and survey information to remove the permissions across that app.

The deep learning model gets periodically trained. There are also other warnings using ML and data analysis being trained. We try to restrict all the data that is looked into. We are trying to limit randomized bias to control bias.