Voluntarily provides the following functions for people
Read web pages.
Browse information about provider organisations and registered schools
Browse and search opportunity listings
View small picture and name of people providing opportunities.
· Register and sign in using username, password, social media or enterprise credentials.
· Maintain a personal profile page
· Browse opportunity listings
· Express interest in, be invited to, and commit to opportunity listings.
· Access contact details (email, phone) of person organizing the opportunity to which they are invited.
· Complete activities and training and receive microcredentials (badges) for same.
· View the personal profiles of other volunteers including their listed skills and badges.
· Follow or join organisations.
· Create and edit activity listings.
· Link and attach resources required for activity listings
· Define assessment requirements and issue badges to people meeting specified criteria.
· Create and edit opportunity listings
· Link and attach resources required for opportunity listings
· Review profile, skills and badges of people expressing interest in an opportunity
· Accept and invite people to commit to the opportunity
· Access contact details – email and phone number of interested parties.
· Edit organisation profile
· Access listings and contact details of followers and members (email only)
· Create and issue badges
· IP address and other platform information collected in the course of providing the web service. Retained by Google Analytics and system logs.
· Personal Profile information entered by user (* required)
Field | Description | Use | Required |
name | full name - longform | in formal communications | required |
validated email address | for validation as a human and communications | required | |
nickname | short form name how person would like to be addressed | general use on the site e.g 'nickname' is interested in this opportunity | optional |
about | Anything the person wants to tell others about themselves. formatted text | Informing others, used to select recommended volunteering opportunities | optional |
location | region or city | used to recommend opportunities by location | optional |
phone | Contact phone number | made available to organisers when person is committed to an event | optional |
pronoun | how to address someone appropriately - subject, object and posessive forms : them/they/their | to ensure communications are rendered using appropriate terms | optional |
language | preferred language code (en, mi, fr etc) | to provide appropriate translations | optional |
imgUrl | URL of image representing the person | Represents the person in various listings pages | optional |
website | personal website URL | social network | optional |
Facebook link | Allows share to facebook function when participating in an activity | optional | |
twitter handle | Allows share to twitter function when participating in an activity | optional | |
status | active, inactive or on hold | inactive and hold people are not available on the site for opportunities | optional |
dateAdded | when person first joined the site | administrative tracking | optional |
tags | list of words describing skills, interests etc. | matching people to appropriate opportunities | optional |
We record the relationship of a person with an opportunity through a lifecycle of being interested, invited, committed and finally having attended or not attended the event.
Before the event only the organisor ( and admins) is able to see the list of interested people. At any time the person can withdraw interest or commitment to an event.
After an event actual attendance is recorded for downstream reporting and to improve the effectiveness of the platform. This information is available to people on their personal history page.
Each badge represents an award recognizing that the person has met specific criteria. Badges are illustrated with a small icon and a link to the badge description which may include the purpose of the badge, when issued, and a citation regarding the achievement or evidence provided to receive the badge.
Badges are portable and may be imported and exported from the platform to other systems including learning management systems, and social media sites.
Badges are intended to be made public and shared. However, badge receivers will be able to suppress the fact that they have a badge if they wish.
Badges fall into the following categories:
· System administration.
· Requirements and Skills
· Achievements and accomplishments
Badges are used instead of status flags to indicate that a person has a certain status on the platform. These include:
· Email validation – confirmation that the person has reply access to the email address they have provided.
· Completion of personal profile – this indicates that a person has provided information on skills and interests etc. so that an organizer can assess their suitability for an activity. Note website and social media links are not required for profile completion.
· Identity validation – this indicates that the person has been validated as a ‘real person’ through various mechanisms that may include ‘RealMe’, viewing of passport or drivers licence. Note: identity validation is a pre-requisite for being able to request a Police vetting process.
· School Ready – this indicates that a person has completed preparatory training for volunteering in a school and has a passed police vetting. Opportunity and Activity providers may require volunteers to have the school ready badge prior to attending an event or working with children.
Note that absence of the badge does not reveal whether a person has failed a police vet as other steps such as email & identity validation, training etc. are also required.
These badges are used to indicate that a person meets specific requirements for an activity or has been assessed to have specific skills. Providers may require at least one person attending to meet these requirements.
These may include:
· First Aider – person has a current first aid certificate
· Organisation specific training – such as TEC or OMGTech onboarding
· Language skills – competency in Te Reo Maori, NZSL, Chinese etc.
· Specific Technical or educational competency
These badges are used to encourage participation and reputation in volunteering by recognizing attendance, special effort, key capabilities etc.
These may include:
· First time school volunteer
· Regular volunteer
· Going the extra mile – for volunteering further from home
· Volunteering where its most needed.
Provide details of any information involved in the change that is likely to be viewed as sensitive by the individuals that it relates to.
Most of the information stored in the system is both non sensitive and under the control of the person in question as to how much the share about themselves.
In the personal profile the telephone number and social media links are probably the most sensitive. Telephone number is not made publicly available and is only shared with people attending an event as a necessary communications tool. Social media links are shown on a person’s profile but are optional.
For Badges the most sensitive information would be whether the person has completed and failed police vetting. This specific information is not stored but is a requirement for a school ready badge that includes other steps.
In obtaining police vetting a more specific set of personal identity information is required. E.g full address, date of birth etc. This is collected as part of the vetting process through a form on the platform which collects data that is not stored in the platform. Instead it is transmitted to an API which results in a formal police vetting request. Once the information has been submitted it is not retained. Once the process has completed the badge is issued.
What information are we collecting directly from the individual involved? For this information, how have we made sure that the individual understands what we are collecting and the purpose that we are collecting it for?
Most information is collected from the individual concerned and is available to them to be updated, removed or corrected.
Profile page forms give details on the purpose of each piece of information requested with further details in associated help.
What information is Voluntarily collecting from other third party sources?
List the source(s) and outline why it is being collected from the source and what consent / authorisation we have to do so.
· A teacher on the system may enter their teacher ID and we may autofill some information that can be obtained from this ID
· When an organisation, acting as a volunteer provider, has integrated into our authentication system so that their staff can sign in directly using their enterprise credentials, we will obtain initial values for Full Name, Nickname, Image and potentially role and skills from the enterprise source. People are then prompted to correct this information on their profile.
· When a person signs into the platform using a social media account such as Facebook, Twitter, GitHub etc. we will obtain initial values for Full Name, Nickname, Image and potentially role and skills from the social media source. People are then prompted to correct this information on their profile.
· If permitted by the person we may obtain initial values for skills and interests from sources such as LinkedIn.
· If permitted by the person we may import badges and credentials from alternative sources such as a learning management system.
· Some organisations may choose to bulk register their members by uploading a table of information. This will contain only basic account information (name, email, role, image)
Provide details of the system / location where information will be stored, including whether it will be hosted in the cloud. If the information will be stored outside the TEC environment, provide details of where and what contractual arrangements are in place.
This is where we need to talk about voluntarily, their security processes and what contractual arrangements are in place around this.
The voluntarily platform is realized through the following components
Source code
Integration and deployment tools
Cloud service accounts and configuration
Secrets
Run time instances
Databases associated with the run time instances.
Voluntarily is an Open Source platform under the Mozilla Public Licence (https://opensource.org/licenses/MPL-2.0)
This means that all source code including management and deployment scripts are available for public inspection.
Voluntarily source code is currently stored on Github.com at: https://github.com/voluntarily/vly2
The platform is based on the following key technologies:
· Node – javascript runtime library
· Express – Web service library
· React – Web UI framework
· MongoDB – document management database
Voluntarily platform makes use of the following integration and deployment tools (CI/CD)
Cirrus CI https://cirrus-ci.com/ - This tool runs automated test coverage
Docker https://www.docker.com/ - container platform
Voluntarily platforms are currently hosted on Amazon Web Services (AWS) using the following services
· Elastic Container Service (ECS) – Fargate
· Elastic Container Repository (ECR)
· Load balancer
· CloudWatch – status monitoring and logging
· Certificate management
· CloudFormation – scripts to build the deployed instances and services.
· Simple Email Service (SES)
· Simple Storage Service (S3) – used to hold uploaded images and attachments.
It is a possibility that the production deployment may move to Microsoft Azure. There it will use a similar set of container and repository services.
For identity management, user registration, sign in, social sign in, and enterprise sign in we use the identity services provided by Auth0.com.
Auth0 Data Privacy statement https://auth0.com/docs/compliance
The personal data stored in Auth0 is used only for the purposes of providing its services, namely authenticating users
Secrets are maintained for the following:
· AWS account credentials used for site construction and deployment.
· AWS account credentials used to access run time services such as email (SES).
· AWS account credentials used for account management and billing
· Atlas Cloud account credentials used to access the MongoDB database.
Primary values for these secrets are held in a LastPass password manager.
Run time values for these secrets are stored as encrypted strings in the build scripts and then injected into the docker containers during construction by the CI system.
Voluntarily will maintain and operate the following run time instances of the platform
Alpha.voluntarily.nz – used as a staging and test site for changes
· Beta.voluntarily.nz – used for field trials and beta testing
· Gamma.voluntarily.nz – used for performance and load testing
· Voluntarily.nz – NZ production site.
The above instances are hosted in Sydney with the exception of alpha which is hosted in Singapore (will move to Sydney eventually)
All information used on the platform not in the source code, or secrets, is placed in the database. This is a mongoDB database hosted at https://cloud.mongodb.com/
The databases are currently hosted in Singapore.
Atlas Cloud Privacy Policy https://www.atlascloud.co.uk/privacy-policy/
Provide details of security controls that are in place to protect the information. If a security risk assessment or penetration testing has been completed, provide a summary of the outcomes here.
Security controls exist at the following levels
1. Access to Open source code.
2. Access to platforms
3. Access to Database contents
4. API Services
The source code is readable by anyone. Changes to the source code are subject to the following controls:
· To commit code people must have a github account and be added to a voluntarily members team to get the ability to create a branch, commit to a branch and issue pull requests. To get this access contributors must demonstrate basic capability in using the system and must communicate directly with the team to request access.
· Deployments are made only from the master branch. To commit to the master branch contributors must issue a Pull Request (PR). A restricted group of staff members have permission to accept a PR into the master branch, and the request must pass a suite of unit, function, end to end and coverage checks plus personal code review.
· Code base and libraries used are monitored by GitHub for known vulnerabilities.
Access to platform for deployment is granted to staff via an AWS IAM account. Access is tracked. Deployed systems run as web services within docker containers and do not have shell access.
Website is HTTPS only so all information transmitted is secured in transit. Information at rest is stored only in the AltasCloud database or in S3 buckets in the case of uploaded images. Both these storage locations are encrypted.
Direct access to the database through the atlas cloud service is limited to key administrative staff of voluntarily. (Currently only (Andrew and Walter). Code level access requires a secret which is not stored in the open source code base except in an encrypted form.
All information in and out of the database is provided by Server side APIs. These allow clients with appropriate credentials to make create, read, update, and delete requests on entities in the database which include people, activities, opportunities, organisations etc.
The API is secured via the CASL library https://github.com/stalniy/casl
This provides fine grained controls on
· Who can have access
· What requests they are able to make
· What data fields can be accessed or sent in requests.
For example, this allows us to provide general access to a personal profile while restricting access to edit the profile to the owner and not giving out phone numbers unless the requestor has the required status.
· To be carried out
To be carried out
Provide details of how individuals will be able to access and correct their information. Will it be through standard TEC processes or will additional steps need to be put in place?
All personal information held on the platform will be able to be edited and maintained by the person themselves through their personal profile.
With the following exceptions:
· If badges are issued in error they will need to be rescinded by the badge issuer
· If people are marked as either attending or not attending an event in error, then the organizer of the event will need to correct the error.
In both above cases the error can also be corrected by making a help desk request (through the site) and an admin will be able to correct the data.
Provide a summary of any validation / accuracy controls that are being put in place to check personal information is accurate before it is used or disclosed.
If collection is from source then we would know.
Other than the person maintaining their profile information directly we perform the following
1. Email validation.
2. Real person validation as part of police vetting
Provide a summary of how personal information will be used in the change. For example, if we are using information to assess an individual’s eligibility for a service and then delivering it, outline what information is being used for assessing the eligibility and what is required to deliver the service.
Information is used to match volunteers with opportunities to carry out educational activities in schools.
Activity and Opportunity providers are able to define the requirements for volunteers participating in an event. This is done by listing the badges required. Badge requirements may be either mandatory or optional. When assessing volunteers organisers have visibility of whether the volunteer has the necessary mandatory badges and how well they match the overall optional requirements.
Policy on whether a particular badge is required is therefore set by the organisation creating the request. In the case where an opportunity is generated from an activity both sets of requirements will be used.
Hence either a school, activity provider (such as ITF) or the voluntarily platform itself may set a policy.
Voluntarily will use algorithms to make recommendations to volunteers as to which opportunities they should consider e.g. by locality, skills matching, interests etc. Similar algorithms may be used to identify potential candidates for helping with an opportunity (shoulder tap).
Presence of absence of specific badges will be involved in automated decision making e.g. excluding non police vetted people from attending events that require it.
In general no. However should we make available a complete set of volunteer activity data for analysis, even without personal identity information it may be able to identify people from other correlations such as social media postings about attending events etc.
Yes it is a condition of using the site and becoming a volunteer that the information provided can be used to
a) provide the service
b) report on and improve the service
There will be a privacy section in the terms and conditions.
A consent check box is required at the point of first expressing interest in an activity and thus wishing to be considered for invitation.
Volunteers will be required to tick the terms box each time the click the I’m interested button unless they visit the Terms page and click the accept button at the bottom.
We will need to write a statement to sit on voluntarily that talks about why we collect what we collect and what we will do with it, storage etc etc.
If so, list all parties who will have access to information, what information they will have access to and why they need to have it?
Reports, and Dashboards showing Information on volunteering and usage of the platform will be available to the following parties:
Voluntarily
Activity Providers
Volunteer Providers (corporates)
Opportunity Providers (schools)
Sponsors & Agencies
The information available will be restricted to that relevant to the organisation. Access to organisation reporting and data features is restricted to a member of the organisation designated OrgAdmin. Organisations may assign one or more Org Admin.
Organisations registered on the platform will have access to the following information:
· Name and email address of followers
· Name and email address of members
· List of all people expressing interest, invited, committed, attended or not attended an opportunity they have organized.
· List of all opportunities, activities, events created on the system by the organisation or their members.
· List of their staff members who have attended/not attended volunteering events, which events and how frequently.
· Reporting dashboard showing overall statistics.
· List of opportunities created based on their activities including school, requestor and attendance list.
· Reporting dashboard showing overall statistics on the use and popularity of their activities.
Consent is a condition of using the platform and is indicated by accepting the terms when volunteering.
A plain English & Te reo Maori version of this document will be provided as part of the terms and conditions.
All organisations have to be created in the system by Voluntarily admins and onboarded by providing an OrgAdmin and configuring their profile. This orgAdmin must accept the terms on behalf of their organisation.
Information regarding privacy and the use of voluntarily data and reports will be communicated to organisations when being onboarded.
We plan to retain information about opportunities and the interested attendees indefinitely in order that effectiveness over time can be assessed.
When an event is completed then a subset of information about the event is moved to an archive collection along with feedback comments and attendance information. Transitory information such as questions asked, emails or chat discussions, invites sent or withdrawn etc will be discarded.
If a person decides to leave the site their personal information will be discarded. In order to maintain database integrity their account id will be retained and their profile details replaced with anonymized default values. E.g. name: volunteer ABCED.
Any non required records in the database will be deleted. In order to maintain database integrity some keys and non identifying information may be retained.
Should the Voluntarily platform close down. The information retained in the database will be made available to (The National Library of New Zealand) (TBD?) for long term data retention.
Are we using any specific unique identifiers for individuals as a part of this change (i.e. NSN, Driver Licence)? If so, provide details of what and why we are using them.
Probably not relevant but we should check that no unique identifiers will be created.
Personal email address is used as the unique identifier for a person in the system. However this may be changed along with name and nickname.
A database key is also used internally to identify the person. This is a non sequential, randomized string e.g 5d957d1094bcb300124d3d4f
This key cannot be used to identify the person in any other system.
Passport and Driver license information may be collected as part of the Police Vetting process. This is not stored in the personal data and not retained once the process has been completed.