F-Droid follows a similar model to traditional linux package managers which has shown time anda gain the they are both trustworthy and secure (or at least, they offer the user the freedom to choose the level of trust they have in the package signers).
When installing from a Debian repo, I'm typically installing a package that is not build/signed by the upstream developer. I am implicitly (in the case of a default install) trusting the Debian developers signing practices or explicitly (if you add a third party repo). This means you trust both those in charge of the building/packaging/signing as well as the upstream developers. The same is true of F-Droid.
Of course, the notable exception is that F-Droid also supports upstream packages signed by the developer if the builds are verifiably reproducible.
People using F-Droid might not be aware that they are trusting a third party as they think it is a trusted distribution channel, relying on the information stated on the client app or website.
What? A smart phone is just a computer—they are the same thing. Everything from private chats to TOTP tokens are on both my phone and my laptop. The only difference is my bank cries if I’m rooted on my phone and says nothing about it on my laptop.
You'll very likely have much more personal data (personal emails, tax returns, banking data, etc) on your PC than on a phone that's just got a few social media apps on it.
Windows is still a joke security wise but MacOS at least has some mediocre sandboxing nor offering defense suitable for casual visual media focused end users though you need Brew to do anything useful as a developer which throws supply chain security out the window. Personally though no one could ever pay me enough to MacOS even if they did have a useful secure package manager and good sandboxing as I value freedom and privacy in addition to security.
AOSP on the other hand substantial hardening and sandboxing isolating apps from each other somewhat like running every app in a docker container. Combine this with the admittedly small collection of dual signed reproducibly built apps on F-Droid and this is as good as it gets in open source end user friendly secure computing.
Well... almost. Trouble is you can not find an Android device hat does not ship with nasty highly privileged spyware and proprietary kernel modules allowing cell carriers, chipset makers, and the governments they obey to track you and have varying levels of access to your device if they really want it.
IMO QubesOS is the only halfway decent general purpose OS in terms of security and privacy you can use today and in the end there is just no good mobile solution that meets my privacy, security, and freedom needs so I just opt to not have a phone at all for now.
That "trivial" access would have to be an actual exploit. The software in a typical Linux system is not actively attacking the user as the proprietary software in a typical smartphone is. The need for sandboxing is much less.
Last I heard Android mostly depended on the Unix security model as implemented by Linux for isolation where each program was run as a separate user. The same sort of local privilege escalation exploits would work on Android as well. Things like Docker containers are susceptible to those sorts of exploits as well. You need actual virtualisation to have any sort of defence against that sort of exploit. That what Qubes does.
On the other hand, there are two big security advances prevalent on mobile but rare on Linux and other desktop operating systems:
- capability-based sandboxing (ie. enforced app permissions)
- device integrity attestation (ie. the system can tell if you've modified your device in non-standard ways)
Linux does actually have nascent and partial efforts on both fronts (eg. Flatpak, Snap, Secure Boot support) but even then they're usually not popular or easy to use.
That lock does not delete the secret key material from the phone. That is how things like the Cellebrite forensics box can still crack phones. An encrypted desktop stores the secret key material in the user's head. Such a system is for all practical purposes unbreakable when it is shut off. The security comes from usage. It is impossible to create a system that is easily available to a user that is not also somewhat available to an attacker.
An open source program maintained in the open by the users of that program is going to be safer than a hostile proprietary program kept in the sandbox of Flatpak, Snap or whatever.
Encryption on Android devices has changed over the last few years, introducing the possibility for File Based Encryption FBE, later making in mandatory. File based encryption enables apps to use keys to encrypt their data that are flushed when the screen is locked. Many security concerned apps like password managers and OTP apps make use of this.
If you feel the need you can use 'multiple users' to create an extra user or use a work profile (Island, Shelter, Insular) to keep sensitive apps and data. These have seperate encryption keys that are flushed upon switching off the work profile or restarting the phone (for multi user). You can still use the main user on the phone with the work profile/multi user encryption keys not held in memory.
> An open source program maintained in the open by the users of that program is going to be safer than a hostile proprietary program kept in the sandbox of Flatpak, Snap or whatever.
The number of users who have the motivation (let alone skill) to maintain their programs is approximately zero. This is how you get vulnerabilities like the log4j ones that have almost unlimited exposure to the whole machine. This is how you get malware from npm packages. OSS works as long as lots of people are constantly paying close attention, but that's a tall order for the majority of OSS. "Just use a massive OSS project" isn't even feasible in many real use cases. So no, I don't think it's safer.
Any iOS device that has not been registered with Apple for use on a dev team or rooted can run only built-in apps and ones instslled from the iOS Store.
That means it can only run apps explicitly approved by Apple.
Sure, Safari has had some zero days, as has iOS generally, but as Heartbleed, Shellshock, and Log4Shell have shown, open source is not magical fairy dust that makes things secure.
Overall, my bet's on the team at Apple being better at securing their systems than the random collection of individuals and overworked maintainers that have assembled the parts in a modern Linux desktop.
Can't you run any app you want if you install it through XCode for up to 7 days, even without registering as developer?
I thought that's how several of the unofficial iOS AppStores for apps that break the rules of the regular sandbox work
I've been maintaining an iOS app generation framework at $DAYJOB, and I've never found a way to run Xcode builds on physical devices short of actually registering the device with Apple for that purpose.
If there's a way to work around it, I'd be shocked and delighted.
Quoting their FAQ:
Why do you need my Apple ID?
Apple allows anyone with an Apple ID to install apps they’ve built themselves onto their devices for testing. AltStore uses your Apple ID to communicate with Apple's servers on your behalf and perform the necessary steps to prepare your account for installing apps onto your device.
Why does it say my apps will expire in 7 days?
Unfortunately, apps that have been installed using non-developer Apple IDs (in other words, Apple IDs not tied to a $99/year Apple developer account) are only valid for 7 days, at which point they will no longer open. To compensate for this, AltStore will periodically attempt to refresh your apps in the background, and you can always manually refresh your apps from within AltStore.
Thanks!
>Heartbleed, Shellshock, and Log4Shell ...
... are all irrelevant to desktop Linux...
(btw Heartbleed affected Linux desktop OSes such as Debian, Mint, Ubuntu, RHEL, etc.)
Linux is also the worst of desktop operating systems.
Here's the exact text of the warning:
> Your phone and personal data are more vulnerable to attack by unknown apps. By installing apps from this source, you agree that you are responsible for any damage to your phone or loss of data that may result from their use.
The only things I can find about app stores in the paper by Google[0] run directly counter to your idea:
> Android explicitly supports installation of apps from arbitrary sources, which led to the development of different app stores and the existence of apps outside of Google Play.
And this:
> Both users and developers are part of an open ecosystem that is not limited to a single application store. Central vetting of developers or registration of users is not required.
And as far as signing goes:
> In order to ensure that it is the app developer and not another party that is consenting, applications are signed by the developer. This prevents third parties — including the app store — from replacing or removing code or resources in order to change the app’s intended behavior
However, for the security model to be respected, each app repository should represent a single source. The device and user management APIs expect that in Android. F-Droid fundamentally bypasses the trust boundaries in that regard by allowing multiple repositories to coexist within a single client.
Not to mention it also results in a terrible UX given that the application IDs are often reused but signed by another party.
This is exactly the point that I was questioning, so it sounds like I understood their point just fine. Do you have a citation for this assertion?
The paper from Google doesn't even mention a repository as a concept.
Here's what it does say:
> Untrusted code is executed on the device. One fundamental difference to other mobile operating systems is that Android intentionally allows (with explicit consent by end users) installation of application (A) code from arbitrary sources, and does not enforce vetting of apps by a central instance.
The Android security model is based on the idea that you can install arbitrary APKs from literally anywhere. If I download an APK through Chrome and install it, I might turn around and download another APK from a different website. If anything, Chrome is more arbitrary in its sourcing of APKs. How does F-Droid break the security model but Chrome doesn't? Alternatively, how does Google allow Chrome to break its own security model?
And again, what is your source for your claim? I'm reading the actual document from Google, and it appears to say exactly the opposite of what you're saying.
Chromium is a particular case, but is still equally considered an untrusted source unless explicitly allowed. Of course, the security model takes into account that apps can be installed from anywhere. That's why they're signed and they're running in their own restricted sandbox.
No, I can't, because as far as I can tell there is no OS-level concept of an app repository. Where are you getting this from? Can you link to the APIs that have this concept documented?
> Of course, the security model takes into account that apps can be installed from anywhere. That's why they're signed and they're running in their own restricted sandbox.
Right. They planned that in. They spelled it out explicitly. Untrusted code from arbitrary sources is allowed if the user opts in. It's not a violation of the security model, it's a particular case that was specifically planned for.
The management features, again, expect the app to represent a single source. F-Droid deliberately chooses to manage multiple sources that can also be added by the user within the same app, thus bypassing these features. That's the way they work and again, this paper is not exhaustive and is not in contradiction to anything that has been said (quite the opposite).
In return, you suggest that the documentation is out there, but you give no specific pages that I can read. My attempts to find them on my own or through your blog post have been fruitless. Given that the idea that you're putting forward runs directly contrary to the paper that Google published and is contradicted by the behavior of Google's web browser, the burden of proof is now on you. I need your source. Please provide a link to where you arrived at your idea.
You're welcome to search for mentions of sources and app stores, and to browse the references.
Again, the paper is not in contradiction, you misread it. Not to mention, as explained in the original comment you were responding to, F-Droid weakens the security model for various other reasons.
It's obvious you're convinced you're right, but since you're unable to produce evidence it seems we are at an impasse. I'm done here.
You have been provided with evidences, but you've been arguing in bad faith since your first comment by misinterpreting the paper. The security model also expects you to download apps from trusted sources because the signature verification is only enforced for app updates, that's a trust-on-first-use model. That notion exists within Android, and you have been given examples.
> In order to ensure that it is the app developer and not another party that is consenting, applications are signed by the developer.
Back to the original question; it is clearly explained why.
https://arxiv.org/abs/1904.05572
See my other comment for what I did find, which is exactly the opposite of what OP says:
Citation, please?
> A more serious flaw opposing the Android security model is the fact that an app store is supposed to feed from a single repository which F-Droid does not adhere to.
Also, where is this documented? I read through several security pages (e.g. https://source.android.com/security/overview) and can't find any reference to a 'repository' or the idea that F-Droid is not secure because it aggregates apps from many sources. I think I'm misunderstanding your point entirely...any links to more detail would be very interesting to me.
Also, it is stuck on old APIs and won't allow the use of Android's new unattended update feature (UPDATE_PACKAGES_WITHOUT_USER_ACTION) and requires intrusive privileged system access to do that.
A more serious flaw opposing the Android security model is the fact that an app store is supposed to feed from a single repository which F-Droid does not adhere to.
Also, often these repos are poorly maintained, rarely updated and often conflict with Play Store packages because they use identical app ids.
All they care about is to be free from "evil proprietary components" which comes at a great cost of security and inescapably privacy.
It's just not a good choice for these and additional reasons such as building a ton of their apps unattendedly on a potentially malicious server.