Dave, > What you're proposing is that the ironworker should reengineer the > bridge in-situ (as if he even has the authority!), causing weeks of > delay, cost overruns, and possibly lead to his employer never getting a > bridge contract again.
That's not at all what I'm suggesting... guess my point wasn't so obvious :) I'm not saying the programmer should totally redesign the application if it's not secure. I am saying that they _SHOULD_ do the simple, 'trivial' things within the context of their current job. Validating input, handling errors properly, ensuring ownership of various id's, etc. All of these things fall in this category. Yet these days, when programmers actually _DO_ do these things, they call these things 'security features' and themselves 'secure programmers' (or whatever). And that's what I think is ridiculous. Other things, like designing a secure protocol/management of your encryption system can be though of as 'something extra' but these types of problems aren't the _MAJOR_ problems (they are big problems, however) that we deal with. There are, of course, design concepts that shouldn't really be billed as 'extra' either [like appropriate user management/access systems, etc]. And back to the main point of this discussion, is that lack of these things in application shouldn't be blamed on consumers (or even management) for not asking. These things should be assumed... -- Michael > > Somehow, that just doesn't hold water. > Kind Regards, > -dsp
