E2EE for SMS /MMS (and even RCS)

[ElsAr4e]

Checklist

• [x] I made sure that there are no existing issues - open or closed - to which I could contribute my information.
• [x] I have read the FAQ and my problem isn't listed.
• [x] I have taken the time to fill in all the required details. I understand that the feature request will be dismissed otherwise.
• [x] This issue contains only one feature request.
• [x] I have read and understood the contribution guidelines.

Is your feature request related to a problem? Please describe. NO

Describe the solution you'd like I would like to have the possibility like Silence or Deku to enable E2EE for SMS or MMS (and even RCS)? Maybe you can also use a qr code to enable the e2ee: https://github.com/deku-messaging/Deku-SMS-Android/issues/183

Describe alternatives you've considered Until now I only know Silence (https://git.silence.dev/Silence/Silence-Android) or Deko SMS (https://github.com/deku-messaging/Deku-SMS-Android) for E2EE SMS or MMS

Additional context Maybe you could have settings (opt-in) that messages without E2EE are not accepted / send an error message Display a warning if the messages don't have E2EE (opt-in; like a red lock icon)

[Aga-C]

Isn't it too much for this app? What do you think @naveensingh?

[ikanakova]

I think RCS would be great and another E2EE would be unnecessary.

[ElsAr4e]

I think RCS would be great and another E2EE would be unnecessary.

But if the other device does not have RCS it will be automatically converted into an SMS or MMS without E2EE? So you would have to prevent that?

[naveensingh]

Nope, too much and too soon.

As far as I know, there is still no API for RCS.

[moriel5]

Hmm... I remember that back in the day, CyanogenMod included E2EE SMS/MMS via WhisperPush.

I wonder whether it may be possible to make a common library for FOSS apps to include something similar. Perhaps the Silence devs could assist in that matter.

[inson1]

I think there should be issue (with blocked label) or discussion about rcs

And E2EE is great, but its hard feature, so I'm for reopening and deleting the part about rcs

[jayb-g]

RCS support will be a great plus and more than required for an SMS app as more providers (already) adopt it in coming years. Of course the fallback will always be the plain old SMS

E2EE would definitely be too much too soon.

[moriel5]

@jayb-g I just read a bit more about RCS recently, and I am starting to understand why it is so hard to implement.

Part of the problem with RCS is that while it is technically a standard, the way it is ratified makes it's status as an open standard dubious, since it is not clear whether all the necessary details for implementing it are actually provided without a license from the GSM association, and in the current situation, the way that the existing solutions are implemented, makes it little better than iMessage in terms of standardization.

Personally, until someone with the know-how and capabilities steps up to clear the situation, I think that E2EE support is actually more practical, since the current solutions render RCS a huge privacy and closed garden risk.

[jayb-g]

Part of the problem with RCS is that while it is technically a standard, the way it is ratified makes it's status as an open standard dubious

Agree

I think that E2EE support is actually more practical,....

Not really. E2EE (even with just plaintext sms support)would need a whole lot of keysharing(and thus privacy issues?) mechanism and enc/dec in place and maybe also internet permissions for that which would make the app basically another chat App and not carrier SMS app.

since the current solutions render RCS a huge privacy and closed garden risk.

Completely agree. But isn't RCS already an open standard? Although it doesn't have E2EE in built, but apps implementing RCS can. Different carriers/countries can use RCS to communicate. See specifications section in wiki

[moriel5]

That is quite interesting, although I am sure that a compromise could be found (perhaps with decentralized key-sharing, though that in itself would take some creative thinking to both preserve privacy and security, and getting more people to easily use it).

Regarding the last part of your reply, the first part of my reply answers that.

By the way, as it currently stands, current RCS apps (such as Google Messages) are basically chat apps with additional SMS support, so if we are already going that way, I personally do not think that E2EE-enabled SMS apps, even with online key-sharing (preferably via P2P means) would be an issue in that regard, so long as it is optional.

[jayb-g]

Sure, but without different devices/operators/OSs/Apps following the same standard like RCS(our best bet as of now), it would again lead to creation of a walled garden.

Google has already done most of the work to bring operators and devices/OSs(ie Apple/iMessage) together to support RCS

[moriel5]

That's the problem, that at this point in time, RCS is almost a walled garden itself, where it is questionable if anyone who is not approved to set up an RCS server could do so, and almost everyone who has an RCS server is closing theirs in favor of Google's.

So while RCS may potentially be the best bet, in it's current form it's almost the same situation as with iCloud, just with Google instead of Apple.

Google has done a lot of work, but most of it was not to bring everyone together with RCS as a standard (they tried doing that a little at the beginning), but rather to be a walled garden where they are the warden.

[jayb-g]

Google has done a lot of work, but most of it was not to bring everyone together with RCS as a standard (they tried doing that a little at the beginning), but rather to be a walled garden where they are the warden.

Maybe they wanted an open alternative to imessage basically which is inherently designed to work with apple devices only.

Well, hard to say what their intent was/is but if RCS is moving towards a standard it really depends on the industry adoption whether it remains walled garden or not. (I believe non-Google(or any/all) RCS users can/should be able to communicate with each other as per the standard)

[moriel5]

Originally, that is very probable, however they may have hit a roadblock not related to adoption that made them give up on open standards (and standardization in general, both of which mark a trend with Google lately abandoning with specific things).

If RCS was moving towards a standard, then I would have agreed with you, since I would be all for a proper standard that would also be as good or better than iMessage to be adopted, however it seems that RCS is currently heading in the opposite direction, especially with GSMA's outlining of the standard being as sketchy as it is.

I'm not saying to give up on RCS, but rather that we need people with proper understanding of both programming and law to unravel the mess that RCS currently is before we can even begin talking about supporting it.

There is a real reason why RCS doesn't have any FOSS support yet, and it's not for lack of interest, but rather lack of a foothold on how to support it.

[jayb-g]

There is a real reason why RCS doesn't have any FOSS support yet, and it's not for lack of interest, but rather lack of a foothold

Hoping that would change soon.

[MulverineX]

In theory it would be possible to roll your own RCS implementation since the protocol is documented, but this would also require rolling an independent authoritative alternative to the Google Jibe service. That's just not something a hobby project like this has the resources to accomplish unless the team accepted a partnership with FUTO or something (this would be ideal).

Ideally Google would've made stock RCS w/ Jibe integration a system component with a rich API that any app can implement, but unfortunately, due to their close minded bullshit surrounding "spam prevention" (doesn't prevent any of it), they rely on Play Integrity (previously known as SafetyNet) and their own ARR closed-source app.

Another option would be for a company like Beeper to step in and make their own authoritative RCS service, but at the moment they haven't expressed any interest in this, likely due to the popularity of alternatives like Signal & WhatsApp.

[MulverineX]

@naveensingh I'm curious what your opinion would be on partnering with FUTO in a similar way to Immich, to accomplish the goal of bringing a more open RCS service to users?

[moriel5]

Partnership with FUTO for this would certainly be nice, at least for clearing up RCS's current sketchiness (the documentation is far from comprehensive about certain things, such as who even is allowed to roll their own server implementation, according to the GSMA's own rules).

[ElsAr4e]

As mentioned until now you can try Silence (https://git.silence.dev/Silence/Silence-Android) or Deko SMS (https://github.com/deku-messaging/Deku-SMS-Android)

Exodus shows 2 known trackers if you scan Deku SMS: https://reports.exodus-privacy.eu.org/en/reports/460028/

Or you use Messengers like SimpleX Chat (https://simplex.chat/)

[naveensingh]

Anything RCS/E2EE related is for the future. Nothing can be said now.

[MulverineX]

I'm not asking for a timeline, to have this feature soon, nor do I really care about E2EE that much, I was just curious whether you would be interested in a FUTO partnership?