[charcircuit]

At least in regards to the security model, it is decades out of date. For example any app can listen to your microphone and spy on you at anytime. Programs can act as ransomeware or destroy all of your files. Stealers can steal your login credentials and access tokens for all your sites including banking ones.

[zorked]

I think people don't realize how inadequate the Unix security model is.

[eikenberry]

Linux doesn't solely rely on the Unix security model. Linux security is mostly based on trust, the trust of the distribution and its maintainers. But if you want to run random, untrusted apps you'll want a different model. Linux is slowly addressing that need w/ a variety of different approaches which could be picked up and used for a mobile OS.

[m4rtink]

Well, isn't the idea that you use apps compiled from source by distro maintainers, which are separate from the upstream maintainers ?

Frankly, I still trust this model much more than black box Android apps automatically updating in the background, sending tons of telemetry and demanding random permissions so they can spy on you.

Not to mention the security model preventing many useful things from working properly (try to get a SFTP working on an Android system so that you can copy out photos taken by the phones camera.

[hollerith]

>isn't the idea that you use apps compiled from source by distro maintainers

That might work if the main danger was upstream maintainers with bad intentions. But the main danger is security holes that no upstream or distro maintainer knows about, which allow attacks by parties that are not open-source maintainers.

Big picture is that GrapheneOS is much, much more secure than PostmarketOS.

[palata]

> Frankly, I still trust this model much more than black box Android apps automatically updating in the background, sending tons of telemetry and demanding random permissions so they can spy on you.

You're comparing a security model to... apps? I don't see how that makes sense.

Apps you install on Linux can do more than apps you install on Android, period. That's part of the security model.

Of course I like that I am an admin on my computer, but I don't need that on my phone. And one can enable root on Android and still keep the apps sandboxed...

[j45]

Meaning, it's a way to keep old hardware running linux instead of being a phone.

[seba_dos1]

...except in virtually any case where you'd run something untrusted there you'd use Flatpak or something similar where what you wrote doesn't apply.

[tom_alexander]

> untrusted

I think the important distinction is _everything_ should be considered untrusted because even trustworthy software can become malicious. For example, the XZ Utils backdoor[0].

On Android, everything I run is subject to the permission model and sandboxed. That is not the case on Linux.

[0] https://en.wikipedia.org/wiki/XZ_Utils_backdoor

[seba_dos1]

It's not the case on Android either and it could be subjected to a XZ-like backdoor just as anything else.

[tom_alexander]

Could you be more specific on how to circumvent the android permission model + sandbox? So far I have only thought of two ways an XZ-like backdoor could circumvent that:

1. By being baked into the OS itself, which is unavoidable since the OS is the thing providing the sandboxing + security model. It still massively reduces the attack surface.

2. By being run through the android debug bridge, which is far from normal and something users have to explicitly enable. Leaving you the option to shoot yourself in the foot in an opt-in manner 99.9% of users will never touch isn't the same as Linux where foot-shooting is the default.

[seba_dos1]

The defining aspect of the XZ backdoor was that it was baked into the OS itself, being linked into memory space by about half of the system and activated by being packaged in a specific way in a specific distribution. If you wanted to ignore 1), you would have to choose a different example.

If you want to confine yourself in a sandbox, feel free to do it. The past decades have demonstrated that it's only necessary for some specific threat models.

[palata]

> If you want to confine yourself in a sandbox, feel free to do it.

I want to confine apps in a sandbox. Android has that, Linux... well not really. I mean "it's possible", but it's not integrated like in Android.

[charcircuit]

>where what you wrote doesn't apply

You can configure your flatpak app so that it will have permission to read microphone in the background or have full access to the disk. Many flatpaks of real apps request dangerous permissions that users have been conditioned to ignore. For example Blender is such an app which has full disk access and background microphone access, and I'm sure many people have installed that. This is unlike Android where these are locked down for every app.

[seba_dos1]

...and if you want an Android app to actually be able to do something useful, you give it root permissions and completely bypass the permission model.

The world isn't black and white. Most reasons why Android apps are being so heavily locked down don't apply to Blender. As a user, I'm not interested in Android-bis - if I were, I would just use Android after all. Nevertheless, things like Flatpak give me, the user, the power over application's permissions and I can take them away (or give more) in a few taps at will. The defaults being tuned for different use cases and threat models are not "being decades out of date", especially when you could already use the existing tooling to replicate other models - regardless of whether you happen to like these defaults or whether they fit your specific use case.

[charcircuit]

>you give it root permissions

This is not possible on a device following the Android security model. Permissioned features should always be implemented using proper security mechanisms like permissions.

>don't apply to Blender

You say that until the SuperRetopologyTools5000.py addon you try out infects your system.

>Flatpak give me, the user, the power over application's permission

Most people are not going to bother with this. It's important for the defaults to be secure. People shouldn't have to opt in to a secure experience, and doing so shouldn't break the program.

[seba_dos1]

> This is not possible on a device following the Android security model.

Yes, that's the user experience on such devices. "This is not possible on a device following the Android security model, either bypass it or use another device".