Your data,
your keys, your network if you want it.

What is protected

• Files you analyseStay in your browserFiles open in your browser and are never uploaded: parsing, queries and charts run on your machine.
• Live stream dataEnd-to-end encryptedAES-256-GCM per frame, sealed by the sender and opened by the viewer. The relay forwards ciphertext and never holds a key.
• Stream keysPassword, device or project keysKeys are derived from the stream password with PBKDF2 (600,000 iterations), wrapped to each of your browsers’ own P-256 device keys, or, in an end-to-end encrypted project, sealed under the project’s key. Only the members’ approved browsers and the project’s approved senders hold that key. A sender proves it holds its API key before a member’s browser approves it.
• WorkbooksPersonal, or end-to-end encryptedA workbook keeps the analysis — worksheets, charts, math channel formulas — never data. Saved for an organization in an end-to-end encrypted project, it is encrypted in your browser with its own key (AES-256-GCM) sealed under the project’s key: the project’s members open it, we can’t. Personal workbooks are stored readable on our servers and only their owner can open them. Saved in a project that isn’t end-to-end encrypted, it is stored readable on our servers, like a personal one, and labelled so; once the project turns encryption on, the next save seals it and its whole history in the browser. Exported workbook files are encrypted for who may open them — only you, your organization, or anyone with Kymoscope — with a key we hold: outside Kymoscope, or for an account outside that scope, the file can’t be read, but we could technically open it. Add a password (PBKDF2-SHA256, 600,000 iterations) and nobody without it can, us included.
• Recovery keyOptional, kept offline by the ownerAn organization’s owner can create a recovery key (optional; offered after the first organization save, never required): a password-protected file and a printed code that never reach us. Every project key is also sealed to it, outside the two-step and approval layers, so the owner can recover every project after losing all browsers. Creating and using it needs the owner’s account with two-step verification, and using it is recorded in the audit log.
• Opening a projectThree layers, chosen per projectEach project chooses three extra layers, all on for new projects. Two-step verification: its keys and streams open only in a session signed in with an authenticator code, except API-key senders, which receive the key as devices. Approval of new browsers: an organization owner or admin approves a person’s new browser for every project of the organization; a project lead, for the projects they lead; never their own; approving, and turning any layer off, needs a session signed in with the code. A typed code: the approver types the code shown on the new browser, compared in the approver’s browser with the key it seals the project key to; the server never sees it. The typed code guards against approving the wrong browser, not against the server. Organization owners can require any layer for every project. An approval stops counting when the approver leaves the organization or loses the role it was given with.
• Who may watchShort-lived ticketsViewers get watch-only tickets for one stream that expire in minutes and renew while the stream is open. Organisation streams are visible to members only.
• Where data flowsOur relay or yoursRun the relay on your own network with one docker command. It verifies our Ed25519-signed tickets locally and keeps working without internet once it has its certificate.
• Account dataEU regionAccounts, organisations, math channels and stream names are stored in the EU (Paris). Payments are handled by Stripe; we never see card numbers.