"Carlos E.R." <robin_listas@es.invalid> asked
> Oh, wait, we don't know if the Samsung app does encryption. We know the
> Google one does. It is of course possible other makers could replicate
> or integrate that encryption.

What I'm trying to clarify is what _path_ RCS takes, encrypted or not.

> <https://en.wikipedia.org/wiki/Rich_Communication_Services>
> Rich Communication Services (RCS) is a communication protocol
> between mobile telephone carriers and between phone and carrier

I read that wikipedia on RCS but it doesn't tell me all that much.

It's mostly about the "history" of RCS, but I'm looking for specifically the
_path_ a 1:1RCS message takes from phone 1 to phone 2 (encrypted or not).

But I'll check out the links, as you suggested, in that wikipedia article.

> (2) <https://www.gstatic.com/messages/papers/messages_e2ee.pdf>
> You say you have some Samsung phones, so you can test this (with updated
> apps). The PDF shows how the messages display when encryption is used.

In that Google "Messages End-to-End-Encryption" technical paper they say
"RCS uses the standard SIP protocol to establish a connection between two
clients through a network of RCS messaging servers."

In addition, it says "Most RCS server deployments are either hosted by a
carrier or by Jibe Mobile <https://jibe.google.com> from Google" and they
say when the two RCS clients aren't on the same carrier network, then
"they're connected through multiple servers - one from each carrier."

That intimates the message path in the worst case could be something like:
1. Phone 1 with RCS app n <-> carrier x's RCS server
2. Carrier x's RCS server <-> carrier y's RCS server
3. Carrier y's RCS server <-> Phone 2 with RCS app m

The paper says these servers can access the following metadata
a. Phone numbers (senders & recipients)
b. Timestamps & approximate size of messages
c. IP addresses (or other connection information)
d. Mobile carriers involved
e. Headers (SIP, MSRP, CPIM)
f. Attachment (yes or no), URL (if stored on a server), & size

The paper intimates Google's RCS server "can" also be in that routing.
Note that the public key exchange uses a different pathway (see below).

> My own Samsung is way too old.

I still have my old $800 Samsung Galaxy S3 somewhere, but Android phones
just get better, faster & cheaper (like almost all consumer electronic
devices do except for those where marketing is highly successful in keeping
profit margins extremely high) so I have lots of Android phones now, given
that I still have my circa 2017 Android 7 $130 LG Stylo 3 Plus phones from
Costco, and my circa 2019 Android 9 $100 Moto G7 phones from Google, and now
a handful of 2021 Android 11 Samsung Galaxy A32 5G phones from T-Mobile.

This is clear about the fact that (at least in June) the Samsung app didn't
have the encryption inside of it (even as the native Google app does)
<https://www.inputmag.com/tech/android-now-has-encryption-in-rcs-messages-several-other-new-features>
E2E encryption "only applies to chats sent between two Android users who
are both using Google's Messages app. That means any conversations you
have with someone who is using a different app, like Samsung Messages
or iMessage on iOS, won't be encrypted."

The latest Samsungs apparently use Google Messages natively but for Android,
being native doesn't matter since you can run any messaging app you want to.
<https://www.cnet.com/tech/services-and-software/samsung-galaxy-s21-makes-google-messages-app-native/>

>> Nobody yet has shown what the _path_ is that an RCS message takes, given
>> only the _app_ is from Google, whereas the _carrier_ sends the RCS message
>> over their cellular or Internet (and it's over your ISP when on home Wi-Fi).
>
> Read that PDF :-)

That PDF is useful but it mainly talks about the Google "Messages" app.

The PDF does mention that RCS & E2E is automatic and that the public key
(per app install and/or device) is also transferred automatically.

The paper says the "central key server" is currently only hosted by Google.

That implies that Google is always involved, at least the first time
(and any time that the public keys need to be refreshed or re-exchanged).

>> As far as I could tell when I skimmed the RCS links Steve cited, the 1:1
>> encryption is completely handled on the two respective phones themselves.
>
> Yep.

The encryption described in that paper mostly assumes both phones are using
Google's Messages app for the encryption with a fallback to unencrypted RCS.

This Google advertisement implies Google gave RCS-encrypted "Messages
Improved" to the carriers who could then rebrand it as their own app.
<https://messagesimproved.com/rcs/>
"Messages Improved's RCS is the first end-to-end encrypted RCS on the
market. This means we can offer you the improved messaging functionality
of RCS, along with a more secure messaging protocol. Messages will only be
encrypted when sent between you and another Messages Improved user
and you are both using RCS."

Apparently "Messages Improved" is an app for "operators":
"Messages Improved is a native (SMS/MMS/RCS) app replacement on Android.
It's the only market-tested P2P alternative to Google/Samsung Messages
that operators can brand as their own. You can think of us as iMessage
for Androids, with encrypted RCS/data messaging (blue bubble) when
messaging other users and native SMS/MMS (green bubble) when messaging
non-users or no internet connection. By branding Messages Improved,
operators can monetize P2P messaging through advertising, without
impacting any existing revenues."

It's looking like we need to learn more about "messages improved":
"The messaging app is becoming the 'everything' app on the phone
and every tech giant is racing to own the most popular one.
We offer device manufacturers and mobile operators the ability to
white-label and preinstall Messages Improved as default on all
Android phones."