1.7.7 F-Droid Requires Location Services

[tryder]

I had downloaded RetroArch 1.7.7 via the F-Droid repository and recently was notified of a new version so I upgraded to the latest version in the F-Droid repository, 1.7.7_GIT, but when starting this new version I am prompted to enable “fine location” permission. If I click cancel the app remains blank with no options and is therefore unusable so naturally I downgraded to the 1.7.7 version.

My question is why are there two 1.7.7 versions in the F-Droid repository, 1.7.7 and 1.7.7_GIT, and why does the latest one require location services to work?

[hunterk]

We’re in a transition period, as Google has mandated that, as of September, any package in the Play Store must contain 64-bit applications and libraries. It can optionally contain 32-bit progs/libs, as well, and the host device will automatically choose the appropriate one (preferring 64-bit) at runtime.

Since we’re re-doing that package, we’re overhauling some other Android-related things in the process, including switching to a new SDK, and that’s probably where the permissions thing is coming from, as it seems it requests that permission if you even have the possibility of using location data.

When we made the Android port, we exposed that capability to cores, in case a hypothetical core ever wanted/needed to do that, but no cores ever actually used it (beyond a test core for that feature). I’m assuming that’s what’s causing it to ask for it.

tl;dr, we don’t actually collect any telemetry, etc. but it seems it asks for permission anyway, just because we have the capability to maybe one day use it, or something. We’ll try to either resolve the asking or just cut out the capability altogether in the near future.

[tryder]

I see. As a suggestion I think the standard practice is to prompt the user to grant a particular permission or set of permissions only when such access becomes necessary by the application and if the user denies the permission only disable parts of the application that rely upon it rather than disabling the entire application.

For example, in this case, RetroArch should not prompt the user to grant location permissions until the user tries to load a core that requires it. If, at that time, the user denies such permission the core simply won’t load, preferrably with a message telling the user why it won’t load. The rest of the application should still function properly.

Out of curiosity what SDK are you switching to? I didn’t know there were any options outside of Android-Studio.

I won’t be upgrading to any new versions so long as they require location service permission to function, but that’s just my philosophy on unnecessary permissions on Android, I’m sure you know how notorious Android applications are for playing fast and loose with user data. However; RetroArch is great, I must thank you for all the hard work.

[hunterk]

Sorry, not SDK. We’re still using Android Studio, but we’re switching to the Gradle build script system from Ant, among some other things (we’re having to change all of our recipes and whatnot).

Well, I’m hoping we can get the permission thing under control, but either way, you’re welcome to audit our code any time.

[tryder]

I believe you when you say you’re not collecting telemetry.

Personally I think the general public severely underestimates the impact data collection can, and likely will, have. I don’t really use Google Play myself so much, but I get the impression that it’s basically a disease reservior for your Android powered devices. By and large people are desensitized to it. It’s normal now for an image viewer to request network, bluetooth, contacts and location access so the embedded Facebook and Google data mining libraries can sell you out to the highest bidder.

I love RetroArch, everybody working on it has clearly put a lot of effort into pushing out a great application, but I’m not gonna start down that road myself. It’s not okay to just say “well this is open source so I trust it.” That’s when the waters start to muddy and your more nefarious actors come in to take advantage of that trust.

Take OpenSSL for example. Despite being widely used by virtually the entire internet and being open source a serious security flaw went unnoticed for years. Who’s to say someone couldn’t bury some code somewhere deep within RetroArch? Sure I could audit the code now and decide to grant the permission, but that permission would then be passed to every future version I upgrade to and I’m not going to audit every line of code every time a new version comes out. I’ll probably even forget that I ever granted location permission in the first place and just let it go unnoticed quietly being sold out, maybe not by you, but who knows who’s going to be managing RetroArch next year or the year after.

Anyway I’m sure it’s a moot point and you’ll get it worked out. There’s nothing within Android, Android-Studio or Gradle that forces an app to request, at startup, every permission it could possibly someday need. Well, not since Android 6.

[tryder]

On a whim I thought I’d take a look at the Exodus Privacy report on RetroArch and found that while the app is listed as having no ads, which appears to be true, the privacy report found the code signature for Google Ads which, obviously, is a data collection library.

I’m guessing this explains the fine location permission.

https://reports.exodus-privacy.eu.org/en/reports/76413/

[hunterk]

Hmm, dunno why that would be in there. That gives us something to look for, though. Thanks!