[newphonnewaccnt]

The hash input could just be a generic description of the bug, minus any sensitive info, plus some salt.

All report hashes would have to go public as soon as the report is accepted. The hash input could go public once the bug goes public, so the duplicate reporters can then finally see proof that the bug had already been reported.

In what cases would companies be unable to publish generic descriptions after the bug is public? I'm not in the industry so I have no idea about this.

[thaumasiotes]

I can prepare generic descriptions of bugs well in advance, regardless of whether those bugs are known to me or not. That scheme lets me mark everything duplicate if I feel like it.

[newphonnewaccnt]

It comes down to how much companies are willing to reveal after the fact then. If companies aren't prepared to reveal enough unpredictable detail involved in an exploit after the exploit had been fixed, that's another issue. I think companies like Google would be ok with it though.

[thaumasiotes]

You're proposing that they do a lot of work for no benefit. What would they get out of it?

You're also still failing to account for the fact that reports rarely become public. I can refer you, again, to a random number just as easily as I can refer you to the calculated hash of my bespoke summary of an issue that was reported eight years ago.

[newphonnewaccnt]

As stated previously, it wouldn't work unless the company was prepared to disclose all reports at two stages: 1) hash of unpredictable description of the issue when the issue is reported, 2) hash input when the issue becomes public.

There would be no benefit except for a tiny amount of goodwill, so it's almost certainly not worth it. This is simply a method to address the duplicates issue. Nothing else.