Response to misinformation about our Sensors permission from F-Droid

FlipSid

Thanks for the link. I had previously uninstalled F-Droid, because of issues mentioned here, but reinstalled because I needed one app I could not get anywhere else.

I'll figure out if I really need this one app.

This type of conduct is not what I expect from developers, especially the ones who spread many Apps that will be used by many people, not just one app.

GrapheneOS
Thanks for the statement 👍🏽

wizoatk

FlipSid but reinstalled because I needed one app I could not get anywhere else.

While not as convenient, it likely can also be fetched and updated with Obtainium. I strongly suspect you could scare up some help if you wanted to try that direction.

xxx

What's about sandboxed f-droid? Would that help? Or maybe more apps in the buld in store?

Xtreix

xxx What's about sandboxed f-droid?

All apps are sandboxed, F-Droid is simply not recommended.

Dumdum

xxx sandboxed f-droid?

If you mean in the same way as "Sandboxed" Google Play, then no, Fdroid is not privileged and so is not in need of the same "sandboxing" (which is of course just the regular Android sandbox that all user apps have by default, as stated by Xtreix).

xxx

Xtreix I know.

Dumdum

I mean some kind of sandboxing for this 'bad' behaving installer. I'm really unsure about this. I never had problems with f-droid but securitywise it is a mess.

cuckflared

GrapheneOS Thanks for your reply.

So, if understand correctly, our most important protections are fine-grained system permissions (like AOSP) that ensure that apps have minimal access to our data. Equally important are additional protections provided by a hardened OS like GrapheneOS e.g. hardened malloc which make exploiting vulnerabilities more difficult. Both open-source and closed-source applications should be confined as much as possible.

My point about reproducible builds is they allow us to be sure that binary we downloaded matches the source code, regardless of the package distributor. Of course this only means that they match, nothing else. It doesn't mean there are no vulnerabilities or back-doors in the code. But if the adversary wants e.g. to slightly weaken client-side encryption in a note-taking application with an online sync and reproducible builds, he has to work in the public repository and make sure that the commits look innocent. This requires more time and increases the chance that some developer "finds out" anyway.

Without reproducible builds I think it's easier for an attacker to make a custom build with slightly modified encryption and get away with it. Doing code analysis on the binary is much more difficult and requires coders versed with assembly or de-compilation. And observing the app at run-time might not reveal anything suspicious.

Without reproducible builds law enforcement can also force distributors to build packages with additional custom code more easily. Especially vulnerable are non-anonymous, lone open-source developers who may not be able to resist existential threats. Bigger distributors like Linux distros can defend with help of their lawyers.

Is my thinking flawed?

de0u

cuckflared Without reproducible builds I think it's easier for an attacker to make a custom build with slightly modified encryption and get away with it.

But "get away with it" would still require tricking victims into installing and running the malware version, which seems like the hard part. If I can trick a victim into installing a bogus version I built, and the app does have reproducible builds, then what? Clearly the victim isn't checking much about the app, and it's highly unlikely that the victim is reproducing builds.

cuckflared Without reproducible builds law enforcement can also force distributors to build packages with additional custom code more easily. Especially vulnerable are non-anonymous, lone open-source developers who may not be able to resist existential threats.

If the threat model is compromised developers, I don't think reproducible builds will add a lot of value, because a compromised developer can be made to insert plausible subtle bugs and then build them reproducibly.

Reproducible builds are useful against corruption of public builds from public source, but only when a third party actually does the labor to reproduce builds. So far that is a mostly hypothetical benefit, right?

Skorp

cuckflared

Reproducible builds don't help with this. Source availability or licensing also don't really help with this.

To explain, auditing an app or service is not reliant on the source code availability or license. In many cases it is not very helpful at all. Auditing can be and is done on many closed source and/or source-unavailable apps and services.

Doing code analysis on the binary is much more difficult and requires coders versed with assembly or de-compilation. And observing the app at run-time might not reveal anything suspicious.

Code analysis of the source code can be equally troublesome as it may not be clear what specific functions do until it is actually compiled, and the actions or connections can be observed. Assuming that because something is FOSS means it is inherently more difficult to hide behaviors or that it benefits from more eyes is flawed logic because in practice we can see many cases of projects that receive little or no review.

Another resource: https://privsec.dev/posts/knowledge/floss-security/

xxx

https://bsky.app/profile/grapheneos.org/post/3lt3ov4a4k22r

I've found the post. ^^
'Due to F-Droid deliberately causing friction and annoyances for GrapheneOS users, we'll be implementing a feature similar to our sandboxed Google Play compatibility layer for it. ...'

https://bsky.app/profile/grapheneos.org/post/3lt3ov4a4k22r

cuckflared

Thanks @de0u and @Skorp for your thoughts. So there aren't many things that we can safely rely upon and no solutions on the horizon.

de0u

cuckflared So there aren't many things that we can safely rely upon and no solutions on the horizon.

Right now there is no magic "security spell" (or "privacy spell") that solves all issues if only one can find out what it is. But then again there is no single medicine that cures all kinds of cancer.

There are steps one can take to improve security and/or privacy, but each of those steps requires time, effort, inconvenience, and/or money. For example, one can refuse to run popular gigantic information-harvesting apps ... but they are popular, so one's friends and family, or one's job, might request or require some of those apps. One might purchase a separate dedicated device for each one of those apps one decides to run, but that's expensive and may be inconvenient.

Edit: there are things on the horizon. Maybe running each Android app inside a Microdroid VM would help. Perhaps the CHERI processor architecture extensions will be shipped in a mainstream phone processor (which would be an upgrade from the research implementation).

« Previous Page