Android 11 tries to enforce scoped storage which some developers aren’t a fan of but from the user perspective it brings more security and overall control about what the apps can do on the external storage. Unfortunately according to my understanding apps which target lover api versions can bypass this restrictions. Google tries to enforce the usage of the scoped storage with the Playstore instead of the operation system itself. In this regard I would like the F-Droid client to warn about apps wich use (legacy) functions (requestLegacyExternalStorage, MANAGE_EXTERNAL_STORAGE) to access the storage without the scoped storage framework (at least on devices with Android 11 and higher). I know that the client already shows permissions but I would prefer a warning similar to anti features like non-free network (maybe something like non-scoped storage access). I understand that some apps like file managers would still need full access to the storage but the client should warn about it.
And hello, I’m new here, this account was created just for this suggestion.
As a user I too am not a fan of Google’s increasingly restrictive storage policies. I appreciate that some feel that privacy and security are the end-all and be-all of “FOSS” but I like having control over my computing experience first and foremost. I think there is probably more than enough fearmongering over scary permissions anyway.
Are you a fan of apps creating “random” folders and files destroying the order you try to maintain? Google’s thinks it’s a good idea if only Google can decide which apps get absolute access. I think it’s a good idea if the user of the device can decide this. “I like having control over my computing experience first and foremost.” We seem to misunderstand each other (I’m not a native English speaker), I never said that you as a user should not have control. In contrast my suggestion would support you on keeping control, scoped storage access let’s you the user decide which of your folders your apps on your device can access.
Most of the software in the store is not up to date because they are usually non-profit projects which cannot be constantly developed, that does not mean that they are not useful, of course.
Some permissions can be dangerous when they are proprietary software, but that is not the case with F-Droid.
Each permission can be dangerous, in capable hands, you’d flood the user with prompts and they’ll learn to press I agree and then everything was useless.
So, I kinda think this idea has merit, but I also want to indeed not add extra pop-ups.
What about a small exclamation mark next to permissions if any of the permissions are “dangerous” and a small exclamation mark next to each dangerous permission when expanded?
Quick 2-minute mockup:
I wonder how to programmatically know what permissions are “dangerous” permissions though… But this should be a relatively easy thing to implement when it is known which are dangerous. Perhaps something to make a GitLab issue about and see if someone picks this up for Hacktoberfest? I think the idea itself is fine, personally.
Notably, apps that don’t target SDK28 or higher are subjected to fewer restrictions.
Yup. Any app with the insta-granted internet permission could get the whole list of your installed apps and send it to a remote server.
Things like that are/were pretty common in Play Store apps.
Since F-Droid is all about free software it is better for users to verify how each permission is used by each app. A dangerous permission or even a system protected permission could be harmless and some “normal” permission could be doing nasty things.
So use a ROM that has that Firewall (Calyx, Graphene, Divest?, etc) and/or use Netguard.
Only allow it if it needs it and you trust it
The problem with the exclamation mark is, “modify and delete content” is something you can do in both ways with scoped storage or the legacy way. What I want to be informed about is »how« the storage is accessed not »if«. Because it’s a difference if the app must ask you for a folder or file to work with or if it can access any folder on the external drive. An app can have legitimate reason to access folders and files but this doesn’t mean that it should be able to access all folders and files.
To solve my special case programmatically I already gave examples:
requestLegacyExternalStorage and
MANAGE_EXTERNAL_STORAGE
I mean one of them has literately “Legacy” in the name hinting that it’s not a good permission to have.
Or in other words it must be solved programmatically similar to how the Playstore solves it, but with warnings in the client instead of restrictions to upload the app (Google only allows whitelisted apps to use MANAGE_EXTERNAL_STORAGE If I’m not mistaken, that’s an unnecessary extreme step but that doesn’t mean we should not inform the user about it so that the user himself can “whitelist” the app by simply downloading it).
If you want users to verify, it’s contradicting to deny informations to the users. If you want users to act then give them tools, denieng that information is not better than Google denieng the users the decisions to install the apps Google did not whitelist because they brake scoped storage.
To say “you don’t need that information in the client, you can read the source code” is like saying “you don’t need the source code, you can decompile the apk and read the bytecode”. It’s the complete opposite of the idea behind Free software. Free software is based on the idea of making information (the source code) accessible (by publishing it and licensing it in a friendly form), hiding information is not the goal. If you are looking at it from an ideological perspective (which I don’t, software are just tools) It’s »free« information so the client should show it in the entirely in the spirit of »free« Software. The client is showing screenshots which is further away from the free source code than the permissions, the permissions are the same on each device because it’s part of the code, but what you see on the screenshots isn’t guaranteed to be the same on your device (different ratio, different Android version, etc.).
I think you lack relevant info about this topic.
SAF (used for scoped storage) doesn’t require any runtime permission, just an user confirmation using the file picker.
Any app that uses SAF (available from KitKat to select files, from Lollipop to select documents’ root) doesn’t require any storage permission, so the hint “modify and delete content” is all about apps that don’t use SAF or at least not exclusively.
Also SAF is the worst in terms of speed and reliability and doesn’t grant access to the underlying filesystem api. Most apps will use it only when there’s no other API available (for instance: to grant write permissions on a external sdcard) or forced by the requirement in API29+, if they’re on the playstore.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.