There is no inventive for researchers to break new features before they are released. In fact it is often more trouble than it’s worth to point them out.
I like to see it as a service to the community -- not a lot of fame and glory if things launch in a safe state, but users are better off. Also, you often have a higher chance to influence things at the design stage.
-
-
Yeah true but if there is a negative incentive then it’s unlikely that features will be properly reviewed.
-
I agree. Do you have any ideas for setting up such incentives? Would it help if developers (e.g. browser vendors) credited researchers for design advice they acted upon before launching?
-
Maybe design bounties or credit when a feature is rejected. The problem is that people creating these features invest a lot of time and take the criticism personally and often dismiss the reports.
-
The flip side is that so few researchers participate at the design stage, that you can be sure that the developer will notice if you file a spec bug, or blog about the feature. It might not result in an immediate change and is not as clear-cut as a CVE, but people pay attention.
-
BTW, this doesn't contradict anything you're saying, I'm just more hopeful that developers who learn about security problems with their upcoming features will do the right thing and fix them. At least this matches my experience...
-
I think they get too attached to them because of the time invested in the code. They are unable to see the bigger picture. But it’s definitely subjective. I personally think iframe srcdoc is a terrible feature whereas many people do not. Same with template literals.
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.