Live data from Hacker News

F-Droid: how it weakens Android's security model

wonderfall.dev

61–69 of 69 posts

Re: F-Droid: how it weakens Android's security model

#61

Earlier quoted context omitted.

The main problem with downloading APKs from the GitHub releases page, is that it doesn't come with a low-friction way of distributing updates. This is especially important for unofficial client apps like NewPipe, which basically become bricked at a moment's notice, and updating within a day or two is important to maintain continuity of service. Not to mention that an app may be hosted on a different platform, perhaps…

Funny you should mention NewPipe since they discourage users from relying on the official F-Droid repo for the very reason of slow updates, which you don't want for an app relying on parsing web pages that are likely to change. The app itself (at least the regular build provided by the developers) sends you a notification once a new update is available. They also maintain a third-party repository, which again is fine…

I actually use direct APK downloads for myself, and F-Droid for my mother, who is far less technical and therefore benefits from the easier end-to-end UX for the update process. Even with delayed updates, having NewPipe unavailable for two or three days is preferable to using the official YouTube app in the Play Store, which doesn't have the features she relies on at all, or a direct APK download that may expose her to the risk of malware.

That said, I should really set her up with a third party repository for updates.

Re: F-Droid: how it weakens Android's security model

#62
post #53

Earlier quoted context omitted.

FYI your comment was marked [dead], I vouched for it because I think it contributes to the conversation. Update: I think you must have been caught in some automatic system because every comment (including your account's first) was already marked [dead] but not [flagged]. This does not seem to have been users flagging you or anything, maybe you use an IP previously used by a troll or so? Or a keyword detector in the f…

Thanks for the heads-up! It's also a new account since I've never posted on HN before, so maybe that's why. (Also I would like to correct myself on my previous comment: I meant "GPG" as the reference implementation of the OpenPGP standard, not "OpenGPG". I was very tired.) > I understand there's much more to it than just that, it just read funnily to me. (Not meant as laughing 'at' you! Hope it didn't come across lik…

Just an offtopic procedural note (I'm a mod here) - some of your comments were indeed getting caught in software filters, plus you were being rate limited (these are restrictions on new accounts because of past abuses by spammers and trolls). I've marked your account legit now so those things shouldn't happen again.

Re: F-Droid: how it weakens Android's security model

#63
post #52

Earlier quoted context omitted.

Ah yes, but this requires adding one repo per app. I meant having a "single" (though selfhostable) Fdroid gateway to CI artifacts so i could just add "cidroid.org" repository to my Fdroid then choose for each application if i want it from F-droid repo or from fresher CIDroid.

It's pretty much the same as PPAs on Ubuntu. For what you're asking for, IzzyDroid's repo may be the closest to what you're asking for.

Thanks i was not aware of this! It's almost exactly what i was looking for, although admittedly i wanted something more automated (along the lines of here's an RSS feed of releases, use this xpath query to extract the download URLs for various architectures).

Re: F-Droid: how it weakens Android's security model

#64
post #28
post #7

Not to discredit the article, but it would be nice to know from the get-go that it's written by a contributor to GrapheneOS and gives a plug to their upcoming App Repository at the end.

I was already under the impression that the GrapheneOS developer(s) were overworked, but still they insist in doing everything themselves because no other project is good enough I have been using for the past year, and the 'advanced' user experience is not great. Updates are forced to the latest version of android, does not seem safe, and definitely does not feel stable, less customization than other roms, a bit aggr…

> they insist in doing everything themselves because no other project is good enough

They are making an alternative store with better security and privacy properties than both Google Play and F-Droid. Why is this problematic?

> Updates are forced to the latest version of Android

On Pixels (the only devices GrapheneOS supports at the moment), only the latest version of Android receives security updates, so GrapheneOS must stay on the latest version to meet a baseline level of security. Each Android release also comes with security and privacy improvements along with further restrictions to the app sandbox.

> does not seem safe

How is GrapheneOS not safe?

> does not feel stable?

In what way?

> less customization than other ROMs

Yes, because GrapheneOS is not focused on customizability. This will be improved in Android 12L.

> a bit aggressive towards root

Root fundamentally cripples the Android security model, so being a security-focused project, this is the proper stance to take.

Honestly I'm not sure why you're complaining about GrapheneOS in this thread. The article is written about F-Droid by someone who is not a GrapheneOS developer. They pointed out F-Droid's issues and mentioned upcoming alternatives without these issues. I don't see how one of those alternatives is an "exercise in craziness," nor how GrapheneOS itself is relevant to the article.

Re: F-Droid: how it weakens Android's security model

#65
post #55

Earlier quoted context omitted.

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…

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

Re: F-Droid: how it weakens Android's security model

#66
post #47

Earlier quoted context omitted.

Raising the minimum SDK level might do this. This is separate from the target SDK level.

Raising the target SDK just turns a general computing device into a glorified webbrowser, because you lose access to the filesystem, the ability to run background daemons, and the ability to run compilers. These should be permissions, not disabled wholesale.

Literally the only situation when an app would need access to your filesystem is when the app is a file manager. And file managers can still request access to your file system.

Re: F-Droid: how it weakens Android's security model

#67
post #9

This is some lazy "threat modeling without a threat model" kind of stuff IMHO.

The article is just a list of insecurities of F-Droid. In fact, it even mentions that you can still use F-Droid if it fits your threat model or for ideological reasons.

Re: F-Droid: how it weakens Android's security model

#68
post #47

Earlier quoted context omitted.

Raising the target SDK just turns a general computing device into a glorified webbrowser, because you lose access to the filesystem, the ability to run background daemons, and the ability to run compilers. These should be permissions, not disabled wholesale.

Literally the only situation when an app would need access to your filesystem is when the app is a file manager. And file managers can still request access to your file system.

Not at all. If you want to support e.g. playlists you need to be able to load video files while the storage framework only gives you access to the playlist file.

Or when you want to store and load ROMs from a folder.

Or in general every time you want to automatically load files that should also be accessible to other apps.

Re: F-Droid: how it weakens Android's security model

#69
post #68

Earlier quoted context omitted.

Literally the only situation when an app would need access to your filesystem is when the app is a file manager. And file managers can still request access to your file system.

Not at all. If you want to support e.g. playlists you need to be able to load video files while the storage framework only gives you access to the playlist file. Or when you want to store and load ROMs from a folder. Or in general every time you want to automatically load files that should also be accessible to other apps.

Unsure why you think the storage access framework doesn't let you grant access to a directory. You can literally try it on a relatively modern app such as Lemuroid: the system file picker lets you grant access to your ROMs folder.

Whole access to the shared storage is deprecated by SAF and scoped storage. That doesn't mean there is no way to achieve the same productivity tasks you could achieve before: it's just that now you're granting explicit fine-grained access to the files and folders your app needs.

MANAGE_EXTERNAL_STORAGE still exists and is now reserved for apps that can justify their file management purpose. Since this is a highly privacy-invasive permission, Play Store requires a review for these kinds of apps.

Post reply on HN