Samsung has released a new video in support of Google’s #GetTheMessage campaign which calls for Apple to adopt RCS or “Rich Communication Services,” the cross-platform protocol pitched as a successor to SMS that adopts many of the features found in modern messaging apps… like Apple’s own iMessage.

  • whofearsthenight@lemm.ee
    link
    fedilink
    English
    arrow-up
    8
    arrow-down
    4
    ·
    edit-2
    1 year ago

    I’ve just been googling a bit because I haven’t read about RCS in a while, but I remember thinking then that the show stopping thing is that it’s not E2E, and Apple would be dumb to move to since iMessage is. It seems now that E2E is supported but requires clients to support it, which tbh seems the worst of all worlds. At least today I know blue = encrypted, green = not encrypted. If it’s optional and we end up in a “is this encrypted? we’ll see ¯\(ツ)/¯” type of world that is honestly terrible. I also don’t know how great it would be if you have to rely on the client vendor to accurately report encryption status because there are some I trust, and especially when it comes to “just download whatever RCS client you want” I absolutely would not trust that.

    • ozymandias117@lemmy.world
      link
      fedilink
      English
      arrow-up
      13
      arrow-down
      2
      ·
      edit-2
      1 year ago

      iMessage is only E2E encrypted if both users have iCloud disabled or have gone into their iCloud settings and enabled “Advanced Data Protection”

        • Natanael@slrpnk.net
          link
          fedilink
          English
          arrow-up
          6
          ·
          edit-2
          1 year ago

          The message transit encryption is on but backups are unencrypted by default, which makes it quite pointless

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

          “Enable” is incorrect, and why I was warning you about it. It’s on by default, so you need to “disable” it if you want E2E encryption

          A blue bubble is unlikely to mean a message is E2E encrypted. That may not matter for your threat model, but Apple almost certainly has the decryption keys for your messages

          • whofearsthenight@lemm.ee
            link
            fedilink
            English
            arrow-up
            4
            arrow-down
            1
            ·
            1 year ago

            Also very good point. My threat model is I don’t want script kiddies with shit that they can get (optionally) off of eBay to be able to read my messages because too many places still default 2fa and other identifiers to SMS. Until RCS defaults to E2E at least in transit, that’s tough. From there it’s still going to be the mercy of what the OS vendor decides, like Apple in this case. That said, if I were worried about government actors or a targeted attack, I would 1000% used advanced data protection.

            Anyway, upvoting your comments as much as I can (+1) because you’re totally right and it’s a consideration you should have.

        • Franklin@lemmy.world
          link
          fedilink
          English
          arrow-up
          3
          ·
          1 year ago

          So essentially they’re just as bad as RCS. Both hamstrung by the limitations of their encryptions interoperability

          • ozymandias117@lemmy.world
            link
            fedilink
            English
            arrow-up
            5
            ·
            1 year ago

            Hamstrung in different ways?

            RCS predates iMessage, but it was never widely adopted. Google has been running with it, but it’s been with Google-specific changes to the protocol

            If they can get others to adopt their extensions as a standard and offer an open source example implementation, it could probably be better than iMessage

            Google has a problem getting other people to use standards they work on because they drop support for them all the time, though