User Disguises Project
| User Disguises | |
|---|---|
| Project state | Developing |
| Tracker issue | MDL-1071 |
| Discussion | https://moodle.org/mod/forum/discuss.php?d=328771 |
| Assignee | Andrew Nicols |
User disguise within the Moodle Forum
Working notes
Use-cases
Asking questions without fear of embarrassment
To allow students to ask "silly" questions of the teacher without fear of embarrassment in front of their peers.
Day-to-day interaction with the forum should be anonymised, but it should be possible for an authorised person to retrieve the identity for safeguarding purposes.
This is key to drawing out quiet or sensitive students in a high-school environment.
Games
Game playing in a forum - for example, playing twenty-questions; or Who am I?.
Reduce inhibition in interaction
Anonymised interaction allows for better, more-detailed, less-inhibited interaction, which increases the rate of knowledge growth.
Role playing
Allow students to take part in an activity with a different persona, or taking part as a person with a specific role for a role-play exercise.
The user’s real identity may, or may not be displayed alongside the persona.
Links to the student’s real profile may be displayed when their real identity is shown.
Students may be graded on their participation (regardless of their real identity).
Real identity may be revealed to all users after the activity has ended, either manually, or on timed-basis.
Disguised discussion for questions and feedback
Allow users to take part wearing a disguise in order to provide feedback to tutors on content; for a staff-student committee; or to ask questions without fear of embarrassment, etc.
Some users note that this is particularly important for students from some cultures.
The user’s real identity is generally hidden and never revealed.
An alias may, or may not be used so as to help understand reply threading within the forum
Students are generally not graded on their participation within the course. (Not just a fixed string "Anonymous").
Activity should not be logged to the Moodle log, or should be logged using it’s anonymous mode.
It should not be possible to turn off the disguise once it has been enabled.
Optional disguise
Allow users to take part wearing a disguise within a forum when required - this may be an individual forum post.
This may be used in order to ask a question or to review a peer’s work with some degree of privacy.
The user’s real identity is hidden for these locations
Review of options
Lock disguise
Field type: Checkbox.
Available options: Yes; No.
Default value: No.
Whether to allow disguises to be disabled at a later date after user content has been entered.
Once enabled, this setting cannot be disabled by ordinary users.
This value may lock other anonymity settings.
Users holding the moodle/disguise:disablelock capability may disable the lock. This ensures that administrators may revert accidental setting of this option.
Also display real identity
Field type: Dropdown select.
Available options: Yes; Restricted; No.
Default value: No.
Which users, if any, will be able to see the user’s normal identity alongside their disguise in every-day use.
In some cases (e.g. role play), it may be desirable to show the user’s real identity alongside their disguise.
The value of this setting will be influenced by the Lock disguise setting.
It may be preferential to display the value of this setting to users when they author content.
The Restricted value will allow all users with the moodle/disguise:showidentity capability to see the normal identity alongside their disguise.
Disable disguises from
Field type: Optional Date/Time picker.
Available options: Date/Time.
Default value: Disabled.
An optional date from which point the normal identity of all users will be revealed to every user.
The value of this setting will be influenced by the Lock disguise setting.
It may be preferential to display the value of this setting to users when they author content.
Log user actions anonymously
Field type: Checkbox.
Available options: Yes; No.
Default value: Yes.
Whether actions should be stored using the standard Moodle Logging. (Note, this does not apply to any additional logging at the web server levels).
If the tutor enables logging, it may be possible to determine users from one another.
The value of this setting will be influenced by the Lock disguise setting.
It may be preferential to display the value of this setting to users when they author content.
Disguise
Type: Dropdown select.
Available options: Disabled + Plugin-dependent.
Default value: Disabled.
The type of disguise to use.
The value of this setting will be influenced by the Lock disguise setting.
This is likely to be a pluggable system which exposes common, or custom, disguise types.
These may include options such as:
- fixed string - e.g. "Anonymous"
- user-chosen - i.e. The user must enter a free-text pseudonym when first entering the activity. This may allow/prevent changes to the pseudonym; and it may prevent name collisions.
- user selected - i.e. The user must select from a list of tutor-defined roles
- tutor-assigned - i.e. A tutor assigns a disguise to each user before that user may take part.
- randomly allocated - i.e. A tutor provides a list of works and these are used to generate a disguise for that user.
These plugins may define additional settings, or User Interface features.
Capabilities
In order for disguises to work well, several new capabilities will be required.
moodle/disguise:disablelock
Type: Write
Role archetypes with this role: Manager
As discussed in the "Lock disguise" setting, teachers will not ordinarily be able to disable the disguise lock in order to disable the functionality, or to make changes which may allow them to reveal an identity.
In certain circumstances it may be a requirement that administrators or managers are able to disable the lock where it has been inadvertently applied.
This should normally be a setting only provided to the administrator role, and possibly with a capability risk attached; but it may be appropriate to also apply it to the manager role.
moodle/disguise:revealidentity
Type: Read
Role archetypes with this role: Manager
In some situations, it may be beneficial for certain roles to be able to temporarily reveal the identity of some users for a brief period. This can be achieved adding a menu item to the admin settings block to toggle the functionality temporarily.
This should normally be a setting only provided to the administrator role, and possibly with a capability risk attached; but it may be appropriate to also apply it to the manager role.
This capability should not normally be applied to the editingteacher or teacher roles as it diminishes the benefit of the function.
moodle/disguise:showidentity
Type: Read
Role archetypes with this role: Manager, Editingteacher, Teacher
Similar to the revealidentity capability, except this capability applies to a greater subsection of users, and when the Reveal identity setting is set to Restricted.
This capability should be granted to teacher, editingteacher, and manager roles as standard.
Other
Plugins which support disguises may also define their own capabilities. For example, the forum may define moodle/forum:usedisguise which will be used to determine if a user may post with a disguise when disguises are optional.
Other notes
In some cases (e.g. forum) e-mails are still sent when wearing a disguise. This factor needs to be considered and, most likely, the no-reply user used instead. Where reply-to-email is an option, the reply address should not be generated if the disguise requires user setup which has not yet been completed.
Recent activity block
This block should already be correct, but it is worth adding testing scenarios for this specific case to ensure it does not lead to an inadvertent reveal of the disguise.
Search and Global search
Care should be taken to ensure that disguises are not revealed when searching for user content.
RSS Feeds
Care should be taken to ensure that disguises are not revealed when viewing syndicated feeds.
Web Services / Mobile app
Care should be taken to ensure that disguises are not revealed when data is obtained using web services, or the mobile application.
User Reports / User Activity reports
Care should be taken to ensure that disguises are not revealed when viewing user reports.
Forum post counts
Care should be taken to ensure that disguises are not revealed by the inclusion of posts in the count of user posts within the forum.
Activity / Course completion
Care should be taken to ensure that disguises are not revealed by the activity or course completion features.
Caveats
There are many ways in which a user identity may be revealed. This solution does not attempt to provide anonymity to Moodle, or to address every issue and does not presume to do so.
There are many places in which the user identity can be revealed. This includes, but is not limited to:
- web server logs - this is beyond the control of Moodle;
- database inspection - content must still be associated with a Moodle user. It is beyond scope to orphan data in this kind of fashion and the use-case is likely too remote;
- logs leading up to an event.
Proposed implementation
(To be confirmed) Add new column (disguiseid) to the context table.
A new helper
A new disguise interface and/or abstract class for disguise types to implement
New functions in the core_user class for fullname, pixicon, profileurl
New module + block level supports constants
(To be confirmed with Mobile team) Update WS to use the new fullname/etc. functions
context->disguise as a magic getter based on the context->disguiseid with caching
Current forms of disguise and/or anonymity
ForumNG (Open University)
Who can post anonymously:
- Forum moderators / tutors
Supports use-cases:
Positives:
Negatives:
- Only a very limited number of users can post anonymously
Advanced Forums
Who can post anonymously:
- Anyone
Supports use-cases:
Positives:
Negatives:
- Loss of threading (you cannot tell which user is which)
