Comment by jovial_cavalier
1 day ago
1) once hypocrite commits were accepted, the authors would immediately retract them
2) I don't think it's unethical to send someone an email that has bad code in it. You shouldn't need an IRB to send emails.
1 day ago
1) once hypocrite commits were accepted, the authors would immediately retract them
2) I don't think it's unethical to send someone an email that has bad code in it. You shouldn't need an IRB to send emails.
> I don't think it's unethical to send someone an email that has bad code in it.
It's unethical because of the bits you left out: sending code you know is bad, and doing so under false pretenses.
Whether or not you think this rises to the level of requiring IRB approval, surely you must be able to understand that wasting people's time like this is going to be viewed negatively by almost anyone. Some people might be willing to accept that doing this harm is worth it for the greater cause of the research, but that doesn't erase the harm done.
Bad code is wasting time; investigating the security of Linux code approval is a good use of time.
See another comment I made in this thread about GKH's response - the UMN group submitted a handful of small patches as part of this study, and "wasted" probably a handful of man hours or at worst a few man days of maintainer time. I don't really consider it a waste because evidence that critical open source infrastructure doesn't bother to run static analysis before merging code from randos is actually useful information that the public deserves to have.
GKH's response was to waste man weeks or man months of maintainer time persecuting every last commit that happened to come from umn.edu, despite having zero reason to believe these commits were more suspect than any other institution's commits.
> evidence that critical open source infrastructure doesn't bother to run static analysis before merging code from randos is actually useful information that the public deserves to have.
It's totally possible to obtain evidence of that without being an asshole to kernel maintainers. Which is the kind of thing that an ethics review conducted before the experiment could have pointed out. If the goal of the experiment was merely to demonstrate the lack of routine static analysis capable of catching such vulnerabilities, then the experiment's design was not justified and the experiment was needlessly harmful to non-consenting participants.
1) How did they hit stable then? [0]
2) Yes, emails absolutely need IRB sign-off too. If you email a bunch of people asking for their health info or doing a survey, the IRB would smack you for unapproved human research without consent. Consent was obviously not given here.
[0] https://lore.kernel.org/linux-nfs/CADVatmNgU7t-Co84tSS6VW=3N...
1) They did not hit stable. GKH is referring, in this email, to a legitimate attempt to contribute from a student at UMN. Whether or not this student was part of the hypocrite commits study, I don't know. But it's not a hypocrite commit, just a normal buggy commit. You can tell, because it's from a umn.edu email address, which they did not use for hypocrite commits.
2) I don't actually care about the internal policies of UMN's IRB. Whether or not the study's approval was proper and whether they would get into trouble with their boss is not my problem. The point is that what they did is obviously not immoral or unethical.
The point of an IRB is to act as an outside reviewer of _ethics_. IRBs aren't some checklist thing admin put in to protect the University's reputation, they exist as a direct reaction to huge amounts of unethical human experimentation occurring last century.