- cross-posted to:
- technology@lemmy.world
- cross-posted to:
- technology@lemmy.world
Apple has announced that its Messages app will support the RCS messaging standard in iOS 18. RCS offers more advanced features compared to traditional SMS, including higher-quality media, typing indicators, and end-to-end encryption. This move will improve messaging between iOS and Android devices, which currently rely on the less capable SMS protocol. Apple’s decision to add RCS support likely comes in response to pressure from Google, Samsung, and European regulators who have pushed for better cross-platform messaging. Overall, this change will bring the iPhone’s messaging capabilities more in line with the Android experience.
It’s a shame Apple decided not to implement e2ee like Google did.
This is an older article, but there is still no movement. https://forums.appleinsider.com/discussion/234352/apples-flavor-of-rcs-wont-support-googles-end-to-end-encryption-extension
I don’t blame them. Google invented their own E2EE and kept it proprietary. Apple is asking the people behind RCS to make an official standard everybody can use instead.
If I recall correctly, Google uses MLS for group chats (which should be usable between messaging services) but Signal’s protocol for individual chats, which requires a centralised key server. The latter is also why Signal can’t federate.
Apple and Google could make some secretive deal here where they share the design docs, or Apple could try to reverse engineer Google’s work, but neither seem like a great solution to me. The ball is now in Google’s court.
I didn’t know MLS and Signal were Google proprietary. TIL. Thanks.
Neither is proprietary, but Google doesn’t document how they implement either of them. Signal’s normal protocol is intended for use with a direct client-server connection, but Google wrapped it into a different message transport (RCS, which is just a predefined set of HTTP calls with lots of XML).
They do some sort of base64 encoding to transport the messages themselves, but they don’t document what key servers are in use, how registration works, or how key material is exchanged with those servers. Do they use RCS to communicate with key servers? Do they require a direct internet connection? What about video calls, are they done through standard RCS or do they add encryption there? Do they exchange the encryption keys for video calls through RCS as well? How do keys work if you deregister from Google Jibe and register RCS with your own carrier?
Lots of open questions here. All stuff that can be reverse engineered. I’m sure plenty of companies are trying to figure out how Google RCS works.
I hope Google switches to full MLS (if they haven’t already, they won’t say!) and implement MIMI for secure cross platform messaging once it’s been finalised, but there’s no way of knowing right now.
It’ll probably take several years for them to switch over to MLS. Hopefully other messaging apps like Telegram and Threema can also utilize it just for crossplatform purposes.
I don’t think Telegram will switch to MLS, they haven’t bothered encrypting group chats before and they’re (strangely) defensive of their MTProto encryption layer.
I’m not sure how Threema’s security works, but it’d be nice if they could add a compatibility layer for external chat services.
Thanks for your reply. I understand a lot better now.
I’m pretty sure Signal is not Google proprietary, and the person you replied to didn’t say it was.
The comment said it was proprietary and uses signal and MLS.
Maybe I misunderstood.
The google proprietary part is e2ee on RCS that use signal and MLS. It is not a standard in the RCS specs.
Apple and Google are working together as part of the GMSA committee on RCS to add encryption to the standard, instead of using Google’s proprietary incompatible extension for e2ee.
It’s probably going to take a while due to the whole process needed to add it to the standard, which is also why RCS in general is a terrible idea: you can’t really innovate if everything you want to improve has to go through this whole layer of bureaucracy.