7 ms·

Reasons to NOT open up the code: 1> Loss of competitive advantage 2> Open source is not necessarily any safer (heartbleed bug ... ) 3> If software for the pace

Reasons to NOT open up the code: 1> Loss of competitive advantage 2> Open source is not necessarily any safer (heartbleed bug ... ) 3> If software for the pacemaker is allowed to be updated like that on a computer, someone will update it with buggy software that can cause adverse side effects. Who owns the liability in that case?

kiba 10y ago
Loss of competitive advantage There's a competitive advantage in keeping pacemakers' source code proprietary? Open source is not necessarily any safer (heartbleed bug ... ) It's a hell lot more amendable to inspection than proprietary software.
- whorleater 10y ago
  > There's a competitive advantage in keeping pacemakers' source code proprietary? There definitely is. If your company takes ~2 years to develop a pacemaker's software, it's not to your advantage to let your competitors catch up. I'm not saying it's a good thing that it's closed source, but there is definitely incentive to keep your research to yourself.
  - pdonis 10y ago
    > If your company takes ~2 years to develop a pacemaker's software, it's not to your advantage to let your competitors catch up. Why should the patient who has the pacemaker implanted care? This seems like a clear situation in which the patient's interests trump everybody else's. Pacemaker manufacturers should be competing in how well their devices meet patient needs. Closed source doesn't meet a key patient need.
    - whorleater 10y ago
      As heartless as this sounds: the patient isn't the only person in the equation. There are investors that fund the medical research, a company has employees to pay, the hospital wants the best pacemaker available, etc.
      - anonbanker 10y ago
        you're right. that sounds pretty heartless.
      - llukas 10y ago
        Sure - why not ask patient for paid subscription for privilege of using pacemaker? Somebody please think of the investors...
        whorleater 10y ago
        And in the same vein, why not ask investors to if they'll fund a pacemaker company in a purely philanthropic fashion? Isn't it better to get pacemakers in a limited fashion than not at all?
        TeMPOraL 10y ago
        Sure. Soon we'll have cloud-connected subscription-based freemium pacemakers that will shut down and kill everyone when the company making them gets acquihired. I mean, I get the business incentives involved, but I also think it's high time to realize they're getting insane and should be altered.
    - HeyLaughingBoy 10y ago
      Medical device software is subject to a level of rigor in development process that little else is. Exactly what patient need do you believe open source would meet that is not being met by the current closed-source development process?
      - llukas 10y ago
        What happens in closed source development model if pacemaker company ceases to develop one or goes belly up?
        unimpressive 10y ago
        Well now, this isn't quite the same thing as your normal IoT device. You would need to be Really Damn Sure any updates are bug-free before you could push them, which would take actual financial resources. Open source would help here, but not quite as much as it normally would.
        HeyLaughingBoy 10y ago
        Manufacturer must support the product for 10 years after the last sale. In the case that they go belly up, that I don't have experience with, but it's likely that another company would step in to fill the role. Support can be quite lucrative.
      - abraae 10y ago
        The need to avoid Therac-25 [1] type bugs in the proprietary code that are fatal to the patient. Open source in conjunction with a bug bounty would make me far more confident than simply trusting that some large corporate has got their shit wired tight when history throws up so many counter-examples. [1] https://en.wikipedia.org/wiki/Therac-25 https://en.wikipedia.org/wiki/Therac-25
        deleted 10y ago
        [deleted]
      - pdonis 10y ago
  - c22 10y ago
    If every pacemaker manufacturer is required to publish source couldn't you just release it under a license that doesn't allow your competitors to use your code and wouldn't it be readily apparent if they did?
iokanuon 10y ago
3> has nothing to do with the code being OS, wherether or not a device is locked down is independent of that.
- smallnamespace 10y ago
  Maybe in a complete vacuum, but in reality, having access to source certainly makes it easier to look for vulnerabilities, and if the same software is in many devices, the cost of finding vulnerabilities is amortized. Security by obscurity obviously doesn't stop a determined attacker, but it does raise the barrier to entry for script kiddies.
  - r3bl 10y ago
    No. Tell me, how many vulnerabilities are running wild on Linux, the software that powers... well, pretty much anything (including the servers through which you read this content)? Even if you find a vulnerability, it gets patched within hours and it may take a day or two for it to be distributed to everyone. > Security by obscurity [...] does raise the barrier to entry for script kiddies. Which script can help you find a vulnerability inside of the source code? You'll need a script that can understand the code it's looking at. I'm not aware of any such script.
    - smallnamespace 10y ago
      If the same vulnerability is present across a large range of devices, a public exploit has a much larger impact. I'm not advocating for security by obscurity in the slightest because on balance I think it's bad, but we should acknowledge that publishing your source does change the potential cost of mounting an attack in various scenarios, and some of them might actually favor obscurity. Nobody except the most determined attacker will attack a device with some custom, unpublished code. On the other hand, popular software have a variety of exploits in the wild because their popularity makes them more attractive targets, one consequence of which is enabling script kiddies (since the hard work can be outsourced). > it gets patched within hours and it may take a day or two for it to be distributed to everyone This doesn't work for embedded devices. Hence why it might not be a great idea to publish their vulnerabilities, or tell the whole world that you're running on old vulnerable source.
choward 10y ago
Number 2 isn't reason NOT to open up the code. You can't just claim because it doesn't do something that it's a good reason. Open source software isn't necessarily faster or more efficient either. So?
woodruffw 10y ago
Even if we assume that these arguments are sound (which they aren't), they do not appear to provide a proper justification for letting a human being die. Put another way: If you had to explain Marie Moe's death to one of her relatives, which of your three points would make the relative understand your position?
- niftich 10y ago
  These are sound arguments. Medical devices have to be certified in all applicable jurisdictions and companies want to protect their competitive advantage. This is no different from, say, new drugs, which are similarly proprietary and the maker retains exclusivity for several years. Further, medications too are risky black-boxes towards end-users.
  - woodruffw 10y ago
    They are not sound in the context of human welfare. We do not allow food companies to hide the ingredients of their products, because we know that companies (in the interest of profit) will fail to inform consumers about the dangers of eating unhealthily. Similarly, we do not allow meat producers to leave their meat ungraded because it endangers their "competitive advantage" - we understand (empirically) that doing so leads to food contamination and otherwise preventable disease. Your choice of proprietary medicine as a counterexample is an interesting one. The pharmaceutical industry in the United States has a long history of "protecting its competitive advantage" at the cost of individual welfare - consider how frequently "reformulations" of the same base chemical are patented to continue milking a lucrative product that could improve the lives of thousands if genericized. Perhaps even more pointedly, consider the fact that we deem it acceptable (and necessary) that the FDA step in and regulate the release of new drugs. Is there a valuable distinction to be drawn between the sort of regulation and evaluation that the FDA does and the sort that would be possible if programmers could openly evaluate medical devices?
- mankash666 10y ago
  Your argument that opening up the source code might have prevented her death is facetious.
morganvachon 10y ago
The code to the Jeep Grand Cherokee is closed source, yet security researchers (and now thieves) have been able to take complete control over the vehicle via simple protocol sniffing and reverse engineering. Closed source is no safer than open source.
falcolas 10y ago
1) The software in a pacemaker is not a competitive advantage. The hardware and rights to distribute to hospitals are. 2) Open and closed are equally vulnerable. Closed may be even more vulnerable, since security researches have to attack a black box and can't run ordinary code linting tools. 3) Liability after update is a good question, but one which can be (and is) solved with traditional contract agreements. See cpap machines.
stordoff 10y ago
None of these are particularly compelling reasons IMO. > 1> Loss of competitive advantage Patient safety trumps business considerations. Skipping clinical trials would be a major competitive advantage (lower costs, quicker to market etc.), but we don't allow that for the same reason > 2> Open source is not necessarily any safer (heartbleed bug ... ) I'll agree, in so far as saying making it open source doesn't necessarily make it safer. However, it should, at worst, be no less safe - the requirements on the manufacturer (testing etc.) should be the same regardless > 3> If software for the pacemaker is allowed to be updated like that on a computer, someone will update it with buggy software that can cause adverse side effects. You can open the code but, for example, required a signed binary before a device can be updated. The openness of the code and the openness of the device itself are linked but separate issues.
- ikeboy 10y ago
  >Skipping clinical trials would be a major competitive advantage (lower costs, quicker to market etc.), but we don't allow that for the same reason About that ... Have you seen http://www.fdareview.org/05_harm.php http://www.fdareview.org/05_harm.php and http://www.fdareview.org/07_market_failure.php http://www.fdareview.org/07_market_failure.php?

kiba 10y ago

Loss of competitive advantage There's a competitive advantage in keeping pacemakers' source code proprietary? Open source is not necessarily any safer (heartbleed bug ... ) It's a hell lot more amendable to inspection than proprietary software.

whorleater 10y ago
> There's a competitive advantage in keeping pacemakers' source code proprietary? There definitely is. If your company takes ~2 years to develop a pacemaker's software, it's not to your advantage to let your competitors catch up. I'm not saying it's a good thing that it's closed source, but there is definitely incentive to keep your research to yourself.
- pdonis 10y ago
  > If your company takes ~2 years to develop a pacemaker's software, it's not to your advantage to let your competitors catch up. Why should the patient who has the pacemaker implanted care? This seems like a clear situation in which the patient's interests trump everybody else's. Pacemaker manufacturers should be competing in how well their devices meet patient needs. Closed source doesn't meet a key patient need.
  - whorleater 10y ago
    As heartless as this sounds: the patient isn't the only person in the equation. There are investors that fund the medical research, a company has employees to pay, the hospital wants the best pacemaker available, etc.
    - anonbanker 10y ago
      you're right. that sounds pretty heartless.
    - llukas 10y ago
      Sure - why not ask patient for paid subscription for privilege of using pacemaker? Somebody please think of the investors...
      - whorleater 10y ago
        And in the same vein, why not ask investors to if they'll fund a pacemaker company in a purely philanthropic fashion? Isn't it better to get pacemakers in a limited fashion than not at all?
      - TeMPOraL 10y ago
        Sure. Soon we'll have cloud-connected subscription-based freemium pacemakers that will shut down and kill everyone when the company making them gets acquihired. I mean, I get the business incentives involved, but I also think it's high time to realize they're getting insane and should be altered.
  - HeyLaughingBoy 10y ago
    Medical device software is subject to a level of rigor in development process that little else is. Exactly what patient need do you believe open source would meet that is not being met by the current closed-source development process?
    - llukas 10y ago
      What happens in closed source development model if pacemaker company ceases to develop one or goes belly up?
      - unimpressive 10y ago
        Well now, this isn't quite the same thing as your normal IoT device. You would need to be Really Damn Sure any updates are bug-free before you could push them, which would take actual financial resources. Open source would help here, but not quite as much as it normally would.
      - HeyLaughingBoy 10y ago
        Manufacturer must support the product for 10 years after the last sale. In the case that they go belly up, that I don't have experience with, but it's likely that another company would step in to fill the role. Support can be quite lucrative.
    - abraae 10y ago
      The need to avoid Therac-25 [1] type bugs in the proprietary code that are fatal to the patient. Open source in conjunction with a bug bounty would make me far more confident than simply trusting that some large corporate has got their shit wired tight when history throws up so many counter-examples. [1] https://en.wikipedia.org/wiki/Therac-25 https://en.wikipedia.org/wiki/Therac-25
      - deleted 10y ago
        [deleted]
    - pdonis 10y ago
- c22 10y ago
  If every pacemaker manufacturer is required to publish source couldn't you just release it under a license that doesn't allow your competitors to use your code and wouldn't it be readily apparent if they did?

iokanuon 10y ago

3> has nothing to do with the code being OS, wherether or not a device is locked down is independent of that.

smallnamespace 10y ago
Maybe in a complete vacuum, but in reality, having access to source certainly makes it easier to look for vulnerabilities, and if the same software is in many devices, the cost of finding vulnerabilities is amortized. Security by obscurity obviously doesn't stop a determined attacker, but it does raise the barrier to entry for script kiddies.
- r3bl 10y ago
  No. Tell me, how many vulnerabilities are running wild on Linux, the software that powers... well, pretty much anything (including the servers through which you read this content)? Even if you find a vulnerability, it gets patched within hours and it may take a day or two for it to be distributed to everyone. > Security by obscurity [...] does raise the barrier to entry for script kiddies. Which script can help you find a vulnerability inside of the source code? You'll need a script that can understand the code it's looking at. I'm not aware of any such script.
  - smallnamespace 10y ago
    If the same vulnerability is present across a large range of devices, a public exploit has a much larger impact. I'm not advocating for security by obscurity in the slightest because on balance I think it's bad, but we should acknowledge that publishing your source does change the potential cost of mounting an attack in various scenarios, and some of them might actually favor obscurity. Nobody except the most determined attacker will attack a device with some custom, unpublished code. On the other hand, popular software have a variety of exploits in the wild because their popularity makes them more attractive targets, one consequence of which is enabling script kiddies (since the hard work can be outsourced). > it gets patched within hours and it may take a day or two for it to be distributed to everyone This doesn't work for embedded devices. Hence why it might not be a great idea to publish their vulnerabilities, or tell the whole world that you're running on old vulnerable source.

choward 10y ago

Number 2 isn't reason NOT to open up the code. You can't just claim because it doesn't do something that it's a good reason. Open source software isn't necessarily faster or more efficient either. So?

woodruffw 10y ago

Even if we assume that these arguments are sound (which they aren't), they do not appear to provide a proper justification for letting a human being die. Put another way: If you had to explain Marie Moe's death to one of her relatives, which of your three points would make the relative understand your position?

niftich 10y ago
These are sound arguments. Medical devices have to be certified in all applicable jurisdictions and companies want to protect their competitive advantage. This is no different from, say, new drugs, which are similarly proprietary and the maker retains exclusivity for several years. Further, medications too are risky black-boxes towards end-users.
- woodruffw 10y ago
  They are not sound in the context of human welfare. We do not allow food companies to hide the ingredients of their products, because we know that companies (in the interest of profit) will fail to inform consumers about the dangers of eating unhealthily. Similarly, we do not allow meat producers to leave their meat ungraded because it endangers their "competitive advantage" - we understand (empirically) that doing so leads to food contamination and otherwise preventable disease. Your choice of proprietary medicine as a counterexample is an interesting one. The pharmaceutical industry in the United States has a long history of "protecting its competitive advantage" at the cost of individual welfare - consider how frequently "reformulations" of the same base chemical are patented to continue milking a lucrative product that could improve the lives of thousands if genericized. Perhaps even more pointedly, consider the fact that we deem it acceptable (and necessary) that the FDA step in and regulate the release of new drugs. Is there a valuable distinction to be drawn between the sort of regulation and evaluation that the FDA does and the sort that would be possible if programmers could openly evaluate medical devices?
mankash666 10y ago
Your argument that opening up the source code might have prevented her death is facetious.

morganvachon 10y ago

The code to the Jeep Grand Cherokee is closed source, yet security researchers (and now thieves) have been able to take complete control over the vehicle via simple protocol sniffing and reverse engineering. Closed source is no safer than open source.

falcolas 10y ago

1) The software in a pacemaker is not a competitive advantage. The hardware and rights to distribute to hospitals are. 2) Open and closed are equally vulnerable. Closed may be even more vulnerable, since security researches have to attack a black box and can't run ordinary code linting tools. 3) Liability after update is a good question, but one which can be (and is) solved with traditional contract agreements. See cpap machines.

stordoff 10y ago

None of these are particularly compelling reasons IMO. > 1> Loss of competitive advantage Patient safety trumps business considerations. Skipping clinical trials would be a major competitive advantage (lower costs, quicker to market etc.), but we don't allow that for the same reason > 2> Open source is not necessarily any safer (heartbleed bug ... ) I'll agree, in so far as saying making it open source doesn't necessarily make it safer. However, it should, at worst, be no less safe - the requirements on the manufacturer (testing etc.) should be the same regardless > 3> If software for the pacemaker is allowed to be updated like that on a computer, someone will update it with buggy software that can cause adverse side effects. You can open the code but, for example, required a signed binary before a device can be updated. The openness of the code and the openness of the device itself are linked but separate issues.

ikeboy 10y ago
>Skipping clinical trials would be a major competitive advantage (lower costs, quicker to market etc.), but we don't allow that for the same reason About that ... Have you seen http://www.fdareview.org/05_harm.php http://www.fdareview.org/05_harm.php and http://www.fdareview.org/07_market_failure.php http://www.fdareview.org/07_market_failure.php?