F-Droid: how it weakens Android's security model

Funny you should mention NewPipe since they discourage users from relying on the official F-Droid repo for the very reason of slow updates, which you don't want for an app relying on parsing web pages that are likely to change. The app itself (at least the regular build provided by the developers) sends you a notification once a new update is available. They also maintain a third-party repository, which again is fine at mitigating some issues of the official repository (while breaking the security model because the OS inherently wants one source per app repository, but at least it's more usable than waiting for the F-Droid build to be updated).

F-Droid can't do anything against "secret code" since they don't/can't analyze the whole codebase. Like said multiple times, they only run a few scripts on the available source code to remove known trackers, which is known to be a poor approach to privacy.

FYI your comment was marked [dead], I vouched for it because I think it contributes to the conversation.

Update: I think you must have been caught in some automatic system because every comment (including your account's first) was already marked [dead] but not [flagged]. This does not seem to have been users flagging you or anything, maybe you use an IP previously used by a troll or so? Or a keyword detector in the first comment set it off (e.g. since the words "You're wrong," might trigger he-said, she-said conversation when taken by itself) maybe? Idk. /update.

> This is a bit exaggerated.

Yes, I was mostly joking in that cited part, that's why I added "(jk)" :). I understand there's much more to it than just that, it just read funnily to me. (Not meant as laughing 'at' you! Hope it didn't come across like that.)

> once you ensured the authenticity, the source doesn't matter as much.

Yes, but that's TOFU. Secure in most cases, but if it's used all the time, an attacker will catch today's lucky ten thousand (xkcd.com/1053) who first download a certain app or who just (re)installed their phone.

Hence my suggestion of something like PGP, where the authenticity can be established more reliably than having everyone hope it wasn't compromised on first download. (It's a good alarm mechanism though, if suddenly everyone else's update fails, so any compromise of app signing keys wouldn't be long-lived. But I do feel like the article argues for a much higher security standard than TOFU.)

Alternatively with f-droid, the CA system is used, and TOFU doesn't go away. If the CA system is compromised, there are still the app signing keys. Conversely, if the signing keys are compromised, the attacker also still needs to compromise the distribution channel or server.

>all they do is running their own scripts to scrap known trackers and the like

Which Google Play does not, happily serving you all the "known trackers". F-Droid is strictly superior on this front.

> You still have to trust the app developer

I don't have to trust the developer as much because I don't have to take their word for it that the compiled app matches the public source.

> and you'd be much better off trusting the strong guarantees provided by the Android app sandbox anyway

False dichotomy. I still have the sandbox with F-Droid. This is chaff.

> Play App Signing is mentioned in the article.

...Okay? What a non-sequitur. Signing is completely off-topic to the fact that Play Services is spyware (notwithstanding your assertion that it isn't). Unlike F-Droid. That's a huge difference.

It's like saying "when meeting a sketchy stranger, don't bring a friend along or meet in a public place because now you have to trust the friend as well, and also the friend might not be strong enough to overpower the stranger anyway. Safer to take an Uber to their house and lock the door behind you."

> False dichotomy. I still have the sandbox with F-Droid. This is chaff.

I didn't imply that you wouldn't benefit from the app sandbox by using F-Droid. I meant that the practical approach to privacy should come from relying on the permission model instead of trusting third parties.

In that sense, F-Droid adds very little to the fact that you still have to trust the upstream code with the permissions you're willing to grant.

If you choose to trust F-Droid, that's perfectly fine and I'm not trying to convince anyone to stop doing that. I also won't comment on your statements that Play Store is spyware because I have very little interest in that topic. You're free to believe that, and I respectfully disagree given the great service (whilst not perfect by any means) offered by Play Store.

Well, surely there are biases in some ways, including some I may not even be conscious of. That being said, I try to follow a fact-based approach: yes, the conclusion is biased in the sense that it was written in a personal context (again, this article wasn't meant to be shared on several platforms like HN), but I can assure you the rest of the article follows this fact-based approach as much as possible. I even mention build reproducibility and Play App Signing: both mentions could be seen in favor of F-Droid (yet the reality is more nuanced than that).

I'm perfectly aware of the FOSS culture and why some want to use F-Droid to promote this. This is just not what I had in mind when writing the article. I simply intended to address some flaws or deliberate choices from F-Droid that I think are in opposition to the practical approach to modern privacy/security. It happens that I think GrapheneOS and modern Android in general follow that approach. Last month, a reddit troll tried to portrait me as a GrapheneOS developer (when I'm an occasional contributor) and used the article to explain how GrapheneOS would be "anti-FOSS". That is so wrong. GrapheneOS is FOSS at its core, and I personally value FOSS solutions. Not sure how someone would extrapolate the opposite from my article.

Knowing that, I then stumbled upon this thread and noticed people digging up random contributions in my GitHub account instead of reacting to the content. Contributing to an alternative project doesn't mean bias or endorsement. Contributing doesn't necessarily mean code, GitHub issues, or money. You could even see this article as a contribution to F-Droid in some ways (but I'm sure they're aware of the majority of the underlined issues, and I don't have the pretention to do better than them). Then again, I deeply think GrapheneOS and Accrescent are paving the way for modern FOSS solutions.