Effective date: Set on publication
Service operator:
Privacy contact:
1. Who runs umask?
umask is an independently operated Discord bot and website. The operator named above handles privacy requests. Discord, PebbleHost and Cloudflare provide separate services; they do not operate umask.
2. The data we use
umask stores Discord server IDs, staff member IDs, staff and elevated-role IDs, optional alert-channel IDs, permitted durations and configuration timestamps. It may retrieve the server owner's Discord ID, usernames, membership and roles from Discord to verify permissions, and displays relevant metadata in the owner's private dashboard. It does not need ordinary message content or complete member lists.
Issued ten-word access phrases are verified using salted Argon2id password hashes. For initial collection, an encrypted phrase copy is temporarily kept; it is deleted when collected or after the 15-minute collection window is processed. If the bot is offline, cleanup can be delayed. Phrases are transmitted through Discord interactions, and are not intentionally logged.
We store active session start/expiry data, failed-attempt counters and lockouts, and completed session history (including Discord identifiers, times and end reason). No full message-history archive is collected.
3. Why we use it
This information is needed to identify authorised staff, authenticate access phrases, grant and remove the owner's chosen elevated role, recover after restarts, limit repeated guesses, and provide security-related session history. Where applicable, we assess our lawful basis under data protection law, including any legitimate interests in providing a secure service. This assessment and applicable jurisdiction must be confirmed before full public release.
4. Where it is processed
The bot and its live SQLite database run on PebbleHost, using its file storage. The public website is served by Cloudflare Pages. Discord provides interactions and server information. Cloudflare Email Routing forwards emails sent to support@umask.app to the operator's chosen mailbox. Private support tickets, if used, are handled within Discord and any ticket tooling configured in the support server.
The static data-request form does not transmit the completed form to our servers. Instead, it prepares a draft in the visitor's email application; nothing is sent until the visitor sends that email. Our website does not require a login or ask for any Umask authentication phrase. Standard connection logs may still be collected by hosting and communication providers.
The operator and hosting providers may have authorised technical access to relevant files and records. The service is not independently security-certified, and no system is immune to all breaches. Hosting location, relevant transfer safeguards and service-provider log practices must be confirmed before final publication.
5. How long data is kept
- Collected credentials: active verifier records remain until revoked, reissued or removed after a valid deletion decision. The encrypted initial delivery copy is normally cleared within the 15-minute collection window.
- Active sessions: kept until role removal is confirmed or appropriate recovery has occurred; a failed revocation may delay deletion of essential session records.
- Completed session history: automatically cleaned up once more than 90 days old, normally by a daily maintenance task, unless a particular record is subject to a documented, time-limited preservation decision.
- Server configuration: kept while needed to operate the server's umask setup. If the bot leaves a server, configuration and associated records are normally cleaned after a seven-day grace period, except where unresolved active sessions or a justified preservation hold require further handling.
- Local SQLite snapshots: one verified daily copy, with automatic removal of snapshots older than seven UTC calendar days, stored on PebbleHost alongside the bot. These copies are not independent protection against loss of the entire hosting account.
- Off-server copies: the operator's intended maximum is 30 days for encrypted backups held separately, but this requires an actual, manually or automatically maintained off-server backup process. We will not represent that process as automatic until it is deployed and tested.
- Privacy-request records: limited records of approved erasures are kept separately from the SQLite snapshots to prevent a restore reintroducing deleted data. Resolved erasure instructions are normally removed after 12 months; pending revocations are retained until resolved. Request correspondence and provider logs may have separate retention arrangements.
6. Requesting access, correction or deletion
You can use the Data requests form, email support@umask.app, or open a private ticket in our support server. You may make a valid request through other channels too; a request does not become invalid simply because it does not use our preferred form.
Staff members: provide your Discord user ID and, if requesting server-specific records, that server's ID. You may request deletion of just your completed session history without automatically asking to revoke valid credentials, or request removal of other eligible personal data. You may also request information about data held across multiple umask servers.
Server owners: provide your server ID and Discord user ID, and describe whether you want the entire server's umask configuration and records removed. Server-wide deletion ends the existing setup and may affect the ability to use Umask until reconfiguration. We verify current server ownership through Discord when possible.
Knowing an ID is not proof of account or server control. We may ask you to verify your identity through an authenticated Discord account or proportionate alternative, without requesting your Discord password, Umask phrase, bot token or identity documents by default.
Requests are reviewed individually, not executed automatically. A server owner may have a legitimate need for specific session history during an investigation, but an investigation is not a blanket exception to an individual's erasure rights. Records are preserved only where there is an applicable lawful reason, such as establishment, exercise or defence of legal claims, and where the retention is necessary and proportionate. Holds on specific history records are time-limited and reviewed. Where necessary and proportionate, we may seek limited information from the server owner to assess a genuine active investigation, without giving the owner an automatic veto or unnecessarily disclosing your request. We will explain the decision and any lawful exception, subject to relevant restrictions.
We aim to respond without undue delay and ordinarily within one calendar month, subject to identity verification and applicable extensions. Where a request is fulfilled, older data may remain in inaccessible backups until rotation; it must not be used for normal operation. You may have rights to object, restrict processing, and complain to the UK's Information Commissioner's Office or another competent regulator.
7. Recovery and data deletion
When erasure of credentials or an entire server is approved, umask must first address active elevated roles. If role revocation fails, necessary session records can remain until cleanup succeeds; we won't claim full deletion prematurely. A separate erasure ledger helps reapply approved decisions after restoring an earlier SQLite snapshot. This does not guarantee recovery if both backup and ledger are lost, and restores require operator review.
8. Changes
We may update this policy for changes to the service, security design or hosting providers. Material updates will be communicated where appropriate and shown with a revised effective date.