5 ms·

And Apple didn't even need to block any device identifiers, just the IPs Beeper Mini was using to connect to the APN service. This could have been blocked in m

And Apple didn't even need to block any device identifiers, just the IPs Beeper Mini was using to connect to the APN service. This could have been blocked in minutes. The delay was likely to get approval from Legal.

lelandbatey 3y ago
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.
- kaladin-jasnah 3y ago
  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.
  - rezonant 3y ago
    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.
- pxeboot 3y ago
  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 https://blog.beeper.com/p/how-beeper-mini-works
  - rezonant 3y ago
    Only required when Mini isn't running.
- wkat4242 3y ago
  If it were purely client based, why did I leave to log in with Google to something then?
zxt_tzx 3y ago
> 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.
- pxeboot 3y ago
  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 https://blog.beeper.com/p/how-beeper-mini-works
  - zxt_tzx 3y ago
    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.)
    - pxeboot 3y ago
      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.
  - rezonant 3y ago
    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.
rezonant 3y ago
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.

lelandbatey 3y ago

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.

kaladin-jasnah 3y ago
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.
- rezonant 3y ago
  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.
pxeboot 3y ago
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 https://blog.beeper.com/p/how-beeper-mini-works
- rezonant 3y ago
  Only required when Mini isn't running.
wkat4242 3y ago
If it were purely client based, why did I leave to log in with Google to something then?

zxt_tzx 3y ago

> 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.

pxeboot 3y ago
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 https://blog.beeper.com/p/how-beeper-mini-works
- zxt_tzx 3y ago
  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.)
  - pxeboot 3y ago
    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.
- rezonant 3y ago
  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.

rezonant 3y ago

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.