I have not looked into this deeply but a quick google around the other day gave me the impression that the USB CDC spec offered pretty much everything we need to run a serial port in most common use cases.
Not Victims : Most of the organizations that caused the problem
So who does FTDI care about? Apparently nobody. They basically screwed everyone, and I bet if there are enough chips effected there will be class action lawsuits from both sides!
I don't know if this was covered before, but is it illegal for a manufacutrer to make a device the operates with somebody else's driver?
A company could present a user agreement that says, "this driver software may not be used with any other manufacturer's device(s)". But could that even be enforcable?
I don't know if this was covered before, but is it illegal for a manufacutrer to make a device the operates with somebody else's driver?
A company could present a user agreement that says, "this driver software may not be used with any other manufacturer's device(s)". But could that even be enforcable?
If the license for the driver says you can only use the software with their hardware then you are in violation of the software license and are subject to the legal and civil ramifications applicable.
to localroger, Heater and everyone interested on it
As this was just brought on topic by some of you and specially for the ones that wanna use USB CDC to control DTR and DSR, maybe the following Jan Axelson's Forum "Topic: Handling RTS and DSR signal in usb device cdc class" could be valuable:
I have not looked into this deeply but a quick google around the other day gave me the impression that the USB CDC spec offered pretty much everything we need to run a serial port in most common use cases.
We appreciate your feedback, comments and suggestions. As you are probably aware, the semiconductor industry is increasingly blighted by the issue of counterfeit chips and all semiconductor vendors are taking measures to protect their IP and the investment they make in developing innovative new technology. FTDI will continue to follow an active approach to deterring the counterfeiting of our devices, in order to ensure that our customers receive genuine FTDI product. Though our intentions were honourable, we acknowledge that our recent driver update has caused concern amongst our genuine customer base. I assure you, we value our customers highly and do not in any way wish to cause distress to them. The recently release driver release has now been removed from Windows Update so that on-the-fly updating cannot occur. The driver is in the process of being updated and will be released next week. This will still uphold our stance against devices that are not genuine, but do so in a non-invasive way that means that there is no risk of end user’s hardware being directly affected. As previously stated, we recommend to all our customers to guarantee genuine FTDI products please purchase either from FTDI directly or from one of our authorised distributors. http://www.ftdichip.com/FTSalesNetwork.htm If you are concerned that you might have a non-genuine device, our support team would be happy to help out. Yours Sincerely Fred Dart - CEO
Legal or not what FTDI did was just plain stupid. All they did was anger people and scare companies away from their products. It would be smart for them to price their chips more competitively and make it easier for others to license their technology. For all we know though they may have already killed the goose that lays the golden egg.
If the license for the driver says you can only use the software with their hardware then you are in violation of the software license and are subject to the legal and civil ramifications applicable.
The driver (or other software) would have to provide a means for an end-user to determine genuine hardware. For individual components on a circuit board it's not reasonable that end-users will know what is genuine and what is not. EULAs and other contracts are not enforceable unless both parties enter into them with understanding of what they are agreeing to, or are at least given the opportunity to do so. There would need to be some means to identify false products to end users, and a device installer is the place to do it. It would have to function before the EULA.
As previously stated, we recommend to all our customers to guarantee genuine FTDI products please purchase either from FTDI directly or from one of our authorised distributors.
I saw this a few days ago on /., and unfortunately his response missed the mark of what they tried to do. FTDI's customers are NOT the ones impacted. Users of products containing FDTI ICs, who had their boards rendered inoperable, didn't buy chips from FTDI, or anyone else. They bought a product someone else created, and which used either genuine or non-genuine parts.
Dart needs to get serious about how he's going to tackle this. Without a doubt he knows which board-level hardware incorporates non-genuine components. If C&D letters to the makers don't work, there's also his country's customs department (in the case of chips marked as FTDI), as well as informational guidance on his site regarding products that contain counterfeit parts. He can contact Alibaba if boards and parts are being traded that contain counterfeits; he can contact eBay, Amazon, and other sellers with C&D letters, and so on.
Except it's unlikely one can actually make an installer check that can tell fake from real.
If the driver can tell the difference to overwrite content in a counterfeit, why can't an installer do the same? If they can only tell after the fact, they have already admitted having a utility that undoes the overwriting (and others have demonstrated the same thing), so the utility can undo the process. Quite to the contrary, it should be quite simple to do. They've already shown it can be done.
Well yeah, but they will get away with it now. The statement is obviously false. They knew what they were doing, they knew people would be mad, and they knew that their only option was to reverse it. Now they have the spotlight, people are aware of what is going on and maybe this is what it takes these days.
More than likely the clone makers have already figured out how to bypass this driver's intent. The only question is how soon the new chips will appear. A few weeks is my guess. The cloners will also thwart any future attempts to lock out their fake chips just as quickly, if it looks profitable to them.
On the other hand, it seems like many of those that were legally using real FTDI chips are now actively looking for other options.
Shot themselves in the foot seems an understatement.
If the driver can tell the difference to overwrite content in a counterfeit, why can't an installer do the same?
Yes indeed. In this case it is possible to tell the fakes in question because they behave a little differently in some odd ways (See below).
But I did go on to use the word "ultimately". Clearly the cloners can always improve their devices to get around such simple checks. This would be playing "whack-a-mole" until the fakes get so good you need to start using crypto and hiding keys on the device. All seems a bit over the top for a simple serial adapter.
As it happens the dangerous FTDI driver did not actually do any detection of fakes before nuking them. Rather it updated the VID/PID in such a way that the writes to the chips EEPROM did not happen on an FTDI chip but did on the clones. This discovered in a reverse engineering of the FTDI driver that you can see here: http://www.eevblog.com/forum/reviews/ftdi-driver-kills-fake-ftdi-ft232/msg535270/#msg535270. That clearly shows that this damage was intentional action and not just an accident. The code in question has no other reason to be there.
There are ways they can detect genuine hardware from non, but it's not easy, and it is does involve building a moving target. Like any good dongle, they basically interrogate their device with an encrypted message that sends back a hash based on the message, which can vary depending on multiple factors (the message is seldom, if ever, the same). Plus, the device returns a copyrightable text string. Their driver validates the checksum, and the text string is for easy-peasy IP suits.
The outcome is that the hardware is left alone, but the driver will not communicate with it. All legal.
There will be people who pop the top of FTDI chips, and eventually figure out how to decrypt the message to arrive at the validating hash. The more brazen will repeat the copyrightable string in their products. But change both every iteration of their chips, and they create a moving target that hopefully will cut down on the more passive infringement. There will always be hardcore cheats out there, but the idea is to make it less attractive to keep stealing from you.
This is how it might be done for the generic device/firmware/driver device, but for FTDI, that horse may have already left the barn (plus they have tons of legacy product out there, so what to do with that). I also suspect this fiasco has generated enough unease among their customer base that at least some products will be reengineered with competing USB solutions.
There are ways they can detect genuine hardware from non...crypto...hash...copyrightable text string...moving target...
Indeed this can all be done. Such crypto soloutions are used to protect the configuration of FPGAs for example.
To my mind such a solution would be more than a little crazy.
We would have gone from the handful of flip flops and gates required to create a UART to a huge complex mess. The USB hardware, the UART hardware, the micro-controller in the middle to run it all, and now a crypto engine and the complex infrastructure needed to support the ever increasingly complex drivers of the operating systems.
This is not tenable. It's like building Fort Knox to protect a nickel.
Joe Decuir was one of the designers of USB, and was also one of the designer of the Atari 800 SIO bus. USB has some similarities to SIO, and shares some of its strengths and weaknesses. Both a great for attaching smart devices to a computer without a ton of specialized ports. Both stink at relatively simple tasks because their inherent complexity and added costs. RS232 seems like a pain point for both of them.
Back in my Atari 800 days I was faced with paying $200 (USD in 1983) for an SIO to RS232 converter, buying a cartridge that bit banged one on a joystick port, or buying a cartridge that hooked up to the address and data buses with enough smarts to memory map a 6551. The SIO to RS232 converter was hopelessly overpriced and complicated and a misuse of the SIO protocol. Using USB for RS232 sounds like history repeating itself to me.
Yes, but it's transparent to anyone but FDTI. The "dongle" is already the hardware itself; the driver must be used in any case. There are no added layers to object to, as they've always been there to begin with. Board developers and users wouldn't even have a clue there's protection.
However, it would rely on a new class of chips, which to sell them, would need to offer significant value over the current ones, so that developers will pick them. Legacy product is left unprotected, but you have to start somewhere.
As a BTW, I'm not sure hash algorithms requires complex infrastructures. There's no decrypting, just matching the hashes. They're pretty simple, but exponentially more difficult to crack as you simply add bits.
And the USB driver maintainers for Linux, BSD and so on. I'm sure they don't want that junk code in there. As a Linux user nor do I. I could imagine that such a move by FTDI might lead to FTDI support being dropped from Linux. As Linux user I don't want it in there. Give me generic standardized interfaces and multiple sources of supply for the hardware parts.
What you are describing, if taken up by everybody and in the extreme, is a computing landscape where all the different pieces are unusable without the appropriate crypto keys, hashes, signatures whatever. Where nothing works without a key and the keys are only there to secure the revenue stream of the key holders.
And the USB driver maintainers for Linux, BSD and so on. I'm sure they don't want that junk code in there. As a Linux user nor do.
You're jumping to conclusions. As I described it, the hardware does not require the validation; only the driver does. FTDI provides the Windows driver. If someone wants to write their own Windows, OSX, Linux, or other driver to interface to an FTDI device, let them have at it.
FTDI's complaint is that their driver, which they spent time developing, is being used on clones -- their software on product they've made zero dollars on. Why would they complain if someone wrote their own driver to interface to FTDI hardware? That doesn't make sense.
Gordon, the problem with any cryptographic challenge protocol is they require either a shared secret, or some heavy duty public key infrastructure. In the case of the former the FTDI driver would have to embed the shared secret, which would make it vulnerable to the clone makers. In the case of the latter, that requires something like an SSL certificate chain and validation code. It's an awful lot of work to do in a driver and dongle firmware.
I tend to agree with Heater than elimination of the serial port from motherboards was a goof. A memory mapped UART and open driver is frankly much simpler for generic serial I/O. USB is better for devices like cameras or smart disk drives., even for keyboards and mice it's a bit of overkill.
OK, perhaps I'm jumping to conclusions. In your scheme real and fake FTDI chips would work with no problem with existing Linux/BSD/whatever drivers. So far so good.
Problems are:
1) Such a crypto scheme can be busted in no time now a days. The last Chaos Communications conference in Germany had guys explaining how easy it is to bust such systems on FPGA's and all kind of other chips.
2) This still leaves innocent Windows users with systems that break because a fake has crept in there some how. This is seriously not good.
3) It renders Microsoft's driver update system unreliable. It abuses MS. I bet FTDI got some feed back from MS about that.
4) It makes their chips more expensive. That is the last thing they need to be doing.
There is a lot of fuss made about the IP in their Windows driver. Let's have some perspective here. It's a UART. A stupid UART. An interface we have been using for a hundred years. Where is there any IP in there that is so sacred?
@Martin,
Yep. I was a bit miffed when serial ports vanished from our computers. But if squeezing everything through a common port makes things smaller and cheaper so be it. If it means there is a standard for a serial port transport that can be used on PC's and tabs and phones it might even be a benefit in the big picture.
Sadly that does not seem to have happened. The "Universal Serial Bus" is not universal. I can't get by Android phone to talk to a serial dongle for example.
And yes, all in all the, multiple layers of complexity here, which basically either does not work or is unreliable, makes me crazy.
Everyone knows these schemes are not foolproof. Given enough resources, even a complex one can be cracked. But y'all are missing the point.
First off, simply by busting the algorithm a clone maker is breaking the law, giving an additional (and easier) avenue for prosecution. Reverse engineering of an obtuse algorithm is easy to prove, costing far less in court than trademark violation, or even copyright. Guilty clone makers will close up and disappear. That's what FTDI wants.
Second, by passing copyrightable strings to and from a device, they can be nabbed for copyright violation. A simple DMCA cease & desist email is all that's needed to stop these infringing products from being listed on eBay, Amazon, Alibaba, and any other site that relies on the safe harbor protections of these laws. If the complaint is challenged, then DMCA requires a raft of personally identifying information to make the challenge legally acceptable. Cheapest kind of legal discovery on the planet.Now FTDI knows where the other guy lives. (And if he's given false info, well, add a charge of perjury, too. All this is great for summary judgments.)
I don't really care about what's wrong with USB or UART, the wiseness of eliminating serial ports, or any of that. Those are obfuscations to the thread topic. I'm attempting to show that by levering existing laws in some not-always-obvious ways FTDI could have done much more to protect their IP, with far less consequence.
These techniques add zero cost other than some additional engineering resources up front, and none "abuse" Microsoft, because they accept these same types of drivers all the time. None of what I'm suggesting here is new.
These guys are already breaking the law by putting trademarked names and logos on their fake devices. What makes you think they do anything but laugh at your silly DMCA and copyright laws? They would go right ahead and put those copyright strings in the chip. What's the difference?
I do agree that FTDI could have handled things differently. I'm not sure how. Perhaps they could have released and publicised a fake detector tool and invited their customers to use it to check what they have. Thus empowing their customers and growing confidence in FTDI.
As it stands they decided to take the law into their own hands and break users systems. This is not acceptable.
Not only that they leveraged Microsoft's update system to deliver their attack. This is not acceptable.
For sure the world want's to avoid such an underhand company.
What makes you think they do anything but laugh at your silly DMCA and copyright laws? They would go right ahead and put those copyright strings in the chip. What's the difference?
Apparently you don't make YouTube videos.
To have something pulled from a website, YouTube, ebay, etc. all one needs to do is to send some sort of DMCA form. The website then must remove the offending post (video, product listing etc.).
I believe Gordon is suggesting taking advantage of this mechanism to have counterfeit chips removed from websites offering them for sale.
If I understand Gordon's tactic correctly, FTDI would still need to put effort into finding these listings.
(I suppose I could have just let Gordon answer for himself but I was looking for some procrastination excuse.)
These guys are already breaking the law by putting trademarked names and logos on their fake devices. What makes you think they do anything but laugh at your silly DMCA and copyright laws? They would go right ahead and put those copyright strings in the chip. What's the difference?
So, you really didn't read what I said about DMCA notices. Is there a point in further discussing this with you? I don't like to repeat myself, and I already said why there's a difference.
Comments
I have not looked into this deeply but a quick google around the other day gave me the impression that the USB CDC spec offered pretty much everything we need to run a serial port in most common use cases.
What have you found lacking in the CDC?
Not Victims : Most of the organizations that caused the problem
So who does FTDI care about? Apparently nobody. They basically screwed everyone, and I bet if there are enough chips effected there will be class action lawsuits from both sides!
A company could present a user agreement that says, "this driver software may not be used with any other manufacturer's device(s)". But could that even be enforcable?
If the license for the driver says you can only use the software with their hardware then you are in violation of the software license and are subject to the legal and civil ramifications applicable.
As this was just brought on topic by some of you and specially for the ones that wanna use USB CDC to control DTR and DSR, maybe the following Jan Axelson's Forum "Topic: Handling RTS and DSR signal in usb device cdc class" could be valuable:
http://janaxelson.com/forum/index.php?topic=1352.0
I hope it helps a bit
Yanomani
We appreciate your feedback, comments and suggestions.
As you are probably aware, the semiconductor industry is increasingly blighted by the issue of counterfeit chips and all semiconductor vendors are taking measures to protect their IP and the investment they make in developing innovative new technology. FTDI will continue to follow an active approach to deterring the counterfeiting of our devices, in order to ensure that our customers receive genuine FTDI product. Though our intentions were honourable, we acknowledge that our recent driver update has caused concern amongst our genuine customer base. I assure you, we value our customers highly and do not in any way wish to cause distress to them.
The recently release driver release has now been removed from Windows Update so that on-the-fly updating cannot occur. The driver is in the process of being updated and will be released next week. This will still uphold our stance against devices that are not genuine, but do so in a non-invasive way that means that there is no risk of end user’s hardware being directly affected.
As previously stated, we recommend to all our customers to guarantee genuine FTDI products please purchase either from FTDI directly or from one of our authorised distributors. http://www.ftdichip.com/FTSalesNetwork.htm
If you are concerned that you might have a non-genuine device, our support team would be happy to help out.
Yours Sincerely
Fred Dart - CEO
http://hardware.slashdot.org/story/14/10/24/1330252/ftdi-removes-driver-from-windows-update-that-bricked-cloned-chips
http://forums.parallax.com/showthread.php/157888-Windows-update-from-FTDI-killing-clone-chips.?p=1299671&viewfull=1#post1299671
It doesn't seem that many people noticed it though.
The driver (or other software) would have to provide a means for an end-user to determine genuine hardware. For individual components on a circuit board it's not reasonable that end-users will know what is genuine and what is not. EULAs and other contracts are not enforceable unless both parties enter into them with understanding of what they are agreeing to, or are at least given the opportunity to do so. There would need to be some means to identify false products to end users, and a device installer is the place to do it. It would have to function before the EULA.
Yes, I saw it.
I doubt I'm the only one to question their honor in this case.
Ultimately whatever messages the real device returns to requests can also be returned by a clone device. It's a bit of problem.
I saw this a few days ago on /., and unfortunately his response missed the mark of what they tried to do. FTDI's customers are NOT the ones impacted. Users of products containing FDTI ICs, who had their boards rendered inoperable, didn't buy chips from FTDI, or anyone else. They bought a product someone else created, and which used either genuine or non-genuine parts.
Dart needs to get serious about how he's going to tackle this. Without a doubt he knows which board-level hardware incorporates non-genuine components. If C&D letters to the makers don't work, there's also his country's customs department (in the case of chips marked as FTDI), as well as informational guidance on his site regarding products that contain counterfeit parts. He can contact Alibaba if boards and parts are being traded that contain counterfeits; he can contact eBay, Amazon, and other sellers with C&D letters, and so on.
If the driver can tell the difference to overwrite content in a counterfeit, why can't an installer do the same? If they can only tell after the fact, they have already admitted having a utility that undoes the overwriting (and others have demonstrated the same thing), so the utility can undo the process. Quite to the contrary, it should be quite simple to do. They've already shown it can be done.
On the other hand, it seems like many of those that were legally using real FTDI chips are now actively looking for other options.
Shot themselves in the foot seems an understatement.
But I did go on to use the word "ultimately". Clearly the cloners can always improve their devices to get around such simple checks. This would be playing "whack-a-mole" until the fakes get so good you need to start using crypto and hiding keys on the device. All seems a bit over the top for a simple serial adapter.
As it happens the dangerous FTDI driver did not actually do any detection of fakes before nuking them. Rather it updated the VID/PID in such a way that the writes to the chips EEPROM did not happen on an FTDI chip but did on the clones. This discovered in a reverse engineering of the FTDI driver that you can see here: http://www.eevblog.com/forum/reviews/ftdi-driver-kills-fake-ftdi-ft232/msg535270/#msg535270. That clearly shows that this damage was intentional action and not just an accident. The code in question has no other reason to be there.
The outcome is that the hardware is left alone, but the driver will not communicate with it. All legal.
There will be people who pop the top of FTDI chips, and eventually figure out how to decrypt the message to arrive at the validating hash. The more brazen will repeat the copyrightable string in their products. But change both every iteration of their chips, and they create a moving target that hopefully will cut down on the more passive infringement. There will always be hardcore cheats out there, but the idea is to make it less attractive to keep stealing from you.
This is how it might be done for the generic device/firmware/driver device, but for FTDI, that horse may have already left the barn (plus they have tons of legacy product out there, so what to do with that). I also suspect this fiasco has generated enough unease among their customer base that at least some products will be reengineered with competing USB solutions.
To my mind such a solution would be more than a little crazy.
We would have gone from the handful of flip flops and gates required to create a UART to a huge complex mess. The USB hardware, the UART hardware, the micro-controller in the middle to run it all, and now a crypto engine and the complex infrastructure needed to support the ever increasingly complex drivers of the operating systems.
This is not tenable. It's like building Fort Knox to protect a nickel.
Who would want to use such a device?
Joe Decuir was one of the designers of USB, and was also one of the designer of the Atari 800 SIO bus. USB has some similarities to SIO, and shares some of its strengths and weaknesses. Both a great for attaching smart devices to a computer without a ton of specialized ports. Both stink at relatively simple tasks because their inherent complexity and added costs. RS232 seems like a pain point for both of them.
Back in my Atari 800 days I was faced with paying $200 (USD in 1983) for an SIO to RS232 converter, buying a cartridge that bit banged one on a joystick port, or buying a cartridge that hooked up to the address and data buses with enough smarts to memory map a 6551. The SIO to RS232 converter was hopelessly overpriced and complicated and a misuse of the SIO protocol. Using USB for RS232 sounds like history repeating itself to me.
That Joe Decuir seems to have a lot to answer for. He also had a hand in the specification of that mess which is the Bluetooth profiles.
Yes, but it's transparent to anyone but FDTI. The "dongle" is already the hardware itself; the driver must be used in any case. There are no added layers to object to, as they've always been there to begin with. Board developers and users wouldn't even have a clue there's protection.
However, it would rely on a new class of chips, which to sell them, would need to offer significant value over the current ones, so that developers will pick them. Legacy product is left unprotected, but you have to start somewhere.
As a BTW, I'm not sure hash algorithms requires complex infrastructures. There's no decrypting, just matching the hashes. They're pretty simple, but exponentially more difficult to crack as you simply add bits.
What you are describing, if taken up by everybody and in the extreme, is a computing landscape where all the different pieces are unusable without the appropriate crypto keys, hashes, signatures whatever. Where nothing works without a key and the keys are only there to secure the revenue stream of the key holders.
I don't want that world to come about.
You're jumping to conclusions. As I described it, the hardware does not require the validation; only the driver does. FTDI provides the Windows driver. If someone wants to write their own Windows, OSX, Linux, or other driver to interface to an FTDI device, let them have at it.
FTDI's complaint is that their driver, which they spent time developing, is being used on clones -- their software on product they've made zero dollars on. Why would they complain if someone wrote their own driver to interface to FTDI hardware? That doesn't make sense.
I tend to agree with Heater than elimination of the serial port from motherboards was a goof. A memory mapped UART and open driver is frankly much simpler for generic serial I/O. USB is better for devices like cameras or smart disk drives., even for keyboards and mice it's a bit of overkill.
OK, perhaps I'm jumping to conclusions. In your scheme real and fake FTDI chips would work with no problem with existing Linux/BSD/whatever drivers. So far so good.
Problems are:
1) Such a crypto scheme can be busted in no time now a days. The last Chaos Communications conference in Germany had guys explaining how easy it is to bust such systems on FPGA's and all kind of other chips.
2) This still leaves innocent Windows users with systems that break because a fake has crept in there some how. This is seriously not good.
3) It renders Microsoft's driver update system unreliable. It abuses MS. I bet FTDI got some feed back from MS about that.
4) It makes their chips more expensive. That is the last thing they need to be doing.
There is a lot of fuss made about the IP in their Windows driver. Let's have some perspective here. It's a UART. A stupid UART. An interface we have been using for a hundred years. Where is there any IP in there that is so sacred?
@Martin,
Yep. I was a bit miffed when serial ports vanished from our computers. But if squeezing everything through a common port makes things smaller and cheaper so be it. If it means there is a standard for a serial port transport that can be used on PC's and tabs and phones it might even be a benefit in the big picture.
Sadly that does not seem to have happened. The "Universal Serial Bus" is not universal. I can't get by Android phone to talk to a serial dongle for example.
And yes, all in all the, multiple layers of complexity here, which basically either does not work or is unreliable, makes me crazy.
First off, simply by busting the algorithm a clone maker is breaking the law, giving an additional (and easier) avenue for prosecution. Reverse engineering of an obtuse algorithm is easy to prove, costing far less in court than trademark violation, or even copyright. Guilty clone makers will close up and disappear. That's what FTDI wants.
Second, by passing copyrightable strings to and from a device, they can be nabbed for copyright violation. A simple DMCA cease & desist email is all that's needed to stop these infringing products from being listed on eBay, Amazon, Alibaba, and any other site that relies on the safe harbor protections of these laws. If the complaint is challenged, then DMCA requires a raft of personally identifying information to make the challenge legally acceptable. Cheapest kind of legal discovery on the planet.Now FTDI knows where the other guy lives. (And if he's given false info, well, add a charge of perjury, too. All this is great for summary judgments.)
I don't really care about what's wrong with USB or UART, the wiseness of eliminating serial ports, or any of that. Those are obfuscations to the thread topic. I'm attempting to show that by levering existing laws in some not-always-obvious ways FTDI could have done much more to protect their IP, with far less consequence.
These techniques add zero cost other than some additional engineering resources up front, and none "abuse" Microsoft, because they accept these same types of drivers all the time. None of what I'm suggesting here is new.
These guys are already breaking the law by putting trademarked names and logos on their fake devices. What makes you think they do anything but laugh at your silly DMCA and copyright laws? They would go right ahead and put those copyright strings in the chip. What's the difference?
I do agree that FTDI could have handled things differently. I'm not sure how. Perhaps they could have released and publicised a fake detector tool and invited their customers to use it to check what they have. Thus empowing their customers and growing confidence in FTDI.
As it stands they decided to take the law into their own hands and break users systems. This is not acceptable.
Not only that they leveraged Microsoft's update system to deliver their attack. This is not acceptable.
For sure the world want's to avoid such an underhand company.
Apparently you don't make YouTube videos.
To have something pulled from a website, YouTube, ebay, etc. all one needs to do is to send some sort of DMCA form. The website then must remove the offending post (video, product listing etc.).
I believe Gordon is suggesting taking advantage of this mechanism to have counterfeit chips removed from websites offering them for sale.
If I understand Gordon's tactic correctly, FTDI would still need to put effort into finding these listings.
(I suppose I could have just let Gordon answer for himself but I was looking for some procrastination excuse.)
So, you really didn't read what I said about DMCA notices. Is there a point in further discussing this with you? I don't like to repeat myself, and I already said why there's a difference.