Earlier quoted context omitted.
Ah thanks. How moronic, whomever thought this was in any way a good idea is pretty out of touch with reality.
isn't it just a form of red teaming? has red teaming fallen out of fashion?
[deleted]
UMN CS&E Statement on Linux Kernel Research
101–110 of 332 posts
Re: UMN CS&E Statement on Linux Kernel Research
#102It was a good idea to ban the uni entirely, cause that way they had to respond.
Anyone saying that it was a bad idea to ban the entire University isn't looking at the big picture. I look at it from a very philosophical standpoint: The entire idea of an academic (research) institution can be summarized as "an entity representing a group of trusted people who act in good faith of that institution". The moment one of your researchers acts in bad faith, or shows that they cannot be trusted, it's cle…
Banning the university is fine to send a message, but reverting all patches from umn emails seems very shortsighted to me. Especially blindly reverting patches years before this "research" was conducted that almost certainly have had context changes around them, likely introducing more harm than good.
Re: UMN CS&E Statement on Linux Kernel Research
#103Earlier quoted context omitted.
red teaming without approval of the target org is out of fashion, yes.
that helps a bit with regards to understanding why people are so upset about this. but honestly, it seems like valuable research to me. it's unfortunate that it took some time away from busy kernel developers, and it's unfortunate that it ultimately makes the project look worse... ...but isn't that supposed to be part of the promise behind open source? it wouldn't surprise me if i learned that management of private o…
The deception / con job was done last year. This time around, there was another series of patches from the same research group, which were claiming to be security fixes, but which scored really high on the you-have-got-to-be-kidding-me scale of incompetence. When the Grad Student was called out on it, he claimed it was due to a static code analyzer which he was testing.
This was not disclosed up front, and at this point, it is impossible to tell whether he was creating an incompetent, no-where-near-state-of-the-art code analyzer which gave bogus results, and then was too incompetent to realize it was bogus, and instead submitted the patches to kernel developers asking us to be his QA, without disclosing that this was what he was done ---- or this could be another human experimentation where they are trying to see how gullible the patch review process is at accepting bogus patches.
We have no idea, because his research group has previously submitted patches in bad faith, and UMN's IRB board gave it the A-OK ethics review. At this point, the safe thing to do is to assume that it was also submitted in bad faith.
Re: UMN CS&E Statement on Linux Kernel Research
#104Interesting, 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.... . 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 allo…
Yeah 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.
Re: UMN CS&E Statement on Linux Kernel Research
#105I don't know why, but somehow I am not too bothered by the research itself. Sure, in retrospect, it does not sounds like it was the right thing to do (or the right way to do). But, you know, stuff happens.
Instead, what bothered me immensely is the way the PhD student handled that interaction: immediately claiming "bias", "slander", playing "victim", etc... I don't know if he learned such a way to communicate from his professors, other students at the CS&E department, or UMN environment in general, but it's very bothersome to me. Such way to communicate precludes constructive (and perhaps heated) exchange of ideas. I think people like that should be nowhere near important CS/EE projects.
Re: UMN CS&E Statement on Linux Kernel Research
#106This is a great statement, they confirm they're aware of the issue, they acknowledge the concerns and they set out their intention to gather the full facts whilst suspending the operation of the research in the meantime. They also acknowledge the systematic way the need to deal with this. I hope their follow up is as thorough but I want to applaud this, it's a good approach.
It is a good statement, and I believe they'll follow through, but it's missing something important that is often missing from otherwise professional communication. The last line is "We will report our findings back to the community as soon as practical." It should be followed by "and we will provide an update in no more than 30 days". Without any explicit time frame, holding them publicly accountable becomes trickier…
> At any point they can just say "we're still investigating" until enough time has passed people aren't paying attention any more.
They need to act to get the ban rescinded, they can't just ignore this issue away.
Re: UMN CS&E Statement on Linux Kernel Research
#107Being unaware of whatever this is, until this HN post just now, I'm still in the dark as exactly what was being done which was apparently unethical since the statement doesn't mention any details. Anyone have any details on what the issue is?
It appears that the U of MN researchers experimented on Linux kernel developers without those developers' consent. The researchers didn't even go through their Institutional Review Board (IRB) until the experiment was done, which is not allowed. When they finished the experiment they then got approval from their IRB, and the IRB approved it even though the people being experimented on had not consented.
There are all sorts of rules when doing an experiment on humans in the US, and they generally require consent.
To be clear: I do not know all the facts in this case, and I'm not a lawyer. But I'm glad that GregKH took the "immediate ban" step, that seemed like the safest course of action with the info he had. I think experiments to see "what can slip through review" could be really valuable & important, but when humans are being experimented on, you normally need their consent first.
Re: UMN CS&E Statement on Linux Kernel Research
#108This is a great statement, they confirm they're aware of the issue, they acknowledge the concerns and they set out their intention to gather the full facts whilst suspending the operation of the research in the meantime. They also acknowledge the systematic way the need to deal with this. I hope their follow up is as thorough but I want to applaud this, it's a good approach.
It is a good statement, and I believe they'll follow through, but it's missing something important that is often missing from otherwise professional communication. The last line is "We will report our findings back to the community as soon as practical." It should be followed by "and we will provide an update in no more than 30 days". Without any explicit time frame, holding them publicly accountable becomes trickier…
This sort of incident is difficult to set expectations for reporting back.
I expect UMN to move swiftly on this but it’s a large university and may move more slowly than we’d like.
Re: UMN CS&E Statement on Linux Kernel Research
#109background for those unfamiliar with this: https://news.itsfoss.com/hypocrite-commits/ and Kangjie Lu's response: https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc....
The sheer entitlement of this: > 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. Here’s a better solution: don’t do it. You do not have a d…
I blew up at someone in the different thread and got roasted... but I don't understand why you couldn't talk to the team reviewing the patches...
Seriously, tell them "we're going to send 10 patches for security review, don't merge any of them, tell us if it's good or not"
Re: UMN CS&E Statement on Linux Kernel Research
#110Earlier quoted context omitted.
Ah thanks. How moronic, whomever thought this was in any way a good idea is pretty out of touch with reality.
isn't it just a form of red teaming? has red teaming fallen out of fashion?
It's not just "out of fashion". Red teaming, without consent of the owners of the system being analyzed, is typically illegal.
You generally must have consent from the people being experimented on within the US.