Trust & Compliance

Cookie-free architecture

Mitr never sets a cookie, first-party or third-party — but "no cookies" isn't actually the property that determines whether a consent banner is needed. EU/UK law (ePrivacy Art. 5(3), UK PECR) regulates storing or reading anything from a visitor's device for non-essential purposes — cookies, localStorage, anything. A lot of "cookie-free" analytics tools still persist a device ID in localStorage instead of a cookie, which is the same category of thing under that law, just a different API. Mitr doesn't do that either, for anonymous visitors. Here's the actual mechanism:

For an anonymous visitor (no identify() call — the default), the SDK doesn't generate a device ID, doesn't write to localStorage or SharedPreferences, and sends no identifier at all. The backend computes a pseudonymous ID entirely server-side, from the request's IP address and User-Agent — both already present on every HTTP request regardless of what the SDK does — mixed with a secret salt that rotates every 24 hours and is then shredded. The same visitor browsing today gets a consistent ID across their pageviews (so sessions, bounce rate, and daily unique visitors all work normally), but that ID has no relationship to the one the same visitor gets tomorrow. There's no database query, no key, no backup that could reconstruct "was this the same person a week ago" — the salt that would make that possible doesn't exist anymore by then.

This isn't a smaller version of tracking — it's a structurally different mechanism. A localStorage device ID and a rotating server-side fingerprint might sound similar, but only one of them involves writing anything to the visitor's browser, which is the actual thing consent-banner laws regulate. Nothing is ever written for an anonymous visitor, so there's nothing to have gotten consent for.

identify(userId) is a separate, opt-in mechanism: if your own app has its own logins, you can tie events to your own user ID instead of anonymous tracking. That id is hashed client-side before it's sent, and — because it's specifically meant to survive across app restarts without you calling identify() again — it is persisted locally, the same way a login/session token would be. That's a narrower, more defensible case under the "strictly necessary for a requested service" exemption most of these laws carry (maintaining a login session is one of the standard examples regulators exempt), and it's your call to make for your own logged-in users, not something Mitr does automatically for anonymous traffic.

You can watch client-side hashing happen in real time in the interactive demo on the homepage — type any identifier and see its SHA-256 digest compute live, entirely in your browser (this is what identify() does; anonymous tracking doesn't hash anything client-side because there's nothing local to hash).

Dashboard sessions work independently of all this: a PASETO token is issued at login and kept in your browser's secure local storage, not a cookie — that's Mitr's own dashboard login, unrelated to how your site's visitors are tracked.

Both SDKs also respect the browser's Do Not Track signal, on top of all of the above. If it's set, initialization installs no auto-tracking, drains no queued events, and every tracking call becomes a no-op — zero network activity for that visitor, not a filtered subset of it.

See the full regulation-by-regulation reasoning on our Cookie Policy.

Automatic PII detection

Custom event properties are the one place a client integration could accidentally leak PII — a developer might pass a real email or phone number as a property value without thinking about it. Every property on every event is scanned at ingest for values that look like an email, phone number, SSN, or credit card, and for known-PII field names regardless of what the value looks like. Anything flagged is hashed in place, the same way, before the row is ever written — the raw value never reaches storage.

This isn't a separate marketing claim from what the dashboard shows you: the "PII Intercepted" count on your dashboard and the per-field warning badge in the Event Inspector both read the exact same flag written at ingest time. There's no second system that could drift out of sync with what's actually stored.

Compliance alignment

Data retention & right to erasure

Every plan has a retention window, enforced in two stages, not just promised. Once an event ages past your plan's window, it's marked deleted but held for a 30-day grace period — recoverable if you or your visitor dispute the deletion — before it's permanently purged. Every purge is logged to an append-only audit trail your dashboard can show you, so "we deleted it" isn't something you have to take on faith.

You can also delete a specific visitor's data on demand — every event is keyed to an opaque, one-way hash (never a raw email or device ID), so deletion works by that hash directly from the dashboard's event list. There's no lookup path from a real identity to that hash in the first place, which is what makes targeted deletion possible without Mitr ever having held the identity it's deleting.

Verify it yourself

Every mechanism on this page has a corresponding place in your dashboard where you can see it working, not just read about it:

• Privacy Audit Shield (dashboard home) — real counts for PII interceptions, retention days remaining, last automatic purge, and visitor deletions, computed live from your own data.
• Event Inspector (dashboard, click any live event) — the full raw payload Mitr actually stored for that event, including a badge on any property that was caught and hashed as suspected PII.
• Data export — download your raw events as CSV or JSON for any date range, exactly as stored.
• Audit log — the append-only record of every deletion and retention purge that's run against your data.

Security practices

• Transport: HTTPS/TLS on every endpoint — SDK ingestion, dashboard API, and this website. No plaintext HTTP is served.
• Identifier hashing: SHA-256, applied client-side in the JS and Flutter SDKs before any request leaves the device.
• Access scoping: every API endpoint checks workspace ownership before returning data, so one client's data is never visible to another.
• At rest: encryption at rest is part of our production hosting setup — this page will be updated to confirm it's active once infrastructure is live.
• No third-party trackers: this website and the dashboard load no third-party advertising or analytics scripts, and embed no cross-site tracking pixels.

See the full write-up in Privacy Policy §4.

Sub-processors

We keep this list short on purpose — the fewer parties that touch your data, the fewer promises we have to make on their behalf.

Full policy: Privacy Policy §5.

Mitr vs. cookie-based analytics