Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

a place to identify what permissions a tracker requests #50

Open
jawz101 opened this issue Mar 16, 2019 · 4 comments
Open

a place to identify what permissions a tracker requests #50

jawz101 opened this issue Mar 16, 2019 · 4 comments
Labels
tracker Issue about the tracker database

Comments

@jawz101
Copy link

jawz101 commented Mar 16, 2019

We currently analyze an app to show what manifest permissions the app has but trackers document what manifest permissions they require or can use.

This would require digging through the documentation on the SDK pages but I think it's important and useful to see what manifest permissions might be solely required by a tracker.

"I have a game that requests location permission but there's no reason its gameplay needs location permission."

I think it's important to highlight this to app developers so they know the consequences of some trackers overstretching and tarnishing an app's reputation for excessive permissions. When developers are struggling to get an app out of 1-star territory because they've tried to monetize with crappy ad networks, perhaps it is a matter of highlighting what crappiness can come with some trackers.

It might also be nice to have a GDPR flag if a network says they respect GDPR and if they respect the android advertising ID.

http://users.eecs.northwestern.edu/~hxb0652/HaitaoXu_files/INFOCOM2018_2.pdf

https://hackernoon.com/app-monetization-data-vs-ads-b9d449584618?gi=86261475b444

https://forum.xda-developers.com/showthread.php?t=2366205

https://forum.unity.com/threads/unity-5-1-adds-android-permission-read_phone_state-automatically-how-to-remove-it.333431/page-3

https://android.stackexchange.com/questions/50091/heyzap-interstitial-ads-in-every-app

I also have a theory that more ad networks are going to hover around certain types of apps that have a main function to, say, record audio/video or a weather or fitness app that naturally needs location permission. It's a way to piggyback off of an expected permission.

@pnu-s pnu-s transferred this issue from Exodus-Privacy/exodus Jul 3, 2019
@pnu-s pnu-s added the tracker Issue about the tracker database label Jul 3, 2019
@eighthave
Copy link
Contributor

This sounds quite valuable to have in the dataset. I might have time to implement it, if Exodus wants to have it.

As part of the Tracking the Trackers project, we're currently digging into questions like this.

@aaronkaplan @MillivoltLightningbolt @uniqx @redplanet

@pnu-s
Copy link
Member

pnu-s commented Jan 22, 2020

Sure!
We can discuss here what form this could take in ETIP (and further on in exodus if we want to integrate it there)

@eighthave
Copy link
Contributor

I guess at the most basic level, it could just be a list of the permissions strings that the app wants the developer to set. If the library is an AAR rather than a JAR, I think it can include an AndroidManifest.xml which will request permissions. In that case, we should be able to automatically parse it too. For JARs, we'll have to rely on documentation, but there is a chance of mapping certain method calls to permissions.

As for the values to use, it should use the canonical strings that represent the permissions in Android. They are documented here as "Constant Value": https://developer.android.com/reference/android/Manifest.permission.html

@pnu-s
Copy link
Member

pnu-s commented Jan 23, 2020

Makes sense to me.
Feel free to open a PR if you have the time :)

Basically what we need to do is to create a new field and create also the list of permissions if we want a select form.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
tracker Issue about the tracker database
Development

No branches or pull requests

3 participants