Quote:
By that logic, when you release an advisory... you are punishing the users of that vendor. They are then forced to rely on half baked patches until an official patch is ready.
your logic is short sided.
yes users will be punished in the short term and that is unfortunate but it is the only way to bring about change. your "ethical" approach only empowers the status quo by protecting vendors and users of bad software that most likely did not establish a good security policy. the fault for damages from vulnerabilities is redirected to unethical disclosure and hackers and the finger is never pointed back to the vendor for providing vulnerable software or the users for not securing the software properly.
the only time a vendor catches heat is if they fail to respond swiftly to a published flaw. this is the wrong approach. the public fails to grasp that the software has been vulnerable since the flaw was introduced not published. if a vendor responds swiftly to a disclosure the public has a "no harm no foul approach" which contains no push for change.
Quote:
Do you develop software? How familiar are you with software development processes? Are you saying that maintenance should be punished?
i am too young to develop software professionally but i do for school. i am familiar with the waterfall v&v waterfall and spiral development process models. i am also familiar with cocomo models function point model and ideal and cmmi. i am not saying that maintenance should be punished. i am saying that putting the effects of the flaws directly on to the public the resulting loss of customers will force companies to change their approach to security. only when it becomes more expensive to have flaws than to not have flaws will this happen.
Quote:
"Unusual or obscure"? Sounds more like "unsupported". If software isn't supported in an enviroment, expect it to fail... If a company creates bad patches, then they're punishing themselves... Let bad software be bad software, just don't let it effect the innocent users of that software.
i would say "unsupported" is too strong a word. it is unacceptable how many patches alter the way some elements of effected apis work. if this were not the case testing before applying patches would not be required.
users innocent or not must be punished. you are providing short term comfort and enabling a long term problem. vendors have no cause to stop building so much software that requires patches. vendors have no cause to make security configuration guides more available to users. the only way to create a cost is to hurt the customers. how is this different than any other industry? by protecting vendors from their faults you further bad software.
Quote:
If you think software quality improvement by assisting attacks against their users is ethical, then I will have to disagree. It's like blackmail, that's what immediate full disclosure comes down to in my mind. Sure, proper policy may make application level security somewhat pointless, but in releasing an advisory prematurely you are putting others at risk.
i think the long term advantages of forcing tighter competition of quality and not just features outweighs the immediate damages caused by not protecting the bad vendors.
Quote:
If you're going to punish a vendor, I don't agree it should be done by assisting the exploitation of it's users so they lose marketshare. Fine 'em or something...
customers won't decide with their checkbooks that the demand better software unless they are forced to. the presence of open source software and the international nature of the situation prevents fining from being applicable at this time. also the mind set that exploits are the fault of unethical disclosure provides vendors a scapegoat to prevent being fined.