Re: [SC-L] Application Insecurity --- Who is at Fault?

2005-04-07 Thread Michael Silk
On Apr 7, 2005 12:43 PM, Blue Boar [EMAIL PROTECTED] wrote: Michael Silk wrote: See, you are considering 'security' as something extra again. This is not right. It is extra. It's extra time and effort. And extra testing. And extra backtracking and schedule slipping when you realize you

Re: [SC-L] Application Insecurity --- Who is at Fault?

2005-04-07 Thread Blue Boar
Michael Silk wrote: See, you are considering 'security' as something extra again. This is not right. It is extra. It's extra time and effort. And extra testing. And extra backtracking and schedule slipping when you realize you blew something. All before it hits beta. Any solution that ends

Re: [SC-L] Application Insecurity --- Who is at Fault?

2005-04-07 Thread Margus Freudenthal
Michael Silk wrote: Consider the bridge example brought up earlier. If your bridge builder finished the job but said: ohh, the bridge isn't secure though. If someone tries to push it at a certain angle, it will fall. All bridges have certain limits. There is difference between a footbridge and

Re: [SC-L] Application Insecurity --- Who is at Fault?

2005-04-07 Thread Michael Silk
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