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 8 days ago | parent [-]

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 8 days ago | parent [-]

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 7 days ago | parent [-]

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 5 days ago \| parent [-]
		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.