2 ms·

Not necessarily, and I see this from Apple's perspective though. When iMessage is under their control (it is their creation after all), they (Apple) can be sur

by selykg 3y ago

Not necessarily, and I see this from Apple's perspective though. When iMessage is under their control (it is their creation after all), they (Apple) can be sure that what is happening is exactly what users expect. We can know that the messages are encrypted E2E without someone in the middle. With Beeper, there are no guarantees of that anymore. I could be messaging a person that is using Beeper, or some other tool, and the messages are being intercepted by that other tool's server and decrypted there. I'd be _expecting_ E2EE but not getting it. Perhaps Beeper has the best of intentions, but if you _allow_ Beeper you will need to allow everyone or then it gets even messier than it already is. When I see a blue message, or know I'm in an iMessage chat I have certain expectations. If you allow outside apps to interface with it like Beeper is doing then my expectations would need to be adjusted and I would no longer be able to trust that what I expect to be happening is always happening.

thomastjeffery 3y ago
Did you even read the post? Beeper's integration is open-source. Anyone can audit it. That means that Beeper requires less trust from its users than iMessage does! Nobody gets to audit iMessage. > Perhaps Beeper has the best of intentions, but if you _allow_ Beeper you will need to allow everyone or then it gets even messier than it already is. And if iMessage's protocol is E2E encrypted, then that is already guaranteed to be secure from MITM. The only new attack surface would be the endpoint, AKA the messaging app itself. The only way to guarantee coverage for that attack surface is to audit every messaging app, including iMessage. That is not the case, so there is no change in expectation. --- Your entire argument boils down to this: You trust Apple, and distrust everyone else: therefore, as an iMessage user, you should just throw E2E encryption out the window, and use unencrypted SMS instead!
- selykg 3y ago
  I'd appreciate if you were less combative in your discussion. "Did you even read the post?" Give me a break, read the rules of this discussion forum, please. Beeper is only ONE of the concerns I mentioned. As I said, Beeper may have the best of intentions, but not every solution will be. And if you allow Beeper, you're going to have issues with others doing the same. iMessage is end-to-end encrypted. Here's how you can MITM it though, if you allow third party tools like Beeper. For an app like this to work it uses a 3rd party app, because it has to fill the gaps of work being done by iMessage, which means it's handling keys, handling encryption, as well as all the user facing functionality. How do we know that all of these tools are not MITM'ing the solution? It could just as easily not E2E encrypt the data and decrypt on the server, before sending it to you via the app on your device (an Android device, or web app, or whatever you're using to interact with Beeper as a non-Apple device user). I understand Beeper operates locally, but even in that scenario a malicious app utilizing this same functionality and code could send the decrypted data elsewhere, requiring no server MITM, just a modified client side app. To an Apple user, we would have no way to tell that the user on the other end is potentially compromised. This _does_ change the trust model, does it not? Again, Beeper may have the best of intentions, but allowing Beeper to operate would mean allowing others to operate and they may not have the same intentions. Allowing these types of tools absolutely changes the trust of the solution. And to be clear, yes, we can view the Beeper code since it's open source. The real concern is other tools utilizing the Beeper code but in a modified way. Just because Beeper's code is open does not mean all solutions are open. And on my end, as an Apple user, I have no way of knowing someone is using a "best of intention" app like Beeper, or a maliciously modified fork of it.
  - thomastjeffery 3y ago
    > I'd appreciate if you were less combative in your discussion. OK. I agree to drop the word, "even". I could have phrased that more generosly. Here's a try: "Did you consider the rebuttal provided in the article?" I didn't want to be redundant by repeating it. --- Let's look at this with some perspective. There are 3 ways this can pan out: 1. What Apple wants: Everyone buys an iPhone and uses iMessage. In this scenario, the security of literally everyone depends on their trust in one party (Apple), because iMessage cannot be audited. It's also never gonna happen, so there's that. 2. What Beeper wants: 3rd party apps can send and receive messages with iMessage, and all messages are E2E encrypted. In this scenario, trust is only needed when the app at each end is closed-source. Open source apps can be audited, so conversations between them can be known to be secure. Messages between closed and open source apps must rely on the trust of one closed source app. This is worse if one or more 3rd party apps is closed source, because that introduces more parties who demand trust. This is better if all 3rd party apps are open source, because it allows guaranteed secure comms between users of open-source apps. It's a neutral change for iMessage users, because they must trust the same number of parties (just Apple). 3. What we got: iMessage is only encrypted (if Apple is trustworthy) when both users are using iMessage. This is worse, because iMessage users (and everyone who messages with them) are practically guaranteed to send and receive unencrypted messages. We have thrown the baby out with the bathwater.

by selykg 3y ago

thomastjeffery 3y ago

Did you even read the post? Beeper's integration is open-source. Anyone can audit it. That means that Beeper requires less trust from its users than iMessage does! Nobody gets to audit iMessage. > Perhaps Beeper has the best of intentions, but if you _allow_ Beeper you will need to allow everyone or then it gets even messier than it already is. And if iMessage's protocol is E2E encrypted, then that is already guaranteed to be secure from MITM. The only new attack surface would be the endpoint, AKA the messaging app itself. The only way to guarantee coverage for that attack surface is to audit every messaging app, including iMessage. That is not the case, so there is no change in expectation. --- Your entire argument boils down to this: You trust Apple, and distrust everyone else: therefore, as an iMessage user, you should just throw E2E encryption out the window, and use unencrypted SMS instead!

selykg 3y ago
I'd appreciate if you were less combative in your discussion. "Did you even read the post?" Give me a break, read the rules of this discussion forum, please. Beeper is only ONE of the concerns I mentioned. As I said, Beeper may have the best of intentions, but not every solution will be. And if you allow Beeper, you're going to have issues with others doing the same. iMessage is end-to-end encrypted. Here's how you can MITM it though, if you allow third party tools like Beeper. For an app like this to work it uses a 3rd party app, because it has to fill the gaps of work being done by iMessage, which means it's handling keys, handling encryption, as well as all the user facing functionality. How do we know that all of these tools are not MITM'ing the solution? It could just as easily not E2E encrypt the data and decrypt on the server, before sending it to you via the app on your device (an Android device, or web app, or whatever you're using to interact with Beeper as a non-Apple device user). I understand Beeper operates locally, but even in that scenario a malicious app utilizing this same functionality and code could send the decrypted data elsewhere, requiring no server MITM, just a modified client side app. To an Apple user, we would have no way to tell that the user on the other end is potentially compromised. This _does_ change the trust model, does it not? Again, Beeper may have the best of intentions, but allowing Beeper to operate would mean allowing others to operate and they may not have the same intentions. Allowing these types of tools absolutely changes the trust of the solution. And to be clear, yes, we can view the Beeper code since it's open source. The real concern is other tools utilizing the Beeper code but in a modified way. Just because Beeper's code is open does not mean all solutions are open. And on my end, as an Apple user, I have no way of knowing someone is using a "best of intention" app like Beeper, or a maliciously modified fork of it.
- thomastjeffery 3y ago
  > I'd appreciate if you were less combative in your discussion. OK. I agree to drop the word, "even". I could have phrased that more generosly. Here's a try: "Did you consider the rebuttal provided in the article?" I didn't want to be redundant by repeating it. --- Let's look at this with some perspective. There are 3 ways this can pan out: 1. What Apple wants: Everyone buys an iPhone and uses iMessage. In this scenario, the security of literally everyone depends on their trust in one party (Apple), because iMessage cannot be audited. It's also never gonna happen, so there's that. 2. What Beeper wants: 3rd party apps can send and receive messages with iMessage, and all messages are E2E encrypted. In this scenario, trust is only needed when the app at each end is closed-source. Open source apps can be audited, so conversations between them can be known to be secure. Messages between closed and open source apps must rely on the trust of one closed source app. This is worse if one or more 3rd party apps is closed source, because that introduces more parties who demand trust. This is better if all 3rd party apps are open source, because it allows guaranteed secure comms between users of open-source apps. It's a neutral change for iMessage users, because they must trust the same number of parties (just Apple). 3. What we got: iMessage is only encrypted (if Apple is trustworthy) when both users are using iMessage. This is worse, because iMessage users (and everyone who messages with them) are practically guaranteed to send and receive unencrypted messages. We have thrown the baby out with the bathwater.