[LeifCarrotson]

> A big one is that the firmware is the piece that not only interacts with but also protects the hardware. If you are easily able to change the firmware, you are easily able to destroy the hardware, and if that's under warranty, companies are going to be concerned.

Is that justifiable, though? I bricked a router some time ago messing around with ddwrt. I thought about soldering on a TTL serial adapter, to recover it, but didn't end up getting around to it, but never in my wildest dreams did I think of asking Netgear to replace the 8-year-old product I broke through my actions. I do know at least one person who is reckless with "no questions asked" warranties, and would ask for a refund with a straight face after trying to use a router to reduce spaghetti sauce spattering when he microwaved his dinner, but these people can't be that common...

One area where it does seem slightly more justifiable is FCC-certified radio devices. If the transmitter power level is restricted by law, I'd prefer that end users/modifiers of the firmware be considered legally responsible for the consequences of their own actions, but I understand that pragmatically it's a lot easier to ask OEMs to lock down firmware after getting certified in a test lab than to monitor a million end users.

[petsfed]

>I do know at least one person who is reckless with "no questions asked" warranties, and would ask for a refund with a straight face after trying to use a router to reduce spaghetti sauce spattering when he microwaved his dinner, but these people can't be that common...

There's common, and then there's common-enough-to-be-costly. REI had a notorious lifetime-return policy that they ended relatively recently because of abuse. How common was the abuse? No idea. I don't know many people who would Return Every Item (as the joke went), but it was common enough that there was always some really beat-up climbing shoes at their member garage sales.

And anyway, there's (at least) 2 kinds of costly: cost of returns, and cost to reputation when unqualified people brick their device, then tell all their friends that their router/refrigerator/laptop stopped working.

[jancsika]

> I don't know many people who would Return Every Item (as the joke went), but it was common enough that there was always some really beat-up climbing shoes at their member garage sales.

I think you chose an idiosyncratic case here. There must be a significant number of their customers who go there to get fully outfitted for a single, relatively short trip.

If you depend only on shame to keep most people below the age of, say, 30 from returning a rent check's worth of camping gear after a single use, well... as you stated REI no longer allows that. (IIRC that happened shortly after the 2008 downturn).

[petsfed]

It happened at least after 2013, because I went skiing with a guy who made it a point to return everything he'd ever bought from REI because of a court case he read about. It was a sort of super-boycott.

I chose an extreme case, because the cost is clear, and the consequences are very visible. Obviously, a company's peculiar financial situation will determine the acceptable return-and-refund/replace rate. Every company will have a financially acceptable return rate, and will look for easy fixes to keep their actual rate below that. Barring replace/refund for user modifications is a way to lower the refund/replace rate, without actually decreasing the number of items that get returned. There's still a cost to inspecting devices for user modifications, and that cost may in turn lower the acceptable refund/replace rate, but it does mean the product development people have to spend fewer resources eliminating potential sources of failure

None of this is to say that I think firmware shouldn't be field editable. Just that barring those sorts of things is low-hanging fruit and (in general) pretty easy to sniff out if the device is just bricked, not permanently damaged. I think manufactures could instead enable firmware updating after cutting a particular trace, to the same effect. Thus, the would-be hacker must knowingly physically damage the product in a way that clearly voids the warranty, and then they're free to modify to their heart's content.

[VLM]

I was messing around with an I2C controlled lithium battery charger on a raspi last night (long irrelevant story) and found out it does NOT support "fast charge" (probably not enough thermal monitoring?) but it does support larger capacity batteries that coincidentally permit higher currents. So the short version is I can charge a battery twice as fast by lying to the charge controller that it's twice as large. On average, probably 99% of people can get away with that, the problem is 1% set the battery on fire or otherwise burn out the battery.

No matter how smart you make the controller you can't outsmart the user; to the battery charge controller, a 1 aH battery being treated as a 2 aH battery behaves like a 2 aH battery that's at 50% capacity due to age or whatever issues.

I would imagine, as long as I can keep it cool, I could install a 50 mAH micro battery and tell the charge controller its a 2 aH battery and it would charge very fast indeed. Perhaps only once, but it would be very fast. I suppose the worst case scenario is some kind of virus/cyberattack reprograms the FW to believe the battery is either 65536 mAH or 1 mAH, either way the battery would appear "dead" to end users.

Another common problem is marketing and mgmt may be a LITTLE over optimistic about a feature; imagine if your IoT cigar humidor (made up idea; probably does exist LOL) has a hardware barometric sensor on the I2C. I2C is famous for dodgy hardware being able to 'jam' the bus. Ah no problem nobody needs a baro on a humidor anyway, we'll just delete it from the marketing materials and remove it from the firmware, no need to e-cycle otherwise good first batch of boards. Well if someone uploads custom firmware and the baro is polled every hour and it randomly jams the I2C once every hundred polls, "must be a thermal issue the CPU crashes" nobody might ever understand the problem. I mean, its gotta be a hardware bug worthy of a return, everyone knows if the code compiles and passes unit tests and works for a couple minutes, it must be good, right? But if the I2C protocol is interrupted due to a wifi interrupt in the middle of whatever it crashes the whole bus so randomly every couple weeks it locks up.

Some big expenses are not brick fails but "it burst into flames while on an aircraft" or "everyone knows the hardware locks up randomly every couple weeks" causing all kinds of crazy bad PR.

Then there's interference with marketing models. Well, technically the hardware for rev1 and rev2 are the same, its just rev2 has more features because we eradicated bugs, so please pay us again, don't just download new FW.

[nine_k]

Nit: it's Ah (A•h) and not aH, because Ampere (the A) is from Henri Ampere, and the h is just the inanimate hour.

A proper SI interpretation of aH would be atto-Henry, where Henry is the unit of inductance (from James Henry), and atto is 1e-18.