• GenderNeutralBro@lemmy.sdf.org
    link
    fedilink
    English
    arrow-up
    178
    arrow-down
    1
    ·
    1 year ago

    They’ve stated that they are using Mac minis as relays. They claim that they do not store messages or credentials, but I don’t see how that’s possible if it relies on a Mac or iOS relay server that they control.

      • SHITPOSTING_ACCOUNT@feddit.de
        link
        fedilink
        English
        arrow-up
        19
        ·
        1 year ago

        They might be able to relay them in a way that the end to end encryption is actually handled on the phone and the relay only relays encrypted messages.

        That would likely still give them a capability to MitM but it’s plausible that they couldn’t passively intercept the messages.

          • KairuByte@lemmy.dbzer0.com
            link
            fedilink
            English
            arrow-up
            10
            ·
            1 year ago

            Absolutely. The iMessage network isn’t some unknowable beast, it “just” requires an Apple device be involved and activated to work. In order to spoof that far, you’d essentially need to emulate quite a bit on device.

        • infinitepcg@lemmy.world
          link
          fedilink
          English
          arrow-up
          10
          ·
          1 year ago

          You give them the credentials for your Apple account. The security concept is “trust me bro” and that’s really the best they can do unless Apple helps them (which they have no reason to)

          • realharo@lemm.ee
            link
            fedilink
            English
            arrow-up
            7
            ·
            edit-2
            1 year ago

            “Trust me bro” is always the security concept of any service where you don’t control the client - that includes regular iMessage (you have to trust Apple) and Google’s RCS (you have to trust Google). They can always instruct or update the client apps on people’s phones to start doing something they weren’t previously doing.

            That being said, I would not trust some random sketchy company with something so important. Even if you trust their intentions, you cannot trust their competence in preventing breaches. Stuff gets hacked and leaked all the time.

        • kirklennon@kbin.social
          link
          fedilink
          arrow-up
          6
          ·
          1 year ago

          They might be able to relay them in a way that the end to end encryption is actually handled on the phone and the relay only relays encrypted messages.

          They’d need to control the app on both phones in order to control what it’s encrypting/decrypting. Their system only works because they’ve got a device in the middle separately decrypting/re-encrypting each message. Google’s Messages app can’t read iMessages; Apple’s Messages app can’t read Google’s proprietary encrypted RCS messages.

          Of course if you want universally cross-platform messaging, complete with full-resolution photos and available with end-to-end encryption, there’s this crazy new technology called “email.” I feel like there’s a missed opportunity for making setting up S/MIME easier.

      • 𝕽𝖔𝖔𝖙𝖎𝖊𝖘𝖙@lemmy.world
        link
        fedilink
        English
        arrow-up
        3
        ·
        edit-2
        1 year ago

        If it’s anything like Beeper 's Matrix bridge then it’s E2EE Matrix encrypted between your device and the bridge server and then using Apple’s iMessage encryption between the bridge server and Apple/the other user.

        The weak point is always going to be the bridge software as by necessity the message must be decrypted there to re-encrypt for iMessage.

        At least in Beeper/Matrix the bridge software is open source and one can host their own bridge while continuing to use the existing Beeper/Matrix main server.

        Doing so gives you no-trust security since the Beeper/Matrix host cannot decrypt the messages between you and the bridge you control and rubbing your own bridge eliminates that weak point.