4 ms·

I've often made this comparison. Software engineering seems primarily focused on making it work correctly, security engineering is about making it fail correctl

I've often made this comparison. Software engineering seems primarily focused on making it work correctly, security engineering is about making it fail correctly. But I also think that latter part should be just given more weight in software engineering in general. A simple example is regex: most people tend to think about writing regexes that positively match expected input, but this generally results in expressions that match things it shouldn't. Writing them is generally easier and more straightforward when you think about not matching what they shouldn't!

jcranmer 5y ago
That's a good point, but I'd actually go a step further and argue that we need to think more generally about actually defining when things should fail. This is exacerbated by a tendency of many people to actually require systems to not fail on bad input but instead try to make as much sense of it as possible so that now compatibility requires you to make the same guesses as to what the user actually meant. See, for example, the tag soup parsing of HTML (which was eventually standardized in HTML5), or the insanity that is trying to parse email messages.
- mooreds 5y ago
  > This is exacerbated by a tendency of many people to actually require systems to not fail on bad input but instead try to make as much sense of it as possible so that now compatibility requires you to make the same guesses as to what the user actually meant. Isn't this Postel's law in practice? https://en.wikipedia.org/wiki/Robustness_principle https://en.wikipedia.org/wiki/Robustness_principle There's a competitive advantage in handling bad input, right? I'm not saying it should always be the primary consideration and certainly not in security situations, but I think that competitive pressures are how we arrived at this situation.

4 ms·

I've often made this comparison. Software engineering seems primarily focused on making it work correctly, security engineering is about making it fail correctl

by stouset 5y ago

jcranmer 5y ago
That's a good point, but I'd actually go a step further and argue that we need to think more generally about actually defining when things should fail. This is exacerbated by a tendency of many people to actually require systems to not fail on bad input but instead try to make as much sense of it as possible so that now compatibility requires you to make the same guesses as to what the user actually meant. See, for example, the tag soup parsing of HTML (which was eventually standardized in HTML5), or the insanity that is trying to parse email messages.
- mooreds 5y ago
  > This is exacerbated by a tendency of many people to actually require systems to not fail on bad input but instead try to make as much sense of it as possible so that now compatibility requires you to make the same guesses as to what the user actually meant. Isn't this Postel's law in practice? https://en.wikipedia.org/wiki/Robustness_principle https://en.wikipedia.org/wiki/Robustness_principle There's a competitive advantage in handling bad input, right? I'm not saying it should always be the primary consideration and certainly not in security situations, but I think that competitive pressures are how we arrived at this situation.