I don’t believe so. Beeper Mini uses Apple’s protocols the same way the native iMessage uses it; they didn’t exploit a security hole (unless you classify the device faking part as a security hole—I don’t). They maintain the E2EE flow.
The protocol's implementation is intended to verify you're connecting a device Apple built, with stuff like secure enclave and end-to-end encryption as known quantities. With Beeper, you have to give your Apple ID to a third-party app, which they then proxy through a server of some kind (https://techcrunch.com/2023/12/11/beeper-mini-is-back-in-ope... "signing in with our Apple ID generated an Apple prompt that noted our ID was being used to sign in with a device “near Los Angeles, CA” (where we are not located.)")
I don't see how you could describe that as anything other than a security hole.
I know that HN is not one homogeneous opinion, but it always comes up in these Apple threads that all this device attestation and secure enclave stuff is unambiguously good because Apple does it, but when it comes to TPM key escrow or Web Environment Integrity suddenly everyone is up in arms about how it's a total violation of a user's freedoms to do what they want with their device.
You shouldn't defend something that's inherently consumer hostile just because it happens to be for something you like.
I'm OK with titrating skepticism on a proposal based on the motivations of the proposer.
To Godwin a bit, I'd treat "we should make the trains to Auschwitz run more on time" differently depending on if it's being proposed by the German government in 1942 or the Polish government in 2023.
> With Beeper, you have to give your Apple ID to a third-party app, which they then proxy through a server of some kind (https://techcrunch.com/2023/12/11/beeper-mini-is-back-in-ope... "signing in with our Apple ID generated an Apple prompt that noted our ID was being used to sign in with a device “near Los Angeles, CA” (where we are not located.)")
I think they have another primary product of the same name that operates this way, but Beeper Mini never sends your credentials off anywhere other than Apple’s servers [0][1].
> To work around this limitation, we built Beeper Push Notification service (BPNs). BPNs connects to Apple’s servers on your behalf when Beeper Mini Android app isn’t running. We can do this while preserving user privacy thanks to Apple separating the credentials needed to connect to APNs to send and receive content (the “push” credentials) and the keys needed to encrypt and decrypt messages (the “identity” keys). Push credentials can be shared securely with the Beeper Push Notification service, and BPNs can connect to APNs on your behalf. Whenever BPNs receives an encrypted message that it won’t be able to decrypt, it simply disconnects from APNs and sends an FCM push notification to wake up the Android app, which then connects to APNs, downloads, decrypts and processes the incoming message. BPNs can only tell when a new message is waiting for you - it does not have credentials to see or do anything else.
Bepper still connects on your behalf to run notifications while the app is not running.
This is incorrect. They're using a legacy, less secure protocol - not in the sense of encryption, but in the sense of the need to generate auth tokens per user.
I don’t believe so. Beeper Mini uses Apple’s protocols the same way the native iMessage uses it; they didn’t exploit a security hole (unless you classify the device faking part as a security hole—I don’t). They maintain the E2EE flow.