Privacy Policy

PRIVACY POLICY

This is an unpublished working draft, not the operative privacy policy. It reflects reviewed application source and known product behavior; production data handling and legal responsibilities still require confirmation. Do not publish until the unresolved items in this draft are approved.

1. Scope and responsibility

This draft covers the public Cantus Firmus website and the music ministry application. The public website is informational and does not offer account signup. Participating organizations provision application accounts, choose which workflows to enable, and decide who may access their organization records. The legal operator of Cantus Firmus and the legal roles of the operator and each organization have not been confirmed. Final wording must identify the responsible legal entity and explain each party’s role.

2. Information processed

Depending on the deployment and enabled workflows, the application may process:

Account and access information: account identifiers, display names, organization membership, login email or username, roles and permissions, invitations, activation state, authentication records, and security events. Reviewed source stores passwords as Argon2id hashes rather than readable passwords; production authentication settings have not been audited.

People, ministry, and contact information: preferred or legal names, organization-defined roles, ensemble or choir membership, sections, service assignments, cantor eligibility, availability, administrator-entered notes, email addresses, phone numbers, contact labels, and household, parent or guardian, emergency-contact, or supervised-person relationships. The reviewed People schema has no date-of-birth field, but organizations may enter information about minors or guardians in other fields or records.

Schedules and participation: service and event details, dates, times, time zones, locations, music selections and planning notes, attendance records, and revision history.

Sensitive event, workforce, and finance information where enabled: funeral records may include a deceased person’s name, service details, family or funeral-home contacts, clergy and musician assignments, music, internal notes, and musician amounts. Workforce and finance records may include employee or contractor classification, work dates and quantities, pay periods, rates and amounts, time cards, review state, budget references, invoice or payment workflow metadata, and audit history. The reviewed schema did not identify bank-account fields; deployment-specific integrations have not been checked. Payroll and payment workflows are incomplete and are not generally production-ready.

Communications information: sender, subject and body, selected To/CC/BCC recipients, requesting user, attachment name, type, size or reference, message and attempt times, delivery status, provider identifiers, and failure details. The reviewed Mailroom model stores message and recipient information.

Google account information for Mailroom: when an authorized operator connects a designated Google Workspace sender, the reviewed code requests gmail.send, openid, and email. It receives the authorizing account’s email and verification state and checks the account against the configured mailbox. It does not request Gmail inbox-reading, Gmail modification, or Gmail settings scopes.

Technical diagnostics: the API source logs request ID, method, path, response status, and certain error categories. Production hosting, proxy, device, cookie, and IP-address logging and retention have not been confirmed. Information may be entered by an organization administrator or another authorized user, or supplied by an individual through an enabled workflow.

3. How information is used

Information supports account authentication and permissions; organization people, ensemble, schedule, service, and music-planning records; staffing and availability; attendance; developing finance workflows; requested documents; communications initiated by an authorized user or organization workflow; duplicate-send prevention; and operational, security, and audit records.

Proposed Google data commitment for owner approval: information received from Google APIs will be used only for the Mailroom sending and account-verification features described here, and not for advertising, sale, or generalized AI model training. Human access to Google API data must remain limited to the purposes permitted by Google’s API Services User Data Policy. The owner must confirm these commitments against production procedures before publication.

4. Google OAuth and Gmail API

Mailroom uses gmail.send so an authorized organization user can submit organization-directed email through Gmail as the designated sender. The openid and email scopes identify and verify which Google account authorized that sender and help reject an unexpected account. This connection is for the Mailroom sender; it is not the sign-in method for every musician or staff member.

When an authorized user directs a message, its content, selected recipients, and supported attachment are sent to Google for delivery and to the intended recipients. The application records a message and recipient snapshot, attachment reference, attempt and status history, and provider identifiers for operational audit and duplicate prevention. A queued or provider-accepted status does not confirm inbox delivery. Reviewed source resolves OAuth client values and the authorized mailbox from protected server configuration, holds access tokens in process memory, and stores configuration references rather than token values in the application database. These are source-code observations; production secret storage, authorization status, and credential deletion have not been independently verified.

Use of Google API data must comply with the Google API Services User Data Policy, including Limited Use. The production OAuth scopes, stored data, and Limited Use procedures must be confirmed before publication.

5. Storage, processing, and sharing

The reviewed application architecture uses PostgreSQL for operational records and describes private, organization-partitioned local storage for PDF bytes. The deployed API, storage location, backups, logging, and security configuration have not been inspected. The operator must confirm the production hosting, database, document storage, backup, support, and other service providers before this description is finalized.

Organization records are available to users authorized by the organization under its configured permissions. Reviewed source includes organization-scoped access and capability checks; the production role matrix and operator access have not been audited. When the organization directs a Mailroom message, its selected content, recipients, and attachments are shared with Google Gmail and the intended recipients. Information may also be shared with service providers needed to operate the application, to protect users or the service, or when required by law. The production provider list and operational access rules require owner review.

6. Employees, volunteers, and young people

Organizations may enter records about employees, contractors, volunteers, clergy, cantors, choir members, musicians, families, and other participants. The application can represent parent or guardian, emergency-contact, and supervised-person relationships. Organizations are responsible for required notices and authority or consent, appropriate access limits, and entering only information needed for an enabled workflow. The public website is not intended to solicit personal information from children. Whether minors may hold accounts or use self-service workflows has not been defined for the production service and requires owner and counsel approval.

7. Security

Reviewed source includes organization-scoped authorization, capability checks, tenant isolation controls, revision history, password hashing, and protected server-side OAuth configuration. These are code-level mechanisms, not an independent security certification or proof of production configuration. Deployed HTTPS, database and storage protections, administrator access, secret storage, backups and restoration, incident response, vendor controls, and personal data in logs or support systems remain to be verified. This draft makes no claim of encryption at rest, certification, or a specific incident-response time.

8. Retention, deletion, and requests

There is no approved product-wide retention schedule. Source includes historical audit, attendance, finance, communication, and document records; retention, legal holds, deletion, archive, and document-disposition rules remain unresolved. No specific retention period or backup-expiry period is promised in this draft. The final policy must explain how long each record type is retained, what happens when an account or organization ends, and which records may remain for legal, financial, security, or audit reasons.

For organization-managed records, begin with the administrator who provided the account. Requests may require identity and authority verification and coordination with the organization responsible for the record. A public Cantus Firmus privacy contact, operator request process, response timeframe, and complaint route have not been confirmed; they must be approved before publication. A Google account holder can revoke Mailroom authorization in Google Account settings. The operator process for removing server-side Mailroom credentials has not been documented. Depending on applicable law, individuals may have rights to request access, correction, deletion, restriction, objection, or a copy of personal information.

9. Changes and publication

This draft has no effective date and is not in force. Before publication, the operator must confirm the legal entity and privacy contact; production fields, authentication, enabled modules, providers, storage, logging, and operator access; retention and deletion rules; employee, volunteer, and youth practices; the exact OAuth scopes and Gmail data stored; Google Limited Use and human-access commitments; and any required privacy counsel review. Publish an effective date only after approval.