With Skilling, you won’t need a guard goat. Though if you want one, by all means. Goats are cool.

Skilling is into Extreme Privacy (EP) (OK, I made up EP, but still, Skilling does it).

FERPA is the most important education data privacy legislation in the US. Skilling was designed with FERPA in mind, but only the regulations that apply to students 18 and older. The rules for children are more complicated.

How does Skilling implement privacy? Let’s look at some issues.

Guard goat

Extra permission restrictions

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.

That’s fine for most uses, but is it enough for us? For example:


Well, of course. Without access, how do I do my job?

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.


OK, you tricked me.

Not at all! You have to think about many different cases, and plan accordingly.

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

Situation: user 1 (instructor) wants to access user 2’s (student) exercise submissions.

Allow access if all of the following are true:

    • 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.

Skilling has a bunch of rules like this.

Here’s another one: should graders know who is submitting the exercises they are grading? That’s been standard practice for decades (centuries?). Instructors have graders, who mark student homework, and record grades in a grade book. They have to know who turned in the homework, so they can record grades. Right?


You want me to say, “Of course, they have to know!”

Ha! I’m not falling for that again.

OK, you’re onto my tricks. With automation, it’s possible to have graders grade, without knowing where each submission came from. This is from the grading system:

Student names withheld

You might not want to withhold student names. It depends on your situation, and the relationship you want between graders and students. Withholding names is the default, but you can change that in configuration.

Field-level privacy

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.

Privacy code is easy to audit

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. Or Banner development, or SalesForce, or whatever. Almost all auditing is around-the-system.

Unlike Drupal, 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. If the code can be open to inspection, if it’s written to be.

Here is a code fragment controlling access to the notes field of lessons:


Hmm… looks like… no, student isn’t in that list.

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


I’m not a programmer. Why show me this?

Give it a chance. Read the code, and see if you can figure out whether students have view access to the notes field of lessons. Hint: || means “or.”

Right! That’s auditing through the system. The rules are explicit in code.

This is not elegant code. It is, however, easy to understand, and easy to test. Auditors see exactly how privacy policies are implemented. They can run the code themselves. They can add breakpoints where they want. Remember, it’s open source, so auditors have the actual source code, not just the compiled result.

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. 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.

These policies are open to change. If the community has use cases needing different policies, let’s talk about it. As long as new policies are justified, implemented well, and documented well, they can be adopted.

Automated tests

Security stamp of approval

So far, we’ve talked about privacy, mainly. What about security?

CSRF and XSS prevention, DoS mitigation, SQL injection defense… they are all built-in to Drupal. You can read more about Drupal security.

Adela, what’s the most common reason that sites are hacked?


Hmm… Don’t know, but I’m guessing bad programming?

A reasonable guess, but that’s not it.

When a security risk is discovered in software, the developers issue a patch, a fix to the code. Many administrators don’t apply those patches. They just let the software get more and more out of date. Sooner or later… hacky hacky hackity hack.

Drupal has a security team. It issues patches, and lets people know about them. You can apply patches easily, if you’ve installed Drupal in the way recommended in Skilling’s installation documentation. Basically, type in one command to update a module, or Drupal core. That command is explained in Skilling’s maintenance documentation.

Skilling uses Drupal’s existing security mechanisms as much as possible. For example, when students submit exercise solutions, they use Drupal’s form system. The form system has built-in security checks. For instance, Drupal forms include tokens, protecting against CSRF attacks.

Some parts of Skilling use client-side Ajax code that is not a standard part of Drupal. For example, the grading interface is implemented in Vue, a framework for making rich client-side JavaScript applications. However, every Skilling Ajax transaction runs against a server controller that invokes Drupal services for token validation, etc.

Because of FERPA, Skilling has some extra requirements beyond most Drupal installations. Skilling’s installation documentation explains the extra requirements.

Apart from issuing patches, Drupal’s security team inspect modules, that is, Drupal extensions, like Skilling. Skilling has the security team’s seal of approval, as you can see on Skilling’s Drupal project page. It looks like this:

Seal of approval

History, privacy, and GDPR

GDPR is the EU’s rule set about data privacy. Retro-fitting software for GDPR compliance can be expensive, and manual compliance… let’s not even go there.

Skilling was written with GDPR compliance in mind. See history for deets.