91–100 of 1001 posts
I don't quite understand the outrage. Quite sure most HN readers were doing/involved in similar experiments one way or another. Isn't A/B testing an experiment on consumers (people) without their consent?
The project is interesting, but how can they be so dumb as to post these patches under an @umn.edu address instead of using a new pseudonymous identity for each patch?!? I mean, sneakily introducing vulnerabilities obviously only works if you don't start your messages by announcing you are one of the guys known to be trying to do so...
Someone does voluntary work and people think that gives them some ethical privilege to be asked before someone puts their work to the test? Sure it would be nice to ask but at the same time it renders the testing useless. They wanted to see how the review goes if they aren't aware that someone is testing them. You cant do this with consent. The wasting time argument is nonsense too its not like they did this thousand…
Yes. Someone sees the work provided to the community for free and thinks that gives them some ethical privilege to put that work to the test?
I guess someone had to do this unethical experiment, but otoh, what is the value here? There's a high chance someone would later find these "intentional bugs" , it's how open source works anyway. They just proved that OSS is not military-grade , but nobody thought so anyway
> but nobody thought so anyway A lot of people claim that there's a lot of eyes on the code and thus introducing vulnerabilities is unlikely. This research clearly has bruised some egos bad.
Later down thread from Greg K-H: > Because of this, I will now have to ban all future contributions from your University. Understandable from gkh, but I feel sorry for any unrelated research happening at University of Minnesota. EDIT: Searching through the source code[1] reveals contributions to the kernel from umn.edu emails in the form of an AppleTalk driver and support for the kernel on PowerPC architectures. In t…
seems extreme. one unethical researcher blocks work for others just because they happen to work at the same employer? they might not even know the author of the paper...
Someone does voluntary work and people think that gives them some ethical privilege to be asked before someone puts their work to the test? Sure it would be nice to ask but at the same time it renders the testing useless. They wanted to see how the review goes if they aren't aware that someone is testing them. You cant do this with consent. The wasting time argument is nonsense too its not like they did this thousand…
> Someone does voluntary work and people think that gives them some ethical privilege to be asked before someone puts their work to the test? Yes. Someone sees the work provided to the community for free and thinks that gives them some ethical privilege to put that work to the test?
I don't quite understand the outrage. Quite sure most HN readers were doing/involved in similar experiments one way or another. Isn't A/B testing an experiment on consumers (people) without their consent?
There is a sea of difference between A/B testing your own property, and maliciously introducing a bug on a critical piece of software that's running on billions of devices.
"We did not introduce or intend to introduce any bug or vulnerability in the Linux kernel. All the bug-introducing patches stayed only in the email exchanges, without being adopted or merged into any Linux branch, which was explicitly confirmed by maintainers. Therefore, the bug-introducing patches in the email did not even become a Git commit in any Linux branch. None of the Linux users would be affected."
Researcher(s) shows that it's relatively not hard to introduce bugs in kernel HN: let's hate researcher(s) instead of process Wow. Assume good faith, I guess?
One is that what the researchers did is beyond reckless. Some of the bugs they've introduced could be affecting real world critical systems.
The other issue is that the research is actually good in proving by practical means that pretty much anyone can introduce vulnerabilities into software as important and sensitive as the Linux kernel. This hurts the industry confidence that we can have secure systems even more than it already is.
While some praise may be appropriate for the latter, they absolutely deserve the heat they're getting for the former. There may be many better ways to prove a point.