That is indefensible, regardless of whether it's right or wrong to use counterfeit parts.

As an embedded medical devices engineer, I know you are exactly right. For safety-critical devices, control of the supply chain is beyond good practice, it's required by federal law, precisely so bad actors can't interfere with peoples' lives. The long list of requirements around approving a vendor are tiring and result in epic stories like the $500 toilet seat, etc., but they prevent stuff like this FTDI debacle from happening. You know it's going to be a toilet seat when the box arrives.

The medical device industry is a massive cultural shift from the majority of the HN crowd (e.g. startups and cloud services). In the world of PCs and servers, disruption is, literally, the name of the game. In IEC62304 land though, everything has to be on the straight, narrow and predictable path. This is why medical devices are expensive, laggy and not very startup-compatible. The FDA's system is actually more secure than Europe's. Take that, socialized medicine!

So it's not always wild and fun here in medical-land. It's like being a cop vs. a cowboy. You're not paid to sling your guns, but to de-escalate. But thank the conservative practices next time your elderly or congenitally defective family members found themselves in the hospital!

We already have fitness devices that can communicate with a PC. Is it really unthinkable that the next batch of medical devices will do something similar? For example, a wearable sensor to continuously measure your insulin levels?

Will you be using an FTDI chip in such consumer devices?

Yes, exactly.

I used to work at a sub-contractor for a large manufacturer of medical equipment, and all the systems we dealt with were like that. The device would run a very small embedded OS but would have a serial port for talking to a PC for firmware development, firmware updates, logging, diagnostics, etc. Their older stuff used real hardware serial ports, but their newer systems (~6-7 years ago now) were moving to virtual USB/FTDI serial ports, with an FTDI chip included in the embedded system.

These tricky FTDI drivers would absolutely have the potential to brick and/or alter the operation of such a device; it's not far-fetched or a flight of fancy at all.

I have a special interest in this thread/issue because I have recently been contacted by that manufacturer regarding one of these FTDI-using systems which has recently begun to exhibit new problems. I haven't started looking into that yet, and I don't know where it will lead, but I'll have to bear in mind the possibility of deliberate driver-based monkey-business now.

So what if all of your preproduction systems have a genuine FTDI chip in them, and many of your millions of deployed production systems have counterfeits that you don't know about? That'll be exciting.

Quality is a matter of defense in depth. You can't rely on your preproduction system running the exact same way as production. You strive for consistency, but ultimately each chip in each computer is a unique physical object made with different silicon crystals, and being identical is impossible. You want a system that's robust against a variety of subtle differences.

FTDI is just doing their small bit to make everything just a little more fragile and unpredictable where their chips are concerned, and as such their products ought to be shunned.

I agree with your premise, but in this case, for a medical device it would also be a Quality Systems failure. Any change in a component is scrutinized and analyzed for impact. You have no idea how many times (as a software dev for medical devices), I've had someone from Manufacturing or Purchasing come to ask me "if we change (trivial part X) to a new vendor, what can go wrong and how can we test it?" as a precursor to executing a Change Plan.

I'm not kidding. Even something as seemingly trivial as changing the type of paint used on an enclosure can trigger weeks or months of analysis depending on what's in that enclosure.

Safety-critical and safety-related applications are a totally different game than what most HNers are used to!

It's clearly unsafe to not wear a seatbelt, but it's also clearly wrong to build a device into cars that kills occupants that get in a crash if they aren't wearing one.

I agree. I don't want to put counterfeits in my product.

Now, show me FTDI's standards documents that indicate how to identify and test for fakes. (Hint: they don't)

As far as I understand, this "behaviour" is totally deterministic and certain. You immediately notice the problem in any test system.

Don't believe that safety-critical devices are allowed to install some drivers willy-nilly!

And when QA validates them on a set of systems that happen to be legit and ships it to systems that happen to have counterfeits?

You seem to be arguing in this thread with a false dilemma between EITHER we must accept counterfeiting OR we must brick the chips, but there are in between measures that are way safer.

Prior art: Several versions of Windows have been able to detect if they were "genuine". Non-genuine windows did not brick their machine, or destroy themselves. Quick googling suggests it blocks you from getting updates, and pops up with links to a page on Microsoft where you could properly license it with some discount. That exact solution may not apply here, but there are options other than destroying hardware that is carrying your name.

(I mean, this isn't even good for FTDI... how many customers will never find out about this and simply learn that "FTDI chips spontaneously die a lot"? Not the brand experience I'm looking for!)

FTDI does not provide any guide lines to third parties how to test whether their chips are counterfeit or not.

The only way to test it is trying to use it with FTDI's Windows driver, and FTDI randomly changes the both the detection criteria, and the action done on detecting a counterfeit chip – sometimes it bricks them, sometimes it sends gibberish, you have no way of knowing beforehand. FTDI doesn't even guarantee that this behaviour is deterministic!