Hacker News Reader

It sends a strong message - universities need to make sure their researchers apply ethics standards to any research done on software communities. You can't ignore ethics guidelines like consent and harm just because it's a software community instead of a meatspace community. I doubt the university would have taken any action at all without such a response.

>It sends a strong message

At a cost to mostly people who didn't / and I'll even say wouldn't do the bad thing.

I understand the point that you are making, but you have to look at it from the optics of the maintainer. The email made it clear that they submitted an official complaint to the ethics board and they didn't do anything. In that spirit it effectively means that any patch coming from that university could be vulnerability injection misrepresented as legitimate patches.

The Linux kernel has limited resources and if one university lack of oversight is causing the whole process to be stretched tinner than it already is then a ban seems like a valid solution.

In this case, the cost is justified. The potential cost of kernel vulnerabilities is extremely high, and in some cases cause irrecoverable harm.

If that cost is high, why are they accepting and rejecting code based on email addresses?

https://twitter.com/FiloSottile/status/1384883910039986179

(Clearly the academic behavior is also a problem, there's no good justification for asking for reviews of known bad patches)

@denvercoder9 had a good comment that might assuage your concern:

> It's not a ban on people, it's a ban on the institution that has demonstrated they can't be trusted to act in good faith. If people affilated with the UMN want to contribute to the Linux kernel, they can still do that on a personal title. They just can't do it as part of UMN research, but given that UMN has demonstrated they don't have safeguards to prevent bad faith research, that seems reasonable.

Has the university taken action yet? All I heard was after blowback, UMN had their institutional review board retroactively review the paper. They investigated themselves and found no wrongdoing. (IRB concluded this was not human research)

UMN hasn't admitted to any wrongdoing. The professor wasn't punished in any form whatsoever. And they adamantly state that their research review processes are solid and worked in this case.

An indefinite ban is 100% warranted until such a time that UMN can demonstrate that their university sponsored research is trustworthy and doesn't act in bad faith.

> I don't like this university ban approach.

I do, because the university needs to dismiss everyone involved, sever their connections with the institution, and then have a person in a senior position email the kernel maintainers with news that such has taken place. At which time the ban can be publicly lifted.

I think the ban hits the right institution, but I'd reason the other way around: is it really the primary fault of the individual (arguably somewhat immature, considering the tone of the email) PhD Student? The problem in academia is not "bad apples", but problematic organizational culture and misaligned incentives.

To me it depends on whether they lied to the ethics board or not. If they truly framed their research as "sending emails" then the individual is 100% at fault. If they clearly defined what they were trying to do and no one raised an issue then it is absolutely the university's fault.

I think it's more than whether they lied, it's whether the ethics board is even plausibly equipped to fully understand the ramifications of what they proposed to do: https://news.ycombinator.com/item?id=26890490

Well if the ethics board is not decently equipped to understand the concerns with this type of research I would say a full ban is perfectly understandable.

> The people banned didn't do anything wrong.

There are ways to do research like this (involve top-level maintainers, prevent patches going further upstream etc.), just sending in buggy code on purpose, then lying about where it came from, is not the way. It very much is wrong in my opinion. And like some other people pointed out, it could quite possibly be a criminal offense in several jurisdictions.

>There are ways to do research like this (involve top-level maintainers, prevent patches going further upstream etc.)

This is what I can't grok. Why would you not contact GKH and work together to put a process in place to do this in an ethical and safe manner? If nothing else, it is just basic courtesy.

There is perhaps some merit to better understanding and avoiding the introduction of security flaws but this was not the way to do it. Boggles the mind that this group felt that this was appropriate behavior. Disappointing.

As far as banning the University, that is precisely the right action. This will force the institution to respond. UMN will have to make changes to address the issue and then the ban can be lifted. It is really the only effective response the maintainers have available to them.

It's not a ban on people, it's a ban on the institution that has demonstrated they can't be trusted to act in good faith.

If people affilated with the UMN want to contribute to the Linux kernel, they can still do that on a personal title. They just can't do it as part of UMN research, but given that UMN has demonstrated they don't have safeguards to prevent bad faith research, that seems reasonable.

I am writing this as someone who is very much "career academic". I am all on board with banning the whole university (and reconsidering the ban once the university shows they have some ethics guidelines in place). This research work should not have passed ethics review. On the other hand, it sounds preposterous that we even would need formal ethics review for CS research... But this "research" really embodies the whole "this is why we can not have nice things" attitude.

A university-wide ban helps in converting the issue into an internal issue of that university. The university officials will have to figure out what went wrong and rectify.

Probably not because nobody else at the university is affected, and probably won't be for a dozen more years when someone else happens to get interested in something. Even in CS there are a ton of legitimate projects to work on, so a ban on just one common one isn't going to be noticed without more attention.

Note that I suspect enough people have gotten notice by the press now.

> None of those people did anything wrong. Putting the onus on them to effect change to me seems unfair. The people banned didn't do anything wrong.

Some of the people banned didn't do anything wrong. Others tried to intentionally introduce bugs into the kernel. Their ethics board allowed that or was mislead by them. Obviously they are having serious issues with ethics and processes.

I'm sure the ban can be reversed if they can plausibly claim they've changed. Since this was apparently already their second chance and they've been reported to the university before and the university apparently decided not to act on that complaint ... I have some doubts that "we've totally changed. This time we mean it" will fly.

"Some"

How many people didn't and did? The numbers seem absurd.

No way to tell. How many people at UMN do usually submit kernel patches that aren't malicious? In any case, it did hit the right people, and it potentially causes collateral damage.

Since it's an institutional issue (otherwise it would've stopped after they were reported the first time), it doesn't seem wrong to also deal with the institution.

I understand where this is coming from, and empathize with this but also empathize with the Kernel.org folx here. I think I'm okay with this because it isn't some government actor.

It is not always easy to identify who works for who at a university in regards to someone's research. The faculty member who seems to be directing this is identifiable, obviously. But it is not so easy to identify anyone acting on his behalf - universities don't maintain public lists of grad or undergrad students working for an individual faculty member. Ad in that there seems to be a pattern of obfuscating these patches through different submission accounts specifically to hide the role of the faculty advisor (my interpretation of what I'm reading).

Putting the onus on others is unfair...but from the perspective of Kernel.org, they do not know who from the population is bad actors and who isn't. The goal isn't to penalize the good folks, the goal is to prevent continued bad behavior under someone elses name. Its more akin to flagging email from a certain server as spam. The goal of the policy isn't to get people to effect change, its to stop a pattern of introducing security holes in critical software.

It is perfectly possible that this was IRB approved, but that doesn't necessarily mean the IRB really understood the implications. There are specific processes for research involving deception and getting IRB approval for deception. but there is no guarantee that IRB members have the knowledge or experience with CS or Open Source communities to understand what is happening. The backgrounds of IRB members vary enormously...

The University of Minnesota IRB never should have approved this research. So this is an institutional level problem. This is not just a problem with some researchers.

It's unfortunate that many people will get caught up in this ban that had nothing to do with it, but the university deserves to take a credibility hit here. The ball is now in their court. They need to either make things right or suffer the ban for all of their staff and students.

Agree that universities don't (and shouldn't) act with a single purpose or intent, but they need to have institutional controls in place that prevent really bad ideas from negatively affecting the surrounding community. Those seem to be lacking in this case, and in their absence I think the kernel maintainers' actions are entirely justified.

I don't like it either but it's not as bad as it sounds: the ban almost certainly isn't enforced mindlessly and with no recourse for the affected.

I'm pretty sure that if someone from the University of Minnesota would like to contribute something of value to the Linux kernel, dropping a mail to GregKH will result in that being possible.

It's definitely killing a mosquito with a nuke, but what are the alternatives? The kernel maintainers claim these bogus commits already put too much load on their time. I understand they banned the whole university out of frustration and also because they simply don't have the time to deal with them in a more nuanced way.

Are they even killing a mosquito?

Someone wants to introduce bugs, they can.

Meanwhile lots of people banned for some other person's actions.

Nobody else that the UMN is even contributing patches, other than these bad faith ones, so this is only banning one set of bugs. Given that a lot of bugs have come from one source banning that source bans a lot of bugs. It doesn't stop them all, but it stops some.

There's a real cost. What's your estimate for going through each of these 190 patches individually, looking at the context of the code change, and whether the "ref counting or whatever" bug fix is real, and doing some real testing to ensure that?

https://lore.kernel.org/lkml/20210421130105.1226686-1-gregkh...

That looks like quite some significant effort. Now if most of those fixes were real, now after the revert there will be 190 known bugs in the kernel, before it's all cleaned up. That may have some cost too.

Looks like a large and expensive mess someone other than that UNI will have to clean out, because they're not trustworthy, ATM.