[rickdeckard]

Unlikely, bootloader unlock is a controlled process and state of the OS for many years now.

The procedure explicitly hands over the responsibility of OS-integrity to the end-user, it's not Samsung's responsibility after that and the user needs to confirm that.

It's much more likely that the cost/benefit profile to develop/maintain/support that feature and its related unlock-process is simply not sufficient, all while several of the biggest customers explicitly require unlock to NOT be supported.

[g-b-r]

What's the cost to develop/maintain/support the feature? It's a simple switch, and since it's probably in AOSP there's cost in removing it, not in leaving it there

[rickdeckard]

The cost is in managing a permitted device-state without a full trust-chain, and maintaining the unlock-logic and service of such an unlock of a device.

It should be simple, but since some carriers required BL-unlock to not be supported at all, many carriers required the availability of a list of all devices being unlocked and all required unlock to be irreversible, there are quite a few considerations to keep this working securely whenever something is touched in the trust-chain of a device.

I hate to say it in this case because I was advocating for BL-unlock for YEARS, but if there's no sufficient commercial demand and no "higher motivation" to justify it, it's a security-risk that's easy to avoid and easy to descope...

[g-b-r]

I don't understand your points, to my eyes if the bootloader is unlocked you simply either:

- don't provide the features for which you require a locked bootloader

- and don't do anything with the rest of the features

And anyhow, I'm almost sure that this is AOSP code (with a quick search I didn't manage to find it).

And, I don't know any carriers that require a locked bootloader outside of the US, and Samsung already only sold models without bootloader unlocking in the US.

[rickdeckard]

You should read up a bit more on the matter then. The bootloader is not shipped in an unlocked state, even on a device which supports BL-unlock.

Bootloader-unlock describes a feature which supports a controlled break of the trust-chain of the device, so telling the bootloader that it should continue executing the bootshell even if the signature check has failed.

In this state the OS should continue to boot despite of this state, and applications should gracefully handle such a condition.

The crucial parts of this are also not part of AOSP, it relies heavily on the chipset manufacturer and the OS-implementation of the device-vendor.

[altairprime]

Note that “applications should gracefully handle” does include “may opt to disable some or all functionality” here, in order to protect secure credentials, comply with merchant agreements, and so on. A productive example of this to study is how macOS behaves when secure boot is disabled, by disabling a couple specific attestation-mandatory features while leaving the majority of application functionality unaltered.