Draft: blog post about android permissions

This doesn't make sense. The way F-Droid displays permission is indeed misleading, especially when it comes to the lack of distinction between install time and runtime permissions. The problem here is not the fact that it shows the user the permissions that an app has, but rather how it shows it to users. This blog post does not address that and I am not even sure what it's trying to say.

Let's use this app as an example: https://f-droid.org/en/packages/im.vector.app/

According to the page, Element can:

Connect to paired Bluetooth devices: Without the Nearby Devices permission, it can't.
Read your contacts: No it can't, you have to go out of your way to grant it that.
Take pictures and videos while the app is in use: No it can't. You have to grant it that.
Record audio while the app is in use: Same as above.
Read the contents of your shared storage: Same as above.
Access approximate location only in the foreground: Same as above.
Access precise location only in the foreground: Same as above.
View network connections: I am assuming its tied to location permission. Same as above.
View Wi-Fi connections: I am assuming its tied to location permission. Same as above.

And I am not even sure that is all of the runtime permissions that the user can simply not grant the app or not. I just took a quick courtesy look.

This is in contrast to the install time permissions like network access that the user has no control over. Of course some apps can be annoying and straight up refuse to work if you don't grant them the permissions, but Element isn't doing that.

To make matters worse, we have things like "use fingerprint hardware" and "use biometric hardware". I am no Android developer, but I am pretty sure the app doesn't even see your fingerprint and this is the job between the fingerprint scanner and the Secure Element/TEE.

I can't see how displaying the permissions like this can possibly help anyone. A technical person will just open the manifest and read the declared permission. A non-technical person reading this will assume "Oh my god, Element can listen to me whenever I use it, it can take pictures of me when I am using it without my constent! Hell, it can even see my fingerprints too! Scary!!!!". This is in fact so bad that I think if you'd just display the actual manifest it would do less harm than showing the permissions this way.

Of course, this is fixable by changing how the permissions are actually displayed, showing what is configurable by the user and what is mandatory. It would be better to see the problem actually getting fixed.

I agree the way F-Droid currently shows it can be improved, but runtime permissions only exist since Android 6 and how Android deals with it depends on the app's targetSdkVersion. Given F-Droid supports Android 5.1+, for some users all permissions are install-time permissions.

I don't think anything can be done to disambiguate on the website given you can't really know with certainty which Android version someone is running (but I'd love to be proven wrong and see a great solution for the website too), but in the app it should be possible (I wonder if there is a list somewhere of which permissions are runtime under what conditions that could be used for this?).

Google's decision to hide it completely I do find troubling, as it makes it harder for users to make educated decisions on what they install as they can't even know the install time permissions anymore unless they're technical enough to open the manifest.

This blog post isn't a "permission handling in F-Droid is perfect", it's more of a "the direction Google is taking it in is worrying and we want to reassure users we're not planning to hide information that helps them make informed decisions on the apps they choose to use". But indeed, improved permission handling would help users to make more informed decision and is definitely a good step for F-Droid to make.

I guess. A couple of things though... I don't think you should let the cure be worse than the disease.

First of all, let's be realistic about this: no one who cares about their privacy or security would be running Android 5.1. Even Android 9 has gone completely end of life at this point, and everyone should be on Android 10 and above. That is API level 29.

Even when apps are legacy apps, if I remember correctly, they still need to prompt for permissions on modern Android.

It makes very little sense to care about API level 22, especially in 2022. It makes even less sense to let that be the reason why the permission shown on the website is misleading.

There is a reason why install time permissions are granted by default - they are not deemed as privacy invasive. I'd wager that maybe the INTERNET permission is questionable, but I don't think the other permissions are. Especially since Android 10, user-installed apps virtually cannot "spy" on the user in any meaningful capacity if they are not explicitly granted the permission to do so. In fact, I'd say that it is less bad to not show any permissions at all like Google does (again, because all of the privacy invasive permissions require a prompt) than showing a bunch of them without proper context and risk misinforming the user.

@tommytran732 Open issues for Client and Website with some mock-ups pls.

F-Droid currently heavily misleads users about how the permission model works. The correct approach is to match the same information shown by Android's package installation API. On modern Android, none of the user-facing (dangerous) permissions is granted by default by installing an app even for apps below API 23 and none of them is supposed to be shown at install time since the user chooses which are enabled at runtime. Apps should not be punished for supporting a feature requiring a permission that's not mandatory, and that's what F-Droid is doing by making users think that they receive access to it at install time.

Older versions of Android such as Android 6 granted the runtime permissions at install time for legacy apps, while still supporting toggles to turn them off. This hasn't been the case for a long time. The correct approach is to shown the runtime permissions as install time permissions for Android < 6 and API < 23 apps on Android > 6 but below the version where legacy apps stopped having runtime permissions granted at install time and instead have them set to an "enabled with review" mode where user has to review them on first launch of the application if any require review.

The low-level install time permissions are meant for developers. They have highly misleading user-facing descriptions not matching what is actually granted at install time. The majority of them are controlled by runtime permissions like Location, require case-by-case user consent (request install packages, request battery optimization exception, etc.), etc. Some like the Bluetooth permissions require Location for sensitive information. Nearby devices was introduced to reduce how much requires the user to grant Location access. Nearby devices works differently for apps targeting an API level predating it which receive it by default and still require Location for almost everything. Apps targeting an API level after it was introduced can get more from Nearby devices since it has to be user granted. They still need Location for full scan information.

Many of the low-level permissions have absolutely no meaning, such as the one for starting at boot, since there are other ways to start at boot. Querying all other packages can also be done just by listing out query filters manually and F-Droid displays NOTHING if you do that. You can list the query for launcher activity intents and then query all apps with launcher activities (99.9% of user installed apps) without QUERY_ALL_PACKAGES. QUERY_ALL_PACKAGES is an example of a permission which one day will be user facing when it actually provides users with any meaningful privacy properties. It does not right now, and therefore displaying it misleads users and makes them thinks apps without it cannot obtain that information when they can obtain it.

F-Droid is currently misleading users in both directions: wrongly telling them apps can access many things they can not, and wrongly implying apps can not access things they CAN access. This is the problem with surfacing the low-level developer permissions. It also doesn't help that F-Droid developers do not understand the permission model.

F-Droid privileged extension install path is the only case where the OS package installation UI isn't used, so that's where you are responsible for showing the correct information on legacy Android versions. There are 2 different cases where permissions should be shown: Android < 6, and API < 23 on Android versions predating the permissions review UI shown when the app targets an API predating runtime permissions and therefore requires the user to review permissions.

Worth noting: the F-Droid privileged extension install path currently has multiple serious security vulnerabilities. Privileged apps with the install packages permissions must enforce parts of the OS installation security model themselves. They take on responsibility for doing this. F-Droid ignores this and bypasses important security features of the OS, not that you care much about that, but it is what it is.

GrapheneOS expects F-Droid to stop misleading users about the permission model or we'll have to add a warning on each launch of the app explaining this. If other known usability and security issues continue not to be fixed, the same thing applies.

The INTERNET permission is arguably a special case since it was a dangerous permission, but they decided not granting it by default would be too invasive. There are also a lot of apps giving other apps partial bypasses, including browsers. There are 3 aftermarket OSes where users can properly disable network access (DivestOS, GrapheneOS, ProtonAOSP). LineageOS-based operating systems have very misleading leaky network toggles. Since there are apps requesting network access and then allowing other apps to access the network through them to an extent, this is a broader ecosystem issue. GrapheneOS is going to be forcefully fixing it for browsers. Other apps will be handled by an app scoping feature similar to our Storage Scopes and planned Contact Scopes features.

I can understand displaying INTERNET to end users, but you should probably include a disclaimer that the app could access the network without the INTERNET permission to an extent due to lack of ecosystem adoption of the INTERNET permission...

It would at least not be as misleading as the currently almost completely inaccurate F-Droid permission listings, which mislead users in both directions: falsely claiming apps will be able to access things they won't be able to access, and implying they won't be able to access things they will be able to access because you are surfacing things like QUERY_ALL_PACKAGES which are not yet enforcing any privacy model yet.

Ok, it is time to pause this thread and let things cool off.

locked this merge request

I deleted off-topic messages. Also, threats and insults are against our code of conduct.

@thestinger you have blocked most F-Droid contributors from your twitters, and kicked/banned most of us from grapheneos rooms. We know you do not like F-Droid, that is abundantely clear. I ask you to keep your posts to your own forums, and leave us in peace.

unlocked this merge request

locked this merge request

unlocked this merge request

@thestinger please keep it on topic, this is a merge request about a blog post on android permissions, so I deleted the off topic post.

@uniqx Thanks for taking up this topic! The core idea is good, but I think it will work better if it is framed more about how we do things than why we think Google Play is doing it wrong. Maybe it could be framed around which permissions are still useful (mic, camera) and why that info should be exposed.

IMHO the Android permissions model is a dumpster fire of questionable early design decisions and Google's current desperate measures to try to deal with the fact that the vast majority of apps in its ecosystem spy on users. Plus many of the permissions can be easily circumvented, for example, the INTERNET permission is largely useless for security. Google is concerned about two things there:

Users don't like being spied on.
All those apps spying on users are competition its own surveillance capitalism.

At least the basic runtime permissions granting microphone/camera access seem useful and reliable. What is fundamentally broken here is the idea that the OS can effectively sandbox untrusted apps while still providing a useful OS. Google is now locking everything down, and each new release breaks more valuable functionality, while preserving the use cases that fit into surveillance capitalism: users as pure consumers that can be steered by algorithms. But maybe I'm digressing to far here.

locked this merge request

@thestinger please stay on topic and heed our code of conduct. Unfortunately, I had to delete more off topic and CoC-violating posts. So I'm locking this again. @tommytran732 sorry, I don't want to lock you out of this discussion.

unlocked this merge request

I think @eighthave, @tommytran732 and @thestinger make some (over-exaggerated) but still good points. (Although, I don't get why they're so abrasive about it, makes cooperating really unpleasant ... @eighthave many thanks for moderating)

I'll try to look at updating permission displays on client and website, before taking another shot at writing a news item about permissions. (However between all my other tasks this could take months, maybe someone else on the team can beat me to it? 😸)

closed

Why close this though?

While the current UI display might have it's faults, that's another separate issue for Client/Website, imho.

I still think this should be blogged about.

Eg. Add a final note of: "The current display mode in F-Droid needs an overhaul to better convey the way permissions are applied and how they affect users"

mentioned in issue admin#369 (closed)

mentioned in merge request fdroidclient!1211 (closed)

Draft: blog post about android permissions

Closed by Michael Pöhn 17 Jul 2022 (17 July 2022 at 15:46:25 CEST) 17 Jul 2022

Activity

Draft: blog post about android permissions

Merge request reports

Closed by Michael Pöhn 17 Jul 2022 (17 July 2022 at 15:46:25 CEST) 17 Jul 2022

Activity