6 ms·

If there were more bugs, why weren't they found? This is a form of "slippery slope" argument that holds no weight as to the security of VeraCrypt, one way or a

by dimino 10y ago

If there were more bugs, why weren't they found? This is a form of "slippery slope" argument that holds no weight as to the security of VeraCrypt, one way or another.

greenshackle2 10y ago
It's not slippery slope. The slippery slope fallacy is arguments of the form 'if we allow x, y and z will necessarily occur, therefore we can't allow x'. (Note that the slippery slope fallacy is not a pure logical fallacy, the argument is valid if the slope is, in fact, slippery). Between two pieces of software with the same function, if the same audit process finds 10 critical bugs in software A, and 100 critical bugs in software B, which do you think is more likely to have undiscovered bugs? I'd say B, since no bug discovery process is perfect. For example, assuming a ~90% hit rate, you'd expect there is ~1 undiscovered bug in A, and ~10 in B. (Note that I am not saying VeraCrypt is bad or that you shouldn't use it. I have no idea how it compares to similar software. All I'm arguing is that, ceteris paribus, discovering more critical bugs is at least weak evidence that more undiscovered critical bugs exist, since no bug-discovery process is perfect.)
- dimino 10y ago
  "If we found bug x, y and z will necessarily be found, therefore VeraCrypt is insecure." That's the argument being made implicitly, and the argument you're reiterating. Saying, "Who knows if there are more bugs?" is a useless statement, you simply can't do anything with it. That's the nature of bugs, if you can't identify or find them, you can't claim they exist. 100 bugs in software B does not imply the 101st bug, is my point. There's no such thing as a bug "hit rate".
  - greenshackle2 10y ago
    >If we found bug x, y and z will necessarily be found, therefore VeraCrypt is insecure. I did not make that argument, I made a probabilistic argument. Trying to apply deductive logic fallacies to probabilistic arguments is a type error. >if you can't identify or find them, you can't claim they exist. I made no absolute claim about the existence or nonexistence of bugs, only about the expected number of bugs, that is, a probabilistic estimate. > There's no such thing as a bug "hit rate". Of course there is, it is, trivially, the number of bugs found by the audit / the total number of bugs. Look at this way: I have two auditors, Alice and Charles. Charles is known to be pretty sloppy, he looks over code quickly, skip parts, etc, but the bugs he finds are usually actual bugs. Alice is extremely rigorous and misses very few bugs. I have 2 pieces of software, SuperCrypt and UltraCrypt. Charles audits SuperCrypt and finds 137 critical bugs. He audits UltraCrypt and finds only one. I know Alice will review both code bases next week. Where do you think she'll find more bugs?
    - dimino 10y ago
      It doesn't matter what I think, it matters what can be supported by evidence, and your emotional narrative aside, the number of bugs found in a piece of software does not indicate there are more bugs to be found. You did make the argument I presented above, even if you didn't mean to. It is not a type error, it is a conclusion that you're trying to imply but don't want to directly state because it's indefensible, and you know it. There is not such a thing as a bug "hit rate" because it would require knowledge of unknown bugs, which isn't possible. To be abundantly clear, I find your emotional narrative entirely unhelpful to this conversation, but to illustrate how unhelpful, I will play along: UltraCrypt clearly wasn't audited correctly, and will have more bugs in it given the complexity of the problem space and the lack of issues found. SuperCrypt was clearly audited well and will therefore have fewer bugs if Charles continued looking and when Alice looks next week. This, I repeat, is wholly unhelpful, because the same information can be used to create arguments for either point, and is therefore not useful.
      - greenshackle2 10y ago
        Uh, on the contrary, I've found your narrative helpful in showing how one might arrive at the conclusion that finding more bugs is evidence that more won't be found later. I often try to back up abstract arguments with a concrete illustration, it makes things clearer for me. I've clearly failed to make myself understood, I don't think it's useful to continue this conversation.
        dimino 10y ago
        I'm saddened how you'd rather end conversation than change your beliefs.
      - Kenji 10y ago
        I don't understand how you still can't get it. Let us try again. Suppose you're a professor and you had a super-productive student who wrote 100 very interesting papers. You only have time to read 50 of them, selected at random. However, you notice that in 10 of these 50 papers, there are mathematical errors. What do you expect of the remaining papers, how many errors will there be? This is basic statistics and nothing about this argument is emotional. What if you read 50 papers and only one contained mistakes? Would you expect more or less errors now in the remaining papers?

by dimino 10y ago

If there were more bugs, why weren't they found? This is a form of "slippery slope" argument that holds no weight as to the security of VeraCrypt, one way or another.

greenshackle2 10y ago

It's not slippery slope. The slippery slope fallacy is arguments of the form 'if we allow x, y and z will necessarily occur, therefore we can't allow x'. (Note that the slippery slope fallacy is not a pure logical fallacy, the argument is valid if the slope is, in fact, slippery). Between two pieces of software with the same function, if the same audit process finds 10 critical bugs in software A, and 100 critical bugs in software B, which do you think is more likely to have undiscovered bugs? I'd say B, since no bug discovery process is perfect. For example, assuming a ~90% hit rate, you'd expect there is ~1 undiscovered bug in A, and ~10 in B. (Note that I am not saying VeraCrypt is bad or that you shouldn't use it. I have no idea how it compares to similar software. All I'm arguing is that, ceteris paribus, discovering more critical bugs is at least weak evidence that more undiscovered critical bugs exist, since no bug-discovery process is perfect.)

dimino 10y ago
"If we found bug x, y and z will necessarily be found, therefore VeraCrypt is insecure." That's the argument being made implicitly, and the argument you're reiterating. Saying, "Who knows if there are more bugs?" is a useless statement, you simply can't do anything with it. That's the nature of bugs, if you can't identify or find them, you can't claim they exist. 100 bugs in software B does not imply the 101st bug, is my point. There's no such thing as a bug "hit rate".
- greenshackle2 10y ago
  >If we found bug x, y and z will necessarily be found, therefore VeraCrypt is insecure. I did not make that argument, I made a probabilistic argument. Trying to apply deductive logic fallacies to probabilistic arguments is a type error. >if you can't identify or find them, you can't claim they exist. I made no absolute claim about the existence or nonexistence of bugs, only about the expected number of bugs, that is, a probabilistic estimate. > There's no such thing as a bug "hit rate". Of course there is, it is, trivially, the number of bugs found by the audit / the total number of bugs. Look at this way: I have two auditors, Alice and Charles. Charles is known to be pretty sloppy, he looks over code quickly, skip parts, etc, but the bugs he finds are usually actual bugs. Alice is extremely rigorous and misses very few bugs. I have 2 pieces of software, SuperCrypt and UltraCrypt. Charles audits SuperCrypt and finds 137 critical bugs. He audits UltraCrypt and finds only one. I know Alice will review both code bases next week. Where do you think she'll find more bugs?
  - dimino 10y ago
    It doesn't matter what I think, it matters what can be supported by evidence, and your emotional narrative aside, the number of bugs found in a piece of software does not indicate there are more bugs to be found. You did make the argument I presented above, even if you didn't mean to. It is not a type error, it is a conclusion that you're trying to imply but don't want to directly state because it's indefensible, and you know it. There is not such a thing as a bug "hit rate" because it would require knowledge of unknown bugs, which isn't possible. To be abundantly clear, I find your emotional narrative entirely unhelpful to this conversation, but to illustrate how unhelpful, I will play along: UltraCrypt clearly wasn't audited correctly, and will have more bugs in it given the complexity of the problem space and the lack of issues found. SuperCrypt was clearly audited well and will therefore have fewer bugs if Charles continued looking and when Alice looks next week. This, I repeat, is wholly unhelpful, because the same information can be used to create arguments for either point, and is therefore not useful.
    - greenshackle2 10y ago
      Uh, on the contrary, I've found your narrative helpful in showing how one might arrive at the conclusion that finding more bugs is evidence that more won't be found later. I often try to back up abstract arguments with a concrete illustration, it makes things clearer for me. I've clearly failed to make myself understood, I don't think it's useful to continue this conversation.
      - dimino 10y ago
        I'm saddened how you'd rather end conversation than change your beliefs.
    - Kenji 10y ago
      I don't understand how you still can't get it. Let us try again. Suppose you're a professor and you had a super-productive student who wrote 100 very interesting papers. You only have time to read 50 of them, selected at random. However, you notice that in 10 of these 50 papers, there are mathematical errors. What do you expect of the remaining papers, how many errors will there be? This is basic statistics and nothing about this argument is emotional. What if you read 50 papers and only one contained mistakes? Would you expect more or less errors now in the remaining papers?