Live data from Hacker News

Apple will soon support encrypted RCS messaging with Android users

theverge.com

31–40 of 270 posts

Re: Apple will soon support encrypted RCS messaging with Android users

#31
post #8

Why was RCS even designed with a none encrypted mode? I get that the original spec isn't exactly new, but it's also not so old that encryption, security or privacy wasn't an issue.

It's the evolution of SMS/MMS; development started 18 years ago, in 2007. The modern spec is based on that with a whole bunch of additional revisions for things like video calling and transferring money. It was designed long before major messenger apps had e2ee in the first place.

Had it been designed with the security practices at the time, the protocol would've been ossified to the point of being practically insecure by today's standards. In a sense, the fact nobody cared about it until the spec was old enough to drive is actually good for users.

The GSMA which designs RCS also serves the needs of government agencies that are tracking (international) criminals, so I bet there must have been some pretty strong opposition against E2EE in the official spec. Frankly, I'm surprised they're even putting it in the spec.

Re: Apple will soon support encrypted RCS messaging with Android users

#32
post #5

So essentially, it's not really an Apple thing, it's more that the universal RCS profile just didn't have encryption, and Google RCS was a non-standard extension that nobody else was allowed to use. The real news is the update to GSMA RCS, because without that, none of this matters. What I'm missing in the article is who's going to own the keys and why this is probably going to default to the telcos as if it's MMS. A…

The encryption is based on MLS: https://www.rfc-editor.org/rfc/rfc9420.html I don't think Google wanted to gatekeep their E2EE implementation. They have some generic documentation about how it works: https://www.gstatic.com/messages/papers/messages_e2ee.pdf The thing about RCS is that no messengers seem to care at all about implementing RCS themselves. Part of that is probably because depending on the carrier, RCS ma…

The protocol is open but key exchange is not: even on Android, third-party messengers can’t interoperate with Google Messages. See page 11 of that PDF.

Re: Apple will soon support encrypted RCS messaging with Android users

#33
post #3

When an iPhone sends a message to 555-1212, where does the iPhone get the public key for that number?

Apple runs servers for managing iMessage key exchange, just like Google’s RCS encryption. Both of them use device attestation to restrict access to those servers to their own apps.

Re: Apple will soon support encrypted RCS messaging with Android users

#34
post #8

Why was RCS even designed with a none encrypted mode? I get that the original spec isn't exactly new, but it's also not so old that encryption, security or privacy wasn't an issue.

Encryption and privacy isn't an issue for carriers, which were part of the standard body and operate SMS protocol even in 2025.

You assume everyone has the same goals in mind :)

Re: Apple will soon support encrypted RCS messaging with Android users

#35
post #23

Any news on if/when one will be able to send RCS from a program or device outside the monolith?

Never. It is just a fancy MMS in new disguise. Carriers / patent holders will hold to it forever while praising it as the new best thing.

You can get access to send MMS though. RCS there is no one selling access yet, especially for person to person.

Re: Apple will soon support encrypted RCS messaging with Android users

#36
Unfortunately, RCS on Android requires google apps, so this isn't really a solution to anyone who doesn't want to be tracked by Google everywhere they go.

I'm still a little confused as to what problem RCS is supposed to solve. It is just as centralized as any other chat app, and is a bit more invasive (often requiring device attestation). Is it really worth all this hassle just to not have to install, let's say, Signal?

Re: Apple will soon support encrypted RCS messaging with Android users

#37

Earlier quoted context omitted.

I'm not sure about the case of RCS, but I've seen some instances of a none cipher being better for compression and deduplication, because the encryption messes with the data.

You'd normally compress the data before encrypting it as that makes the resulting cyphertext more resilient against cryptanalysis as well as reduces the amount of data which needs to be encrypted so this sounds like a bogus reason.

You'd have to compress every single message separately and then encrypt them. That's still a far cry from being able to compress across every message.

Re: Apple will soon support encrypted RCS messaging with Android users

#38

Unfortunately, RCS on Android requires google apps, so this isn't really a solution to anyone who doesn't want to be tracked by Google everywhere they go. I'm still a little confused as to what problem RCS is supposed to solve. It is just as centralized as any other chat app, and is a bit more invasive (often requiring device attestation). Is it really worth all this hassle just to not have to install, let's say, Sig…

Now that Signal cannot be the SMS / RCS app, yes that's too much hassle. Network effects are too powerful.

Re: Apple will soon support encrypted RCS messaging with Android users

#40
post #32

Earlier quoted context omitted.

The encryption is based on MLS: https://www.rfc-editor.org/rfc/rfc9420.html I don't think Google wanted to gatekeep their E2EE implementation. They have some generic documentation about how it works: https://www.gstatic.com/messages/papers/messages_e2ee.pdf The thing about RCS is that no messengers seem to care at all about implementing RCS themselves. Part of that is probably because depending on the carrier, RCS ma…

The protocol is open but key exchange is not: even on Android, third-party messengers can’t interoperate with Google Messages. See page 11 of that PDF.

That text seems more a reflection of the fact that only Messages supported it, when the document was written

If they seriously wanted random third parties to implement it, anyhow, they'd have published a specification, not an "overview"

Post reply on HN