> These secure boot systems exist because of DRM protection to media that is mandated by the content companies.
That statement sounds too simplified. How about non-approved images pumping power upstream above regulatory limit on RF? Or overclocking the CPU? Or reporting all keystrokes to a place of your choice? Would you, as a manufacturer of the device, like to make that easily possible?
> Their point is to verify that the whole OS from kernel to userspace can't be modified by 3rd parties (such as you, the owner of the device).
What makes it impossible is not the secure boot but the fact that the _unauthorized_ 3rd parties don't have the keys for signing stages of the images. Some owners of some secure-boot devices, do have keys and sign their images. One example: a telecom operator, owner of its park of the set-top box decoders, does that. Secure boot can be made to allow several/many authorized keys.
My statement above is simplified, thanks for your additions.
> How about non-approved images pumping power upstream above regulatory limit on RF?
This is possible through other means (you can buy RF chips and wreck havoc on the frequencies). And it's illegal to do so anyway.
>Or overclocking the CPU? Or reporting all keystrokes to a place of your choice?
I, the owner of the device, might want to do this and these are sometimes completely reasonable things to do (if you're a developer, for instance).
> Would you, as a manufacturer of the device, like to make that easily possible?
Probably not, but that goes against the interests of the customer. ("but most of them won't care anyways")
> What makes it impossible is not the secure boot but the fact that the _unauthorized_ 3rd parties don't have the keys for signing stages of the images.
I am completely fine with this if, and only if, I can add my own secure boot keys and sign my own firmwares/OS images which allow.
I, the owner of the device, should be an "authorized" party when it comes to my device.
I am willing to accept that I do not get 8k service from YouFlix Inc if I add my own keys.
I have no problem with secure boot (the technology) but I do take issue when it is used to limit the rights of the owner to their own device.
I actually replied for the sake of technical discussion (secure boot is ~1/10 of what a decent DRM should be, and adding the remaining 9/10 is a huge cost for the manufacturer).
But since you say:
> I, the owner of the device, ...
I am tempted to ask -- how much would you agree to pay for a phone that is working but will never be able to connect to the network (no 4G and no WiFi)?
> ... phone that is working but will never be able to connect to the network ...
If you're implying that devices without locked bootloaders can't connect to RF networks, that's just incorrect. There are lots of devices that aren't locked, and it wasn't a common practice a decade ago.
Why no WiFi? This makes absolutely no sense at all.
4G is also a pointless restriction. It is illegal to connect a device with the wrong specification to 4G networks already. This does not need to be enforced by DRM it is already enforced by law.
Unclear what you had in mind. I'll assume you were speaking about your own secure-booting mobile phone that you paid full price and now would like to be able to reflash?
I am not sure what to tell you. The situation pre-dates the secure boot. If I recall correctly, Iiyama monitors were known to be unrepairable because the manufacturer always refused to release schematics. It did not prevent their extreme popularity.
As an end-consumer, I support very much the freedom to change any products I own, the way I want. I once replaced ball bearings in the drum of my washing machine -- you get the idea.
As a person authorizing a product that can potentially emit unhealthy or unsafe levels of RF, or a parent of teenagers using social media, or a developer of medical applications intended for mobile phone... I am none of that, but I guess I would have a very different opinion.
> As a person authorizing a product that can potentially emit unhealthy or unsafe levels of RF,
This used to be, can be, and should continue to be limited on a hardware level. You can't flash a phone to emit "unhealthy or unsafe levels of RF" if the circuit itself won't let such amounts of power to flow to the radio. Of course, someone could still mess with the hardware itself, but that doesn't scale and (in case of breaking RF limits) is illegal.
> or a parent of teenagers using social media,
This is interesting because, in a way, it's telling me that you the maker of the device are my parent. The argument sounds like, "to prevent your child from flashing your device, we'll prevent you from flashing your device". How about giving me the tools to limit my child's access, if I desire to do so, while not limiting my access?
> or a developer of medical applications intended for mobile phone...
This is a large topic, but to a first approximation, I don't believe a software that cannot be modified by the end-user for health reasons should be allowed on the phone. I also don't believe most medical apps in the smartphone spaces are of this category. The way I see it currently: either accept that some users (like myself) want to have full read & write access to their data on their phones, or make your solution a separate, tamper-proof, black-box device (and get a regulator to rule that for me to open it is illegal).
Maybe not unsafe per se from an emissions perspective, but there are spectrum considerations and other things, and with more and more done in software and less with discrete components, the trend is clear.
Safety is complex - what if the phone starts emitting on bands allocated to emergency services.
> As a person authorizing a product that can potentially emit unhealthy or unsafe levels of RF, or a parent of teenagers using social media, or a developer of medical applications intended for mobile phone... I am none of that, but I guess I would have a very different opinion.
Let's be honest and accept it's just about money and control to the makers of these devices. They will bring reasons such as these in their defense, but really they just want to keep the user from being in control of their device and e.g. making tracking them more difficult. I mean there have probably been tens of thousands of roms flashed on different devices. How many of them have emitted unhealthy levels of RF? And parents could retain the ability to flash their devices without giving that ability to their children. The reasons really just don't hold any water imo.
> Let's be honest and accept it's just about money and control to the makers of these devices.
Agree. My point is that less control for manufacturers over the image presumably will lead to lesser profits. My illustrations might be more or less relevant, depending on the standpoint.
>I am not sure what to tell you. The situation pre-dates the secure boot.
That's an invalid argument. It doesn't matter how long this has been the case.
>As a person authorizing a product that can potentially emit unhealthy or unsafe levels of RF, or a parent of teenagers using social media, or a developer of medical applications intended for mobile phone...
You're presuming this is the only and the correct way of handling this. That is, you're arguing it is the manufacturer's affair and right to restrict one's basic rights to enforce lawful handling of their product.
I'd rather argue that in reality the manufacturer's main interests lie in reducing support costs and the enforcement of their patents and copyrights.
> You're presuming this is the only and the correct way of handling this. That is, you're arguing it is the manufacturer's affair and right to restrict one's basic rights to enforce lawful handling of their product.
This is not really what I said (somehow people focus on the second part), but I do believe that offering this freedom (to install any image) will lead to lesser profits for the manufacturers. Quite possibly because other potential customers might find this feature unacceptable (my illustrations may be good or bad). That is, your personal freedom runs into someone else's. Then the market should decide, right?
> I'd rather argue that in reality the manufacturer's main interests lie in reducing support costs and the enforcement of their patents and copyrights.
Yes. Add there loss of face in case of hostile hacking. Etc. Since when this is condemnable?
Do not confuse the tools businesses are provided by the law with the interest to profit. For instance, 10 to 80 years long copyright terms after death are not your inherent rights as a creator but tools the current legal infrastructure offers. Hence it is not the only solution.
>This is not really what I said (somehow people focus on the second part)
No, you did, and the market decides only a share because it is already affects by numerous direct and indirect regulatory measures, e.g., patents. In the past explicit enforcement of the right to repair was rarely an issue for consumers just as net neutrality had not been a serious issue. This has obviously changed.
Having worked with DRM for 10 years, I can confirm that while very simple, that statement is entirely correct. He says this is the reason the secure boot process exists, not that this is the only benefit.
> How about X, Y, Z
Those scenarios certainly benefit from a secure chain of trust but they are not what brought it about. The whole secure boot chain exists because of companies that require DRM to access their content.
Samsung wants Netflix to play the best content on their devices. That's the only motivation that has ever mattered to device manufacturers.
didn't iphone 3g did that? it was alwas a few W over what the spec and regulations called for to steal better reception than other devices around it. nobody was punished and it actually become the norm.
That statement sounds too simplified. How about non-approved images pumping power upstream above regulatory limit on RF? Or overclocking the CPU? Or reporting all keystrokes to a place of your choice? Would you, as a manufacturer of the device, like to make that easily possible?
> Their point is to verify that the whole OS from kernel to userspace can't be modified by 3rd parties (such as you, the owner of the device).
What makes it impossible is not the secure boot but the fact that the _unauthorized_ 3rd parties don't have the keys for signing stages of the images. Some owners of some secure-boot devices, do have keys and sign their images. One example: a telecom operator, owner of its park of the set-top box decoders, does that. Secure boot can be made to allow several/many authorized keys.