eighthave

Lots of projects with good security track records host key servers in a "member's house". That said, the F-Droid buildserver is not hosted in anyone's house.

There are two key concepts at play here: "least authority" and "infrastructure as code". The buildserver host is sensitive security-wise, but easy to set up an instance. We have multiple instances running, and spin up new ones from time to time. For production infrastructure, there should only be enough people with access to it as are needed to maintain it. No more. If a sysadmin goes rogue, we can always just spin up a new instance elsewhere with a new maintainer.

The limiting factor for upgrading our buildserver is finding a trusted, skilled sysadmin to physically install, setup and maintain new hardware at the high level of security that is needed for a release buildserver for a project like F-Droid. It also needs to be in a trusted physical location. Hetzner is definitely not that.

F-Droid is working to figure out how to manage secure backups in a way that is controlled by a free software community and is as secure and usable as possible.

I hope that this precedent applies to any and all countries waging illegal wars. This definitely should apply to US/UK/etc regarding the Iraq War.

Interesting points, I agree the Updates tab could do better there. Update All is implemented if you have F-Droid Privileged Extension installed, it could also be implemented when it is directly installed, if someone wants to contribute there.

We welcome contributions to support APK diffs, it would make a big impact: https://gitlab.com/fdroid/fdroidclient/-/issues/450

JSON is the file format, it is then parsed and stored in the local SQLite

Hey @pserwylo, great to hear from you, and I especially appreciate your message here with the background. And I'd like to highlight your point that there is much less contributor time than people imagine. If anything, the F-Droid client UX design process back in 2016 has proven to be an immensely efficient exercise it putting together a UX that still works decently. Plus we managed to predict that bottom nav would rise in popularity and those sliding sidebars, which were recommended back in 2016, would fade.

You're of course welcome to contribute again! The hard part is that app stores are large and complicated apps, when done fully, so that makes it hard to contribute to. We do mark issues with "first-timer" https://gitlab.com/fdroid/fdroidclient/-/issues/?label_name%... and "help-wanted" https://gitlab.com/fdroid/fdroidclient/-/issues/?label_name%... if anyone is looking for a place to jump in. I think we can also see this in all the various other clients like G-Droid, M-Droid, Foxy, Droid-ify, NeoStore, etc. Many rapidly stop being maintained, and others leave out key functionality like localization and automatic mirror selection because it is a lot of work to implement. The new libraries should make it a lot easier for forks to implement these features.

This is a full revamp of a bunch of the key guts of the app. We hope that other F-Droid-compatible clients like Classic, Foxy, NeoStore, droid-ify, etc. can benefit from this revamp as well: we've split out this core functionality into libraries. This should fix lots of stability issues. I think it is also important to point out that the official F-Droid client is stable for the core contributors, and that's mostly because a) we are the devs and we fix the bugs we encounter, and b) we report the bugs we can't fix.

I think most F-Droid contributors are using Google-free devices these days, so that's where it works best, especially when built into the ROM like CalyxOS, Lineage-for-microG, etc. Unfortunately, that means we pay less attention to how things run on Google devices. So if you're running F-Droid on a Google device, please be sure to report issues so we are aware of them!

I disagree that the main question is: "do multiple stores benefit the user?". The main question is: "Should the user have the choice in their stores?". Apple believes that their users should not have that choice, and Google used that to drive adoption with Android by making it more open. AS Google gained the market share and power, they locked down Android more and more to gain those monopoly-level profits. Based on data that was released as part of Oracle v. Google, it looks like they have over 40% profit margins. Plus notice how Google just cut their fee in half (30% to 15%). That means they were rolling in cash.

How people access apps is not a on/off switch between walled garden and dog eat dog free for all. Decentralized systems need to be designed with safety in mind, just like walled gardens do. Both can be done badly or done well.

With free software and reproducible builds, it is possible for small scale curators to inherit the security of the large scale curators. That is why they are key pieces of the f-droid.org collection.

I agree with basically all the points in this thread, one thing that is missing is that most of these points are not mutually exclusive. A decentralized system like F-Droid does not close out the possibility of walled gardens, it just gives users choice of whether they want to remain in it. For example, you can buy a CalyxOS device now and only enable F-Droid as the app source. That is a walled garden of the safest kind: all free software reviewed by bots and humans before inclusion. Users then can opt into other sources.

We have recently implemented some rudimentary controls where you can use Device Admin mode to lock F-Droid to a given set of repositories. That strictly enforces the walled garden, but doesn't require a single monopolist have all the power.

It is true that many essential organizations cannot effectively defend their networks. But it is also important to point out that there are many orgs that _are_ effectively defending their networks. I've worked in IT in a huge range of companies, orgs, and context. One thing that is clear is the culture plays a huge role. Those with a culture of supporting people who deal with real problems fare much better, those with a culture of "Cover Your Ass" or "When you say jump, I say how high" are getting hacked left and right.

With free software and decentralized repositories, users in each country can decide which software they want to distribute and how. If someone thinks a local ban is unjust, they know they have the right and the tools to redistribute any app that is in f-droid.org, or other free software repositories. Free software is central to an effective decentralized ecosystem.

https://apt.izzysoft.de/fdroid/index/

If you're interested in learning more about what F-Droid offers, I can recommend some more blog posts:

* https://f-droid.org/2022/09/30/free-software-and-inspection-... * https://f-droid.org/2022/02/28/no-user-accounts-by-design.ht... * https://f-droid.org/2020/01/16/tracking-the-trackers.html * https://f-droid.org/2019/05/05/trust-privacy-and-free-softwa... * https://f-droid.org/2019/04/15/privacy-preserving-analytics....

GNOME Software is an app: https://apps.gnome.org/app/org.gnome.Software/

It is not about scale as much as the possibility of getting apps from multiple sources. Each source can set its own curation policies, and each user can choose the sources they want. And for things that people want to keep out of their life, lots of people don't want NSFW images on their phone, but they want easy access to all the apps they want. What is NSFW in one country could be totally fine in another country (e.g. images of people wearing tank tops or swimsuits).

IEEE is not alone in that, basically all editorials in major publications are backed by PR staff. That's how it works, at least in the US.

That may be true if you are sideloading F-Droid. Our security model focus is based on integrating F-Droid into the ROM, like with CalyxOS. This method is proven to provide better security than Google Play devices, since by default, all apps are open source and reviewed by humans. For example https://f-droid.org/2020/03/04/f-droid-is-a-key-source-for-a...

Jitsi lets you set room passwords, and it is also very easy to create a new Jitsi room, so you can easily send a new URL around as needed.

F-Droid is about user freedom, so there are clients that are more like Linux package managers, for example https://github.com/mvdan/fdroidcl

I was also initially skeptical, but after looking into IPFS, I think the core ideas are real and useful. IPFS is inspired by bittorrent, and addresses some of the issues with bittorrent that keep torrenting a very manual process. Debian did experiments with bittorrent mirrors, they worked poorly. I think IPFS is worth trying since it could actually work.

We're taking a hybrid approach right now, where we incorporate IPFS support into our working stack. Then we can transition more and more to IPFS as it proves mature enough to replace the more centralized methods.

Yes, but f-droid.org actually does let devs use their own keys via the reproducible builds process (https://f-droid.org/docs/Build_Metadata_Reference/#Binaries). The only blocker for getting Signal into f-droid.org is that it includes proprietary Google libs.

If a project maintained reproducible builds, then they can have the best of both worlds: their own repo where they can publish builds as they like, then f-droid.org can later reproduce them and use the upstream developer's signature.

This patch workflow would also work with F-Droid. I don't know of any other workflows for this situation.

If you're not getting icons and screenshots, that most likely because your data/wifi settings are set to not download them. For example, if you never/rarely use WiFi, and your data/wifi settings are set to only allow downloading over WiFi, it won't download the icons or screenshots. Originally, we had same defaults for everyone, then we updated it so that if you started F-Droid without WiFi on, then it would always allow downloads over data.

That said, yes, the official client could be improved, and we welcome contributions. The security side of F-Droid is quite solid, that's the problem with the various forks. They focus on UX, without the careful attention needed for security. The ideal world would be that the core of the official F-Droid client would be a standalone library, so that the forks can have the same solid base. We welcome contributions there.