[pserwylo]

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

[nosedief]

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.

[toastal]

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

[themacguffinman]

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.

[kuschku]

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.

[amatecha]

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.

[toastal]

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.

[hansel_der]

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.

[upofadown]

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.

[lrvick]

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.

[upofadown]

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

[gradeless]

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

[kuschku]

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.

[themacguffinman]

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.

[upofadown]

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

[gradeless]

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.

[themacguffinman]

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.

[NateEag]

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.

[kuschku]

> 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

[NateEag]

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.

[kuschku]

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.

[upofadown]

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

>Heartbleed, Shellshock, and Log4Shell ...

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

[amatecha]

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

[PausGreat]

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

[lolinder]

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.