Skip to content

Comment on GrapheneOS' rewritten Messages app is released

Comments

Does it do RCS?

We've announced our plan to add RCS with Messaging Layer Security (MLS) for E2EE compatible with Google Messages and iOS. SMS/MMS will only be a fallback once that's implemented.

No. RCS is still quite hard to actually implement. There's an open issue for it but the effort is mildly herculean.

AFAIUI though GOS does intend on providing an RCS impl eventually even if it takes years to do.

I'm really hoping they're doing this to pave the way for an RCS implementation. If it can be done, GOS is in the best position to make it happen, and without RCS, chatting with normies is both extremely inconvenient (large group chats straight up do not work) and categorically insecure. If I could convince all my friends and family to use Signal I would, but they just think I'm on about some weird Edward Snowden shit, and they just write me off as crazy. "Why would I checks notes download software to solve a problem when I could use the one that came with my phone?"

I'll give you the strategy that works for me.

Do NOT talk about privacy, E2EE, or any of that. To regular people, "privacy" has negative value, so even if they wanted something, your talk of private communication and not being scanned by data brokers and governments will make them want it less.

So what to do then?

I present Signal as a novelty and focus on one single feature: "hey, video calls work much better than WhatsApp! Try it out!"

Bam, instant download.

Don't give up the good fight! Took some time but I got the whole family to adopt it as we had no common shared platform before, and it's been great.

I'm thinking quite the opposite. I hope RCS can die fast. We already have chat apps WhatsApp, signal, telegram, you can even create your own. I'm quite happy that SMS for one are not something centralized by the giant US big corp. Would be the dream of Google to get all your messages as a gateway.

So I looked into this because my idea of RCS was that it was pretty decentralized direct encrypted communication.

TIL that RCS was designed as a fairly decentralized protocol where every carrier could run their own RCS servers, but it didnt get adoption. So Google stepped in and built their own routing infrastructure, and now mostly all RCS is centralized on Google's servers (even if you use an iPhone, because the RCS server is mandated by your carrier)

In my neck of the woods Google actually disabled some of that routing infra, breaking RCS, I guess wanting to force the carriers to build out parts of it? Needless to say the carriers wouldn’t have any of it, so as it stands RCS is fully broken, has been for some time, and will continue to be.

This just shows the fragility of the tech and why I wouldn’t want to rely on it for anything crucial.

The implementations of RCS servers that were being done (here in the UK) by carriers, had many issues. A lot of the time your Google messages couldn't connect to the carrier RCS server, messages silently didn't send. I don't know if that was due to something like the carriers not updating their servers, or bad implementation though.

It may take a long time to make a fully standalone implementation and that may not be compatible with most carriers. However, we plan to provide it in the short term through support for using the Google RCS infrastructure. We can have it start out supporting using sandboxed Google Play for RCS activation in the same way Google Messages uses it to replace Google Messages.

particularly if you want to support all of the message-body features, of which there are MANY. it's very business-comms oriented.

I broadly expect third-party RCS apps to drop that though, like how essentially none support all of MMS. did you know MMS supports slideshows (I built support for this once)? 3d objects (mimetype model/gltf+json)? "timed text" (mimetype text/mp4)?

What's so difficult about implementing RCS from a technical perspective?

Thanks! I noticed on one of my phones that RCS breaks once the Messages app is out of date by a certain amount of revisions. I hope this is an arbitrary decision by Google to invalidate older versions, given that the RCS protocol hasn't changed. I wouldn't want the Graphene team to have to keep up with each change Google makes with their Messages app, and instead is a security oversight Google has found in their own app.

also I think RCS is way to insecure for Graphene OS - they have no way of making sure the communication is actually 100% secure.

In my experience, Graphene OS doesn't make compromises.

We've announced our plan to add RCS with Messaging Layer Security (MLS) for E2EE compatible with Google Messages and iOS. SMS/MMS will only be a fallback once that's implemented.

Why would they support SMS then?

SMS is a defacto carrier tech that people expect to work, people also don't expect e2ee or any kind of privacy scheme on SMS but it might be a place to hand communication off to a different tech. Whereas RCS leaks meta data to the goog or worse (I don't know the ins and outs of RCS) but by default I would trust it less then signal, who may also collect meta data leaked through the goog, so I guess the real solution is to be boring and assume there is no security or privacy for anyone of reasonable means.

Signal > RCS > SMS.

Just because RCS can't be done without metadata doesn't mean it's a fruitless endeavor. Why not have someone use RCS to then get on Signal? That is so much better than plaintext SMS to Signal.

And for most people, RCS between Android <-> iOS is the biggest advancement in encrypted communication for the layman that I've seen since Let's Encrypt.

We've announced our plan to add RCS with Messaging Layer Security (MLS) for E2EE compatible with Google Messages and iOS. SMS/MMS will only be a fallback once that's implemented.

Google Messages is essentially the only remaining RCS client for Android and it's the only one with end-to-end encryption. It already works on GrapheneOS via a toggle for ICC authentication extending our sandboxed Google Play compatibility layer. We want to add support for it to our own Messaging app but that's not straightforward since it's not at all an open platform even to the extent of SMS/MMS.

That is a positive progression for sure. I guess it sounds like RCS is gatekept behind a play store API on the android side so there isn't an open source solution quite yet? Mostly I'm lamenting that even with signal there's meta-data you can infer behavior from. I know Session messenger has a bit of a network shuffle (is it garlic routing?) That blurs metadata collection a bit, but then they watered down several of Signals' security/privacy choices. I'm constantly curious and overwhelmed at the choice of text communication platforms, just so many!

The world unfortunately uses SMS for 2FA.

RCS is way more secure than SMS what are you talking about? RCS+MLS (i.e. GSM standard RCS E2EE) is basically as secure as you can get unless you lock all users involved into a specific app (ex: signal, etc)

RCS is really the only thing I truly am annoyed by with rooted devices. If GrapheneOS can build something open that works we should be able to rip it apart and get it to work without passing play integrity.

RCS already works on GrapheneOS via Google Messages using sandboxed Google Play. We have an ICC authentication toggle for granting the required access to Google Play services. We want to provide our own implementation within our Messaging app to replace Google Messages and then we want to provide an alternate backend not depending on sandboxed Google Play, at least for carriers with their own implementation.

For the context, the vast majority of carriers do RCS with Google's RCS servers (https://github.com/phhusson/rcs-scanner). I'm a bit rusty, but to my knowledge the only exceptions are Jio in India, all Chinese telcos, and some Japenese telcos.

Of course it is relevant privacy-wise (Google still gather a lot of metadata about who speaks to who and when), but that's not even the reason I'm mentioning it.

In the RCS specification, there are three lines on a killer-feature: device attestation. A server can whitelist which devices are allowed to connect to it. And of course Google uses this, allowing only Google-certified devices and Apple devices.

And then, there is actually one RCS client for Google's RCS servers. Because Google Messages doesn't use RCS, it uses a custom protocol based on protobuf. My personal guess is that this protobuf is a 1-to-1 matching with actual RCS, and it's both-way compatible. But still, that means that potentially the Google device-attestation won't work with an RCS client.

Sibling comments say that GrapheneOS plan on implementing it. I think it can reasonably work. TBH I'm expecting that giving a LLM the publicly available information about RCS on microG should give a working "send message" within a day (even when using Google apps rather than microG, it's just that the microG work explains the API). And once RCS work in GrapheneOS' message app, it should be pretty straightforward to port to microG, so yay. However I have to admit I'm not optimist about how long it will keep working. I'd say we are two years away from Google enforcing RKP device integrity for RCS, and uh, good luck passing that.

Of course, I'm hoping that, in the EU, the DMA will break this Google/Apple-only device-attestation, but I'm not aware of anyone pushing that ATM.

RCS requires Google account and Google Play services, completely useless, I'm better off with Whatsapp not requiring any of these to function, heck I xan even download APK directly from whatsapp website without play store or aurora

Not yet, but they do plan to add support for it.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.