Chip,
Bottom line is that one can have PC and a USB peripheral that works. Then get this driver update and it no longer works. Not because of regular every day bug, but by deliberate intent. This is intolerable behaviour.
Wait a minute. I understand the complaint when they were bricking hardware. But this is different. Look at it this way:
Their drivers had a bug, namely that non-FTDI hardware was using the FTDI drivers instead of their own drivers. FTDI fixed that bug.
Why should FTDI be punished for making sure their software only works with their hardware?
Maybe I am a old timer, maybe I just see software development as a value because I live off it for most of my life.
There are generic class drivers in Linux, Windows and Mac. As a hardware designer building devices you do not need to write a own driver. Just use the generic one. No problem.
FTDI could have used the generic drivers also but where thinking - well to slow, missing features, lets write a better one.
FTDI pays people to develop faster and sort of different drivers for Windows, Linux and Mac for their own product. They pay money for putting them into the OS'es either via Microsoft Certification, MAC for sure also takes money to install by default and providing driver for the Linux distributions and keeping them up to date will for sure also need some guys at FTDI to take care of, also wanting a income.
All this cost money, software developer want to eat too.
FTDI also pays for a VID/PID combination, used to select the correct driver for their products.
So their products are more expensive as just HW alone.
Here now come the suckers. They could use the generic class driver, but think - well to slow, missing features, lets just steal VID/PID and driver from FTDI and sell some HW for half the price, undermining FTDIs sales and not paying any money to any of them programmers working on that code.
It is simply theft, and nothing else. And IMHO not paying a programmer for his work is simply criminal. But I am partisan there, since I am a programmer.
I have to agree with @heater that bricking them devices is not right, on the other hand the VID/PID is something like a Brand/Trademark/Name. The VID says 'who produced this thing'. And FTDI did not produce them. So they removed that entry. Maybe not right, but understandable.
I did not build this.
Like a artist coming into a gallery and finding a picture for sale, claiming to be made by him, his signature on it, but he never painted it and it is not even the style he would paint. Can ruin his life, can't it?
But everybody was hammering FTDI that that is wrong and they should not have bricked the devices, but refuse to work with them and inform the end-user about the reason why.
Device driver can not pop up Message boxes, so how to inform the end-user? SURE - by using the function of the device itself, serial input and output.
FTDI does exactly what there where asked for most, after FTDI-gate 1.0.
Not working, not bricking and informing the end-user about the problem. Via serial. Driver do not have access to the GUI, how else?
This driver is not written for the HW you are using. Please use our product with this driver or use another driver provided by the vendor of your product.
Why should FTDI be punished for making sure their software only works with their hardware?
That is their right, just as potential customers have the right to factor in the market confusion and support calls from their befuddled customers.
Anyone who has a visible & 'as far as they know' legitimate FTDI device, may still decide to replace that with one that has less support cost.
Some of the links appear to give examples of exactly this happening.
Looking around here, I see quite a few FTDI logo parts.
Do I know for sure by inspection they are all legitimate ? Of course not. I believe they are.
I didn't agree with the bricking. This, I do agree with.
Maybe those people making clone chips can write a simple utility to prevent update of the driver they didn't write, nor supports their product officially.
As for avoiding them. I won't. Just gotta be sure it's the real deal, or take another design choice and path. I won't blame others for stepping away from this mess either.
It could be an expensive mess.
I do blame those peeps out there, who took the pennies on the dollar deal. Some didn't know, and that's fair. But, you just know a lot of them did.
Maybe they can take those fatter margins and find a solution for their customers, or design it out, or pay the guys who did the real work.
As for milking the design. Hey, they did the work and want to be paid. Others, wanting in on a nice business could do the work too. Until that investment is made, the FTDI guys earned their money.
They could choose to drop their price to help cut out the infringement too.
Up to them. I would not expect them to do that, given all that has transpired.
I didn't agree with the bricking. This, I do agree with.
But what they're doing is bricking, just in a more subtle and passive-aggressive manner. What gets bricked are the systems that were working fine until the latest update, after which the driver inserts messages in the datastream that can disrupt the system's operation -- all without the casual app user even knowing why things are screwing up. If the system happens to be some sort of medical equipment or other life-critical app, FTDI could be liable.
The correct response would have been a clearly-visible Windows pop-up from the driver that reports the incompatibility when trying to connect with a bogus chip.
No, it's not quite the same. People have options. They might not like those options, but they have them. Managing the software environment is one option, replacing the chip is another, and replacing the gear is yet another.
No, it's not quite the same. People have options. They might not like those options, but they have them. Managing the software environment is one option, replacing the chip is another, and replacing the gear is yet another.
Err. teensy detail : People are not clairvoyant.
Remember, the end customer is the one bitten first here.
Until they know what is wrong, they have no options. There is no Pop-up, for example.
Their system goes flaky, they have no idea they have a Driver change that has just nobbled their system.
A technical callout, or support call is needed.
"Correct" is all subjective. I'll go with more friendly, or desirable, etc.... but not correct.
The thing is, that response means people can ignore the problem. That's an ongoing market for the free loading infringers. Got a burger the other day, and right on the drive thru screen I see a software counterfeit message. It's been there for over a year.
FTDI just isn't obligated to be nice.
So, the real trouble is all these infringing devices. Who is making those and what kind of attention should they be getting. The FTDI guys aren't the problem. These other clowns are.
That we see very little discussion on that front tells me people are going to ignore it more than they don't, and FTDI is being expected to play ball, when they don't have to do that, and apparently won't anymore.
Liability? Lol, for what? A device they didn't design, didn't support, didn't manufacture and didn't sell? FTDI can win that case.
None of this is on them. All of it is on both the infringing parties as well as anyone designing it in there and then somehow showing a great BOM cost from, "an alternate supplier", who actually infringe to make money and offer no meaningful value otherwise
Yes, Jmg I am quite sure end user triage isn't cheap. Seems to me, once those calls get made, and real problem found, there should be some meaningful discussion on what to do with dangerous, infringing chips that could do a lot of harm.
Everybody, everywhere running those infringing chips really should be aware of what has happened.
I don't like any of it. But I also know FTDI really can't be made to just support infringing garbage either. Not without some compensation at a minimum. It's just not their problem.
Asking FTDI to play nice is fair, but when they say no, and it appears they have, it's time to start placing blame on the parties actually responsible for the mess.
BTW, I'm about to start working with a product that has this functionality. I've asked them to certify they are using FTDI components, and will make it clear that is a requirement.
I'm not going to get stuck cleaning up end user messes.
Lots of conversations of that kind need to happen, and again, when that costs way more than the savings from the infringing chip, I'll bet different choices get made.
That could be to avoid FTDI. Fine. How much that matters really is up to FTDI.
I fear that liability might be determined as much by proximate cause, as by ultimate cause. In the scenario I presented, the proximate cause of system failure is FTDI's driver; the ultimate cause, the bogus chip. This is especially troublesome for FTDI if the proximate consequences of their deliberate actions are foreseeable, which they certainly are in this case.
This strawman argument about being dangerous needs to be addressed. Let's take the "medical equipment" statements as an example. Let's suppose that said equipment contains a counterfeit FTDI chip. Now, let's suppose the drivers were updated and it stops working in such a way that it harms a person. The argument being made above is that this is FTDIs fault. But that's wrong, and here's why:
1. The medical equipment contains COUNTERFEIT HARDWARE. This hardware could fail at any time, regardless of the driver update. As the producer of the medical equipment, the very fact that you have counterfeit hardware is already a major problem that has NOTHING TO DO WITH FTDI.
2. If it is possible for the medial equipment drivers (or other software, for that matter) to be arbitrarily updated without any verification, validation, or testing, there is another huge issue that has NOTHING TO DO WITH FTDI.
3. If the medical equipment has not gone through proper Failure Modes and Effects Analysis, such that a failed "FTDI" chip could cause harm to a person, then the medical equipment is already dangerous and has NOTHING TO DO WITH FTDI.
These same 3 points apply to every potentially dangerous product. And, in every case, it has NOTHING TO DO WITH FTDI.
So, please stop using the "this could harm someone" argument. It is an emotional argument masquerading as something else.
As for the "show a dialog" argument, I don't think it's practical. Drivers usually don't have GUI access, unless you have installed a separate GUI app that communicates with the dialog. Personally, I don't want to encourage every chipmaker out there to insist on running a background GUI app to validate my hardware. There's already enough cruft...
However, it should be possible for the driver to add an entry to the Event Log, then just stop transferring the data altogether. I think this would be more easy to discover at the consumer level than their current approach.
Which brings me to my next thought... how many consumer devices does this actually affect? Looking through the discussions, it seems to me that they are *all* (so far) concerning hacker/maker/etc hardware. Obviously, considering the nature of this community, we are going to be more sensitive to the issue. Of course, it's also exactly this same community (not specifically this forum community, but the broader hacker/maker/etc community) that is purchasing the cheap knock-offs in the first place. Caveat emptor and all that. Don't blame others for your bad choices.
That's not to say that everyone knew what they were buying. Some certainly believed they were buying genuine hardware. But, unlike the typical consumer, this community is technically savvy enough to go back to the product manufacturer and address the counterfeit issue directly. If product manufacturer cannot fix the issue, then you stop using their products and find another product manufacturer.
And, that's not to say that counterfeit parts aren't in consumer-level products. But, for the average joe, I don't think this driver update will have much impact. For those few that are affected, they will generally see that their whole device has stopped working. Nothing more. When they return the product to Amazon and write that negative review, it will be about the product, not about the counterfeit FTDI chip inside.
As for the "show a dialog" argument, I don't think it's practical. Drivers usually don't have GUI access, unless you have installed a separate GUI app that communicates with the dialog. Personally, I don't want to encourage every chipmaker out there to insist on running a background GUI app to validate my hardware. There's already enough cruft...
While not every peripheral should have a GUI component for user feedback, it's commonplace for important ones, like video adapters and printers. For commercial or industrial applications using an FTDI interface, I'd wager the use case is important enough that it wouldn't be considered cruft, and in fact could be looked upon as an important and desirable troubleshooting tool.
I agree with those who say for other applications the driver going into fault mode is not harmful in and of itself. For consumer and DIY applications, these are very likely not mission critical anyway. Yes, the device is put out of service until the user installs the correct driver, But the device improperly was using the wrong driver to begin with.
That said, I personally see no reason FTDI had to put the crippling version of their driver on automatic Windows update -- if that is in fact what they did. Also, for those who were affected by this, did driver rollback not work? Was this somehow made non-functional by FTDI? I suspect there is more to this than what's been reported so far.
Isn't infringing the Smile out of FTDI also reprehensible?
I just scanned a variety of discussion on this. First, this is most likely to impact rock bottom cheap hardware more than anything else. Could be some consumer devices too.
A lot of the framing is "bricking competitors chip" and that's completely ignoring what has FTDI doing what they are doing. Producing an infringing product in such a way as to imply the original vendor supports it isn't competition at all. A competitor would have to actually release a product, do support, etc... not just mooch off FTDI.
I read the clones are coming out of China. Good luck with that IP enforcement. On that basis, can't blame FTDI. There won't ever be a requirement that their driver support infringing devices sold on the cheap. They want people to either do something else, or check that they are getting the FTDI solution, and they want that to shut out the clones.
There are quite a few comments related to the FTDI chip pricing and how that somehow justifies these "cheap competitors" Interestingly, those are the same arguments media pirates use to justify their actions too. One director polluted torrents of his production with ones filled with footage of his scrotal sac. (which is hilarious) The idea being to cast doubt on the infringing products. Another female musician looped, "you should be ashamed" to make polluted torrents.
Like the media people and that piracy going on, FTDI does have the option of changing pricing, and or doing other kinds of deals to get some of that money flowing back to them.
Based on the comments I read through this morning, anyone working on serious gear isn't worried. The various certification / verification / testing processes would not be kind to BOM changes that included infringing hardware. The underwriters would have a field day charging for that. Non issue, as has been stated here. I've been on a few projects like that, and verifying BOM items, arranging for alternative suppliers, etc... is taken very seriously. Using these illegitimate chips would be a firing offense at the minimum.
There are a ton of people who got really cheap stuff, and a lot of them are impacted. In my experience, they will hack around the trouble and continue to be very vocal about how they've been harmed, but the nice price will continue to be a draw and will prove to be a nice motivation to continue to ignore the problem. (Because pricing) There is a definite "FTDI deserves this for pricing their product high" subtext to this whole thing.
Honestly, that annoys the Smile out of me and it drains away any sympathy I might have. FTDI did the work, made a market, and prices for value. It's not cheap, but it works and it works well.
Seems to me, replicating that isn't cheap, or it would have been done and there would be real competitors out there, not infringers.
So there is an opportunity out there for someone. I'm a believer in real competition, and this niche where FTDI plays is ripe for some. Get out there and disrupt them! There is your market based solution right there. I suspect doing that just isn't easy, and it will have dubious returns, which is why FTDI is in the position they are in.
Until somebody does that, FTDI gets to price where they think the value is and these infringers and people buying their counterfeit products aren't doing anyone but themselves any favors.
The real message here is, "best make sure it's genuine" and again, I can't blame FTDI for that. And that is the reason for putting the driver on auto update. The people buying the infringing parts really aren't going to care. A few will. Those who made an honest mistake. But, the majority won't because they have a beef with FTDI pricing. Again, I find the parallels between this and media piracy very interesting! It's the same rough argument, but the stakes are higher. It's one thing to be mooching torrents. It's quite another to be shipping real products.
As you watch this play out, pay close attention to what isn't being said. I find it enlightening.
Isn't infringing the Smile out of FTDI also reprehensible?
Yes it is.
Except of course if the clone does not use FTDI's name, logos, or other trade marks or infringe on any patents they may have on the device or otherwise misrepresent itself. Building a compatible device is no shame.
I have no idea if there are such clones mind you.
However, the actions of the fakers are not the fault of end users. End users should not be inconvenienced because of this.
As you watch this play out, pay close attention to what isn't being said. I find it enlightening.
Yes it is enlightening.
Those who condone or even support FTDI actions are basically saying that it's OK for manufacturers to fight out their turf wars on our machines at our inconvenience and expense.
I'm really not OK with that.
The whole situation is nuts. Now there are suggestions of a GUI with the FTDI driver. What?! This is a frikken UART we are talking about. An interface that is dead simple and has been around since before most visitors here were alive. Any such driver and config GUI should be part of the OS. Serial config should be part of the OS API. It should be usable from any standard terminal or serial port software.
Where did this all go wrong?
Oh, yeah. Intel. Intel invented USB to sweep all that aside.
This whole thing reminds me of communities where WalMart comes to town, everyone shops there while the mom & pop stores go out of business, then WalMart leaves and everyone cries about the loss of jobs & options when not shopping there in the first place would've kept things exactly as they were.
I look on EBay and see the $2 "Arduino", but I'll never buy it because it's Smile. To those who did, and now it's not working, what were you expecting for that price?
FTDI's previous bricking episode was Smile. This one, less so, and given that they don't have a lot of reasonable options, I'm ok with it. The cloners are very directly stealing from them, and they did something about it.
There was an app developer a while ago that wrote a "game development simulator" game, like Railroad Tycoon by for games. They released a cracked / pirate version of their own game in which the story arc is affected by piracy and eventually you go bankrupt. Their forum was full of people complaining about piracy ruining the game for them, unaware of the irony. It was amazing. I say kudos to FTDI for getting creative.
BTW, I'm about to start working with a product that has this functionality. I've asked them to certify they are using FTDI components, and will make it clear that is a requirement.
I'm not going to get stuck cleaning up end user messes.
Lots of conversations of that kind need to happen, and again, when that costs way more than the savings from the infringing chip, I'll bet different choices get made.
That could be to avoid FTDI. Fine. How much that matters really is up to FTDI.
"I'm not going to get stuck cleaning up end user messes." is a great aspiration.
When you "asked them to certify" how confident are you that is what will happen ?
The only way to be certain, is to do the test yourself. and add more controls to your supply lines to avoid merging products...
Of course right up until FTDI made this change, you may have already been doing all of this, but whenever their driver changes, your tests need to change.
When any given counterfeit device passes this test, what do you do then ?
The next secret FTDI driver update could see you "stuck cleaning up end user messes".
Smarter product design includes the question "How could I avoid all these dice rolls?"
Those who condone or even support FTDI actions are basically saying that it's OK for manufacturers to fight out their turf wars on our machines at our inconvenience and expense.
I'm really not OK with that.
The whole situation is nuts. Now there are suggestions of a GUI with the FTDI driver. What?! This is a frikken UART we are talking about. An interface that is dead simple and has been around since before most visitors here were alive. Any such driver and config GUI should be part of the OS. Serial config should be part of the OS API. It should be usable from any standard terminal or serial port software.
Where did this all go wrong?
Oh, yeah. Intel. Intel invented USB to sweep all that aside.
Yup, the whole situation is nuts.
FTDI imagine they have the right (currently unproven) to fight this on end-users machine, which also means designers have an equal right to avoid being turf-war collateral damage.
There are driverless USB solutions out there, but I think the missing piece is HID to VCP, which sounds like an OS provider could solve ?
Jmg, I will employ legal means as well as testing.
@all, I would be far more sympathetic to disruption of end users, given FTDI has better options. I don't see many for them.
And we've all experienced this before. Ever have your consumer gear not work due to some DRM or other?
Moving away from this mess is fair too. Will be interesting to see what people end up doing and if that ends up worth it for FTDI.
What I don't see anywhere near enough of is people experiencing their counterfeit device problems and asking why their supplier chose that route, exposing them to this Smile.
...
The whole situation is nuts. Now there are suggestions of a GUI with the FTDI driver. What?! This is a frikken UART we are talking about. An interface that is dead simple and has been around since before most visitors here were alive. Any such driver and config GUI should be part of the OS. Serial config should be part of the OS API. It should be usable from any standard terminal or serial port software.
...
And there is. it is called generic driver in Windows, no clue about Mac and Linux.
A standard class driver for serial USB. No installation required.
What I don't see anywhere near enough of is people experiencing their counterfeit device problems and asking why their supplier chose that route, exposing them to this Smile.
You wrongly presume the supplier always 'chose'.
See my example above, for how even you can get caught - others will then claim you chose to do this.
If FTDI can detect these counterfeit chips, then surely their driver can be made to simply not work with them. Instead, they deliberately chose to act in a belligerent and antagonistic manner that only harms the user of the device. That makes no sense to me, and I find it hard to believe that anyone could think what FTDI has done is somehow "right".
As for the "show a dialog" argument, I don't think it's practical. Drivers usually don't have GUI access, unless you have installed a separate GUI app that communicates with the dialog. Personally, I don't want to encourage every chipmaker out there to insist on running a background GUI app to validate my hardware. There's already enough cruft...
However, it should be possible for the driver to add an entry to the Event Log, then just stop transferring the data altogether. I think this would be more easy to discover at the consumer level than their current approach.
I would prefer it to stop working. Yes and event log entry or can't the driver report the problem to the device section (where you check the system/device drivers when they don't work - isn't it possible for the driver to explain why here?
Better to not work than brick or corrupt - in either case IMHO its malware.
Comments
Wait a minute. I understand the complaint when they were bricking hardware. But this is different. Look at it this way:
Their drivers had a bug, namely that non-FTDI hardware was using the FTDI drivers instead of their own drivers. FTDI fixed that bug.
Why should FTDI be punished for making sure their software only works with their hardware?
There are generic class drivers in Linux, Windows and Mac. As a hardware designer building devices you do not need to write a own driver. Just use the generic one. No problem.
FTDI could have used the generic drivers also but where thinking - well to slow, missing features, lets write a better one.
FTDI pays people to develop faster and sort of different drivers for Windows, Linux and Mac for their own product. They pay money for putting them into the OS'es either via Microsoft Certification, MAC for sure also takes money to install by default and providing driver for the Linux distributions and keeping them up to date will for sure also need some guys at FTDI to take care of, also wanting a income.
All this cost money, software developer want to eat too.
FTDI also pays for a VID/PID combination, used to select the correct driver for their products.
So their products are more expensive as just HW alone.
Here now come the suckers. They could use the generic class driver, but think - well to slow, missing features, lets just steal VID/PID and driver from FTDI and sell some HW for half the price, undermining FTDIs sales and not paying any money to any of them programmers working on that code.
It is simply theft, and nothing else. And IMHO not paying a programmer for his work is simply criminal. But I am partisan there, since I am a programmer.
I have to agree with @heater that bricking them devices is not right, on the other hand the VID/PID is something like a Brand/Trademark/Name. The VID says 'who produced this thing'. And FTDI did not produce them. So they removed that entry. Maybe not right, but understandable.
I did not build this.
Like a artist coming into a gallery and finding a picture for sale, claiming to be made by him, his signature on it, but he never painted it and it is not even the style he would paint. Can ruin his life, can't it?
But everybody was hammering FTDI that that is wrong and they should not have bricked the devices, but refuse to work with them and inform the end-user about the reason why.
Device driver can not pop up Message boxes, so how to inform the end-user? SURE - by using the function of the device itself, serial input and output.
FTDI does exactly what there where asked for most, after FTDI-gate 1.0.
Not working, not bricking and informing the end-user about the problem. Via serial. Driver do not have access to the GUI, how else?
This driver is not written for the HW you are using. Please use our product with this driver or use another driver provided by the vendor of your product.
What is wrong with that?
confused again!
Mike
That is their right, just as potential customers have the right to factor in the market confusion and support calls from their befuddled customers.
Anyone who has a visible & 'as far as they know' legitimate FTDI device, may still decide to replace that with one that has less support cost.
Some of the links appear to give examples of exactly this happening.
Looking around here, I see quite a few FTDI logo parts.
Do I know for sure by inspection they are all legitimate ? Of course not. I believe they are.
I didn't agree with the bricking. This, I do agree with.
Maybe those people making clone chips can write a simple utility to prevent update of the driver they didn't write, nor supports their product officially.
As for avoiding them. I won't. Just gotta be sure it's the real deal, or take another design choice and path. I won't blame others for stepping away from this mess either.
It could be an expensive mess.
I do blame those peeps out there, who took the pennies on the dollar deal. Some didn't know, and that's fair. But, you just know a lot of them did.
Maybe they can take those fatter margins and find a solution for their customers, or design it out, or pay the guys who did the real work.
As for milking the design. Hey, they did the work and want to be paid. Others, wanting in on a nice business could do the work too. Until that investment is made, the FTDI guys earned their money.
They could choose to drop their price to help cut out the infringement too.
Up to them. I would not expect them to do that, given all that has transpired.
The correct response would have been a clearly-visible Windows pop-up from the driver that reports the incompatibility when trying to connect with a bogus chip.
-Phil
Err. teensy detail : People are not clairvoyant.
Remember, the end customer is the one bitten first here.
Until they know what is wrong, they have no options. There is no Pop-up, for example.
Their system goes flaky, they have no idea they have a Driver change that has just nobbled their system.
A technical callout, or support call is needed.
The thing is, that response means people can ignore the problem. That's an ongoing market for the free loading infringers. Got a burger the other day, and right on the drive thru screen I see a software counterfeit message. It's been there for over a year.
FTDI just isn't obligated to be nice.
So, the real trouble is all these infringing devices. Who is making those and what kind of attention should they be getting. The FTDI guys aren't the problem. These other clowns are.
That we see very little discussion on that front tells me people are going to ignore it more than they don't, and FTDI is being expected to play ball, when they don't have to do that, and apparently won't anymore.
Liability? Lol, for what? A device they didn't design, didn't support, didn't manufacture and didn't sell? FTDI can win that case.
None of this is on them. All of it is on both the infringing parties as well as anyone designing it in there and then somehow showing a great BOM cost from, "an alternate supplier", who actually infringe to make money and offer no meaningful value otherwise
Too good to be true probably is.
Again, what would you do?
Everybody, everywhere running those infringing chips really should be aware of what has happened.
I don't like any of it. But I also know FTDI really can't be made to just support infringing garbage either. Not without some compensation at a minimum. It's just not their problem.
Asking FTDI to play nice is fair, but when they say no, and it appears they have, it's time to start placing blame on the parties actually responsible for the mess.
I'm not going to get stuck cleaning up end user messes.
Lots of conversations of that kind need to happen, and again, when that costs way more than the savings from the infringing chip, I'll bet different choices get made.
That could be to avoid FTDI. Fine. How much that matters really is up to FTDI.
-Phil
1. The medical equipment contains COUNTERFEIT HARDWARE. This hardware could fail at any time, regardless of the driver update. As the producer of the medical equipment, the very fact that you have counterfeit hardware is already a major problem that has NOTHING TO DO WITH FTDI.
2. If it is possible for the medial equipment drivers (or other software, for that matter) to be arbitrarily updated without any verification, validation, or testing, there is another huge issue that has NOTHING TO DO WITH FTDI.
3. If the medical equipment has not gone through proper Failure Modes and Effects Analysis, such that a failed "FTDI" chip could cause harm to a person, then the medical equipment is already dangerous and has NOTHING TO DO WITH FTDI.
These same 3 points apply to every potentially dangerous product. And, in every case, it has NOTHING TO DO WITH FTDI.
So, please stop using the "this could harm someone" argument. It is an emotional argument masquerading as something else.
The people making infringing chips are actually criminal. Who are those people? What can be done? They have harmed a lot of other people.
However, it should be possible for the driver to add an entry to the Event Log, then just stop transferring the data altogether. I think this would be more easy to discover at the consumer level than their current approach.
I agree with your 3 points above regarding medical equipment.
However, deliberately adding to the unreliability of any equipment by injecting random data into the stream is reprehensible behaviour.
This is malware plain and simple.
That's not to say that everyone knew what they were buying. Some certainly believed they were buying genuine hardware. But, unlike the typical consumer, this community is technically savvy enough to go back to the product manufacturer and address the counterfeit issue directly. If product manufacturer cannot fix the issue, then you stop using their products and find another product manufacturer.
And, that's not to say that counterfeit parts aren't in consumer-level products. But, for the average joe, I don't think this driver update will have much impact. For those few that are affected, they will generally see that their whole device has stopped working. Nothing more. When they return the product to Amazon and write that negative review, it will be about the product, not about the counterfeit FTDI chip inside.
While not every peripheral should have a GUI component for user feedback, it's commonplace for important ones, like video adapters and printers. For commercial or industrial applications using an FTDI interface, I'd wager the use case is important enough that it wouldn't be considered cruft, and in fact could be looked upon as an important and desirable troubleshooting tool.
I agree with those who say for other applications the driver going into fault mode is not harmful in and of itself. For consumer and DIY applications, these are very likely not mission critical anyway. Yes, the device is put out of service until the user installs the correct driver, But the device improperly was using the wrong driver to begin with.
That said, I personally see no reason FTDI had to put the crippling version of their driver on automatic Windows update -- if that is in fact what they did. Also, for those who were affected by this, did driver rollback not work? Was this somehow made non-functional by FTDI? I suspect there is more to this than what's been reported so far.
I just scanned a variety of discussion on this. First, this is most likely to impact rock bottom cheap hardware more than anything else. Could be some consumer devices too.
A lot of the framing is "bricking competitors chip" and that's completely ignoring what has FTDI doing what they are doing. Producing an infringing product in such a way as to imply the original vendor supports it isn't competition at all. A competitor would have to actually release a product, do support, etc... not just mooch off FTDI.
I read the clones are coming out of China. Good luck with that IP enforcement. On that basis, can't blame FTDI. There won't ever be a requirement that their driver support infringing devices sold on the cheap. They want people to either do something else, or check that they are getting the FTDI solution, and they want that to shut out the clones.
There are quite a few comments related to the FTDI chip pricing and how that somehow justifies these "cheap competitors" Interestingly, those are the same arguments media pirates use to justify their actions too. One director polluted torrents of his production with ones filled with footage of his scrotal sac. (which is hilarious) The idea being to cast doubt on the infringing products. Another female musician looped, "you should be ashamed" to make polluted torrents.
Like the media people and that piracy going on, FTDI does have the option of changing pricing, and or doing other kinds of deals to get some of that money flowing back to them.
Based on the comments I read through this morning, anyone working on serious gear isn't worried. The various certification / verification / testing processes would not be kind to BOM changes that included infringing hardware. The underwriters would have a field day charging for that. Non issue, as has been stated here. I've been on a few projects like that, and verifying BOM items, arranging for alternative suppliers, etc... is taken very seriously. Using these illegitimate chips would be a firing offense at the minimum.
There are a ton of people who got really cheap stuff, and a lot of them are impacted. In my experience, they will hack around the trouble and continue to be very vocal about how they've been harmed, but the nice price will continue to be a draw and will prove to be a nice motivation to continue to ignore the problem. (Because pricing) There is a definite "FTDI deserves this for pricing their product high" subtext to this whole thing.
Honestly, that annoys the Smile out of me and it drains away any sympathy I might have. FTDI did the work, made a market, and prices for value. It's not cheap, but it works and it works well.
Seems to me, replicating that isn't cheap, or it would have been done and there would be real competitors out there, not infringers.
So there is an opportunity out there for someone. I'm a believer in real competition, and this niche where FTDI plays is ripe for some. Get out there and disrupt them! There is your market based solution right there. I suspect doing that just isn't easy, and it will have dubious returns, which is why FTDI is in the position they are in.
Until somebody does that, FTDI gets to price where they think the value is and these infringers and people buying their counterfeit products aren't doing anyone but themselves any favors.
The real message here is, "best make sure it's genuine" and again, I can't blame FTDI for that. And that is the reason for putting the driver on auto update. The people buying the infringing parts really aren't going to care. A few will. Those who made an honest mistake. But, the majority won't because they have a beef with FTDI pricing. Again, I find the parallels between this and media piracy very interesting! It's the same rough argument, but the stakes are higher. It's one thing to be mooching torrents. It's quite another to be shipping real products.
As you watch this play out, pay close attention to what isn't being said. I find it enlightening.
Except of course if the clone does not use FTDI's name, logos, or other trade marks or infringe on any patents they may have on the device or otherwise misrepresent itself. Building a compatible device is no shame.
I have no idea if there are such clones mind you.
However, the actions of the fakers are not the fault of end users. End users should not be inconvenienced because of this. Yes it is enlightening.
Those who condone or even support FTDI actions are basically saying that it's OK for manufacturers to fight out their turf wars on our machines at our inconvenience and expense.
I'm really not OK with that.
The whole situation is nuts. Now there are suggestions of a GUI with the FTDI driver. What?! This is a frikken UART we are talking about. An interface that is dead simple and has been around since before most visitors here were alive. Any such driver and config GUI should be part of the OS. Serial config should be part of the OS API. It should be usable from any standard terminal or serial port software.
Where did this all go wrong?
Oh, yeah. Intel. Intel invented USB to sweep all that aside.
I look on EBay and see the $2 "Arduino", but I'll never buy it because it's Smile. To those who did, and now it's not working, what were you expecting for that price?
FTDI's previous bricking episode was Smile. This one, less so, and given that they don't have a lot of reasonable options, I'm ok with it. The cloners are very directly stealing from them, and they did something about it.
There was an app developer a while ago that wrote a "game development simulator" game, like Railroad Tycoon by for games. They released a cracked / pirate version of their own game in which the story arc is affected by piracy and eventually you go bankrupt. Their forum was full of people complaining about piracy ruining the game for them, unaware of the irony. It was amazing. I say kudos to FTDI for getting creative.
http://www.greenheartgames.com/2013/04/29/what-happens-when-pirates-play-a-game-development-simulator-and-then-go-bankrupt-because-of-piracy/
"I'm not going to get stuck cleaning up end user messes." is a great aspiration.
When you "asked them to certify" how confident are you that is what will happen ?
The only way to be certain, is to do the test yourself. and add more controls to your supply lines to avoid merging products...
Of course right up until FTDI made this change, you may have already been doing all of this, but whenever their driver changes, your tests need to change.
When any given counterfeit device passes this test, what do you do then ?
The next secret FTDI driver update could see you "stuck cleaning up end user messes".
Smarter product design includes the question "How could I avoid all these dice rolls?"
What happens when your hard drive or SSD or internet connection becomes unusable because of something like this?
FTDI imagine they have the right (currently unproven) to fight this on end-users machine, which also means designers have an equal right to avoid being turf-war collateral damage.
There are driverless USB solutions out there, but I think the missing piece is HID to VCP, which sounds like an OS provider could solve ?
@all, I would be far more sympathetic to disruption of end users, given FTDI has better options. I don't see many for them.
And we've all experienced this before. Ever have your consumer gear not work due to some DRM or other?
Moving away from this mess is fair too. Will be interesting to see what people end up doing and if that ends up worth it for FTDI.
What I don't see anywhere near enough of is people experiencing their counterfeit device problems and asking why their supplier chose that route, exposing them to this Smile.
And there is. it is called generic driver in Windows, no clue about Mac and Linux.
A standard class driver for serial USB. No installation required.
No need to use FTDI ones.
Enjoy!
Mike
See my example above, for how even you can get caught - others will then claim you chose to do this.
Any links to more details ?
I find this
http://www.microchip.com/forums/m420851.aspx
Mentions HID and CDC, but both have caveats.
https://msdn.microsoft.com/en-us/library/windows/hardware/dn707976(v=vs.85).aspx
Better to not work than brick or corrupt - in either case IMHO its malware.