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.
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
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...
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.
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
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...
3 replies →