3 ms·

Project Zero is exclusively concerned with security: when they say "bug" they mean "security bug"; when they say "fuzz" they mean "fuzz with an intent to find e

by svat 9y ago

Project Zero is exclusively concerned with security: when they say "bug" they mean "security bug"; when they say "fuzz" they mean "fuzz with an intent to find exploitable security vulnerabilities", etc. 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.

WhitneyLand 9y ago
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.
- microcolonel 9y ago
  > 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.
  - WhitneyLand 9y ago
    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.

by svat 9y ago

WhitneyLand 9y ago

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.

microcolonel 9y ago
> 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.
- WhitneyLand 9y ago
  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.