Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.


Phone calls aren't encrypted either, if you think about it [1]. There's a large expectation of the telecommunications industry to be able to perform legal interception, and providing end-to-end encryption out of the box might be seen as a direct violation of that requirement.

[1] Except, somewhat incongruently, between Google Fi subscribers on some Android phones: https://support.google.com/fi/answer/11295314?hl=en – no idea how that came to be and how it even works! I suspect it just upgrades to a FaceTime-like VoIP call.


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 :)


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.


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.


That doesn't allow you to deduplicate across users, though – which of course is the entire point, or the network would be able to see who's forwarding which documents.


It depends on what you're doing I guess... for storage it doesn't make sense, but for pushing a lot of data over a private pipe, why spend the resources adding a cipher?


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.


I assume some sort of multicast.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: