Eh...

The set of people who can maliciously modify it is the people who run f-droid, instead of the cloud provider and the people who run f-droid.

It'd be nice if we didn't have to trust the people who run f-droid, but given we do I see an argument that it's better for them to run the hardware so we only have to trust them and not someone else as well.

▲

lrvick 14 hours ago | parent | next [-]

You actually do not have to trust the people who run f-droid for those apps whose maintainers enroll in reproducible builds and multi-party signing, which only f-droid supports unlike any alternatives.

▲

gpm 13 hours ago | parent | next [-]

That looks cool, which might just be the point of your comment, but I don't think it actually changes the argument here.

You still have to trust the app store to some extent. On first use, you're trusting f-droid to give you the copy of the app with appropriate signatures. Running in someone else's data-center still means you need to trust that data-center plus the people setting up the app store, instead of just the app store. It's just a breach of trust is less consequential since the attacker needs to catch the first install (of apps that even use that technology).

▲

lrvick 13 hours ago | parent [-]

F-droid makes the most sense when shipped as the system appstore, along with pinned CA keychains as Calyxos did. Ideally f-droid was compiled from source and validated by the rom devs.

The F-droid app itself can then verify signatures from both third party developers and first party builds on an f-droid machine.

For all its faults (of which there are many) it is still a leaps and bounds better trust story than say Google Play. Developers can only publish code, and optional signatures, but not binaries.

Combine that with distributed reproducible builds with signed evidence validated by the app and you end up not having to trust anything but the f-droid app itself on your device.

	▲	gpm 10 hours ago \| parent [-]
		None of this mitigates the fact that apriori you don't know if you're being served the same package manifest/packages as everyone else - and as such you don't know how many signatures any given package you are installing should have. Yes, theoretically you can personally rebuild every package and check hashes or whatever, but that's preventative steps that no reasonable threat model assumes you are doing.

▲

imiric 11 hours ago | parent | prev [-]

Why have we normalized "app stores" that build software whose authors likely already provide packages of?

I've been using Obtainium more recently, and the idea is simple: a friendly UI that pulls packages directly from the original source. If I already trust the authors with the source code, then I'm inclined to trust them to provide safe binaries for me to use. Involving a middleman is just asking for trouble.

App stores should only be distributors of binaries uploaded and signed by the original authors. When they're also maintainers, it not only significantly increases their operational burden, but requires an additional layer of trust from users.

▲

ejj28 14 hours ago | parent | prev [-]

The cloud isn't the only other option, they could still own and run their own hardware but do it in a proper colocation datacenter.