I’d like to know more about it too.

So far, from what I know, the main problem is the drivers for everything but CPU. Linux runs perfectly on ARM, be it Apple or not, but when it comes to something like a video adapter… with HW-accelerated video decoding and stuff… here’s where you start getting problems.

Regarding software, I run an ARM-based distro inside a VM on Apple for work and everything from what I need there exists and works.

No. Sorry, Microslop.

No, that might hurt someone’s feelings, so if you do that you’ll be banned from the platform, your data will perish and your whole online personality will be canceled eventually. Welcome to the modern internet :)

GrapheneOS pretty much solved the closed device trees issue you’re referring to. They don’t need them anymore and use their own toolchain to workaround the issues.

The problem with Pixel 10 was different: it was released with Android 16 QPR1 out-of-the-box, but this very QPR1 hasn’t been pushed to AOSP until a couple of weeks ago. This is why the GrapheneOS build for Pixel 10 was not possible: they could not/didn’t want to port the older Android 16 OS to Pixel 10’s hardware, and they didn’t have the source code of the QPR1 to build GrapheneOS on top of it.

Now the QPR1 (and currently even the QPR2) has been pushed to AOSP, so GrapheneOS has released Android 16 QPR1-based GrapheneOS both for older phones and for Pixel 10.

Yes, unfortunately. It’s their con, but also their pro at the same time. It’s bad because they end up isolated from everyone else playing nice with each other, and then no one wants to deal with them, but they also don’t agree on compromises that might hinder security or the stability and development of their project. And I respect that. That is partly a reason why they created probably the most secure and private AOSP distrubution nowadays.

They can, but it’s not their goal. Their goal is to have control over 99% of Android phones produced and not let their users install adblock or NewPipe, or torrent app or whatever.

There’s GrapheneOS that I think would try to address this problem — secure, proper architecture, compatible with some major app stack (e.g. Android apps). It’s AOSP-based, but they’re already thinking ahead up to a point where they would be forced to fork it and even work with OEMs to create their own phone hardware for it. There are a couple of threads on their Mastodon.

I don’t know how much they would be able to achieve, but I would pay for such system.

This. And obviously to ban all the things like adblockers, NewPipe, custom browsers, etc that give people any kind of relief from Google’s digital slavery.

PIN code throttling can’t be implemented properly if hardware doesn’t support it. This is the very purpose of the secure element.

It has its own CPU, storage, random number generator and realtime clock. Once a secret (encryption key) is generated inside of it, it can’t get unlocked until this very tiny chip allows it. And the chip uses different kind of protections (in case of weak pins — the most prominent one is throttling using its built-in RTC clock).

If there’s no secure element, then attacker can just extract the memory chip and easily brute force the encrypted key on the much more powerful (and not throttled by RTC) hardware.

And since the PIN codes are so weak, even the strongest key derivation functions won’t help against such bruteforce.