> it seemed Apple was actually doing the a lot of the right things when it came to privacy and security
Isn't this one of them?
A security hole existed that permitted Beeper to pretend to be your Apple device. In this case, it was being used for non-nefarious purposes, but that doesn't mean everyone would. Apple's fixing that hole seems in-line with your desired "privacy and security".
"Hey, I'm /u/ceejayoz's new iPhone! Bwahahahahahaha. Ahem. I promise I'm really the iMessage client you're expecting. Start sending me a copy of all their potentially sensitive messages."
Again, how do we not classify that as a security issue?
If you’re referring to the history, then it cannot talk to the iCloud keychain, and even if it could, it would require your credentials. Same thing if you are just talking about incoming messages, they need your credentials. If they have those you’re already fucked. And also, they could just have taken an iPhone and log in there with your credentials.
It isn’t proxying afaik, it is calling the Apple servers directly. The only thing getting to Beeper servers (and that can be disabled) is an IDS key without its matching decryption key, for Beeper to be able to see if messages are coming to signal the phone (which has the encryption key but is not connected continuously) to fetch it and show the notification.
At the very least, it's being proxied through the third-party Beeper app, which Apple has no reason to trust. (Nor the Android device it's running on.)
> In tests, 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.)
> What is stopping me from buying a second-hand old iPhone and doing this without Beeper?
In that scenario, you're still using the official client, which Apple presumably knows isn't silently siphoning messages off to somewhere else. You're on official hardware with an official client.
5. "Gah! Beeper was hacked/compromised/deliberately siphoning off Apple ID credentials into a log/error reporting/bad actor's database and now millions of people have had their sensitive texts and other iCloud data exposed."
Facebook and LinkedIn used to try to get people to hand over their email credentials so they could "help you find your friends on Facebook"; people were correctly skeptical then. Giving my Apple ID to a third-party seems insane, given what can be done with it, and I'd imagine Apple sees it the same way.
> Giving my Apple ID to a third-party seems insane
That's fair. You'd be happy to learn that literally no one is forcing you to hand over your Apple ID to Beeper. Your approach is very good for your account safety, but you don't need to keep other people safe from themselves.
Do you have similar concerns when people use non-Google-approved email clients to use Gmail, or alternative YouTube clients, or Signal/Telegram forks?
Perhaps you think HN should ban alternative clients or weird web browsers too. Too bad a lot of people think interoperating clients are important or we would be left with the Web Integrity crap to "keep us safe".
> Do you have similar concerns when people use non-Google-approved email clients to use Gmail.
If they ask for credentials, absolutely. Google has both an OAuth flow and the ability to generate app-specific passwords (which correctly have very limited abilities) so I never have to pass over the real creds.
I have never given my Gmail credentials to Apple, but I get my mail just fine.
Google requires you to register an application and get it approved to log in with OAuth, you can't just use it with arbitrary callback URLs. Why should I need to ask Google permission to use my own data, or ask for Google's permission to allow other apps to use my data?
If the Beeper service is totally fine, and you mind their auth methodology, perhaps you should complain about Apple not providing better iMessage auth options.
Instead, you complain about users being able to give their own data to an app they chose to install.
> Google requires you to register an application and get it approved to log in with OAuth, you can't just use it with arbitrary callback URLs. Why should I need to ask Google permission to use my own data, or ask for Google's permission to allow other apps to use my data?
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.
Isn't this one of them?
A security hole existed that permitted Beeper to pretend to be your Apple device. In this case, it was being used for non-nefarious purposes, but that doesn't mean everyone would. Apple's fixing that hole seems in-line with your desired "privacy and security".