←back to thread

2071 points K0nserv | 10 comments | | HN request time: 1.032s | source | bottom
1. kylecazar ◴[] No.45088315[source]
It's a matter of ownership vs. licensing. You own the hardware you buy, but you license the software. I agree with the author that as long as you use that software, you should be subject to the constraints of the license.

The key is that if you choose not to run that software, your hardware should not be constrained. You own the hardware, it's a tangible thing that is your property.

Boils down to a consumer rights issue that I fall on the same side of as the author.

replies(4): >>45088369 #>>45088472 #>>45088572 #>>45089149 #
2. EvanAnderson ◴[] No.45088369[source]
The hardware should not be equipped with undefeatable digital locks. Put a physical switch on the hardware (like Chromebooks have-- had?) to allow the owner to opt out of the walled garden.

Also worrisome are e-fuses, which allow software to make irrevocable physical changes to your hardware. They shouldn't be allowed to be modified except by the owner. (See Nintendo Switch updates blowing e-fuses to prevent downgrades.)

replies(1): >>45088935 #
3. hibikir ◴[] No.45088472[source]
When the hardware is complicated enough that the software required to run it al all would take many millions of dollars to replicate, hardware freedom alone doesn't cut it. Just like a modern processor needs mountains of microcode to do anything you'd actually want. And that's without companies needing to obfuscate their hardware to avoid interoperability they don't want.

In practice, a whole lot software would have to be open source too so that the hardware is reasonably usable. The layers you'd need to let an iPhone run android well, or a Pixel phone to run iOS are not small.

4. glitchc ◴[] No.45088572[source]
First, we had bespoke computer systems where the hardware and software were tailored to solve specific problems. Then, as computers became commoditized, the hardware was more standardized and software interacted with it through an abstraction layer. Now, we're circling back to heterogeneous hardware where software and hardware are tightly coupled for the best performance and power efficiency. Of course there's always a trade-off. In this case, it's flexibility.

The smartphone does not consist of just one processor, it's a collection of dedicated processors, each running custom algorithms locally. Sure, there's software running in the application layer, but it's playing more of a coordination role than actually doing the work. Just think of sending a packet over the internet and how different it is between a smartphone and a computer, how much more complex a cellular modem is compared to a network card.

It's less about software now and more about hardware accelerated modules. Even CPUs run primarily on microcode which can be patched after the fact.

These patterns are cyclical. It will take a number of years before we return to standardized compute again, but return we will. Eventually.

5. charcircuit ◴[] No.45088935[source]
E fuses are needed so people can't downgrade the device to old insecure software to exploit it. Without it or an equivalent like a secure monotonic counter how do you think such attacks be protected?
replies(2): >>45088949 #>>45094829 #
6. SchemaLoad ◴[] No.45088949{3}[source]
There's a disagreement on who the attacker is. From Nintendo's perspective, the owner of the device is the attacker. From the owners perspective it's Nintendo.

Obviously the parent commenter believes you should be able to exploit your own device and downgrade the OS if you wish.

7. bccdee ◴[] No.45089149[source]
That's an oddly legalistic line to draw. What if they start licensing the hardware too? Surely if we care about users being respected by technology, the line between software and hardware or between ownership and licensing is immaterial. These are all excuses to deny users the opportunity to do things they should be entitled to do, like installing arbitrary applications.
replies(1): >>45092551 #
8. kylecazar ◴[] No.45092551[source]
Well, the line is drawn by the fact that hardware and software have intrinsic differences. It sounds like we're on the same page about hardware -- with the software, should we not be bound by licenses in client/server services (phones, consoles)? You are using someone else's service with others, for some collective benefit like playing a game, and being bound to constraints on that software doesn't seem that offensive. Modified clients can piss in the pool for others using the services and affect the network's quality.

Again, if you want to run purely OSS software with permissive licenses, that should be your prerogative. But you might miss out on the Play store. If you want to mess with Valve anti-cheat, you can't connect to Steam games online. Etc. I think these companies do have a right to dictate software requirements for client code accessing their servers.

But, you should be able to wipe those clients if you don't care about them and play tux racer on Arch.

replies(1): >>45095398 #
9. const_cast ◴[] No.45094829{3}[source]
Is this is a real threat that's actually happening on a scale that matter or moreso a make believe type thing?

Because I can do make believe type arguments all day. We should lock everyone up, because what if a super astroid hits the Earth and only prison is strong enough to protect them??

See, easy, and kind of fun. Doesn't mean much though.

10. bccdee ◴[] No.45095398{3}[source]
> Well, the line is drawn by the fact that hardware and software have intrinsic differences.

Do they? Is microcode hardware, or software? If I open up the plugboard on my IBM 407 and rewire the connections, am I updating software or reconfiguring hardware? I think this is a false dichotomy. Software or hardware, kernel or userspace, these are all just parts of a machine. I care about the holistic behaviour of that machine, not about which specific parts do which specific things.

> But, you should be able to wipe those clients if you don't care about them and play tux racer on Arch.

I don't need to play tux racer. I need to use my bank.

> I think these companies do have a right to dictate software requirements for client code accessing their servers.

They're not just dictating the requirements of the client code, they're dictating requirements for the entire execution environment. Following your logic to its conclusion, if I'm going to do banking from my phone (and that's a foregone conclusion), I have to have to cede that bank the right to veto any other piece of software from my phone.

I could buy a second phone, because I'm a relatively affluent software developer, but most people have neither the money nor the energy to buy a special phone for banking. They'll just let the bank control their phone. I consider this is an unacceptable abridgement of their freedom.

I have no problem with Valve anti-cheat, so long as it's reasonably permissive. Valve anti-cheat won't stop me from installing my own software. I'm not drawing a hard technical line here; there's a grey area of reasonable integrity provisions. Sideloading restrictions in Android cross well beyond that grey into the black.