Security

How Glitterball protects your workspace, and how to report a security problem

How your data is protected

• Every connection to Glitterball uses HTTPS, and browsers are told never to fall back to plain HTTP
• Recordings, comments and accounts are stored with providers that encrypt them at rest. See Subprocessors for who they are.
• The storage bucket for recordings is private. Recordings are only served to people the walkthrough is shared with.
• Sign-in sessions and keys are stored only as one-way hashes, so a copy of our database can't be used to sign in as you
• Recordings replay inside a locked-down frame where nothing from the recorded page can run

Who can get in

• Your workspace's owners and admins decide who joins, and can remove anyone. Removing someone also cancels their keys for that workspace.
• Keys for coding agents and chat apps only work in the workspace they were made for. Revoke a key under Integrations in the sidebar to disconnect it.
• Sign-ins, failed sign-in codes, new and deleted keys, membership and plan changes, and account exports and deletions are kept in a security log for a year

How we look after it

• Every change to Glitterball is reviewed and tested before it ships
• Our dependencies are checked for known vulnerabilities on every change
• We review Glitterball's security every week and fix what we find

Report a security problem

Email team@glitterball.dev with what you found and how to reproduce it. We'll reply within two working days. Please don't access other people's data or disrupt the service while testing, and give us a reasonable time to fix the problem before you share it. Our security.txt has the same details.