[jerf]

Your argument is assuming something that I don't believe is true, which is that we're already on the Pareto optimality frontier for security/convenience. It is certainly true that you can not forever increase security without eventually impacting usability, but I don't think many people are actually in that position.

I've improved a lot of real-world security by replacing functions that bash together strings to produce HTML with code that uses functions to correctly generate HTML, and the resulting code is often shorter, easier to understand, easier to maintain, and would actually have been easier to write that way in the first place given how much of the function was busy with tracking whether we've added an attribute to this tag yet and a melange of encoding styles haphazardly applied. What costs you can still come up with ("someone had to create the library, you have to learn to use it") are generally trivial enough to be ignored by comparison, because the costs can be recovered in a single-digit number of uses.

[nkassis]

"Your argument is assuming something that I don't believe is true, which is that we're already on the Pareto optimality frontier for security/convenience. It is certainly true that you can not forever increase security without eventually impacting usability, but I don't think many people are actually in that position"

That's true that we aren't at the sweet spot yet but that what I meant by companies being bad about doing the risk analysis judgement of security versus usability.

On you second point languages have gone through that cycle. Look at Java doing boundary checks. That helps avoid a whole class of security issues but at the cost of making things that C was able to do easily more difficult. These tradeoffs happen at every layer.