> The developer of "Bouncer" will
receive the text, attachments, and sender information in SMS and MMS messages from senders not in your Contacts. Messages may include personal or sensitive information like bank verification codes.
> Bouncer does not share, upload or send any of your personal information or SMS messages to a remote server. All the filtering happens locally on your phone, based on your own private word or regular expression list.
You can also validate this assertion with the App Privacy Report. Settings -> Privacy (& Security, if on iOS 16) -> App Privacy Report -> App Network Activity -> Show All -> all network activity will be here. Bouncer shouldn't be listed (or at least, it isn't on my device) because it doesn't use the network for this.
Most apps are compiled straight from some dev's laptop with a largely undocumented environment consisting of many unvetted tools capable of injecting themselves into the build process.
This is the Apple mindset, glossy features and apps but forgetting that these apps are made by people that aren't perfect. Looking at code almost feels 'dirty' to many Apple users. Like first class passengers on a cruise ship being horrified at the oily smell of the engine room :)
It's part of the glamour that Apple has built around its products, but it is mainly a marketing thing. After all Cellebrite and Pegasus manage to break through just fine.
The big benefit though of reproducible builds is that what you see in the code repo is actually what you get on your device. There is no reason to hide this code like Apple do, it's not 'magic' and having visibility helps against apps abusing the users' data.
Verifiably open source packages are a net positive to security because it ensures the code running is the same code that has the public's eye on it.
People keep forgetting this, because they spend most their time thinking about security in the terms of a enterprise system, but for a personal usecase, an app extracting data to their servers that i was not expecting is a info leak security breach.
Its just that acknowledging that fact requires treating most operating systems (ubuntu, (but not debian) android, and ios included) as malware and this is a uncomfortable position.
It's fine that the app on your phone can read your messages, for that reason. It's not fine that it can then send them to its developer or anyone else. (I know it claims it doesn't. My point is that it can, so you have to trust that the developer is telling the truth, and that an update will never make it start to.)
So it's not the case that it'd be too much work or technically infeasible for such a permission to be available to us. It's just that Apple doesn't actually care about us or our privacy.
This feels like a case where it'd be good if Apple had two different messages, one for SMS filters which have a ILMessageFilterExtensionNetworkURL configured (which should get the scary message you saw) and one for those that don't (which are sandboxed to be purely device-local).
That said, Apple doesn't really handle the case of permissions changing with an app update very well, so launching your app purely device-local then updating to add something server-side a year later would probably let you get around that.
This app seems to not have the key that'd indicate it's capable of sending anything to a server: https://github.com/afterxleep/Bouncer/blob/master/Bouncer/In... (though, you know, that assumes that the build on the App Store is directly from the source we can see...)
It's a boilerplate warning that applies to the maximum possible amount of data-collection that could be happening. The app says it doesn't collect anything, and its source on GitHub supports that claim... but a SMS app theoretically could and so Apple warns you of the worst case.
Maybe there's a specific legal difference between "receiving" and "collecting" data? ("Collecting" makes me think the data is stored somewhere else with a 3rd party)
(I'm not associated with the app, but this is basically what I wish was built in to iOS, and it's OSS, free, ad-free, and implemented entirely on the device)
> Bouncer a simple SMS and MMS filtering app that moves unwanted messages to the "Junk", "Promotion" and "Transaction" sections of the Messages app.
> Different to other apps, Bouncer does not share, upload or send any of your personal information or SMS messages to a remote server. All the filtering happens locally on your phone, based on your own private word or regular expression list.
I’m using a free app called SMS block[0] for a number of years. Other than a weird app icon (has a strange logo that has the word TAXI on it with a cross mark for some odd reason), it seems to run local and does the job simply and effectively. Wonder if I need to worry about it leaking any data? I guess it’s easy to switch to Bouncer
This is probably a dumb question, but is it possible that a malicious update to Bouncer could allow a bad actor to intercept my texts and ship them to a remote server?
So, first of all, it'd only ever be shown texts (not iMessage messages) from people who aren't in your contacts. But that probably includes things like 2fa codes, so that's not necessarily comforting.
The app registers an ILMessageFilterExtension. This is run (if you enable it) when you receive a SMS and is given the sender and contents of the message and asked whether it should be blocked or categorized. However, it's sandboxed away from the main app you install and isn't allowed to store data for later access or send network requests. It is allowed to tell iOS that it needs to contact a server to work out whether the message should be blocked, and then an iOS system-service will contact a URL associated with the app with the data about the message... (I don't know whether Apple proxies these requests to avoid the server being able to correlate by your IP address.)
The theory is that since the system is handling contacting the server, it can avoid sending any extraneous data that would let the text be tied to you by anything more than its actual contents (so e.g. it might have a 2fa code, but it wouldn't know what your email address is). But it'd still be sent all the actual contents of your non-contacts texts.
But to sum up: Apple doesn't distinguish in its warning between apps that are configured to maybe send texts to a server for classification (which is indeed "the developer has access") and those that aren't. It just gives a maximalist warning -- which, to be fair, covers well the case where an app initially can't send data to a server... and later updates so that it does.
Because even if there is no back-end service, _the developer's code_, running on your device, will have access to your messages. It is a matter of semantics, granted, but that is what it means.
What bank? Every US bank requires phone-based 2fa so far as I know
I bought a YubiKey a few years ago, and was extremely disappointed to find that there are only a tiny number of important services that actually support it without requiring insecure SMS as a backdoor
The problem here is we're talking about "simjacking" (where you exploit one of the many, many security loopholes in the cellular network to take over someone's phone line for a while and get SMS 2FA codes)
I don't know about Ally or Citibank and will check those out, but it's been my experience that Chase requires a phone number and it makes sending 2FA codes to that number an option.
You realize you're applying your own "acceptable amount of security" and expecting bank users to be this sophisticated? lol.
If you're gonna advocate for better security when it comes to authenticating your banking details, please, for everyone's sake; don't just shift the attack vector to another service and claim it's superior because YOU use TOTP 2FA with YOUR email account.
Be better to advocate that services use TOTP 2FA directly.
Disagree [0]. Name one major email provider that doesn't have bruteforce protection.
This is a silly circular argument anyway. You're just upset that I'd have the gall to suggest that you use online banking to someone who lives in a rural town in Iowa. Instead, you keep pontificating on the level of security between email and sms... while at the same time, being perfectly ok with using a bank that only offers sms 2fa. Facepalm.
At the end of the day, neither matter... your funds get stolen from simjacking because a bank only offers that as protection? Read this [1]... max loss is $500 and more likely $0. This is bike shedding a moot issue. 2fa is more relevant for other issues.
No, Apple has a content blocking API. The only thing the app can do is tell iOS something along the lines of “scan incoming SMS for this regex, if it matches, throw it in junk.” The blocker app never actually sees the messages.
This message displayed before allowing app access contradicts your statement:
"The developer of Bouncer will receive the text, attachments and sender information in SMS and MMS messages from senders not in your Contacts. Messages may include personal or sensitive information like bank verifications codes."
I’m not so sure that’s true reading through the privacy notice when enabling SMS filtering it reads “You can install and use third-party SMS filters. If you do, the filter provider can access all of the text and content included in incoming SMS and MMS messages that you receive from unknown senders.”
That doesn’t sound like the same thing as the content blocker api it sounds like it provides plaintext access to sms messages. And it’s enough of a risk that I decided not to install it.
You're thinking of the way web content blocking works. This is a SMS filter, which is given actual access to the message contents.
However, the extension isn't allowed to make network requests while it's doing that, and has to pass off a request to contact a server to an iOS service than handles this outside of the extension's control. (I'm not actually sure what restrictions are involved on what Apple will send to your own server, admittedly.)
What I said applies to iOS ad blockers as well, at least the ones that use Apple’s content blocking API (which is the only one that works in Safari). If it uses a loopback VPN then it has more free reign but I think Apple is trying to crack down on those.
I can find references to the built in spam filter for Google Messages going back to at least the beginning of 2019, so this isn't exactly a new feature. I haven't noticed it myself, but as someone who has received a spam message maybe once or twice in his life, I don't think SMS spam filtering is something I would've come up with were I to work on an SMS messenger. Maybe as an extended blocking feature?
I personally use Signal for my SMS messages, maybe that's filtering messages for me. Pretty neat to be able to use an alternative messenger as the system messenger app to be honest, since I'm going to install Signal on my phone anyway!
I’ve never done iOS dev, but is there a way for me to load my own dev app onto my phone from Xcode or something. I’d like to not let 3rd parties get access to my texts.
As far as I know, if you have a dev account, apps installed yourself will be valid for a year, instead of 7 days. I've never done it myself though, so this is just based on what I've read.
The message presented on iOS is just Apple's boilerplate. It gets added to all applications using the ILMessageFilterExtension by default, without any consideration of the actual features of the app.
The reason I wrote this app is because I don't trust third party developers with my SMS messages or personal data.
That's also the reason is Open Source and available in Github: https://github.com/afterxleep/Bouncer, in case you want to confirm it's safe and build it yourself. ;)
This is a pretty good proposition for people across devices. This is the one feature I've been expecting to see in a keynote for the last few years but alas. This seems like a good compromise (Google's incoming SMS/caller spam identification is still the most compelling reason to stay on its platform (but I'm a 'mom and pop' style device user who's app averse)
That’s a no for me, dog.