FERPA regulates access to student data.

FERPA has different provisions for students of different ages. Skilling was designed with FERPA in mind, but only the regulations that apply to students 18 and older.

The privacy requirements apply not just to live data. They also apply to historical data that is exported for analysis. Skilling takes both cases into account.

Drupal has a typical permissions system to control data access. Users are given roles, like Student, and Instructor. Role have permissions. For example, students can create submissions. Instructors can edit calendar events. Both can view lessons.

Skilling extends this system in two main ways. First, data access takes enrollments into account.

Should instructors have access to all student data? No, not if you take a strict view of privacy.

Suppose there are two classes, 1 and 2. Instructor 1 runs class 1. Student 1 is in class 1. Instructor 2 runs class 2. Student 2 is in class 2.

Strict privacy rules would say that instructor 1 should not be able to access student 2's data, because student 2 is not in instructor 1's class. Similarly, instructor 2 should not be able to see student 1's data.

Skilling enforces strict privacy rules. It does so by adding enrollment checks. The rule for this case is something like:

Situation: user 1 wants to access user 2's data

Allow access if:

- User 1 has the Instructor role.
- User 2 has the Student role.
- User 1 and user 2 are both enrolled in a common class.
- User 1 has the Instructor role in that class.
- User 2 has the Student role in that class.

There's more about rule implementation below.

An entity is something you store data about. A user is an entity, a lesson is an entity, an exercise submission is an entity, and so on. (An entity is a little different in Drupal, but let's go with the simple definition.) Entities have fields, like first name and last name for user, title for lesson, and exercise for exercise submission.

Drupal permissions tend to be at the entity level. If you have access to any of the fields of an entity, then generally you have access to them all. So, if you can see the title field of a lesson, you can see all of the other fields of the lesson.

This isn't enough if you want some fields to be restricted to some users. For example, it would be convenient if authors could add private notes to lessons, perhaps ideas on how to improve lessons. However, they might not want students to be able to see the notes. Perhaps instructors can see the notes, but not change them.

Skilling adds field-level restrictions like this. The rules are custom coded to match Skilling's single purpose: making skills courses.

Skilling keeps data about student behavior and performance. The data can help authors improve courses. For example, if most students thought that an exercise was easy, it might not be a good use of their time.

Privacy needs to be protected, however. Only administrators can export data. If authors want data for analysis, they have to request it from another person. Organizational policies come into play at this point.

Further, information that identifies students, like names and email addresses, is stripped before data is exported. Students are identified by an id number in data exports. This lets authors and researchers check, for example, the relationship between procrastination and performance. However, the ids are meaningless internal numbers. They don't match anything in the real world.

Auditors differentiate between around-the-system and through-the-system auditing. Around-the-system treats software as a black box. Auditors test inputs and outputs, but don't look inside the code. Through-the-system means that the software is open to internal inspection. For example, auditors can find the source code that implements privacy policies, and inspect it for themselves.

Drupal is general-purpose. It can be used for thousands of different tasks. Generality is achieved by abstraction. So, not only is the code complex, the relationship between code and data is difficult to understand without special training. Even finding the code that controls access to a field can be challenging.

What does mean? Through-the-system auditing is not practical for auditors without training in Drupal development.

Skilling is not general purpose. It helps build and run skills courses. That all it does.

Skilling's security code is not general. It is centralized, and specific to Skilling's architecture. Here is a code fragment controlling access to the notes field of lessons:

protected function isLessonFieldAccess($operation, $fieldName) {
  // Deny access by default.
  $allow = FALSE;
  ...
  if ($operation === SkillingConstants::VIEW_OPERATION) {
    switch ($fieldName) {
      // Viewing a lesson.
      ...
      case SkillingConstants::FIELD_NOTES:
        // Admins, authors, reviewers, instructors, and graders
        // can see notes of lessons.
        $allow = $admin || $author || $reviewer || $instructor || $grader;
        break;

Even if you can't program, you should be able to follow the code to some extent. Hint: || means "or."

This is not elegant code. It is, however, easy to understand, and easy to test. Auditors can run the code themselves. They can add breakpoints where they want, and see exactly how privacy policies are implemented.

Bottom line: Skilling privacy (and security) code is open to both around-the-system, and through-the-system auditing.

The downside of this approach is loss of flexibility. Administrators can't expose any data they want, without having the source code changed.

There are exceptions to this policy. Skilling allows data customization that could help courses be more effective, or better suit an institution's administrative preferences. For example, an administrator could add a field showing whether a student has a disability. Authors could test that field in lessons, perhaps showing extra content to those students. This would require no programming. In general, however, Skilling's privacy rules are hard-coded.

That isn't to say there is no flexibility. If the community has use cases needing different policies, that is open to discussion. As long as new policies are justified, implemented well, and documented well, they can be adopted.