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.
https://developer.apple.com/documentation/sms_and_call_repor...
If this is true, then why does Apple say that the developer of the app will have access to your messages? https://news.ycombinator.com/item?id=32791686
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.
We all know that isn't true, but that's a huge issue given the amount of simjacking that goes on.
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
Ally: email
Citibank: phone app
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.
1. the not recognized device. in this case, it is only text or call.
2. recognized device, 2fa login: in this case, you get text or email as options.
mmk.
I don't see how my email, which is secured with 2FA, is more likely to be compromised than simjacking.
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.
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.
Have a nice day, sir.
No I just think you're so far up your own ass that you fail to realize that 2FA TOTP on your email doesn't make you more secure.
But whatever, you do you homie.
More secure than what?
I live in a small rural town in Iowa. All our banks use SMS to send 2FA, are you suggesting I move... because my bank uses SMS for sending a code?
Having control of this data is way better than SIM swapping. This seems like a terribly risky thing to install, security-wise.
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.
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.)