Privacy and security

Where Doska stores your data, what it collects, how permissions, passwords and API tokens are protected, and what infrastructure import keeps.

This page summarizes how Doska handles your data and protects access to it: where it lives, what is collected, and the security measures behind sign-in, permissions, API tokens and infrastructure import. The binding texts are the Privacy Policy and the Terms of Service.

#Where your data is stored

Everything you create on getdoska.top is stored on Doska's own server, hosted by an infrastructure provider in the European Union. Traffic passes through a content delivery network for protection and speed; these providers process data only on Doska's behalf.

Boards, documents, diagram code, comments, version history and uploaded files are all kept in one PostgreSQL database. When an account, board or organization is deleted, its data is removed from the database right away and disappears from backups within 14 days.

#What Doska collects

Usage statistics are first-party: they stay on Doska's server and are not shared with anyone. There are no third-party analytics and no tracking cookies. Visits to the home and sign-in pages are counted without cookies: a visitor is a hash of the IP address and browser with a salt that changes every day and is then deleted, so the same person can't be followed across days, and the IP address itself is not stored. Bots are not counted.

Doska doesn't sell your data, show advertising, build marketing profiles or use your data or content to train AI models.

#Cookies

Doska sets one session cookie to keep you signed in and a short-lived cookie that protects the Google sign-in step. Your browser also stores preferences such as theme and language.

#Google sign-in

Doska asks Google only for openid email profile: your account ID, name, email address and whether it is verified. It never receives your Google password and gets no access to Gmail, Drive, contacts or other Google data.

#Permissions

• Checked on the server. Every request and every live-editing connection is checked against your current role. The web app hides buttons you can't use, but the server is what enforces access.
• Organizations are isolated. A request for a board, project, file or comment of another organization answers "not found", so its existence isn't revealed.
• Viewers can't write. A viewer's live connection is read-only: the server drops any change it sends.
• Changes apply immediately. When a role is lowered or someone is removed, their open boards reconnect with the new rights.
• Public links are read-only, are not indexed by search engines, and stop working the moment they are turned off.

Roles and sharing are described in Sharing and permissions.

#Passwords and sessions

• Passwords are stored only as salted scrypt hashes, never in plain form.
• Sessions are random tokens in an httpOnly cookie. The database keeps only their SHA-256 hash, so a database copy can't be used to sign in. Changing your password ends your other sessions.
• Sign-in and sign-up attempts are rate-limited.

#API tokens

Tokens for Claude, MCP clients and CI are built for least privilege:

• Stored as hashes. The token is shown once when created; Doska keeps only its SHA-256 hash. The dsk_ prefix lets secret scanners recognize a leaked token.
• Scoped. Each token belongs to one organization and has a level (read, comment or edit), optionally a list of projects and an expiration.
• Never more than you. A token can't exceed its owner's current rights. If you lose access to a project, so does the token.
• Narrow surface. Tokens work only for the REST API (/api/v1/*) and MCP. They can't manage members, sharing or other tokens.
• Admin control. Organization admins set the highest level members and guests may use, see every token in the organization and can revoke any of them.
• Undo. Before the first change through a token, Doska saves a version of the board, so an agent's changes can be rolled back in one click.

See Claude and MCP for details.

#Transport and browser protection

• All traffic uses HTTPS, and HSTS tells browsers to use only HTTPS for a year.
• A strict Content Security Policy allows scripts only from Doska itself, with no external resources. Pages can't be framed by other sites (X-Frame-Options: DENY, frame-ancestors 'none').
• Cookie-authenticated changes are accepted only from Doska's own origin, which blocks cross-site request forgery; live-editing connections from other origins are rejected.
• Camera, microphone and geolocation are disabled by policy.
• Uploaded files are recognized by their content, not their name, are served only to people who can see the board, and carry a sandboxing policy, so a disguised script can't run.
• Diagram code is never executed: Doska's own parser builds only a graph, HTML in labels is stripped and click handlers are ignored.

#Infrastructure import

Infrastructure import is designed to keep secrets out of Doska:

• Attribute values are never stored. Only resource names, types and relations reach the board. Passwords, environment variables and the contents of Kubernetes Secrets are not saved anywhere.
• Network data is kept where it is needed for network checks: CIDR ranges, ports and protocols.
• No live access. Doska doesn't connect to your cloud account or cluster and doesn't store kubeconfig files or keys. You or your CI provide the files.
• Files stay local in the browser. In the import dialog and in the free Terraform tool, files are parsed in your browser and are not uploaded. Through the API or MCP, they are parsed in server memory.

#Your rights

You can change your name in Settings and export any board to a file at any time. To get a copy of your personal data, correct it, or delete your account and all its data, use the contact on the Privacy Policy page.