Hacker News new | past | comments | ask | show | jobs | submit login

Nobody would fault FTDI for releasing new drivers that don't work with counterfeit parts.

That alone would cause enough inconvenience to manufacturers to make sure they use legitimate parts.

It's the (unethical) bricking of the parts that has everybody up in arms.




Tangentially: people totally would fault FTDI for releasing drivers that don't work with counterfeit parts. See: Apple detecting and rejecting counterfeit iPhone cables.


The correct way is to detect counterfeit parts, display a huge warning and let the customer continue on their own risk. A similar process is used by the Linux kernel developers for non-opensource kernel modules: If you load them, the kernel becomes "tainted" and you won't get any support from the kernel developers if something goes wrong.


Yes, this would be smart.

Probably just putting a message with priority "Error" in the windows event log would be enough to warn computer-literate users.


Yes, people would fault them for removing functionality.

The problem in that case is not the actual new drivers, but the process of uninstalling the old working drivers.


"bricking" doesn't seem to be the right word. FTDI is making it so that the counterfeit chips don't work with any FTDI drivers, old or new. (Per the thread, all that happens is the PID is changed to a PID that no FTDI driver will recognize)


It's not that they just won't work with their drivers, it's that it disables the device so that it's not operable without special (and costly, if they're widely deployed) intervention.

  The new Windows driver changes the PID to 0, and then the driver won't 
  recognize the device (even if you edit the INF file), and you can't use 
  the config tool. The workaround is to use a Windows XP or Linux system to 
  change the PID back, and then don't use the new driver.
Seems an awful lot like bricking to me.

This is really skirting the ethical line and I'm not sure I can agree with their methods. I'm fine with them writing a driver that fails to work with counterfeit chips, but not actively disabling the chip. What if the device is attached to more expensive equipment that will also fail? We can't ensure that these chips are knowingly purchased after all.

This motivation reminds me of when the U.S. and Syrian governments disseminated sabotaged munitions that explode in the weapon, killing/maiming the operator, among their opponents. The danger is that they will find their way back to friendlies.


Or any other drivers, because it breaks it at the USB level, doesn't it?


I don't think so. There was at least one guy in the thread who reprogrammed the PID back, and the chip worked with the old FTDI drivers again, which means the USB interface was working just fine (or else how could he access it to change it back).


Having to write custom driver-level code to repair something falls pretty well inside the accepted usage of "bricked". It's only marginally easier than just hooking up a JTAG interface.


They change the PID to zero, which means Windows won't associate it with FTDI or any other driver. You have to jump through some manual hoops to undo it, which is something most people can't do. So for all intents and purposes it is bricked, a.k.a "locked out".


Most HN'ers seem to agree it is OK for FTDI to prevent their own drivers from working with the fakes, right? The fact that there are no OTHER drivers that are compatible (no matter what the pid is) with the fakes isn't their problem, is it?


It is ok to have SOFTWARE that refuses to work

It is NOT OK to modify the HARDWARE in ANY WAY, including changing the PID.

That is the issue.

Further Most people defending FTDI assume this code will be 100% pure and never incorrectly identify a real chip as fake, I find that claim to be suspect.

Lastly I would find it very hard to support vendors that take these aggressive risks and stances, I certainly would never incorporate a device from a manufacturer that uses these types of tactics into a mass produced product.


Honest question: are you participating in this thread as a greenbean because you want to hide your identity from harassment from those who disagree with your unpopular opinion, or because you want to hide the fact that you are affiliated with FTDI?


Honestly? I rotate accounts on most major sites periodically. It is a tinfoil-hat foible, a way to distance myself from the exceedingly dumb things I have almost certainly said in years past.

Unfortunately for me, I chose today to rotate.

I don't work for FTDI; I'm not even British. But I did build that Adafruit altoid tin MP3 player eight years ago, which used a FT232.

Why am I wasting my time on this argument? I don't really know, aside from I hate the "internet dogpile" effect.

My credibility as a greenbean is nil of course, but oh well.

Edit: obviously folks do not believe me. Serves me right for trying to answer. jessaustin, I hope you at least feel like you got your answer. I get the feeling it doesn't actually matter what I say or even who I really work for- I'm branded.


I didn't downvote any of your posts and I believe you when you say you're not affiliated with FTDI. But I vehemently disagree with your stance that the sabotage of hardware is warranted or even that it's a minor inconvenience.

Let's take this from another point of view:

You purchase a device or some piece of hardware for a project which becomes useful to others and you decide to make the project marketable and release your own line. You source your components and one of them happens to have an FTDI chip that you believe legitimately came from the company. Your project is accepted by others and everyone is happy.

Then one day, your supplier decides to switch out a source for the chip in one of the components of your project to one that's cheaper (the supplier may not suspect these are counterfeit). You don't see any difference either as you haven't tested it with the latest driver, which may not be out yet. The project is now shipped.

A new driver is released. An overwhelming number of customers now hit your support system saying the update has stopped your project cold. Rolling back the update has no effect. You don't know which component caused the problem as your project uses several from different suppliers. It may take days or even weeks to track down the problem, but meanwhile, your customers grow angry.

This is now your fault and you're left holding the bag.

This scenario need not be hypothetical, as this is just the same as GM "fixing" a problem with their ignition switch that has already claimed lives, but leaving the part number the same. This makes recalling a nightmare as there's now no way to tell which cars are affected until the switch fails or someone dies again.

Just the same as there's no way to tell which one of your project's components carry counterfeit chips and you need to issue a recall for potentially 100K units since you don't know which ones carry a counterfeit and there's no software fix anymore as the chip is bricked. Your project is also potentially being used in mission critical infrastructure that cannot be shut down to do a test without costing a lot of money. Better hope no one follows "best practices" and updates the driver as it may also contain a security fix.

FTDI is well within their rights to protect their product. But are they doing the ethical thing by costing unsuspecting customers and potentially hundreds of other businesses that rely on their product valuable time and money? All for not knowing that somewhere along the supply chain, someone cut a few corners and got their chips from a counterfeiter? Should they be victims twice; once by the counterfeiter and again by the company?


I hope you at least feel like you got your answer.

Yes, I take this answer at face value. I didn't really think there were only two possibilities here. Perhaps I was a bit blunt in the hopes of eliciting a "real" answer like this one.


It's interesting that you're more eager to dispel the notion that you work for FTDI than that you support the crime of destruction of property. You need to think long and hard about the direction of your moral compass.


It's asshole behavior to put code in their drivers specifically to detect and abort even trying to work with fakes, but they are fully entitled to do so.

They are not entitled to break the hardware by changing the PID so it doesn't work with any drivers.

There are other drivers that work when the PID is left intact.


Well, FTDI is leaving their vendor ID intact, and given their behavior so far it wouldn't surprise anyone if they tried to interfere with third-party drivers that enabled using non-FTDI hardware identifying itself with FTDI's vendor ID.


According to the thread the VID is RO?


So? Does anyone actually think that fact will somehow make FTDI want to be more reasonable? They'll just say that those devices being hard-coded to spoof FTDI's VID is further justification for mistreating them.


There are other drivers, on other operating systems that are NOT written by FTDI.


[dead]


Right, I forgot, anyone who isn't part of the lynch mob is a shill.

I rarely eat breakfast in the first place, sadly.


There is no apology sufficient for maliciously and intentionally damaging the private property of your customers.

Refusing to work with counterfeit hardware is entirely appropriate, destroying it in a way that most consumers cannot recover from is in no way acceptable or defensible.

You may as well have come into my home and destroyed my cookware because I bought a stove from you and the pots I had weren't your brand. It's uncalled for, inappropriate, unethical, and immoral and I'm not certain that it's not illegal. Your employer has no leg to stand on.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: