| ▲ | IshKebab 14 hours ago |
| "F-Droid is not hosted in a data centre with proper procedures, access controls, and people whose jobs are on the line. Instead it's in some guy's bedroom." Not reassuring. |
|
| ▲ | PaulKeeble 14 hours ago | parent | next [-] |
| It could just be a colo, there are still plenty of data centres around the globe that will sell you a space in a shared rack with a certain power density per U of space. The list of people who can access that shared locked rack is likely a known quantity with most such organisations and I know in the past we had some details of the people who were responsible for it |
|
| ▲ | TomatoCo 14 hours ago | parent | prev | next [-] |
| In some respects, having your entire reputation on the line matters just as much. And sure, someone might have a server cage in their residence, or maybe they run their own small business and it's there. But the vagueness is troubling, I agree. A picture of the "living conditions" for the server would go a long way. |
|
| ▲ | a3w 13 hours ago | parent | prev | next [-] |
| Depends on the thread model, which one is worse. State actor? Gets into data centre, or has to break into a privately owned apartment. Criminal/3rd party state intelligence service? Could get into both, at a risk or with blackmail, threats, or violence. Dumb accidents? Well, all buildings can burn or have an power outage. |
| |
| ▲ | Aurornis 13 hours ago | parent [-] | | > State actor? Gets into data centre, or has to break into a privately owned apartment. I don’t think a state actor would actually break in to either in this case, but if they did then breaking into the private apartment would be a dream come true. Breaking into a data center requires coordination and ensuring a lot of people with access and visibility stay quiet. Breaking into someone’s apartment means waiting until they’re away from the premises for a while and then going in. Getting a warrant for a private residence also would likely give them access to all electronic devices there as no 3rd party is keeping billing records of which hardware is used for the service. > Dumb accidents? Well, all buildings can burn or have an power outage. Data centers are built with redundant network connectivity, backup power, and fire suppression. Accidents can happen at both, but that’s not the question. The question is their relative frequency, which is where the data center is far superior. | | |
| ▲ | u8080 an hour ago | parent | next [-] | | >I don’t think a state actor would actually break in to either in this case Read Jabber.ru Hetzner accident: https://notes.valdikss.org.ru/jabber.ru-mitm/ | |
| ▲ | pbhjpbhj 10 hours ago | parent | prev | next [-] | | >Breaking into a data center requires coordination and ensuring a lot of people with access and visibility stay quiet Or just a warrant and a phone call to set up remote access? In the UK under RIPA you might not even need a warrant. In USA you can probably bribe someone to get a National Security Letter issued. Depending on the sympathies of the hosting company's management you might be able to get access with promises. I dare say F-Droid trust their friends/colleagues more than they trust randos at a hosting company. As an F-Droid user, I think I might too? It's a tough call. | |
| ▲ | Calzifer 11 hours ago | parent | prev | next [-] | | > Data centers are built with redundant network connectivity, backup power, and fire suppression. [...] The question is their relative frequency, which is where the data center is far superior. Well, I remember one incident were a 'professional' data center burned down including the backups. https://en.wikipedia.org/wiki/OVHcloud#Incidents I know no such incident for some basement hosting. Doesn't mean much. I'm just a bit surprised so many people are worried because of the server location and no one had mentioned yet the quite outstanding OVH incident. | | |
| ▲ | arjie 5 hours ago | parent | next [-] | | I'm not going to pretend datacenters are magical places immune to damage. I worked at a company where the 630 Third Street datacenter couldn't keep temperatures stable during a San Francisco heatwave and the Okex crypto exchange has experienced downtime because the Alibaba Zone C datacenter their matching engine is on experienced A/C failure. So it's not all magic, but if you didn't encounter home-lab failure it's because you did not sample the population appropriately. https://www.reddit.com/r/homelab/comments/wvqxs7/my_homelab_... I don't have a bone to pick here. If F-Droid wants to free-ball it I think that's fine. You can usually run things for max cheap by just sticking them on a residential Google Fiber line in one of the cheap power states and then just making sure your software can quickly be deployed elsewhere in times of outage. It's not a huge deal unless you need always-on. But the arguments being made here are not correct. | |
| ▲ | Bridged7756 4 hours ago | parent | prev [-] | | Surely "Juan's home server in basement burns down" would make the headlines. You're totally right. |
| |
| ▲ | tcfhgj 12 hours ago | parent | prev [-] | | > The question is their relative frequency, which is where the data center is far superior. as a year long f-droid user I can't complain |
|
|
|
| ▲ | pwndByDeath 13 hours ago | parent | prev | next [-] |
| I think there are countless examples of worse failures by organisations that meet your criteria for far more valuable assets than some free apps. |
|
| ▲ | ugh123 14 hours ago | parent | prev | next [-] |
| The 'cloud' has come full circle |
|
| ▲ | gpm 14 hours ago | parent | prev [-] |
| 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. |
|