[SC-L] (fwd) New mailing list announced -- MobileBugtraq

FYI, this seems kind of topical -- a new bugtraq list specifically for discussing vulnerabilities in mobile terminals. See message below, forwarded from the Full-Disclosure list. Cheers, Ken van Wyk -- KRvW Associates, LLC http://www.KRvW.com == snip ==

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

At 7:44 AM -0400 4/7/05, Dave Paris wrote: > What you're proposing is that the ironworker should reengineer the > bridge in-situ (as if he even has the authority!) or the expertise. -- Larry Kilgallen

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

Blue Boar <[EMAIL PROTECTED]> wrote: > [Security] 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. ...if you're lucky. (Or if you're doing development right, but IME that

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

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 poi

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

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". You would be panic stricken. Fear would overcome you, and you might either

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

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 b

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

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 end

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

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 re

Re: [SC-L] Mobile phone OS security changing?

Michael Silk wrote: > The last thing I want is my mobile phone updating itself. I imagine > that sort of operation would take up battery power, and possibly cause > other interruptions ... (can you be on a call and have it update > itself?) A larger issue for me (though I'm straying a bit from SC)