Hacker News Reader

"Just about everything you own running embedded software that has some update functionality..."

"Worse, just about all these devices have some access to JTAG ports such that you could easily program them yourself if you wanted to and had something useful to flash them with. I've run into so many products I use on a regular basis with bugs or simple but badly needed features that I could have easily fixed/hacked in with access to the source code but alas, I cannot."

IMO, it is a massive waste. Short-sighted, short-term thinking.

There are people who for whatever reason do not want you to have access to the software ("firmware") and to read/fix/improve upon it.

Some of these people comment on HN. They become active during debates over whether users would derive any benefit from being able to read and edit source code.

The problem seems to be that software is viewed as a trade secret.

Big old companies have CEOs and boards that see embedded software in the same way many legislators and judges see it. Firstly they don't really understand it. But in any case it's part of the product and people have no reason to tinker with it. Now software is being used to enforce what manufacturers could previously have only dreamed of: monopolizing repairs.

With hindsight it seems obvious that things converged onto the embedded computers of consumer products: think microwaves and TVs rather than general purpose computers. The problem with tractors is that all the farmers I know have a much better idea of how a tractor works and how to fix it than the average motorist does about their vehicle.

I am reminded of the era when windscreen-mounted GPS navigation systems started becoming mainstream. Most of the models had very similar hardware but the software was all that differed. I never looked into it but I suspect almost zero had source code published.

To the more typical consumer, the unit is as a whole and the software comes with it. If it routinely takes you the wrong way down a one way street or tries to take you down a set of steps, it's defective and needs to be replaced.

To the more technical consumer it's clear that either the software or the data is at fault and either could be fixed with the right resources. I still feel a sadness at this, yet this waste is insignificant compared to a tractor or any other vehicle.

>The problem seems to be that software is viewed as a trade secret.

Because it is? I mean a lot of the automotive embedded industry is moving toward separation of software from hardware (AUTOSAR Runtime Environment), which is not working as well as expected, because embedded and separating software is a bit tricky. But the goal is to have more suppliers for software than for the hardware. The only trade secret these companies will hold is the software IP.

I think farmers should be able to fix their own equipment, but software being a trade secret is a fact, not something only big old stuffy companies see that way.

The other thing is there are many regulations to comply with. Companies don't want to get sued for some hacks by customers.

The only trade secret these companies will hold is the software IP.

Lots of companies in other industries prosper in that situation, without locking everything down. RHT, for instance, has performed really well over the last year. These software subs could likewise go to a service model or literally anything other than "our software must be installed in crippled fashion". It's not as though e.g. Honda is going to decide to "pirate" their shit.

Not only a trade secret, but also a liability. If source code is disclosed, companies can be accused of copyright violation when some code is similar to an older protected program.

There's another angle - vendors also make money from support contracts, and fear that if they gave you the ability to get support from anyone (even yourself!) they'd lose that revenue stream. For more consumer-oriented products, manufacturers don't want to deal with supporting products that have been modified... (well, they don't want to support them unmodified either, often as not).

I believe the change should start from consumers, especially big institutions. For example, a big municipality or government agency may impose limits on buying new software/hardware that isn't open to refactor/repair by their competitors, to avoid lock-in to a single supplier, operate on more open market, and consequently drive the costs down.

I like the idea. I'm worried that this ship has sailed though as it's becoming harder to even get phones without cryptographically verified bootloaders, and god forbid you want to mess with the baseband/modem source. This is only going to get worse too, as software becomes the part that's actually valuable. AI will mean that everything on the processor will be a trade secret x1000 and everything that can possibly be kept from the local processor will be hidden away in the cloud, forever dependent on continued server access.

>I personally feel that companies should be required to go one step further and be compelled to release their embedded keys and source code for any product that they no longer provide complete support for.

The embedded team where I work struggles with the same thing. Frankly this should be included with the first delivery of any industrial system. Under NDA if they absolutely must, though I don't like it.

I also don't like consumer systems being locked up, but at least it's somewhat defensible. But treating farmers as dumb, inbred "hold my beer and watch this firmware hack" hillbillies and not the educated industry professionals that they are is beyond condescending, disrespectful and is completely indefensible.

Exactly who is deemed qualified to hack farm equipment firmware is something for the farming trade associations and their insurance companies to work out, but as far as John Deere and the regulators are concerned, we're talking about professional embedded developers writing code to run on their equipment to support an industrial process, something that is completely uncontroversial in many other fields. That you're not supposed to intentionally or inadvertently convert your combine into a man-eating killbot is surely already covered by insurance policy clauses, labour laws and public safety laws.

I completely agree with you, but I am a little sympathetic to the "bad PR" angle. It's really, really not that hard to imagine a scenario where a well-meaning farmer (or their contractor) loads something onto the embedded processor that does cause a malfunction, and before you know it there's a splashy news story featuring pictures of a big green tractor not living up to its brand.

I work for a robotics company making indoor self-driving vehicles, and we worry about exactly this issue— from an ROI perspective, our product is a slam dunk, so it's safety and reliability are the first and second most significant questions which have to be answered during the sales process. When we invest substantially in associating our brand with those values, we really can't afford the possibility that an unauthorized user modification compromises them in a way that's outside of our control. Hence closed source, FDE, and all the rest of it.

That is a very specific scenario, but agreements can be made to release software in exchange of loss of warranty and liability protection: I give you the code and from that moment (either if you use/modify it or not) you lose all warranties and can't sue me even if the product burns your house and kills all your kittens.

Losing the warranty is a given once it's been modified.

And obviously before electronic control, there were still a hundred ways you could break any given device and have it generate undeserved bad press for the manufacturer.

But I contend that the scope of things that can go wrong when you mess with the software, and the degree of damage that can be done, are both worse than with purely mechanical modifications. There's huge potential for unintended consequences, and bad press puts the original manufacturer in the awkward position of having to disavow their own product, bearing their symbol, because "the user modified it in an unsupported manner."

All this gets even worse if the manufacturer actively supplies source code and an SDK for making such modifications. How do you delineate supported vs. unsupported mods?

you can't release all liability.

I personally feel that companies should be required to go one step further and be compelled to release their embedded keys and source code for any product that they no longer provide complete support for.

Sounds great, but it's something the abandonware[1] scene has been fighting for over the past 20 years, to no avail.

1. https://en.wikipedia.org/wiki/Abandonware

It's a good idea, so people should keep fighting for it, even if it takes more than 20 years.

I think the difference here is that when it comes to embedded software, very expensive capital can be tied up, as is the case in the above video. Not many commercially available software packages cost >$10k and very few people are exposed to that risk. Meanwhile, there are hundreds of millions of cars in the US.

It'll probably take one generation to raise the issue (and find an example for enough people to care), another to debate, and finally a third to agree about the common sense solution.

So give it another 40 years.

"Nobody is going to try to clone a tractor because they have the source code for it."

Thus is the funniest thing I've read in ages. It's also 100% correct and this whole situation shows perhaps clearer than many, how Stallman's warnings were accurate.

While that is true, i think the manufacturers are more afraid of competitors, which could in some way "clone" at least the software.

I'm doubtful that DRM in any space has ever been about competitors.

> Nobody is going to try to clone a tractor because they have the source code for it.

In the automotive industry, people and companies will do this (at the component level). Enabling features via that the OEM has disabled due to its marked segmentation strategy via aftermarket components is done (and would be done to a greater extend if OEMs did not protect the part of their diagnostic stack that handles feature activation).

For example, XCP or UDS security access modules are sometimes distributed by the Tier 1 as a DLL so that even the OEM has no source code for the concrete authentication mechanism that is used.

Not to defend Deere et al., but one argument I've seen bandied about is that the manufacturers consider their software to be their "secret sauce" value add. If machined steel were all there is, there's nothing preventing the Chinese (or whoever happens to be the current outsourcing bogeyman) from producing perfectly good equipment at a fraction of the price. Personally I'm not convinced this is a really sustainable "moat"; surely the Chinese (boo!) can do embedded programming as well.

That's why a lot of people are advocating for a fair law that forces companies to release sources after a reasonable amount of time or when they cease to support the product, so that they can profit for some years from their IP but users aren't screwed when the product becomes obsolete. And of course being repairable and/or upgradeable means that a piece of technology won't be thrown away.

> embedded field [...] companies should be [...] compelled to release their embedded keys and source code

awesome! my botnet malware that exploits and roots your smart meter or set top box can now install new firmware with a permanent backdoor and nothing will complain because all the malware binaries are signed - by the manufacturer's key, no less - so they must be secure, right?

It would be beyond retarded to use the exact same key for every unit. That's not what people are asking for.

People are asking for keys to their exact units so they and only they can sign software for them.

While GP's snark is uncalled for, he is correct as that's exactly how this works. What you're asking for is like saying that a web server would provide a unique HTTPS cert to every distinct visitor.

>What you're asking for is like saying that a web server would provide a unique HTTPS cert to every distinct visitor.

It's not similar at all. The equivalent would not be the certificate but the session key, and you do get your own session key in order to prevent what the person above is describing. My HN session key is useless for decrypting your HN password even if I could intercept the traffic.

There is no technical reason why the devices can't ship with not only the manufacturer's public key, but also a key pair generated for each unit that comes off the assembly line for the customers to use to sign their own firmware images (and if they wish, delete the manufacturer's public key). But they will never be able to sign images for any device but their own because they simply don't have any signing keys that can produce a signature that will be accepted by any device but their own.