3 ms·

>I'm unaware of concrete evidence that open sourcing code affects security outcomes either way. Do you have any examples? An impossible standard, how do you pu

>I'm unaware of concrete evidence that open sourcing code affects security outcomes either way. Do you have any examples? An impossible standard, how do you purpose to measure that? >And look where that has gotten us. A million eyes all glazed over the same bug. How is a less eyes a solution to that problem? Allow me this thought experiment: One person holds up a black box and asks you to stick your hand inside promising up and down that it is not full of venomous snakes, another person does the same with a transparent box. You are blind, but there are some well meaning (though not perfect) people in the room who don't want to see you hurt and they see no snakes in the clear box. What box do you choose?

nickpsecurity 10y ago
"An impossible standard, how do you purpose to measure that?" Number of compromises for product/system X vs open alternatives. Number of published vulnerabilities. Time to patch them. Evaluation of binaries for common issues showing if even basic, due diligence was applied. Results of independent evaluations against meaningful criteria, such as QA methods used & results of them. There's quite a few ways to assess this. "How is a less eyes a solution to that problem?" How is no eyes looking at specific OSS a solution to the problem? Pointless questions not focusing on the issue. "Allow me this thought experiment: One person holds up a black box and asks you to stick your hand " Now, lets say the same thing happens FOSS-style. The box is clear but people dive in blindfolded without being asked. That's vast majority of FOSS with negligible security benefit. Next, someone looks at the box but has neither seen a snake nor knows which are venomous. This is people glancing at the code. Lets say they know 1 or 2 venomous snakes, ask they be removed, and dive into the others because they didn't know how to spot them. This is amateurs or pro's with little domain knowledge knocking out low-hanging fruit (err, snakes). Finally, let's say an expert on all poisonous snakes puts significant time inspecting the box to make sure no adults or even babies lurk in there. After they're gone, the expert inserts their hand with no damage unless a new type of snake was hidden in there. I choose the box where an expert looked inside to remove as many dangers as possible. I don't care if it's open or closed for my baseline: just that it was vetted by reliable people with evidence it's the same box. Most proprietary and FOSS software doesn't meet this standard although it was mostly proprietary that reached highest level of proof. Took a lot of expensive experts years to do it is why. FOSS theoretically has an advantage due to free labor but they just don't do high-security. Hard to get them to use safer, systems languages and unit testing much less high-security methods. So, there's your example. It withers away once the truth is once again demonstrated: it's the review(s), what was reviewed, and if you trust reviewer or review methods. OSS only helps in rare case that more pro's or experts are interested in doing that. It occasionally happens but too rare to be the rule for the baseline.

nickpsecurity 10y ago

"An impossible standard, how do you purpose to measure that?" Number of compromises for product/system X vs open alternatives. Number of published vulnerabilities. Time to patch them. Evaluation of binaries for common issues showing if even basic, due diligence was applied. Results of independent evaluations against meaningful criteria, such as QA methods used & results of them. There's quite a few ways to assess this. "How is a less eyes a solution to that problem?" How is no eyes looking at specific OSS a solution to the problem? Pointless questions not focusing on the issue. "Allow me this thought experiment: One person holds up a black box and asks you to stick your hand " Now, lets say the same thing happens FOSS-style. The box is clear but people dive in blindfolded without being asked. That's vast majority of FOSS with negligible security benefit. Next, someone looks at the box but has neither seen a snake nor knows which are venomous. This is people glancing at the code. Lets say they know 1 or 2 venomous snakes, ask they be removed, and dive into the others because they didn't know how to spot them. This is amateurs or pro's with little domain knowledge knocking out low-hanging fruit (err, snakes). Finally, let's say an expert on all poisonous snakes puts significant time inspecting the box to make sure no adults or even babies lurk in there. After they're gone, the expert inserts their hand with no damage unless a new type of snake was hidden in there. I choose the box where an expert looked inside to remove as many dangers as possible. I don't care if it's open or closed for my baseline: just that it was vetted by reliable people with evidence it's the same box. Most proprietary and FOSS software doesn't meet this standard although it was mostly proprietary that reached highest level of proof. Took a lot of expensive experts years to do it is why. FOSS theoretically has an advantage due to free labor but they just don't do high-security. Hard to get them to use safer, systems languages and unit testing much less high-security methods. So, there's your example. It withers away once the truth is once again demonstrated: it's the review(s), what was reviewed, and if you trust reviewer or review methods. OSS only helps in rare case that more pro's or experts are interested in doing that. It occasionally happens but too rare to be the rule for the baseline.