amosbatto

Linux distros and repos with AppArmor, SELinux, SNAP and Flatpak often decide what permissions the app has. It usually isn't the decision of the creator of the app. Of course, this can be done in the AOSP world, but I don't think F-Droid changes the permissions that apps ask for, and Google Play Store certainly doesn't change them in my experience.

Most Linux phones only run proprietary apps inside an LXC container (Waydroid, AppSupport, Andromeda or Lepton), which has its own security configuration that can be set the distro.

> Members of the GrapheneOS project (myself included) call these projects out because they're misleading their users.

It is fine to publicly criticize the security/privacy of other FOSS projects, because criticism often fuels improvement in the long term.

In my case, however, I had two public debates with Daniel Micay (first on a Hacker News thread, then later on a Reddit thread) about the security of Linux vs AOSP, in which he publicly accusing me of organizing raids against the GrapheneOS community, which was a total fabrication on his part. My interaction with Micay is mentioned in Techlore's 45 minute video, where he documents his own conflict with Micay.

I'm actually impressed by GrapheneOS's work on the Android kernel, so this isn't a comment on GrapheneOS per se, but I decided to never use GrapheneOS and to stay far away from the project based on that negative experience.

Off the top of my head, here are some of the anti-user features in AOSP/Android that I would change:

* Remote attestation. If someone wants this, they can turn it one, but the OS and apps shouldn't be able to impose this requirement on the user.

* Making it hard for people to root their phones. I can understand having root access turned off by default, but it should be an easy and documented process to turn on root access on your phone, but it should also require setting a root password, which the user has to enter when doing an administrative action in the system. After rooting the phone, the GUI will ask for the root password when doing certain administrative tasks and the terminal will ask for it when using `su`. However, I would enable non-root users to access more than they currently can (see below).

* Apps should not be able to decide that they won't execute based on rooted status, Play Integrity checks, SELinux enforcing, bootloader unlocked status, etc. It should be up to the user, not the app creator, whether an app is allowed to execute. The OS should inform the user about potential security problems, but not encourage app creators to put these restrictions on their apps. I realize, however, that an AOSP fork wouldn't have the power to stop app creators from doing this stuff, so I would include a clean Android work profile and make it so those problematic apps can't detect what has been done to the rest of the system.

* The Activity Manager (`am` command) needs to be designed or eliminated to stop restricting the user. It is very annoying that users can't just execute graphical apps from the terminal like in Linux, and the way `am` does it is designed to make users not use a terminal. Instead of `am start -n org.videolan.vlc/org.videolan.vlc.gui.video.VideoPlayerActivity -a android.intent.action.VIEW -d file:////storage/emulated/0/VideoToPlay.mp4`, it should just be `vlc ~/VideoToPlay.mp4` like in normal Linux. Forcing apps to name the activity with the `-a` option, and to pass their parameters with the `-d` and `-es` options is designed to stop users from using options. Most Android apps have no command line options because Android makes it so painful to use them, and that is by design. Why does Android force users to refer to apps by reverse domain name order like "org.videolan.vlc" which is impossible to remember and so hard to type? Using the full reverse domain name for an app should only be necessary if there are two apps with the same name, and it should be possible to create an alias for apps so they can have short names. If a user (i.e. the person using the phone) initiates an app, then that person should be able to kill the app from the command line with a short command like `pkill app-name`. Currently, AOSP only allows `am force-stop com.example.myapp` if the phone has been rooted or if issuing through ADB (`adb shell am force-stop com.example.myapp`), which is an anti-user restriction that needs to be eliminated. I wouldn't require the `am` command at all for starting and stopping apps, but if AOSP/Android is going to use the `am` command, make everything easy to type and very short. It should be possible to set variables when executing apps just like in normal Linux (e.g. `MY_VAR=value myapp`) Instead, AOSP forces people to either root their phone or use adb, just to set variables when executing an app: `adb shell setprop wrap.com.example.myapp "env MY_VAR=value"`

* AOSP requires a rooted device or adb in order to use many commands, including `setprop`, the package manager (`pm`), most networking commands (`ip`, `ss`, `netstat`, etc.), use of wrap.com.example.appname or debug.com.example.appname, etc. It is really annoying that you have to root the device just to see the list of the installed packages with `pm list packages`, see the current battery state with `dumpsys battery` or even see the IP address with `ip a`.

* AOSP requires a rooted device or adb in order to view most of the directory structure on the device. In standard Linux, an ordinary user gets read-only access to `/`, `/dev`, `/sys`, etc., which makes it much easier to figure out how the system works and diagnose problems, but the device is basically a black box for the ordinary android user. I can understand forcing normal apps to access the hardware through the Android HAL and not be able to read the / directory, but terminal apps should have permissions, so the normal user can have read-only access to `/`, `/dev`, `/sys`, etc. Forcing users to execute some custom command like `termux-setup-storage` just to get permission to access the microSD card is bizarre and another anti-user feature.

* Forcing users to create an app just to execute a custom script from the launcher is another anti-user feature. Let’s say that you want tapping on an icon on your screen in order to run a custom script. In a standard Linux system, you just create the script, and then you add a launcher in the graphical interface to execute it or you add a `.desktop file` to the `~/.local/share/applications` to add it to the graphical interface. In AOSP/Android, you need to create your own app in Android Studio that has a `AndroidManifest.xml` file with this code: ``` <intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.HOME" /> <category android:name="android.intent.category.DEFAULT" /> </intent-filter> ``` And you need to have application code that has Java or Kotlin code like this: `Runtime.getRuntime().exec("/storage/emulated/0/your_script")` Then you need to create the apk file and sign it and install it. There are workarounds, like installing Termux and Termux:Widget, but those workarounds shouldn't be necessary. AOSP should make it as easy as standard Linux.

* The way permissions work in AOSP/Android is simply a hassle and requires too much cognitive load for the average user. When you first install a new app, you have no idea how the app works or what permissions it really needs. There are 324 different permissions in Android 17, and it is overwhelming for most people to install a messaging app and be asked for a dozen different permissions, such as Notifications, Identity, Contacts, SMS, Phone, Photos/Media, Storage, Camera, Microphone, Wi-Fi, Calendar and Location, which is why so many users simply grant all the permissions that are requested, so the permission system doesn't really work as intended.

It would be much better for the distro package manager to configure the app to grant just the permissions that most users of the distro would want, and then let the user set the permissions that she always wants to be asked about, but not be bothered with the rest. For example, Calendar and Location shouldn't be necessary for most users of a messaging app, so they wouldn't be granted by default, and the OS would ask for those permissions if the user tries to use a feature that requires those permissions. In a distro focused on security, the defaults would be different from a normal distro. The list of permissions granted by default should be shown to the user when installing, and users who want to pick and choose can open a dialog box to select the permissions. They can also set the permissions across all apps that they want to be asked about.

In my opinion, the user should only be asked about each permission only if an app comes from outside the default repository. Of course, this assumes that the default repository is only contains open source code, and the package manager is separate from the app creator and is reviewing the code in the interest of the AOSP distro's users.

* Each app has a different user assigned to it by AOSP/Android, and you can't change the name of that user, which is very inconvenient, because AOSP/Android creates random usernames that are very hard to remember. For example, every time I want to ssh to my AOSP phone, I have to open Termux and use the `whoami` command, because I can never remember that my Termux user is named u0_a281.

The problem with Android's "fine-grained run-time permission model" is that most users learn very quickly that if they don't grant Android apps all the permissions that they ask for, they won't have the app's full functionality. I have played this game many times with Android apps, where I only grant them the permissions that I think are strictly necessary. However, after I start using the app, I constantly discover that I keep needing to grant them more and more permissions. In the end, it becomes such a hassle to keep being asked for permissions, that I almost always end up giving every app all the permissions that it asks for.

It is far better for most users to have their apps preconfigured to only grant the permissions that they need by distros and companies who care about protecting users and keeping their data private. As a user, I don't want to have to scrutinize every app that I install and check whether the business model of the app creator is based on surveillance capitalism or malware. Since I use the PureOS and Mobian distros (which are Debian derivatives) on my Linux phones, I can have a lot more confidence that I'm not installing anything that will harm me or spy on me. Yes, I know that Firefox is paid to set Google as the default search engine and Canonical tried a few schemes in the past like its Amazon Shopping Lens in 2012-16, but those are anomalies in the Linux world, whereas they are the norm in the Android world.

> Nothing stops Android apps from being open source and also properly vetting contributors. This isn't a technical limitation of AOSP-based OSes at all.

Yes, there are companies making AOSP derivatives which have good business models that respect and protect the user, such as Murena, iodé and Volla, and I know that the F-Droid community did a good job of reviewing the code that I submitted to them. I have a personal beef with how Daniel Micay treats other FOSS projects, but GrapheneOS does a good job of protecting its users. However, I know from personal experience that I always end up installing apps based on surveillance capitalism on my AOSP phones, because I always end up needing some Android app. In 27 years of using Linux, I haven't installed any malware or spyware that I know of (beyond Firefox's Google search), and that is the common experience of most Linux users. (See below for further argument.)

> This is absent on the alternatives you propose. Flatpak doesn't use a proper run-time model, isn't as fine-grained and has numerous sandbox escape possibilities (notably via dbus or access to config files like .bashrc).

If you are arguing that mobile Linux needs to improve its userspace security model, then I agree. I'm not saying that Flatpak is perfect. My argument is that it is much easier to improve mobile Linux's security model than to fork AOSP or even just replace the user anti-features in each new release of AOSP.

> The vetting system on Linux is imperfect as I said above, it still relies on trust. And as I said before, there are more security problems than simply code written with malicious intent.

True, there have been instances, such as OpenSSH's CVE-2026-35414, where they didn't catch the problem for 15 years, and you mentioned the xz backdoor, where someone (probably the Israeli government) was deliberately introducing security holes. In general, the Linux distros have been lulled into a sense of complacency since they haven't had major security issues like Windows and Android have had in the past. I think the real issue is the fact that the major Linux companies (IBM/Red Hat, SUSE, Canonical and Google) are mainly focused on servers, where userspace security isn't an important factor. If your argument is that mobile Linux won't be able to implement a better userspace security model without the help of the big Linux companies, then you may have a point. However, the example of Qubes demonstrates that it isn't impossible for a single distro to implement major changes.

However, if the long-term goal is digital freedom and user empowerment, dependence on Google puts us in a very precarious position, and I suspect that Google and the phone brands will keep turning the screws and making it harder and harder for the AOSP-derivatives to keep operating, because the business model of the mobile industry is changing from planned obsolescence to surveillance capitalism and the monetizing of people's personal data. The tech giants are in a fierce race to collect as much of our personal data as possible in order to train their LLMs. Although the current AI bubble will pop, just like the Internet bubble popped in 2001-2, that didn't stop the Internet from becoming the predominant paradigm for the tech industry, and AI will probably follow a similar trajectory, so I don't think the financial incentives to collect our personal data for targeted advertising and AI training will stop.

As I explained in my previous article on Linux phones, the smartphone brands that permit unlocking of the bootloader have dropped from 42.5% to 7% of the market in recent years. The brands which allow their bootloaders to be unlocked (without major restrictions like Xiaomi) only sold about 87 million phones in 2025, including Lenovo/Motorola (60M), Google (12M), OnePlus (11.6M), Nothing (2M), GigaSet (>1M), Sony (400k), Fairphone (145k), SHIFT (10k), Teracube, Volla and Brax. The number of new phones sold in 2025 that have official LineageOS ports and aren't locked by carriers is probably around 20 million phones or 2% of the global smartphone market, and that number will probably drop to 10 million per year as Motorola keeps switching more of its phones away from Snapdragon processors, OnePlus is pulling out of Europe and North America and Nothing is cutting staff and will probably pull out of many markets. In other words, our ability to install custom ROMs will keep being restricted. For people living in Iran and most of Africa, there is not a single new phone on the market that has an official LineageOS port. In some African countries (Kenya, South Africa, Nigeria, Ghana and Eygpt), most of Latin America (except Mexico) and most of Asia (except Japan, Taiwan, Singapore, India and Malaysia), they only have one new phone on the market with an official LineageOS port, which is the Motorola Moto G15 that was released in December 2024.

We are becoming increasingly dependent on Google for both the software and hardware to run AOSP phones. For most of the world, Motorola is the only option to install an AOSP derivative, which means waiting 3 to 14 days just to unlock the bootloader, or buying a used Xiaomi and dealing with Xiaomi's insane policies to get an unlock code.

We need to support the Linux phone companies, because we have no idea how much longer Google will continue to release AOSP, and we are totally screwed if Motorola or Google change their bootloader unlock policies. None of your arguments convince me that the community can maintain an AOSP fork with 309 million lines of code, whereas we know that the Phosh and Plasma Mobile interfaces and the existing mobile Linux distros like SailfishOS, Ubuntu Touch, Nura, Mobian, DanctNIX, Droidian, etc. can be maintained by the community.

OK, let me try to address some of your specific points in subsequent comments below.

Purism's public reputation was blackened by its decision to stop repaying the refunds to people who canceled their Librem 5 pre-orders after Feb. 2020. I think that decision allowed the company to finish developing the Librem 5 phone and start shipping it in Nov. 2020, but you will find a lot of negative comments online about the company (see Reddit's r/Purism). I often point out the positive aspects about the company, because the company gave a lot to the community by developing libadwaita and Phosh, but some people don't see it that way.

Purism chose to upstream their changes to mainline Linux, whereas the volunteers working on the PinePhone's kernel generally didn't.

To:

Purism generally chose to upstream its changes to mainline Linux, whereas the volunteers working on the PinePhone's kernel were less consistent about upstreaming their changes.