[HN Gopher] UMN CS&E Statement on Linux Kernel Research
___________________________________________________________________
UMN CS&E Statement on Linux Kernel Research
Author : fhars
Score : 410 points
Date : 2021-04-21 21:12 UTC (1 hours ago)
(HTM) web link (cse.umn.edu)
(TXT) w3m dump (cse.umn.edu)
| motohagiography wrote:
| The other reason this is a hotbutton issue is because it is
| related to the general problem of abusing the universities as a
| protected platform for general subversion for its own sake.
|
| It's not innovation or research, or even progress, it's actively
| destabilizing and subverting a targetted community that a huge
| part (even majority) of the economy depends on the integrity of.
| This is a hawkish view, but in a challenging cultural moment,
| their activities are very difficult to be charitable about.
| Animats wrote:
| This 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...
| evgen wrote:
| So far it has only been 'insiders' (FOSS-aware/friendly press
| and trade press a bit closer to the dev side than the
| management side) but the real question will be if it hits any
| large mainstream news sites by tomorrow. If it does not land
| until Friday then the story is over in terms of real
| consequences, but the PR team at UMN is probably hoping that
| fast damage control now can push anything major out a day or
| two where it disappear into the weekend trash.
| thatguy0900 wrote:
| Your tech department being blackballed from submitting Linux
| patches is a pretty embarrassing consequence. What else would
| happen? It's not like anyone will fine them.
| dporter wrote:
| Loss of grant money
| thatguy0900 wrote:
| Oh, true
| alpb wrote:
| How is DHS Cybersecurity related to this?
| ghughes wrote:
| Ethics of the research aside, I'm surprised how easy it is to
| sneak code that nobody understands the purpose of into the Linux
| kernel.
| detaro wrote:
| I found these statements by the associate department head
| interesting:
| https://twitter.com/lorenterveen/status/1384955467051454466
|
| > _I do work in Social Computing, and this situation is directly
| analogous to a number of incidents on Wikipedia quite awhile ago
| that led to that community and researchers reaching an
| understanding on research methods that are and are not
| acceptable._
|
| and https://twitter.com/lorenterveen/status/1384966202301337603
|
| > _Yes! This was an IRB 'failure'. Again, in my area of Social
| Computing, it's been clear for awhile that IRBs often do not
| understand the issues and the potential risks/harms of doing
| research in online communities / social media._
|
| An interesting question is IMHO who people actually tried to
| contact in the first round of this getting publicity (and I guess
| how many did so at all), and if leadership should thus have been
| aware earlier that there was controversy worth looking into.
| CaffeineSqurr wrote:
| Terveen was always honest about what works and what doesn't
| work. Its good to see them acknowledge that this is something
| they need to dive into and fix.
| fhars wrote:
| That whole twitter thread is really interesting, starting from
| https://twitter.com/lorenterveen/status/1384954220705722369
| detaro wrote:
| Yes Twitter is "weird" about with sub-thread it picks as the
| "main" one (well, it choses one and didn't pick the
| interesting one here), so I had to explicitly link the latter
| point.
| debaserab2 wrote:
| Yeah, it gets even worse:
|
| https://twitter.com/SarahJamieLewis/status/13848713855379087.
| ..
| zenir wrote:
| Basically now they can do a meta study on how the review
| process of IRB has flaws. As shown, if you intentionally try to
| bypass the IRB, apparently you can. It's even reproducible.
| finnthehuman wrote:
| >it's been clear for awhile that IRBs often do not understand
| the issues and the potential risks/harms of doing research in
| online communities / social media.
|
| Too bad he's not in a position of power to implement that
| additional review to CS department research.
| metanonsense wrote:
| To me reverting those hundreds of patches sounds like an
| overreaction, which might cause actual damage. It's not clear (at
| least from what I have read in the thread) that this code, which
| may be wrong or at least useless, is part of any "let's check
| their patch process" experiment (or did I just miss that?)
|
| That they did that in the past is clearly unethical and was
| generally a shitty thing to do, but this group also seems to do
| technical security research. That the student (allegedly) trusted
| his static code analyzer so much that he did not care to verify
| if its findings doesn't speak for him, but Hanlon's razor may
| also apply here. Just banning that student (if he keeps
| submitting technically inferior patches) should be enough imho.
| lmeyerov wrote:
| 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.... .
|
| 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 wrote:
| > 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
| UncleMeat wrote:
| 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.
| ShamblingMound wrote:
| 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.
| RayVR wrote:
| The heads of departments are political animals.
|
| This is purely a damage mitigation strategy. If we give them more
| credit than they really deserve, the department and IRB were
| severely negligent.
| gumby wrote:
| This kind of research is interesting and important but should not
| be done by a computer science department, any more than the
| social science department should try to develop a process control
| system.
| spuz wrote:
| Which department should do it?
| gumby wrote:
| Sociology or anthropology. Possibly, though less so,
| political science, economics, or even a B school. These are
| all disciplines that study the social behavior of groups.
|
| As as study of a group activity it seems inapplicable to a
| psychology department, though that could be a bias on my
| part.
| detaro wrote:
| No, computer science departments should be adequately equipped
| and trained to handle this. Lots of areas of computing involve
| humans and need to be studied by people also knowledgeable
| about the technical side. (and "computer science" departments
| usually are not strictly "pure computer science" departments,
| it's just the usual label under which most of computing ends
| up)
| cperciva wrote:
| The title here should probably be "UMN CSE Department
| Statement..." rather than merely "UMN Statement ..." since it's
| coming from the department head and associate department head,
| not from the university as a whole.
|
| cc/ dang
| YetAnotherNick wrote:
| Sorry for getting sidetracked, but does cc has any special
| function here or you are hoping that dang would read all the
| comments and see your cc?
| cperciva wrote:
| I think dang might have something in place which alerts him
| when he is mentioned. Certainly he tends to show up quickly
| when people "page" him like this.
| asveikau wrote:
| I wonder if such a "something" would have false positives
| for phrases such as "dang nabbit". Fortunately that's an
| antiquated usage.
| dredmorbius wrote:
| The recommended mode of reaching HN's moderation team is by
| email at hn@ycombinator.com
|
| Though I suspect periodic searches for recent mentions of
| dang's username in comments are also employed. It's a matter
| of what's most efficient and convenient for the team, and
| what community practices have evolved.
| loeg wrote:
| Title on the webpage is now showing as "Statement from CS&E on
| Linux Kernel research - April 21, 2021" vs HN's "UMN Statement
| on Linux Kernel Research."
| h2odragon wrote:
| "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."
| kapp_in_life wrote:
| Allegedly. Of course the department will want to do their due
| diligence and investigate the accusations.
| infogulch wrote:
| 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.
| janoc wrote:
| That sounds like someone's academic career has just landed in the
| toilet ...
| tolbish wrote:
| I wonder if potential collaborators will come to light, from
| UMN or other universities.
| Fordec wrote:
| Apparently the researchers in question don't have tenure. If
| that is so, RIP to their achedemic careers right now.
| g42gregory wrote:
| I 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.
| dshpala wrote:
| Maybe that was in line with the "research"?
|
| I think this can be an interesting topic in itself, how those
| trigger words and victim playing can get you through code
| reviews faster. It's certainly true in my company...
| g42gregory wrote:
| It looks like Linux kernel has passed the test!
| 1970-01-01 wrote:
| Good start. That was faster than expected.
| ransElectronics wrote:
| The researchers, the researcher's bosses and pretty much every
| person in command at UMN had to sign off on this being an
| acceptable method of conducting research. This shows such an
| extreme lack of good faith or judgement on their part that I do
| not believe UMN could, or should ever be forgiven. Their actions
| show nothing but criminally bad faith taking place, all the way
| up to the top. The only rational response from the Kernel team is
| to revert all code submitted by any member of UMN and to
| permanently blacklist every person who has ever attended UMN or
| worked at UMN for any reason or any length of time.
|
| The only way I could see this getting forgiven is if every party
| that could have cancelled the project is forcibly removed from
| holding any position of employment or enrollment at UMN, going
| all the way up to the head owners and managers of the entire
| university.
| lfc07 wrote:
| I am definitely against the line of research and hope someone
| acknowledges their fault. I also want to appeal that the issue it
| taking a political turn with a lot of unwarranted hate in forums
| and media mostly from people who are not part of kernel
| community. We are talking about young researchers and some
| possibly are misguided or innocent. Lets now make a political
| feast out of this just because we can.
| Will_Do wrote:
| I guess the question I have is "Did any *previous* research done
| by UMN _successfully_ introduce bugs into the Linux Kernel git
| commit log? "
|
| There are weasel words in this statement that make it unclear and
| the researchers have been really dishonest already. But! If it's
| true that their research has never made it out of email chains
| then it does seem like the reaction is a bit disproportionate to
| the damages here.
| finnthehuman wrote:
| Lu has posted to LKML today, weasel wording around when asked
| point blank for a list of everything malicious sent to the
| kernel.
|
| https://lore.kernel.org/lkml/YIBMKSovJumS79SR@pendragon.idea...
|
| e: Not getting pulled into a maintainer tree isn't enough to be
| safe about what was posted to a kernel mailing list. People can
| (and testing scripts blindly do) grab and apply patches on the
| mailing list.
| hannasanarion wrote:
| Much focus is on the 3 patches from the paper last year, but
| others have been submitted before and since by the same group,
| and some that have been found to be malicious did make it into
| the Stable branch:
| https://lore.kernel.org/lkml/78ac6ee8-8e7c-bd4c-a3a7-5a90c7c...
| vzaliva wrote:
| Here is some background for those who are not familiar with the
| rules of academic research in the US. Usually, any experiments
| involving human subjects are subject to Univesity Institutional
| Review Board (IRB) [1] approval. IRB should evaluate both ethical
| and safety concerns. I recall having to jump through quite a few
| hoops just to do a simple touch screen gesture recognition test
| of a dozen willing fellow students. Apparently, the IRB approval
| step was skipped, or IRB failed to do its job in this case.
|
| [1] https://en.wikipedia.org/wiki/Institutional_review_board
| res0nat0r wrote:
| Being 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?
| dwheeler wrote:
| 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.
| babayega2 wrote:
| Doesn't HK summarize it clearly in his answer to the researcher
| https://www.neowin.net/news/linux-bans-university-of-minneso...
| loeg wrote:
| It's still #3 on the front page:
| https://news.ycombinator.com/item?id=26887670 (and other
| iterations on the same story earlier today).
| res0nat0r wrote:
| Ah thanks. How moronic, whomever thought this was in any way
| a good idea is pretty out of touch with reality.
| a-dub wrote:
| isn't it just a form of red teaming? has red teaming fallen
| out of fashion?
| [deleted]
| detaro wrote:
| red teaming without approval of the target org is out of
| fashion, yes.
| a-dub wrote:
| 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 orgs hire security firms to do
| this sort of thing. where does that come from in foss
| land, other than the ethers of others tinkering,
| researching and experimenting?
|
| i think this whole calling for the researchers heads
| business is overblown. i read their paper, it looks like
| they approached the situation quite ethically to me.
| detaro wrote:
| 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 are attempts coming
| and got their approval.
|
| Given that, you need a good justification why that wasn't
| enough for you, and what value you truly added over what
| already was the common view on the issue. But at least we
| got valuable recommendations from their paper, like
| "there should be a code of conduct forbidding malicious
| submissions" and "you could try vetting peoples real
| identities". (I guess they added to the last bit, giving
| additional data points that "works at a respected
| institution in a related field" is not sufficient to
| establish trust)
| a-dub wrote:
| 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...
| a-dub wrote:
| > So you are saying that because a non-controversial
| method to show the same issue wouldn't cause the
| publicity connected purely to their way of operating, it
| was right to ignore the concerns?
|
| what's the non-controversial alternative? alerting the
| organization before they do it? that doesn't work. that's
| why scientists do blinding and double blinding.
|
| if you mean something else, then i'm missing parts of
| this (really complicated) debate.
| detaro wrote:
| So you are saying that because a non-controversial method
| to _show the same issue_ wouldn 't cause the publicity
| connected purely to their way of operating, it was right
| to ignore the concerns?
| tytso wrote:
| 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.
| a-dub wrote:
| i think the discussion should not be around banning them
| as known bad actors, but instead should be around how to
| detect bad actors or better introduce safety and security
| into the project.
|
| i'll tell you one thing, it has shaken my trust in the
| oss kernel development model as it operates today, and
| honestly that seems like maybe a good thing?
|
| how many companies are literally printing money with the
| linux kernel? can't they throw a few bones at helping
| beef up code review and security analysis?
| tytso wrote:
| No development model is protected from malicious actors,
| and this is not unique to OSS. Could the Ministry of
| State Security sponsor a student to study at the US, and
| then after graduate, that student gets a job at
| Microsoft, and then introduces vulnerabilities in
| Windows? In theory all patches should get code reviews,
| but could someone get a bug past code reivew? Sure!
|
| You can try to detect it before it happens, but very
| often you won't catch it until after it's landed in the
| source code repository, and some cases, it'll actually
| make it out to customers before you notice.
|
| It's true for proprietary code; it'st true for open
| source code; it's true for x.509 CA certificates[1]. We
| should still do the best job that we can, if for no other
| reason that there are plenty of zero-days which are
| introduced by human error, never mind by malicious
| actors.
|
| [1] https://www.thesslstore.com/blog/final-warning-last-
| chance-t...
| dwheeler wrote:
| 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.
| thatguy0900 wrote:
| They submitted patches that did nothing but introduce
| vulnerabilities, in a test to see if they would get through.
| They've done this previously for a research paper.
| nomel wrote:
| From my understanding, it wasn't this. It was that they
| didn't come clean or provide a quick emergency stop when they
| saw that the patches would make it through. Although, I'm
| having trouble sifting through the rage/drama.
| iasmseanyoung wrote:
| I 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?
| tytso wrote:
| 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 point assuming bad faith for all UMN
| patches and reviewing them all before allowing them to stay in.
| (Or if they get reverted by default, someone else can manually
| apply them after they go through strict review.)
|
| Fool me once, shame on you, fool me twice....
| kapp_in_life wrote:
| >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
| Denvercoder9 wrote:
| There were more than three buggy commits, at least one of
| which is from this month
| kapp_in_life wrote:
| Which weren't intentionally buggy. https://lore.kernel.or
| g/lkml/YIBMKSovJumS79SR@pendragon.idea...
|
| Best to spend time auditing every commit in the kernel
| for bugs rather than grandstanding over the commits from
| one university's members.
| tedd4u wrote:
| What a mess, that could be hundreds of hours of work ...
| baxter001 wrote:
| background 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....
| Doctor_Fegg wrote:
| 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 divine
| right to carry out this "research" no matter what.
| WrtCdEvrydy wrote:
| 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"
| nickysielicki wrote:
| Now we wait for the IEEE statement.
|
| They _will_ release a statement, right?
| WrtCdEvrydy wrote:
| I sent an email to the chair of the conference asking if this
| was ethically okay...
| jtchang wrote:
| It's not just the linux kernel. You can imagine this having some
| fallout to other open source projects where they all come out and
| say they won't accept contributions from the university. Huge PR
| nightmare.
| 29athrowaway wrote:
| Linux is used for very sensitive stuff. Stuff that involves a lot
| of money.
|
| Messing with Linux is messing with that sensitive stuff, which
| means messing with important people and organizations. That is
| something that is very hard to get away with.
|
| That guy just got himself into a legal supernightmare.
|
| If someone is running a stock exchange on Linux and a guy
| introduces vulnerabilities on purpose, I am sure that person will
| be pretty upset and pursue litigation.
| locacorten wrote:
| I 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.
| aahortwwy wrote:
| > do this
|
| They got caught and had all their contributions reverted.
| ghughes wrote:
| Well-paid, well-equipped, and highly experienced security
| experts act quickly and usually don't get caught.
| prepend wrote:
| He didn't succeed in injecting anything, right?
|
| It would be interesting if someone found bad stuff in the
| kernel, but pet of the org structure makes this hard.
| ghughes wrote:
| He landed code that nobody seems to understand the purpose
| of. That looks like success to me.
| Traster wrote:
| This 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.
| mewse-hn wrote:
| I also think it's a good response but I think an apology would
| be in order - perhaps left out because it can be considered an
| admission of guilt.
|
| The way their statement stands they can investigate themselves
| and determine they did nothing wrong, we'll have to see what
| they say down the road.
| belval wrote:
| Perhaps I am naive but I think the apology should come after
| the internal investigation.
|
| It is more likely that you just have an administrator that
| became aware of the issue, they won't make an apology until
| they understand what happened.
| kenjackson wrote:
| They could investigate and determine that they did nothing
| wrong, but they aren't the final arbiter of justice. This is
| not like the police investigating themselves. The OSS
| community can come to a different conclusion and still punish
| them.
|
| The job of UMN is to get the facts first, and then determine
| actions. If the OSS community (and others) feel like the
| actions don't match the facts (or if they feel the facts
| don't match what actually happened) they can apply their own
| set of actions.
| IncRnd wrote:
| I doubt an apology would increase liability in this case,
| since the actions already occurred and are forensically
| visible.
| tw04 wrote:
| >but I think an apology would be in order - perhaps left out
| because it can be considered an admission of guilt.
|
| I think an apology before they've had a chance to review
| everything that occurred would be rather empty, don't you?
| "I'm sorry you're upset"?
|
| I far prefer what they've stated they're going to do which is
| stop the activity they know about immediately, and to review
| how we got to this point.
|
| If, on the off chance, the professor was being honest about
| ensuring they weren't wasting anyone's time, and ensuring no
| bad code made it into the kernel, then the situation becomes
| a bit more murky. They'd need to go through all of the
| associated emails both public and internal to validate that.
|
| If on the other hand this is in fact a duck, I would expect
| them to both to issue a meaningful apology at that point, as
| well as lay out the steps they've taken to ensure it doesn't
| happen again (which they've indicated is their plan). And
| hopefully restore the trust of the OSS community.
| winphone1974 wrote:
| Maybe it's because I'm both Canadian and a tech manager but
| I've never worried about over apologizing if it's genuine.
| Same goes for saying thank you.
| colechristensen wrote:
| Apologies are overrated. Are these leaders actually sorry for
| something they likely weren't aware of before today?
| Doubtful. Who are they apologizing to? The public?
|
| When the issue has gotten actual attention an apology to the
| kernel mailing list might be appropriate, but as someone who
| has been apologized to many times it all just becomes
| meaningless, who cares if you say you're sorry. I care what
| you'll do about it.
| agf wrote:
| 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.
|
| Note that the companies that do ongoing incident updates on
| status sites best all do this -- "We will provide an update by
| 10:30pm PST".
| boomboomsubban wrote:
| > 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.
| ellisv wrote:
| 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.
| agf wrote:
| That's why you promise an update, not a resolution.
| mort96 wrote:
| Kind of like how Mozilla will open-source Pocket any day now,
| just like they promised in 2017...
| Quekid5 wrote:
| What on earth has that got to with any of this?
| mort96 wrote:
| It's an example of an organization making a promise to
| take action to respond to feedback from the community,
| not providing a time frame, and then just never doing it.
| IncRnd wrote:
| There was one thing that I found to be lacking from their
| statement. They never said that what they had done was wrong.
| The university already knows what the researchers did and are
| aware of the paper that was written about the subject by those
| same researchers. [1]
|
| [1] On the Feasibility of Stealthily Introducing
| Vulnerabilities in Open-Source Software via Hypocrite Commits
| --
| https://github.com/QiushiWu/QiushiWu.github.io/blob/main/pap...
| xibalba wrote:
| This is what innocent until proven guilty looks like. I, for
| one, agree with the approach. I don't want to live in a world
| where people are fired and projects shutdown on the basis of
| allegations alone.
| IncRnd wrote:
| Don't jump to conclusions, and say I am guilty of something
| that I didn't write. I never said to fire people and
| shutdown projects based upon allegations alone. You may not
| have read the article for this comment page, but they admit
| that the action took place. The researchers, themselves,
| elsewhere admitted it took place.
| xibalba wrote:
| Pardon me. I did not mean to imply you were calling for
| anything. And I agree, the facts look pretty damning.
| Nevertheless, I fully support a slow, deliberate, and
| comprehensive evaluation by any authority when evaluating
| serious accusations. Further, I strongly believe in
| presumptive innocence, regardless of initial impressions.
|
| Btw, I'm not suggesting you _don 't_ believe in any of
| the above.
| [deleted]
| MattGaiser wrote:
| I would argue that first requires investigation.
|
| They probably just have a bunch of angry emails to go on at
| this point and haven't looked in detail at anything else.
| IncRnd wrote:
| > I would argue that first requires investigation.
|
| Why do you think that enough of an investigation hasn't
| been performed in order to understand culpability?
|
| Thay already know what happened and want to learn why it
| was approved. That was what their comment said.
|
| _Take a look at the actual PDF from the researchers_ , "On
| the Feasibility of Stealthily Introducing Vulnerabilities
| in Open-Source Software via Hypocrite Commits" [1]
|
| [1] https://github.com/QiushiWu/QiushiWu.github.io/blob/mai
| n/pap...
| alexeldeib wrote:
| The prof overseeing the paper clarified that they
| initially did not seek IRB approval, and then received an
| IRB exemption [0]. I'd want to ask the IRB why they
| approved that, for starters. Maybe because they'd already
| done the research and hoped it would blow over, vs. the
| controversy of rejecting it when they'd already done the
| work?
|
| 0: https://www-
| users.cs.umn.edu/~kjlu/papers/clarifications-hc....
| zxspectrum1982 wrote:
| From my reading of the threads in the kernel mailing
| lists, it seems the IRB thought "is it bioscience with
| experimentation on live animals? No? Then it's all fine".
| ellisv wrote:
| I participated in IRB for a UMN campus and that's pretty
| much how these things worked back then.
| seoaeu wrote:
| Yeah, especially considering that the IRB said the
| research was out of scope (specifically that it was not
| "human subject research") rather than indicating that it
| was ethical. Kind of like the distinction between a court
| not having jurisdiction and a court declaring you didn't
| break any laws.
| IncRnd wrote:
| Yes, but that doesn't have bearing on my comment that was
| being referenced, that they didn't say what had happened
| was wrong.
|
| Here is Ken Thompson's apropos paper from 1984. [0]
|
| [0] https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1
| 984_Ref...
| alexeldeib wrote:
| Sure. I was answering your question:
|
| > Why do you think that enough of an investigation hasn't
| been performed in order to understand culpability?
| _rpd wrote:
| I think they misrepresented the project so that it would
| be classified as "not human research". It's unclear
| whether the misrepresentation was intentional (to obtain
| the exemption) or unintentional (they were genuinely
| unaware of the human impact).
| colechristensen wrote:
| Honestly I'm guessing this kind of situation didn't match
| any existing policy for the review board and a few people
| made a bad call.
|
| We need to make sure to be supportive of people making
| mistakes and learning from them instead of raising
| pitchforks for every misstep. Failure is never completely
| avoidable and responding properly to failure is way more
| important than never failing.
| MattGaiser wrote:
| > We will investigate the research method and the process
| by which this research method was approved, determine
| appropriate remedial action, and safeguard against future
| issues, if needed.
|
| The "if needed" tells me they aren't sure what if
| anything is wrong yet. It would surprise me if they have
| done that much of an investigation in the few hours since
| they might have learned about this beyond scheduling
| meetings with involved parties and compiling relevant
| documents in a folder.
|
| I think they are at the point of having a bunch of angry
| emails and a few news articles from certain publications.
| I don't blame them wanting a bit more than that before
| saying anything.
| epage wrote:
| I'm up for "wait and see". From an administrative
| perspective, removed from what is happening, I can see
| investigating first before admitting fault. I'd much rather
| people understanding why they were wrong, even if it takes
| some time.
| hn8788 wrote:
| They shouldn't have. This appears to be a pretty clear cut
| case, but made up outrage-bait has made it to the top of HN
| before. Investigating claims is the correct thing to do.
| bronson wrote:
| It's too early for that. I expect their followup will have
| details on failures but first they need to figure out exactly
| what happened. That will take some time and effort.
|
| At least now they're burning UMN time and not kernel
| maintainer time.
| Isthatablackgsd wrote:
| 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
| "investigation first and comment after" cautiously and
| seriously.
| balozi wrote:
| It's worth remembering that this was a repeat offense. They
| failed to respond to the first complaint.
| detaro wrote:
| 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".
| notyourday wrote:
| They have _just learned_ about the details of the research
| conducted:
|
| > Leadership in the University of Minnesota Department of
| Computer Science & Engineering learned today about the
| details of research being conducted by one of its faculty
| members and graduate students into the security of the Linux
| Kernel.
|
| I'm going to say that the odds are that the faculty member in
| question is not going to be a faculty member anymore
| especially if the ban remains in place as the said faculty
| member probably at best fibbed the leadership before about
| his research.
| seoaeu wrote:
| Firing faculty is oddly difficult, but I do expect they'll
| take at least some actions
| Causality1 wrote:
| I disagree. There's not a single word of apology in it.
| aspaceman wrote:
| They also didn't just throw the group under the bus and try and
| wash their hands clean - good move.
| balozi wrote:
| Academia runs on egos and reputations. You can be sure the
| the fallout is coming.
| Zarathust wrote:
| If they really care about being banned, they'll have no choice
| but to follow thorough
| simlevesque wrote:
| Yeah and that's some heavy shade on a university. They'll
| lose good students if this is not fixed.
| dpwm wrote:
| 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.
| mumblemumble wrote:
| 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 a statement that is short and to the point.
| Which is also appropriate and laudable. Typically when an
| organization says any more, it's to try and do some spin
| doctoring.
| dpwm wrote:
| > 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.
| kbenson wrote:
| > I think it's because the last bit of the first
| paragraph - the ban - flows onto the second paragraph -
| the situation.
|
| So, as long as you ignore the formatting they presented
| it with and decide to read it without it, you can come to
| a different conclusion?
|
| I don't think contortions such as that to link sentences
| is fair, nor the fault of the organization that put forth
| for a statement _specifically separating them_.
| nolok wrote:
| I entirely disagree.
|
| Not once do they talk about getting the ban removed,
| instead they talk about figuring out why it happened and
| how to be better at having research done being ethical.
|
| Was the ban the trigger to them (the heads) looking into it
| ? Of course since they do already have safeguards and
| review processes in place, this happened despite those, so
| they're saying they will investigate them to figure out how
| this project was validated and make sure to strengthen
| these processes as needed.
|
| The end goal they give themselves in that message is not a
| ban removal but "safeguard against future [such] issues".
| dpwm wrote:
| > Not once do they talk about getting the ban removed,
| instead they talk about figuring out why it happened and
| how to be better at having research done being ethical.
|
| I feel as if we're discussing two different statements.
|
| > 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.
|
| Here the cause is that "the research method used raised
| serious concerns in the Linux Kernel community"
|
| Not that it was unethical, or potentially how it was.
| It's not that something clearly went wrong. The cause can
| be read as the response, rather than the action.
|
| > safeguard against future issues, _if needed_
| boomboomsubban wrote:
| The focus is rescinding the ban, but they acknowledge that
| the way to do so is review their actions and set up
| safeguards to prevent similar things from happening.
| There's too much bureaucracy involved for them to already
| publicly review their actions.
| adamrezich wrote:
| basically the response I expected & hoped for. hopefully an
| eventual follow-up statement will detail what their investigation
| finds & what actions they took as a result
| kbumsik wrote:
| For someone who don't know what happened:
|
| "They introduce kernel bugs on purpose"
|
| https://news.ycombinator.com/item?id=26887670
| stabbles wrote:
| It was a good idea to ban the uni entirely, cause that way they
| had to respond.
| earthscienceman wrote:
| 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 clear that the institute cannot be trusted
| until the institute takes decisive restorative action. By
| banning the University, you are saying "we no longer trust you
| in your authority as an institution until it can be made clear
| that this isn't a systemic problem."... you are _not_ saying
| "every single person at the University is terrible" as it was
| framed by some commenters in the other thread.
|
| This is why, in any broad case, it's so upsetting when an
| institution of _any_ variety doesn 't take clear responsibility
| for the behavior and actions of its members or representatives
| (take for example the police, or the federal government). When
| that is true, the behavior of any member of that institution
| should be subject to scrutiny and distrust. It's not a
| complicated social phenomena.
| toss1 wrote:
| Yup, it had to be dealt with on an org level, not only the
| offending person/group.
|
| Although it isn't the medical profession, the same directive
| should apply to research:
|
| "First, do no harm."
|
| This deliberate poisoning of OS projects without prior
| permission to 'test the security' violated that big time.
|
| I'm astonished it got past any ethics review, indicating to
| me that there likely was none.
| kapp_in_life wrote:
| 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.
| zacwest wrote:
| I could easily see sending in a bad patch to see what
| happens and then waiting a few years to write it up;
| there's no realistic way to guarantee when the bad-faith
| contributions started.
| shultays wrote:
| they are re-reviewing the patches and will be accepting
| them back if they look fine, it is not really blindly
| rejecting them all
| readingnews wrote:
| Eh, I work at a uni. This came from a dept head. The university
| is taking it seriously?? Doubt it.
|
| Now, when a Dean puts up a webpage... things just got serious.
| elliekelly wrote:
| I wonder if there's anyone higher up in the administration even
| aware this is happening.
| korethr wrote:
| IMO, the CompSci department would be the one most severely and
| immediately affected. Is it not better that the CompSci dept
| head addresses the issues of their department _before_ the dean
| has to get involved?
| elcomet wrote:
| That was quick. I'm glad they will look into this and I hope we
| don't see this kind of research in the future.
|
| This story reminded me of facebook experimenting on their users
| to control their emotional state (but they said users were
| volunteers because "terms of service"...)
| eganist wrote:
| This is a statement announcing an investigation. Expecting a mea
| culpa right at this time is a bit premature considering they
| still need to figure out where they went wrong.
|
| There's value in setting down the pitchforks.
| [deleted]
| williesleg wrote:
| China.
___________________________________________________________________
(page generated 2021-04-21 23:00 UTC)