Privacy API

Note: This page is a work-in-progress. Feedback and suggested improvements are welcome. Please join the discussion on moodle.org or use the page comments.

Overview

The Privacy API has been implemented to help report the use of data within Moodle Plugins as part of General Data Protection Regulations, and will help admins comply with key user rights such as:

• request information on the types of personal data held, instances of such data and retention policy for each
• their right to access their data ("Right of Access") *and* to have their data in a machine readable format ("Right to data portability")
• deletion of personal data ("Right to erasure" / "right to be forgotten")

It shall be expected that *all* plugins will require to report their use of and storing of personal data as part of their inclusion in the Moodle Plugins Database.

All plugins will be expected to implement a privacy provider class. This class will provide details on:

• personal data being held by the plugin and where it is held.

Architecture

The Privacy API comprises 3 components within the core_privacy subsystem:

Metadata providers

A set of PHP interfaces to be implemented by components for that component to describe the kind of data that it stores, and the purpose for its storage

Request providers

A set of PHP interfaces to be implemented by components to allow that component to act upon user requests such as the Right to be Forgotten, and a Subject Access Request

Manager

A concrete class used to bridge components which implement the providers with tools which request their data.

Plugins that do not hold personal data

If a plugin does not hold any personal data it should implement a provider class that implements the core_privacy\local\metadata\null_provider.

Some examples of plugin types which might fit this criteria include themes, blocks, filters, editor plugins, etc, however plugins which cause data to be stored elsewhere in Moodle (e.g. via a subsystem call) are considered to store data.

get_reason(): string

This function should return a string that explains why the plugin is asserting that it holds no personal data.

Example

One examples of a plugin which does not store any data would be the Calendar month block which just displays a view of the user’s calendar. It does not store any data itself.

block/calendar_month/classes/privacy/provider.php // …

namespace block_calendar_month\privacy;

class provider implements

   # This plugin does not store any personal user data.
   \core_privacy\local\metadata\null_provider

{

   /**
    * Get the language string identifier with the component's language
    * file to explain why this plugin stores no data.
    *
    * @return  string
    */
   public static function get_reason() : string {
       return 'privacy:null_reason';
   }

}

block/calendar_month/lang/en/block_calendar_month,php $string['privacy:null_reason'] = 'The calendar month block displays information from the Calendar, but does not effect or store any data itself. All changes are made via the Calendar.';

Using Privacy API

Every plugin should define a privacy provider class. At minimum this will describe the data held in the plugin, and implement means for servicing Subject Access Requests (SARs) and Deletion of User Data.

Data is described via a metadata provider, and it is both exported and deleted via an implementation of a request provider.

This must:

• be named provider,
• be in a <plugin>\classes\privacy\provider.php file.
• be in the "<pluginname>\privacy" namespace
• implement core_privacy\local\metadata\provider or core_privacy\local\metadata\null_provider
• implement core_privacy\local\request\plugin\provider

namespace mod_peerassessment\privacy;

class provider implements

   \core_privacy\local\metadata\provider,
   \core_privacy\local\request\plugin\provider

{ ... }

Reporting Meta Data

get_metadata(collection $collection): collection

This function allows you describe the personal data that is held and where it is held in Moodle.

Moodle currently has 6 areas where data can be held:

• database tables
• user preferences
• subsystems
• other Moodle plugins
• external locations

A description for user data held in these areas is added to a metadata collection via add_<type>() or link_<type>() methods. $collection->add_database_table($name, $fields, $summary); $collection->add_user_preference($name, $summary); $collection->link_subsystem($name, $summary); $collection->link_external_location($name, $fields, $summary) $collection->link_plugintype($name, $summary);

Describing database tables

You should describe each database table and each field within that table that holds user data.

Example

mod/forum/classes/privacy/provider.php public static function get_metadata(collection $collection) : collection {

   $collection->add_database_table(
       'forum_discussion_subs',
        [
           'userid' => 'privacy:metadata:forum_discussion_subs:userid',
           'discussionid' => 'privacy:metadata:forum_discussion_subs:discussionid',
           'preference' => 'privacy:metadata:forum_discussion_subs:preference',

        ],
       'privacy:metadata:forum_discussion_subs'
   );

   return $collection;

}

mod/forum/lang/en/forum.php

$string['privacy:metadata:forum_discussion_subs'] = 'Information about the subscriptions to individual forum discussions. This includes when a user has chosen to subscribe to a discussion, or to unsubscribe from one where they would otherwise be subscribed.'; $string['privacy:metadata:forum_discussion_subs:userid'] = 'The ID of the user with this subscription preference.'; $string['privacy:metadata:forum_discussion_subs:discussionid'] = 'The ID of the discussion that was subscribed to.'; $string['privacy:metadata:forum_discussion_subs:preference'] = 'The start time of the subscription.';

Site-Wide User Preferences

Each plugin should be aware of how it handles its own preferences.

Where there are multiple instances of a user-preference (e.g. tool_usertours_tour_completion_time_2) only the general name needs to be indicated.

Any plugin providing user preferences must also implement the core_privacy\local\request\user_preference_provider interface, and the export_user_preferences(int $userid) function.

Exporting User Data

To support the export of user data for Subject Access Requests, the plugin provider class should implement \core_privacy\local\request\plugin\provider