6 ms·

I disagree with the consensus. It's their driver, it operates in a specific way, perhaps responding to possible device output. Using it with non-compatible par

by expr- 12y ago

I disagree with the consensus. 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.

HCIdivision17 12y ago
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.
- kabdib 12y ago
  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).
  - HCIdivision17 12y ago
    Oh absolutely. To me, it's just choosing the lesser of two evils. Like, I'd rather go to jail and be inconvenienced instead of shot on sight, but I feel both are overkill for a parking ticket.
JoeAltmaier 12y ago
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?
- Alupis 12y ago
  Just playing devil's advocate: 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).
  - serf 12y ago
    It's very easy to spot, as the driver 'bricks' the chip by resetting it's PID.
    - Alupis 12y ago
      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.
      - wpietri 12y ago
        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.
        12y ago
otikik 12y ago
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.
- expr- 12y ago
  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.
- HNaTTY 12y ago
  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.
  - Dylan16807 12y ago
    They don't meaningfully own the PID and there are non-counterfeit chips using that PID for compatibility purposes.
Vendan 12y ago
It's malicious and intentional. https://twitter.com/marcan42/status/525202516816842752 https://twitter.com/marcan42/status/525202516816842752

by expr- 12y ago

HCIdivision17 12y ago

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.

kabdib 12y ago
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).
- HCIdivision17 12y ago
  Oh absolutely. To me, it's just choosing the lesser of two evils. Like, I'd rather go to jail and be inconvenienced instead of shot on sight, but I feel both are overkill for a parking ticket.

JoeAltmaier 12y ago

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?

Alupis 12y ago
Just playing devil's advocate: 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).
- serf 12y ago
  It's very easy to spot, as the driver 'bricks' the chip by resetting it's PID.
  - Alupis 12y ago
    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.
    - wpietri 12y ago
      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.
      - 12y ago

otikik 12y ago

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.

expr- 12y ago
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.
HNaTTY 12y ago
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.
- Dylan16807 12y ago
  They don't meaningfully own the PID and there are non-counterfeit chips using that PID for compatibility purposes.

Vendan 12y ago

It's malicious and intentional. https://twitter.com/marcan42/status/525202516816842752 https://twitter.com/marcan42/status/525202516816842752