[palata]

> It's a good idea to avoid Android because of kernel security as well.

Well it's "just" a matter of updating the kernel, right? Those linux projects like PostmarketOS do a lot of mainlining, which benefits custom Android ROMs.

I agree that if the goal is to use the device as an RPi, then it's better to avoid Android. But I wouldn't say that Android is less secure than Linux in general (on the contrary, Android has an interesting security model).

[d3Xt3r]

It's not "just" the kernel. The bigger issue is the firmware - Android devices have a ton of closed-source low-level firmware bits, and you really shouldn't expose them to the Internet after the device has reached end-of-support.

But if you're only using it for limited projects as an RPi replacement, then it's probably alright if you're also putting a firewall in front of it, or having it in an isolated network segment with a reverse proxy.

[palata]

> Android devices have a ton of closed-source low-level firmware bits

Can you elaborate on that? You seem to be suggesting that there are low-level firmwares on Android devices that are exposed to the Internet and do not receive updates. Which ones? And do they receive updates with Linux on mobile OSes? And if yes, why couldn't alternative AOSP-based systems use those firmware updates?

[d3Xt3r]

The important ones - from a security and privacy standpoint - are the baseband (cellular stack), WiFi, Bluetooth, NFC, camera, mic, bootloader and the Trusted Execution Environment. Then there's also minor firmware bits for the sensor hub (accelerometer, ambient light sensor etc), touch controller, audio etc.

You can imagine the consequence if there was a vulnerability in say the WiFi firmware or the microphone. The Bluetooth stack is especially vulnerable, with it being an attack vector many times in the past.

On Android devices, only Android has been able to deliver updates to those firmware blobs. This is mainly because these are closed source binary blobs, and are provided by the OEM (often in conjunction with the respective chipset manufacturer, covered by a license agreement).

AOSP and unofficial Linux based OSes like PostmarketOS do not have a license to obtain and distribute these firmware. But even if they did, it means nothing if the support agreement from the chipset maker has ended. Being closed source bits, you can't do anything about it if the respective manufacturer refuses to provide updated firmware.

Ocassionally, some Android custom ROM makers may extract these blobs from more recent devices having the same chipset but running newer firmware, and of course, it doesn't always work (well), not to mention, it's technically illegal. And of course, an official project like PostmarketOS or LineageOS would never do something like redistribute proprietary firmware bits. Projects like these conveniently ignore the firmware issue, and leave it as an exercise for the end user.

[palata]

Thanks for the insights, that's super interesting!

[jraph]

> (on the contrary, Android has an interesting security model).

Which doesn't really apply to a server use case, does is?