On Fri, Jul 27, 2007 at 04:49:41AM +0200, Erik Persson wrote: > Andrew Sackville-West wrote: >> On Thu, Jul 26, 2007 at 10:52:07PM +0200, Erik Persson wrote: >>> Anyhow, the basic fact that there is fewer security alerts in Konq makes >>> this a more secure browser, whether this maybe is because only of a >>> smaller user base or not. >> I'm sorry, and i hate to argue with people, but this last statement >> just doesn't fly with me. security alerts are the result of someone >> finding a security problem and reporting it. The fact that fewer >> security alerts exist does _NOT_ mean that konq is more secure. It >> only means it has fewer reported security problems. Now it _could_ be >> that this is because there actually _are_ fewer security problems, but >> it could _also_ be because no one has _found_ or reported >> problems. There's an important distinction there. > > The assumption is of course that there is no significant difference in the > ratio of reported security issues to discovered security issues, and I > can't see any reason those should differ. I can't see any reason why they _should_ differ either, but it is entirely possible that they do and that's the point. It boils down to this argument you stated: "Anyhow, the basic fact that there is fewer security alerts in Konq make this a more secure browser...." and that's ridiculous. It doesn't make it a mroe secure browser. It makes it a browser with fewer reported security alerts. period. There _may_ be other issues involved and it in fact _may_ be a more secure browser, but that is not necessarily because it has fewer alerts. The relationship between reported bugs in one piece of software versus another is directly related to how many of those bugs have been found, not how many bugs there are. True, there is a relationship between the number found and the number that exist, but that doesn't mean that because one has fewer reported bugs that it has fewer bugs. That is, the number found will always be equal to or less than the number that actually exist. But that is all you can know about the number of bugs in a piece of software -- it has exactly or more than the number reported. One piece of software could have 1000 bugs with one reported while another piece could have 100 bugs with 99 reported. According to your statement, the software with the 1 reported bug has fewer bugs than the one with 99 reported but that's not necessarily true. You can only know one thing about the number of bugs in a piece of software and that is the number of _reported_ bugs. > > Anyhow, it is more likely that a browser with more reported security issues > have more discovered security issues. And it is also more likely that a > browser with more discovered security issues have more security issues. > Both, of course, under the assumption that there is no information that > changes this. yes yes yes... _likely_ sure... given a reasonable assumption that the number of users, testers and coders involved are sufficient to effectively test the software, then yes, the one with more reported issues _may_ be less secure. But that's not what you said. You said the fact that Konq had fewer reported problems makes it more secure. You didn't say likely, or reasonable assumed to be... important distinction. > >> WARNING! CAR ANALOGY! >> if we have two cars parked side-by-side and mine is stolen (I'll >> take the fall for this analogy ;) and yours is not, does that mean >> that your car is more secure? no. it means someone looked for a way >> into my car and exploited it. maybe they never even looked at your > > It also mean that it is more likely that your car is less secure. ... > If you have 10 cars of type A and 5 of type B and 2 A cars, and one B car > was stolen, you should guess, if no more information was available, that > the cars were about equally secure. No, if you have 10 A cars, and 5 B > cars, and 1 A car was stolen and 4 B cars, you should guess that the B cars > were less secure. no. you _could_ guess that. But it is equally valid to guess that car B's, being rarer cars are more desireable and therefore more likely to be stolen. > Now, if you have x A cars and y B cars and you don't know x and y, but you > know that more A cars are stolen, it is more likely that the A cars are > less secure, since there is no reason to believe that x > is larger than y, than believing the opposite. no, again, you could believe that, but its equally valid to believe that A cars getting a high price in the chop-shop market. There is possibly some correlation, but not necessarily a causal relationship between security and the numbers stolen. There are other factors involved, just as in software there are other factors: programming language, skill of the coders, number of testers, fundamental security of the design, security of the linked libraries et etc etc. but cars are a bad analogy, hence my BIG WARNING. > >> END CAR ANALOGY! >> a more pertinent fake example. >> programmer X finds a security hole in konq that when visiting a >> carefully crafted website, allows remote execution of code, privilege >> escalation and ultimately results in a box getting >> rooted. okay. that's obviously a security problem. but programmer X >> doesn't report this problem and no security alert is issued. programmer Y >> finds a security hole in mozilla that allows an already >> installed plugin at a certain version to escalate its own privileges and >> as a result >> download and save a piece of code to disk with the name >> "execute_me". Now if the user happens to see that file and thinks, >> hmmm... I wonder what that is and executes it (after chmod +x) it does >> a rm -rf on their home. programmer y reports this security hole and a >> security alert is made detailing the problem. now, clearly, the konq >> vulnerability is *much* more of a security risk >> than the mozilla error, right? the mozilla one requires the plugin be >> already installed and the right version and then requires the user to >> actually chmod and execute the thing. the konq one just requires the >> user to visit a carefully crafted website. > > If this would be the case in the mozilla vs konq situation, you have to > explain to me why: > 1) konq security issues should be reported at a lower ratio because the person who found the bug likes knowing the bug and wants to be able to utilise it to compromise machines, and thus keeps it under his black hat... > 2) why security issues in konq are more severe it was an example showing how your premise that more reported bugs means less secure. I was showing that the number of reported bugs is not necessarily related to the security. > eg. why there should be reason to believe that there is a statistically > significant bias between the browsers in factors such as reporting security > issues and severity of security issues. because the whole conversation was predicated on the possibility that one browser has significantly larger mind/eye-share and therefor has greater opportunity to have problems discovered and reported. Sure there are some folks looking at fire&iceweaselfox and hiding the vulnerabilities they discover, but as the crowd of users/testers/coders grows, they become statistically less significant than they would be for a program with lower numbers of users/tester/coders. > > I can see no reason to believe one or the other. I just look at the facts - > there are less security issues reported for konq. The only reasonable > conclusion is that konq is more secure. no. that is _a_ reasonable conclusion, but by no means the only one. > >> but based on what you've written above, because the mozilla one was >> reported, then mozilla is less secure than konq. that doesn't add >> up. And in fact, in my fake example above, the lack of security alert >> makes konq even more of a security problem because 1) the right devs >> might not know about the problem to issue a patch and 2) the public >> doesn't know about the problem to avoid it until a patch comes along. > > As I stated above, you have to explain how this constructed example could > have any impact at all on the real mozilla vs konq case. I don't have to explain it because it doesn't. it was an example used to illustrate how your assertion was false. But in fact, I believe that in fact this sort of thing goes on all the time. An unreported security vulnerability is _much_ more dangerous than a reported one. A reported one gets fixed. An unreported one gets exploited. > > Do you really mean that there is some sort of bias in how security issues > are reported and that this is to the advantage of firefox? > nope. I never said that. I merely pointed out that the assumption that fewer reported security flaws means better security is not valid. > As I said, if it is a fact that there is fewer security alerts in konq, the > only reasonable conclusion is that konq has less security issues. nope. konq has fewer security alerts == fewer reported security problems !== fewer actual problems. > All other > conclusions rely on some sort of asymmetry between the browsers, for > example when it comes to the severity of the reported security issues, the > presumed not found or not reported security issues, in the the ratio of > reported found security issues etc. But these are all valid possibilities, not certainties. You have stated that this: fewer security alerts == fewer security problems is a certainty. Or at least near enough so as not to be significant. But its not a certainty. It may, in the final analysis be true, but until _all_ the security problems from both programs have been found and counted, then it is not a certainty. It is unknowable. > If you don't have any facts supporting such kind of asymmetry, you can't > argue that there exist such asymmetry, and especially you can't argue that > such asymmetry is to the advantage of Firefox (it could just as likely be > to the advantage of konq - if it existed). I never argued that there _was_ such an asymmetry. I provided an example of how such an asymmetry would make your assertion false. Note that I have no bias regarding kong and iceweasel. Also, I'm more than willing to embrace a counter example. OpenBSD has had two remote holes in the base install in more than 10 years. And I'm willing to wager that it is in fact probably the most secure OS out there for common folk to use. BUt that is a special case because we _know_ that it was built up piece by piece for one purpose -- to be secure. Security has motivated every decision made about OpenBSD so we have additional data on which to make the assumption that its number of reported vulnerabilities is a good indicator of its security overall. But just pulling two pieces of software out of the air and comparing their security based on the number of reported vulnerabilites doesn't work. Not without some additional information to support those assumptions. A
Attachment:
signature.asc
Description: Digital signature