Forum archive 2000-2006

William Wheeler - FERPA and "Restricting Information ...."

William Wheeler - FERPA and "Restricting Information ...."

by Arnold Pizer -
Number of replies: 0
inactiveTopicFERPA and "Restricting Information ...." topic started 1/24/2001; 10:18:56 PM
last post 1/25/2001; 3:59:30 PM
userWilliam Wheeler - FERPA and "Restricting Information ...."  blueArrow
1/24/2001; 10:18:56 PM (reads: 1051, responses: 2)
The issue that David raised about the use of Social Security numbers in WebWork is broader than just TA-accessibility and should be considered by all WebWork institutions.

Under federal law (FERPA), a student's Social Security number is private information, and universities and colleges must protect that privacy. Here at Indiana University, the central computing unit is especially sensitive about this, because several years ago an anti-privacy advocate found a list of names and Social Security numbers for about 1000 IU employees on an insecure Web Server and then posted that list on his WWW site.

As a result, we have had to abandon the use of Social Security numbers in WebWork. As part of generating the WebWork classlist from the electronic roster provided by the Registrar, we replace the Social Security numbers with random 8 digit numbers. Then, after importing the classlist, we use the Email Option on the Professor's page to send a message to each student to inform the student of her/his initial password (i.e., the random 8 digit number). To generate the messages containing the initial passwords, one merely has to prepare a message file "initial_password.msg" that includes the line:

Initial Password: $SID

<| Post or View Comments |>

userArnold K. Pizer - Re: FERPA and  blueArrow
1/24/2001; 11:07:37 PM (reads: 1265, responses: 0)
It is convenient to use as the studentID (which is also the initial password) whatever your university uses as their studentID. The reason is that the scoring routines output this studentID in the scoring totals file which can be exported to and imported from Excel for example. Thus it can be used to keep track of all semester grades. If you instutution allows it, it's very convenient to use a truncated version of this file to send final grades to the registrar --- usually they want the student's name and student ID. The same file can be used by WeBWork's send mail page to email students their grades and in fact all scores on which thier grade is based. We find this very useful especially in catching missing or erroreous recitation/quiz grades --- there are not many errors but even one is important to the affected student.

If using the university studentID is not important to you, the method Indiana uses is very good. At Rochester, this semester the registrar made available electronically half hidden SS#'s, e.g. XXX-XX-1234. As a student login we use the first part of a student's email address, e.g. ab002j. For a unique studentID, many courses at Rochester combined these using e.g. ab002j-1234 (i.e. the student's email address and the last 4 digits of their SS#). You could use the same string as login and studentID, but in that case the initial password is quite public and it is likely "friends" might login and change a student's password.

If your university adopts a studentID different from the SS#, this is the obvious thing to use. In New York a state law takes effect July 1st which I think will prevent Universities from using SS#'s as ID's. I do not know what Rochester will do. This semester the approach seems to be to still use SS#'s, but to keep them half hidden, at least in electronic formats. I wonder if this will be legal after July 1.

<| Post or View Comments |>

userAndy Wildenberg - Re: FERPA and  blueArrow
1/25/2001; 3:59:30 PM (reads: 1279, responses: 0)
>I wonder if this will be legal after July 1.

If it's not, Stony Brook is going to have some very big problems...

Another alternative would be to use hash values instead of actual SS#s. The random number system is quite useful but if you lose the trnaslation table your life becomes difficult.

I would guess that Perl would have some hash functions of some sort built in, and if not it should be simple enough to make them. Something like MD5 is probably overkill: I was thinking a CRC check or even some sort of XOR function would work.

<| Post or View Comments |>