privacy policy
privacy policy
Updated: September 23, 2026
At weBump, we believe nearby social interactions should not come at the cost of global constant tracking. This Privacy Policy explains how we collect, use, store, and protect data when you use the weBump mobile application (the "App"), our backend services, and the weBump developer portal.
1. Core Privacy Principles
- No Constant GPS Tracking: We do not maintain a travel history, record your exact locations, or track you on a live map.
- Local-First Handshakes: Proximity matches are recorded using local Bluetooth Low Energy (BLE) signals. Your ordinary proximity handshake history stays on your device. Optional connected-game handoffs use temporary server eligibility and duplicate-reward records, as described below.
- Gradual & Controlled Reveal: You decide exactly what parts of your profile are shared with users you bump into before adding them as friends.
- Under-18 Protection: We do not show anyone's age range on their public card. School sharing with non-friends is disabled for users under 18.
- No Address Book Uploads: weBump does not scan, access, or upload your device's contacts or address book.
2. Information We Collect and How We Use It
A. Account & Installation Data
The mobile App does not require passwords, email registration, or third-party OAuth sign-ins. Developer portal access uses email verification, described below.
- Installation Credentials: Registration gives the App a private Installation ID, a randomly generated secret, and a Public Tag. The App stores these credentials in your device's Keychain. The server stores a hash of the secret for authentication, not the secret itself. The Installation ID is linked to your profile on our service; it is not broadcast over Bluetooth.
- Friend Code: The server generates a unique, randomized Friend Code (e.g.,
WB-ABCD-EFGH) linked to your installation, allowing you to invite or add trusted friends. - Metadata: We store your platform (iOS), application version, and the timestamp of when you were last seen.
B. Profile Information
You have control over your profile details. You can choose to provide and publish:
- Display Name, private age range, State/Region, and School. Current profile writes store an age range rather than an exact age. The server may return only a "Similar age" match to another user, not your range. Historical backup or retained rollback copies may still contain older records until their separate retention lifecycle ends.
- Bio / Blurb (up to 250 characters).
- Theme Colors & Badge Titles.
- Social Media handles (Instagram, TikTok, X, Snapchat, YouTube, Threads).
- Gaming Platform handles (Nintendo Switch, Steam, PlayStation Network, Xbox).
- Apple Music Metadata: The App requests MusicKit authorization to search the Apple Music catalog. If you choose a favorite item for your profile, we store its selected catalog metadata (such as title, artist, artwork URL, catalog ID, and web URL). We do not upload your music library or Apple account credentials to our server.
Note on Visibility: You can choose whether non-friends see your general area, school, bio, selected music, and social handles. Your age range is not shown to them. For users under 18, school sharing with non-friends is disabled.
C. Proximity Discoverability & Rolling IDs
To discover nearby devices without transmitting your persistent identity:
- The App generates a rotating, anonymous local identifier called a Rolling ID which is broadcast via Bluetooth Low Energy (BLE).
- This Rolling ID rotates every 10 to 15 minutes to prevent replay attacks or continuous tracking of your device in public areas.
- A Rolling ID can be resolved until one day after its epoch ends. Protected mappings are retained for seven days for reconciliation and removed by the daily cleanup. Retaining a mapping does not extend its resolution window.
D. Coarse Location Density
If you opt to check local activity density:
- The App sends your current coordinates to our server.
- The server immediately rounds your location to a coarse grid (approximately an 11km x 11km area bucket).
- We do not save your precise latitude and longitude. We save only the coarse grid ID and the time of the query to calculate general street density levels (e.g. "growing" or "active") and return them to nearby users.
E. Safety, Moderation, & Abuse Prevention
To enforce our EULA and protect the community:
- If you report a user or are reported, we collect the report details (reason, text details, and a snapshot of the reported profile at the time of the incident).
- We store user blocks (the blocker and blocked installation IDs) on our server to prevent blocked users from interacting with you.
- Before publishing profile changes, we may automatically review your display name, school, and bio for harmful content, unsupported contact details, or other EULA violations. Rejected profile submissions may be retained with the moderation decision and provider result for abuse review and enforcement.
F. Service Analytics
To keep the service reliable and understand launch health, we record aggregate backend counters such as daily install counts, profile publish outcomes, discovery loads, bump resolution outcomes, friend request outcomes, referral outcomes, push token registrations, and rate-limit hits.
- These counters are grouped only by day, route, outcome, platform, and app version.
- They do not store precise locations, Friend Codes, Rolling IDs, profile content, Bluetooth encounter history, or a central history of who bumped whom.
- We use these counters for reliability, abuse prevention, and product health. They are not sold or used for advertising.
G. Request Security and Rate Limits
To keep the App, game API, and developer portal available, the server processes IP addresses and request identifiers for admission, rate limiting, and abuse prevention. First-party rate-limit database keys are stored as keyed hashes rather than raw IP addresses and become eligible for deletion after two days without use; daily cleanup removes them afterward. Temporary in-memory limits also use IP addresses or an installation/token fingerprint. These security controls are separate from the aggregate service counters above.
3. On-Device Storage (Local Data)
Your proximity handshake history is stored locally on your device (in the App's private UserDefaults database). This history contains:
- Scanned Rolling IDs of nearby peers.
- The date/time of the encounter.
- An estimated proximity indicator (e.g., immediate, near, around, far) based on Bluetooth signal strength (RSSI).
- A cache of profiles resolved from those encounters.
We cache up to 200 of your most recent handshakes on your device, overwriting older logs automatically.
4. Third-Party Services & Data Collection
To support our operations, we integrate the following third-party services:
weBump operates its own backend and database. Supabase remains a compatibility relay for older app versions and a retained rollback copy.
A. Google AdMob (Advertising)
Unless you have acquired a "Supporter Badge," weBump shows rewarded advertisements.
- Google AdMob may process IP addresses, ad interactions, performance or crash data, and device identifiers. The iOS advertising identifier (IDFA) is available to AdMob only when you allow tracking through Apple's App Tracking Transparency prompt.
- You can manage ad tracking preferences using iOS system settings (under Settings > Privacy & Security > Tracking).
B. Apple Push Notifications (APNs)
- We collect and store APNs push tokens on our servers to deliver friend request alerts and proximity notifications.
- If a push token is inactive for 90 days, it is deactivated, and it is permanently deleted from our servers 30 days later.
C. OpenAI Moderation API (Profile Safety)
- When your profile text changes, our backend may send your display name, school, and bio to OpenAI's moderation API to help detect harmful or disallowed content before publishing.
- This processing is used only for safety, abuse prevention, and app functionality. It is not used for advertising or tracking.
- OpenAI may process and retain API inputs and outputs according to its API data-use and abuse-monitoring policies.
5. Data Retention & Account Deletion
- Account Deletion: You can request deletion of your weBump installation and associated App data by opening Settings and tapping "Delete Account & Start Over".
- What is Deleted: The App first asks the active server to delete your installation record, credentials, rolling IDs, profile settings, relationships, push tokens and connected-game data. Local handshake logs and Keychain credentials are cleared after that server confirms deletion. If the request fails, you can retry.
- What is Retained for Safety: To prevent ban evasion and maintain platform safety, moderation reports and rejected profile safety snapshots may be retained when an account is removed.
- Copies and Backups: Our current encrypted-backup rotation retains up to 24 hourly, 14 daily, eight weekly, and 12 monthly snapshots. The retained Supabase rollback database is a separate historical copy and is not automatically erased by Start Over on the active server. Contact support@webump.app with questions or a deletion request concerning historical copies. Data that another person or game already downloaded cannot be recalled; connected games are required to remove cached personal data when access ends at their next sync.
Automatic Server Cleanup: To keep our systems clean, our database automatically runs a daily purge:
• Protected Rolling ID mappings older than the seven-day retention window are deleted. Resolution still expires one day after the epoch ends.
• Installations that never publish a profile are deleted after 7 days of inactivity. Other installations remain until you delete them.
• Stale friend requests and requests older than 30 days are deleted.
6. Children's Privacy
weBump does not permit registration or use by anyone under the age of 13. If we discover that we have collected information from a child under 13, we will immediately delete that installation and all associated data.
7. Optional Connected Games
When available, you must approve a game inside weBump before it can access your own game data. Basic visitor-card sharing starts on for new and existing users unless they have saved a different choice. An approved game played by someone you bump may receive your display name and color even if you do not play that game. You can turn this off or exclude individual games in Connected Games. Only bumps after sharing starts can qualify. Each game’s selected stats stay private until you separately enable sharing for that game. Games receive no installation secret, friend code, age, school, location, other games' private saves, or general encounter history.
A game may also ask for a separate option to share selected game data, such as a custom design or challenge. It is offered when you connect and can be turned off there or later in Connected Games. When it is on, that game can publish a selected copy of its reviewed data for authorized visitors who use the same game. This does not expose your private save and does not appear on your weBump profile. Your connection, sharing choice and the start of uninterrupted publication must predate the eligible bump. Published copies expire after seven days; visitor access may expire sooner. Updating an unexpired publication lets already eligible visitors retrieve the latest selected data. After withdrawal or expiry, a new publication requires a later eligible bump. Ordinary reconnects preserve active sharing when you keep those choices enabled. Turning this option off, disconnecting, or revoking the game's grant removes the published copy; your private supplemental save is retained until you delete it or normal account cleanup applies.
Games receive a random visitor identifier that lets the same player recognize your repeat visits within that game, even if you change your name or color. Different games and receiving players get different identifiers. Recognition lasts while unexpired seven-day receipts maintain the relationship; reading a card does not extend it. Sharing opt-out, game exclusion, blocks, explicit game disconnect or revocation, and deletion reset the affected relationships. The identifier cannot fetch a profile or bypass sharing settings. Your phone retains receipt references locally. Our server keeps temporary eligibility references linking the observer, game and visitor so it can enforce consent, blocks and reveal delays. References expire after seven days, a requested transfer expires after five minutes, and duplicate-reward records expire after eight hours. Expired records are removed by the next daily cleanup, which can take up to another 24 hours. No visitor list or card data is placed in a link.
If you enable “Show on my profile” for a connected game, everyone who can view your profile can see its reviewed icon, title, launch link, and selected public fields. Private game saves are never published. The Games section stays hidden when you have no visible games. Hiding a game, disconnecting it, or blocking a viewer stops new access; previously viewed information cannot be recalled. Game icons are served by weBump rather than fetched from developer tracking URLs.
Connected Games lets you inspect recipients, exclude a game, withdraw sharing, disconnect, or delete game data. Withdrawal stops pending cards and subsequent refresh access. Games must remove cached personal data at their next sync; already downloaded data cannot be recalled. Disconnect retains supplemental state; Delete Game Data removes it. Account deletion also removes connected-game grants and data. Games should keep local saves as their primary progress. Backup copies follow the service's backup lifecycle.
Connected games are run by their own developers. Each approved game provides its own privacy and support links. Review those practices before connecting, especially if the game asks you to publish stats or selected game data. weBump reviews each project's requested permissions and requires developers to honor access withdrawal, but cannot erase information a game has already downloaded from that developer's own systems.
This update explains the default-on visitor card and how to turn it off. Saved sharing choices are preserved. Connecting an app and sharing its game stats still require separate choices; the visitor-card default does not connect games or enable game-stat or selected-data sharing.
8. Developer Portal
Developers who apply to connect a game use email verification. We collect their email address, contact name, organization (if supplied), project description, requested permissions, callback and support/privacy URLs, domain-verification result, agreement acceptance and review history, and an uploaded game icon. We use these records to verify ownership, review and operate projects, contact applicants, enforce limits, and investigate abuse. Applicant icons are sent without the applicant's identity to OpenAI's moderation API for safety screening before human review; rejected icon files are not stored, but a screening verdict may be retained. Approval and status emails are delivered through Resend.
Developer sign-in uses short-lived email codes and secure browser sessions. The portal processes IP addresses for admission and rate limits; persistent quota keys use hashes. Expired sign-in challenges, sessions, and synthetic playground data become unusable immediately and are removed in daily maintenance. Unapproved accounts expire after 180 days; sent email-outbox records are removed after 30 days. Approved account, project, agreement, and review records remain while access is retained. The public playground uses fictional profiles and does not expose real player data.
9. Contact Us
If you have any questions or concerns about this Privacy Policy or our data practices, please contact us at:
- Email: support@webump.app