From b2d9616186a13b541ce4dc6d781bf1d547d98189 Mon Sep 17 00:00:00 2001 From: Wonderfall Date: Sat, 15 Jan 2022 16:41:44 +0100 Subject: [PATCH] package id issue --- content/posts/fdroid-issues.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/content/posts/fdroid-issues.md b/content/posts/fdroid-issues.md index 1ad8335..8dd5bd7 100644 --- a/content/posts/fdroid-issues.md +++ b/content/posts/fdroid-issues.md @@ -108,6 +108,8 @@ F-Droid also has a problem regarding the adoption of **[new signature schemes](h It is worth mentioning that their website has (for some reason) always been hosting an [outdated APK of F-Droid](https://forum.f-droid.org/t/why-does-the-f-droid-website-nearly-always-host-an-outdated-f-droid-apk/6234), and this is still the case today, leading to many users wondering why they can't install F-Droid on their secondary user profile (due to the downgrade prevention enforced by Android). "Stability" seems to be the main reason mentioned on their part, which doesn't make sense: either your version isn't ready to be published in a stable channel, or it is and new users should be able to access it easily. +Not really relevant to security, but F-Droid should enforce the approach of prefixing the package name of their alternate builds with `org.f-droid` for instance (or add a `.fdroid` suffix as some already have). Building and signing while reusing the package name is bad practice because it causes **signature verification errors** when some users try to update/install these apps from other sources, even directly from the developer. That is again due to the security model of Android which enforces a signature check when installing app updates (or installing them again in a secondary user profile). + ## 5. Misleading permissions approach F-Droid shows a list of the [low-level permissions](https://developer.android.com/reference/android/Manifest.permission) for each app: these low-level permissions are usually grouped in the standard high-level permissions (Location, Microphone, Camera, etc.) and special toggles (nearby Wi-Fi networks, Bluetooth devices, etc.) that are explicitly based on a type of sensitive data. While showing a list of low-level permissions could be useful information for a developer, it's often a **misleading** and inaccurate approach for the end-user. Apps have to [request the standard permissions at runtime](https://developer.android.com/guide/topics/permissions/overview#runtime) and do not get them simply by being installed, so knowing all the "under the hood" permissions is not useful and makes the permission model unnecessarily confusing.