4 ms·

Pretty typical HN over-reaction. Why not wait to hear from FTDI before joining the lynching mob? If the driver broke clones without the express intention to c

Pretty typical HN over-reaction. Why not wait to hear from FTDI before joining the lynching mob? If the driver broke clones without the express intention to cause damage, well, tough for the clones. If, on the other hand, they set out to actually cause damage they are out of business or will suffer greatly. There's another angle here. I'll use a hypothetical. Say your chips are being used on MRI machines, cars, planes, glucose meters, ATM machines and a whole host of other mission critical systems. And you know clones are dangerous because they are unreliable, failure prone and nondeterministic in some way. What do you do? What should you do? Bricking these devices without warning would be a bit extreme, agreed. What if you figure out a way to ensure that legitimate chips work and others fail in whatever way based on the nature of the cloning design. Is that OK. What if people could die? Not trying to be dramatic at all. Just saying that sometimes you need to be in someone else's shoes in order to understand their ecosystem and have context from which to understand their decisions. I've been using FTDI chips since they came out. I have designed products that could kill people and burn down buildings if they were to fail in certain ways. We bought these chips through proper distribution channels. Had we not or in the case of our distributors being duped by clone makers I'd much rather our devices be bricked than risk someone getting hurt. So, yeah, this is very real for me.

pessimizer 12y ago
>And you know clones are dangerous because they are unreliable, failure prone and nondeterministic in some way. Is there any evidence of this?
conductor 12y ago
Here is their response: https://twitter.com/mikelectricstuf/status/524917368154492929 https://twitter.com/mikelectricstuf/status/52491736815449292...
icebraining 12y ago
Say your chips are being used on MRI machines, cars, planes, glucose meters, ATM machines and a whole host of other mission critical systems. First, that's a red herring because most of those machines aren't running Windows, let alone with automatic updates. Second, you're essentially advocating vigilantism by corporations. If FTDI was actually concerned about the lives of people due to faulty chips - and I find this supposition laughable, but let's go with it - they could have (1) warned the users, (2) disable the driver and/or (3) contact the appropriate official institutions. A supposition that someone, somewhere might die does not justify unlawful destruction of property, and if proven that FTDI intended to brick those chips, I hope they get sued hard.
- robomartin 12y ago
  > First, that's a red herring because most of those machines aren't running Windows, let alone with automatic updates. Are people on HN wound up so tight that all imagination is lost? These are HYPOTHETICAL EXAMPLES used to illustrate mission critical applications. And be careful about making assumptions about critical systems not running Windows. You'd be surprised. Sometimes vendors don't have a choice. If you are working under a contractual obligation to use Windows, well, that's what you use. For example, what do you think you might find in a huge array of military Command and Control centers? Yup. You also seem to be ignoring the fact that FTDI chips typically go on all kinds of embedded systems that are attached to a computer for tasks that have nothing to do with their mission critical nature. For example, we built a dedicated FPGA-based target tracking system used in such places as White Sands Missile Test Range that was entirely self contained. It has an FTDI-driven serial port for firmware updates and configuration. Don't assume that everything related to USB requires full time connectivity like a keyboard or a mouse. Another example is an extremely high power LED system with over 1,500 W of LEDs (much more, but that's all I can say). FTDI-powered USB is used to control it in real time. And, yes, a Windows application is at the other end. That was the spec. And, yes, it has error correction code and a dedicated communications protocol that ensures a certain degree of safety. If that chip is a fake there is no way to know what other "features" it may have. Again, the HN mob is quick to be judge, jury and executioner. That's to be expected. Until most of the HN crowd has another decade or two under their belt emotion will drive a lot of the thought processes. I get it. If FTDI truly intended to cause harm, of course they deserve to be sued out of existence. What kind of a moron would not agree with that. If, on the other hand, the issues are a side effect of code that is so fine-tuned to their devices that bad clones fail, well, that's not their fault. I need to go dig-up the official FTDI position on this, everything else is bullshit and conjecture.
  - deleted 12y ago
    [deleted]
  - icebraining 12y ago
    To be clear, I wasn't accusing FTDI themselves of anything. I was purely arguing to your hypothetical example, in which they did intend to brick chips. If you didn't want to argue that position, you shouldn't have made a post arguing it. Kindly redirect your anger against the "HN mob" somewhere else.
mikeash 12y ago
If your stuff is really that critical, wouldn't you rather they tell you that you have a fake, rather than just brick it mysteriously and leave you to figure out the reason on your own?
- robomartin 12y ago
  In order to understand this you have to take a deep dive into the sometimes-murky world of electronic component sourcing. Even when buying from top tier distributors in the US there's potential for getting less-than-wholesome product. The legitimate product manufacturer would have no way of knowing who got what. The best anyone can do is issue a notice like auto manufacturers do for recalls advising you that fake chips may have gotten into the system. Now think about how you might react to that. Externally the chips look exactly the same. Depending on the nature of the organization you might choose to scrap your entire inventory or setup a testing system or. In the case of larger scale production you could very well have 100,000 units of your product manufactured before you can even consider reacting to the news. Once the product is in the market your choices are greatly reduced. Scale is a huge factor. We can send engineers to every single one of our installations to manually swap chips. I did the math, it would probably cost somewhere in the order of five million dollars to do so (travel, time, tools, loss of business, etc.). Well, we can't do that. Few businesses can burn cash like that. And, of course, there's the issue that we might waste millions of dollars swapping out good chips. In this context it is far easier if devices with fake chips stop working and a normal process is used to fix them. You remove liability and quickly identify the clones. In consumer land things are different. There is no sensible way to deal with 100,000 or 1,000,000 units of a product that may have some bad chips. Yes, you probably don't want those devices bricked on purpose. However, if you are operating at that scale you are also responsible for ensuring that your supply chain is not shoving fake or out-of-spec parts into your products. Easier said than done. This isn't the only fake electronic component made by crafty Chinese manufacturers. In that regard this isn't a revelation at all.
  - mikeash 12y ago
    I'm not sure I understand how this makes bricking better than simply detecting the problem. The advantage you discuss seems to boil down to the ability to identify bad units, but disabling them isn't necessary to identify them, so I don't really understand what's useful there.
zorpner 12y ago
I'd much rather our devices be bricked than risk someone getting hurt. The idea that these are mutually exclusive options is almost comically naive, particularly coming from somebody who claims to have designed critical systems.
- robomartin 12y ago
  You have obviously never experienced a situation where a signal is perfectly good at one end of a PCB trace and bad at the other with no apparent reason for the difference. Make fun of my statement all you want. Give it a decade or two and you might understand. And, of course, if you don't design hardware and the software that runs it you lack a huge layer of context. Perhaps you do. Don't know.
  - zorpner 12y ago
    It's like you didn't even read my post! Of course many of us who have worked in hardware have had issues with bad parts. The idea that this justifies bricking a piece of hardware when the driver on the controller system is upgraded is ludicrous and dangerous. Your decades of experience seem to have blinded you to basic risk mitigation.
    - robomartin 12y ago
      No, I read it. You thought my position was comical. And this revealed you simply don't have enough experience to fully comprehend it. And that's OK. My opinions thirty years ago were based on a very different version of reality. I get it. Don't worry about it. Of course this does not mean we WANT our devices bricked. We immediately issued a tech notice to our customers advising to avoid driver upgrades until further notice. We are OK with devices being bricked under a supervised upgrade. We don't want ANY fake and potentially dangerous chips in our equipment. We don't think we have any due to the nature of our supply chain. Yet we can't assume this. Fake devices can be dangerous in more ways than compatibility and functionality issues. For example, they can have substandard ESD characteristics, RF emissions issues, power issues, thermal issues and flat out safety problems. They can represent a huge liability. And so we are planning on setting up a process through which we have customers swap out the board with the potentially questionable chips with a known good board we Fedex in advance. We can rotate a few boards in this fashion and service all of our customers within a few months. If one or more brick before we can get to them we'll FedEx a board right away. In this fashion the bricking acts as an inconvenient fake chip detector. We don't have any high volume consumer products so our perspective is very different from that of a company making consumer cameras or routers.

pessimizer 12y ago

>And you know clones are dangerous because they are unreliable, failure prone and nondeterministic in some way. Is there any evidence of this?

conductor 12y ago

Here is their response: https://twitter.com/mikelectricstuf/status/524917368154492929 https://twitter.com/mikelectricstuf/status/52491736815449292...

icebraining 12y ago

Say your chips are being used on MRI machines, cars, planes, glucose meters, ATM machines and a whole host of other mission critical systems. First, that's a red herring because most of those machines aren't running Windows, let alone with automatic updates. Second, you're essentially advocating vigilantism by corporations. If FTDI was actually concerned about the lives of people due to faulty chips - and I find this supposition laughable, but let's go with it - they could have (1) warned the users, (2) disable the driver and/or (3) contact the appropriate official institutions. A supposition that someone, somewhere might die does not justify unlawful destruction of property, and if proven that FTDI intended to brick those chips, I hope they get sued hard.

robomartin 12y ago
> First, that's a red herring because most of those machines aren't running Windows, let alone with automatic updates. Are people on HN wound up so tight that all imagination is lost? These are HYPOTHETICAL EXAMPLES used to illustrate mission critical applications. And be careful about making assumptions about critical systems not running Windows. You'd be surprised. Sometimes vendors don't have a choice. If you are working under a contractual obligation to use Windows, well, that's what you use. For example, what do you think you might find in a huge array of military Command and Control centers? Yup. You also seem to be ignoring the fact that FTDI chips typically go on all kinds of embedded systems that are attached to a computer for tasks that have nothing to do with their mission critical nature. For example, we built a dedicated FPGA-based target tracking system used in such places as White Sands Missile Test Range that was entirely self contained. It has an FTDI-driven serial port for firmware updates and configuration. Don't assume that everything related to USB requires full time connectivity like a keyboard or a mouse. Another example is an extremely high power LED system with over 1,500 W of LEDs (much more, but that's all I can say). FTDI-powered USB is used to control it in real time. And, yes, a Windows application is at the other end. That was the spec. And, yes, it has error correction code and a dedicated communications protocol that ensures a certain degree of safety. If that chip is a fake there is no way to know what other "features" it may have. Again, the HN mob is quick to be judge, jury and executioner. That's to be expected. Until most of the HN crowd has another decade or two under their belt emotion will drive a lot of the thought processes. I get it. If FTDI truly intended to cause harm, of course they deserve to be sued out of existence. What kind of a moron would not agree with that. If, on the other hand, the issues are a side effect of code that is so fine-tuned to their devices that bad clones fail, well, that's not their fault. I need to go dig-up the official FTDI position on this, everything else is bullshit and conjecture.
- deleted 12y ago
  [deleted]
- icebraining 12y ago
  To be clear, I wasn't accusing FTDI themselves of anything. I was purely arguing to your hypothetical example, in which they did intend to brick chips. If you didn't want to argue that position, you shouldn't have made a post arguing it. Kindly redirect your anger against the "HN mob" somewhere else.

mikeash 12y ago

If your stuff is really that critical, wouldn't you rather they tell you that you have a fake, rather than just brick it mysteriously and leave you to figure out the reason on your own?

robomartin 12y ago
In order to understand this you have to take a deep dive into the sometimes-murky world of electronic component sourcing. Even when buying from top tier distributors in the US there's potential for getting less-than-wholesome product. The legitimate product manufacturer would have no way of knowing who got what. The best anyone can do is issue a notice like auto manufacturers do for recalls advising you that fake chips may have gotten into the system. Now think about how you might react to that. Externally the chips look exactly the same. Depending on the nature of the organization you might choose to scrap your entire inventory or setup a testing system or. In the case of larger scale production you could very well have 100,000 units of your product manufactured before you can even consider reacting to the news. Once the product is in the market your choices are greatly reduced. Scale is a huge factor. We can send engineers to every single one of our installations to manually swap chips. I did the math, it would probably cost somewhere in the order of five million dollars to do so (travel, time, tools, loss of business, etc.). Well, we can't do that. Few businesses can burn cash like that. And, of course, there's the issue that we might waste millions of dollars swapping out good chips. In this context it is far easier if devices with fake chips stop working and a normal process is used to fix them. You remove liability and quickly identify the clones. In consumer land things are different. There is no sensible way to deal with 100,000 or 1,000,000 units of a product that may have some bad chips. Yes, you probably don't want those devices bricked on purpose. However, if you are operating at that scale you are also responsible for ensuring that your supply chain is not shoving fake or out-of-spec parts into your products. Easier said than done. This isn't the only fake electronic component made by crafty Chinese manufacturers. In that regard this isn't a revelation at all.
- mikeash 12y ago
  I'm not sure I understand how this makes bricking better than simply detecting the problem. The advantage you discuss seems to boil down to the ability to identify bad units, but disabling them isn't necessary to identify them, so I don't really understand what's useful there.

zorpner 12y ago

I'd much rather our devices be bricked than risk someone getting hurt. The idea that these are mutually exclusive options is almost comically naive, particularly coming from somebody who claims to have designed critical systems.

robomartin 12y ago
You have obviously never experienced a situation where a signal is perfectly good at one end of a PCB trace and bad at the other with no apparent reason for the difference. Make fun of my statement all you want. Give it a decade or two and you might understand. And, of course, if you don't design hardware and the software that runs it you lack a huge layer of context. Perhaps you do. Don't know.
- zorpner 12y ago
  It's like you didn't even read my post! Of course many of us who have worked in hardware have had issues with bad parts. The idea that this justifies bricking a piece of hardware when the driver on the controller system is upgraded is ludicrous and dangerous. Your decades of experience seem to have blinded you to basic risk mitigation.
  - robomartin 12y ago
    No, I read it. You thought my position was comical. And this revealed you simply don't have enough experience to fully comprehend it. And that's OK. My opinions thirty years ago were based on a very different version of reality. I get it. Don't worry about it. Of course this does not mean we WANT our devices bricked. We immediately issued a tech notice to our customers advising to avoid driver upgrades until further notice. We are OK with devices being bricked under a supervised upgrade. We don't want ANY fake and potentially dangerous chips in our equipment. We don't think we have any due to the nature of our supply chain. Yet we can't assume this. Fake devices can be dangerous in more ways than compatibility and functionality issues. For example, they can have substandard ESD characteristics, RF emissions issues, power issues, thermal issues and flat out safety problems. They can represent a huge liability. And so we are planning on setting up a process through which we have customers swap out the board with the potentially questionable chips with a known good board we Fedex in advance. We can rotate a few boards in this fashion and service all of our customers within a few months. If one or more brick before we can get to them we'll FedEx a board right away. In this fashion the bricking acts as an inconvenient fake chip detector. We don't have any high volume consumer products so our perspective is very different from that of a company making consumer cameras or routers.