Frequently Asked Questions
Mon-Fri, 9am to 5pm
U.S. Mountain Time:
Chat With Us
June 3, 2013
News - FTDI Drivers and Counterf…
about 7 months ago
This is a personal first: Kudos to Microsoft for doing the right thing.
Well THIS little incident isn’t going to do good things for their reputation, that’s certain.
FTDI doesn’t own the Linux driver. What they’re doing prevents you from using an affected device with Linux.
Pretty sure that talking my mother through that procedure is a non-starter.
How confident are you that, having done this once, that FTDI won’t make a mistake in the future and release a driver that accidentally bricks legitimate FTDI devices?
For all intents and purposes, reprogramming the PID to zero bricks the chip. It’s not just unusable by their driver, it becomes unusable by ANY driver on any OS. It is recoverable by a guru, but suggesting that this isn’t sabotage is disingenuous.
That other companies may or may not have done it doesn’t make it more acceptable.
Oh, and 
If they did what prolific did a while ago and BSOD/panic on detection, I’d be fine with that.
Deliberate hardware bricking is unacceptable in any context.
I can understand that. And I’m not calling on SparkFun to throw away stock on hand. But when products need to be revised or new products created, I hope SparkFun will remember the dangers involved in trusting FTDI not to pull a Stuxxnet.
Besides, what if the next time they try this little stunt they mess something up and it starts bricking legitimate FTDI product? Maybe a chip revision they missed in driver testing? Who knows what might happen. It’s just not worth the risk to use their chips.
When those “things that have to be done” include destruction of property that doesn’t belong to you, then I think you are dangerously wrong.
No public wish lists :(
Forgot your password?
No account? Register one!