5 ms·

Do note "readily available to consumers". XMPP never reached a level of polish outside being embedded in part-proprietary solutions that it'd be available to yo

Do note "readily available to consumers". XMPP never reached a level of polish outside being embedded in part-proprietary solutions that it'd be available to your average user, not to even talk about OTR.

Andrew_nenakhov 6y ago
Gtalk was polished enough. It didn't have OTR built in, but majority of users don't really need end to end encryption anyway, it only makes their life not good. Also, iMessage never reached a level of polish to work on anything not produced by Apple. If we're taking proprietary vendor specific secure services, Blackberry did it before Apple, too. So, definitely not the first and not the only.
- derefr 6y ago
  E2E encryption is mostly for people whose lives are already not good. It only works to help those people, though, if enough “civilian” traffic is also using it that any ISP blocking it would be considered to be breaking the Internet. BBM was not E2E encrypted. BlackBerry always retained the capability to read your message traffic. Apple does not.
  - Andrew_nenakhov 6y ago
    > Apple does not. Well, I'm not _that_ familiar with BBM since it was never available in my country. But what makes you think Apple can't read your messages? Do you have any encryption keys that you share between devices? Or you just enter login/password on a new device and voilà all your messages are displayed to you? If that is so, I guess I'll have to tell you something... Anyway. Last time I checked, iMessage apps source code was not available, you can't verify fingerprints of your contacts in iMessage, so... how do you know Apple doesn't insert a very simple MitM agent that does e2ee both for your and your chat partner, having all messages nicely decrypted in the middle? So far it looks like the only thing that makes you think Apple can't do that is because they pinky promised this to you. Sorry.
    - derefr 6y ago
      > Do you have any encryption keys that you share between devices? Or you just enter login/password on a new device and voilà all your messages are displayed to you? You should really look more into the iMessage encryption scheme before attempting to fear-monger about it. The approach it uses to multi-device encryption is well known[1][2], and is basically its entire innovation over other clients—an approach that every other piece of E2E-encrypted chat software has been encouraged heavily to copy, but for some reason none yet have. (WhatsApp specifically is often ridiculed for its requirement to route all your messages through a "primary device", which feels like going back in time after experiencing iMessage's approach.) [1] https://support.apple.com/en-ca/guide/security/secd9764312f/web https://support.apple.com/en-ca/guide/security/secd9764312f/... [2] https://support.apple.com/en-ca/guide/security/sec70e68c949/web https://support.apple.com/en-ca/guide/security/sec70e68c949/... To save you the trouble of looking it up: you don't "log into iMessage." There's no such thing as a central "iMessage account." Instead, in iMessage, your devices synchronize state with one-another by participating in an ad-hoc group based on a shared "key bag" of all your devices' private iMessage signing keys. When you get a new device and want to join it to this existing group, it sends out a signed request on an announce channel corresponding to your iCloud identity, requesting that another device in the group "invite" it to the group. From the user's perspective, this appears as their new device telling them that the iMessage sign-on needs to be confirmed on an existing device; and a modal popping up on all their existing devices, asking whether they want to accept the new device's join request. If the user confirms the join request, then the existing device the user confirmed on will take its own iMessage keybag, encrypt it with the new device's public key, and send it to the new device. This will then allow the new device to securely "introduce itself" to the rest of the group. Throughout this process, no key material ever travels unencrypted through Apple's servers. Apple can't recover your iMessage keys; nor are Apple's servers an implicit "participant" of your iMessage sync group. iMessage's cloud backend is, during this pairing process, just a dumb message-queue system between your client devices, one that sees only opaque encrypted messages. (Note that this also means that it's totally possible to get "locked out of" your iMessage sync-group if you lose access to all your existing devices. This is usually fine, because 1. iMessage clients won't sync history from before a new device joined the group with that new device, so you're not losing access to anything you had any potential to recover anyway; and 2. you can make a new sync-group under an existing iCloud identity/phone number/IMEI/etc., because none of those visible identifiers are the primary key of the sync-group. The sync group has no primary key. It's not a central "entity" with an identifier. It's a mesh, that happens to be reachable through identifiers it registers to—sort of like softphone apps registering a DID number. But those actively-registered aliases aren't a means of security, nor recovery.) > Last time I checked, iMessage apps source code was not available People interested in messaging security don't tend to trust source code even if it is available. Unless the build process is deterministic and replicable by the researcher themselves—to produce exactly the artifact distributed by the store—then who knows what of the published source actually makes it into the published binary, and/or what-all else ends up in there as well. (Would you trust Chrome [the binary] just because Chromium is open-source? Would you trust macOS [the binary distribution] just because the XNU kernel and BSD userland are open-source?) Instead, security researchers dump packet captures and analyze them. And, in this case, those packet dumps reveal that iMessage does... exactly what is stated above.
Dahoon 6y ago
You are arguing that a $600+ phone for yourself and all your friends is more "readily available to consumers" than a $0 downloadable open source open standard software with multiple clients available? Two-thirds of the world population live on less than $10 a day. You are living in quite the bubble. XMPP is way more "readily available to consumers" on world average.
- simonh 6y ago
  I’m not sure I’m understanding you. Are you arguing that more ordinary consumers have and are using XMPP than are using iPhones, or are you arguing that in theory they could and therefore.... something. I’m just wondering what proportion of those people on $10 a day are happy XMPP users. There’s a serious point here. Highly technical, bare bones infrastructure componentry like this isn’t actually free to use. It requires that the user have an extensive set of incredibly valuable skills that are very expensive to acquire. In fact I’d argue the skills needed to understand and effectively use a solution like this from scratch, including setting up and running a server, cost a heck of a lot more than $600. That’s aside from the opportunity cost of learning all that, and setting up and running a server.
- sascha_sl 6y ago
  Maybe in direct comparison to iMessage and considering only economic factors of "availability". Ease of use and how easily your contacts adapt a messenger are far more important factors to your average consumer. If you really want to argue economics, it's hard to argue with any of the other free messengers (Signal, Telegram, WhatsApp, etc.) over XMPP.

Andrew_nenakhov 6y ago

Gtalk was polished enough. It didn't have OTR built in, but majority of users don't really need end to end encryption anyway, it only makes their life not good. Also, iMessage never reached a level of polish to work on anything not produced by Apple. If we're taking proprietary vendor specific secure services, Blackberry did it before Apple, too. So, definitely not the first and not the only.

derefr 6y ago
E2E encryption is mostly for people whose lives are already not good. It only works to help those people, though, if enough “civilian” traffic is also using it that any ISP blocking it would be considered to be breaking the Internet. BBM was not E2E encrypted. BlackBerry always retained the capability to read your message traffic. Apple does not.
- Andrew_nenakhov 6y ago
  > Apple does not. Well, I'm not _that_ familiar with BBM since it was never available in my country. But what makes you think Apple can't read your messages? Do you have any encryption keys that you share between devices? Or you just enter login/password on a new device and voilà all your messages are displayed to you? If that is so, I guess I'll have to tell you something... Anyway. Last time I checked, iMessage apps source code was not available, you can't verify fingerprints of your contacts in iMessage, so... how do you know Apple doesn't insert a very simple MitM agent that does e2ee both for your and your chat partner, having all messages nicely decrypted in the middle? So far it looks like the only thing that makes you think Apple can't do that is because they pinky promised this to you. Sorry.
  - derefr 6y ago
    > Do you have any encryption keys that you share between devices? Or you just enter login/password on a new device and voilà all your messages are displayed to you? You should really look more into the iMessage encryption scheme before attempting to fear-monger about it. The approach it uses to multi-device encryption is well known[1][2], and is basically its entire innovation over other clients—an approach that every other piece of E2E-encrypted chat software has been encouraged heavily to copy, but for some reason none yet have. (WhatsApp specifically is often ridiculed for its requirement to route all your messages through a "primary device", which feels like going back in time after experiencing iMessage's approach.) [1] https://support.apple.com/en-ca/guide/security/secd9764312f/web https://support.apple.com/en-ca/guide/security/secd9764312f/... [2] https://support.apple.com/en-ca/guide/security/sec70e68c949/web https://support.apple.com/en-ca/guide/security/sec70e68c949/... To save you the trouble of looking it up: you don't "log into iMessage." There's no such thing as a central "iMessage account." Instead, in iMessage, your devices synchronize state with one-another by participating in an ad-hoc group based on a shared "key bag" of all your devices' private iMessage signing keys. When you get a new device and want to join it to this existing group, it sends out a signed request on an announce channel corresponding to your iCloud identity, requesting that another device in the group "invite" it to the group. From the user's perspective, this appears as their new device telling them that the iMessage sign-on needs to be confirmed on an existing device; and a modal popping up on all their existing devices, asking whether they want to accept the new device's join request. If the user confirms the join request, then the existing device the user confirmed on will take its own iMessage keybag, encrypt it with the new device's public key, and send it to the new device. This will then allow the new device to securely "introduce itself" to the rest of the group. Throughout this process, no key material ever travels unencrypted through Apple's servers. Apple can't recover your iMessage keys; nor are Apple's servers an implicit "participant" of your iMessage sync group. iMessage's cloud backend is, during this pairing process, just a dumb message-queue system between your client devices, one that sees only opaque encrypted messages. (Note that this also means that it's totally possible to get "locked out of" your iMessage sync-group if you lose access to all your existing devices. This is usually fine, because 1. iMessage clients won't sync history from before a new device joined the group with that new device, so you're not losing access to anything you had any potential to recover anyway; and 2. you can make a new sync-group under an existing iCloud identity/phone number/IMEI/etc., because none of those visible identifiers are the primary key of the sync-group. The sync group has no primary key. It's not a central "entity" with an identifier. It's a mesh, that happens to be reachable through identifiers it registers to—sort of like softphone apps registering a DID number. But those actively-registered aliases aren't a means of security, nor recovery.) > Last time I checked, iMessage apps source code was not available People interested in messaging security don't tend to trust source code even if it is available. Unless the build process is deterministic and replicable by the researcher themselves—to produce exactly the artifact distributed by the store—then who knows what of the published source actually makes it into the published binary, and/or what-all else ends up in there as well. (Would you trust Chrome [the binary] just because Chromium is open-source? Would you trust macOS [the binary distribution] just because the XNU kernel and BSD userland are open-source?) Instead, security researchers dump packet captures and analyze them. And, in this case, those packet dumps reveal that iMessage does... exactly what is stated above.

Dahoon 6y ago

You are arguing that a $600+ phone for yourself and all your friends is more "readily available to consumers" than a $0 downloadable open source open standard software with multiple clients available? Two-thirds of the world population live on less than $10 a day. You are living in quite the bubble. XMPP is way more "readily available to consumers" on world average.

simonh 6y ago
I’m not sure I’m understanding you. Are you arguing that more ordinary consumers have and are using XMPP than are using iPhones, or are you arguing that in theory they could and therefore.... something. I’m just wondering what proportion of those people on $10 a day are happy XMPP users. There’s a serious point here. Highly technical, bare bones infrastructure componentry like this isn’t actually free to use. It requires that the user have an extensive set of incredibly valuable skills that are very expensive to acquire. In fact I’d argue the skills needed to understand and effectively use a solution like this from scratch, including setting up and running a server, cost a heck of a lot more than $600. That’s aside from the opportunity cost of learning all that, and setting up and running a server.
sascha_sl 6y ago
Maybe in direct comparison to iMessage and considering only economic factors of "availability". Ease of use and how easily your contacts adapt a messenger are far more important factors to your average consumer. If you really want to argue economics, it's hard to argue with any of the other free messengers (Signal, Telegram, WhatsApp, etc.) over XMPP.