Alternative security-focused F-Droid client

,
1

Hello,

There are currently two official F-Droid clients:

  • F-Droid, the classic full-featured client, and

  • F-Droid Basic, a modern client with a reduced feature set.

I would like to propose creating another official client with an even more reduced feature set, which would be marketed as a “hardened” / security-focused client.

Rationale

Some people consider using the existing F-Droid clients as a security threat. To understand why, one should have the Android OS security model in mind. With regards to installing apps, the Android OS security model assumes two things:

  • Trust in the app author, materialized as a cryptographic signature in the APK. The Android OS will block an app update if the new APK is not signed with the same signature as the old one, which is assumed to be the signature of the app author.

  • Trust in the app store, materialized as a specific permission that needs to be granted to each app store. The OS will block an app install if it the app store that installs it does not have this permission.

The current F-Droid clients can be considered to break this model:

  • The trust in app authors is broken, as 91% of the apps distributed by F-Droid are built and signed with a signature managed by F-Droid instead of their author. This means that F-Droid could change what these app contain without the knowledge or consent of their author. This does not concern the 9% of apps that are reproducible by F-Droid, and therefore signed by their author. (Note that the Google Play Store also breaks trust in app authors: apps are now required to let Google manage their signature in order to be published on Google Play.)

  • It breaks the trust in app stores. The F-Droid clients allows users to install apps from additional repositories. This means that users could add repositories that distribute apps that are not curated by F-Droid and therefore potentially unsafe using the same client, without the Android OS asking to grant an additional permission for it.

Proposal

I would like to propose creating a new official client that would:

  1. Only list and install apps from the official F-Droid repository that have reproducible builds,

  2. Not allow adding other repositories (the client would have the Tethered Network antifeature),

  3. (Optional) Have an option to share an APK before installing it, like Obtainium does. This would let users verify an the APK signature using an app such as AppVerifier.

I believe that this new F-Droid client would be beneficial to many users that are currently unable to use F-Droid due to their threat model. Combined with the guarantee of FOSS reproducible builds that only F-Droid offers, this could become the most secure way to find and install apps on Android.

Apart from an optional new feature, creating this client would only require removing functionalities from the F-Droid Basic client. This could therefore be implemented as a fork from the F-Droid Basic client and would need a low development time and a be minimal maintenance burden.

Please let me know what you think.

3 Likes
2

This would be very much nice to see overall. Though I’d imagine someone would need to step up to actually maintain such a fork.

Personally I never saw this as a big risk and I still don’t. Only if F-Droid is included as a third party app store however. As you mentioned the user has to explicitly use extra repositories. Though I feel it might be good to add some extra warning labels for more inexperienced users for example say a popup on first time of opening the repositories section.

However I do agree still it would be very good to have a hardened client without this feature as I do see extreme risk if a operating system were to include F-Droid as a first party app store.

Cause then hypothetically if you give someone your phone temporarily in a separate user profile and lock it to first party app stores… If they are intelligent enough they could exploit the fact that F-Droid is able to use multiple repositories and install apps technically from unknown sources still through that

But also this introduces the issue that some operating systems use their own third party F-Droid repositories for delivery of application updates. I think a easy fix for this however is to still allow extra repositories in the code but don’t allow adding new ones in the app. So that way developers can include the necessary repositories needed for their OS to receive speedy updates. This way also doesn’t break the trust in my opinion as this implies the developers of said OS trusts these extra app sources.

1 Like
3

So few people know about F-Droid, developers don’t know anything, current users don’t advertise it, “big apps” are not FOSS…

but you know what… let’s have even less people use it, what a great idea…

C’mon :man_facepalming:

That’s a lie.

Basic HAS NOTHING EXTRA, it has LESS features… get the thing right at least.

Higher TargetSDK is not the “one true answer that will bring the cows home”

/PS: count how many times #geekproblem is used: State Funding of #FOSS and Open Source: Is it a Good Idea or a Bad Idea? – Hamish Campbell then imagine digging a bigger whole for F-Droid to sink in

IMHO, we should bring the best F-Droid to more people, not less, see https://mobifree.org/

3 Likes
4

This is correct. Higher TargetSDK is nice but is not nearly significant enough on it’s to own miraculously change everything in terms of security.

That’s also a fair argument. Would be wise if somebody were to make a fork like this to rebrand it to avoid confusion.

This is also a fair argument. Apologies I was not seeking to undermine F-Droid. I was just entertaining the idea that a possible hardened fork could be a pretty nice idea. I would never want the original to be replaced with this purely hypothetical fork or for the fork to undermine the original however.

2 Likes
5

Please explain, I am not sure I understand what you are referring to.

I am sorry, I think there was a misunderstanding. I am proposing an additional official app, which would be maintained alongside the F-Droid and F-Droid Basic clients, for people that are unable to use these clients. This could only lead to more people using it, not less?

Sorry if you feel there was an error in my post, I would not want to spread misconceptions. What would you suggest to improve it, remove the word “modern” in the description of F-Droid Basic?

I did not understand this article and fail to see a link with a proposal for a new F-Droid client with a reduced feature set. Could you please explain?

I agree, and that’s the reason I am making this proposal :slightly_smiling_face:

2 Likes
6

We often see people asking about why 2 official clients. If it’s not confusing enough lets create one more official client for security minded users…:man_shrugging:t6:

I believe your proposed amendments are better for certain users who share this threat model. Therefore it should be maintained as fork/third-party F-Droid client.
As I said it’ll make things more confusing for general users e.g. Point 2. Why forked “security” specific F-Droid client has AntiFeature? We know why but reality is most users don’t go through documentations.
Point 3. AppManager installer has this feature already. It shows APK signature before the installation, no need to share the app.

You shouldn’t share your phone with whom you don’t trust in the 1st place. There are much bigger threats to consider than they installing just some app from unknown repositories.

4 Likes
7

That’s a fair point.

I didn’t know about this app, thanks a lot!

4 Likes
8

Couldn’t this be solved by an Anti-Feature “Allow non-reproducible builds”?

3 Likes
9

Actually @Licaon_Kter CMIIW I think you won’t get “Tethered” AF for your hypothetical security-focused F-Droid client even if that doesn’t support other repositories.

Official F-Droid repo mirrors/instances are self-hostable. The user can choose whatever address they prefer to use from the client. e.g. Droid-ify use https://f-droid.org address by default only.

Allow only reproducible builds is the main theme of this hypothetical FD client. Changing your vision means you really don’t believe in it.
IMO this whole discussion is about solving a problem that doesn’t exist.

Rather an important discussion would be “How can the official client demonstrate which versions are reproducible?” Currently there is no way to distinguish between FD signed builds vs reproducible builds.

2 Likes
10

This is correct and I do agree. I was mainly speaking from the perspective of the android app store trust model as that’s the only hypothetical scenario that I could see this being a potential issue.

In general this was one of the things I never understood why this was considered a big issue with F-Droid. I didn’t (and still don’t) understand how following this specific trust model would improve security in any big and significant way.

I sure don’t. Any potential security issues that are actually very problematic should just be able to be fixed in the official client and should not require a hardened client. However I do still have a belief that hardening is good if there are good and valid reasons to do so. Which the ones here are not really sufficient enough for me to say so.

Agreed.

2 Likes
11

Thanks for your answers, these are very good points.

I think we can all agree that in the spirit of free and open-source software, the main F-Droid client is and should remain as inclusive as possible. Enforcing reproducible builds and pinning the official repository would make it less inclusive and therefore should only be done in a separate client.

Whether something is secure is a very personal question in my opinion. We might be exposed to (or care about) different threats, so what is secure for me might be insecure for you, and vice versa. No matter whether this hypothetical client would be useful for me, I believe there are many people who would find it very useful, because they personally prefer to follow the Android OS security model and therefore cannot install the main F-Droid clients.

This is true, and there is already some discussion about this on GitLab:

3 Likes
12

The article is IzzyOnDroid repo specific.
The main takeaway is 3rd party clients trying to improve by adding reproducible build status, libraries, VirusTotal detection. I hope eventually official F-Droid client will find motivation to improve in these directions as well.

3 Likes
13

F-Droid Basic development was sponsored by divested.dev for (DivestOS)[divestos.org] as a more secure F-Droid client. It did so by reducing the features to the minimum. This therefore reduced the attack surface. I also believe it was the first to use an Android API that allowed unattended updates.

I believe it would be wiser to implement some of your ideas into F-Droid basic, rather than create a new one. However, I disagree with

  1. This would make F-Droid unusable. Maybe a toggle in the settings ?
  2. This directly contradicts with your dev signature (reproducible builds) proposal. When you install a developer repo (eg NewPipe, FUTO), you now get packages directly signed by the devs.*
  3. I agree this would be nice to have. However, we should be clear that many apps don’t have their signature in the database (including FUTO apps). The problem I have with AppVerifier, is that since many apps aren’t in the database, I end up installing anyway.**

*But the disadvantage ofc, is that you have no certitude that the APKs are actually based on the GitHub code…
** I now used F-Droid exclusively, but I used Obtainium for months.

1 Like
14

@SkewedZeppelin you did?

15

Sorry, I got it wrong it was Calyx. And not sure they specifically sponsored F-Droid Basic.

1 Like
16

It started with Basic, but it’s ongoing in all directions, client wise :slight_smile:

1 Like
17

Thank you for your detailed reply. I didn’t know about the story behind F-Droid Basic.

The only difference in usability would be the number of apps available. I agree with you that this would make F-Droid unusable for many people, and that’s why I am proposing to create a separate client.

A toggle in the settings would be a welcome addition to the current F-Droid clients. I guess it will be possible to add this feature when the F-Droid server starts tagging reproducible builds.

That said, the entire reason for this proposal is to provide an alternative official F-Droid client that fully respects the security model of the Android OS. Unfortunately, if an app store would allow installing apps signed by F-Droid instead of their developer, it would break the first assumption of the Android security model:

Trust in the app author, materialized as a cryptographic signature in the APK.

Regarding your second comment:

An external repo would indeed allow installing apps that are signed by their developer, which is the same consequence as reproducible builds. However, as you pointed out, this removes any trust in F-Droid to verify that these apps are reproducible and safe. This breaks the second assumption of the Android OS security model:

Trust in the app store, materialized as a specific permission that needs to be granted to each app store.

As I am understanding it, the only way for an app store to fully respect the security model of the Android OS is to completely not offer these two features (apps with non-dev signatures, and apps from external sources).

I agree with you that it would already be very nice if these features could be turned off in the main clients, but I believe these clients would still be incompatible with many people’s threat models, and these people would be very happy to have the possibility to use an alternative official F-Droid client that doesn’t have these two features at all.

Completely agree with you here. I think the author of AppVerifier is also not satisfied with the database situation, and is considering to remove it from the app altogether. It would be nice for people to have the ability to save and import their own signature database in the app, in order to avoid having to look for an app’s signature again if they already have done so. There is at least one feature request that goes in this direction on their bug tracker.

1 Like
18

Unfortunately I can no longer edit my first post, but another welcome addition to a security-focused F-Droid client would be:

  1. Only list and install apps that target a recent API level in order to benefit from security improvements brought in the latest versions of the Android OS.

Note: The target API level is not the same as the minimum API level and apps targeting a recent API level cant still be installed on old devices.

1 Like