I've found some discussion on the United States Family Educational Rights and Privacy Act (FERPA), but most seems fairly cursory up to this point. As a developer for a public institution in the United States, FERPA binds us to some serious restrictions, some of which we've struggled to make compatible with Moodle.
Our interpretation of FERPA suggests that we cannot release any data which links a person to enrollment at the institution; the only exceptions exist in the pursuit of an employee's duties (as defined in 34 CFR § 99.31). Now, we do understand that if a FERPA student opts into something then they relinquish their protections in that context. However, our system runs in such a way that all students in courses supported by Moodle are auto-enrolled at the beginning of the quarter, so we cannot simply post a disclaimer stating that by using Moodle one relinquishes their FERPA protections.
We use public courses with a modification which allows for private (enrolled-only) activities, and for this reason, we've had to disable the Participant block in both the Student and Guest contexts, because enrollment only implies that a student gives up their FERPA protections to the instructor, not the rest of the class. Additionally, we've had to disable moodle/user:viewdetails in all contexts currently because user/view.php lists a series of courses within which a student is enrolled. Now, anyone familiar with the social networking aspects of Moodle would say that this causes major problems. A semi-solution involves simply removing that field and then protecting all mandatory fields and only allowing opt-in fields visible through $CFG->hiddenuserfields.
We hit another big FERPA issue with the moodle/role:assign capability, which presents the user with a two-column selection box that clearly violates FERPA as on the right it shows ALL people in the entire system, including those who have FERPA holds. So again we've had to limit functionality greatly by disabling this capability globally except for administrators, as instructors only have the right to see FERPA data for students enrolled in classes that they teach.
We also found several places (such as the forum user view) where you can pull the full name of a user simply by inputting an ID, even if you don't have access to see anything else for the user. Thus we had to alter $CFG->fullnamedisplay to first name and then enable moodle/site:viewfullnames for instructors and content editors to allow teachers to see their correct name but protect from these other invasive tricks to pull FERPA data.
Basically, I've found that as we've moved to enforce FERPA fully in our instance of Moodle, we've greatly sacrificed functionality. Was wondering if there are any considerations currently about implementing FERPA functionality (as I couldn't find any solid mention in docs or forums)? Also, how have other institutions in the United States conformed with FERPA while using Moodle? It seems a lot have either made it opt-in or created a disclaimer warning FERPA students that they relinquish their protection in the context of Moodle - neither of these approaches is viable in our situation.
Also, how have other institutions in the United States conformed with FERPA while using Moodle? It seems a lot have either made it opt-in or created a disclaimer warning FERPA students that they relinquish their protection in the context of Moodle - neither of these approaches is viable in our situation.
You've made some very important points, and at the same time, frustrating points. I think most US institutions that have adopted Moodle (P-12 and Higher Education) are probably just ignoring the "fine" points of FERPA...you have done far more than any others I've heard of.
Even the institutions that assume an "opt-in" approach sufficiently addresses the problem, are, in my opinion making a mistake if their students "must" use Moodle in their courses and are provided no other alternative...it's not really "opt-in" if there is no alternative. That is a policy just begging to be challenged.
Just for your consideration (as if you don't already have enough to consider ), I'm sure you are aware that anyone (student, faculty, or guest) who has access to a course, also has access to any file the faculty member uploads to the "files" area in course admin....even if the faculty member doesn't make it available on the course. This is true up through at least version 1.6 (and I assume the same holds true for higher versions, but I haven't checked)
Faculty should be made aware of this and understand that just because this "files" area is in their course "admin" area, doesn't mean (as one would logically assume), that this is a protected area. I've had faculty upload spreadsheets with all kinds of student information to that area, thinking that it was only accessible by them.
Steve
FERPA has indeed proven frustrating, but as both a developer and a student at the institution, I have a unique point of view in understanding where it truly serves an important purpose.
I'd like to thank you very much for bringing up the point about the Moodle filesystem. We had not, to this point, considered it but indeed I could envision a teacher putting up data with student data on it so definitely going to have to think about how to address this issue. It seems that likely the best approach with this would be promoting faculty awareness - possibly even building in some sort of warning dialog to appear during uploads. Have you had to tackle this issue? If so, what decisions did you come to?
I'd like to thank you very much for bringing up the point about the Moodle filesystem. We had not, to this point, considered it but indeed I could envision a teacher putting up data with student data on it so definitely going to have to think about how to address this issue. It seems that likely the best approach with this would be promoting faculty awareness - possibly even building in some sort of warning dialog to appear during uploads. Have you had to tackle this issue? If so, what decisions did you come to?
Well, it has been discussed a few times in the forums (like below), but to my knowledge has never been addressed (or even acknowledged) by the developers.
http://moodle.org/mod/forum/discuss.php?d=48883
You are correct that the best approach (and possibly the only approach) is promoting faculty (and site admin) awareness.
It's ironic that Moodle makes a big point about ensuring your moodledata directory is not accessible directly via the web upon install...quoting from the install directions:
"Security warning: For security purposes, it's best that this directory is NOT accessible directly via the web. The easiest way to do this is to simply locate it OUTSIDE the web directory,..."
But then neglects the fact that, once anyone is in a class, they have access to those same files 
. Again, I have not tested this beyond version 1.6, so I would hope that it has been addressed in later versions, but I doubt it has been.
Just take a look at some of the installs that didn't follow the install "Security warning" and have their moodledata directory "on the web"...only takes a simple (allinurl: "moodledata") search on Google...and then know that these same files are available to anyone in a class even in a "proper" Moodle installation. I would assume that many people who have their moodledata directory in the public_html folder, did their install through Fantastico and that is where it was automatically put...and they are not even aware of it. Again, this is an assumption...I haven't done a Fantistaco install in years, but the last time I did, moodledata was created in public_html.
The way I handle it is through education...when I teach a class I have a select few of those moodledata links book-marked to show teachers that even though their course files can't be browsed like that, those files can still be accessed by a "smart" participant in their classes...the visuals seem to make an impact. So, unfortunately, the bottom line message is....if you don't want a participant in your class to have access to it....don't upload it to Moodle....just because a file is in "your" admin area, that doesn't mean you are the only one who can access it.
Steve
I wasn't aware it was so insecure, but I've just tried accessing the files section in 1.8.1 with a student account and got a warning about not having permissions to do that. So unless there is another way in I think it may have been fixed.
Regards
Regards
Yep, indeed it seems like this is locked down. Going to keep testing though.
That's good...thanks for the update.
Steve
Hummm....I have a Moodle 1.8.2 test site. There is a course on it called "A Test Course". It doesn't allow guest, has an enrollment key, and has one student in it. There is nothing in the course and one file in the teacher "files" area. The student login is:
Username: moodle1
Password: moodle2
http://www.extremeclassroom.com/lms/file.php/4/my_docs/test.doc
Click the link above, login and see if you get the document. I'll leave access open for a day or so.
Steve
Yes, I can. My test case must not have been set up right.
Hi Steve,
Boy, you sure opened a can of worms! Actually, the can was already open. You just pointed it out.
Modify extremeclassroom.com/lms to allow guests (so you get the Login as guest button). Then repeat the experiment, this time logging in as guest rather than as moodle1. Once you're on the site, don't bother trying to enter the test course -- forget it! It's "protected" by an enrolment key. Just point your browser at the test.doc URI and see what happens.
Boy, you sure opened a can of worms! Actually, the can was already open. You just pointed it out.
Modify extremeclassroom.com/lms to allow guests (so you get the Login as guest button). Then repeat the experiment, this time logging in as guest rather than as moodle1. Once you're on the site, don't bother trying to enter the test course -- forget it! It's "protected" by an enrolment key. Just point your browser at the test.doc URI and see what happens.
Let me guess without trying...you still get the document?
Steve
Yes.
I think some of this might be a cache issue (see below, Ray Lawrence asks this question). I was much LESS able to get to things when I cleared the cache prior to each attempt.
atw
atw
A.T.
I experimented some more and I'm beginning to think you're right about the caching. Some of the files I thought I was able to access without authentication had probably been in my cache for several days. When I cleared my cache, I could no longer access those files.
When I did the experiment on Steve's site (see above), I logged in as Guest and then used the "secret" URI (which he posted) to access a file in a course that did not permit guest access. I got the save or open dialog, but I did neither. Then I logged out and accessed the file again using the same URI. Again, I got the a save or open dialog. I'm sure this is somehow related to caching, but how does caching work with a document that hasn't been opened or saved?
By the way, Steve has wisely removed has document so you'll have to try this experiment elsewhere.
I experimented some more and I'm beginning to think you're right about the caching. Some of the files I thought I was able to access without authentication had probably been in my cache for several days. When I cleared my cache, I could no longer access those files.
When I did the experiment on Steve's site (see above), I logged in as Guest and then used the "secret" URI (which he posted) to access a file in a course that did not permit guest access. I got the save or open dialog, but I did neither. Then I logged out and accessed the file again using the same URI. Again, I got the a save or open dialog. I'm sure this is somehow related to caching, but how does caching work with a document that hasn't been opened or saved?
By the way, Steve has wisely removed has document so you'll have to try this experiment elsewhere.
I tried to see just how far I could get with this strategy. We already know that a guest who knows (or is able to guess) the filename and location can directly access any course file created by a teacher. But what about student files in moddata?
As long as it's not an assignment, anyone logged into the site (including guests) can see them.
File.php checks that the user attempting to view an uploaded assignment is either the student who submitted the assignment or someone with the capability mod/assignment:grade. But what about Workshop and Exercise? Both of these activities place files in moddata. Some are created by the teacher and others (the submissions) are created by students. No security check is performed for these files, and any logged in user (including guest) who knows or can guess the URI can access them directly, e.g.
The URI's of these file are much more predictable, and the filename may be easy to guess if you know something about the exercise, so these files are particularly vulnerable to snooping by fellow students -- or worse.
Just created MDL-10701 "Security of Workshop files"
As long as it's not an assignment, anyone logged into the site (including guests) can see them.
File.php checks that the user attempting to view an uploaded assignment is either the student who submitted the assignment or someone with the capability mod/assignment:grade. But what about Workshop and Exercise? Both of these activities place files in moddata. Some are created by the teacher and others (the submissions) are created by students. No security check is performed for these files, and any logged in user (including guest) who knows or can guess the URI can access them directly, e.g.
http://yoursite/file.php/4/moddata/exercise/2/my_summer_vacation.doc
The URI's of these file are much more predictable, and the filename may be easy to guess if you know something about the exercise, so these files are particularly vulnerable to snooping by fellow students -- or worse.
Just created MDL-10701 "Security of Workshop files"
So there was another way of getting to the files section!
Still broken in 1.8.1 too then if you know the exact path and name which for some won't be too hard to work out!!!
Still broken in 1.8.1 too then if you know the exact path and name which for some won't be too hard to work out!!!
I have never worked with two institutions that interpreted FERPA the same way. But all of them followed a few standard practices:
Not locking down the installation in this way is the equivalent of letting anyone off the street walk into a university building and into a classroom--whether the students in that classroom are wearing masks or not is sort of irrelevant at that point.
Within secured courses, however, no functionality is lost. In fact, you lost all your functionality by trying to keep the courses "open."
In my opinion, you have to lock down your courses with enrollment keys in order to safely use the Web 2.0 functionality. And what is the point of Web 2.0 functionality anyway, if students can't see who the other students are? The goal of that functionality is to create human connections.
What I usually find is that the middle ground wherein an institution is both FERPA-compliant and provides decent interactivity in (any) LMS is an administrative middle ground, achieved through administrative compromises and changes, not changes to Moodle.
A
- Secure all courses with enrollment keys.
- Force loginforprofiles.
- Do not allow guest access to courses.
- Do not allow self-authentication.
Not locking down the installation in this way is the equivalent of letting anyone off the street walk into a university building and into a classroom--whether the students in that classroom are wearing masks or not is sort of irrelevant at that point.
Within secured courses, however, no functionality is lost. In fact, you lost all your functionality by trying to keep the courses "open."
In my opinion, you have to lock down your courses with enrollment keys in order to safely use the Web 2.0 functionality. And what is the point of Web 2.0 functionality anyway, if students can't see who the other students are? The goal of that functionality is to create human connections.
What I usually find is that the middle ground wherein an institution is both FERPA-compliant and provides decent interactivity in (any) LMS is an administrative middle ground, achieved through administrative compromises and changes, not changes to Moodle.
A
In my opinion, you have to lock down your courses with enrollment keys in order to safely use the Web 2.0 functionality. And what is the point of Web 2.0 functionality anyway, if students can't see who the other students are? The goal of that functionality is to create human connections.
Unfortunately, many of those social networking functions violate FERPA, at least by my institution's interpretation: students do not implicitly have the rights to another student's FERPA protections simply because they share a class. By attending the class physically they forfeit their protections to those enrolled in the class; however, that does not release their rights online, and as we autoenroll all students in a class, we cannot viably allow access to a class roster.
Where does FERPA lay out this exception to the rules of attending a course, wherein attending an online course is different from attending a classroom course? What is the passage of the regulations that makes that differentiation? I have never heard of it before.
If a student enrolls in an online course, that is the same thing as enrolling in a classroom course. The online course still has a classroom, only it is a virtual classroom. Students expect to see who else is in the course with them, whether it's a real classroom, or an online classroom.
In all likelihood, you have no control over your institution's interpretation of FERPA, but I've never heard of a simultaneously strict FERPA policy and an "open" course setup before. My line of thinking is that you're trying to make Moodle do two things it's not designed to do simultaneously. The fact that it doesn't do these two things simultaneously is what allows organizations to make Moodle FERPA-compliant. So your organization has backed itself into a logical corner. Once again, sometimes the solutions to these things have to be organizational and administrative, not technological.
For example, why not have students give permission to be automatically enrolled in an online Moodle component upon registration?
A
If a student enrolls in an online course, that is the same thing as enrolling in a classroom course. The online course still has a classroom, only it is a virtual classroom. Students expect to see who else is in the course with them, whether it's a real classroom, or an online classroom.
In all likelihood, you have no control over your institution's interpretation of FERPA, but I've never heard of a simultaneously strict FERPA policy and an "open" course setup before. My line of thinking is that you're trying to make Moodle do two things it's not designed to do simultaneously. The fact that it doesn't do these two things simultaneously is what allows organizations to make Moodle FERPA-compliant. So your organization has backed itself into a logical corner. Once again, sometimes the solutions to these things have to be organizational and administrative, not technological.
For example, why not have students give permission to be automatically enrolled in an online Moodle component upon registration?
A
Where does FERPA lay out this exception to the rules of attending a course, wherein attending an online course is different from attending a classroom course? What is the passage of the regulations that makes that differentiation? I have never heard of it before.
If a student enrolls in an online course, that is the same thing as enrolling in a classroom course. The online course still has a classroom, only it is a virtual classroom. Students expect to see who else is in the course with them, whether it's a real classroom, or an online classroom.
If a student enrolls in an online course, that is the same thing as enrolling in a classroom course. The online course still has a classroom, only it is a virtual classroom. Students expect to see who else is in the course with them, whether it's a real classroom, or an online classroom.
I'd have to ask up the chain because this is merely what we've been told.
In all likelihood, you have no control over your institution's interpretation of FERPA, but I've never heard of a simultaneously strict FERPA policy and an "open" course setup before. My line of thinking is that you're trying to make Moodle do two things it's not designed to do simultaneously. The fact that it doesn't do these two things simultaneously is what allows organizations to make Moodle FERPA-compliant. So your organization has backed itself into a logical corner. Once again, sometimes the solutions to these things have to be organizational and administrative, not technological.
I believe the reason we have an open course setup is so that Instructors can post some information for the general public and then have other information locked down to enrolled students only.
What kind of institution do you work at?
I wonder if there would be an easier solution that would allow instructors to still post information to the public, but wouldn't require you to leave all the courses accessible to unauthenticated users. What about giving instructors their own public courses, and separate courses secured with enrollment keys. You can duplicate the courses without user information and just create a second course. Who is the "public" that accesses these courses?
If you can, have the chair check on that interpretation of enrollment information. There are many forums out there for Registrars and others who have to write institutional FERPA policy, and many must have dealt with Moodle before. I have always been told by Registrars that if a student knowingly enrolls in an online course, they knowingly share their enrollment info for that course with their classmates. Even if that isn't the case, registering students could simply sign a release form addressing that permission.
The other issues, being able to access files an instructor has uploaded, and things like that, they are security issues that have to be addressed in Moodle, but I wonder if there isn't an administrative compromise your institution might come to.
A
I wonder if there would be an easier solution that would allow instructors to still post information to the public, but wouldn't require you to leave all the courses accessible to unauthenticated users. What about giving instructors their own public courses, and separate courses secured with enrollment keys. You can duplicate the courses without user information and just create a second course. Who is the "public" that accesses these courses?
If you can, have the chair check on that interpretation of enrollment information. There are many forums out there for Registrars and others who have to write institutional FERPA policy, and many must have dealt with Moodle before. I have always been told by Registrars that if a student knowingly enrolls in an online course, they knowingly share their enrollment info for that course with their classmates. Even if that isn't the case, registering students could simply sign a release form addressing that permission.
The other issues, being able to access files an instructor has uploaded, and things like that, they are security issues that have to be addressed in Moodle, but I wonder if there isn't an administrative compromise your institution might come to.
A
I wonder if there would be an easier solution that would allow instructors to still post information to the public, but wouldn't require you to leave all the courses accessible to unauthenticated users. What about giving instructors their own public courses, and separate courses secured with enrollment keys. You can duplicate the courses without user information and just create a second course. Who is the "public" that accesses these courses?
Our production server currently uses this method. However, when we start talking about hundreds of classes, it becomes cumbersome; even with categories, it becomes tricky to navigate and clearly isn't easy to use. Additionally, we do not use enrollment keys - instead, we do auto-enrollment from an external database as we've been told our Moodle needs to reflect up-to-date student enrollment.
I have always been told by Registrars that if a student knowingly enrolls in an online course, they knowingly share their enrollment info for that course with their classmates. Even if that isn't the case, registering students could simply sign a release form addressing that permission.
The courses are not actually online courses; merely, we use Moodle as a supplement, and then additionally for collaborative sites. Even if they were to share their enrollment with fellow classmates (which our lawyers have thus far objected to), Instructors still either have full access to an ENTIRE list of ALL students in Moodle or they cannot manually assign roles, anyone in the system can sweep through ID's in the forum user view page and see the name of every individual in the system (anyone with moodle/user:viewdetails can see even far greater FERPA infringements). Even with disclaimers if we'd be allowed to implement them, problems like the two above constitute major issues.
Enrollment keys don't just enroll students: they keep non-enrolled students from entering a course with an enrollment key. Even with Moodle installs that enroll from an external database, you should use enrollment keys if you want to prevent unauthorized access to courses.
If you use 1.8 you can edit your roles to prevent unauthenticated users from viewing forums and forum posts. I believe the setting is viewdiscussion:
http://docs.moodle.org/en/Capabilities/mod/forum:viewdiscussion
The fact that a student is taking courses at an institution is not FERPA-protected; what is protected is what specific courses the student is taking:
It is not a FERPA violation to let instructors see a list of all students in the institution where they teach. That is "dates of attendance," and that is not restricted by FERPA. This is only common sense, after all, since you could just as easily see the student in the halls of the building in which you teach.
The FERPA risk is when a student name is connected to non-directory contact information, though I don't know whether email is considered directory information or not (you can hide the email address in 1.8); academic records such as enrollment in specific courses and grades earned; and any ID numbers housed within the course. These fields can all be hidden in Moodle 1.8 and higher.
A
If you use 1.8 you can edit your roles to prevent unauthenticated users from viewing forums and forum posts. I believe the setting is viewdiscussion:
http://docs.moodle.org/en/Capabilities/mod/forum:viewdiscussion
The fact that a student is taking courses at an institution is not FERPA-protected; what is protected is what specific courses the student is taking:
Schools may disclose, without consent, "directory" information such as a student's name, address, telephone number, date and place of birth, honors and awards, and dates of attendance.http://www.ed.gov/policy/gen/guid/fpco/ferpa/index.html
It is not a FERPA violation to let instructors see a list of all students in the institution where they teach. That is "dates of attendance," and that is not restricted by FERPA. This is only common sense, after all, since you could just as easily see the student in the halls of the building in which you teach.
The FERPA risk is when a student name is connected to non-directory contact information, though I don't know whether email is considered directory information or not (you can hide the email address in 1.8); academic records such as enrollment in specific courses and grades earned; and any ID numbers housed within the course. These fields can all be hidden in Moodle 1.8 and higher.
A
Enrollment keys don't just enroll students: they keep non-enrolled students from entering a course with an enrollment key. Even with Moodle installs that enroll from an external database, you should use enrollment keys if you want to prevent unauthorized access to courses.
We want some details on a course public and thus enrollment keys do not work for us.
Schools may disclose, without consent, "directory" information such as a student's name, address, telephone number, date and place of birth, honors and awards, and dates of attendance.
It is not a FERPA violation to let instructors see a list of all students in the institution where they teach. That is "dates of attendance," and that is not restricted by FERPA. This is only common sense, after all, since you could just as easily see the student in the halls of the building in which you teach.
The FERPA risk is when a student name is connected to non-directory contact information, though I don't know whether email is considered directory information or not (you can hide the email address in 1.8); academic records such as enrollment in specific courses and grades earned; and any ID numbers housed within the course. These fields can all be hidden in Moodle 1.8 and higher.
The point of that paragraph is to define what a school may do when no FERPA hold exists and also to make sure that a student is aware of FERPA. We've been told by our Director of IT Security, Legal Counsel, and the Registrar's Office, that FERPA data includes anything that links a student to the school such as full name (or first initial plus last name), student ID, or course enrollment. As an example, when someone requests information about a student of our institution, the response they receive if the person has a FERPA hold is something to the extent of "we have no information on that person." Professors technically cannot even post grades with student ID numbers on their door, a still fairly common practice.
My line of thinking is that you're trying to make Moodle do two things it's not designed to do simultaneously. The fact that it doesn't do these two things simultaneously is what allows organizations to make Moodle FERPA-compliant.
It is true that the Open nature of his courses is not the norm and results in some unique problems, but simply putting enrollment keys on a course and closing them to the general public does not make Moodle FERPA compliant...that just keeps the general public out.
As I believe Eric correctly pointed out in a previous reply, even other students in a course are not entitled to certain information about their classmates that may be available once in a course. If the student information that he is concerned about (as outlined in the original post) is still available to all students in the class, then it could still be a FERPA concern...the fact that the information is only available to other students and not the general public doesn't matter.
If a student enrolls in an online course, that is the same thing as enrolling in a classroom course. The online course still has a classroom, only it is a virtual classroom. Students expect to see who else is in the course with them, whether it's a real classroom, or an online classroom.
And...due to the nature of the online environment, there is a huge difference between the information available in the two (online vs face-to-face) and assuming they are the same is a vast over simplification.
Steve
I agree that government regulations are important, but these regulations were not written for the Web. There is a difference between publishing a list of all student enrollment in your institution on an HTML page on the Web and having students enrolled in courses in an LMS that is password-protected.
If enrollment information--that is, what other students are enrolled in a single course--is not supposed to be accessible to one's classmates, then just about every K-20 online course being taught in the US is in violation of FERPA, regardless of what LMS it's housed in.
Most K-20 curricula encourage person-to-person interaction between students with all media available--because matriculation is increased when students have personal connections with classmates and instructors.
If enrollment information--that is, what other students are enrolled in a single course--is not supposed to be accessible to one's classmates, then just about every K-20 online course being taught in the US is in violation of FERPA, regardless of what LMS it's housed in.
Most K-20 curricula encourage person-to-person interaction between students with all media available--because matriculation is increased when students have personal connections with classmates and instructors.
I agree that government regulations are important, but these regulations were not written for the Web. There is a difference between publishing a list of all student enrollment in your institution on an HTML page on the Web and having students enrolled in courses in an LMS that is password-protected.
If enrollment information--that is, what other students are enrolled in a single course--is not supposed to be accessible to one's classmates, then just about every K-20 online course being taught in the US is in violation of FERPA, regardless of what LMS it's housed in.
Unfortunately, what everyone else does isn't an excuse when we break the law, especially as a government-funded institution. Both our lawyers and the Registrar's office have informed us of their interpretations on FERPA and expectations upon us to uphold them.If enrollment information--that is, what other students are enrolled in a single course--is not supposed to be accessible to one's classmates, then just about every K-20 online course being taught in the US is in violation of FERPA, regardless of what LMS it's housed in.
There is a difference between publishing a list of all student enrollment in your institution on an HTML page on the Web and having students enrolled in courses in an LMS that is password-protected.
You may assume that based on your own logic, but are you sure about that...from a legal perspective?
If enrollment information--that is, what other students are enrolled in a single course--is not supposed to be accessible to one's classmates, then just about every K-20 online course being taught in the US is in violation of FERPA, regardless of what LMS it's housed in.
It's not about what other students are enrolled in a single course...on a default install of Moodle, ALL courses other students are enrolled in is available to everyone in the course. For example, I just clicked on your name in your post and discovered your occupation, city, email, webpage, skype, ALL courses you are enrolled in (Using Moodle and Moodle Lounge), and the last day, date, and time you accessed this course. Some of this information you entered into your profile voluntarily (occupation, webpage, skype)...some, you had no choice (email, city, courses enrolled in, and login information).
This is just a simple example of what some would consider a FERPA concern. I also realize that what is a FERPA concern to some is not necessarily a FERPA concern to others. For example, if you are a 5th grade art teacher and decide to display your students art work in the hallway of you school, this may not be a FERPA concern to you, BUT that doesn't mean it isn't a FERPA concern to others.
I think Eric has the correct take on this when he writes:
"Unfortunately, what everyone else does isn't an excuse when we break the law, especially as a government-funded institution. Both our lawyers and the Registrar's office have informed us of their interpretations on FERPA and expectations upon us to uphold them."
That pretty much sums it up.
Steve
Moodle.org is not the only way of configuring a Moodle site. Just because you can find my skype ID on Moodle.org doesn't mean you could get it on a secured academic installation. Also, in fact, I can hide my email address in my user profile on Moodle.org. And all the other fields can be hidden by default from the GUI for all non-admin users on the site, using Permissions.
I agree that the fact that the list of courses a student is enrolled in is FERPA information. This is a good point, and there should be a way to hide this in the short profile view from the Admin screens.
Other than that, everything you list here can be hidden using 1.8 configuration settings in the GUI, and even that can't be seen by a non-authenticated user on most installs. I agree that some people don't set things up the right way (sometimes because they simply don't know better) but I don't think Moodle can be blamed for this.
A
I agree that the fact that the list of courses a student is enrolled in is FERPA information. This is a good point, and there should be a way to hide this in the short profile view from the Admin screens.
Other than that, everything you list here can be hidden using 1.8 configuration settings in the GUI, and even that can't be seen by a non-authenticated user on most installs. I agree that some people don't set things up the right way (sometimes because they simply don't know better) but I don't think Moodle can be blamed for this.
A
We've been told that the first name (or initial) plus the last name in relation to the school is a FERPA violation. In fact, in confronting this issue, our Director of IT Security informed me of a case where one student had come to him concerned about his FERPA status because if his parents or government had any idea where he attended school then his life would be in jeopardy. FERPA exists to protect people, and, while we can debate it philosophically, in reality lives hang on the line.
Frankly, while you say that we may not have set things up right, I'd argue that in fact Moodle has a gap in functionality when it comes to FERPA: filesystem, course list, full names for all unless you specify first name for all, a full listing of all students on Moodle for faculty, etc. We're working on our own attempts - more than anything I was looking for help from others to see if anyone has found any other FERPA/privacy holes - but in fact I'd think that being able to flag name, course, etc. for private should be an option.
Frankly, while you say that we may not have set things up right, I'd argue that in fact Moodle has a gap in functionality when it comes to FERPA: filesystem, course list, full names for all unless you specify first name for all, a full listing of all students on Moodle for faculty, etc. We're working on our own attempts - more than anything I was looking for help from others to see if anyone has found any other FERPA/privacy holes - but in fact I'd think that being able to flag name, course, etc. for private should be an option.
Can you please create a detailed list of issues here:
http://docs.moodle.org/en/FERPA
That would help us (Moodle experts) start addressing each one with answers in a more structured way, and end up with a reference for those interested in FERPA conformance.
I believe almost all of the issues you are talking about can be solved in current versions of Moodle by correct configuration of Moodle, and if there are any remaining issues I will certainly help to solve them.
The issue that people ALREADY inside courses can access all files from their courses (including unpublished ones IF THEY KNOW THE NAME) is well known and has been discussed before (example , example , example). Even though it's not a *critical* issue in my opinion, it should be resolved as part of the work on repository API in Moodle 2.0, which will let you use a dedicated external repository for all files, with full access control.
http://docs.moodle.org/en/FERPA
That would help us (Moodle experts) start addressing each one with answers in a more structured way, and end up with a reference for those interested in FERPA conformance.
I believe almost all of the issues you are talking about can be solved in current versions of Moodle by correct configuration of Moodle, and if there are any remaining issues I will certainly help to solve them.
The issue that people ALREADY inside courses can access all files from their courses (including unpublished ones IF THEY KNOW THE NAME) is well known and has been discussed before (example , example , example). Even though it's not a *critical* issue in my opinion, it should be resolved as part of the work on repository API in Moodle 2.0, which will let you use a dedicated external repository for all files, with full access control.
The issue that people ALREADY inside courses can access all files from their courses ... is well known
Yes, Steve pointed out one such discussion, and perhaps it is not a critical issue. But I was surprised to discover that anyone who is logged into the site (even as Guest) can see exactly the same files -- including certain student submissions in moddata -- without needing to be "inside" any course. This does seem like a more critical issue.
That's correct...No one said it hasn't been discussed before...just pointing out a potential problem that I would think developers would want to address. I view it as an important (and even critical), issue (at least for those in the US) but that's just my view. I would assume the Original Poster in this thread would view it as "critical". But, if the lead developer of Moodle doesn't view it as a "critical" issue, then clearly it's not an issue.
Also, you are one of the "power users" around here, so if you "were surprised" by this, then it's probably not that "well known".
If I were Blackboard, I would make a commercial out of this discussion.
Steve
You consider the reply above this "way off topic" Amy? Interesting...would you like to expand on that I see you rated all my other posts as "Not very helpful"...is that because I disagree with you or would you like to expand on those as well?
I see the post-raters are already chiming in an adding a lot of "value" to this discussion.
Steve
I'm going to answer here frankly, Steve, even though I think that your posting this question to me, in this manner, is inappropriate. I will respond just this once, and I will not contribute to this thread after that.
You're baiting people, Steve. You're baiting me right now. You're being unnecessarily hostile and your post to this thread, addressed to me, is not on the topic of Moodle and FERPA.
I stopped contributing to this thread because I don't feel like you are addressing the issues you've found constructively. I think you've done good work to uncover some of these issues, but I think your tone is, well, "way off topic."
The Moodle community is more than willing to work on these issues once they're uncovered, but insulting Martin isn't the right way to proceed, Steve. We are not Blackboard, and that's one of the reasons for the success of Moodle. We depend on volunteers like you to point things out and improve Moodle. But we also try to be more or less courteous and constructive. Destructive posts, posts which don't advance the Moodle community towards improving Moodle, those posts are indeed "way off topic."
Respectfully,
Amy
You're baiting people, Steve. You're baiting me right now. You're being unnecessarily hostile and your post to this thread, addressed to me, is not on the topic of Moodle and FERPA.
I stopped contributing to this thread because I don't feel like you are addressing the issues you've found constructively. I think you've done good work to uncover some of these issues, but I think your tone is, well, "way off topic."
The Moodle community is more than willing to work on these issues once they're uncovered, but insulting Martin isn't the right way to proceed, Steve. We are not Blackboard, and that's one of the reasons for the success of Moodle. We depend on volunteers like you to point things out and improve Moodle. But we also try to be more or less courteous and constructive. Destructive posts, posts which don't advance the Moodle community towards improving Moodle, those posts are indeed "way off topic."
Respectfully,
Amy
I have to agree with Amy here. I believe that there are some problems with privacy in almost ALL the on-line systems we use at universities. Technology progresses much faster than policy and law making! While I think most institutions try to be in compliance, because we care about our students and doing what is right, there are many mistakes that we make on a daily basis. Some are system wide, and some are as simple as an instructor accidentally disclosing information in a conversation.
I like the idea of Moodlers collaboratively devising some specific practices that will help people use Moodle and also comply fully with the law. That may mean some recommendations on role settings as well as good practices from the instructor's perspective. Some solutions will involve technology, some will involve training and awareness. And maybe some will involve core code changes.
I appreciate MD's willingness to have a serious look at these issues, and I (for one) am going to spend some time thinking about my own institution and what we can do better. I would also like to hear what our German friends have to say about privacy. I know that Ralf Hilgenstock has mentioned privacy constraints because Germany has some very strong laws regarding this. Privacy is not just a FERPA issue! I hope some of you will message some people who can add to this conversation and ask them to drop in.
atw
I like the idea of Moodlers collaboratively devising some specific practices that will help people use Moodle and also comply fully with the law. That may mean some recommendations on role settings as well as good practices from the instructor's perspective. Some solutions will involve technology, some will involve training and awareness. And maybe some will involve core code changes.
I appreciate MD's willingness to have a serious look at these issues, and I (for one) am going to spend some time thinking about my own institution and what we can do better. I would also like to hear what our German friends have to say about privacy. I know that Ralf Hilgenstock has mentioned privacy constraints because Germany has some very strong laws regarding this. Privacy is not just a FERPA issue! I hope some of you will message some people who can add to this conversation and ask them to drop in.
atw
Hi Alicia,
in the last years we had some discussions about German privacy laws and moodle. Most of the in the German course here.
The German situation is that we have a federal law and 16 laws of the countries. In addition there are different rules for public organisation and for privates. Because the laws didn't mention E-Learning concrete the commissioned personed make individual interpretations.
During a first Workshop in March at the German Moodle Conference Christian Grune and Andreas Vollmer presented some ideas. See here https://lms.hu-berlin.de/moodle/course/view.php?id=3857.
In the discussion we saw that there are more issues because other European countries have other laws and rules. Several of the processes in actual moodle versions are not in conformance with this rules.
One day before the Austrian moodle Conference in September starts we will discuss this issues again on a one-day workshop. We aim to develope a concept for next developements in Moodle to create conformance.
in the last years we had some discussions about German privacy laws and moodle. Most of the in the German course here.
The German situation is that we have a federal law and 16 laws of the countries. In addition there are different rules for public organisation and for privates. Because the laws didn't mention E-Learning concrete the commissioned personed make individual interpretations.
During a first Workshop in March at the German Moodle Conference Christian Grune and Andreas Vollmer presented some ideas. See here https://lms.hu-berlin.de/moodle/course/view.php?id=3857.
In the discussion we saw that there are more issues because other European countries have other laws and rules. Several of the processes in actual moodle versions are not in conformance with this rules.
One day before the Austrian moodle Conference in September starts we will discuss this issues again on a one-day workshop. We aim to develope a concept for next developements in Moodle to create conformance.
You made the ratings and I asked for you to elaborate...not sure why that would be inappropriate. Thanks anyway for providing some support for your ratings. You think I'm bating, I think I'm debating....sorry if you don't see that.
Insulting Martin? Destructive posts?
And in response to:
Destructive posts, posts which don't advance the Moodle community...
Again, I don't see any destructive posts here, but I will say that I'm not, never have been, and never will be a blind follower of any community. I'm certainly not going to overlook an issue that could put my own organization at significant legal risk just so I can be a "loyal follower" in the Moodle community.
Steve
"If I were Blackboard, I would make a commercial out of this discussion."
Having been a user of Blackboard as part of my daily work, I think they would be very, very unwise to start making any comparisons, comments or commercials on security issues.
Having been a user of Blackboard as part of my daily work, I think they would be very, very unwise to start making any comparisons, comments or commercials on security issues.
I've used Blackboard for about 7 years...still use it today. To my knowledge students can't access other students work or unpublished teacher files. Of course, I could be wrong, but I can't replicate the issue in Blackboard.
If there are other security issues (FEPRA related) or otherwise, I would like to know about them since I (and my campus) still use that system...however, we are considering switching to Moodle (been discussing it for the past year), but we are going to proceed with our eyes open.
Do you have some specific examples you can share with us?
If you don't want to post them, email them to me and once I verify them, I'll post them.
Steve
There is this vulnerability (reported 2005) related to being able to download other student's assignments.
Its hard to tell if its related to the huge Blackboard cheating fiasco of a few months ago, or if that was a new
Its hard to tell if its related to the huge Blackboard cheating fiasco of a few months ago, or if that was a new
Thanks John...sounds similar to the Moodle problems we have been discussing here.
I'm leaving today for an education conference in Beijing where I'll be doing a presentation on Open Source Software (and saying some good things about Moodle as part of that presentation). I'll be gone for a couple of weeks, but I'll check this out on our Blackboard system when I get back and let you know what I find. If that vulnerability exist, then people need to know about it.
As has been pointed out by others before, security through obscurity is never a good practice...open source or not.
Steve
Just to follow-up, I can not replicate this problem in Blackboard. If it was a bug in their system, it looks like they've fixed it.
Steve
Thank you very much John for your information. For me it is absolutely a critical issue, and for me is everbody who means it is not, outside of every discussion. When a user can access to any other users files is this a desaster and not only a problem.
Only by coincidence i found your posting, but i see you open a ticket in the tracker! We will see ...
Thanks again!
Andy
Only by coincidence i found your posting, but i see you open a ticket in the tracker! We will see ...
Thanks again!
Andy
In reply to Andy Tagliani
Re: Moodle and FERPA (slightly off topic) file accessible to anyone
by Jason Hollowell -
I've read through this thread twice now 
and decided to post a question here that is directly related to the discussion that took place midway through the thread about access to files. I understand that this portion of the thread was/is slightly off of the initial post but is still very related I believe.
I am using 1.8.2+ and in the following situation, a file that I upload within a class that I have protected by an enrollment key (no guest access) is accessible by anyone that has the url. You do not have to be logged into the site as a student, guest, admin...
Here is the scenario:
1. I turn on editing in my course
2. Select "link to file" from the "add a resource" menu
3. Upload a video file (student conversation) with the following parameters:
Under Advanced Settings: Window - same window (all options below that checked (e.g. keep page navigation visible on the same page) - no parameter settings.
When I (or any student) clicks on that file it is played as it should be using the multimedia filter (my files are .mov files) and to my surprise the location (url) of the file appears below the file. This url is the one that can be accessed by anyone on the internet. Of course you have to know the url but the mere fact that it is accessible to anyone in the world is a big problem at my university. Administrators will freak if I present this site university-wide without a work around for this issue.
If I change the settings to: new window or don't check the "keep page navigation visible on the same page", the url appears in the browser url window. Oddly however, the url that appears in the browser window with the settings I explained first (1, 2, 3, above) is a url with a php ID which is NOT accessible without being logged in. In a previous version of Moodle (I think it was either 1.6 or 1.7 I can't remember) I didn't have the issue of the url being displayed when the file was being played back....I guess it was probably still accessible to anyone who knew the address though...
My university is not in the States (I'm in Japan) so FERPA is not an issue but we have a committee on campus now (called the Compliance committee) that deals with internet related security issues and with personal information issues and this one is a 'personal information' issue for us.
Am I correct in interpreting comments made here in this thread to mean that my current problem is one that has been noted and is something that will be dealt with in 2.0? And, is there any way I can deal with this problem in the meantime? 2.0 is a ways off right?
Thanks in advance for any help or advice anyone can provide.
Jason
P.S. My data directory is outside my www directory....I don't understand why access to this file is allowed without a login...
I cannot do this same thing for attachments made in a forum. Copying the link to the attachment in a forum and then trying to access that url without being logged in takes me to the login window instead of giving me direct access the way it does with the video file.....?
I am using 1.8.2+ and in the following situation, a file that I upload within a class that I have protected by an enrollment key (no guest access) is accessible by anyone that has the url. You do not have to be logged into the site as a student, guest, admin...
Here is the scenario:
1. I turn on editing in my course
2. Select "link to file" from the "add a resource" menu
3. Upload a video file (student conversation) with the following parameters:
Under Advanced Settings: Window - same window (all options below that checked (e.g. keep page navigation visible on the same page) - no parameter settings.
When I (or any student) clicks on that file it is played as it should be using the multimedia filter (my files are .mov files) and to my surprise the location (url) of the file appears below the file. This url is the one that can be accessed by anyone on the internet. Of course you have to know the url but the mere fact that it is accessible to anyone in the world is a big problem at my university. Administrators will freak if I present this site university-wide without a work around for this issue.
If I change the settings to: new window or don't check the "keep page navigation visible on the same page", the url appears in the browser url window. Oddly however, the url that appears in the browser window with the settings I explained first (1, 2, 3, above) is a url with a php ID which is NOT accessible without being logged in. In a previous version of Moodle (I think it was either 1.6 or 1.7 I can't remember) I didn't have the issue of the url being displayed when the file was being played back....I guess it was probably still accessible to anyone who knew the address though...
My university is not in the States (I'm in Japan) so FERPA is not an issue but we have a committee on campus now (called the Compliance committee) that deals with internet related security issues and with personal information issues and this one is a 'personal information' issue for us.
Am I correct in interpreting comments made here in this thread to mean that my current problem is one that has been noted and is something that will be dealt with in 2.0? And, is there any way I can deal with this problem in the meantime? 2.0 is a ways off right?
Thanks in advance for any help or advice anyone can provide.
Jason
P.S. My data directory is outside my www directory....I don't understand why access to this file is allowed without a login...
I cannot do this same thing for attachments made in a forum. Copying the link to the attachment in a forum and then trying to access that url without being logged in takes me to the login window instead of giving me direct access the way it does with the video file.....?
In reply to Jason Hollowell
Re: Moodle and FERPA (slightly off topic) file accessible to anyone
by Ray Lawrence -
Jason,
Did you access the file when logged in and then attempt to access it after logging out? Have you tried to access the file after emptying your browser cache?
Did you access the file when logged in and then attempt to access it after logging out? Have you tried to access the file after emptying your browser cache?
In reply to Ray Lawrence
Re: Moodle and FERPA (slightly off topic) file accessible to anyone
by A. T. Wyatt -
I like this idea about emptying the cache. That definitely might have affected what has gone on before with the testing scenarios.
I get these results on 1.6.3:
1) Forum was created with each student in his or her own group (only member)
2) Graded rubric was posted to each student using the separate groups setting (pdf file)
3) URL does not show when pdf file is opened, but if you copy the link location prior to clicking on the link, you can get a path straight to the file
4) Cache cleared
5) Sample Student account used to access the URL (Pasted the path). Student first asked to log in to moodle (we don't allow guest access); student second asked for enrollment key in the course; then student is presented with the file.
Scenario two:
1) Assignment was turned in by student
2) URL does not show when flash file is opened, but if you copy the link you can get the path
3) Cache cleared
4) Sample Student account used to access the URL. Student first asked to log in to moodle; student second asked for enrollment key in the course; then student is presented with the pink "Access denied" error.
This is getting more interesting! Why the different behaviors for different areas, or filetypes? Clearly we need to do more testing, and the cache clearing makes a big difference to the results! Good catch, Ray! I am setting up my production 1.8 over the weekend, and when I get some more courses restored on that system, I will try to create a test matrix of different scenarios and post back here.
atw
I get these results on 1.6.3:
1) Forum was created with each student in his or her own group (only member)
2) Graded rubric was posted to each student using the separate groups setting (pdf file)
3) URL does not show when pdf file is opened, but if you copy the link location prior to clicking on the link, you can get a path straight to the file
4) Cache cleared
5) Sample Student account used to access the URL (Pasted the path). Student first asked to log in to moodle (we don't allow guest access); student second asked for enrollment key in the course; then student is presented with the file.
Scenario two:
1) Assignment was turned in by student
2) URL does not show when flash file is opened, but if you copy the link you can get the path
3) Cache cleared
4) Sample Student account used to access the URL. Student first asked to log in to moodle; student second asked for enrollment key in the course; then student is presented with the pink "Access denied" error.
This is getting more interesting! Why the different behaviors for different areas, or filetypes? Clearly we need to do more testing, and the cache clearing makes a big difference to the results! Good catch, Ray! I am setting up my production 1.8 over the weekend, and when I get some more courses restored on that system, I will try to create a test matrix of different scenarios and post back here.
atw
In reply to A. T. Wyatt
Re: Moodle and FERPA (slightly off topic) file accessible to anyone
by John Isner -
A.T.
How about posting a link to your file?
How about posting a link to your file?
In reply to John Isner
Re: Moodle and FERPA (slightly off topic) file accessible to anyone
by A. T. Wyatt -
The files I tested were real files. I can't post those. Or do you mean the matrix? I am now confused!
atw
atw
In reply to A. T. Wyatt
Re: Moodle and FERPA (slightly off topic) file accessible to anyone
by John Isner -
I mean a link to a real file -- say the pdf. If you believe the files cannot be accessed by anyone who is (a) not logged in to your site (b) not enrolled in your course and (c) doesn't have the file cached in his browser, then the best way to test that theory would be to make the URI of the file public.
In reply to John Isner
Re: Moodle and FERPA (slightly off topic) file accessible to anyone
by A. T. Wyatt -
When I have time to set up a test case, I will.
atw
atw
In reply to A. T. Wyatt
Re: Moodle and FERPA (slightly off topic) file accessible to anyone
by Andy Tagliani -
What John post i can confirm. If u user has the exact link to a file in a course he is already a student (not only his own files), this file must not be published inside a course, only stored in a folder, example in the folder called files, he can download this file. Also files in the folder moddata.
Sure, a student can send this file to another user outside of moodle, but in this case, it is his will. When students begin to play with filesnames, this is a major problem, and i think its not only my opinion!
Andy
Sure, a student can send this file to another user outside of moodle, but in this case, it is his will. When students begin to play with filesnames, this is a major problem, and i think its not only my opinion!
Andy
In reply to Andy Tagliani
Re: Moodle and FERPA (slightly off topic) file accessible to anyone
by Ray Lawrence -
In reply to Ray Lawrence
Re: Moodle and FERPA (slightly off topic) file accessible to anyone
by Jason Hollowell -
Ray,
Thanks You are correct, it was a cache issue for me. I cleared my cache and restarted the browser (just to be extra thorough) and could no longer access the file mentioned.
It would be nice if I could remove the link that is displayed below the video as it plays but as long as it's not accessible to anyone/everyone, my problem is basically solved. Sorry for my false alarm.
Without reseting my cache, would this issue for me consist for the duration of time I have selected for session timeout? I have my site set to request a login after 30 minutes of inactivity and am guessing that would/should require me to login to access the file after that amount of inactivity?
Jason
Thanks
It would be nice if I could remove the link that is displayed below the video as it plays but as long as it's not accessible to anyone/everyone, my problem is basically solved. Sorry for my false alarm.
Without reseting my cache, would this issue for me consist for the duration of time I have selected for session timeout? I have my site set to request a login after 30 minutes of inactivity and am guessing that would/should require me to login to access the file after that amount of inactivity?
Jason
In reply to Jason Hollowell
Re: Moodle and FERPA (slightly off topic) file accessible to anyone
by Marcus Green -
As a general testing point I recommend keeping a separate brand browser available to try to eliminate caching issues. Thus if you normally use IE, then double check with Firefox or with Opera. It can make life much, much easier.
My earlier comment about Blackboard was not to do with this particular type of issue, just with the wisdom of making any general security claims. I have seen Blackboard installations exhibit what appeared to be alarming security holes. However that could have been a poor installation, a lack of patching of known issues or a problem with that version of Blackboard. My point is that it is not that Blackboard is any less secure than alternatives such as Moodle, just that it is very, very unwise to throw stones at the security of rival software. All complex software will eventually have security issues.
My earlier comment about Blackboard was not to do with this particular type of issue, just with the wisdom of making any general security claims. I have seen Blackboard installations exhibit what appeared to be alarming security holes. However that could have been a poor installation, a lack of patching of known issues or a problem with that version of Blackboard. My point is that it is not that Blackboard is any less secure than alternatives such as Moodle, just that it is very, very unwise to throw stones at the security of rival software. All complex software will eventually have security issues.
Having developed a couple of Data Privacy courses for folks, here's my understanding:
One of the first questions to ask is what information does the institution designate as "directory information?" As long as a student does not specifically restrict the information, it may be disclosed.
Another consideration regarding data privacy in the US is state legislation.
One of the first questions to ask is what information does the institution designate as "directory information?" As long as a student does not specifically restrict the information, it may be disclosed.
Another consideration regarding data privacy in the US is state legislation.
Just my two-cents.
Ellen
Ellen
A quick search online produced these references:
https://www2.itap.purdue.edu/registrar/training/ferpa/content.cfm
http://www.ants.edu/student/registrar/ferpa_faq.htm#4
http://registrar.wisc.edu/ferpa/faculty/not_directory_info.php
https://www2.itap.purdue.edu/registrar/training/ferpa/content.cfm
http://www.ants.edu/student/registrar/ferpa_faq.htm#4
http://registrar.wisc.edu/ferpa/faculty/not_directory_info.php
Good links Ellen...thanks. I think the part that is particularly pertinent to this discussion (and is addressed in all three of those links) is the part that reads:
"As long as a student does not specifically restrict the information, it may be disclosed."
So, the question is...what do I do when the first students walks in and says don't make my information public?
Just food for thought.
Steve
I'm wondering whether there are standard practices that folks are using to shield student names where students have requested FERPA holds. We've done the standard stuff discussed here and on the FERPA docs page, but but given features that we use in Moodle (the messaging system, in particular), I don't see any any way to mask student names completely. We are doing external authorization and enrollments; no self-enrollment or self-registration is allowed.
We're exploring setting the names of all students with FERPA hold requests to a standard name ("Name Withheld") plus a few digits of their student ID number, which does not identify them uniquely. This allows instructors, who have access to the full ID number from our student information system, to cross-reference the names they see in the participants list and the gradebook, so they can correctly identify which "Name Withheld" students they're looking at. Students will also be allowed to request a pseudonym, to make it more comfortable to interact with other students in forums and such (and to draw less attention to the fact that a record has a hold request).
It's not a great system, but we think it'll be functional. Above all, we need to prevent access to anyone's name while still allowing students to message each other, which has become a critical part of how our faculty use Moodle.
What are other folks doing? Does anyone have any better suggestions?
David Walton
We're exploring setting the names of all students with FERPA hold requests to a standard name ("Name Withheld") plus a few digits of their student ID number, which does not identify them uniquely. This allows instructors, who have access to the full ID number from our student information system, to cross-reference the names they see in the participants list and the gradebook, so they can correctly identify which "Name Withheld" students they're looking at. Students will also be allowed to request a pseudonym, to make it more comfortable to interact with other students in forums and such (and to draw less attention to the fact that a record has a hold request).
It's not a great system, but we think it'll be functional. Above all, we need to prevent access to anyone's name while still allowing students to message each other, which has become a critical part of how our faculty use Moodle.
What are other folks doing? Does anyone have any better suggestions?
David Walton
I believe we are going with the pseudonym solution. Fortunately, there are few students who have requested that directory information be withheld.
I agree that having a "name withheld" entry is not very desirable!
atw
I agree that having a "name withheld" entry is not very desirable!
atw
We've done some work and posted it to http://tracker.moodle.org/browse/MDL-13568 for inclusion in core, but if you want FERPA compliance, simply change the following settings in your roles for teacher and below:
For students:
My fixes are implemented for 1.9. It shouldn't be hard to re-write them for 1.8+.
tabs.php
around line 92
$context = get_context_instance(CONTEXT_SYSTEM);
if ($user->id == $USER->id or has_capability('moodle/user:viewdetails', $context, NULL)) {
$toprow[] = new tabobject('profile', $CFG->wwwroot.'/user/view.php?id='.$user->id.'&course='.$course->id, get_string('profile'));
}
instead of
$toprow[] = new tabobject('profile', $CFG->wwwroot.'/user/view.php?id='.$user->id.'&course='.$course->id, get_string('profile'));
weblib.php
around line 4309
$context = get_context_instance(CONTEXT_SYSTEM);
if ($link && ($user->id == $USER->id or has_capability('moodle/user:viewdetails', $context, NULL))) {
instead of
if ($link)
around line 4486
if ($user->id == $USER->id or has_capability('moodle/user:viewdetails', $context, NULL)) {
$output .= '<a href="'. $CFG->wwwroot .'/user/view.php?id='. $user->id .'&course='. $course->id .'">'. $string->fullprofile .'...</a>';
}
instead of
$output .= '<a href="'. $CFG->wwwroot .'/user/view.php?id='. $user->id .'&course='. $course->id .'">'. $string->fullprofile .'...</a>';
grader/lib.php
around line 685
$context = get_context_instance(CONTEXT_SYSTEM);
if ($user->id == $USER->id or has_capability('moodle/user:viewdetails', $context, NULL)) {
$link = '<a href="'.$CFG->wwwroot.'/user/view.php?id='.$user->id.'&course='.$this->course->id.'">'.fullname($user).'</a>';
}
else {
$link = fullname($user);
}
$studentshtml .= '<tr class="r'.$this->rowcount++ . $row_classes[$this->rowcount % 2] . '">'
.'<th class="header c'.$columncount++.' user" scope="row" onclick="set_row(this.parentNode.rowIndex);">'.$user_pic
.$link.'</th>';
instead of
$studentshtml .= '<tr class="r'.$this->rowcount++ . $row_classes[$this->rowcount % 2] . '">'
.'<th class="header c'.$columncount++.' user" scope="row" onclick="set_row(this.parentNode.rowIndex);">'.$user_pic
.<a href="'.$CFG->wwwroot.'/user/view.php?id='.$user->id.'&course='
.$this->course->id.'">'.fullname($user).'</a></th>';
| View user profiles moodle/user:viewdetails |
Not Set |
| View hidden details of users moodle/user:viewhiddendetails |
Not Set |
| View participants moodle/course:viewparticipants |
Allow |
For students:
| View user profiles moodle/user:viewdetails |
Not Set |
| View hidden details of users moodle/user:viewhiddendetails |
Not Set |
| View participants moodle/course:viewparticipants |
Not Set |
My fixes are implemented for 1.9. It shouldn't be hard to re-write them for 1.8+.
tabs.php
around line 92
$context = get_context_instance(CONTEXT_SYSTEM);
if ($user->id == $USER->id or has_capability('moodle/user:viewdetails', $context, NULL)) {
$toprow[] = new tabobject('profile', $CFG->wwwroot.'/user/view.php?id='.$user->id.'&course='.$course->id, get_string('profile'));
}
instead of
$toprow[] = new tabobject('profile', $CFG->wwwroot.'/user/view.php?id='.$user->id.'&course='.$course->id, get_string('profile'));
weblib.php
around line 4309
$context = get_context_instance(CONTEXT_SYSTEM);
if ($link && ($user->id == $USER->id or has_capability('moodle/user:viewdetails', $context, NULL))) {
instead of
if ($link)
around line 4486
if ($user->id == $USER->id or has_capability('moodle/user:viewdetails', $context, NULL)) {
$output .= '<a href="'. $CFG->wwwroot .'/user/view.php?id='. $user->id .'&course='. $course->id .'">'. $string->fullprofile .'...</a>';
}
instead of
$output .= '<a href="'. $CFG->wwwroot .'/user/view.php?id='. $user->id .'&course='. $course->id .'">'. $string->fullprofile .'...</a>';
grader/lib.php
around line 685
$context = get_context_instance(CONTEXT_SYSTEM);
if ($user->id == $USER->id or has_capability('moodle/user:viewdetails', $context, NULL)) {
$link = '<a href="'.$CFG->wwwroot.'/user/view.php?id='.$user->id.'&course='.$this->course->id.'">'.fullname($user).'</a>';
}
else {
$link = fullname($user);
}
$studentshtml .= '<tr class="r'.$this->rowcount++ . $row_classes[$this->rowcount % 2] . '">'
.'<th class="header c'.$columncount++.' user" scope="row" onclick="set_row(this.parentNode.rowIndex);">'.$user_pic
.$link.'</th>';
instead of
$studentshtml .= '<tr class="r'.$this->rowcount++ . $row_classes[$this->rowcount % 2] . '">'
.'<th class="header c'.$columncount++.' user" scope="row" onclick="set_row(this.parentNode.rowIndex);">'.$user_pic
.<a href="'.$CFG->wwwroot.'/user/view.php?id='.$user->id.'&course='
.$this->course->id.'">'.fullname($user).'</a></th>';