eighthave

> the APK on the website is signed by a different key from the one that F-Droid updates itself with

Could you explain? I don't understand what you mean here. https://f-droid.org/F-Droid.apk is signed by the same key that signs https://f-droid.org/repo/entry.jar

When Google added the "session" installer to AOSP, we thought it would replace F-Droid Privileged Extension (FPE). So we stopped development on it. The answer now is that the "session" installer mostly replaces FPE, but not fully. So we're exploring reviving development: https://gitlab.com/fdroid/privileged-extension/-/work_items/...

F-Droid and F-Droid Basic are the same code base, even more so with 2.0. So the automatic updating support is the same for both.

If you like the Obtanium user experience, I recommend you get involved and help them implement signature verification on F-Droid repos: https://github.com/ImranR98/Obtainium/issues/3348

I think it is great that there are multiple clients out there, so people have a choice of user experience. One thing that I think is too often overlooked look is if they have implemented the same security and privacy standards as F-Droid, if that's important to you. For example, last I checked, the third party clients where still using index-v1, which is signed using SHA1. Maybe NeoStore updated to index-v2? And there is also quite a bit of effort put into the client-side to make sure it leaks as little as possible to the servers. There are libraries of the official core pieces for third party clients to use to gain many of these protections: https://f-droid.org/2023/05/02/three-client-libraries.html

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.

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.