> I do not need to be a security researcher to understand that they, as with everyone else, have an obligation to the body politic to not be a dick
So are you talking about AMD being dicks by releasing buggy chips, or the researchers somehow being dicks for finding out?
Related question: if a "food security researcher" discovered a vendor was selling contaminated produce - would it be reasonable for them to give the vendor 90 days notice before telling the public?
While I think it's reasonable and appropriate professional practice for _some people/teams_ to go down the "coordinated disclosure" path (I think the world is a better place for having Tavis Ormandy disclose the way he chooses to), it does without doubt benefit the company who's products are flawed more than the researcher or the public. Anybody who knows they work at a firm that's going to be described dismissively like AMD here did "This company was previously unknown to AMD" is quite likely correct to publish-and-be-damned, because you can bet there's a non-zero chance that AMD's response to non-public disclosure is going to include either stonewalling and stringing the problem out as long as possible, or lawyering up ad threatening to sue the "previously unknown to AMD" company into oblivion.
If you don't want public disclosure of security flaws about your products, either don't make flawed products or don't ship them to the public. Especially if some of the key selling features of said product include bullet points like "AMD Secure OS".
> Related question: if a "food security researcher" discovered a vendor was selling contaminated produce - would it be reasonable for them to give the vendor 90 days notice before telling the public?
This example is absolutely farcical. It's not even close to the same thing and you know it. A security flaw is not equivalent to poisoned food - it still requires outside action to be exploited.
Everybody releasing chips releases buggy chips. It's the current reality of both hardware and software. Unless they do it maliciously, they're not dicks.
Close to 100% of software has bugs. Almost all drivers have bugs. Anything that prioritises company profit and release dates over complete correctness in sectors where bugs == deaths, will have bugs. (And even those sectors are not magically immune) So yes - I expect they do.
Unless they released it maliciously, I don't hold it against them. And wouldn't call anyone a dick unless they planned to do something evil.
Exceptions: issue was known but got ignored due to release schedule, or security was never mentioned in the project and at no level was there any security consideration. But that's for specific management issues, not engineers or the vendor in general.
What's important aren't really the bugs, bugs can be fixed. What's important is who is allowed to run, inspect, share, and modify the code. If only the copyright holder is allowed to do this, that's proprietary software and that's malicious. If a user's software freedom is respected so users can choose to fix it themselves, wait for another release, hire someone else to fix the code, or live with the bugs that's treating the user properly.
Everyone makes mistakes; it's more about how those mistakes are handled and if a user's control over their computer is respected.
So are you talking about AMD being dicks by releasing buggy chips, or the researchers somehow being dicks for finding out?
Related question: if a "food security researcher" discovered a vendor was selling contaminated produce - would it be reasonable for them to give the vendor 90 days notice before telling the public?
While I think it's reasonable and appropriate professional practice for _some people/teams_ to go down the "coordinated disclosure" path (I think the world is a better place for having Tavis Ormandy disclose the way he chooses to), it does without doubt benefit the company who's products are flawed more than the researcher or the public. Anybody who knows they work at a firm that's going to be described dismissively like AMD here did "This company was previously unknown to AMD" is quite likely correct to publish-and-be-damned, because you can bet there's a non-zero chance that AMD's response to non-public disclosure is going to include either stonewalling and stringing the problem out as long as possible, or lawyering up ad threatening to sue the "previously unknown to AMD" company into oblivion.
If you don't want public disclosure of security flaws about your products, either don't make flawed products or don't ship them to the public. Especially if some of the key selling features of said product include bullet points like "AMD Secure OS".