-
Notifications
You must be signed in to change notification settings - Fork 14
Help improve Bisq Mobile: opt‐in analytics
Bisq Mobile is built by a small team of volunteers. Opt-in anonymous analytics help us find bugs, prioritise fixes, and make better product decisions — which means a more reliable app for you. This feature is OFF by default. Nothing is collected unless you turn it on yourself.
If you're willing to help, opting in is the single most impactful thing you can do for the project short of contributing code. We get useful signal even from small numbers — a few hundred opt-in users tells us more about real-world reliability than thousands of bug reports.
| Default | OFF — nothing collected unless you opt in |
| What's collected | Which app screens you visit, and crash reports (redacted) |
| What's never collected | Trade data, addresses, balances, chat, identifiers, IPs |
| Where it goes | A self-hosted server run by Bisq Mobile maintainers (no third parties) |
| How it's transmitted | Tor-only — clearnet leaks are impossible by design |
| Retention | 90 days, then deleted |
| How to opt in / out | Settings → Help us improve Bisq Mobile (toggle, anytime) |
| How to verify | Read AnalyticsEvent.kt — every event the app is capable of sending lives in that one file |
When analytics is on, the app sends:
- Screen visits — which top-level screen you opened (Dashboard, Offerbook, My Trades, Settings, etc.) and when. We do not collect what's on the screen — no trade IDs, no offers, no balances, no peer names.
- Crash reports — when the app crashes, we receive the stack trace so we can fix the bug. Every stack trace passes through a redactor that strips Bitcoin addresses, emails, file paths, onion addresses, BIP-39 seed-shaped strings, and IP addresses before sending.
That's the entire list. The full set of events the app is capable of sending is hardcoded in AnalyticsEvent.kt as a Kotlin sealed class. Adding a new event requires modifying that file — which means it shows up in a public PR and a public commit. There's no generic track(name, data) API, no remote configuration, and no way to enable a new event between releases.
By design — not by promise — the app cannot send:
- Trade IDs, amounts, payment methods, counterparty info
- Bitcoin addresses, balances, transactions, payment proofs
- Chat messages or any chat-related content
- Fiat payment account data (account numbers, holder names, etc.)
- User profile names, public keys, or identifiers
- Device IDs, IP addresses, advertising IDs, hardware fingerprints
- Anything that could link two sessions to the same person
This isn't a promise we ask you to trust — it's a property of how the code is structured. The sealed event class only contains the events listed above; the redactor strips known sensitive patterns from every payload as a defence-in-depth layer. We physically cannot send what the code does not know how to send.
Events are sent to a self-hosted GlitchTip server running on infrastructure controlled by Bisq Mobile maintainers. GlitchTip is open-source error tracking — think Sentry, but self-hosted on a tiny VM.
There are no third parties in the pipeline. No Google Analytics, no Sentry-as-a-service, no Cloudflare. The data goes from your device, through Tor, directly to our server.
Analytics data is sent only over Tor. The server endpoint is a .onion hidden-service address, which has two consequences:
-
No clearnet leak is possible. A
.onionaddress is unresolvable without a Tor connection. If the Tor circuit isn't up, the SDK simply cannot send. There's no "fall back to HTTPS" path. - We can't see your IP address. Tor's anonymity properties apply to analytics traffic the same way they apply to your normal trade traffic. From our server's perspective, every event arrives from a Tor exit node, not from you.
- Tor trusted node (the default): analytics traffic rides alongside your trade traffic through your existing Tor circuit. No additional setup, no extra battery use.
- Clearnet (LAN) trusted node: analytics will pause and not send until you switch to a Tor connection. The settings toggle stays on; no data is sent in the meantime. The settings screen shows a "paused" status so you know. Your trade traffic is unaffected — only analytics is gated.
This is intentional. We won't start a new Tor circuit just for analytics, because that would change your network footprint without you asking. If you've configured a clearnet trusted node, we respect that choice and let analytics stay quiet.
Events are kept on the analytics server for 90 days, then deleted. That window is long enough to spot regressions across release cycles, and short enough that there's never a useful long-term dataset to leak or subpoena.
You'll see a prompt on your Dashboard at some point inviting you to help improve Bisq Mobile. Tapping accept gets you there. The prompt shows once — dismissed-forever afterwards.
Anytime, you can change your mind from:
Settings → Help us improve Bisq Mobile → Analytics toggle.
Changes take effect within a few seconds. No app restart required, no syncing across devices (each install is independent — opting in on one device doesn't opt you in elsewhere).
You don't have to take our word for any of this. Bisq Mobile is fully open source.
-
Event list:
AnalyticsEvent.kt— the canonical, complete, hardcoded list of what the app is capable of sending. Sealed class — cannot be extended at runtime. -
Redactor:
AnalyticsRedactor.kt— the patterns that strip sensitive data before sending, as a defence-in-depth backstop. -
Initialization:
SentryAnalyticsService.kt— when and how the SDK starts, what options are set.
If anything on this page doesn't match the code, the code wins — please open an issue or ping the maintainers and we'll fix the docs.
Will this slow down my app or drain my battery? No. Events are small (typically under 1 KB), sent asynchronously over your existing Tor circuit, and rate-limited. There's no background process — the SDK only does anything when you trigger an event.
Why opt-in? Wouldn't opt-out (default-on) give you more data? Yes, but it would also mean collecting data from people who never explicitly agreed. That's industry standard but it's not what Bisq stands for. We'd rather have honest, opted-in numbers from people who chose to help.
Can I see what's been sent from my device? Not yet. A local "events sent today" log is on the roadmap. For now, the most accurate audit is reading the source code linked above — every event the app can send is in one short file.
What if I opt in by accident and then change my mind? Just toggle it off in Settings. No data is retained client-side. Server-side, the 90-day retention means anything sent earlier will age out and be deleted automatically.
Do you sell the data? Share it with third parties? No, and we'd be defeating our own purpose if we did. The data is used by Bisq Mobile maintainers to find and fix bugs, and that's it. No aggregate dashboards shared with partners, no anonymised data sold to anyone.
Is the Bisq DAO involved? The Bisq DAO funds Bisq Mobile development. The analytics server itself is run by the Bisq Mobile maintainers on a tiny VM — DAO involvement isn't required at that level. The DAO does not have access to the analytics data.
Can you secretly change what's collected?
No. The event list is hardcoded in a Kotlin sealed class. Adding a new event requires a public commit to AnalyticsEvent.kt. You can watch that file's GitHub history. There's no remote configuration that could enable a new event between releases.
A new app version adds new event types — am I auto-consenting?
Updating the app is how you'd receive any new event types. If you want to review what's new before installing an update, check the changelog or read the diff to AnalyticsEvent.kt between versions. You can opt out at any time, and your opt-in status is preserved across upgrades (it doesn't get re-prompted unless you've never made a choice).
I run a Tor-paranoid setup. Is there any leakage risk?
The only way analytics traffic can be sent is over Tor — the .onion endpoint is unresolvable otherwise. If your trusted node is on clearnet, analytics pauses and sends nothing. We do not start a Tor circuit on your behalf without your trusted node already using one.
What about crash reports — do those leak personal data via stack traces? Possibly, which is why every stack trace passes through the redactor. We strip patterns matching Bitcoin addresses (legacy/P2SH/bech32/taproot), emails, file paths under common home directories, onion v3 addresses, BIP-39 12-word seed shapes, and IP addresses (v4 and v6). The sealed-event architecture is the primary guarantee; the redactor is the safety net.
Where can I learn more? The original design discussion: bisq-network/bisq-mobile#525. The privacy contract specifically: issue #525, comment 4256687436.
Last updated: 2026-06-08