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.
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 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.
As far as unethical behavior by corporation is concerned I really not think it's even noteworthy.
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.
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.
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
Can you picture a Linux or *BSD driver in which there is an intentional
if (counterfeit) { do_damage(); }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.
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.
Perhaps you'll like this example better? https://www.google.com/patents/US4577289 "Hardware key-on-disk system for copy-protecting magnetic storage media"
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.
In listening to the various accounts of GPL enforcement, it isn't always easy to track down the actual vendor. Quoting from http://www.infoworld.com/article/2617579/open-source-softwar...:
> 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.
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).
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.
Whether FTDI screwed customers is a debatable question. In any event, FTDI definitely screwed themselves.
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.