Re:The Great DOM Fuzz-Off of 2017
by WhitneyLand on Thursday September 21, 2017 @09:48PM
(#15308837)
Your’re missing his point. The issue is not the purpose of the effort, that’s clear, everyone agrees. The question I infer is closer to be something like: If crashing bugs are inadvertently found in software, from whatever source, what would you expect the interest/motivation/urgency to be in fixing them?
It’s a good question but I’m not sure the answer is clear. On small projects I’d make the case that 100% of reproducible crashes should be fixed, always. However when the “project” approaches operating system scale and complexity, most pure principle policies like that cease to exist for practical reasons. Most decisions, not just bug fixing, are about tradeoffs/cost benefit considerations due to the simple realization you can’t boil the ocean.
Re:The Great DOM Fuzz-Off of 2017
by microcolonel on Friday September 22, 2017 @02:41AM
(#15309889)
> you can’t boil the ocean.
Call me crazy, but it seems like we have a responsibility to boil this ocean. If we don't, the quality will continue to spiral down into the abyss.
Re:The Great DOM Fuzz-Off of 2017
by WhitneyLand on Monday September 25, 2017 @04:59PM
(#15334089)
Boil the ocean is an expression meaning do the impossible, so I don't think it matters much if we have a responsibility to do something we are incapable of. It does matter if we do the next best thing, and that's where the trade offs come in.
IMO this restricted sense of "bug" is clear from the second sentence of the article ("in the recent years the popularity of those kinds of bugs in targeted attacks has somewhat fallen in favor of Flash (which allows for cross-browser exploits) and JavaScript engine bugs (which often result in very powerful exploitation primitives)"). Even the first sentence becomes questionable if we interpret "bugs" more broadly (Historically, DOM engines have been one of the largest sources of web browser bugs); the example given is a CVE, etc.
So IMO I wouldn't call it the fine print. And in this context, the remarks about MemGC also make sense (Microsoft considers these bugs strongly mitigated by MemGC and I agree with that assessment […] useful mitigation that results in a clear positive real-world impact) — "mitigation" is the term for something makes it hard to exploit a [security] bug, not something that makes the bug go away.
A similar question about general bugs (as in "the last bug in TeX…") would be very interesting, but I don't know if we have a way of measuring it.