Your data does not leave your machine
VeraTracer Desktop reads and writes files on your own disk and has no route to send them anywhere. That is a property of how the app is built, not a policy we promise to keep.
What runs where
VeraTracer Desktop is a native application: a Rust core with a web-technology interface, shipped through Tauri. It is not a web app in a wrapper, and it does not have a server component. When you run a workflow, the execution happens in the process on your machine.
Concretely, today:
- Source files are read from paths you chose, on your disk.
- Exports are written back to your disk.
- Checkpoints are held in the running process, not uploaded.
- No account exists, so there is nothing your data is attached to.
The app cannot phone home
This is enforced rather than intended. The application ships with a content security policy whose connect-src permits only the local IPC bridge:
default-src 'self'
connect-src ipc: http://ipc.localhost
img-src 'self' asset: http://asset.localhost blob: data:
font-src 'self' data:
style-src 'self' 'unsafe-inline'There is no remote origin in that list. The interface cannot open an HTTP connection to an external host, cannot load a remote script, and cannot fetch a remote image or font — the browser engine refuses the request before it is made.
No telemetry
There is no analytics SDK, no crash reporter and no usage tracking in the application. Nothing counts how often you run a workflow, and nothing reports which files you opened. This follows from the policy above as much as from choice: an outbound request had nowhere to go.
What the app is allowed to do
Tauri applications declare their capabilities explicitly. VeraTracer Desktop requests a deliberately small set:
| Permission | Why |
|---|---|
| core:default | Baseline window and event handling. |
| dialog:default | The native open and save pickers — how you choose what the app may read. |
| window:start-dragging | Dragging the window by its title bar. |
| window:destroy | Closing the window. |
Filesystem access is not granted through a broad plugin scope. It goes through specific commands in the app's own Rust layer, reached from paths you selected through a native dialog.
How this changes with hosted runs
Being straight about this, because it is the part that actually involves risk. A hosted run executes on our infrastructure, so it reads from sources the server can reach rather than your local disk. The guarantees above are properties of running locally and do not automatically carry over.
These questions are open, and we would rather list them than imply they are settled:
- Which regions runs execute in, and what that means for residency.
- How connectors authenticate to your warehouse without credentials resting somewhere they should not.
- Retention — how long a hosted checkpoint lives.
- Isolation between tenants.
Until those have answers, hosted runs are not available. See hosted runs for the current state.
This website
Separate from the app. The site is statically generated and serves no third-party scripts, trackers or advertising. The sign-in and sign-up forms are interface only — there is no accounts backend behind them yet, and nothing submitted through them is stored or transmitted.
Reporting a vulnerability
Email security@veratracer.com. Please include enough detail to reproduce the issue, and give us a chance to fix it before disclosing publicly.
We will confirm receipt, tell you whether we consider it in scope, and keep you updated until it is resolved. We do not currently run a paid bounty programme.
Status of this page
VeraTracer Desktop is pre-release. The properties described here are true of the current build and verifiable in the application bundle, but the product has not yet been through an external security audit. When it has, this page will say so and give the date.