RoboStopper

@albert_wolszon Hey Albert, thank you for taking the time to comment. The "Should I Answer?" app, and all other apps like it on Android, use a blacklisting approach to screen calls. This relies on users reporting numbers that should be flagged as spam, which updates an on-device list of spam numbers, and the next time that number calls someone, it is either blocked or displayed as suspicious. RoboStopper is the first app on Android that uses an on-device whitelisting approach that only allows calls through from people that are in your contact list. In the comment below/before yours', Jim Weiler notes the challenges that are introduced with this approach (blocking calls too well), which we mitigate with a variety of modes that give the user control over the timing and level of spam blocking. For our users that used to have an out-of-control problem with spam calls, RoboStopper keeps their phones quiet during the day and allows calls through from their family members and friends. If you have the time, please give RoboStopper a try (7-day free trial!) and let us know what you think.

@vaelek Thank you for taking the time to write up such a great comment, Jim! First and foremost, we're taking your comment about transparent pricing onboard and will update our website ASAP with our current pricing: 7-day free trial, $3.99 per month subscription service, with a future option for a reduced yearly subscription price. This pricing is industry standard at this point for spam blockers, due to running costs related to network infrastructure, call forwarding, storage, notifications, etc. We definitely understand your concerns about "blanket" call blocking. This is the inherent challenge in taking a high-quality "whitelist" spam call reduction approach instead of the failure-prone "blacklist" approach that almost all of our competitors take (which is why their users report that they don't work). RoboStopper contains a variety of tools that empower the user to control time windows where the spam blocking level is reduced to allow calls through when the user doesn't, as you say, have "advance notice of the number it will be coming from". As mentioned to Albert in the reply above to him, for our users that used to have an out-of-control problem with spam calls, RoboStopper keeps their phones quiet during the day (and night) and allows calls through from their family members and friends. For all other calls, the user receives a notification of a call (not a ringing phone), and then can listen to the voicemail if necessary and easily respond with a follow-up call. We're just getting started with this service, and feel that it has tons of potential for features that can address the use cases of most people. If you're down to join us on this adventure, please take a dive into the app (7-day free trial!) and hit us with some more feedback at robostopper@codeheadlabs.com.

@danielbradshaw If the blocking is done via an on-device whitelist, then what is the service end providing exactly? I can find no privacy or data use policy on your site. But with what you have said, I get the inkling that to use this, you sync my contact list, set my line to forward all calls to your service, where those present in said contact list are then forwarded back to me, and the rest hit the paywall, or leave a message, presumably also with your service? If so, I can appreciate what you're trying to do, but even if there were no fee, in the age of data harvesting, I could never sign on to that.

@vaelek Jim, thank you for taking the time to discuss. You're raising concerns that we have talked about at length as well, and I think we can address each: 1. Privacy policy / terms: Our privacy policy and terms of service are linked in the footer of the robostopper.app, and are available to users at the beginning of the onboarding process. 2. Android / on-device: On Android the service layer is necessary in order to handle calls after they have been blocked on the device. Depending upon the characterization of the person that is calling, we provide a mechanism to leave a voicemail, or send the caller to the paywall so that if they're willing to pay our user's bypass rate, we can send the call back and ring the phone. 3. Contact information: Your concerns here are our own as well. In order for us to take a whitelisting approach, we need the phone numbers for all of a user's contacts. What we don't need is the actual phone number, though. On-device for both Android and iOS, we only send a strong hash of the user's phone number and each of their contact's phone numbers to our server. You are wicked smart, though, so you're already seeing two problems with this: 3a. Hashing: On-device encryption would be better, but we're not there yet after only a couple months of development. Ultimately, even encryption isn't a perfect solution, but what's hashed / encrypted is just an anonymized phone number, not all of your contact's information. 3b. Verifiability: You rightfully don't trust us automatically; neither would I, because... the world we live in. Why would anyone take our word that we're only sending the hashes to our server if we have access to the user's whole address book? This verifiability is something we don't have figured out yet. What would put your mind at ease? We use Flutter, so we could publish / open-source the package that we use to obtain and hash contact information (with the hashing function as a constructor parameter so that users of the package don't need to reveal the hashing function they use), but of course even that leaves question marks. Open-sourcing the entire app is not an option, which is perhaps the only way to fully alleviate this concern. Finally, thank you for your thoughtful comments and engagement.