BanditKin Privacy Policy
BanditKin is an end-to-end-encrypted location and messaging app for your circle. Only your circle's devices hold the keys to its private content. Online navigation, public camera reports, purchases, and support reports have different data flows, explained below; they are not private circle messages.
Private circle content and operational metadata
End-to-end encrypted (our relay stores ciphertext it cannot decrypt):
- Circle location, accuracy, speed, heading, and location history
- Circle/member display names
- Messages, reply/reaction contents, and voice clips
- Place names and boundaries, arrival/departure alert contents
- SOS and check-in contents
The initial circle key is created on your phone and shared by an in-person QR scan or an explicit text invitation through a channel you choose. Key rotation can pass through the relay only encrypted with the previous circle key. The relay never receives a readable circle key.
Visible to the relay: random circle/device identifiers and membership, coarse platform labels, timestamps and encrypted-payload sizes, battery/charging/online status, app-health flags, alert/event types, and your circle's cloud-plan status. Hosted pairing stores a generic hardware label ("Mobile device"), not the submitted detailed model name. An issue report can include detailed model/OS information when you choose to send it.
Requests to the circle relay expose a source network address to the relay and its hosting provider, Fly.io. The application uses a truncated SHA-256 digest of the address in short-lived, in-memory abuse-limit counters. BanditKin does not store the address with circle records or use it for advertising. Providers also process connection metadata needed for delivery and security. Cloudflare serves public map files and the OHTTP relay described below; it is not the current hosted circle-data store.
We use operational metadata to deliver and protect the service, not to sell profiles or target advertising. The Android app contains no third-party analytics or advertising SDK.
Google/Firebase wake-ups in the Play build
Firebase Messaging auto-init is disabled. After pairing and E2E readiness, the app initializes Firebase and registers a messaging token with our relay. Google processes installation/messaging identifiers and network/timing metadata needed for delivery. Our relay replaces the token when registration changes and removes it from active storage when that device or circle is deleted.
The FCM application payload is exactly {"wake":"1"}: no circle/device ID, location, destination, query, message, audio, or encryption key. The app then fetches encrypted events from BanditKin. Token rotation is not a claim that Google has deleted its own installation records. The self-host build contains no Firebase SDK; it uses the relay's direct event transport instead.
App updates in the self-host build
The self-host app checks BanditKin's fixed HTTPS release endpoint on app launch and can check again while its foreground service runs. Background checks are throttled to no more than approximately once an hour, not guaranteed on an hourly schedule. The host sees the network address and normal HTTP metadata; the check sends no circle or device credential, relay address, location, message, place, destination, query, audio, or encryption key. Accepted updates come from that endpoint; Android checks the APK signing identity. The Google Play build does not use this APK updater.
Google Play purchases in the Play build
Google Play processes the purchasing Google account, payment method, price, region, and transaction under Google's terms. BanditKin does not receive card or bank details. The app sends Google a SHA-256 obfuscated circle value rather than its readable random circle identifier. The plan screen checks the circle's relay-side coverage on opening and before checkout to help prevent an unnecessary second purchase; this is not a guarantee against simultaneous purchases from different phones.
For verification or restore, the app sends the product ID and opaque purchase token through its authenticated HTTPS connection. The relay uses the Google Play Developer API to check the purchase. Raw purchase tokens are processed for those checks, not saved in the circle registry. That registry holds product, status, applicable expiry, and purchase-token digests linking ownership to a circle. Ownership claims are removed when the circle is deleted.
Google real-time billing notices pass through Google Cloud Pub/Sub in BanditKin's project. The configured undelivered-message retention is seven days. Notices can contain purchase tokens. The relay authenticates the push identity, audience, and payload before processing it; ordinary updates trigger purchase verification, while an authenticated full-void notice can directly block the purchase without another purchase API call.
The relay records a notice's message ID, token digest, type, outcome, and processing time to prevent duplicates. Its event table is capped at 20,000 records and removes records older than 30 days when a subsequent billing event is written. If no new billing event arrives, older records can remain until that cleanup runs; this is not an exact 30-day physical-deletion guarantee. These records do not contain raw purchase tokens or circle message contents.
A full refund/revocation notice can also create a permanent, digest-only block record containing the purchase-token digest and processing time, without a circle identifier. This record survives circle deletion to prevent the same voided token from reactivating service. A goodwill refund without revocation can leave access intact. The dedicated billing-failure log records only an allowlisted operation/error code and notification type, not a token, circle ID, device ID, message ID, or raw provider diagnostic.
Billing does not send private circle locations, messages, Places, audio, route destinations, or E2E keys to Google Play. The self-host flavor contains no Play Billing library and does not require a BanditKin Cloud purchase.
Support reports
"Report an issue" deliberately sends readable text, selected feature, app/build/platform diagnostics, random device/circle identifiers, and an optional email address to the operator. The screen discloses this before send. Relay copies follow the approximately 90-day cleanup policy below. Delivered emails can also be held by the configured mail provider; contact us about deletion of a delivered support copy.
Background location
When circle sharing is enabled, BanditKin reads location even when the app is closed or not in use. Private circle locations are encrypted before upload; only paired circle devices can read them. They are not used for advertising. Pause sharing, revoke location permission, or remove the device to stop sharing. Offline fixes may be queued encrypted on the phone and uploaded on reconnect. This does not add a new recipient or category of circle data.
Maps, public cameras, and community reports
Installed base-map packs derived from OpenStreetMap render on-device without a base-map viewport request. Downloads and installed-region updates contact public file/catalog hosts such as maps.banditkin.com on Cloudflare. Those hosts see the requested public file and network address, not a circle credential.
Build 313 adds automatic Android Auto display-map detail in Anonymous Online mode (the default), or after a private-mode driver allows online access for that car session. Where supported, the app retrieves small fixed map areas through OHTTP instead of downloading a whole state. Cloudflare's relay sees the network address and encrypted request; the Fly gateway sees archive names and byte ranges, from which map areas can be inferred. The public map host sees the gateway's request. These requests have no circle/account/device identifier, but they are not E2E circle content and are not a guarantee against correlation. A generic signed catalog is fetched directly from the public catalog host, which sees the network address but no selected map area in that request. Existing downloaded maps take priority. Private modes do not automatically fetch these display areas without the session grant; previously cached areas can still be displayed. The temporary on-device detail cache is size-limited and may be evicted; it is not a replacement for explicitly downloaded offline maps. An already in-flight request may finish after changing modes.
The on-by-default camera layer has a separate network flow even while the base map is offline.
Camera/U-turn reads. The official endpoint uses OHTTP with fixed 0.05-degree map-grid boundaries. Cloudflare's relay sees the network address and encrypted request; the Fly gateway and public camera service see the requested cells, not a circle/device bearer. A custom camera endpoint is a separate trust choice and can receive the address and map area directly. Turning the layer off stops its automatic overlay reads; explicit reporting and navigation features that request camera data are separate actions.
Optional public reports, proposals, and confirmations. Build 310 can submit camera/U-turn positions, additions, edits/removal proposals, and confirm/reject votes. These are public-service submissions, not circle E2E content. A submitted feature can be close to your own position. The app includes bounded nearby-fix summaries: fix count, observation span/age, closest distance, best accuracy, and a mock-location flag; it does not submit the underlying location trail. A confirmation also sends the feature ID and an anti-abuse challenge response.
Reports use scoped pseudonymous handles derived on-device. Report handles vary by feature/type, coarse cell, and UTC week. Confirmation handles are stable for a particular feature to detect repeated votes; they do not guarantee total anonymity or prove independent people. No circle bearer or readable member name is sent. The gateway can read submitted feature coordinates. Its legacy feature-report path rounds them to a 0.00025-degree grid (roughly 25-28 metres north/south) before forwarding. This is not a promise that exact submitted coordinates never reach BanditKin.
Pending reports are shown distinctly and do not by themselves drive alerts or avoidance. Build 310 also recognizes a service-provided community_confirmed status: qualifying nearby confirmations can make an addition/edit usable for alerts and navigation while moderator review remains open. Removals require moderation. Supported submission paths depend on the deployed gateway/service. Public feature and scoped anti-abuse records are separate from circle storage; deleting a circle does not automatically delete them. Contact us about public report corrections/deletion. Pseudonymous records are not necessarily non-personal merely because they omit a name.
No user-reported road-hazard feature is enabled in this release. This is separate from provider traffic-aware routes and traffic display in Anonymous Online navigation. The app does not expose a user-report feed for crashes, closures, construction, weather, or responders.
Map/camera source data includes OpenStreetMap contributors (ODbL).
Navigation and search
In Fully Private and Private Online Assist modes, route calculation and search run on-device: typed queries and exact route endpoints are not sent to an online routing/search provider. Public area/camera data can still be fetched as disclosed above. In Private Online Assist, missing fixed public area objects may be requested through OHTTP; absence fails closed rather than falling back to a route-shaped direct fetch. Explicit regional downloads can contact a selected HTTPS host, which sees the public region/file and network address.
Anonymous Online is the default navigation mode unless an earlier choice was saved. You can select a private mode before search or routing. Anonymous Online sends typed search text with client-coarsened proximity and exact route start/end coordinates to the provider (currently Mapbox) through OHTTP. Traffic-aware rerouting can make further requests during a trip. Requests contain no circle/device bearer, advertising ID, message, or E2E key. Extra Permissive Routing changes route options, not the identity fields sent.
OHTTP splits visibility: Cloudflare's relay sees the phone's network address and encrypted request; the Fly gateway sees the decrypted operation from the relay; Mapbox/public-data hosts see the gateway. BanditKin operates both relay and gateway. The design disables correlation/request logging, but it does not make one operator cryptographically incapable of correlating separately obtained observations. OHTTP is not end-to-end secrecy from the gateway/provider.
Retention and deletion on the current Fly service
The hosted circle-data store is a Fly.io file volume, not Cloudflare SQLite. Routine compaction targets 24 hours for location history/stale live pins, 30 days for messages, encrypted voice files/metadata, event and delivery/ack records, and 90 days for issue reports. Shorter disappearing-message timers can apply. Cleanup is periodic, not exact at the cutoff second; an outage can delay physical removal. Active SOS state lasts until cleared or its device/circle is deleted. Member labels, Places, and circle configuration persist until removed. Billing retention and permanent refund blocks follow the separate rules above.
Reset this device first requests relay-side device deletion. If it cannot confirm success, the app offers retry or an explicitly disclosed phone-only erase. A founder with the circle admin credential can delete the whole circle, including after plan expiry. Whole-circle deletion removes its active data, credentials, Firebase tokens, and purchase claims. Device removal does not mean all shared Places or other members' records are deleted. Key rotation protects future content; it cannot erase copies already delivered to other phones.
To recover interrupted device removal or a lost deletion response, the relay may temporarily retain a SHA-256 credential digest, the random circle ID, an expiry time and, for device removal, the random device ID and a cleanup-only type marker. These records expire after one hour, do not restore access and contain no raw credential or private circle content.
Scheduled Fly volume snapshots are currently configured for five-day retention. Deleted content and operational metadata may remain in that provider recovery history until the containing snapshot expires; circle payloads remain E2E encrypted. A backup is not the active service. Self-host operators control their storage and backups. Already delivered support emails and Firebase wake-ups cannot be recalled; contact us about support-copy deletion. Any added backup policy must be disclosed when introduced; the five-day statement is about current Fly snapshots.
Abuse protection
The current file relay uses short in-memory windows keyed by route and a truncated SHA-256 of a network address or credential. Counters reset on process restart and are not saved as circle profiles. They are abuse/cost controls, not a guarantee against every distributed attack. Public-report scoped handles and billing anti-replay records follow their separate rules above.
Website visits
The Android SDK statements above do not mean website visits are invisible. The website host receives browser network metadata. The current website also includes a Tawk.to support-widget loader, including on informational pages; loading it can expose browser/network metadata even without a chat. Information you send in support chat is readable by the operator and provider, not circle E2E content. Website support and browser-storage choices are separate from Android circle sharing.
Children and contact
BanditKin is intended to be set up and managed by an adult for their circle. Questions or deletion requests: privacy@banditkin.com.
We update this policy as the product evolves. Material changes will be noted in the app's release notes.