3 ms·
Interesting, looks like the 2nd time they're doing the same thing, and 2nd time they're in hot water for it. They even apologized the first time by pleading nai
by lmeyerov 6y ago
Interesting, looks like the 2nd time they're doing the same thing, and 2nd time they're in hot water for it. They even apologized the first time by pleading naivete: https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.pdf https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.... .
First time they initially skipped IRB review for sending malicious patches to the mailing list, which people do install. (So IRB exemption should not apply.) A top security conference allowed a paper with a broken IRB process, and UMN IRB, when a later IRB exempt request was filed, explicitly allowed this. Bad, bad, and bad.
The latest Linux incident seems like a repeat by the same CS dept, advisor, student, & presumably, UMN IRB. No naivete excuse anymore, this is now business as usual.
The bigger fail to me is the UMN dept head + IRB, and the security conference review process around IRB norms. Especially damning that it's a repeat of the same IRB mess. IRB exemption matters a lot for practicing scientists, and leadership tolerating this stuff is what will get it taken away for everyone else.
Fool me once..
- re 6y ago> looks like the 2nd time they're doing the same thing It's not clear that they're doing the same thing--we don't know that these recent patches are deliberately bogus. See this comment with clarifications from the other post: https://news.ycombinator.com/item?id=26890583 https://news.ycombinator.com/item?id=26890583
- lmeyerov 6y agoAgreed! The broader R&D group seems to work on symbolic execution, and given the patches, which it seems to stem from. Most charitably, the tool makes changes maintainers largely don't care about -- see the revert reviews that characterize past acceptances as being rubberstamping of irrelevant patches to irrelevant code -- so this just violates basics like informed consent by not disclosing what's happening. Maintainers had to figure out the nonsense, and instead of declining a second round of undesirable non-opt-in participation, banned. What would normally happen is the patches would be tagged w/ the R&D tool, so people know they're part of an experiment, and can ignore / ask them to stop / consent through action. Less charitably, it is a DoS attack on reviewers, and who knows what else is in here. Either way... not good.
- UncleMeat 6y agoYeah I agree. To me, the biggest problem is with Oakland, who accepted the paper. A single faculty member doing something really stupid is one thing. But the field's top conference accepting the work? Christ.
- ShamblingMound 6y agoOh my gosh, their IRB approved this as exempt knowing all the details? Initially, my guess was that the researchers misinformed the IRB about what the experiment involved. But the IRB approved as exempt an experiment involving (1) humans (2) who are deceived (3) and who do not provide informed consent. Additionally, an IRB review should take into consideration all possible harms to people that could result from an experiment, and as a result of this experiment, many downstream Linux users were affected who also did not have an opportunity to provide informed consent. I would think this would be a hard experiment to get approval for at all, let alone exempt. That's bananas. For me, this taints the reputation of the university. Edit: The more I think about this, the worse it gets. One of the pragmatic aspects of not harming participants is compensating them for their time. Through the experiment, researchers get data, and participants get something in a trade that's not always exactly fair, but at least treats the research participants with respect. That's why it's common to receive gift cards for filling out surveys. Research participants in this experiment (skilled software developers) were presumably not compensated for their time during the experiment and their time is probably worth quite a bit. How in the world did this pass IRB as exempt.