I agree with this.

> and so the term "responsible disclosure" is misleading.

I think this is a key point. As I said, I think "responsible" implies being responsible on both sides: neither simply publishing without sufficient time for a vendor to make a fix, nor waiting indefinitely while the vendor waffles around or tries to pretend the vulnerability doesn't exist. "Responsible disclosure" focuses (or ought to focus) on minimizing harm to users, whereas "coordinated disclosure" focuses on cooperating with the vendor. As such, "Responsible disclosure" in fact carries within itself the threat of going public if the vendor is dragging their feet, where "coordinated disclosure" doesn't.

I continue to think that we should use the term "responsible disclosure", and insist that it mean actually behaving responsibly to users.

[Minor edits]

The problem is that (charitably) the term of art (or uncharitably, brand) "responsible disclosure" is attached to some very specific norms, including "not releasing vulnerabilities without a patch" and "giving vendors a commercially reasonable amount of time to create a patch" and "working closely with vendors to coordinate that time window" and "redacting or carefully reducing POC code", which are not themselves universal or even generally "responsible".

They're commercially responsible, to be sure! But it should not be an obligation of unpaid third party researchers to expend any effort whatsoever to be responsive to a vendor's commercial concerns. It's a nice thing to do, and some people are just preternaturally nice to vendors, and that's usually fine, but there's nothing deontologically "responsible" about that.

I'm saying more than that.

We both seem to agree that there is an ongoing war about disclosure; and that large vendors (through a mix of good, neutral, and bad intentions) are warring to make disclosure more convenient and less painful for themselves, to the detriment of their users (and ultimately themselves as well); and that the use of words is one arena in which that warfare exhibits itself.

But we've come to opposite conclusions about the best way to fight the war in this specific arena.

You've observed that companies are trying to define "responsible" to mean "commercially responsible". But rather than recognizing this attempt at redefinition as an attack, and insisting on using the word "responsible" to actually mean responsible towards users, you seem to think that the use of the word itself is an attack; and want to instead try to insist on using a different term, "coordinated disclosure".

I think that's a bad strategy. You're advocating that we surrender the word "responsible" entirely to large vendors. Large vendors are not going to stop using the word "responsible"; if right-minded security researchers simply abandon the word, then the broader public are going to be entirely at the mercy of vendors to decide what's "responsible". Furthermore, as I've argued, using "coordinated" shifts all focus to the vendor, removing any focus from the user at all.

In the war over disclosure, your strategy seems to me to hand a massive win to big vendors.

I think a much better strategy is to counter-attack. The word "responsible" is too valuable a term to just give up. We must continue to insist that "responsible" means "responsible to users"; and we must continue to insist that there are times when pressuring and even embarrassing large companies is the most responsible thing to do.

http://attrition.org/security/rant/z/ms-disclose.html

It’s a dumb term. You should never use it. Use a more descriptive and neutral term.

That doesn't give a history of responsible disclosure, but it does correspond with my understanding of the situation.

He mentions "RFPolicy" invented by security researcher Rain Forest Puppy [1]. This policy includes the following stipulation right at the top:

> You basically have 5 days (read below for the definitions and semantics of what is considered a 'day') to return contact to the individual, and must keep in contact with them at least every 5 days. Failure to do so will discourage them from working with you and encourage them to publicly disclose the security problem.

This is completely the opposite of "the vendor is entirely in control of the process". A few paragraphs after this reference, the author of your article says:

> This entire charade [a push by Microsoft about disclosure] is nothing more than an elaborate PR scam. The five security companies that are involved (@Stake, BindView, ISS, Foundstone, Guardent), were they not following these general rules along the lines of responsible disclosure?

This paragraph implies that the author of the article identifes RFPolicy -- a policy created by security researchers themselves -- with "responsible disclosure", and is blaming Microsoft for trying to hijack the term.

But instead of insisting that "responsible disclosure" means something like RFPolicy, you're insisting that actually "responsible disclosure" means something like what Microsoft wants it to mean. Rather than fighting to maintain control a term that security researchers invented, you're advocating surrendering the term to Microsoft and other organizations like them.

I think that's bad strategy.

[1] https://dl.packetstormsecurity.net/papers/general/rfpolicy-2...

Edit: Clarify some antecedents.

This isn’t surrendering the term, not only because Microsoft largely invented it, but even they disavowed it 10 years ago. Not even Microsoft wants that term anymore!

You cannot “insist” what it means. You’re trying to redefine it from it’s original framework to fit your personal definition of “responsible”, which nobody agrees on, and which is one of the many reasons that it’s a dumb term.

It’s like saying you believe in buying cars that are responsible colors. If you want to communicate efficiently and without being inflammatory and presumptuous in a community where reasonable minds have long disagreed, you should just say “red”. Everyone knows what that means.

Here is some other reading:

https://blogs.technet.microsoft.com/ecostrat/2010/07/22/coor...

https://resources.sei.cmu.edu/asset_files/SpecialReport/2017... (See 1.2.5.1)

https://www.computerworld.com/article/2519499/drop--responsi...

https://security.googleblog.com/2010/07/rebooting-responsibl...