Comment by dTal | Hacker News Reader

Comment by dTal | Hacker News Reader

>The issue with F-Droid is that all apps are signed by the same party (F-Droid) which is also not the developer. You’re now adding another party you’ll have to trust since you still have to trust the developer anyway

This is fallacious for several reason.

Firstly, no I do not "have to trust the developer anyway" - I can always not install the app. I'm not starting with an app, adding my trust of the developer, and adding my trust of F-Droid - I am starting with F-Droid, and only installing apps which F-Droid trusts, because F-Droid's criteria for accepting apps are far more stringent than Google Play's - more stringent even than I could feasibly audit myself.

Secondly, trust is not binary. Maybe I trust the developer enough to run their published source code, but not quite enough to run their precompiled binary that they might have slipped some tracking library into. Indeed this is very common and F-Droid strips a lot of such libraries. So even if we take it as a given that I am definitely going to install an app, and my only choice is between installing it from Google Play or from F-Droid, F-Droid is still superior because the builds on F-Droid are built from public source, and I am much more sure that F-Droid themselves won't slip malware into the builds because they have a track record of not doing that.

Thirdly, Android's default app store, Google Play, also trusts a third party by default - Google, who insist on running a tracking rootkit on your computer, which is so much more egregiously invasive than trusting any one app that it renders any comparison with F-Droid moot.

I fail to see how it's fallacious since you're confirming my point.

> I'm not starting with an app, adding my trust of the developer, and adding my trust of F-Droid

You are. You seem to believe they actually read the whole source code when it's not the case: all they do is running their own scripts to scrap known trackers and the like (and again, I must say badness enumeration is a flawed approach), this is far from a stringent process and this would be a very weak approach in any threat model to rely on that.

You still have to trust the app developer, and you'd be much better off trusting the strong guarantees provided by the Android app sandbox anyway. Seems like there's a major disagreement here when it comes to our approach to privacy.

> Thirdly, Android's default app store, Google Play, also trusts a third party by default - Google, who insist on running a tracking rootkit on your computer, which is so much more egregiously invasive than trusting any one app that it renders any comparison with F-Droid moot.

Play App Signing is mentioned in the article.

>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.

The "tracker checking" is useless because it just checks for a small list of libraries in the app. If an app has no tracker libraries, this doesn't mean that they do not track you. So it gives you a false sense of security.

Doesn't google do exactly the same thing with the app store anyway?

As of August 2021, new apps must use Android App Bundles. Older apps can still be distributed without providing the key to Google.

[0] https://developer.android.com/guide/app-bundle

[1] https://developer.android.com/guide/app-bundle/faq#app-signi...

Yes, last I checked, Google signs the app with your private key, which they force you to give them. In other words, they have the ability to make any changes to your app and re-sign it at their whim. Anyone concerned about the security of their shit should only install apps directly signed directly by the developer, using a private key only the developer possesses.

It's a shame these platforms go to such great lengths to force distribution through their "safe" channels.

Playing devil's advocate, given the choice between trusting a random developer to keep their keys private or Google to keep their keys private, I'd probably side with Google.

Yeah that doesn't help with coercion or government letters, but neither would being a solo dev, both parties will comply.

I don't think the concern is with Google keeping the keys secure. I think the concern is with Google being able to rewrite the app however they want and sign it without the developer even knowing.

Except the developers can still have access to the key, they just have to share it with Google. This not only violates the old advice: "Never share your private key!", it also gives you the worst of both worlds: You have to trust both the random developer and Google to keep the keys private.

What Google does with their keys is known only to Google. Google also have various commercial pressures which can compromise their behaviour (on that note, have we even managed to stop Certificate Authorities selling carte-blanche certificates to middleware-box vendors yet?)

A team-maintained package repository on the other hand operates through transparency.

Reply on news.ycombinator.com