Security and privacy
How sign-in, access control, uploads, retention and data handling work, for reviews and questionnaires.
SCAD Maps carries operational information about a live event: where people are, what is going wrong and who is dealing with it. This page describes how that information is protected, what is stored and for how long, and where data goes. It is written for security reviews and for organisers who are asked about privacy by their venue, clients or crew. It describes the product as built; deployment choices such as hosting location and backups are the operator's own.
Who can sign in#
- No anonymous access. Everything except the sign-in form and a few public status checks requires an account, a guest link or a single sign-on session.
- Account approval. Accounts are created by an administrator or by an approved invitation. Self-signup is off unless the operator enables it, and even then a request stays pending until an administrator approves it. A pending or rejected account cannot sign in.
- Passwords. Passwords are 8 to 72 characters and stored only as slow, salted bcrypt hashes. The sign-in check takes the same time whether or not the account exists, so the form cannot be used to find out who has an account.
- Sign-in limits. Attempts are limited per account name (8 per 15 minutes by default) and per network address, and heavy simultaneous sign-in traffic is queued rather than allowed to slow the server for everyone.
- Single sign-on. Instances can delegate sign-in to the organisation's identity provider, where groups decide the access level and sessions are capped at 24 hours. See Single sign-on.
- Guests. Guest access comes from a QR code or link and can be protected with a PIN, limited in time and restricted to chosen layers. Guests cannot share location, chat or search. See Invitations, QR codes and access requests.
Sessions and tokens#
| Item | How it is handled |
|---|---|
| Access token | Valid for 15 minutes and kept only in the page's memory, never in local storage. The app renews it quietly in the background. |
| Refresh token | Valid for 7 days by default and held in a cookie that scripts cannot read. It is restricted to the instance's own site, marked secure and stored on the server only as a hash. Each use replaces it with a new one. |
| Replay detection | If an old refresh token is presented after it has been replaced, the whole session is ended and its live connections are cut off. |
| Change protection | Requests that change data must carry a second token that only the genuine page has, on top of the cookie. |
| Immediate effect | Changing someone's role, disabling or deleting an account, or resetting a password takes effect on their next request, not when the token expires. Any open live connection is closed. |
Access control#
Permissions are enforced by the server. The app hides buttons a person may not use, but that is convenience: every request is checked again on the server with the person's current access level and roles. The three access levels, restricted users, guests and the machinery admin flag are laid out in Permissions.
- Restricted users are limited on the server to content tagged with their own groups; the limit is applied to the map, search, live updates and chat.
- Hidden means not sent. Site plans, notes, tasks and areas that a person may not see are left out of what the server sends. They are not merely hidden by the interface. Asking for something by its identifier gives the same answer as if it did not exist.
- Live updates. Real-time messages are addressed to the map regions and channels a person is entitled to, so a phone only ever receives events for content it may see.
- Direct messages are visible to the two people in them and to no one else, including administrators.
What is stored#
| Data | Kept for | Who can read it |
|---|---|---|
| Accounts: name, email, access level, roles, settings | Until deleted | Administrators; each person sees their own |
| Notes, areas, tasks, incidents with their history | Until deleted | According to visibility and roles |
| Chat messages | Until deleted by the author or an administrator | Members of the channel |
| Voice-note audio | 7 days, after which the message stays and the audio is removed | Members of the channel |
| Photos and documents | Until deleted with what they belong to. Photos are re-encoded on upload and checked by file signature | Anyone who can see the item |
| Activity log | 90 days by default | Admins and User Admins |
| Live location | About 10 minutes after the last update | Signed-in non-guests viewing that part of the map |
| Movement history | One point per person per minute while sharing; deleted after 7 days by default | Administrators |
| Browser error reports | A short in-memory list and the server log | Operators |
The default periods can be changed by the operator; see Instance configuration. Deleting a user removes their movement history. Location sharing is off until a person turns it on, per device, and nothing is sent or stored for someone who has not. Details are in People and location.
Uploads#
- The type of every file is verified from its contents, not from its name or the type the browser claims. A file that does not match the allowed formats is refused.
- Images are limited in size and pixel dimensions, then converted to WebP by the server, which removes embedded metadata such as camera position from the stored copy.
- Files get long random names and are served only to signed-in people. Each person has a storage quota (50 MB by default).
- Uploaded files that are never attached to anything are deleted automatically after a few hours.
Secrets and integrations#
- Credentials for integrations, such as the monday.com token, the machinery tracker secret and the Dropbox authorisation, are encrypted before they are stored and are never sent back to the browser.
- The Dropbox connection is limited by Dropbox itself to one app folder with read-only permissions.
- Public monday.com dashboard links carry a signed token that expires. Webhook addresses contain a long random secret.
- Integrations are inert until an administrator connects them, and each can be switched off for the whole instance by the operator.
Browser protections#
The app is served over HTTPS only. Cookies use the strictest same-site setting, the standard security headers are set, and other sites cannot place the app in a frame. The page loads no advertising or analytics scripts and contains no third-party trackers.
The app does contact a few external services, and only for what they are needed for:
| Service | When | What it receives |
|---|---|---|
| Public map imagery providers | Base maps and street backgrounds | The tiles requested for the area on screen, with the visitor's network address. |
| Building data service (3DBAG) | Only if the 3D layer is enabled and switched on | Requests for building data around the area. |
| Public rain radar | Only as a fallback when the instance's own radar source fails | Radar tile requests. |
| Push services of the browser vendor | Only if a person turns on notifications | Message content, encrypted end to end to the device. |
Rain radar, machinery positions, Dropbox images and monday.com traffic pass through the SCAD Maps server rather than straight from the browser to the provider.
Limits that protect the service#
The API is rate-limited per network address, creates and edits are limited per person, and chat, uploads and sign-in have their own tighter limits. Administrators are exempt from the per-person write limit. Static map tiles and images are exempt from the general limit so that a busy map does not lock people out.
What to decide as an organiser#
- Choose who receives which access level and prefer custom roles or restricted users for external crews.
- Decide whether location sharing is expected of everyone or voluntary, and tell people up front.
- Use a PIN and an expiry time on guest links, and revoke them after the event.
- Export what you need for the after-action report, then let the retention periods run. See Activity and export.
- Ask the operator where the instance is hosted, how backups are made and how long they are kept, since these depend on the deployment.