Comment by john01dav | Hacker News Reader

Comment by john01dav | Hacker News Reader

Parent Full thread

I want regulation that divides all software into two categories: part of the hardware, or not part of the hardware, with specific requirements.

Part of the hardware:

- Can be restricted to specific devices

- Must be available under GPLv3, including anti-tivoization provisions (forced bootloader unlock)

- May not attempt to use TPMs, DRM, or other systems to support assertions about client devices

Not part of the hardware:

- May only interact with hardware through public, documented, APIs in the "part of hardware" category

- Using alternatives from competitors must be fully supported

- When made by a company that also makes hardware, must also work on competitors' hardware (at least one, more if technically feasible)

- May be under a proprietary license

- Must not attempt to assert anything regarding the hardware, so things like Google Safteynet are now illegal. Security boundary must be shifted to consider client devices insecure

This is, I think, a good compromise to allow software developers to get paid without taking away ownership of hardware devices. Developers can be paid for "part of the hardware" software with money from selling the hardware, and "not part of the hardware" software can be trivially commercialized under a proprietary license. But, there is no way for a user to end up unable to control their hardware, or incentivized to configure it in a specific way.

Unfortunately it's never going to happen.

Also, things like TPMs, Secure Boot, etc, are good security tools which can be used by an end user to get security guarantees over their device.

I use Secure Boot with Linux because, when done right, it means you can get full disk encryption without gaps (at best, without secure boot, you have an un-encrypted bootloader on a flash drive which decrypts your disk and boots your machine, and this is a clunky setup).

I use GrapheneOS's hardware attestation to alert me if something compromises my android phone's operating system.

Now it's true that these features are abused by companies like Google to force you to run a blessed Android build if you want to use e.g. Google Pay (which is the only mobile payment option in e.g. the UK). But it's important to separate the technology from the bad actors abusing it.

The difference is you using the tpm feature and anyone else using the tpm feature. The feature can exist as long as it's only there for you not for anyone else. You can satisfy yourself that no one has hacked your device. Your bank can not satisfy itself that they have ultimate control over your device instead of you.

The described mechanism doesn't say the hardware features can't assert the software features, only the other way around: the premise was merely that the software features need to be replaceable; in fact, this is exactly what you want, as it ensures that the mechanism in the hardware providing the secure boot feature is open source and it also ensures that the operating system you run is anything you want, rather than being locked into a specific choice by the maker of the hardware (or, if the people who make the hardware want to ship an OS with the hardware as if it were some kind of cohesive product, then that OS would also have to be open source and modifiable, which is how you can get a GrapheneOS in the first place).

That's a good idea in spirit but seems a little over complicated to me. I think it might be simpler to just categorically ban any and all technical measures designed to prevent users from controlling or modifying software on devices that they own. Distributing binary code without the source and build tools would count as such a technical measure. This would be an even more radical change in many respects, but also a lot simpler and more principled.

Curious to hear if there are any unintended consequences to this that I may not have thought of. Think of this as a strawman proposal.

> ban [...] technical measures designed to prevent users from controlling or modifying software on devices that they own

Is this legal ownership or technical 0wnership?

You'd need to define "technical measure", or you'd have endless litigation to do it in courts. Trying to define that reasonably precisely is how I came up with my proposal.

I think that it might make sense as a kind of certification that can be available for computers that follow these specifications. However, it will need to be changed a bit; one change is that the division as part or not part of the hardware is not good enough and there should be one in between. Most of it looks like good, though.

What would this third division consist of?

Do you make any carveouts for software meant for game consoles, like the playstation 5?

No, I explicitly want the game console business model to be shut down. As it stands now, they sell hardware at a loss to then extract value later, at the cost of user control over what they bought. I'd like to see consoles cost what they really do, and then the same for games. I also don't like how restricted it is to make games for consoles nor do I like games being exclusive, since this blocks competition between consoles on their own merit. If a user wants to pay less upfront and more later, then we have a tool for that. It's called financing.

Why does it bother you if people who want game consoles buy them?

Non-transparent pricing (or non-transparent anything) makes a market worse/less efficient. Regulation to make things more transparent is always better for all good-faith market participants.

I'm not convinced that the average customer of consoles is considering the tradeoffs fully, and even if they are it distores the market away from freedom since the average customer doesn't see the long term effects of freedom being restricted.

Why? If Sony is loosing money on selling these devices, they should perhaps just raise the prize. Why should we make carveouts to allow companies to compete on the market unfairly and to lock in customers?

Reply on news.ycombinator.com