It's okay to run experiments on humans without their explicit informed consent now?
“They introduce kernel bugs on purpose”
631–640 of 1001 posts
Re: “They introduce kernel bugs on purpose”
#632Here's a clarification from the Researchers over at UMN[1]. They claim that none of the Bogus patches were merged to the Stable code line : >Once any maintainer of the community responds to the email,indicating “looks good”,we immediately point out the introduced bug and request them to not go ahead to apply the patch. At the same time, we point out the correct fixing of the bug and provide our proper patch. In all t…
The response makes the researchers seem clueless, arrogant, or both - are they really surprised that kernel maintainers would get pissed off at someone deliberately wasting their time? From the post: * Does this project waste certain efforts of maintainers? Unfortunately, yes. We would like to sincerely apologize to the maintainers involved in the corresponding patch review process; this work indeed wasted their prec…
This is an indignant rebuttal, not an apology.
No one says "wasted their precious time" in a sincere apology. The word 'precious' here is exclusively used for sarcasm in the context of an apology, as it does not represent a specific technical term such as might appear in a gemology apology.
Re: “They introduce kernel bugs on purpose”
#633This seems like a pretty scummy way to do "research". I mean I understand that people in academia are becoming increasingly disconnected from the real world, but wow this is low. It's not that they're doing this, I'm sure they're not the first to think of this (for research or malicious reasons), but having the gall to brag about it is a new low.
> having the gall to brag about it is a new low Even worse: They bragged about it, then sent a new wave of buggy patches to see if the "test subjects" fall for it once again, and then tried to push the blame on the kernel maintainers for being "intimidating to newbies". This is thinly veiled and potentially dangerous bullying.
> This is thinly veiled and potentially dangerous bullying.
Which itself could be the basis of a follow up research paper. The first one was about surreptitiously slipping vulnerabilities into the kernel code.
There's nothing surreptitious about their current behavior. They're now known bad actors attempting to get patches approved. First nonchalantly, and after getting called out and rejected they framed it as an attempt at bullying by the maintainers.
If patches end up getting approved, everything about the situation is ripe for another paper. The initial rejection, attempting to frame it as bullying by the maintainers (which ironically, is thinly veiled bullying itself), impact of public pressure (which currently seems to be in the maintainers' favor, but the public is fickle and could turn on a dime).
Hell, even if the attempt isn't successful you could probably turn it into another paper anyway. Wouldn't be as splashy, but would still be an interesting meta-analysis of techniques bad actors can use to exploit the human nature of the open source process.
Re: “They introduce kernel bugs on purpose”
#634I don't know how their IRB approved this, although we also don't know what details the researchers gave the IRB.
It had a high human component because it was humans making many decisions in this process. In particular, there was the potential to cause maintainers personal embarrassment or professional censure by letting through a bugged patch.
If the researchers even considered this possibility, I doubt the IRB would have approved this experimental protocol if laid out in those terms.
Re: “They introduce kernel bugs on purpose”
#635Using faked identity and faked papers to expose loopholes and issues in an institution is not news in science community. Kernel community may not be immune to some common challenges for any sizable institution I assume, so some ethical hacking here seems reasonable.
However, doing it repeatedly with real names seems not helpful to the community and indicates a questionable motivation.
Re: “They introduce kernel bugs on purpose”
#636[deleted]
Re: “They introduce kernel bugs on purpose”
#637Here's a clarification from the Researchers over at UMN[1]. They claim that none of the Bogus patches were merged to the Stable code line : >Once any maintainer of the community responds to the email,indicating “looks good”,we immediately point out the introduced bug and request them to not go ahead to apply the patch. At the same time, we point out the correct fixing of the bug and provide our proper patch. In all t…
The main issue here is that it wastes the time of the reviewers and they did not address it in their reply.
To help clarify for purposes of continuing the discussion the original research did address the issue of minimizing the time of the reviewers [1] [2]. Seems the maintainers were OK with that as no actions were taken other than an implied request to stop that kind of research.
Now a different researcher from UMN, Aditya Pakki, has submitted a patch which contains bugs that seems to be attempting to do the same type of pen testing although the PhD student denied it.
1. Section IV.A of the paper, as pointed out by user MzxgckZtNqX5i in this comment: https://news.ycombinator.com/item?id=26890872
> Honoring maintainer efforts. The OSS communities are understaffed, and maintainers are mainly volunteers. We respect OSS volunteers and honor their efforts. Unfortunately, this experiment will take certain time of maintainers in reviewing the patches. To minimize the efforts, (1) we make the minor patches as simple as possible (all of the three patches are less than 5 lines of code changes); (2) we find three real minor issues (i.e., missing an error message, a memory leak, and a refcount bug), and our patches will ultimately contribute to fixing them.
2. Clarifications on the “hypocrite commit” work (FAQ)
https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc....
"* Does this project waste certain efforts of maintainers? Unfortunately, yes. We would like to sincerely apologize to the maintainers involved in the corresponding patch review process; this work indeed wasted their precious time. We had carefully considered this issue, but could not figure out a better solution in this study. However, to minimize the wasted time, (1) we made the minor patches as simple as possible (all of the three patches are less than 5 lines of code changes); (2) we tried hard to find three real bugs, and the patches ultimately contributed to fixing them."
Re: “They introduce kernel bugs on purpose”
#638This seems like a pretty scummy way to do "research". I mean I understand that people in academia are becoming increasingly disconnected from the real world, but wow this is low. It's not that they're doing this, I'm sure they're not the first to think of this (for research or malicious reasons), but having the gall to brag about it is a new low.
> having the gall to brag about it is a new low Even worse: They bragged about it, then sent a new wave of buggy patches to see if the "test subjects" fall for it once again, and then tried to push the blame on the kernel maintainers for being "intimidating to newbies". This is thinly veiled and potentially dangerous bullying.
>then tried to push the blame on the kernel maintainers for being "intimidating to newbies".
As soon as I read that all sympathy for this clown was out the window. He knows exactly what he's doing.
Re: “They introduce kernel bugs on purpose”
#639It would be fascinating to see the ethics committee exemption. I sense there was none. Or is this kind of experiment deemed fair game? Red vs blue team kind of thing? Penetration testing. But if it was me in this situation, I'd ban them for ethics violation as well. Acting like a Evil doer means you might get caught... and punished. I found the email about cease and desist particularly bad behavior. If that student w…
I didn't read this bit: "The IRB of University of Minnesota reviewed the procedures of the experiment and determined that this is not human research. We obtained a formal IRB-exempt letter"
Um. Ok.
Re: “They introduce kernel bugs on purpose”
#640This feels like the kind of thing that "white hat" hackers have been doing forever. UMN may have introduced useful knowledge into the world in the same way some random hacker is potentially "helping" a company by pointing out that they've left a security hole exposed in their system. With that said, kernel developers and companies with servers on the internet are busy doing work that's important to them. This sort of…
Your analogy doesn't work. A true "white hat" hacker would hack a system to expose a security vulnerability, then immediately inform the owners of the system, all without using their unintended system access for anything malicious. In this case, the "researchers" submitted bogus patches, got them accepted and merged, then said nothing, and pushed back against accusations that they've been malicious, all for personal…
That's gray-hat, a white-hat wouldn't have touched the system without permission from the owners in the first place.