Re: Encryption comes to RCS at last on iPhones.

On Tue, 18 Mar 2025 07:25:55 +0000, Andy Burns wrote :

when I last asked Andy what he pined for in RCS, it was "net-based"
texting (SMS/MMS) because of how they're charged for texts in the UK.

 Since apple implemented RCS, I haven't 'hounded' my iPhone-using friends to upgrade/enable it, but they do seem to be doing it.

Thanks. You are the first person to describe to me WHY you wanted RCS more
than a year or so ago, as I didn't see what it did that PulseSMS didn't do.
 <https://home.pulsesms.app/overview/>
Even the iOS messages app doesn't do anything that PulseSMS doesn't do
(although to do it requires an account on a server just like with iOS).
The main difference, I think, once this is implemented, is we'll have LOTS
of messaging apps that can handle RCS/MMS while iOS will still have only 1.
It looks like when the new RCS/MLS stuff is included by both Apple and the
Android messaging apps, then our new terminology can be SMS/MMS/RCS/MLS
(or maybe just SMS/MMS/RCS since the MLS is just the protocol being used).
Apparently the (future) flow is thus for Android to iOS (RCS/MLS):
1. The user composes a message in their chosen messaging app.
2. The app determines if the recipient (iOS user) supports RCS/MLS.
3. The Android device and the iOS device perform the MLS key exchange
   to establish shared secret keys. This happens after the RCS/MLS
   status is determined and before the message is encrypted.
4. The message is encrypted end-to-end using MLS on the Android device.
5. The encrypted message is sent from the Android device to the T-Mobile
   RCS infrastructure or to Jibe's RCS hub, depending on carrier setup.
6. T-Mobile or Jibe routes the RCS/MLS message to Apple's iMessage servers.
7. Apple's servers receive the RCS/MLS message.
8. The Apple servers then route the message to the destination iOS device.
9. The iOS device receives the encrypted message.
10. The iOS device decrypts the message using MLS.
11. The decrypted message is displayed in the iOS messaging app.
It's almost the same flow from iOS to Android (RCS/MLS):
1. The user composes a message in the iOS messaging app.
2. The iOS device determines if the Android recipient supports RCS/MLS.
3. The iOS device and the Android device perform the MLS key exchange
   to establish shared secret keys.
4. The message is encrypted end-to-end using MLS on the iOS device.
5. The encrypted message is sent to Apple's iMessage servers.
6. Apple's servers route the RCS/MLS message to the T-Mobile
   RCS infrastructure or to Jibe's RCS hub.
7. T-Mobile or Jibe routes the RCS/MLS message to the Android device.
8. The Android device receives the encrypted message.
9. The Android device decrypts the message using MLS.
10. The decrypted message is displayed in the Android messaging app.
Notice that iOS handles things at the OS level while Android initially
handles things more at the app level, but both interact with the OS.
For example, Google Messages performs checks to see if the recipient's
phone number is registered for RCS while Apple's iMessage system will be
responsible for checking if a recipient is RCS-capable.
Also, key exchange will, apparently,l be done slightly differently, again
mainly because for Android most of the heavy lifting is done by the app,
while for iOS, apparently, the security stuff is handled in the OS.
Android to Android is simpler as there's no Apple server involved.
1. The Android user composes a message in their chosen messaging app.
2. The app determines if the Android recipient supports RCS/MLS.
3. The two Android devices perform the MLS key exchange to establish    shared secret keys.
4. The message is encrypted end-to-end using MLS on the sender's device.
5. The encrypted message is sent to the carrier's RCS infrastructure
   or Jibe's RCS hub.
6. The carrier/Jibe routes the message to the recipient's Android device.
7. The recipient's Android device decrypts the message using MLS.
8. The decrypted message is displayed in the recipient's messaging app.
Note that for Android-to-Android, the message stays within the RCS network.
But for iOS to iOS, the RCS/MLS flowchart is more complicated I think.
1. The iOS user composes a message in the messaging app.
2. The iOS device determines if the iOS recipient supports RCS/MLS.
3. The two iOS devices perform the MLS key exchange.
4. The message is encrypted end-to-end using MLS.
5. The encrypted message is sent to Apple's iMessage servers.
6. Apple's servers route the message to the recipient's iOS device.
7. The recipient's iOS device decrypts the message.
8. The decrypted message is displayed.
But if iMessage is being used:
 If both iOS users are on iMessage, the process is similar to the  RCS/MLS process above, but it uses Apple's proprietary encryption  and key exchange instead.

If the RCS 3.0 protocol exists, there's no reason for Google to stick with their proprietary encryption, so it feels like once apple and google have been through a round of upgrades, we will get interoperability (which we already have) with encryption (which we don't) ...

Google is already on record for ditching the current system, I think:
 <https://www.msn.com/en-us/news/technology/apple-sharing-rcs-encryption-with-android-users/ar-AA1AWeK3>
 <https://www.zdnet.com/article/why-apples-rcs-encryption-move-is-a-privacy-game-changer-for-your-texts/>
 "Google also confirmed to The Verge that it would support   the new standard, making it the first time both Apple   and Google did so at the same time."