Privacy Policy
TestDossier is built around a simple promise: your test data is yours. This page explains exactly what we collect, what we don't, and why.
Who is responsible for your data
The operator of TestDossier is the data controller for account, billing, security, support, and service-usage data. Contact the controller at support@testdossier.com. When an organization uses a workspace to process test content on its own behalf, that organization generally decides why and how that content is processed and acts as controller; TestDossier handles it as a service provider or processor on the organization's instructions.
If you submit information about another person—for example, a reviewer, teammate, or person visible in test evidence—you are responsible for having an appropriate basis to do so and for giving them any notice your organization is required to provide.
Purposes and legal bases
- Contract: creating and securing your account; providing local-to-cloud sync, capture, sharing, review, sign-off, inbox, export, and billing features you request.
- Legitimate interests: preventing abuse, protecting accounts and infrastructure, diagnosing reliability problems, keeping necessary operational records, and producing limited cookie-free service metrics. You may object where this basis applies.
- Consent: where we specifically ask for optional processing. You may withdraw consent for future processing at any time without affecting earlier lawful processing.
- Legal obligations: keeping or disclosing limited records where tax, accounting, fraud-prevention, or other applicable law requires it.
We do not use personal data for advertising, data brokerage, credit decisions, or solely automated decisions that produce legal or similarly significant effects.
Local authoring without sign-up
If you use TestDossier without signing in, local authoring data — tabs, screenshots, results — is stored in your browser's IndexedDB. None of that local authoring data is sent to our servers unless you choose a server-backed feature, such as creating a share link or submitting a browser capture.
Accounts, Free sharing, and Pro sync
If you sign in or use server-backed features, we store only what is needed to operate those features:
- Your email address (for login and account recovery)
- If you use “Continue with Google” or “Continue with Microsoft”, the verified email address from the provider's identity token (and, for Microsoft, the tenant identifier used to validate it) — nothing else from your profile, and never your provider credentials
- If a workspace owner mints an audit-feed token, the token's label, a short prefix, a hash of the token, and created/last-used timestamps. Events pulled through the feed are the same workspace activity records described below
- Per-device sessions: each signed-in browser stores a coarse device label (browser and operating-system family only, e.g. “Chrome · macOS”) and an at-most-hourly last-used timestamp so you can review and revoke devices under Account → Devices. The raw user-agent string, IP address, and any device fingerprint are not stored with sessions
- Passkeys, if you enroll one: the credential’s public key and identifier, an opaque account handle, signature counter, available transport hints, device/backup category, the label shown in Account → Security, and created/last-used timestamps. TestDossier never receives the private key, fingerprint, face template, or device PIN. Short-lived one-time challenges are deleted when used and expire after five minutes
- Sign-in abuse protection: a secret-keyed, non-reversible hash of your network address is used in rolling-window rate-limit counters. These counters are retained only for abuse prevention and pruned opportunistically after their enforcement window; the raw network address is not stored in the sign-in counters, and the hash is not used for advertising or cross-site tracking
- Share links: the frozen report payload, share settings, password hash if you set one, expiry data, comments or verdicts if enabled, an anonymous aggregate open count, and per-view analytics only when the share owner opts in
- Free capture submissions: a temporary capture bundle and evidence inbox long enough for the app to import it into your browser; free capture bundles expire after 7 days if not imported
- Pro synced data: your test cases, projects, test plans, history, and screenshots so they sync across devices and workspaces
- Your subscription status and payment-provider identifiers, only if you have a paid plan managed via Stripe Managed Payments
We do not read, mine, sell, or train AI on your test content. We disclose data only as needed to operate the service, meet legal obligations, or protect the service and its users. TestDossier does not use AI to process your test content. Public pages use self-hosted fonts and do not contact an external font provider.
Retention after cancellation. Cancelling stops renewal; Pro remains active through the paid billing period. When the subscription ends, personal cloud data is retained for a 30-day grace period. During that window, re-subscribe to restore full in-app access and cancel the scheduled deletion. You can also download two complementary exports: a re-importable ZIP of active cases and their evidence, and an account-data JSON archive containing projects, plans, runs, snapshots, trash records, and other account metadata. The JSON archive is for portability and audit and is not currently a one-click restore format. We email you when the grace window opens and before it closes. After it ends, eligible personal cloud data may be permanently deleted. Deleting your account immediately removes personal account records; anonymized team-workspace history remains as described under Your rights below. (See Terms §6.)
Team workspaces (Pro)
If you create a workspace and invite teammates, we store: the email addresses you invite, each member's account membership and role (owner / admin / member), and an activity feed recording who edited which test case and when. We also broadcast lightweight presence signals (which test case a teammate is currently viewing) in real time to other members of the same workspace.
Workspace data stays inside the workspace — it is not shared with other workspaces or used for anything besides operating the workspace. Owners and admins can remove members at any time; removed members lose access immediately.
CI ingest (Pro)
If you POST results from your CI pipeline (Cypress, Playwright, JUnit XML, or generic JSON) to /api/ci/ingest, we store: run metadata (build, environment, duration, branch), per-test results (name, status, duration, error messages), and any attachments included in the payload. CI runs land in your project's history alongside manual runs.
CI source context is optional and off by default. When you enable it in testdossier.json, the CLI reads bounded source excerpts identified by the test report, redacts common credential literals, and uploads the content with its repository-relative path, language, line range, digest, truncation and redaction indicators, and commit when available. TestDossier stores it as run and case evidence. Source is removed from public shares unless the owner separately chooses Include source code. --dry-run reports metadata but never prints the code. Do not enable source capture for repositories you are not authorized to upload.
The per-project bearer token used to authenticate ingest requests is stored hashed at rest and never displayed again after creation. You can rotate it any time from project settings.
Browser extension — TestDossier Capture
The optional TestDossier Capture browser extension can record a user-started manual test session—clicks and page download/export requests (including a bounded, redacted link-provided filename, but never downloaded bytes), committed field changes and form values (including bounded, redacted filenames selected in file controls, but never the file bytes or local path), form submissions, page navigations and URLs, and short visible result text after an action. Screenshots are best-effort. When Network & errors is enabled and the required browser APIs or page hooks are available, the session can also include supported network and GraphQL request metadata (via registered webRequest listeners), available bounded and redacted fetch/XHR previews, console warnings and errors, uncaught exceptions, and unhandled promise rejections. Capture runs only after you press Record and stops when you stop.
The extension may attach the browser name/version and operating-system name as troubleshooting context. Firefox treats this as optional technical data: if you decline that permission, those two fields are omitted and recording, review, and submission continue to work normally.
Site access is opt-in. On Chrome, Edge, and Firefox, the extension installs with host access to only the TestDossier origin (used to submit your captures). The first time you press Record, the browser asks you to allow the extension to read the sites you test — a single browser-managed grant that its screenshot API requires — and the recording script still runs only on tabs you're actively recording. You can review or withdraw this access at any time from the extension's details page (Site access). Nothing is captured outside a recording you started. The extension is disabled in private/incognito windows so capture state and saved tokens are not shared with private browsing.
Your capture evidence stays on this device until you submit. The session is buffered locally in the browser's IndexedDB; you review it in the panel and choose to submit or discard. Only on submit is the assembled capture sent to /api/capture. On Free, the bundle is held temporarily so the app can import it back into this browser, then it expires if not imported. On Pro or workspace projects, submitted capture evidence is stored with the synced project.
Guided replay is also user-initiated. The extension retrieves the selected case's title and steps from your TestDossier project, then stores each Pass, Fail, Blocked, or Skipped verdict, optional note, and screenshot locally while the replay is in progress. Results are sent to the selected project only when you choose Log results; Discard removes the local replay without submitting it. Cloud-synced replay logging requires a Pro or Workspace project.
Because a captured case can be published as a public share link, the extension is redacted by construction: password fields are never captured (masked at the source, before anything is buffered), and known-sensitive values (card numbers, SSNs, secrets, tokens, OTPs) are masked the same way. Network evidence includes request metadata; when technical capture is enabled, it can also include small, browser-redacted and size-limited text previews of fetch/XHR requests and responses. Cookies and authorization headers are not collected from browser traffic. Project access tokens are stored raw in this browser's extension storage because the bearer credential must be presented to the API. They are sent only over HTTPS to the TestDossier API as an Authorization header when the extension validates a token, loads project or case details, saves language preferences, fetches or submits replay results, or submits a capture. TestDossier stores only a token verifier/hash on the server; you can revoke a token from project settings at any time.
A note on visible page content. Before storing a screenshot, Capture makes a best-effort, capped attempt to mask detected sensitive-field regions. Detection or compositing can miss or fail, and account names, customer data, internal copy, or an open chat panel may still appear. After recording, you can black out screenshots manually before submitting. To make the case readable, Capture also records a small, time-limited set of short status messages, validation feedback, and headings after a recorded action. Common email, token, and long-number patterns are redacted from that prose in the browser, but this is a safety net, not complete detection; other sensitive text may remain. Review the case and every screenshot before submitting, and use Pause before doing anything sensitive.
Chrome Web Store Limited Use. The use of information received from Google APIs will adhere to the Chrome Web Store User Data Policy, including the Limited Use requirements. TestDossier uses captured information only to provide and improve the extension's single purpose: creating the test evidence that you explicitly record and choose to submit. We do not sell captured data, use it for advertising or credit decisions, or allow people to read it except with your explicit support consent, when required for security, or when legally required.
Test inbox (Pro)
The test inbox gives you disposable email addresses (of the form name.xxxx@inbox.testdossier.com) for exercising sign-up, verification, and notification flows. You can hold up to three personal addresses plus one per workspace and rotate any of them at any time.
When mail arrives at one of your addresses we store the sender, subject, and a capped plain-text preview so you can inspect it. HTML bodies, raw message source, and attachments are not stored in the current version. Messages are assigned a seven-day expiry and the inbox worker regularly purges expired rows. Rotating an address bounces new mail to the old one but leaves already-received previews readable until they expire. Inbox messages are scoped to your account or workspace and are never shared, mined, or used for anything besides showing them to you.
Anyone who knows one of your addresses can send mail to it, so treat it as a test mailbox — don't route real personal or production data through it.
Shared evidence links — viewers and commenters
When you generate a shareable evidence link, anyone with the link (and password, if you set one) can view it. We don't require viewers to sign in. If you choose Send by email, we temporarily store recipient addresses and your optional message in our transactional-email outbox and send a separate invitation to each recipient. Addresses and message content are scrubbed after delivery is accepted or permanently abandoned; privacy-minimized hashed delivery records may remain for up to 90 days. A share password is never included in an invitation email.
We always increment an anonymous total open count when a person loads a report. Known link-preview and search crawlers are excluded. This integer has no corresponding per-view row and contains no network, device, referrer, location, or other viewer attribute.
Detailed view analytics is off by default. If the share owner enables it, we collect the following limited data so the owner can understand how the link is used. Their last choice pre-fills the next share they create and can be changed before publishing:
- View rows: a daily-rotating, secret-keyed hash derived from the viewer's network address and share, the host portion of the referring page (for example, slack.com), and the country code Cloudflare reports at our edge. We do not store the raw network address or a User-Agent fingerprint in share analytics.
- Comments: if a viewer leaves a comment on your shared report, we store the name they typed, the optional email they provided (never displayed publicly — only stored so you can reply manually), the comment body, and an approximate country code from Cloudflare's edge. The country is visible only to the share owner during moderation; other public viewers don't see it. The share owner gets an email notification.
You (the share owner) can disable commenting or detailed view analytics per share, remove and restore individual comments, or revoke the share entirely. Turning detailed analytics off deletes that share's view rows and related analytics events but keeps its anonymous total open count. Revocation makes the report URL and preview endpoints unavailable immediately. Most report-scoped content is deleted in that request; a legacy signed report can remain inaccessible while a durable worker finishes exact digest sealing and then deletes its report, comments, view rows, one-time codes, and build objects. Verdict and verified-signature ledgers are retained for 12 months as described below. Evidence objects still referenced by the underlying project are not deleted merely because one link is revoked, and previews already cached by third parties may remain until their caches expire.
Verified sign-off (Pro)
A share owner can ask reviewers to record a verdict — approve, request changes, or block — on a shared report. Casting a verdict requires a name and an email address, and, when the owner requires verification, confirming a one-time code we email to that address. This only proves the reviewer controls the mailbox: no account is created. The sign-off email contains only the code. A separate invitation containing the share link and optional owner-written message is sent only when the owner explicitly chooses Send by email; it never contains the share password.
For each verdict we store the reviewer's name, email, the verdict chosen, any note they add, timestamps, country, and a daily-rotating network hash used for abuse prevention. For verified sign-off, we also store a secret-keyed browser hash scoped to that report as audit evidence; it cannot correlate the browser across unrelated reports. Each verified signature is bound to a SHA-256 digest of the exact frozen report header and ordered report chunks. New verdicts are appended rather than overwritten while the share remains active. Public viewers see only aggregate counts; individual reviewer details are visible only to authorized owners. When a report is revoked or purged after expiry, the report itself is deleted but its verdict and signature ledger, report title/type, timestamps, and report digest are retained for 12 months. Personal ledgers are included in account data export and are erased if the owner deletes the account; workspace ledgers remain with the workspace.
Analytics
We use Cloudflare Web Analytics on our marketing pages and app to produce aggregated, cookie-free traffic metrics. We do not use Google Analytics or third-party advertising trackers, and we do not use these metrics to build cross-site profiles.
Cookies and browser storage
We do not use advertising or tracking cookies. We use only first-party storage needed for features you request: an essential signed-in session cookie for up to 30 days; a security cookie lasting up to 10 minutes during optional federated sign-in; and local browser storage for chosen preferences and on-device authoring data. The security cookie expires quickly, and the session cookie is cleared when you sign out. Local data remains until you delete it or clear the site's browser data. Because there is no optional tracking storage to accept or reject, we do not display a cookie-preferences control. If that changes, we will ask for consent before activating it where required.
Data retention
We apply the following default retention periods unless law requires a different period, a workspace customer instructs us otherwise under an applicable agreement, or data is needed to resolve a live security, billing, or legal dispute:
- Local authoring: until you delete it or clear the browser's site data.
- Unimported Free capture bundles: seven days. Drained bookkeeping receipts are deleted after 60 days.
- Recently Deleted: recoverable for 30 days. After that, test-case content is wiped while a minimal sync tombstone remains; deleted run snapshots are removed.
- Share opens and analytics: the anonymous total open count lasts with the share. Detailed view rows last 90 days and are deleted sooner if the owner disables analytics or revokes the share.
- Expired and revoked shares: expired reports are unavailable immediately and their report-scoped content is deleted 30 days later. Revoked reports are unavailable immediately; deletion normally finishes in the same request, while a legacy signed report may be deleted after durable digest sealing completes. Verdict and signature ledgers associated with either are retained for 12 months from deletion, unless a personal owner deletes their account sooner. Previously cached previews can outlive the public link until the third party's cache expires.
- Execution snapshots: 12 months from when they were logged. Each test case's most recent result and any snapshot referenced by a shared report are kept regardless of age.
- Operational events: 12 months.
- Pro cancellation: personal cloud data has a 30-day grace period after the paid term ends before eligible data is deleted.
- Backups: deleted data may remain in private recovery copies for up to 35 days and is not restored into the live service except for disaster recovery.
Logged snapshots are kept as you logged them. Once a test run is logged, TestDossier doesn't rewrite the snapshot. You can delete a run for cleanup, but deletion removes the run instead of changing what was recorded. Shared reports keep showing the frozen copy that was shared, so viewers don't see quiet edits after the fact. Snapshots older than the 12-month retention period above are removed automatically.
If you free up image storage from your account settings, the image bytes are deleted from our object store but the test run row itself keeps its references. Old screenshots show as unavailable rather than the historical record silently changing.
Your rights
Depending on the circumstances and applicable law, you may ask us to access, correct, delete, restrict, or provide a portable copy of your personal data, and you may object to processing based on legitimate interests. Where processing relies on consent, you may withdraw it for the future. You may also complain to the data-protection supervisory authority where you live or work, or where you believe an infringement occurred.
The account-settings page provides Download all my data and Delete my account actions. For other requests, email support@testdossier.com. We may need to verify your identity and will respond within the period required by applicable law, normally one month under the GDPR. If an organization controls your workspace, direct content-specific requests to that organization first; we will assist it as required.
What account deletion removes: your email address, login sessions, personal projects and their content, personal shares, preferences, and the account link to subscription records. Associated object-storage keys are placed in a durable deletion queue and retried until complete.
What account deletion preserves and why: content contributed to a team workspace stays with that workspace so the organization's shared QA record is not destroyed by one member leaving. The live account and email mapping is removed, workspace author fields are replaced with a fresh opaque erasure identifier, assignments are cleared, and the operational event metadata associated with the account is scrubbed. Contact the workspace controller or support if particular workspace content also requires review.
Service providers and international transfers
We use Cloudflare for hosting, network protection, database, object storage, and aggregated web analytics; Resend for transactional email; Stripe Managed Payments for paid subscriptions; and Google only when you choose Google sign-in. These providers receive only the data needed for their function and act under their applicable service and data-protection terms.
Providers may process data in countries outside the EEA, United Kingdom, or Switzerland. Where transfer restrictions apply, the relevant provider terms must supply an approved mechanism, such as an adequacy decision or Standard Contractual Clauses, together with any required supplementary measures. Contact support@testdossier.com for the current provider list and the mechanism applicable to your data.
Contact
Questions about privacy? Email support@testdossier.com.