The number of reports that eventually become fully public is nearly zero. Most don't become public at all, but of those that do, a lot of content is generally redacted.
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.
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.
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.
Other people have covered most of the rest of your comment, but there are things to say about this one specifically. The reporting platforms support it. It's a very frequent request from researchers who file duplicate reports. It's rare for a company to do this, because (1) it doesn't do anything to help with the issue being reported; (2) it doesn't change how the report will be handled; and (3) researchers hate it. They don't hate it when they file a duplicate report and want to see what scooped them. But they hate it when their report gets shared with someone who filed a duplicate finding.
Sharing duplicate reports causes a lot more fights than it solves. And it tends to piss off the higher-productivity researchers in an attempt to soothe lower-productivity ones, who generally aren't soothed anyway.
The ticket I saw the most outrage on over this issue was one that I duped to another ticket with a higher number. (HackerOne assigns ticket numbers serially. Fun!) How could I justify calling this report a duplicate of one that, as anyone could see, was filed later?
Well, the second report began
> Hi, I reported this through email and was told that in order to claim a reward I should open a ticket in the HackerOne program...
(This situation is odd enough, and easy enough to explain without sharing private information, that I could explain it to the guy on the lower ticket number without causing problems (or sharing the other ticket directly. That's a big no-no.). I present it here as an example illustrating that, even if you think you have ironclad evidence that the program is out to screw you over, it probably isn't.)
I definitely saw companies doing things that were unfair considering the program as a whole. That generally happened as part of an effort to preserve a relationship with a researcher who frequently filed useful reports. I never saw a ticket duped inappropriately. If you want my advice on how to get the most money out of your bug reports, it's this:
- Don't antagonize the team handling you.
- As much as you can get away with, demonstrate what you can do with the issue you report. The program will say "we investigate the impact of every issue and pay out according to the highest-severity potential impact." They are sincere. But they don't have the motivation you do to find the highest-severity potential impact. Any impact you actually demonstrate will automatically be considered, because nobody had to notice it was possible.
- Sometimes an issue might ambiguously fall into a low-paying category, or maybe a high-paying category. Try to characterize it as belonging to the high-paying category.
- Decide whether you're a "deep" guy who finds complex issues on a handful of platforms or a "shallow" guy who finds the same set of related issues everywhere he can with minimal effort. Both approaches work. If you're a "shallow" guy, make sure that when you report an issue, it's really there, and don't argue too much over what you think it should be worth. If you're a "deep" guy, you have more scope to develop a personal relationship with the team who handles you.
- Watch for existing programs to add new platforms. This often happens when a company with an existing program makes a new acquisition. The new platform probably has a lot of low-hanging fruit.
- Clean up after yourself. The most outrage I've ever seen on the company side was someone who demonstrated full-on RCE on a company server. He installed a webshell. And his webshell was still up when he filed his report. Don't be that guy. You can be disqualified from a bug that would have paid tens of thousands of dollars.