> just the IPs Beeper Mini was using to connect to the APN service.

Hmm, wouldn't blocking IPs be overly broad and risked affecting regular users? Considering that IPs are scarce and constantly recycled by ISPs etc. Blocking device identifiers sounds more targeted and, for that reason, realistic.

If you take a look at their How it Works post [1] this is not an entirety client side implementation, so there would presumably be a small number of IPs that would need to be blocked.

[1] https://blog.beeper.com/p/how-beeper-mini-works

Are you referring to the step where Beeper's servers make a persistent connection with Apple's APN service to listen to new messages ?

So your point is Apple can presumably distinguish between an actual iOS connection and Beeper's connection by looking at "how many connections per IP"? Still seems prone to false positives to me, unless there is something else I missed.

(Upon re-reading the post, I realized that the phone number registration is actually done by Apple. Wonder if this might provide another basis to block Beeper, i.e. all this SMS infrastructure is not cheap to maintain and Beeper's integration is arguably using it in an "unauthorized" way.)

Yes. An Apple sysadmin could just install Beeper, watch what IP their APN requests are coming from and block it. Then repeat the process occasionally.

They don't need to break it completely. If Beeper is unreliable, nobody is going to pay for it.

In that very article they mention you can turn BPNs off, it is just used to listen to APNs when the app is not running. If that's what they blocked, Beeper Mini would still work while the app is running, or at least when that setting is turned off.

I can’t speak for Cupertino et al., but I would take that risk, even if it weren’t IP-based but instead UDID/serial-based.

The amount of legitimate users it would affect would be trivial and can be taken care of by customer support.

The benefit of that is that I can then, at that point, verify if we’re dealing with a legitimate device or not. Geniuses at Apple Stores can obviously do this physically, and remote support has the option to run remote diagnostics and even share screens.

I think you've got Beeper Mini mixed up with other iMessage bridges. The whole thing with Beeper Mini (vs other iMessage bridges) was that it was entirely client side on the phone, no server to block. So the "IPs Beeper Mini was using to connect to the APN service", those IPs were just the IP addresses of every individual phone with Beeper Mini installed on it, no centralized place to block.

No, the BPN server is a server side service that persistently recieves APNs to forward to the phone (that don't contain the message data) since unlike iPhones, Android phones can't persistently check for APNs (at least that's what I understood from the announcement article). AIUI that's what you're paying for. But that wouldn't explain why sending is broken.

The How It Works article is clear that BPNs is only used to serve push to your phone when the app isn't running. Disabling it would not cause send/receive failures.

If you check the How it Works post, they do show the Beeper Push Notification Service running in the cloud [1] to intercept 'new message available' APNs and then notify the Android device a new message is available.

[1] https://blog.beeper.com/p/how-beeper-mini-works

Only required when Mini isn't running.

If it were purely client based, why did I leave to log in with Google to something then?

Only BPNs used Beeper hosted services, and this is an optional component of the app (which enables push notifications when Mini is not running).

Otherwise the IP Apple sees is those of the individual handsets on whatever network they are on.

It's pretty likely that they blocked Mini based on the IDS (Identity Service) which requires the device to pass it's hardware model, serial number, and disk UUID as described elsewhere.