3 ms·

The fix is regulation mandating: 1. All phones should allow the bootloader to be unlocked, without compromising security, so that the user can install any OS o

The fix is regulation mandating: 1. All phones should allow the bootloader to be unlocked, without compromising security, so that the user can install any OS on it. 2. All hardware parts should provide details of an API so that anyone can make device drivers for them for any OS.

zsmi 5y ago
I agree with you in principle but I think writing this regulation, in a way that actually solves the problem and is not trivial to work-around, is much harder than you think. Here's an example: The other day I was using a lidar sensor has a very well documented API, into its c-library. I do have the source for that c-library, and can build it, but it's calling into the part which doing many undocumented things because the part itself has a micro inside it and it has been updated since the documentation was written. And that c-library comes with a binary file that is filled with micro firmware and magic numbers that were determined by the factory during calibration. I have no idea how those measurements represent or how they were made, not that I can reproduce them anyway. Is this sensor compliant? And, it probably was compliant once, but now is it still? Because the sensor itself changed, even though the C API remained constant. Also, many parts, like this sensor, are made internationally: hardware is from one country, firmware is from another, company headquarters are a third.
bzzzt 5y ago
I think the problem with this kind of reasoning is that need to have a lot of faith in this mythical 'anyone' person to minimally provide you with timely, trustworthy security updates. Bonus points for keeping up with the more advanced features of newer phones. I've got a drawer full of 2000's era 'open source' hardware where the possibility is there but nobody bothered to create a good working operating system.

zsmi 5y ago

I agree with you in principle but I think writing this regulation, in a way that actually solves the problem and is not trivial to work-around, is much harder than you think. Here's an example: The other day I was using a lidar sensor has a very well documented API, into its c-library. I do have the source for that c-library, and can build it, but it's calling into the part which doing many undocumented things because the part itself has a micro inside it and it has been updated since the documentation was written. And that c-library comes with a binary file that is filled with micro firmware and magic numbers that were determined by the factory during calibration. I have no idea how those measurements represent or how they were made, not that I can reproduce them anyway. Is this sensor compliant? And, it probably was compliant once, but now is it still? Because the sensor itself changed, even though the C API remained constant. Also, many parts, like this sensor, are made internationally: hardware is from one country, firmware is from another, company headquarters are a third.

bzzzt 5y ago

I think the problem with this kind of reasoning is that need to have a lot of faith in this mythical 'anyone' person to minimally provide you with timely, trustworthy security updates. Bonus points for keeping up with the more advanced features of newer phones. I've got a drawer full of 2000's era 'open source' hardware where the possibility is there but nobody bothered to create a good working operating system.