Tagged releases of AOSP are the same base code that all the retail distributions of Android are based on, so should be just as safe.
If you have a Pixel device, the RattlesnakeOS project [0] will allow you to run your own automated AOSP distro, complete with OTAs, on AWS. It also supports adding a few modifications like MicroG.
All but the most recent Pixel devices are also supported by GrapheneOS, which is a security-focused ROM.
Both of these projects support signed builds, so once you flash them to your device, you can lock the bootloader.
This wipes all existing data and notifies the user that the device is not secure whenever it's booted. There's no way that a user would fail to realize this. I agree that it's unrealistic to expect apps that directly deal with money/finance/etc. to be supported on unlocked devices, but aside from that it should be fair game.
I think you place far more trust in an average user than they deserve. If a user saw that their phone was factory reset and had a scary warning, I can easily see many users happily ignoring it and setting up their phone again, assuming it was the result of some bug.
The more tech-savvy HN crowd might be worried and flash it with fastboot to be safe but don't expect that of a random average person.
The problem with unlocked devices is that it's a legitimate security risk.
With a signed OS and hardware attestation, you can verify with 100% certainty that the foundation of the device's security model is there and fully intact. Upon that foundation you can build features that you might not be comfortable with otherwise, like an OTP app, authenticator app or a payment app. You wouldn't build an "OTP" app for Windows for example because Windows doesn't have a solid security model, it's quite easy for one application to access another application's resources.
Once that foundation is broken, all bets are off. If the bootloader is unlocked, you have no way of knowing what's running on a user's device. For all you know, all of the permission checks have been removed and nothing is secure anymore. Even the APIs you'd expect to interact with a secure enclave could be replaced.
Others are suggesting that this is the user's choice and so perhaps developers should just deal with it but I disagree. A device isn't necessarily unlocked by the user. A device can be unlocked by anybody with physical access and the passcode. For example a malicious party could install a malicious version of Android on your device if they have unattended access to your phone for a while. They could also buy phones, flash malicious versions of Android and then sell them at a slight loss, making profit off the money stolen from their victims.
There's also the problem of malware that gains root privileges. With a locked bootloader, there's limited opportunity for such malware to become persistent. It can't modify the system partition at all. With an unlocked bootloader, it can modify the system partition and permanently modify the OS. Basically, locking the bootloader prevents rootkits.
This is why these features are here. They're not here to make enthusiasts' jobs harder, they're here to provide a solid foundation of security upon which an OS that's secure enough to handle high-value information can be built.
> When this is enforced for all devices some apps, like the eBay app, won't run on unlocked devices anymore.
In some cases (e.g. games), I think this is ridiculous. For apps that deal with finance or other sensitive areas, as explained above, I think this is entirely reasonable.
All that said, I can see a world in which we have custom ROMs as well as security:
- We make custom signing keys [0] commonplace, not just a thing for Pixel devices.
- Set up an automated service through which a device can submit CTS [1] results and have its build of Android whitelisted.
[0]: https://android.googlesource.com/platform/external/avb/+/mas...
[1]: https://source.android.com/compatibility/cts