>Beeper put them between a rock and a hard place
"Should we allow a third party we have no control over to man-in-the-middle our end-to-end encrypted messaging service or not? This is a tough one!"
"Should we allow a third party we have no control over to man-in-the-middle our end-to-end encrypted messaging service or not? This is a tough one!"
That's absolutely not what's happening, and I think Beeper's response here was totally correct.
There is no encryption, at all, between iOS and Android clients if the iOS user is using iMessage. And, furthermore, my understanding is that the presence of a single Android user in a group chat means nobody gets an encrypted messaging experience.
In the past, Apple's response to this has literally been "Buy your grandmother an iPhone". How can anyone not call incredible amounts of bullshit when their response to a company that actually let, for the first time, an Android user have an encrypted conversation with an iOS user as "This is unacceptable, we can't allow this" and claim it's because Apple cares about user security???
Not enough BS chutzpah in the universe for that one.
You also don't have to trust Beeper because you are not obliged to use it. You are welcome to not use it (and buy an Apple device) or even fall back to SMS.
The recipient can themselves decide what level of security they want and whether they trust Beeper (but they don't need Beeper to compromise their security - they can just as well post screenshots of your E2E-encrypted messages with them, make a backup on a compromised computer or leak their Apple/iCloud credentials).
Do you actually believe these things you're claiming, or are you arguing for the sake of contrarianism?
E-mail can be end-to-end encrypted; you can use PGP (of which there are multiple implementations, all compatible) or some other custom cryptographic protocol. Having multiple compatible implementations does in no way prevent it from being secure.
> FTP and SSH are client-server protocols whereas iMessage is client-server(s)-client.
I don't understand how iMessage and FTP are different? Both have a server which mediates communication between different clients. The FTP server accepts & persists files which other clients then see and can download. The iMessage server does something similar but with messages.
> Do you actually believe these things you're claiming
Yes? I believe every person should have the right to choose which software they use to interact with services, whether it's first-party, third-party, or their own creation. I don't know nor care which browser you're using to read & reply to my comments and shouldn't have a say it in in any case - whatever happens on your machine is your own business only.
I don't understand what is so extreme about my position? It's like arguing that being able to open & create Microsoft Office files in anything but a Microsoft-approved version is heresy.
SMS can be end-to-end encrypted; you can use PGP.
>I don't understand how iMessage and FTP are different?
If I get a new iPhone and set it up without restoring it from a backup and I have NOT opted into "Messages in iCloud" (I personally have not), then my entire iMessage history is unavailable to me on my new iPhone.
>I believe every person should have the right to choose which software they use to interact with services
Then you also believe that forgoing E2E encryption is an acceptable tradeoff for exercising that freedom.
>I don't understand what is so extreme about my position?
It's not that your position is extreme, it's that you don't seem to understand the consequences of that position.
Ok, the difference between an FTP server and the iMessage server is that iMessage only buffers the messages for a few hours (until delivered) where as FTP server would persist it for longer. That's completely irrelevant in this case though - both operate as a temporary storage space to which multiple clients owned by different parties connect to, and I still don't understand why it should be acceptable to connect a third-party client to one but not the other?
> Then you also believe that forgoing E2E encryption is an acceptable tradeoff for exercising that freedom.
If there was some technical reason why E2E wasn't possible then sure, but there's none - as both GnuPG, browsers, SSH clients, XMPP, and Beeper all demonstrate, a third-party client can just as well implement an E2E protocol, and the only reason we can't have that with iMessage is because it would compromise Apple's vendor lock-in.
> it's that you don't seem to understand the consequences of that position
Which are? I still don't understand how Beeper being out there affects me negatively as an Apple user? Even if we assume Beeper actually had some security vulnerabilities and was literally sending message contents in plain unencrypted form over an untrusted network, it still wouldn't be any worse than texting those people via SMS, which is unencrypted by design?
> Plenty of places will suspend your account if discovered you have done this.
Plenty of services base their business on restricted interoperability and suspend your account not because of security but because they'd miss out on all the "engagement" they get from the official client. This has nothing to do with security.
This isn't rocket science.
And yet that's not the route Apple chose to take.
Someone recently really tried to get me to use Chime. As soon as the "must use Plaid" part came up in their onboarding, I stopped immediately. It's just a shame that I had already provided Chime so much of my information just to stop there.
One of the primary benefits of end to end encryption is that it can protect messages from an untrusted carrier. In other words, a proper encrypted messaging setup is not vulnerable to man-in-the-middle attacks
> Using native chat apps independently may be more secure than connecting to other encrypted chat networks with Beeper Cloud.
https://www.beeper.com/faq#how-does-beeper-connect-to-encryp...
Please tell me more about how Beeper can't be used as a MiTM for E2E encrypted networks like Signal.
I appreciate you pointing out specifically what the problem was rather than just repeating that it was insecure, rather than how, and admit what I said was, as far as I now know, wrong
That said, what are the odds that Apple would accept a solution that was encrypted on-device? If this were feasible, would Apple still block the interoperation with their network, and do we agree on whether they'd be wrong to?
I think the main issue I see with iMessage that this highlights is that it's presented in a way that's deceptive to its users, and thus might give them a false sense of security in their messaging. An interoperating client on android is a band-aid for this problem at best, but it's a weird move to block it. I guess for now there's the plausible deniability of what appears to be a real issue though. The way Apple's messaging has addressed it still leaves a bad taste in my mouth, because they do not make clear that what you point out is the issue
We probably agree that the odds hover just above 0%
>would Apple still block the interoperation with their network, and do we agree on whether they'd be wrong to?
We could agree in principle that they would be wrong to, _if_ there were a clear path to continuously verifying that a third party client is behaving above board. Unfortunately that's just not the case. AFAIUI, this is still an intractable issue with encrypted communications. Is it an impossible problem? Probably not, but the amount of sustained effort this would require from Apple (and the 3rd parties) seems unworkable. So given that reality (I think), I don't think Apple are wrong to disallow third party clients for their E2E encrypted service.
>The way Apple's messaging has addressed it still leaves a bad taste in my mouth, because they do not make clear that what you point out is the issue
Yeah, I don't disagree here. I can only say that this is par for the course when it comes to Apple's PR. They would basically never explicitly state that their E2E encrypted service is at risk of a MiTM attack due to third party clients. Instead we will get very generic language and be left to fill in the blanks ourselves.
Beeper Mini was a completely self-contained app that implemented the iMessage protocol on-device and did not use bridges. Its only optional cloud component was a push notification bridge that wasn't actually given the E2E keys (the cloud proxy would receive your messages but not be able to decrypt them, instead it just sends a push to wake up your device which will fetch and decrypt them).