Bouncer stores your blocklist, call log, and settings locally on your device. zeroemdashes has no access to that data unless you choose to send some of it, as described below.
Starting with the subscription-model release, Bouncer also uses Firebase Analytics to record a small set of anonymous usage events: blocked-call milestones and subscription funnel signals. These events never contain phone numbers, contact names, or per-call timestamps.
Bouncer shares your block list: the phone numbers and number ranges on it. Bouncer uses them to find spam numbers for everyone. It never sends your contacts, your call history or anything that names you. You can stop sharing at any time in Settings, and your shared block list is deleted.
If you tap Report spam or Not spam on a call in the call log, Bouncer sends that one number and what you said about it. Nothing else from your call log is sent.
zeroemdashes is an independent software publisher operated by Bojan Gasparovic. This privacy policy applies to apps and products published under the zeroemdashes name, including Bouncer for Android.
All call-blocking data the app works with stays on your device at all times. zeroemdashes has no access to any of it.
| What is stored | Where | Why |
|---|---|---|
| Your custom blocklist (phone numbers and optional labels) | On-device Room database | So the app knows which numbers to block |
| A log of screened calls (number, contact display name if matched, timestamp, outcome) | On-device Room database | So you can review what was blocked or allowed through |
| Your settings (blocking mode, blocking action, master toggle state) | On-device DataStore | So the app remembers your preferences |
None of this information is uploaded to any server, except your shared block list and the numbers you report, as described in Sections 2c and 2d. None of it is shared with any third party. None of it is used for any purpose other than making the app work for you.
Starting with the subscription-model release, Bouncer sends anonymous usage events to Firebase Analytics (Google LLC).
Every event is a count or a fixed category label. None of them ever includes a phone number, a contact display name, the content or audio of a call, or a per-call timestamp.
The events fall into four groups:
Bouncer also sets a small number of user properties, which Firebase attaches to later events so that usage can be grouped by state. These record the current entitlement (free, grandfathered, subscription or lifetime), whether blocking is switched on, and whether the call-screening role is held. Each is a fixed category label.
This section describes the categories of data collected rather than naming every individual event. The specific events may change from one release to the next, but they will remain within the categories and limits described here. If that ever ceases to be true, this policy will be updated and the effective date changed, as described in Section 9.
In addition to these custom events, Firebase Analytics automatically collects certain data from every app that uses its SDK: a Firebase Installation ID (a pseudonymous per-device identifier that can be reset), device model, operating system version, device language, country (derived from IP address by Google), app version, and session-level events such as first open and session duration.
Advertising ID collection is disabled. The google_analytics_adid_collection_enabled key in AndroidManifest.xml is set to false, which prevents the Firebase SDK from reading the Google Advertising ID (GAID) on Android. The GAID is not collected.
Bouncer shares your block list to build the spam list. On a new install, sharing is on from the start. On an install from before version 3.7 that does not share yet, Bouncer asks first, when you turn on Block spam numbers, and nothing is sent until you agree.
What is sent: every phone number and number range on your block list, the country of your SIM card, the app version, and a random identifier made for this purpose on your phone. The identifier is not your Firebase or advertising identifier and is not linked to them. Labels you gave numbers are never sent. Your contacts, your call history and your allow list are never sent.
When: once when sharing starts, then again whenever your block list changes.
What we do with it: a number on one phone's shared block list becomes suspected spam in the spam list that Bouncer gives every user. Once two different phones have it, by sharing or by reporting it (Section 2d), it becomes known spam. Where phones blocked several numbers close together, the spam list can also hold a range of 100 numbers as suspected spam. People choose in Settings whether Bouncer blocks known spam, suspected spam or both. The spam list contains phone numbers and ranges only, with nothing about who shared them.
Stopping: Settings, Blocking rules, "Stop sharing my block list". Bouncer stops sending, turns Block spam numbers off, and asks the server to delete your shared block list. Turning the Block spam numbers switch off on its own does not stop sharing.
In the call log, a call can offer Report spam or Not spam. Report spam also adds the number to your block list; Not spam stops spam blocking for that number on your phone. These are separate from sharing your block list: they work whether or not you share it, and whatever blocking mode you use. Nothing is sent until you tap one.
What is sent: the one phone number you reported, whether you said spam or not spam, the app version, and the same random identifier as in Section 2c. Nothing else from your call log is sent: not the time of the call, not its length, not any other number.
What we do with it: one phone reporting a number as spam makes it suspected spam in the spam list; two phones make it known spam. One phone saying a number is not spam makes it at most suspected; two phones take it out of the spam list for good. The identifier only lets us count each phone once.
Stopping: after you report a number, the call log offers Undo spam report or Undo not spam. Tapping it asks the server to delete that report. Reports are kept when you stop sharing your block list, because each one was its own choice. To have all your reports deleted, email support@zeroemdashes.com.
Besides what people share and report, the spam list includes numbers from public spam lists, such as complaint data published by the US Federal Communications Commission and community lists of spam numbers in other countries. These contain phone numbers only.
Bouncer can show the name of a number that calls you: in the call log, in the blocked call notification and on screen while the phone rings. To find the name, your phone asks our server for the names in a block of 100 numbers that holds the caller's number.
What is sent: the caller's number without its last two digits, so the request covers 100 numbers and never says which one called. Like every request over the internet, it also carries your phone's IP address. No identifier is sent: not the random identifier from Section 2c, and not your Firebase or advertising identifier. Numbers in your contacts and withheld numbers are never looked up. Your phone keeps each answer, so it does not ask about the same 100 numbers again until the names are updated, about once a month.
What we keep: nothing. The server answers the request and does not record it, the digits in it or your IP address.
Where the names come from: public place listings published by the Overture Maps Foundation, and names that people gave a number in public reports on spam websites. The data sources are listed on the Bouncer page. If your number is listed and you want it removed, email support@zeroemdashes.com.
Spam labels: the call log and the on-screen name can also say Known spam or Suspected spam. That label comes from the spam list already on your phone, so it needs no request.
Turning it off: Settings, Caller ID, which has two switches: Caller ID in the call log and Caller ID during calls. Both are on from the start. With both off, no lookup leaves your phone.
In the call log, Lookup opens the number's page on zeroemdashes.com in your browser. The page shows what Bouncer knows about the number: its caller ID name, whether it is on the spam list, and a web search for it. Nothing is sent until you tap Lookup.
What is sent: the number, in the page's address. Like every web page, the request also carries your phone's IP address. No identifier is sent: not the random identifier from Section 2c, and not your Firebase or advertising identifier.
What we keep: nothing. The server builds the page, does not record the request, the number in it or your IP address, and does not count lookups.
Before version 4.1, Lookup opened a Google search for the number instead.
Bouncer requests access to your contacts if you enable whitelist mode. Whitelist mode blocks calls from anyone who is not in your contacts.
When a call comes in, the app checks the caller's number against your contacts list directly on the device. This check happens entirely within Android's standard contacts API. Your contacts are never read in bulk, never transmitted anywhere, and are not retained beyond the duration of the check.
If the caller is matched to a contact, the contact's display name may be stored in the call log alongside the call record so you can see who was blocked or allowed. This data stays on your device and is never shared.
If you do not enable whitelist mode, the contacts permission is not used.
You can revoke the contacts permission at any time in Android Settings. If you do, whitelist mode will stop working, but all other app functions remain unaffected.
Bouncer uses three third-party services that receive data: Firebase Analytics, Firebase Cloud Messaging for offer notifications, and Cloudflare for shared block lists, spam reports and caller ID lookups.
| Service | Operator | Data received | Purpose |
|---|---|---|---|
| Firebase Analytics | Google LLC | Firebase Installation ID, device model, OS version, language, country, app version, session data, and the custom events and user properties described in Section 2b | Anonymous usage analytics and subscription funnel measurement |
| Firebase Cloud Messaging | Google LLC | A push token: a random identifier Firebase creates for your installation of the app, so a notification can reach it | Sending occasional notifications, such as an offer on Bouncer Pro, to groups of installs chosen from the analytics in Section 2b |
| Cloudflare Workers, D1 and R2 | Cloudflare, Inc. | The shared block list, spam reports, SIM country, app version and random identifier described in Sections 2c and 2d | Storing shared block lists and reports to build the spam list |
| Cloudflare Workers and D1, caller ID | Cloudflare, Inc. | The first digits of a caller's number and your IP address, described in Section 2f; a number you look up and your IP address, described in Section 2g | Answering caller ID lookups and serving number pages. Nothing is stored |
Cloudflare processes this data on zeroemdashes's behalf under its Data Processing Addendum. The database is held in Cloudflare's EU jurisdiction.
Firebase Analytics and Firebase Cloud Messaging are governed by Google's privacy policy and the Firebase Data Processing and Security Terms. Google processes this data as a data processor on zeroemdashes's behalf, not as an independent data controller.
Notifications sent through Firebase Cloud Messaging appear in their own notification channel, Offers. You can turn that channel off in Android's notification settings for Bouncer, and every other Bouncer notification stays on. A notification never contains your call log or your block list.
The app also uses the following open-source libraries, all of which run entirely on your device and transmit no data:
Bouncer is not directed at children under 13 and we do not knowingly store personal information from children. If you believe a child under 13 has used the app on a device you manage, you can clear the call log and blocklist from within the app at any time, or contact support@zeroemdashes.com.
Call-blocking data stored on your device is yours to keep or delete. You can delete your blocklist entries one by one or clear the call log at any time from within the app. Uninstalling the app removes all data the app stored on your device.
Shared block lists: kept while you share. Each upload replaces your previous one. When you stop sharing, your phone asks the server to delete your shared block list. If that request cannot be sent, for example because the app was uninstalled first, email support@zeroemdashes.com.
Spam reports: kept until you undo one in the call log, or ask us to delete them at support@zeroemdashes.com. Stopping sharing does not delete them.
Numbers that already passed into the spam list stay there without any link to you.
Caller ID lookups: not stored. The server answers each one and keeps no record of it (Section 2f).
Lookup: not stored. The server builds the number's page and keeps no record of the request (Section 2g).
Google retains Firebase Analytics event data according to the retention settings configured for the Firebase project (the default is two months for user-level data and fourteen months for aggregate reporting). zeroemdashes does not independently control Google's server-side retention beyond those project-level settings. Existing event data already transmitted to Firebase cannot be deleted by zeroemdashes, but you may contact support@zeroemdashes.com to initiate a deletion inquiry.
For locally stored data, your rights of access, rectification, erasure, and portability are satisfied directly: you can view and delete everything from within the app at any time. For Firebase Analytics data, your rights extend to data held by Google under the Firebase Data Processing and Security Terms. Contact support@zeroemdashes.com and zeroemdashes will coordinate with Google where required.
google_analytics_adid_collection_enabled manifest flag, so the Google Advertising ID is not collected. The categories of personal information collected are identifiers (Firebase Installation ID; the Firebase Cloud Messaging push token; the random identifier and the phone numbers you share or report, Sections 2c and 2d), internet or network activity (the events and user properties described in Section 2b), and coarse geolocation (country level, derived from IP address). You have the right to know what is collected, to request deletion, and to non-discrimination for exercising these rights. Contact support@zeroemdashes.com.
The data safety section in the Google Play Store for Bouncer reflects what is stated in this policy:
This update (effective 2026-11-05) is a meaningful change under this policy's own definition. From version 4.1, Lookup in the call log opens the number's page on zeroemdashes.com instead of a Google search; the server keeps no record of it. Section 2g describes it, and Sections 4 and 8 were updated to match.
The update effective 2026-11-04 was also a meaningful change. From version 4.0, Bouncer has Caller ID: to find the name of a number that calls you, your phone sends the caller's number without its last two digits to our server, which keeps no record of it. Section 2f describes it, and Sections 4, 6 and 8 were updated to match.
The previous update (effective 2026-10-23) was also a meaningful change. From version 3.10, Bouncer uses Firebase Cloud Messaging to send occasional notifications, such as an offer on Bouncer Pro, in their own Offers channel, which you can turn off. Sections 4, 7 and 8 were updated to match.
The update before that (effective 2026-10-18) was also a meaningful change. From version 3.7, a new install shares its block list from the start, on the basis of legitimate interest, and you can stop at any time in Settings; installs that do not share yet are still asked first. Two phones, sharing or reporting, now make a number known spam, and a report can be undone in the call log. Sections 2c, 2d, 6, 7 and 8 were updated to match.
Before that, the update effective 2026-10-15 was also a meaningful change. It added Sections 2c, 2d and 2e: sharing your block list for spam blocking, which happens only if you agree; spam reports from the call log, sent only when you tap Report spam or Not spam; and the public spam lists the spam list also draws on. Sections 4, 6, 7 and 8 were updated to match.
Before that, the update effective 2026-09-16 was also a meaningful change. Two categories of data are newly described: screening reliability, meaning whether the app still holds the call-screening role on your device, and app usage, meaning which screens are opened. Section 2b was also rewritten to describe the categories of data collected rather than list individual event names, which changed between releases without the categories changing. This policy is published at a stable address linked from the Play Store listing, and its effective date is updated whenever the data collected changes.
The one before that (effective 2026-09-10) was a meaningful change too: a version of Bouncer before it made no data collection of any kind, and that version added Firebase Analytics.
If this policy changes in a meaningful way in the future (for example, if additional data collection is added), the effective date at the top of this document will be updated. The updated policy is published at the address linked from the Play Store listing before the change takes effect.
Questions about this policy?
support@zeroemdashes.comThere is no automated system on the other end. You will get a reply from Bojan.