What I never get is: why not prepare to fork AOSP? I like the security model of AOSP :-).
eOS is basically what you are looking for for most phones or GrapheneOS (pixel only)
But for the reason an antiquated os like postmarketos are suggested is that the project is being opportunistic thinking this is a chance they can be relevant. Additionally, the population of HN has more sentimental view on these legacy operating systems and view it as a chance to go back to the past and use software they are familiar with.
That's not a hard fork. They always rebase on top of AOSP when there's a new AOSP source release
Regulators in the US decided that Android did not have to be split from Google, but they could theoretically decide that Google is not allowed to break AOSP to gain a competitive advantage. Not that it would matter: TooBigTech is too powerful to care about regulations anyway.
If you don't rebase from AOSP, the apps won't run pretty quickly.
For a while I thought it was a missed opportunity to compete on a hard fork, but then I realised that Huawei probably cannot fork the Android SDK/NDK because it's not open source.
- Using the default 5g setting resulted in far worse battery life than stock, telling people to choose 4g isn't a solution. They desperately need something like the adaptive connectivity service.
- Using Homeassistant's GPS tracking feature just destroyed the battery life, even switching to 4g didn't solve this issue. Changing all the GPS settings didn't help either.
- The obnoxious green GPS active icon makes the notification bar useless if using a GPS tracking app (or even gps navigation). The request for a whitelist was either ignored or rejected, the teams communication can come off a bit rough.
No normal user is going to be happy with Grapheneos. From what I've seen postmarketos is much more user friendly.
What's obnoxious about the green GPS icon? How does it make the notification bar useless? It is on all the time while I'm using Google Maps, it's small and not in the way and is a good reminder if I have accidentally left Google Maps open in the background. What's the problem?
I ended up using my public ip address in combination with a list of known ips for home and work and such, and building my HA automations around that. I wanted to do it with wifi SSID's, but that also requires the location permission and triggers the indicator (which is understandable, just wish I could still read SSID's with location services disabled entirely) (or, just let me disable the gps antenna and leave everything else).
It's not noise for me, I only ever have GPS on for Google Maps, and I like the indicator because its absence reassures me that nothing is using GPS in the background.
I am a normal user, extremely happy with GrapheneOS. I just don't use HomeAssistant, which seems to have been your dealbreaker in this case.
I genuinely don't see a difference between Stock Android and GrapheneOS, except that I get more updates and I have more privacy controls (like scopes, but honestly I haven't had a need to use them yet).
Not to mention the 5g battery drain is a hard show stopper, not just Homeassistant issues. I even experimented with different apps like owntracks but same problem with GPS.
I found a solution to the GPS icon but it requires an ADB command so not a great fix.
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.
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.
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...
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.
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.
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.
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.
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.
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.
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.
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".