If they want to redesign their driver so it fails to work with non-genuine FTDI chips, go for it. Nobody will judge them. Heck if they want to show a message that informs the user they're using a fake, that's fine too.
I think most people seemed to agree that bricking fakes was too far (and also could be considered illegal in some countries/areas). It also negatively impacted innocent parties (e.g. consumers who purchased generic goods, which happened to contain fake FTDI chips).
Plus if you're in the business of bricking things, it is too easy to make a mistake and brick your OWN stuff. I mean software bugs are common, and it is best to stay away from a set of them which indefinitely makes chips malfunction.
PS - I wonder if Microsoft got in touch and essentially told them "we will pull your driver from Windows Update unless you do it first. It won't return until it is fixed." We know from the previous thread that Microsoft was looking into this.
What I don't understand is why they don't make the messaging more clear. In their pre-bricking drivers, FDTI caused the counterfeits to fail in confusing and counterintuitive ways, rather than just telling the user that the chip is fake.
As a user, if my device stops working randomly, my first thought is certainly not "there was a counterfeit chip in the supply chain for this hardware and the drivers must be rejecting it!"
A little bit more user notification around "you have a counterfeit FTDI" or, even better, a tool to find out if your FTDI is fake would be a lot better than "oh, you can tell if the chip is fake because it will only work properly with drivers before 2.08.14, otherwise it will randomly crash!"
Prolific do the same thing, but their drivers at least fail to start with a common error code which is easy to Google.
"""
As a user, if my device stops working randomly, my first thought is certainly not "there was a counterfeit chip in the supply chain for this hardware and the drivers must be rejecting it!"
"""
Yep. Believing the consumer cares about your product as much as you do is a line of thinking that's easy for engineers to fall into when their lives and livelihoods depend on the product. It's why smart companies employ someone with the capacity to sit in a more objective position to evaluate the market and public perception.
Do we have evidence FTDI was in fact making the counterfeits randomly fail on purpose, separate from this bricking thing? Hanlon's Razor is still worth thinking about.
For example I have a Prolific chip that is almost certainly a fake that only works with driver X.Y.Z, I always assumed that was because the fakers targeted that driver and made an imperfect spoof.
The Prolific counterfeit protection is documented as being explicit (and not the result of an accidental incompatibility): Prolific introduced a check in later drivers which requires a specific response the fakes didn't implement.
Thankfully, Prolific chose to simply prevent their drivers from starting with an easy-to-Google code, rather than causing frustrating failures or bricks.
I would assume but honestly don't know that the FTDI random failure code was also intentional. All signs point to intentionality: it appeared in all drivers after a specific version, was accompanied by a change to the EULA indicating that counterfeit chips wouldn't work, and accompanied a lot of messaging from FTDI about avoiding counterfeits.
I suppose someone should break out a disassembler and some USB snooping tools to check for sure.
Part of the way that manufacturers convince customers that counterfeit chips are unacceptable is by pointing to a higher rate of glitches and failures. Perhaps FDTI wanted counterfeit chips to get an (at least partially undeserved) reputation for shoddiness rather than be seen as artificially refusing to work with counterfeits.
I don't think that is very straight forward. It's easy to know how your device will operate in various conditions. counterfeits can fail in a million unpredictable ways.
FTDI have code which can tell with some high degree of certainty (at least enough that they trusted it to brick devices!) that a chip is fake.
They've used this code to make counterfeits intentionally unpredictable in the last few versions of their driver, rather than simply stopping the device with an error code (like Prolific do) or notifying the user or client library (like all of these vendors should be doing).
So, for FTDI at least, it should be very straightforward to do something other than intentionally making fakes of their devices behave unpredictably.
Someone at the eevblog analyzed the file. It's setting the PID to 0 in a way that on genuine chips it will only buffer the change, and not actually apply it. If it wasn't a manufacturer with signed drivers pushing this on windows update but a guy at DEFCON explaining his trick I would find it very cool.
They might not have the ability to do that - I could quite easily see the bit of code that can tell if its fake being the same code that bricks the device. Maybe all the real ftdi chips will reject a PID of 0 (as it's invalid), while the fake ones accept it.
Their drivers prior to the bricking drivers (everything after 2.08.14) caused the fake devices to fail, where previously they hadn't.
Whether or not that behavior was intentional, there is clearly an exploitable property of the fake devices which can determine that they are fake without bricking the device.
FTDI should use it rather than playing these games. Their reaction to the discovery of the bricking issue on Twitter and elsewhere yesterday strongly suggests that it was anything but an "oh shit, our driver bricks some of those crappy fakes" moment.
FTDI was asked to return a string like "COUNTERFEITCHIP" or something similar instead of returning zeros, so they instead did a PID reset or some such to disable instead.
A bunch of chips failing with COUNTERFEITCHIP may have been pretty obvious
" In their pre-bricking drivers, FDTI caused the counterfeits to fail in confusing and counterintuitive ways, rather than just telling the user that the chip is fake."
Or maybe because the fake chip is not working in some corner case exactly as the original chip?
It's probably not something deliberate.
Edit: Do you really think the manufacturer should test their driver agains all fake chips and see how they behave? Really?
They test their chips and their software first and foremost. What happens outside of that is not their responsibility.
I don't think the argument here is to test their drivers against fakes. I think the argument is against /intentionally harming/ fakes vs. throwing an error. I'm also against the "random malfunctions" feature, if that was also intentional, which it sounds like it was.
> and also could be considered illegal in some countries/areas
Is there some country where it's legal to break somebody's property because you have a beef with a third party?
Certainly in the US if somebody produced a virus that did this nobody would even blink at a federal prosecution. That FTDI slipped a bit of text into a document nobody reads doesn't strike me as relevant. If a piece of malware also popped up an innocuous dialog with a terms link and a user clicked ok, nobody sane would say that the malware-writer was legally in the clear.
If FTDI doesn't end up prosecuted over this, I think it's less about the relevant laws and more about how prosecutors view people with money and status who commit crimes in pursuit of profit. Versus, of course, somebody like Aaron Swartz, who not only failed to wear a suit, but was engaged in a political act against the status quo. Crime that improves profits is currently more acceptable than crime that harms profits.
What's your opinion there on the odds of prosecution for something like this? I have the (possibly media-driven) notion that the UK has a stronger tradition of public service. But then you also have a more explicit class dynamic.
"Microsoft has given us a statement: Yesterday FTDI removed two driver versions from Windows Update. Our engineering team is engaging with FTDI to prevent these problems with their future driver updates via Windows Update."
It's also important to keep in mind that the driver bricked not only counterfeits that were illegally marked with FTDI's name, but legal clones (reverse-engineered reimplementations which are not marked as being from FTDI) that had the same slight difference in behaviour from the original.
The reverse-engineered reimplementations / clones would have to have been programmed with an FTDI VID (or included modified FTDI drivers) in order for the FTDI drivers to claim them, so I'm not so sure about the "not marked as being from FTDI" bit.
That's an interesting question. Is the VID a signal of protocol compatibility? Or a brand name?
In a way it's both, but since end users almost never see the VID, I suspect a lawyer would have an easy time that under the law it's more the former than the latter, and therefore not covered under trademark and related laws.
Especially since it's the only way to be compatible as far as I know (since (VID,PID) determines the driver that will get loaded for proprietary protocols).
Also.. Can you even claim any special rights to a non-government registered trademark/brand name (one that is registered at a non-government entity - the USB Implementers Forum in this case)?
It seems like trademark would be really difficult to attach to (VID, PID) if no one in the supply chain actually used any USB-IF logos. Basically FTDI assumed a right to destroy property based on a violation of a contract neither the property owner, nor any of the chain of vendors that produced the property, had been a party to.
That's a good lesson for people always wanting the famous brands. FTDI chips are more expensive and not better than the other ones, they need a special driver and they are subject to counterfeiting. You take a no-name one, and you have a standard stuff.
It's a stupid USB to RS232, not a rocket control system, there should be no famous brand, it's the lowest of the commodities.
That said, I do have an FTDI USB to serial adapter (no idea of the authenticity), because I didn't know better or care, I needed to plug my MCU board to my computer and I bought the first one I found (and it's just used for debug, I never ever use serial in real life).
The FTDI chips and drivers also have the ability to toggle a few extra pins. If you are making a device this can be important enough to lure you away from just being a generic USB Communications Device Class profile. (Think a 'reset' function or a 'enter firmware update mode' function.)
Given that as a consumer/purchaser I have no way of knowing if I have a counterfeit chip or if the next batch produced by a manufacturer will have them… I now have an incentive to avoid FTDI entirely when given a choice.
Good remark. I didn't think about that, because I use a real USB chip for USB, I don't try to convert it to serial (I like the idea of having various communications going at once, the stall, etc.)
Does a lot more than just RS232. I believe it supports almost all serial protocols. Depending on what you're doing, it could be much more than just a simple display tty.
Is there even such a thing as a generic usb to serial chip for Windows? I ordered some ch340g chips from China, and now an nervous about installing a driver that might be malware.
Good, destroying a device you legally purchased is unacceptable, whether you knew it was a counterfeit or not. It's not their job to police that kind of stuff.
Failing to work with counterfeit devices is completely fine and would have been a much better approach than straight up bricking them.
Yeah, but looking at the physical differences between the chips it's probably not something that difficult to ensure. The counterfeit chips are built in a totally different fashion, with different size and materials, on a different process tech.
But that's impossible for something like a Windows driver to determine.
The only way the FTDI driver could determine if the chip counterfeit was a slight difference in how the counterfeit chips handled a certain EEPROM write. And the counterfeiters will be sure the next revision of the chip takes care of this corner case.
Sure, the driver doesn't know the manufacturing process. His point is the chips are simply so different, there are bound to be obvious ways for the driver to tell.
If the chip manufacturer needed this incredibly subtle trick to determine a real chip from a fake at the driver level, what does that say about how close the counterfeiters got?
The chip dies may be incredibly different, but the fake operated 99.99% like the real one. There were no "obvious ways" to tell them apart.
In the US there isn't a legal way to purchase counterfeit goods. It may be different in other countries. Similar to stolen property, the person left holding the bag gets in trouble too.
Edit: after actually looking up the issue instead of guessing it turns out that in most places (other than France and Italy) there isn't much at stake for the end user, and almost all of the laws are written to stop the sale or manufacture of counterfeit items.
> "In the US there isn't a legal way to purchase counterfeit goods."
Sure, but the mechanism for combating counterfeiting is the government and law enforcement organizations, not unilateral action by the aggrieved party.
FTDI has no authority - moral or legal - to be bricking devices. This is vigilantism.
It is however perfectly legal to make a hardware device that could make use of the Same API and driver i.e a clone. Provided it is not branded as a FTDI chip, but rather "FTDI Driver compatible"
Now that may violate the terms and lic of the driver software on windows (not on linux because it is GPLv2) but that would not make it illegal to buy nor would it give them (FTDI) the legal right to modify that hardware
Using the FTDI vendor ID is branding it as an FTDI product. I would argue that it is even more important than the text printed on the chip since that is the part of the brand that the average end user is exposed to.
There doesn't appear to be any legal protection on USB vendor IDs though. It's just important if you want to follow the rules of the USB-IF, but that's no legal requirement.
It's interesting watching this play out with reputable, legal companies.
Something similar happened earlier in the year with Nintendo 3DS flashcards, however the software was not just disabling the flashcard, but would brick the users 3DS.
Their response was essentially, "Yeah? What are you going to do about it?" and promising to replace the 3DS of anyone who could prove they were using a legitimate card.
I wanted to reply with a quick note to clarify to those quickly reading this post that it was the flash card maker, not Nintendo, adding the bricking code.
Your post is accurate, but to those not already familiar with this incident (such as myself, until I searched for stories about it), a quick read will give the impression that this was Nintendo's doing, when it wasn't.
Few will be surprised if prosecutors are found to care more about shenanigans in the MS-Win ecosystem than those in the Nintendo ecosystem. Actually FTDI may be in more danger from class action tort lawyers. This is almost a perfect class for them, in that lots of people suffered a limited but not negligible harm.
Correct. Most arguments seem to assume that FTDI is either 100% responsible for damaging hardware that doesn't belong to them, or 0% responsible. Clearly the company itself assumed the latter position would prevail in each and every jurisdiction where people use computers. I don't know what sort of drugs they had to take to arrive at that conclusion, but I don't want any, thanks.
One big problem is that civil courts in the US do not work that way at all. FTDI could easily be found 5% responsible for an enormous judgement.
At the time they were the only functioning solution (They may still be? I'm out of the loop now) and everything else on the market were clones of their cards.
It was almost like a hostage situation with the community, a lot of people hating on the company, while hyping up their next update.
We do not want to set a precedent whereby a company responds to customer feedback, and then gets hit by a huge lawsuit anyhow. That just incentivizes companies to dig their heels in, because it means there's no change in outcome between speedily responding and trying to stay the course, at which point staying the course is the only sensible choice.
There's a time and a place for mercy, and giving positive feedback to the company for rapidly reversing course. They ate their crow; save the nuclear escalation for a company that refuses to.
Bluntly? Fuck 'em. The only reason they "responded" apparently is because Microsoft tapped them on the shoulder, by way of yanking their updates until it gets fixed, and then only because someone publicly connected the dots as to what was going on.
There is an untold amount of bricked gear out there. Those people are entitled to replacements and compensation for their time spent dealing with this malfeasance.
No, this isn't "responding to customer feedback". The code they published was pretty much illegal - imagine your garage destroying your car because it's the wrong brand! Their reasoning should be (and probably was) "by fixing this fuck-up ASAP, we'll only get a class-action lawsuit by 10K customers, instead of by 100K".
They have already damaged my equipment. I don't give two shits about hurting a corporation's feelings. They've already hurt my physical items. Once they've gone down that path, it's now an actionable tort. I can't believe their legal team approved of this.
What specific piece of equipment was affected? (not doubting - just curious, as I've not come across specific examples of people being affected by this driver)
35 devices put together by students doing EE projects... well, that's annoying, but they are at least direct consumers/users of the counterfeit components - presumably they have the option/ability to replace the chip with a genuine one once they source one. I've yet to hear of any end user finding that a commercially purchased peripheral has been bricked by this driver because its manufacturer used counterfeit parts, though. Would be fascinated to hear about such an example.
No equipment was destroyed by the old driver: the old driver set a word in the firmware of counterfeit devices to zero. All that needs to happen to reverse what some comment-writers are calling "bricking" is to set the word back to its original value. The new version of the driver could probably do that.
I'm not an expert on USB protocol, so I'm not sure how your suggestion would work. The driver bricks it in the sense that the Product ID of the device is wiped (zero'd). As a result, the OS doesn't know what to do with it or what drivers to connect it with.
Is there some signature to the USB device that would allow the OS to know what to do with the affected gizmos? Or do you have to explicitly tell the system "no, really, the device on this USB port is specifically this"? If it's not automatically deployed like the initial driver but rather actually requires the user to screw with firmware-style updates, then it's effectively ruined for many beginners with these chips. (Thankfully, there's been a lot of fuss over this, so newbies will likely be able to troubleshoot this problem after a few hours of groping in the dark for why their device has gone silent.)
Dang. If a person's not familiar with the ins and outs of USB protocol, I'm going to bet they're not going to be able to think up or through that procedure. At best it'd just be some incantation to recite in the hopes the gizmo comes back to life. And if you're using the FTDI chip specifically because it abstracts away serial to USB communication stuff, well, hopefully the device is cheap enough to just replace.
Still, perhaps it could be automated somehow via a responding Windows Update? That's the thing that gets me - it was autmatically propagated, it oughtta be automatically fixed.
Bricking is exactly what you describe - the device is not usable after the driver sabotages it. Bricking is a common description of a device made non-functional by interrupting a firmware upgrade process. It's not destroyed, and can be restored to functionality by special tools. But as far as the user is concerned, the device is broke.
"Bricking" doesn't mean a device is completely demolished, just that it's basically been rendered into a useless lump, especially via corrupt firmware. Even a 'hard' bricked device can sometimes be recovered via JTAG.
They really should. Class actions are an inferior mechanism for both parties anyhow. The lawyers sitting in the middle will make it so it's radically more expensive for the company, and the odds of the supposed "winners" of the class action suit will probably get uselessly small vouchers for service rather than actual replacement.
"Class actions are less about compensation and more about forming big enough sticks to beat misbehaving corporations about the head with.
"
Class actions were never about this until recently . The original purpose was to make it easier to manage the case (vs 50 separate cases) for the justice system. It was about "the efficient administration of justice". Nothing more, nothing less.
When they were created (out of thin air) in the US, this was the goal. AFAIK, nobody thought about, or wanted, what has happened now. It's not even a good vehicle to accomplish "beating misbehaving corporations" , because when used for that purpose, it mostly makes money for lawyers, encourages nuisance suits, etc.
The we can do what the US Coast Guard does about oil/fuel spills into water. You're guaranteed a fine when it's reported. However, the fine is lower if you report it yourself. Gives a clear incentive for the ship operator to report their spill rather than someone else who happens to find it.
Given their initial reactions on Twitter, I don't feel bad if they get taken to court over this. As others have mentioned, they only agreed to rapidly reverse course after Microsoft put them in time out.
- unbrick devices they bricked, so the chips will at least work with drivers other than theirs
- log something to the windows event log about a clone device being detected
It's their choice whether they should work with the clone device or not; I would hope they would choose to. I understand their reluctance, but people are going to be only slightly less mad about a device not working than a bricked device.
It would be bad for their driver to pop UI warning about a clone device. Drivers that do this make life very, very difficult for devices attached to headless servers (also, I believe it's against the MS WHQL rules).
How would they unbrick a device? By definition, to "brick" is to render the device inoperable.
A friend of mine, in the course of his work, bricked a BMW [1]. It took an engineer, flown in [2] to fix the issue.
[1] He worked at a company making automobile diagnostic tools for mechanics. He was reflashing the BMW when the power went out. That scrambled the on-board computer system enough to brick the car.
[2] South Florida (Miami/Ft. Lauderdale area) I'm sure the German engineer wasn't all that upset.
To misquote The Princess Bride: "This device isn't bricked. It's just mostly bricked. There's a difference."
The device is still there, and it will talk, there's just no matching driver in the system for it now.
So you add PID=0x0000 to your existing driver (I think this is just an edit to the INF file on Windows) and sniff the device to see if it's one you've likely (semi) bricked, and make the attempt. You own the VID, so this operation should be safe in your namespace.
Brickness is a measure of the user's ability and motivation to restore a device. I've worked on systems where you have to unsolder really tiny devices in order to unbrick. It's a continuum of inconvenience, really. To most users, the evil FTDI driver made a brick because it was beyond their skill to do the repair (hey, you can write a driver for PID=0x0000 any time you want to, oaky?)
They get a special icon in "Device Manager", and, if I remember right, the statusbar-thingie that dances around while newly-connected devices are detected will put up a bubble with an error message.
Cause Linux has drivers that support it already, that are a part of the kernel. Not likely that FTDI'd manage to get the kernel devs to add bricking code like this. Kernel devs already added code to handle devices that had been messed up by the drivers, actually.
Because windows drivers need non-trivial amounts of support in the form of driver development kit and driver signing. Then you run into issues with which driver to pull for the chip, cause now you are conflicting with FTDI's driver. Other chips that aren't clones do have their own drivers.
Seems a lot of the posts on that thread are from HN visitors, many may not even have the equipment/chip in discussion.
While it's great FTI reversed their decision (I'd hate to see this sort of thing become wide-spread), it's a little off-putting that so many non-users of the chip could force a company into something.
No, but suppose this was another scenario, such as automatic product bagger/sealers and some counterfeit part was being bricked by the original manufacturer. I doubt anyone outside of the warehouse/manufacturing industry would care, nor would anyone outside that industry have any real right to care.
In the FTI situation, I'm indifferent, but I just don't like the "crowd mentality" thing where people get stirred up about things that only a few hours ago, they had no idea even existed.
The company I work for uses (genuine) FTDI USB-Serial converters in our $500,000 medical instruments. I have full confidence in our Supply Chain Management people, but mistakes happen. If we were to send out a field upgrade to the instruments, as happens periodically, and some of them had the counterfeit chips, then suddenly there are patients all over the world, many in Emergency Rooms or Intensive Care, that can't get their test results because instruments are down.
This can affect many, many people not in a particular industry, depending on where the device is embedded.
As soon as I heard about this, I notified our senior design EE so he could pass the information on if necessary. This is not to be taken lightly.
The scenario you present is a little "doomsday". You'd have to replace all of your deployed product's chips with cheap counterfeit ones for this to happen -- and you say you have complete confidence in your supply chain.
My warehouse has a couple Sharp Max baggers w/ counter and sorter, which are just as expensive as your medical instruments. The electronics check to ensure you are using only the Sharp brand parts, otherwise the machine refuses to work.
Most printer cartridges won't work in printers unless they are the name-brand cartridge (printers read the chip on the cartridge).
Neither permanently damage the counterfeit parts, but it doesn't matter much if you can't use the counterfeit part you just bought (thinking you were going to save a buck or two).
Frankly, I don't buy the argument that a lot of users didn't know they had bought counterfeit. For a device that retails for $15 and you got it new for $1.50, well, something is up.
Perhaps a better way for FTI to go would be to detect the counterfeit when it's plugged in, then just refuse to do anything with it. (although this would allow someone to get a non-FTI driver to work)
All it takes is one bad chip in a critical location in one instrument and that instrument is down, or at least rolled back to "limp mode" depending on which feature the chip supports. That instrument may be processing hundreds or thousands of patients a day if it is installed in a large medical lab. Do you see the problem here?
Sure, an Emergency Service Call will take care of the problem, but that can take hours (over a day in some locations).
Steep discounts for volume are the norm. Its arguable that the consumer doesn't know nor care why the discount; as long as the vendor/product passes a qualification test.
Not to mention that he's assuming the cost was different. Many companies have to deal with counterfeit parts (we have) and often the only difference is that they either outright refuse to work (good!!) or fail early (very bad).
> While it's great FTI reversed their decision (I'd hate to see this sort of thing become wide-spread), it's a little off-putting that so many non-users of the chip could force a company into something.
A wide variety of non-users of the chip have a very strong interest in Windows Update not becoming a vector for malware. I doubt this situation would have gained the quick public notice it did if it had been the work of a driver available for download on FTDI's website.
It's their driver, it operates in a specific way, perhaps responding to possible device output. Using it with non-compatible parts advertising themselves as compatible and any resulting behaviour, including unwanted, is the responsibility of the user. To play it safe, don't use any drivers with incompatible hardware.
You'd be right if this weren't just a chip buried in a device. To properly implement that, we'd need to be able to safely scan and verify devices on the chip-level. That's not really an option. The end user is only ever going to be informed by the driver telling them it's invalid; in this case the notification is the silent crippling of the gizmo, with no feed back or diagnostics.
As many have noted, all that's needed is an alert for the user that the driver's incompatible. That way the user can take rectification measures, be it getting new compatible chips/devices, or using unofficial drivers.
Alerting the user from a driver is a bad, bad thing.
I believe it is not allowed by WHQL certified drivers.
(It's also non-trivial to do in a Windows kernel driver. You can't call MessageBox(), you can't process user input, you can't even get a context to draw on the screen. Basically you have to rely on a user-mode helper app that gets launched at boot time, which is one of the reasons you see so many device-tweaking utilities for graphics cards and sound cards).
That's reasonable, until they start deliberately destroying my property. Then its a civil case. Do we have any evidence either way, deliberate or accidental?
They figured out how to program the clones without programming their own chips. Looks freaking intentional to me, I don't know any reason to send commands to write to an eeprom and do a pre-image attack on a checksum just on opening a connection. Also explains why just the PID is changed, not the VID. It would have affected their chips if they tried changing the VID.
Do you have any evidence specifically that their driver destroyed your chip, or could there be reasonable doubt that your counterfeit chip died? For a class-action suit that a lot of people seem to be talking about, you would have to have evidence that this was what did your chip in. And getting enough people (who appear to be mostly end-users) to submit the necessary evidence could be quite the task (most probably will just assume the device croaked one day and toss it out).
well, the PID is not a physical thing. So for the average user, "the board just died on my one day". Getting wide-spread testing and evidence submitting would be challenging I think.
I don't see why that would be more challenging than any other class-action suit. Indeed, this looks easier, in that you have widespread media coverage and plenty of experts speaking out publicly. It's not a question of trying to find experts qualified to testify; here, you can pick from a bunch. The technology here is also much more straightforward than, say, an automobile, and there are successful class-action suits involving those all the time.
there isn't really any media coverage, other than the forum posts and HN. Also, using your automobile example, an average-joe consumer can take their car into a mechanic and have it tested for a recall/defect. The average-joe with an arduino is far more likely to toss the defective unit out, rather than try to spend a while troubleshooting a $40 board.
I just don't see a class-action really able to take off. Especially since we're talking about otherwise illegal counterfeit chips in the first place.
The line of argument "I, as some random anonymous person on the internet, can't see X" doesn't do much for me. Lots of people can't see lots of things, but most of the time that turns out to be about failures of knowledge or imagination, not evidence that that what they're talking about is impossible.
Further, I don't think it's really my job to make people see things. (Well, actually, it is, but I charge by the day for that.) If you don't see it, I can live with that.
Not entirely sure what your argument was here, you sort of drifted into the weeds a bit.
I think you meant to argue:
"There is one source of media coverage, although it's largely just twitter comments. And just because something is difficult to prove doesn't mean it's not provable."
Both are valid arguments.
I don't count ZDnet as a very credible source of news, and in this case, some googling seems to show they are practically the only "news site" running this story. Although, as pointed out, it's mostly just a paragraph followed by several twitter posts.
Secondly, the evidence thing is important if a case like this were to proceed. In order to sign onto the class action, you would have to prove you purchased an effected chip/board, and that this driver is what killed your product.
Two problems here:
1) You bought a counterfeit chip/board. It's unlikely any award will be levied for illegal/infringing products.
2) Users would have to show evidence they were effected. Even in the RedBull class action case that is settling now, you must prove you bought a RedBull during the time period the case covers (receipt or whatever). Again, you have a counterfeit product, which was illegal to sell/buy in the first place. Not to mention, getting average-joe to test his device, even if someone made a testing utility and freely distributed it, will be close to impossible. People who are technical and care may do it, but average-joe will assume his arduino went belly-up one day, and likely toss it in the garbage.
Let's be realistic. A handful of people in-the-know will care passionately, and do everything they can to further a claim. Several handfuls of people will care enough to do something if they believe they will get something in return (a payout). The rest will have no clue this is even a thing, and will simply throw away their "defective" device.
What FTI did was wrong. But there is no real recourse here.
Check other posts on this HN story; others have proven the drivers were deliberately malicious by analyzing either a USB stream or a driver disassembly (I haven't read enough to know which).
The problem isn't knowing the driver itself can cause a bricked chip and therefore bricked device.
The problem is Joe-Average isn't going to be able to prove it was this driver and not just a defective device/chip for another reason. Even with a free "testing" tool someone can make to check for the flipped PID bit, Joe-Average has no clue this is even going on, and is likely to just throw away his bricked device.
Even if such existed (it does not), this standard is not applicable to a civil case, only to the criminal trials for destruction of property/malicious mischief that every single person involved should have to go through.
For counterfeit/illegal property? This seems reminiscent of the guy who bought cocaine from his dealer, found out it was cut with flour, then tried to file a police report. I'd think you've had a tough time convincing a judge that you genuinely believed the chip/board you bought from some shady seller on eBay based in China for pennies on the dollar was a legit product.
None-the-less, someone will try I'm sure. Then everyone can enjoy the $5 check they get in the mail 1 year later.
This has been thoroughly covered in an earlier thread[0]. The chips do not in themselves violate any law. To whatever extent there may be a trademark violation, that is between FTDI and whoever mislabeled them. None of this entitles FTDI to destroy anyone's property. That's a crime.
What is the limit there, then? Would it be ok for the chip to, say, install spyware to look for my credit card data and steal money from me? That is also "unwanted behavior".
I would be ok if the driver simply refused to work. But making hardware unusable on purpose is too much.
Doing things not related to interacting with, or "driving", the hardware is the limit for a good device driver. For software in general, not all forms of spyware are illegal (but stealing money is, at least in my jurisdiction).
Whatever the code for changing the PID is, it (supposedly) would work as well for a malfunctioning but real product, as well as a counterfeit.
Since the "making the hardware unusable" step is just setting the PID to 0, the slope doesn't seem too slippery to me. If the manufacturers of the counterfeit chip had their own PID and Windows drivers, they wouldn't have used FTDI's. FTDI here is merely enforcing that chips which are not theirs don't use their PID.
I agree that their updated driver will probably continue to not work with these counterfeit chips, and while it shouldn't mess up the chips' functionality in Linux, fixing the PID in Linux is fairly straightforward.
In the case where the driver will continue to not work with these chips, "bricking" only refers to not resetting the PID which causes the device not to work in Linux as well.
If they want to redesign their driver so it fails to work with non-genuine FTDI chips, go for it. Nobody will judge them. Heck if they want to show a message that informs the user they're using a fake, that's fine too.
I think most people seemed to agree that bricking fakes was too far (and also could be considered illegal in some countries/areas). It also negatively impacted innocent parties (e.g. consumers who purchased generic goods, which happened to contain fake FTDI chips).
Plus if you're in the business of bricking things, it is too easy to make a mistake and brick your OWN stuff. I mean software bugs are common, and it is best to stay away from a set of them which indefinitely makes chips malfunction.
PS - I wonder if Microsoft got in touch and essentially told them "we will pull your driver from Windows Update unless you do it first. It won't return until it is fixed." We know from the previous thread that Microsoft was looking into this.