Hacker News Reader

Comment by nosedief | Hacker News Reader

Although I'd like to applaud any alternative to Google Play the approach F-Droid pursues does not fit a serious security model. F-Droid builds are custom signed and can be made by random parties without proper auditing after initial review.

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.

View on HN

> F-Droid builds are custom signed and can be made by random parties without proper auditing after initial review.

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.

There is a difference in your Linux desktop workstation and your most private device. Desktop systems are not nearly as secure and should not be seen as such, and Linux surely at the tail end.

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.

In order to get started with F-Droid you have to jump through several hoops with strong warnings from Android about allowing third party apps to install applications.

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.

> your most private device

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.

A smartphone is a computer that is more involved in your private activities. For example, a phone is likely to be on your body when you move around the city and talk to other people so it is exposed to more private information about you than a stationary desktop will be.

Right, it's in your pocket while you are having private conversations, it's on the bedside table while you're... well, in bed. Surely this gets the point across. You probably don't ever want to be running some malicious actor's software on it.

So don't keep location services on and don't give microphone/camera permissions to apps you don't trust?

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.

You haven’t met me but my laptop basically goes everywhere with me and has for the last dozen years. It also has cameras and mics I have to deal with. And with 5G coming to laptops and how to get those speeds the signals have to target your device, we will always be tracked as long as we touch cell networks... just as you can being on WiFi or having an IP address. I don't feel my phone is closer to me in any way.

not to disagree, but imo the main point here is that almost everybody has a smartphone but only a minority has a desktop computer, so it makes sense to care mostly about the phone thingy.

Surely a desktop running a well respected Linux distribution is much more secure than any smartphone. It will be locked for much of the day, possibly with disk encryption. There are few services (any?) exposed to the network. The software can be all open source, both OS and applications. The only weakness would be the web browser, and there are web browsers used on smartphones.

Desktop operating system are less secure than mobile devices.

Linux is also the worst of desktop operating systems.

https://madaidans-insecurities.github.io/linux.html

I think iOS devices are much more secure than a Linux desktop.

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.

IMessage had a remote code execution that could entirely take over the phone...

>Heartbleed, Shellshock, and Log4Shell ...

... are all irrelevant to desktop Linux...

Did you hear about "PwnKit"? Just a month ago one of the most serious security flaws in Linux (affecting nearly all distributions) was disclosed and it had been present since 2009. https://www.bleepingcomputer.com/news/security/linux-system-...

(btw Heartbleed affected Linux desktop OSes such as Debian, Mint, Ubuntu, RHEL, etc.)

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

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 never heard of this ability. Do you have a link describing it?

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.

I believe I was thinking of https://github.com/rileytestut/AltStore, but I’m not sure if that’s the exact project (I don’t use iOS, so I don’t keep all of the details in mind)

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.

Wow, this is fascinating. I do not recall hearing of this workaround before.

Thanks!

In practice, not really IMO. Both Android & iOS also supports disk encryption and are also locked for most of the day. I don't know why you say "few services exposed to the network" for Linux when virtually every installed package has unfettered access to the internet (unless you're wrapping it with something like Docker or manually setting up your own network namespaces). Android and its apps can be run 100% open source as well.

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.

>Both Android & iOS also supports disk encryption and are also locked for most of the day.

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.

Disappointing to hear that mobile disk encryption is subpar, I have heard of stuff like Cellebrite but didn't know much about it.

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

While its likely Cellebrite make use of some known (and possibly some unknown) exploits to bypass the screen lock on some phone models and get at user data, sometimes they require the device to be unlocked and doubtlessly make use of adb to pull out user data.

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.

I wish this were true but the reality is that with the exceptions of QubesOS and ChromiumOS, desktop linux distros grant any process trivial access to elevate to root as there is no sandboxing model. Any process can alias your sudo command to steal your password, or run privileged docker commands, etc. It gets worse when you introduce snaps, appimages, and flatpaks usually uploaded, usually unsigned, by randos. This download-random-exes style model is becoming default and encouraged by distros like Ubuntu.

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.

>desktop linux distros grant any process trivial access to elevate to root as there is no sandboxing model.

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.

Theres a lot more to the android app sandbox than just running processes as seperate users. Theoretically something similar could be implemented in some other 'typical linux system'. It would be a huge undertaking. If you are thinking about security need to consider not only malicious apps, but possible attack vectors opened up by any application. This paper is a couple of years old, it explains how it all works on Android https://arxiv.org/abs/1904.05572

Most modern flatpaks under wayland are quite well sandboxed. They'll only have access to manually selected folder, can't access other windows (not even the way accessibility services on android can) and their process and network namespaces are limited as well.

Do you have a citation for your claims about the Android security model?

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

[0] https://arxiv.org/abs/1904.05572

You misunderstood what they said. Indeed, Android can have multiple app repositories and this is an integral part of its security model design.

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.

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

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.

This paper is not exhaustive and there is further documentation on the APIs in question on the Android official website. You can easily guess the problem involved with the security model when the OS expects an app repository to represent a source of trust, but the app in question decides otherwise.

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.

> You can easily guess the problem involved with the security model when the OS expects an app repository to represent a source of trust, but the app in question decides otherwise.

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.

Any regular app can be considered an installer. Such APIs like the one controlled by requireUserAction which allows seamless app updates since Android 12 are declared in the app in question, and can even allow apps to update seamlessly.

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

You still haven't explained where it is specified that the OS cares about number of "sources". I have cited the original document explaining the Android security model. I have given you the specific paragraphs that show why I think the way that I do.

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.

Sounds like a you problem: https://developer.android.com/reference/com/google/android/t... https://developer.android.com/reference/android/os/UserManag...

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.

The links you provide say nothing except something I already knew: there is a setting that tells Android to allow installing apps from unknown sources. Which proves... nothing at all.

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.

Once again, these management features don't expect an app to bypass the trust boundaries by allowing the user to arbitrarily add repositories. There is a to-be-exposed toggle that allows user profiles to install apps from trusted sources. It wouldn't work with the way F-Droid works. I can't explain more than that.

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.

This sounds like the traditional Linux packaging model: one repo with software built by distro maintainers, additional repos added by the user with software built by whoever. I don't see any problems with it

The Android security model strictly forbids it. This should be enough of a problem as it is the very foundation to establish security for the system's user.

> The Android security model strictly forbids it.

Citation, please?

I don't know enough about the Android security model to evaluate what you're saying. What parts of the Android security model does F-Droid violate? Is there a spec or description of the Android security model anywhere that I can read?

There's a paper by several Google employees describing it. I haven't read it, just skimmed and searched keywords, but near as I can tell it doesn't mention anything like what the OP thinks it does:

https://arxiv.org/abs/1904.05572

See my other comment for what I did find, which is exactly the opposite of what OP says:

https://news.ycombinator.com/item?id=30507713

I don't understand the definition of 'repository' here:

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

That may be true if you are sideloading F-Droid. Our security model focus is based on integrating F-Droid into the ROM, like with CalyxOS. This method is proven to provide better security than Google Play devices, since by default, all apps are open source and reviewed by humans. For example https://f-droid.org/2020/03/04/f-droid-is-a-key-source-for-a...

Reply on news.ycombinator.com