PrivSec-dev/privsec.dev
1
0
Fork 0
mirror of https://github.com/PrivSec-dev/privsec.dev synced 2025-02-20 18:31:35 -05:00
Code

Rearrange sections for better flow

Browse Source 
Signed-off-by: friendly-rabbit-35 <169707731+friendly-rabbit-35@users.noreply.github.com>
This commit is contained in:
friendly-rabbit-35 2024-05-20 20:23:40 +00:00 committed by Friendly Rabbit
parent 1278ddaa51
commit 73e6589ce9
1 changed files with 50 additions and 50 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

100
content/posts/android/F-Droid Security Issues.md
View File

@ -10,9 +10,9 @@ F-Droid is a popular alternative app repository for Android, especially known fo
Before we start, a few things to keep in mind:
- The main goal of this write-up is to inform users so they can make responsible choices, not to trash someone else's work. I have respect for any work done in the name of good intentions. Likewise, please don't misinterpret the intentions of this article.
- You have your own reasons for using open-source or free/libre/whatever software which won't be discussed here. A development model shouldn't be an excuse for bad practices and shouldn't lure you into believing that it can provide strong guarantees it cannot.
- You have your own reasons for using open-source or free/libre/whatever software which won't be discussed here. A development model shouldn't be an excuse for bad practices and shouldn't lure you into believing that it can provide strong guarantees it cannot fulfill.
- A lot of information in this article is sourced from official and trusted sources, but you're welcome to do your own research.
- These analyses do not account for threat models and personal preferences. As the author of this article, I'm only interested in facts and not ideologies.
- These analyses do not account for threat models and personal preferences. As the author of this article, I'm only interested in facts, not ideologies.
*This is not an in-depth security review, nor is it exhaustive.*
@ -23,7 +23,7 @@ Unlike other repositories, F-Droid signs all the apps in the main repository wit
Normally, the developer is supposed to sign their own app prior to its upload on a distribution channel, whether that is a website or a traditional repository (or both). You don't have to trust the source (usually recommended by the developer) except for the first installation: future updates will have their authenticity cryptographically guaranteed. The issue with F-Droid is that all apps are signed by the same party (F-Droid), which is separate from the developer. You're now adding another party you'll have to trust since **you still have to trust the developer** anyway. This isn't ideal: **the fewer parties, the better**.
On the other hand, Play Store now manages the app signing keys too. [Play App Signing](https://developer.android.com/studio/publish/app-signing#app-signing-google-play) is required for app bundles which are, in turn, required for new apps since August 2021. These signing keys can be uploaded or automatically generated, and are securely stored by [Google Cloud Key Management Service](https://services.google.com/fh/files/misc/security_whitepapers_march2018.pdf). It should be noted that the developer still has to sign their app with **an upload key** so that Google can verify its authenticity before signing it with the app signing key. For apps created before August 2021 that may have [not opted in Play App Signing](https://developer.android.com/studio/publish/app-signing#opt-out) yet, the developer still manages the private key and is responsible for its security, as a compromised private key can allow a third party to sign and distribute malicious code.
On the other hand, the Play Store now manages the app signing keys too. [Play App Signing](https://developer.android.com/studio/publish/app-signing#app-signing-google-play) is required for app bundles which are, in turn, required for new apps since August 2021. These signing keys can be uploaded or automatically generated, and are securely stored by the [Google Cloud Key Management Service](https://services.google.com/fh/files/misc/security_whitepapers_march2018.pdf). It should be noted that the developer still has to sign their app with **an upload key** so that Google can verify its authenticity before signing it with the app signing key. For apps created before August 2021 that may have [not opted in Play App Signing](https://developer.android.com/studio/publish/app-signing#opt-out) yet, the developer still manages the private key and is responsible for its security, as a compromised private key can allow a third party to sign and distribute malicious code.
F-Droid requires the source code of an app to exclude any proprietary library or ad service, according to their [inclusion policy](https://f-droid.org/en/docs/Inclusion_Policy/). Usually, that means that some developers will have to maintain a slightly different version of their codebase for their app to comply with F-Droid's requirements. Besides, their "quality control" offers **close to no guarantees** as having access to the source code doesn't mean it can be easily reviewed. Saying the Play Store is filled with malicious apps is beyond the point: the **false sense of security** is a real issue. Users should not think of the F-Droid main repository as free of malicious apps, yet unfortunately many are inclined to believe this.
@ -39,13 +39,13 @@ While we've seen that F-Droid controls the signing servers (much like Play App S
F-Droid's answer, interesting yet largely unused, is [build reproducibility](https://f-droid.org/en/docs/Reproducible_Builds/). While deterministic builds are a neat idea in theory, it requires the developer to match their toolchain with what F-Droid provides. The additional work needed on both ends sometimes results in [apps severely lagging behind in updates](https://code.briarproject.org/briar/briar/-/issues/1612), so reproducible builds are not as common as we would have wanted. It should be noted that reproducible builds in the main repository can be exclusively developer-signed.
Google's approach is [code transparency for app bundles](https://developer.android.com/guide/app-bundle/code-transparency), which is a simple idea addressing some of the concerns with Play App Signing. A JSON Web Token (JWT) signed by a key private to the developer is included in the app bundle before its upload to Play Store. This token contains a list of DEX files and native `.so` libraries and their hashes, allowing end-users to verify that the running code was built and signed by the app developer. Code transparency has known limitations, however: not all resources can be verified, and this verification can only be done manually since it's not part of the Android platform itself. (This means that requiring a code transparency file cannot be enforced by the OS right now.) Despite its incompleteness, code transparency is still helpful, easy to implement, and thus something we should see more often as time goes by.
Google's answer is [code transparency for app bundles](https://developer.android.com/guide/app-bundle/code-transparency), which is a simple idea addressing some of the concerns with Play App Signing. A JSON Web Token (JWT) signed by a key private to the developer is included in the app bundle before its upload to the Play Store. This token contains a list of DEX files and native `.so` libraries and their hashes, allowing end users to verify that the running code was built and signed by the app developer. Code transparency has known limitations, however: not all resources can be verified, and this verification can only be done manually since it's not part of the Android platform itself. (This means that requiring a code transparency file cannot be enforced by the OS right now.) Despite its incompleteness, code transparency is still helpful, easy to implement, and thus something we should see more often as time goes by.
> What about other app repositories such as the Amazon Appstore?
[To my current knowledge](https://developer.amazon.com/docs/app-submission/understanding-submission.html#code_wrapper), the Amazon Appstore has always been wrapping APKs with their own code (including their own trackers), which means they were effectively resigning submitted APKs.
[To my current knowledge](https://developer.amazon.com/docs/app-submission/understanding-submission.html#code_wrapper), the Amazon Appstore has always been wrapping APKs with their own code (including their own trackers), which means they were effectively re-signing submitted APKs.
If you understood correctly the information above, Google can't do this for apps that haven't opted in Play App Signing. As for apps configured with Play App Signing, while Google could technically introduce their own code like Amazon, they wouldn't do that without announcing it since such a change would be easily noticeable by the app developer and more globally researchers. Google has other means on the Android app development platform to do so. Believing they won't do that based on this principle is not a strong guarantee, however, hence the above paragraph about code transparency for app bundles.
If you understood correctly the information above, Google can't do this for apps that haven't opted in Play App Signing. As for apps configured with Play App Signing, while Google could technically introduce their own code like Amazon, they wouldn't do that without announcing it since such a change would be easily noticeable by app developers and, more globally, researchers. Google has other means on the Android app development platform to do so. Believing they won't do that based on this principle is not a strong guarantee, however, hence the above paragraph about code transparency for app bundles.
Huawei AppGallery seems to have a [similar approach](https://developer.huawei.com/consumer/en/doc/distribution/app/20210812) to Google, where submitted apps could be developer-signed, but newer apps will be re-signed by Huawei.
@ -56,55 +56,16 @@ F-Droid not only requires specific changes for an app to comply with its inclusi
*This is one of the main reasons why Signal refused to support the inclusion of a third-party build in the F-Droid official repository. While [this GitHub issue](https://github.com/signalapp/Signal-Android/issues/127) is quite old, many points still hold true today.*
Considering all this, and the fact that their build process is often broken using outdated tools, you have to expect **far slower updates** compared to a traditional distribution system. Slow updates mean that you will be exposed to security vulnerabilities more often than you should've been. It would be unwise to have a full browser updated through the F-Droid official repository, for instance. F-Droid third-party repositories somewhat mitigate the issue of slow updates since they can be managed directly by the developer. However, they aren't ideal either as you will see below.
Considering all this, and the fact that their build process is often broken using outdated tools, you have to expect **far slower updates** compared to a traditional distribution system. Slow updates mean that you will be exposed to security vulnerabilities more often than you should've been. It would be unwise to have a full browser updated through the F-Droid official repository, for instance. F-Droid third-party repositories somewhat mitigate the issue of slow updates since they can be managed directly by the developer. However, they aren't ideal either as you will see in the next section.
## 3. Low target API level (SDK) for client & apps
SDK stands for *Software Development Kit* and is the collection of software to build apps for a given platform. On Android, a higher SDK level means you'll be able to make use of modern API levels of which each iteration brings **security and privacy improvements**. For instance, API level 31 makes use of improvements on Android 12.
As you may already know, Android has a strong sandboxing model where each application is sandboxed. You could say that an app compiled with the highest API level benefits from all the latest improvements brought to the app sandbox, as opposed to outdated apps compiled with older API levels, which have a **weaker sandbox**.
```
# b/35917228 - /proc/misc access
# This will go away in a future Android release
allow untrusted_app_25 proc_misc:file r_file_perms;
# Access to /proc/tty/drivers, to allow apps to determine if they
# are running in an emulated environment.
# b/33214085 b/33814662 b/33791054 b/33211769
# https://github.com/strazzere/anti-emulator/blob/master/AntiEmulator/src/diff/strazzere/anti/emulator/FindEmulator.java
# This will go away in a future Android release
allow untrusted_app_25 proc_tty_drivers:file r_file_perms;
```
This is a mere sample of the [SELinux exceptions](https://android.googlesource.com/platform/system/sepolicy/+/refs/tags/android-12.0.0_r21/private) that have to be made on older API levels to demonstrate why SDK level matters.
It turns out the official F-Droid client doesn't care much about this since it lags behind quite a bit, **[targeting the API level 29](https://gitlab.com/fdroid/fdroidclient/-/blob/master/app/build.gradle?ref_type=heads#L39)** (Android 10) of which some SELinux exceptions were shown above. As a workaround, some users recommended third-party clients such as [Droid-ify](https://github.com/Iamlooker/Droid-ify) or [Neo Store](https://github.com/NeoApplications/Neo-Store). The best F-Droid client is actually [F-Droid Basic](https://f-droid.org/en/packages/org.fdroid.basic) for the following reasons:
- Compared to the official F-Droid client, F-Droid Basic targets a higher SDK level (API level 34 to the official client's 29) and has a reduced attack surface, as features found in the official client (such as [Nearby Swap](https://f-droid.org/tutorials/swap/)) are not present in the "Basic" client.
- Compared to Droid-ify and Neo Store, F-Droid Basic supports repository mirrors properly and removes an extra party of trust, as it is maintained by the F-Droid team.
Furthermore, F-Droid **[doesn't enforce a minimum target SDK](https://gitlab.com/fdroid/fdroiddata/-/issues/2210#note_440967209)** for its official repository. The Play Store, on the other hand, [does that quite aggressively](https://developer.android.com/google/play/requirements/target-sdk) for new apps and app updates and refreshes these requirements every year:
- Since August 2023, the Play Store requires new apps to target at least API level 33 (Android 13), and existing apps must target Android 13 or higher for updates to be submitted.
Keeping the **app ecosystem modern and healthy** is necessary, though it may seem bothersome. As shown above, F-Droid's lack of enforcement on this front sends the wrong message to developers (and even users). They should care about an modern and healthy app ecosystem, and this is why many of us think F-Droid's [relegation of this upkeep](https://gitlab.com/fdroid/fdroiddata/-/issues/2210#note_440967209) to individual app developers may be even harmful to the FOSS ecosystem. Backward compatibility is often the enemy of security, and while there's a middle-ground for convenience and obsolescence, it shouldn't be exaggerated. As a result of this philosophy, the main repository of F-Droid is filled with obsolete apps from another era, just for these apps to be able to run on the more than ten years old Android 4.0 "Ice Cream Sandwich". Let's not make the same mistake as the desktop platforms: instead, complain to your vendors for selling devices with no decent OS/firmware support.
There is little practical reason for developers not to increase the target SDK version (`targetSdkVersion`) with each Android release. This attribute matches the version of the platform an app is targeting, and allows access to modern improvements, rules and features on a modern OS. An app can still ensure backwards compatibility in such a way that it can run on older platforms: the `minSdkVersion` attribute informs the system about the minimum API level required for the application to run. Setting it too low isn't practical though, because this requires having a lot of fallback code (most of which is handled by common libraries) and separate code paths.
At the time of writing:
- Android 12 is the oldest Android version that is [getting security updates](https://endoflife.date/android).
- [~80% of the Android devices](https://developer.android.com/about/dashboards) used in the world are running **at least** 8.0 Oreo.
*Overall statistics do not reflect real-world usage of a given app (people using old devices are not necessarily using your app). If anything, it should be viewed as an underestimation.*
## 4. General lack of good practices
## 3. General lack of good practices
The F-Droid client allows multiple repositories to coexist within the same app. Many of the issues highlighted above were focused on the main official repository which most F-Droid users use anyway. However, having **other repositories in a single app also violates the security model of Android** which was not designed for this at all. The OS expects you to trust **an app repository as a single source** of apps, yet F-Droid violates this model as it mixes several repositories in one single app by design. This is important because the OS management APIs and features (e.g., [UserManager](https://developer.android.com/reference/android/os/UserManager), which can be used to prevent a user from installing third-party apps) are not meant for this and see F-Droid as a single source. You're trusting the app client to not mess up far more than you should, especially when the **privileged extension** comes into the picture.
There is indeed a serious security issue with the OS first-party source feature being misused, as the privileged extension makes use of the `INSTALL_PACKAGES` [API](https://developer.android.com/reference/android/Manifest.permission#INSTALL_PACKAGES) in an insecure manner (i.e., not implementing it with the appropriate security checks). The privileged extension accepts any request from F-Droid, which again suffers from various bugs and security issues and allows user-defined repositories by design. A lot can go wrong, and bypassing security checks for powerful APIs should definitely not be taken lightly.
On that note, it is also worth noting that the repository metadata format for F-Droid isn't properly signed as it lacks whole-file signing and key rotation. [Their index v1](https://f-droid.org/2021/02/05/apis-for-all-the-things.html#the-repo-index) format [uses JAR signing](https://gitlab.com/fdroid/fdroidserver/-/blob/d70e5c2cd92eb1924caf51a1f88202749956038f/fdroidserver/signindex.py#L40) with `jarsigner`, which has serious security flaws. F-Droid added their [index v2](https://f-droid.org/docs/All_our_APIs/#the-repo-index) format with [support for `apksigner`](https://gitlab.com/fdroid/fdroidserver/-/commit/3182b77d180b2313f4fdb101af96c035380abfd7#e915676f3ed7e51adef7ee3d1eaa0ef7be386a84) in May 2022, but this just seems to be an over-engineered and flawed approach since better suited tools such as `signify` could be used to sign the metadata JSON.
On that note, the [new unattended update API](https://developer.android.com/reference/android/Manifest.permission#UPDATE_PACKAGES_WITHOUT_USER_ACTION) added in API level 31 (Android 12) that allows seamless app updates for app repositories without [privileged access](https://f-droid.org/en/packages/org.fdroid.fdroid.privileged/) to the system (such an approach is not compatible with the security model) won't work with F-Droid "as is". It should be mentioned that the third-party client [Neo-Store](https://github.com/Iamlooker/Droid-ify/issues/20) supports this API, although the underlying issues about the F-Droid infrastructure largely remain. Indeed, this secure API allowing for unprivileged unattended updates requires not only the app repository client to target API level 31, but also the apps to be updated to target at least API level 29. *Update: since version 1.19.0, both the official F-Droid client and F-Droid Basic support unprivileged unattended updates on Android 12 or later, but the issues with the privileged extension when installing apps through F-Droid remain.*
As a matter of fact, the [new unattended update API](https://developer.android.com/reference/android/Manifest.permission#UPDATE_PACKAGES_WITHOUT_USER_ACTION) added in API level 31 (Android 12) that allows seamless app updates for app repositories without [privileged access](https://f-droid.org/en/packages/org.fdroid.fdroid.privileged/) to the system (such an approach is not compatible with the security model) won't work with F-Droid "as is". It should be mentioned that the aforementioned third-party client [Neo-Store](https://github.com/Iamlooker/Droid-ify/issues/20) supports this API, although the underlying issues about the F-Droid infrastructure largely remain. Indeed, this secure API allowing for unprivileged unattended updates requires not only the app repository client to target API level 31, but also the apps to be updated to target at least API level 29. *Update: since version 1.19.0, both the official F-Droid client and F-Droid Basic support unprivileged unattended updates on Android 12 or later, but the issues with the privileged extension when installing apps through F-Droid still remain.*
It is also worth noting that the repository metadata format for F-Droid isn't properly signed as it lacks whole-file signing and key rotation. [Their index v1](https://f-droid.org/2021/02/05/apis-for-all-the-things.html#the-repo-index) format [uses JAR signing](https://gitlab.com/fdroid/fdroidserver/-/blob/d70e5c2cd92eb1924caf51a1f88202749956038f/fdroidserver/signindex.py#L40) with `jarsigner`, which has serious security flaws. F-Droid added their [index v2](https://f-droid.org/docs/All_our_APIs/#the-repo-index) format with [support for `apksigner`](https://gitlab.com/fdroid/fdroidserver/-/commit/3182b77d180b2313f4fdb101af96c035380abfd7#e915676f3ed7e51adef7ee3d1eaa0ef7be386a84) in May 2022, but this just seems to be an over-engineered and flawed approach since better suited tools such as `signify` could be used to sign the metadata JSON.
F-Droid's official client also lacks **TLS certificate pinning**. Certificate pinning is a way for apps to increase the security of their connection to services [by providing a set of public key hashes](https://developer.android.com/training/articles/security-config#CertificatePinning) of known-good certificates for these services instead of trusting pre-installed CAs. This can avoid some cases where an interception (*man-in-the-middle* attack) could be possible and lead to various security issues, considering you're trusting an app to deliver you other apps.
@ -133,7 +94,46 @@ Certificate pinning is an important security feature that is also straightforwar
To be fair, the F-Droid team has considered several times about adding certificate pinning to their client [at least for the default repositories](https://gitlab.com/fdroid/fdroidclient/-/issues/105). [Relics of preliminary work](https://gitlab.com/fdroid/fdroidclient/-/blob/1.14-alpha4/app/src/main/java/org/fdroid/fdroid/FDroidCertPins.java) can even be found in their current codebase, but it's unfortunate that they haven't been able to find [any working implementation](https://github.com/f-droid/fdroidclient/commit/7f78b46664981b9b73cadbfdda6391f6fe939c77) so far. Given the overly complex nature of F-Droid, that's largely understandable.
F-Droid also has a problem regarding the adoption of **[new signature schemes](https://source.android.com/security/apksigning)**. They [held out on the v1 signature scheme](https://forum.f-droid.org/t/why-f-droid-is-still-using-apk-signature-scheme-v1/10602) (which was [horrible](https://www.xda-developers.com/janus-vulnerability-android-apps/) and deprecated since 2017) until they were forced by Android 11 requirements to support the newer v2/v3 schemes (v2 was introduced in Android 7.0, v3 in Android 9). Quite frankly, this is straight-up bad, and **signing APKs with GPG** is no better, considering [how bad PGP and its reference implementation GPG are](https://latacora.micro.blog/2019/07/16/the-pgp-problem.html) (even Debian [is trying to move away from it](https://wiki.debian.org/Teams/Apt/Spec/AptSign)). Ideally, F-Droid should fully move on to newer signature schemes, and should completely phase out the legacy signature schemes which are still being used for some apps and metadata.
Furthermore, F-Droid has a problem regarding the adoption of **[new signature schemes](https://source.android.com/security/apksigning)**. They [held out on the v1 signature scheme](https://forum.f-droid.org/t/why-f-droid-is-still-using-apk-signature-scheme-v1/10602) (which was [horrible](https://www.xda-developers.com/janus-vulnerability-android-apps/) and deprecated since 2017) until they were forced by Android 11 requirements to support the newer v2/v3 schemes (v2 was introduced in Android 7.0, v3 in Android 9). Quite frankly, this is straight-up bad, and **signing APKs with GPG** is no better, considering [how bad PGP and its reference implementation GPG are](https://latacora.micro.blog/2019/07/16/the-pgp-problem.html) (even Debian [is trying to move away from it](https://wiki.debian.org/Teams/Apt/Spec/AptSign)). Ideally, F-Droid should fully move on to newer signature schemes, and should completely phase out the legacy signature schemes which are still being used for some apps and metadata.
## 4. Low target API level (SDK) for client & apps
SDK stands for *Software Development Kit* and is the collection of software to build apps for a given platform. On Android, a higher SDK level means you'll be able to make use of modern API levels of which each iteration brings **security and privacy improvements**. For instance, API level 31 makes use of improvements on Android 12.
As you may already know, Android has a strong sandboxing model where each application is sandboxed. You could say that an app compiled with the highest API level benefits from all the latest improvements brought to the app sandbox, as opposed to outdated apps compiled with older API levels, which have a **weaker sandbox**.
```
# b/35917228 - /proc/misc access
# This will go away in a future Android release
allow untrusted_app_25 proc_misc:file r_file_perms;
# Access to /proc/tty/drivers, to allow apps to determine if they
# are running in an emulated environment.
# b/33214085 b/33814662 b/33791054 b/33211769
# https://github.com/strazzere/anti-emulator/blob/master/AntiEmulator/src/diff/strazzere/anti/emulator/FindEmulator.java
# This will go away in a future Android release
allow untrusted_app_25 proc_tty_drivers:file r_file_perms;
```
This is a mere sample of the [SELinux exceptions](https://android.googlesource.com/platform/system/sepolicy/+/refs/tags/android-12.0.0_r21/private) that have to be made on older API levels to demonstrate why SDK level matters.
It turns out the official F-Droid client doesn't care much about this since it lags behind quite a bit, **[targeting the API level 29](https://gitlab.com/fdroid/fdroidclient/-/blob/master/app/build.gradle?ref_type=heads#L39)** (Android 10) of which some SELinux exceptions were shown above. As a workaround, some users recommended third-party clients such as [Droid-ify](https://github.com/Iamlooker/Droid-ify) or [Neo Store](https://github.com/NeoApplications/Neo-Store). The best F-Droid client is actually [F-Droid Basic](https://f-droid.org/en/packages/org.fdroid.basic) for the following reasons:
- Compared to the official F-Droid client, F-Droid Basic targets a higher SDK level (API level 34 to the official client's 29) and has a reduced attack surface, as some features found in the official client (such as [Nearby Swap](https://f-droid.org/tutorials/swap/)) are not present in the "Basic" client.
- Compared to Droid-ify and Neo Store, F-Droid Basic supports repository mirrors properly and removes an extra party of trust, as it is maintained by the F-Droid team.
Furthermore, F-Droid **[doesn't enforce a minimum target SDK](https://gitlab.com/fdroid/fdroiddata/-/issues/2210#note_440967209)** for its official repository. The Play Store, on the other hand, [does that quite aggressively](https://developer.android.com/google/play/requirements/target-sdk) for new apps and app updates and refreshes these requirements every year:
- Since August 2023, the Play Store requires new apps to target at least API level 33 (Android 13), and existing apps must target Android 13 or higher for updates to be submitted.
Keeping the **app ecosystem modern and healthy** is necessary, though it may seem bothersome. As shown above, F-Droid's lack of enforcement on this front sends the wrong message to developers (and even users). They should care about an modern and healthy app ecosystem, and this is why many of us think F-Droid's [relegation of this upkeep](https://gitlab.com/fdroid/fdroiddata/-/issues/2210#note_440967209) to individual app developers may be even harmful to the FOSS ecosystem. Backward compatibility is often the enemy of security, and while there's a middle-ground for convenience and obsolescence, it shouldn't be exaggerated. As a result of this philosophy, the main repository of F-Droid is filled with obsolete apps from another era, just for these apps to be able to run on the more than ten years old Android 4.0 "Ice Cream Sandwich". Let's not make the same mistake as the desktop platforms: instead, complain to your vendors for selling devices with no decent OS/firmware support.
There is little practical reason for developers not to increase the target SDK version (`targetSdkVersion`) with each Android release. This attribute matches the version of the platform an app is targeting, and allows access to modern improvements, rules and features on a modern OS. An app can still ensure backwards compatibility in such a way that it can run on older platforms: the `minSdkVersion` attribute informs the system about the minimum API level required for the application to run. Setting it too low isn't practical though, because this requires having a lot of fallback code (most of which is handled by common libraries) and separate code paths.
At the time of writing:
- Android 12 is the oldest Android version that is [getting security updates](https://endoflife.date/android).
- [~80% of the Android devices](https://developer.android.com/about/dashboards) used in the world are running **at least** 8.0 Oreo.
*Overall statistics do not reflect real-world usage of a given app (people using old devices are not necessarily using your app). If anything, it should be viewed as an underestimation.*
## 5. Confusing UX
It is worth mentioning that the F-Droid 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). This is still the case today, which leads many users to wonder why they can't install F-Droid on a 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 land in a stable channel, or it is and new users should be able to access it easily.