What if FTDI decided to optimize the driver to bring new functionality to their ftd2xx.dll library and for whatever reason some clones would act erratically midstream after the device and the program have already established a handshake.

It's in their best interest (FTDI's) to detect and refuse to work with cloned chips at initialization, otherwise they might be liable if they attempt to communicate with devices not designed by them and that might not be up to spec for the driver's features.

So yeah, you can turn the whole thing around legally and FTDI can be firm to state that they don't want to be liable for talking with unknown chips with unknown characteristics.

Personally I agree 100%, I'd be totally okay with it refusing to work with known clones on the grounds that they're unpredictable. Quite a different thing from intentionally malfunctioning.

Logged

No longer active here - try the IRC channel if you just can't be without me

I want to see how many here will try to defend their actions - they have all the right to refuse work with non-original and potentially counterfeit components, right?!

I'll bite. What Apple is doing here is bricking phones that have potentially been stolen and the button (which is also the fingerprint sensor) replaced to gain access to the stolen phone.

Stolen phones are a big problem and I fully support any efforts on the part of the manufacturers to render stolen phones useless to the thieves. That's the only way to solve the theft problem. If a few innocent people inadvertently get their phones bricked as a result, then that's probably the price we have to pay to solve the greater problem of phone theft.

Yup, also agree 100%. The implications for self-repair are unfortunate, but pretty much a necessary consequence. Personally, I would never buy an iPhone because of the lack of user-"serviceable" bits - I specifically chose my most recent phone for the removable battery and SD slot, for instance - but that's me, I totally see why other people would like them.

Logged

No longer active here - try the IRC channel if you just can't be without me

Stolen phones are a big problem and I fully support any efforts on the part of the manufacturers to render stolen phones useless to the thieves. That's the only way to solve the theft problem. If a few innocent people inadvertently get their phones bricked as a result, then that's probably the price we have to pay to solve the greater problem of phone theft.

People die of liver cancer. So let's remove everyone's liver, healthy or otherwise, in order to prevent liver cancer.

Reminds me of Angelina Jolie, who removed her breasts and ovaries just because she was afraid of cancer. She wasn't even diagnosed yet, she only found out that she's got the mutated gene, so she just went and mutilated herself. Brilliant.

Logged

"The nice thing about standards is that you have so many to choose from." (Andrew S. Tanenbaum)

What if FTDI decided to optimize the driver to bring new functionality to their ftd2xx.dll library and for whatever reason some clones would act erratically midstream after the device and the program have already established a handshake.

It's in their best interest (FTDI's) to detect and refuse to work with cloned chips at initialization, otherwise they might be liable if they attempt to communicate with devices not designed by them and that might not be up to spec for the driver's features.

So yeah, you can turn the whole thing around legally and FTDI can be firm to state that they don't want to be liable for talking with unknown chips with unknown characteristics.

It's perfectly ok when the driver stops talking to the fake chip, but it's no ok to brick it or to send some modified data which could cause any damage. And bonus points for a driver which tells the user about the fake chip.

Stolen phones are a big problem and I fully support any efforts on the part of the manufacturers to render stolen phones useless to the thieves. That's the only way to solve the theft problem. If a few innocent people inadvertently get their phones bricked as a result, then that's probably the price we have to pay to solve the greater problem of phone theft.

People die of liver cancer. So let's remove everyone's liver, healthy or otherwise, in order to prevent liver cancer.

When you can't come up with an intelligent argument to get your point across, resort to the most extreme straw man possible.

FTDI distribute their driver through the official mechanism on Windows, it's essentially part of the operating system. What the hell is wrong with using it? If they don't want people using their driver they shouldn't give it away.

So let's say that someone cloned Nvidia's graphics chipset and made their own board--should they just piggyback on Nvidia's drivers (which are part of Windows) rather than writing their own? Nvidia has invested millions in writing these drivers and it's a key part of their IP. Where do you draw the line?

So let's say that someone cloned Nintendo's GameCube gamepad protocol and made their own controller -- should they just piggyback on Nintendo's system and software rather than developing their own? Nintendo has invested millions in designing this hardware and software ecosystem and it's a key part of their IP. Where do you draw the line?

So let's say that someone cloned Microsoft's SMB protocol and made their own compatible implementation -- should they just piggyback on Microsoft's SMB subsystem (which is part of Windows) rather than writing their own OS? Microsoft has invested millions in developing this protocol and integrating it into their OS and it's a key part of their IP. Where do you draw the line?

Oh wait, it's called Samba, and MS was actually ordered by the European Commission to supply the Samba developers with protocol information, as part of an antitrust case.

Are you sure you didn't get the two mixed up? Or perhaps they're both actually clones, but one passes the test enough to identify as genuine?

AFAIK the clones use a microcontroller whereas the genuine ones are a full ASIC. If true, funny to see the former beating the latter in timing stability... it's usually the other way around.

Totally sure. It's a documented errata of the FT232R that was never fixed as far as I can tell, and there is no usable workaround (the workaround in that PDF is total bullshit, because you can't actually feed it data fast enough through USB to keep up with the max bitbang clockrate). The clone chip got it right. The errata PDF actually goes out of its way to be misleading and imply that the bug is fixed in Rev B, while it isn't - of the 3 issues documented, two say "fixed in rev B", but not the timing issue, and the Revision B section says "There are no known new functional issues specific to revision B.". I can confirm that genuine revision C chips are still bugged in bitbang mode. So, two silicon revisions later FTDI still hasn't fixed their broken bitbang mode, while the cloners got it right on the first try (as far as I can tell).

I want to see how many here will try to defend their actions - they have all the right to refuse work with non-original and potentially counterfeit components, right?!

I'll bite. What Apple is doing here is bricking phones that have potentially been stolen and the button (which is also the fingerprint sensor) replaced to gain access to the stolen phone.

As far as I can tell, Apple isn't "bricking" anything, or at least we don't know that they are. Bricking implies deliberate action. FTDI was bricking devices - they wrote code for that purpose. iPhones are getting bricked, but we don't know that that was a deliberate choice.

We know that the home button sensor is paired to the phone (this is part of their security architecture, not some anti-repair crap). This just sounds like their update process makes the assumption that your home button module is the right module for your phone, and then when it isn't something goes wrong and it explodes. The "bricking" is just a consequence of the restore getting interrupted halfway through.

I'm usually one to bash Apple for their anti-competition, anti-third-party practices (they try really hard to stop Linux users from syncing music to their iPhones), but in this particular case, we don't really have any evidence of deliberate malicious action here, at least not yet.

So let's say that someone cloned Nvidia's graphics chipset and made their own board--should they just piggyback on Nvidia's drivers (which are part of Windows) rather than writing their own? Nvidia has invested millions in writing these drivers and it's a key part of their IP. Where do you draw the line?

Nvidia releases the driver to microsoft who distributes it gratiously to the user. The user does not sign an EULA for that driver, so he can use it for anything he wants, including reverse engineering it. You can also use the open source "nouveau" driver, which was developped by the community.

Now for a moment, let's assume Nvidoa had another buisness model. Nvidia does sell their driver and give away their board for free. You could use the graphics card with the open source nouveau driver, or you could purchase a right to use the proprietary GeForce driver. No problem with that. You can't give away something to people and try to restrict how they use it.It's NVIDIA who does put a the line on what they want to give away.But, if the boards Nvidia gives away put fire to your home, didn't respect ROHS, EMC, safety, or other regulations, they would still be liable. Exactly like people are angry at FTDI intentionally corrupting data.

Besides, it's true that another company is not supposed to use the VID/PID. But you are allowed to do such tricks for the sake of compatibility. Of course, it'S not a "USB" peripherial, because the USB consortium restricts the use of their brand to their members, and to using only their assigned VID. In short, you should not put the logo "USB" on the product. But you can sell it legally.

So let's say that someone cloned Nvidia's graphics chipset and made their own board--should they just piggyback on Nvidia's drivers (which are part of Windows) rather than writing their own? Nvidia has invested millions in writing these drivers and it's a key part of their IP. Where do you draw the line?

Nvidia releases the driver to microsoft who distributes it gratiously to the user. The user does not sign an EULA for that driver, so he can use it for anything he wants, including reverse engineering it.

This angle has many similarities of companies cloning Intel's x86 architecture. It turned out Intel couldn't do anything about it!The legal problem for FTDI is that their driver comes with Windows and is installed silently without the user acknowledging the driver may only be used with hardware made by FTDI.

Logged

There are small lies, big lies and then there is what is on the screen of your oscilloscope.

We are not talking about FTDIgate 1.0, bringing that up (the bricking) just muds the waters of the current situation and it's just used to distract the topic at hand, not helpful at all.

Perhaps you aren't but many of the people here are and have been discussing FTDI's actions in toto. It's their pattern of response to this issue that is telling - even if their most recent driver is less bad.

I think based on the numerous posters here and on other sites like Hackaday who have stated they are no longer designing products with FTDI chips due to their actions as well as the numerous people stating they will no longer buy a product with an "FTDI" chip due to the risks involved shows that FTDI has already lost.

Out of curiosity - I just did an ebay search for "USB UART TTL serial converter"and was shocked to see how many of the listings specifically list alternative chips in the title. I don't remember that being the case in the past (before FTDIgate 1.0)

Also - I defy anyone here who says - "just don't buy a cheap device and you'll avoid risking getting a clone" to point out which of the FTDI listings are guaranteed fake. And BTW - I just tested one of the listed $2 FTDI converters which I bought several years ago and turns out the chip on it is not fake - go figure.

FTDI has clearly lost this battle and all their doing now is speeding up the decline of their USB-serial converter business. The back and forth here is great fun but irrelevant to the eventual outcome of this saga.

Stolen phones are a big problem and I fully support any efforts on the part of the manufacturers to render stolen phones useless to the thieves. That's the only way to solve the theft problem. If a few innocent people inadvertently get their phones bricked as a result, then that's probably the price we have to pay to solve the greater problem of phone theft.

People die of liver cancer. So let's remove everyone's liver, healthy or otherwise, in order to prevent liver cancer.

When you can't come up with an intelligent argument to get your point across, resort to the most extreme straw man possible.

Oh, I got my my point across, but your argument (stolen devices) is absolutely void, because an iphone has several other securities measures other than the fingerprint sensor.

A properly set up iphone (iOS 7+) can be completely and remotely bricked by the owner if it gets stolen. Post iOS 7, an iphone is effectively locked to an Apple ID, so it has zero value if stolen.

So, as we can see, Apple already had countermeasures in place in case an iphone gets stolen.

Now, and here comes the difference: a [dumb] user failed to set up security on the iphone properly, and it got stolen, and the thief was able to use the device. Whose fault is it: (a) Apple's (b) the user's (c) everyone else who happened to take his/hers legitimate phone to an unauthorized apple repair center?

Let me just give you an example: my state has over 20.8M inhabitants and exactly 853 cities, spread over 586,522.122 km². Do you know how many authorized Apple repair centers are in here? FIVE. That is why most people I know take the phone to unauthorized centers: unauthorized centers repair the phone in a few hours, while the authorized ones will keep your phone for over a month.

Now, you're saying that because Apple isn't able to attend the existing demand, people can't find a solution by their own? They have to subject to over a month wait because there aren't enough authorized repair centers?

And now, because a few people are too dumb to RTFM and properly set up the security in their devices, everyone should have their phones bricked?

My "extreme" comparison fits the bill precisely to what apple is doing. They are hurting people that have never stolen a phone, leaving them with a device that might have cost them a few months of salary just because some other people are completely retarded and can't set up an iphone properly. My comparison is quite precise.

« Last Edit: February 06, 2016, 05:35:07 am by AlxDroidDev »

Logged

"The nice thing about standards is that you have so many to choose from." (Andrew S. Tanenbaum)

So let's say that someone cloned Microsoft's SMB protocol and made their own compatible implementation -- should they just piggyback on Microsoft's SMB subsystem (which is part of Windows) rather than writing their own OS? Microsoft has invested millions in developing this protocol and integrating it into their OS and it's a key part of their IP. Where do you draw the line?

Oh wait, it's called Samba, and MS was actually ordered by the European Commission to supply the Samba developers with protocol information, as part of an antitrust case.

If you should have read your own links, you should have known that the reason was that microsoft has a near monopoly.As far as I know, FTDI has no monopoly on the (emulated) serial port, neither a monopoly on USB-UART chips.Please, don't try to behave like you are some kind of lawyer.

Logged

The difference between theory and practice is less in theory thanthe difference between theory and practice in practice.Expensive tools cannot compensate for lack of experience.

Western Digital developed this into the first widely available single-chip UART, the WD1402A, around 1971. This was an early example of a medium scale integrated circuit.

A logic chip that sends & receives 5 to 8 bits of DATA.No restriction on what type of data. No requirement for a computer!A hardware way to increase distance and reduce wires.

To save hardware costs, one or both ends might use a computer program to replace hardware.A great program would verify it's outputs before sending it to the IC. When operating systems were placed between the program that created the data and the WD1402A, it has to be transparent.

That is 45 years where data was data.

To be clear the FTDI chip is acting like that WD1402A on one end of the circuit and the FTDI driver is now between the program that could do safety checks and the WD1402A.

What happens to very large night print job? The print job that uses a full box of paper with a cost of $25 to $200 per box.

That string in binary could be anything.What is if in binary code for a computer chip or storage device?

The unknown is how much damage this output on the serial port has caused.The second unknown is how much time and money this will cost someone's.

The third unknown is how soon a micro controller will appear in FTDI's packages with the USB, power and ground on the same pins.

Now some should be asking why the anti-Malware software on their computer has not flagged or removed this software.

If you should have read your own links, you should have known that the reason was that microsoft has a near monopoly.As far as I know, FTDI has no monopoly on the (emulated) serial port, neither a monopoly on USB-UART chips.Please, don't try to behave like you are some kind of lawyer.

The reason they were forced to provide documentation is because they had a monopoly (hence, antitrust case). FTDI isn't being forced to do anything, because they're not a monopoly, but they also don't have the slightest case against clone chips using their driver (as long as they don't have an FTDI logo), for the same reason Samba is completely legal. Or are you suggesting that Samba would be illegal were it not for that antitrust ruling? My point is that not only is Samba legal, but, to reinforce that fact, the tables were even tilted the other way, against MS, as part of an antitrust ruling. If Samba were illegal to begin with that wouldn't have happened.

If you should have read your own links, you should have known that the reason was that microsoft has a near monopoly.As far as I know, FTDI has no monopoly on the (emulated) serial port, neither a monopoly on USB-UART chips.Please, don't try to behave like you are some kind of lawyer.

The reason they were forced to provide documentation is because they had a monopoly (hence, antitrust case). FTDI isn't being forced to do anything, because they're not a monopoly, but they also don't have the slightest case against clone chips using their driver (as long as they don't have an FTDI logo), for the same reason Samba is completely legal. Or are you suggesting that Samba would be illegal were it not for that antitrust ruling? My point is that not only is Samba legal, but, to reinforce that fact, the tables were even tilted the other way, against MS, as part of an antitrust ruling. If Samba were illegal to begin with that wouldn't have happened.

Clone FT232 without using their logo is legal since FTDI, AFAIK did not patent the protocol.Cloning SMB is not. M$ patented their protocol. However, the reason Samba is legal is because M$ explicitly gave up rights on SMB protocol, as well as many other commonly used M$ protocols/formats, like docx.

Clone FT232 without using their logo is legal since FTDI, AFAIK did not patent the protocol.Cloning SMB is not. M$ patented their protocol. However, the reason Samba is legal is because M$ explicitly gave up rights on SMB protocol, as well as many other commonly used M$ protocols/formats, like docx.

The discussion here is pretty much all about trademarks and copyright, which is why I didn't go into patents. Patents are a whole different can of worms, and this goes into the software patents debate which is still very much open. Suffice it to say that FTDI has no case based on their trademarks and copyright.

That said, talking specifically about Samba, it seems the MS patents in question were not infringed by Samba to begin with and are largely irrelevant. See here for more info (you can't really patent a protocol as far as I know, you can patent specific implementation details, and other people can work around those patents, like Samba does).

1) They don't detect counterfeits. They detect non FTDI chips. It could be a legitimate compatible chip, a clone, a grey market FTDI silicon, or a counterfeit.

Legitimate manufacturers do not impersonate their competition by spoofing their vendor ID and product ID...{Snip}

Yeah, Compaq Computer Corporation totally wasn't a legitimate manufacturer. I mean, how dare they reverse engineer the PC BIOS and capitalize on the huge investment IBM had made by releasing a clone. The nerve!

Fact is, most of these FTDI compatible chips aren't counterfeits. By that I mean they're not direct copies of FTDI's die. Most of them were designed to replicate the function and protocol of the real thing, but are still uniquely different than a real FTDI chip.

The simple fact that FTDI is able to detect them all is proof of this. (If they were straight mask copies they would be functionally identical to a genuine device.)

It wouldn't be super hard for the clone makers to write a CDC device driver to support their own chips, and in modern OS' like OS X it's not strictly needed as there are generic drivers present. I think the big reason they emulate the FTDI protocol is because it's broadly supported out of the box on many platforms. I guess you could say FTDI's driver is Prolific.

Analogy time again: FTDI are entitled to take their ball and go home, (i.e. driver rejects chips it doesn't like), but not to boot it at or through your picture window (i.e. knowingly modify, transiently or otherwise, your data or hardware in a way it wouldn't do with a genuine chip).

Clone FT232 without using their logo is legal since FTDI, AFAIK did not patent the protocol.Cloning SMB is not. M$ patented their protocol. However, the reason Samba is legal is because M$ explicitly gave up rights on SMB protocol, as well as many other commonly used M$ protocols/formats, like docx.