[wegs]

Let's work through this example. You're a manufacturer of devices using FTDI chips. You make an emergency system for airplanes which e.g. releases breathing equipment, or life rafts, or similar. Or a backup avionics system. Due to a supply chain slip-up, a small number of counterfeit devices slipped in.

An emergency comes up, and the instant the emergency system comes up, it turns out to have been bricked. People die. Is this a good outcome?

If I were a manufacturer, I'd want to know about this ASAP. Would I want devices to stop working? Especially the examples you gave where people's lives are on the line? Absolutely not. I'd want them to work as well as possible until a replacement can go out.

Pro-consumer would be a pop-up letting the user know they received a counterfeit devices. I can then contact whoever sold me the device, and ask for a replacement. During cross-shipping, I can keep working. Anti-consumer is having my business trip and fall on its face when all the pen tablets which allow people to work from home are bricked during a pandemic.

Of course the counterfeit manufacturers are the bad guys. But FTDI is a company I'd never do business with either. If I'm an FTDI partner, and I got the wrong product, we were both cheated. I'm no more at fault than FTDI.

Should FTDI smack me and my customers upside the head for it? Well, that means we're not really partners.

[robomartin]

You are making the mistake of arguing against a hypothetical. It's just a fabricated example to convey an idea, not something to argue against. As an aerospace engineer I assure you that sourcing components for aerospace isn't as simple as your hypothetical to my hypothetical.

> Pro-consumer would be a pop-up letting the user know they received a counterfeit devices.

This from driver code?

The party at fault here is whoever sourced the devices. If the design engineer called for FTDI and they put in FunTDI instead, well, they didn't build what they were contracted to build. Period.

Something as simple as a driver revision to, for example, improve performance, could break a fake chip. Is the legitimate manufacturer supposed to now be aware of every fake and design their drivers forever more to ensure fakes work perfectly? C'mon, that's preposterous.

If I design a board and someone decides to use a cloned version in their machine and somebody gets killed because of a software update I can assure you that the case wouldn't even get to court. The instant it is discovered that the board was a fake the entire thing would be thrown out. There is no way anyone is going to hold the manufacturer responsible for ensuring that clones work property. That is not what they are in business to do.

[leoedin]

About 7 or 8 years ago I built an internal testing system used to test a satellite payload which used a microcontroller board from a reputable manufacturer, purchased through a reputable electronics supplier.

When we updated the ftdi driver, the board was bricked. Fortunately the system was still in development so we found a different board - it was only a bit of pain.

However, if that system had been shipped (as it was 6 months later), that board being bricked could have had much more significant ramifications. It would have caused a slipped schedule and tangible costs.

What should I have done differently?

[robomartin]

You would have to explain the degree to which parts were traced, certified, tested, etc. If you simply trust the supplier and distributor anything could happen.

I mentioned in another thread that we had one of the top two US electronics distributors knowingly ship us low "B" grade components many, many years ago. These components were in allocation and an enterprising young man at the distributor thought he would be smart and ship us a lower qualified component instead of what we ordered. That was twenty years ago or so. It cost our company dearly, nearly took us out of business.

This was that learning moment for me and it changed my approach to sourcing as well as the level of trust I grant anyone providing us with components. I will never put anything into a design where an illegitimate or lower grade component could jeopardize the safety, reliability or operation of the system.

At some level this is what engineering is about, isn't it? It's that old "Trust but verify?" concept.

We are working on industrial, flight (aircraft) and space (lunar) projects at the moment. No component will go into any of these systems without full knowledge and verification of its origins. This is true for individual components or contracted sub-assemblies.

BTW, this issue of failures being caused by not verifying components isn't anything new. The history of engineering is full of examples. One reasonably recent example of this happened to SpaceX a number of years ago:

https://www.space.com/29994-spacex-rocket-explosion-cause-fa...

[wegs]

No. This is not what engineering is about. Engineering is about making reasonable design trade-offs. Simply throwing dollars at a wall without doing an ROI estimate is called overengineering, and overengineering is bad engineering.

For reliability, where that trade-off sits depends on the application. Aerospace, medical, consumer electronics, and disposable toys will sit in different places. If I lose a mission to Mars saving $100 on part which had a 5% chance of failure within a year, that's very poor engineering. If I include that same part in a $3 toy, bringing the price to $103, that's equally poor engineering.

Whether I trust or trust-and-verify depends on how much the "verify" part costs, how strong my trust is, and what the costs of failure are. Normally, the ROI calculation is easy; capitalist markets work well for this. I can ballpark expected costs.

When working with a customer like the government, the boundaries might be a little bit distorted, since the customer is process-oriented. The government might have a hard salary cap which makes it impossible to bring in qualified engineers, and I might take 3 years with a team of 5 people at $100k to do what one person at $300k could do in 6 months. At the same time, I might have hard requirements on process, such as origin-tracing every part.

The danger is when that becomes in-cultured and spills over to other places. If I'm working for the government, I'll follow government processes, and I understand why those are there. But I won't confuse those processes with good engineering. Once people do, they become poor engineers.

If I've shipped a toy which unwittingly has thousands of fake parts which I thought you made, we'll both have been cheated, and I'll expect you to solve that with me cooperatively. If you hack into my product and brick it, even if you were legally in the right (and you're not), you've lost a customer. That's bad business too.

[wegs]

Your hypothetical was lousy, I agree, but if you're going to hinge your argument on a lousy hypothetical, I'll push back on that hypothetical.

To answer your questions:

(1) Yes, driver code can do things like this. If you don't believe me, buy an HP printer, and see the driver code pop up all sorts of advertisements, deals, and other crap. Driver code has access to your system's low-level internals. From there, it can do whatever it likes.

(2) The parties at fault here are multiple. One of the keys to building robust systems is to understand failures can take place anywhere in the system. In medical device, the terminology is "single point of failure." If one failure can kill a person, a medical device won't be certified by the FDA. In the same way you want the hardware to be tolerant of a single-point-of-failure, you want your organizational processes, logistics, etc. to also be tolerant. Mistakes will happen, and when they do, people shouldn't die.

(3) No one would hold FTDI responsible for making sure clones work properly. Plenty of people would hold FTDI responsible for intentionally attacking my hardware because I had a clone, if things go wrong. Two wrongs don't make a right. There is plenty of case law around this. Here's a nice chain for you to go down to get you started:

https://en.wikipedia.org/wiki/Sony_BMG_copy_protection_rootk...

https://www.cs.uaf.edu/~cs393/CACHE/Wired_RIAA.pdf

If FTDI's drivers stop working with my device incidentally, they're not responsible. If they intentionally brick a piece of hardware I own, for any reason, including believing I violated or contributed to a violation of their IP, that's a pretty clearly digital trespass under CFAA.

Would I pursue FTDI for breaking a cheap consumer device? That's not worth anyone's time. Had it, as in your example, killed someone or took down a planeload of people, you can bet your butt there would be both civil and criminal prosecutions for stuff like that.

(4) Any regarding supply chains, whenever I've done this, I've worked for small companies that wanted to keep logistics simple. We'd try to make sure complete designs could be sourced from one distributor (usually Newark, sometimes Digikey). And no one had resources to do any kind of tracing of parts. I understand that's done in aerospace, but that's not done in hardly anything else.

If there's some mixup in the supply chain, and I've shipped a thousand consumer widgets with a bad FTDI chip, FTDI should go after the parties responsible: my distributor, and the pirate company. Not me. Not my customer. And it should do it properly through the legal system and pursue damages, not break devices vigilante-style.