Hacker News Reader

Comment by jrootabega | Hacker News Reader

I clearly don't think what the administration did here is good. But I don't exactly align with the students, either. Thought experiment: let's go back to the days when we always had hardwired desktop computers at every desk. Their locations and network addresses are known. Usage is logged locally and centrally, e.g. in Active Directory. Would logging require IRB approval? Once the logs were collected, would running a report on the logs to show how much usage each workstation was getting, and by whom, require IRB approval? It doesn't really seem like a science experiment to me, just logistics. (And I think the "we're not doing science here" issue was not understood or handled in good faith by the students. Technically, any time someone says "Hmm, I wonder...let me check something...aha!" is science.) But I also acknowledge that there are situations where you would need to err on the side of treating it like an experiment even if there is doubt.

View on HN

The rules (laws, really) on this are actually pretty clear.

You can collect a lot of data for internal “operational”. A hospital could track surgical infections to see if an Operating Room needs decontamination or someone needs retraining. Likewise, the AD logs are fair game for sysadmin or admin purposes.

However, you need IRB approval for “research activities” that are meant to draw generalizable conclusions that extend beyond the immediate situation. How do cleaning schedules, in general, affect surgical outcomes? Do more logins lead to better student outcomes? The IRB can retroactively authorize you to look at operational data for that, or to collect new data, or even add in (some) perturbations.

Hmm... I'm still confused but that could be me. I would put the desk monitoring under the former category.

Is this a decent example?

Operational: We analyzed the performance logs on Tony's computer to show that he didn't use his CPU that much and thus could be given a cheaper model.

Research: we used those same logs, and everybody else's, to show that most people use about 25% of their CPU capacity.

It’s definitely not a bright line, which is why you’re supposed to talk to the IRB.

In your example, I think it depends on the audience and goal. If you’re using these data to plan a computer lab upgrade, it seems very clearly operational. If you wanted to publish a study entitled “Factors affecting IT utilization at an R1 university”, you probably need to run it by the IRB. In that case, they will almost certainly give you the go-ahead after reminding you not to include any identifiable information.

I assume IRB approval would not be needed if the school was just using computer logs to verify that school policy is being followed.

Regarding the "we are not doing science here"... there is a lot of ambiguity with the use of the word "we" which students may have been instinctively reacting to. "We" is generally an inclusive term, and the students probably felt insulted that the administrator was dragging them into the mess by suggesting the students were part of the process, when they were not. However the students may have misunderstood the intentions in the administrator's use of "we" and maybe he was referring to an entirely different group of people.

If I were a student or parent of one of the students I'd start making some calls to find out if any approvals were made for the under desk surveillance of students. Although from a liability perspective the onus is on any of the faculty at the school that fail to report a whiff of a Title IX violation.

One difference is intent. The computer logging was somewhat incidental (but not entirely benign, so we shouldn't give it a pass without thinking), while the heat sensors are there very deliberately.

The other difference is territoriality. The students very acutely (and accurately) perceived the sensors as intruders in their space. This may be a crude animal instinct, but it's there for a reason. Permit one intrusion, and more will follow.

Reply on news.ycombinator.com