In the next few weeks we’ll be changing the Won’t Fix outcome to Informational. You may notice this shift happening gradually. This means that while you’ll see “informational” start to appear in the Bugcrowd user interface, not all references to “won’t fix” will change immediately. For a time, “won’t fix” and “informational” will be considered equivalent until we finish migrating our data and services across to the new nomenclature.
In regard to our researcher incentives and outcomes, “Informational” will be largely equivalent to “won’t fix”. Researchers will receive the same amount of points for an informational submission as they would for a won’t fix. In most reports and breakdowns, the mapping will be similarly easy.
Users of our past and current customer API versions will still use “won’t fix”, to maintain backward compatibility. We’ll cut a new version of the API that uses the new state and encourage everyone to upgrade to that, but maintain backward compatibility for a long time to come.
Why Bugcrowd is Making this Change
The differences in meaning between words can be subtle, yet powerful. In English, telling your friend that you can’t do something is very different to telling them that you won’t – the “can’t” implies a physical incapability, and carries the subtext that you might want to do something but it’s impossible. By contrast, “won’t” implies that you could do something, but that you don’t want to.
It’s time to pick some better words.
We think that the word “informational” is relatively neutral. It covers a broader range of cases without as many unintended implications, and is more widely-accepted in the security industry.
In addition, we will be changing the positioning of “Informational” to be an accepted end-state for a Submission. Currently, the Bugcrowd platform considers it a weakly rejected end-state and some statistical calculations count “won’t fix” as valid, others not. We’re going to be much clearer about its status as an accepted state.
When we were first building the Bugcrowd platform, we opted to use the words “won’t fix” to describe submissions that we or the customer acknowledge as being technically true, but are not applicable in a particular context, are somehow mitigated in a specific case, or an accepted risk.
For example: on your bugcrowd.com researcher profile, it’s possible to enter markdown as part of your bio. This can include links to other sites. This could look like an insecure design – the link could go anywhere, and surely SEO farmers would try to use it deviously!?
However, we mark those links with the nofollow and noreferrer attributes, and your profile is only visible once you have at least one valid submission. To our minds, this is the correct balance of power for researchers, sanity for our platform, and secure behaviour for end-users.
In this case, we marked the first-to-report submission as “won’t fix”.
You could say that we’ve accepted the risks associated with the feature as designed, and don’t intend to change it. In this context, “won’t fix” is apt.
However, you could also argue that there was nothing there to fix in the first place! The feature was working as intended, and while the researcher identified some interesting hypotheticals, they didn’t pan out. If you interpret it this way, “won’t fix” is a paradox.
For many vulnerabilities and many of our customers, either interpretation is fine. In other instances, this distinction can be extremely important. For legal or compliance reasons, “won’t fix” can carry this implication that something is wrong or not working correctly, and the customer is deliberately choosing not to fix it. “Can’t fix because it’s not broken” is very different to “won’t fix because I don’t want to”. For many of our users, this distinction is very important.
We hope this change will clarify a lot of confusion, and make both our researchers and our customers happier with the outcomes of their submissions. Hack the planet!
