The question here is, is it possible for FTDI to detect if the chip is counterfeit in another way?
I do not think so! They probably spend a lot of time figuring this method out.
I bet there are other ways of detecting them. I don't have any clones myself, so I can't test, but it's extremely unlikely that the cloners nailed everything else but this. And even if they did, it would still be way better to read-modify-write-restore the EEPROM as a detection mechanism, rather than, again, going for damage.
FTDI doesn't have to guarantee that there code works with chips of someone else. Many manufactors warn for non-functioning equipment when their drivers are used with products, which are not produced by them.
There's a difference between code that happens not to work on another device, and code whose sole purpose is to destroy another device. "Only use manufacturer-approved equipment" is not a valid legal veil to hide behind while you explicitly set out to destroy non-compliant equipment. It's (usually) legal to detect and refuse to work with knockoffs (not always - antitrust laws come into play here, and sometimes even that can be illegal). Deliberately causing damage is crossing the line.
Actually they just erase the product id. That is all you can easy reprogram it.
Linux still won't load the driver. That's still causing deliberate damage, even if it's reversible.
I mean that counterfeit IC cann't be used for now with the new drivers.
Hence, don't work. It's a negative state of affairs, particularly for the owners of said devices.
No, they are not. They do not pass the new test system to detect if they are a clone. Therefor they are not compatible. Many PC compatibles in the 80 where also not compatible.
You seem to be confusing compatibility with 100% identical behavior. Intel and AMD CPUs are largely compatible. They're also trivial to tell apart. Even AMD's original (much simpler, compared to modern chips) Am486 was completely compatible with the 80486, but dedicated code designed to tell it apart could still do so.
You can buy Philips screwdrivers from two manufacturers. They are compatible. Doesn't mean they have to be the same color, material, or have all the atoms in exactly the same place. Just because I can look at them and tell them apart doesn't mean they aren't compatible.
No, these ID's are used to assign a driver to the chip through the INF file. For instance in the PCI system if you chose to use 8086 as vendor id and 8259 as product ID I am sure you end up with a non functioning PC.
Actually, that product ID is unused by Intel right now, so absolutely nothing bad would happen, and if your device is of a standard device class, it'll even work fine with generic drivers. For example, I could build a PCI SD Host Controller interface with those IDs, and it would work fine. Intel might not be amused, and it would be a silly idea, but harmless. If Intel ever releases a device with that ID, then indeed it would cause a conflict. However, if I designed a device register-compatible with an Intel device and used its same ID, again, practically speaking, nothing bad would happen. In fact, that is exactly what all virtualization solutions like VMWare, VirtualBox, and QEMU do, all the time. I have myself written a virtual USB xHCI controller for QEMU, and yes, it could emulate one of two different chips, and yes, it used their VID/PID, and yes, it even had to deal with some retarded "anti-clone" vendor-specific commands, and no, it wasn't 100% bug-for-bug compatible, but it was close enough to work.
The same applies also for the USB. This is the only way for the OS/BIOS/EFI to detect new hardware and assign the right driver. They should be unique ID's. You pay $5000 so that you are ensured they are unique.
You pay $5000 for the right to use the USB logo. Yes, the IDs should be unique. No, there is no legal protection nor guarantee that they are, unless you use the USB logo. The world doesn't end if you use someone else's ID, especially if you do it in a compatible way.
Try assigning some random numbers to your USB devices and see what happens on Linux also. You need a VID and PID and the system works by uniqueness of these numbers.
Actually, the vast majority of the USB devices that people use every day are identified by class codes, not VID/PID - mass storage, HID, CDC, even the PCI controllers (UHCI, OHCI, xHCI). VID/PID only have to be unique
for a particular proprietary device interface. Nobody cares about what VID/PID you use for a standard device (as long as they don't conflict with a proprietary one, which might result in their driver being assigned), and again, there's nothing wrong with masquerading as another device if you intend to be compatible with it. You're taking a risk, but that's a compatibility risk, and it's not reasonable to expect direct gunfire from the other side in return.
It is the responsibility from the manufactor to check their sources.
Sure, and everyone demands a paper trail and armed guards across the entire chain of custody, to make sure no counterfeits slip in, right?
It sucks when these things happen, but placing all the blame on the final assembler/manufacturer is grossly oversimplifying things. You have no idea what happened that led to counterfeits being used in an end product.
I think here in the Netherlands you can leave it behind on the airport and may be lucky when you do not get a fine.
Funny,
the first Google result for "netherlands counterfeit goods" proves you wrong. There's an exception for personal use, within reasonable limits. Seriously, before you argue with someone on the Internet about your own country's laws, you might want to at least do a cursory check...
P.s. How many non-functioning devices you got?
None, but I've developed a rather strong disgust for people who destroy end-user hardware through gross negligence or deliberate action, over the past 8 years or so, due to certain communities I've been involved in, and I've done my best to make sure that my software never does that, not even in the least likely of circumstances. I have a very strong respect for people's hardware.