51–60 of 74 posts
Earlier quoted context omitted.
That person died in a car accident and they were wearing a seatbelt! Why would anyone wear a seatbelt? They are clearly useless.
If a lot of money is involved, it's only a matter of time before all oversight is corrupt. Similarly, you can safely assume all data that is on an important (big money) topic is fake.
Earlier quoted context omitted.
You know there's a lot of he-said she-said here. The truth is that I was repeating there what they claimed in the paper which is that they intervened prior to merge to mainline.
My point was that (the article claims that) they didn't "reveal that the patches are malicious" at that point. Revert yes, reveal no.
Earlier quoted context omitted.
1) once hypocrite commits were accepted, the authors would immediately retract them 2) I don't think it's unethical to send someone an email that has bad code in it. You shouldn't need an IRB to send emails.
> I don't think it's unethical to send someone an email that has bad code in it. It's unethical because of the bits you left out: sending code you know is bad, and doing so under false pretenses. Whether or not you think this rises to the level of requiring IRB approval, surely you must be able to understand that wasting people's time like this is going to be viewed negatively by almost anyone. Some people might be w…
The stupid thing about the experiment was that it's never been a secret that the kernel is vulnerable to malicious patches. The kernel community understood this long before these academics wasted kernel maintainer time with a silly experiment.
Woah, the thing that leapt out at me, as a professor, is that they somehow got an exemption from the UMN institutional review board. Uh, how?? It's clearly human subjects research under the conventional federal definition[1] and obviously posed a meaningful risk of harm, in addition to being conducted deceptively. Someone has to have massively been asleep at the wheel at that IRB. [1] https://grants.nih.gov/policy-an…
I've also had to deal with the IRB a lot as a professor. The retroactive application is extremely weird (although maybe better than nothing?). This seems like one of those situations that would usually require regular review to err on the side of caution if nothing else. It's worth pointing out there are exceptions though: https://grants.nih.gov/sites/default/files/exempt-human-subj... Generally those exceptions fall…
Did they ever get un-banned ? IIRC, that Univ has/had great Computer Science Dept. But there is always the BSDs.
Woah, the thing that leapt out at me, as a professor, is that they somehow got an exemption from the UMN institutional review board. Uh, how?? It's clearly human subjects research under the conventional federal definition[1] and obviously posed a meaningful risk of harm, in addition to being conducted deceptively. Someone has to have massively been asleep at the wheel at that IRB. [1] https://grants.nih.gov/policy-an…
There are cases where deception (as they call it) can be approved (even by ethics boards). Based on the Verge's article, this research setup should not have been approved even by then. But the topic itself seems as relevant as ever with the xz case and all.
Earlier quoted context omitted.
Oh I misunderstood the sections in the article about the umn.edu email stuff. My mistake. The actual course of events: 1. Prof and students make fake identities 2. They submit these secret vulns to Greg KH and friends 3. Some of these patches are accepted 4. They intervene at this point and reveal that the patches are malicious 5. The patches are then not merged 6. This news comes out and Greg KH applies big negative…
>No one likes being cheated out of work that they did, especially when a lot of it is volunteer work. You know what would really be wasteful of volunteer hours? Instituting a policy whereby the community has to trawl through 20 years of commits from umn.edu addresses and manually review them for vulnerabilities even though you have no reasonable expectation that such commits are likely to contain malicious code and y…
Imo, the experiment was worthwhile, it exposed a risk, hopefully the kernel is better armed against similar attacks now.
They retaliated against the entire university. I don't think they learned anything.
That says a lot about Linux kernel safety.