That sounds like someone's academic career has just landed in the toilet ...
Apparently the researchers in question don't have tenure. If that is so, RIP to their achedemic careers right now.
UMN CS&E Statement on Linux Kernel Research
121–130 of 332 posts
Re: UMN CS&E Statement on Linux Kernel Research
#122This is starting to snowball. Industry news sites are picking up the story.[1] Hasn't hit the mainstream press yet. No word from DHS Cybersecurity yet. [1] https://www.google.com/search?channel=fs&q=university+of+min...
How is DHS Cybersecurity related to this?
Re: UMN CS&E Statement on Linux Kernel Research
#123"We discovered some folks have been urinating into the campus coffee urns, in order research whether people will object to the flavor. We have told them to stop."
A potent analogy, perhaps it will sway those that don't consider consent an important part of social research.
I expect the department and university to perform a thorough investigation, and respond with decisive action afterwards. Not the other way around.
Re: UMN CS&E Statement on Linux Kernel Research
#124I do some maintenance work for the linux kernel dvb and infrared subsystems. I reviewed and accepted some patches from umn.edu addresses. They looked fine to me, however they're all around error handling, which can get pretty tricky with long error paths. What else can I do than revert the lot?
gregkh sent a 190 patch series to revert all of the "easy" UMN reverts, pending review. People are now looking at the patches and saying things like, "that's one OK, don't revert". There are another 68 commits which did not revert cleanly, in some cases because they were later fixed up, already reverted, or some other patch has touched those lines of code. This will require further manual work. We basically at this p…
>We basically at this point assuming bad faith for all UMN patches
This seems like a gross overreaction to three commits that didn't even make it into mainline. Especially when done for commits years before the "research" was done. But I suppose nobody can miss a chance to let loose a little outrage
Re: UMN CS&E Statement on Linux Kernel Research
#125Earlier quoted context omitted.
I’ve read and re-read that statement, and it seems like the ban is the focus – not what led to the ban. I get that they may not know anything, but there are other ways to word that without admitting liability, making it seem less like the focus is on the ban and more on the allegedly shady stuff.
I'm not sure how you get that. The ban is mentioned as part of a single sentence that acknowledges the current state of the situation, which seems obligatory, so of course it's there. Then the whole second paragraph is talking about how they're shutting down the activity that led to that situation while they work on getting to the bottom of it. This seems like an entirely appropriate balance of text and emphasis for…
> The research method used raised serious concerns in the Linux Kernel community and, as of today, this has resulted in the University being banned from contributing to the Linux Kernel.
> We take this situation extremely seriously.
I think it’s because the last bit of the first paragraph – the ban – flows onto the second paragraph – the situation.
Once you’ve had the two linked, it’s like one of those ambiguous optical illusions, where you just can’t see the other.
If I were writing that statement, I’d be concerned it looked that had there been no ban, there would be no situation. Said statement doesn’t do that for me.
Re: UMN CS&E Statement on Linux Kernel Research
#126Earlier quoted context omitted.
The department heads just learn of what is happening. They cannot say "we didn't do anything wrong!!!" without investigation because it will make the university in a very negative light (it is a serious ramifications). They need to get all the facts and knowing how it happens and who is responsible for this. So this way they can make a concise action and they will make a proper statement. They are taking "investigati…
It's worth remembering that this was a repeat offense. They failed to respond to the first complaint.
It's a bit unclear who complained to whom about this - and I'd expect looking into this to be part of the review. i.e. I could easily see "some people reached out to IRB concerned about lack of its involvement, IRB talked to researcher and went through process, came to result for whatever reasons" happening and not being something that is reported up the chain, because it was "resolved".
Re: UMN CS&E Statement on Linux Kernel Research
#127I think everybody is missing the point. If one grad student was able to do this, imagine what a team of dozens of well-paid, well-equipped, and highly experienced security experts could do.
In other news, we just learned that any half-decent security agency has already injected their own vulnerabilities and back-doors in OSS.
Re: UMN CS&E Statement on Linux Kernel Research
#128Earlier quoted context omitted.
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…
If you wanted to know if the kernel review process is able to reliably catch malicious attempts you literally could have just asked the kernel maintainers and they'd told you that no, review can't go that deep. Or looked at non-malicious bugs and observed that no, review does not catch all bugs with security implications. You'd very likely would have been able to get code past them even if you told them that there ar…
the project is 30 something odd years old now, and is no longer a hobby, it is now critical infrastructure that powers virtually everything.
it's unfortunate that something happened in the project that cost the maintainers a lot of hours, that comes with the territory of working on important software, i'd argue.
i don't want an espionagetastic fundamentally untrustable and inescapable computing hellscape, airplanes falling out of the sky, cars crashing or appliances catching fire because it "already was the common view on the issue."
if the paper raises awareness of the issue, it's a good thing for society, it seems. if money materializes to do background checks on kernel contributors, that seems a good thing, no? if resources materialize for additional scrutiny, that seems a good thing, no?
if anything, the "common view" / status quo seems terribly broken, as demonstrated by their research. while what they've done is unpopular, it seems to me that ultimately the project, and the society of which large chunks it now powers, may be better of for it in the long run...
Re: UMN CS&E Statement on Linux Kernel Research
#129This 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…
Kind of like how Mozilla will open-source Pocket any day now, just like they promised in 2017...
Re: UMN CS&E Statement on Linux Kernel Research
#130Interesting, 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…
Oh 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.