I hope this causes a major and publicly visible malfunction in some important device/installation/machinery, of course with no harm done to any persons, but enough of an embarrasment to really set an example, so no vendor will think of pulling tricks like these in the future.
Takeaway lesson: End users should never touch anything remotely FTDI-like, since it's probably impossible to verify if the device is genuine or not. Wonder if FTDI thought this through.
I hope this causes a major and publicly visible malfunction in some important device/installation/machinery, of course with no harm done to any persons
I actually hope that this does cause an event drastic enough so that FTDI will have blood on its hands that ends in jail time for management and engineers. I don't want to see anyone hurt, especially not innocent third parties, but fuck FTDI, fuck the management who ordered this, and fuck the engineer(s) who didn't quit in protest. I'm not easily offended, but as a programmer who has been responsible for code that would result in loss of life if I made it defective by design, I have no sympathy for this sort of thing. One other thing that I could hope for is that this teaches everyone the true cost of closed source, especially drivers. Don't put up with it.
We're talking about bricking a serial to USB chip, not something worth shedding blood really.
We're talking infrastructure: if this was a civil engineer designing a road to spontaneously create potholes that would flatten tires on certain brands of vehicles, they'd be put in the slammer post haste. FDTI has no idea where their chips and drivers will end up, and as designers of such low-level infrastructure type devices, it is criminally negligent to intentionally brick hardware. If I designed a file I/O library to randomly corrupt data when used on Windows, I'd be criminally negligent.
As far as unethical behavior by corporation is concerned I really not think it's even noteworthy.
Destroying other people's hardware to try to ensure your profits? No, not unethical or noteworthy at all.
> if this was a civil engineer designing a road to spontaneously create potholes that would flatten tires on certain brands of vehicles, they'd be put in the slammer post haste
And if a civil engineer designs a bump in the road that will destroy your suspension if you are driving above the speed limit they have set, we'd just call it a speed bump
> Destroying other people's hardware to try to ensure your profits? No, not unethical or noteworthy at all.
I said it was unethical.
I say it might not be noteworthy when you compare it to business who are actually hurting human beings right now: companies who destroy ecosystems, companies who employ underpayed workforce in sweatshops to increase their profit margin. Companies who sell tools and weapons used to oppress people in authoritarian countries. I could go on for a long time enumerating the list of unethical behaviors in the industry before I hit the "releasing drivers that willingly brick IP infringing copies". So yes I find your reaction a bit over the top even if you're right that they deserve to get some backlash for this type of shoddy behavior.
What if this chip is part of the maintenance interface on a medical device at your local hospital? Meaning regular maintenance can no longer be done, rendering the device unable to help people?
Whoever is in charge of sourcing for life-critical application and let the sketchy part slip in should be held responsible for it.
>the parts aren't "junk"
You don't know for sure. How likely is it that the manufacturer of the knock-off part performed full characterization of their chip to ensure they are within spec limits of the original manufacturer? What if the chip starts sending wrong bits when the temperature gets a bit high or voltage supply fluctuates somewhat? Don't you think getting disabled by driver might even be a less disastrous failure mode in this case?
Um... how exactly do you think the electronics business works, because it's nothing like what you just described. The vendor is often 3 to 5 times (or more) removed from the sourcing of individual components.
hah... Assuming the prototype is actually identical to the delivered product. People who want to skim money off the top aren't stupid, the prototype will probably contain the specified part and so will the first few lots. To insure validity of every part you need to test every part.
OK, let's run with this a bit. Seems simple enough if you make a single pcba, but what if you're a company like sony and your product has 8 different pcbas in it, some source from other companies and some designed an manufactured in house. Whose testing process should screen the counterfeit chips? If a violation is found, who is liable? Someone has to be, because there will be a cost to the end user when the things go belly up. Also, why the hell would anyone have thought to do this in the past? I work in testing and no one creates a QC process to check for fakes during the PCBA process. You don't test the chips when you're manufacturing the board, you test the integration. Doing a full functional verification of every component during PCBA is really dumb.
No matter how you slice it, this is lunacy. FTDI was extremely short sighted here and any competent engineer or product manager will see this as a sign to be weary of incorporating FTDI into future designs. You don't want your component manufacturers playing shady stuff like this. Supply chain management is complicated enough without having to worry about devices getting bricked weeks, months, or years after you've done the engineering work.
Well, the core issue is that there isn't a standard vendor-independent device class driver for CDC devices in Windows like there is for say HID. This is a solved problem on pretty much every other OS. The only reason a manufacturer would make devices that use the same vid as an FT232R as opposed to a functionally-identical pin-compatible device with a different vid is because the drivers included in Windows are vendor-tied. You don't see this kind of issues with no-name mice or keyboards for example because they don't need a vendor-specific driver.
Well, that didn't take long! Arduino Nano's on Ebay are already starting to ship with the CH340G instead of the FTDI clone. Way to go FTDI - pissed off your end users and caused manufacturers to move to a completely different chipset. That worked out well for you didn't it?
http://www.ebay.co.uk/itm/Nano-V3-0-ATmega328-16M-Micro-cont...
Yes, I can. I can picture a product vendor using a modified Linux kernel with that code in a driver, or at least a moral equivalent. Eg, a NAS box which is "only compatible with brand X drives".
Just because the code is available doesn't mean it does no damage. Only that you have the ability to find and fix the code.
A NAS box "only compatible with brand X drives" is nowhere near a NAS box that intentionally bricks non-brand X drives when attached.
As a side note, are there any known cases where a vendor has released open source code that intentionally bricks a device? I'd be surprised if they were not found legally liable if the intent was spelled out so clearly.
There are physical holes on the disk. "The test program writes the sections with a test pattern which generates a change in the pattern of magnetic domains of the medium, a subsection at a time, with a subsection responding to the test pattern only in the absence of indicia thereon, to form a stored pattern on the given section. An expected pattern and the stored pattern are compared at least a subsection at a time to determine if corresponding subsections have a predetermined pattern of magnetic domains."
If you have "insert key disk now", followed by a write to the disk, and then a verification, then a standard disk/non-key disk will get corrupted.
That 'bricks' non-brand floppies by design, under the aegis of copy protection.
There's been open source with back doors in it. Eg, Firebird had one that took about 6 months to detect, after source code release.
> Always keen to shave the last few cents from their bill of materials, these manufacturers tend to procure their firmware from low-cost suppliers that have in turn delivered open source software without passing on its licensing terms. It can come as a surprise to the hardware manufacturer to discover a violation of the license terms.
While that's about incorrect use of licensing terms, it shows there's no reason why the manufacturers are aware of all of the code in the software they sell.
Thanks for the second example. It's a more clear use-case than the mischievous do_damage() function I had in mind.
I think intent would definitely play a role in establishing liability for damaged equipment (i.e. the user misusing the device versus the company tampering with the user's equipment).
> Just because the code is available doesn't mean it does no damage. Only that you have the ability to find and fix the code.
Also your shenanigans become visible. You'd have to code extremely carefully to break the fake with plausible deniability, and even then your name as a developer would forever be mud.
Basically all vendors outsource production. Very few vendors will knowingly put a fake chip in their product, the trick is pulled by someone closer to manufacturing, either to cut costs or to try and ship earlier in case the original chip is hard to get right now.
I doubt very few vendors will realize if a fake FTDI chip is part off their manufactured product even after rigorous testing since the functionality is correct (until you get this driver).
EDIT: I doubt FTDI have thought this through. I will share this with the hardware designers I know and most will probably react like on the linked thread, and just switch to another chip to avoid any possible hassle.
Takeaway lesson: End users should never touch anything remotely FTDI-like, since it's probably impossible to verify if the device is genuine or not. Wonder if FTDI thought this through.