> If this is a reasonable direction, it could still be achieved on the same device. There would be sufficient security architecture available to completely isolate those two areas.
The problem here is: Who controls the means of input and output - the screen and keyboard? The trusted identity thingy sometimes needs to show the user some details, have them key in a pin number, things like that. So they know whether they're approving a $2 in-app purchase, or a 10-bitcoin transfer.
If the free and open part of the system controls the screen and keyboard, the details could be shown wrong and the pin number could be keylogged and replayed later.
If the secure-and-locked-down part of the system controls the screen and keyboard, the free and open part of the system is basically reduced to an app or website.
And if the secure-and-locked-down part of the system has its own separate screen and keyboard - it's hardly the same device.
No, but I find the supported options to customize Android sufficient for my needs so that wouldn't happen to me personally.
My point is only that there's already a system that lets you run whatever apps you want, and to heavily customize the OS, and also make your bank happy by running a secure OS. It's just out of the box Android. You can replace all the built in apps, including the base "desktop" GUI, keyboard and browser. So this discussion revolves around an edge case: someone who wants to customize security-critical OS primitives like the kernel or compositor, AND who isn't doing this as part of a project big enough to partner with Google, AND who wants their bank to accept their changes as secure enough, AND who doesn't want to provide such institutions with some non-Google managed evidence of that, AND who doesn't want to tolerate using two devices.
There's very few use cases for that. The only one anyone can seem to muster in this thread is to prepare for a hypothetical future in which Google prevents ad blocking at the OS level, which hasn't happened in more than 15 years of Google being an ad company. So today there is a vanishingly small number of people for whom Android's existing mechanisms are insufficient, and for those people, there is dual boot - again, because the Android team planned for this and built a secure boot system that allows alternative OS installs on a phone.
The problem here is: Who controls the means of input and output - the screen and keyboard? The trusted identity thingy sometimes needs to show the user some details, have them key in a pin number, things like that. So they know whether they're approving a $2 in-app purchase, or a 10-bitcoin transfer.
If the free and open part of the system controls the screen and keyboard, the details could be shown wrong and the pin number could be keylogged and replayed later.
If the secure-and-locked-down part of the system controls the screen and keyboard, the free and open part of the system is basically reduced to an app or website.
And if the secure-and-locked-down part of the system has its own separate screen and keyboard - it's hardly the same device.