7 ms·

I enables independent, non-involved, non-interested parties to check it. Also when the protocol is open, it enables multiple implementations; keeping a known-by

I enables independent, non-involved, non-interested parties to check it. Also when the protocol is open, it enables multiple implementations; keeping a known-by-few trojan style bug in all of them is specially difficult.

UncleMeat 4y ago
That's true. And yet, the linux kernel consistently has bugs like these in it. If you want exploitable vulns in literal media codecs go have fun taking a look at the history of ffmpeg. I love open source. In so many ways it is uniquely responsible for the development of our technology landscape. It is observably not a meaningfully different path to secure code than closed source development.
- marcodiego 4y ago
  The difference in "who you have to trust" is reason enough.
  - UncleMeat 4y ago
    If your concern is about deliberately inserted exploits by the WhatsApp developers, that's got virtually nothing to do with the topic at hand.
    - lmm 4y ago
      If this particular exploit had been deliberately inserted by WhatsApp developers, what would you expect to be different?
      - marcodiego 4y ago
        They are the only party who have access to the code. They don't even need to pretend about unintentional bugs. The world had a lesson with PRISM, if we learned anything... that is a different matter.
        hulitu 4y ago
        They didn't learned anything. The mantra is "i would not happen to me".
- ianbutler 4y ago
  I think that’s true of all software, people are fallible open source or not. I’d love to see average time to discovery and reporting in closed versus open source though. I’ve always heard it’s better in open source, which intuitively makes sense, and by the nature of closed source I think gathering the data will be challenging but valuable to see a tight comparison.
  - UncleMeat 4y ago
    Lots of people have attempted this sort of analysis. You can find attempts at this in ICSE of FSE or whatever. But frankly there is no way to make effective science out of this. All of the data are always messy and make huge compromises to get anything even close to resembling an apples-to-apples comparison. I don't believe that anybody who claims it is meaningfully better in open source has any actual data really backing that up. If you want my opinion, there is a huge gap between the tiny portion of open source projects that get any real professional scrutiny and the rest of the open source ecosystem. For something like the linux kernel, there are a lot of professionals who are deliberately focusing their novel tools at it and reporting issues. This is clearly better than nothing - though I'm not certain it is so much better than nothing to call it a big win. And this is the result of a large number of different teams all looking at this one codebase. But pretty much immediately below "the linux kernel" in visibility, everybody stops caring. Even hugely deployed security-critical open source projects that manage media decoding and network stacks get absolutely zero professional analysis. All these projects get is the useless "drive-by CVE-report" garbage where somebody throws an off the shelf system at the repo and reports everything it spits out, no matter how useless the report.
    - ianbutler 4y ago
      Good insight about the long tail of open source projects that don't have the same level of activity or interest from the developer community. I hadn't considered how sharply that drop off is, even for some what still widely used projects simply because the amount of people with the know how, and interest, to look for vulnerabilities is a lot smaller than the available project surface area.
GoblinSlayer 4y ago
>Also when the protocol is open, it enables multiple implementations Nice theory, but most of the time it's "just use zlib, bro, it's battle tested".

UncleMeat 4y ago

That's true. And yet, the linux kernel consistently has bugs like these in it. If you want exploitable vulns in literal media codecs go have fun taking a look at the history of ffmpeg. I love open source. In so many ways it is uniquely responsible for the development of our technology landscape. It is observably not a meaningfully different path to secure code than closed source development.

marcodiego 4y ago
The difference in "who you have to trust" is reason enough.
- UncleMeat 4y ago
  If your concern is about deliberately inserted exploits by the WhatsApp developers, that's got virtually nothing to do with the topic at hand.
  - lmm 4y ago
    If this particular exploit had been deliberately inserted by WhatsApp developers, what would you expect to be different?
    - marcodiego 4y ago
      They are the only party who have access to the code. They don't even need to pretend about unintentional bugs. The world had a lesson with PRISM, if we learned anything... that is a different matter.
      - hulitu 4y ago
        They didn't learned anything. The mantra is "i would not happen to me".
ianbutler 4y ago
I think that’s true of all software, people are fallible open source or not. I’d love to see average time to discovery and reporting in closed versus open source though. I’ve always heard it’s better in open source, which intuitively makes sense, and by the nature of closed source I think gathering the data will be challenging but valuable to see a tight comparison.
- UncleMeat 4y ago
  Lots of people have attempted this sort of analysis. You can find attempts at this in ICSE of FSE or whatever. But frankly there is no way to make effective science out of this. All of the data are always messy and make huge compromises to get anything even close to resembling an apples-to-apples comparison. I don't believe that anybody who claims it is meaningfully better in open source has any actual data really backing that up. If you want my opinion, there is a huge gap between the tiny portion of open source projects that get any real professional scrutiny and the rest of the open source ecosystem. For something like the linux kernel, there are a lot of professionals who are deliberately focusing their novel tools at it and reporting issues. This is clearly better than nothing - though I'm not certain it is so much better than nothing to call it a big win. And this is the result of a large number of different teams all looking at this one codebase. But pretty much immediately below "the linux kernel" in visibility, everybody stops caring. Even hugely deployed security-critical open source projects that manage media decoding and network stacks get absolutely zero professional analysis. All these projects get is the useless "drive-by CVE-report" garbage where somebody throws an off the shelf system at the repo and reports everything it spits out, no matter how useless the report.
  - ianbutler 4y ago
    Good insight about the long tail of open source projects that don't have the same level of activity or interest from the developer community. I hadn't considered how sharply that drop off is, even for some what still widely used projects simply because the amount of people with the know how, and interest, to look for vulnerabilities is a lot smaller than the available project surface area.

GoblinSlayer 4y ago

>Also when the protocol is open, it enables multiple implementations Nice theory, but most of the time it's "just use zlib, bro, it's battle tested".