Not quite FERPA compliant

[ybakos]

Because SM stores students schedules within the database, it is not technically FERPA-compliant.

We need to change how schedule saving is done, such that a student's schedule is only stored on the client, and never on the server.

Short term: remove the "save" feature and change it to prompting the user to save the web page to their machine in order to protect their privacy.

[pianohacker]

That's a nasty restriction, one that precludes a number of useful features. Namely, students can only work on their schedule from one computer, and lose any ability to compare schedules with friends.

Would it be possible to meet somewhere in the middle? Perhaps we could remove public access to schedules, and allow students to download an image (effectively a screenshot)? Or, alternatively, make it non-default and explicit to make your schedule public?

From my understanding of FERPA, from the summaries I've found and http://www.law.cornell.edu/uscode/text/20/1232g , nothing precludes the keeping of records, we just have to be very careful not to release them without explicit consent. Who voiced this concern?

[sgonzalez]

One of the things I really like about schedule miner is comparing with friends. From what I understand, we could prompt the user to have a publicly visible schedule in case they do want privacy. I am pretty sure that it is ok to store the information, just not release it to the public without consent.

[snowe2010]

Also, these schedules aren't set in stone. So technically we aren't even releasing student information. It's just a schedule builder, not creating the actual schedule the student is going to have. And even if it does qualify as being student information, when they create the schedule it is explicit in stating that it is publicly viewable. I think that complies with FERPA.

[snowe2010]

Also on that topic, we aren't using students accounts. They can create the account using whatever username, first name, and last name that they want. Not sure if that could become a problem then, because somebody could always have the same name as someone else or could even pretend to be someone else. I think we might just need some sort of disclaimer stating that the schedules displayed do not indicate a person's actual schedule.

[ybakos]

Definitely consider FERPA compliance a design constraint, and come up with a creative solution. (Mine was a short-path suggestion.)

Ask yourself: when miner.mines.edu gets hacked, all the user data is exposed, and a student decides to sue (because under FERPA, you can), would you be comfortable being liable?

[ybakos]

Be absolutely certain to educate yourself about FERPA (which is more than reading Web pages) before asserting that SM is FERPA-compliant. (Hint: it's not.)

[ybakos]

@pianohacker That's an important point you make. But what happens when SM is hacked, and that schedule data is exposed?

[sgonzalez]

Would simply providing a disclaimer when signing up work? Stating that we are not responsible for hacked data etc. and all student schedules are not final.

[muff1nman]

Be absolutely certain to educate yourself about FERPA (which is more than reading Web pages) before asserting that SM is FERPA-compliant. (Hint: it's not.)

I browsed a couple websites :P and found these excerpts from this page http://www2.ed.gov/policy/gen/guid/fpco/ferpa/students.html that may be helpful:

Under FERPA, a school may not generally disclose personally identifiable information from an eligible student's education records to a third party unless the eligible student has provided written consent. However, there are a number of exceptions to FERPA's prohibition against non-consensual disclosure of personally identifiable information from education records. Under these exceptions, schools are permitted to disclose personally identifiable information from education records without consent, though they are not required to do so. Following is general information regarding some of these exceptions.

So it would be my understanding that we could require "written constent" in the form of a website agreement (along the lines of what @sgonzalez suggested) when using the site.

Another exception permits a school to non-consensually disclose personally identifiable information from a student's education records when such information has been appropriately designated as directory information. "Directory information" is defined as information contained in the education records of a student that would not generally be considered harmful or an invasion of privacy if disclosed. Directory information could include information such as the student's name, address, e-mail address, telephone listing, photograph, date and place of birth, major field of study, participation in officially recognized activities and sports, weight and height of members of athletic teams, dates of attendance, degrees and awards received, the most recent previous educational agency or institution attended, grade level or year (such as freshman or junior), and enrollment status (undergraduate or graduate; full-time or part-time).

Although not quite as clear-cut as the above, it could be argued that the information is "directory information" and it would be argued that the information would not be harmful if disclosed.

In either case, Mines has a lawyer that I'm sure could help us out in this regard. (I don't know how to get a hold of him/her but think it would be a smart idea)

[snowe2010]

So pretty much exactly what I said above about having a disclaimer stating that the person's schedule is not in any way confidential information because it is not a reflection of the students actual schedule, only one that they want.. And because the students are able to change their name and email, all except username, I don't think that the information supplied by the miner is even directory information. It does not supply information about a specific student because the person that signed up could be anyone.

[ybakos]

All excellent ideas.

[snowe2010]

So I found several things reading through about FERPA. From the main page discussing what is and is not covered under FERPA

FERPA generally prohibits the improper disclosure of personally identifiable information derived from education records. Thus, information that an official obtained through personal knowledge or observation, or has heard orally from others, is not protected under FERPA. This remains applicable even if education records exist which contain that information, unless the official had an official role in making a determination that generated a protected education record.

The definition of education records from page 1 of this pdf:

The eligible student has the right to have access to his or her education records, the right to seek to have the records amended, the right to have control over the disclosure of personally identifiable information from the records (except in certain circumstances specified in the FERPA regulations, some of which are discussed below), and the right to file a complaint with the Department. The term "education records" is defined as those records that contain information directly related to a student and which are maintained by an educational agency or institution or by a party acting for the agency or institution

Therefore we are maintaining education records, so FERPA does apply to us.

Therefore we need permission to release this information. As @muff1nman stated above, according to FERPA some things might qualify as "Directory information." Sadly, the schedule does not seem to fall under this though the name and email do. Each college can also define their own definition of directory information, though it seems that Mines has kept with the original definition.

Therefore I suggest that we make it not publicly viewable by default, and then ask for written consent from the student to show their schedule if they want. Thankfully, the internet has its own laws for written information and according to Mines all we would need is a disclaimer, a signature (which legally can be a checkbox), and a submission of the date.

To reiterate, and for those who just want a TL;DR:

"education records" is defined as those records that contain information directly related to a student and which are maintained by...a party acting for the agency or institution

We need permission to release this information, except that which complies with "Directory Information"

According to Mines, "Directory Information" is

• Student Name.
• Student address (including local mailing, permanent addresses).
• Telephone Number (including local and permanent).
• Date of birth.
• Major field of study.
• Dates of attendance.
• Enrollment status (e.g., full time or part-time student status).
• Degrees Awarded.
• Last school attended.
• Participation in officially recognized activities and sports.
• Class (Freshman, Sophomore, etc.).
• Academic honors.

notice the absence of email in the Mines definition. That is because it is disclosed in the student directory under the Academic Computing and Network Services policies somewhere. I actually couldn't find where

Because we are releasing schedules, even though they are not actual schedules, they could reflect information that the student does not want released. We need a FERPA disclaimer stating that if the user chooses to disclose his true name and email, the information can be freely disclosed under FERPA and we need the setting for public viewing of a schedule to default to false.

If the user wants to disclose that information then we need to provide a disclaimer stating the records to be released (schedule), the purpose of the disclosure (seeing who has the same classes as you?), and the party or parties to whom the disclosure will be made (users of miner.mines.edu). Then we must obtain their signature, which because we are obtaining electronically could consist soley of a checkbox and the date of the signature.

If I missed anything please let me know.

[ybakos]

Awesome. But there's also the general precedent that if the app continues to store schedules, this is PII (personally identifiable information) in that it discloses a user's location. And, it doesn't matter if the schedule is hypothetical or not.

This situation makes for a great case study in information assurance, privacy, security and risk management issues. These are things that an IT curriculum addresses, which we don't have at Mines, so have fun exploring this. I encourage you to get deep and make a choice.

Treat it as a design constraint: what's the best solution to the problem?

Let's direct this thread toward suggesting specific solutions. Eg, the ideal would be "We'll just make SM so secure it's impossible for any PII to escape the system, so we'll never be in violation of any law." Failing that, what else might we do?

[snowe2010]

Oh so are we not following Brandon's precedent of deleting the schedules at the end of the semester or am I misunderstanding what you are stating?

[ybakos]

I'm only stating that the team needs to think about a solution to the constraint that doesn't sacrifice SM's usefulness.

[aashah]

How is it done for trailhead? Or are those circumstances different?

[ybakos]

@aashah: I think you're missing the point here. If TH were exploited, and student information were to be taken, the university would be in violation of FERPA and could be sued by a student.

This issue is not about "not storing personal information." It's about risk management.

[pianohacker]

To poke an old bug as we move forward with a rewrite, how far outside the university's purview do we need to move to not be liable under FERPA? Is anything we do liable? Do these restrictions not apply if we do not use the school's hosting, and use acmX's recently acquired VPS (which is not under .mines.edu) instead?

Poking Yong specifically, since he took the brunt of this and is the most familiar with the legal shenanigans involved.

[ybakos]

Only federally funded institutions are required to abide by FERPA. Since you're moving the hosting of SM to an external server, and because SM isn't developed by the university, it would seem that you no longer have to abide by FERPA. However, law is a murky thing, and I am no lawyer. So, I can imagine how someone may hold the university liable for students in a student group (funded by the university) who create a system that violates FERPA, regardless of where the data is physically hosted.

I would keep this requirement as a design constraint - there is a solution.

[ybakos]

In other words, what I would do is create SM such that:

• it is a client-side application that makes http requests for data to authenticate against SM-server, and to request course information
• stores all schedule stuff client-side In the end, you have SM-server, which provides authentication and exposes a web service to sanely request course data; and SM-client, which is a JS (or other! mobile, etc) application.

In either case, I myself would design SM such that it consists of multiple "apps," one of which is a server-side app that just presents sane endpoints for working with course data. That way, this SM-server component stays fairly unchanged, regardless of the client used to access the data; and allows you to create a wide variety of clients that are completely decoupled from the drama of course data from the registrar.

[ybakos]

This would also allow you to create a client-side feature that allows the student to publish their schedule to a third app server, say, SM-sharing. "Namely, students can only work on their schedule from one computer, and lose any ability to compare schedules with friends." This would allow client-side retrieval of schedules from multiple clients, sharing, etc, and also give you the opportunity to present the user with a "I understand that I'm allowing my shit to be published and won't hold you liable for FERPA crap" when hitting a "share" button.