Here is their answer:
Hi,
Thank you for your thoughts on the announced SMS removal. The blog post describes all of the biggest factors in making this decision, but I know this is a change that is difficult to adjust to, so I wanted to chime in with some additional info that might give some more context.
1. RCS (Rich Communications Services) is coming, and it doesn’t play well with Signal. I once had a situation when I was sending SMS to one of my friends via Signal, but I wasn’t seeing any of their responses – this was because their app was automatically responding via RCS, which wasn’t delivered to Signal. This is going to continue to get worse, and Signal cannot add RCS support because there’s no RCS API on Android. Honestly, the days of any third-party SMS app are numbered.
2. Proper SMS/MMS support is hard. Signal has to support thousands of devices running dozens of versions of Android. Now multiply that by the hundreds of cell carriers running an inherently bad/buggy protocol, and you’ll start to understand the weird MMS bugs we can run into. And any time spent trying to fix them is time invested in an insecure protocol.
3. SMS/MMS has plenty of its own bugs. Remember that incident a few years ago in which everyone got old Valentine’s SMS messages delivered 9 months later? It was an SMS protocol bug for which some users blamed Signal. Other weird bugs like temporarily-split MMS groups, bad image quality, and the general inability to leave MMS groups are flaws in MMS that also get attributed to us.
4. Spam. My goodness, SMS spam is a real thing, and many people who use Signal cannot tell the difference between SMS spam and Signal messages if both come through Signal. They think we’re responsible for the spam.
5. Finally, Signal having SMS support gives a lot of people the wrong impression of SMS. They think that because SMS is being sent through Signal, it’s actually secure or as secure as an encrypted Signal-to-Signal message, and that’s just not true. We can add unlocked padlock icons to each SMS message, and we can label the message compose box as “insecure”, but the misunderstanding would continue. The only thing we can do is store the SMS messages encrypted on the device, but in my opinion that matters very little when anyone who wants your SMS messages can just get them all from your cell carrier.
In short, SMS is on its way out in general, and in a world where Signal supports SMS, all of SMS shortcomings are often attributed to Signal itself, all while confusing people into thinking their SMS messages are secure.
In my opinion, a secure SMS app does not exist. Just choose the one with the best layout or usability, and preferably one that supports RCS (which I believe at this point are Google and Samsung Messages), because at least then there’s some chance that they might end up being encrypted in the future.
I hope that helps give some more context. And please know that I understand this is difficult to adjust to. I can relate. I’ve used Signal as my SMS app for over 6 years, but I truly think it’s for the best.
And their president also commented on it a bit at https://www.theverge.com/23409716/signal-encryption-messagin...
I do still occasionally get work conversation initiated via SMS rather than WhatsApp especially if that comes from a phone which is associated with a task or job. Like the out of hours mobile phone which is moved between people.
Has there been any new press on this? The last nugget I heard was https://www.android.com/get-the-message/, which didn't really announce any progress.
You can see various threads where people complained about the forced Apple emoji e.g. https://github.com/signalapp/Signal-Android/issues/3712 and https://github.com/signalapp/Signal-Android/issues/3675
Signal's own FAQ says
> Signal Android includes built-in emoji functionality for consistency between platforms
https://support.signal.org/hc/en-us/articles/360017561992-Wh...
My initial response on it being announced in the Signal app was "Oh no, that's terrible!". Followed by "Meh, all software goes to shit eventually. Now it's Signal's turn". Now I already don't really care anymore.
I have been using Silence [0] as my sms app for a day and don't really miss the Signal sms integration anymore.
What bugs me more is that the text message export from Signal seems incomplete. Oh well, I will get over that as well.
(Funnily enough Silence is a fork of Signal for SMS only. I thought it looked quite familiar but just realised it is the case)
Source https://www.ofcom.org.uk/__data/assets/pdf_file/0011/222401/...
SMS decline is probably inevitable though.
https://www.statista.com/statistics/271561/number-of-sent-sm...
The stats show a significant drop as mobile data became cheaper and richer services became available, but still quite a lot of traffic.
I suspect that the people I see using Nokia and Samsung dumb phones will continue to use SMS, so traffic will fall to a sustained tail.
https://www.statista.com/statistics/271561/number-of-sent-sm...
"It doesn't matter for the use cases I don't care about" - what a selfish look at the world.
Besides paying for parking by SMS and other services in Europe there's also M-Pesa and similar services[1]
Telegram has had emoji reactions since 2021 -- https://economictimes.indiatimes.com/magazines/panache/now-y...
MTProto is the name of the:
1. Cloud Encryption
2. E2E encryption
algorithm at Telegram. MTProto 2.0 is not just secret chats, a different implementation is used for cloud: https://core.telegram.org/mtproto/AJiEAwIYFoAsBGJBjZwYoQIwFM...
Both cloud and e2ee consist of what's called the MTProto 2.0 algorithm.
Also see [1], they have every bridge's features well documented.
[0] https://news.ycombinator.com/item?id=33181636
[1] https://news.ycombinator.com/item?id=33179047
[2] https://community.signalusers.org/t/signal-blog-removing-sms...
https://twitter.com/matrixdotorg/status/841424770025545730/p...
Bridging chats of different technologies doesn't work well/at all (i.e. Signal bridge + WhatsApp bridge users in a single room) but bridging external chats (DM or group) into Matrix works very well. Some services need a daemon running on a phone (i.e. WhatsApp) and that's very annoying, but where possible these bridges all run in the cloud.
If you trust third parties, you can also go the easy route by getting a subscription from EMS (https://element.io/matrix-services/ems-pricing) or Beeper (https://www.beeper.com/). I personally prefer to keep my messages and encryption keys on devices I control, but others prefer to let someone else take care of it all and I respect that.
It's relatively straight-forward to set up a bridging server if you're comfortable with Docker and YAML files. You can read how to set up a Matrix server here: https://matrix.org/docs/guides/free-small-matrix-server and here: https://github.com/spantaleev/matrix-docker-ansible-deploy/b...
If you use the Ansible playbook, all you should really need to do is run through the setup, fire up a Matrix client, start chats with bot accounts, and follow the instructions on the guide (usually sending /login to a bot and authenticating your account with whatever service you're bridging).
Your Matrix account doesn't have to be on the same server as your bridges, which is a setup some seem to prefer. You can set up a Matrix server just for bridging so that you don't need to set up all the VoIP features and performance tricks while keeping your own server dedicated to just bridging stuff. This does break some nice features (i.e. double puppeting, a bridge feature) but it also makes your own server less of a single point of failure if you ever do get talking on Matrix.
on this paper: https://nebuchadnezzar-megolm.github.io/
Worth reading the response from Matrix as well (https://matrix.org/blog/category/security).
My first reactions are to wonder how many of these issues are associated with federated (as opposed to fundamentally decentralized) group chat in general. Matrix seems to be taking the position that some of these issues ultimately relate to trust vs lack thereof in the homeserver as a bottleneck.
I also wondered if there was a good security model for federated or decentralized group chat at all at the moment. I can't remember offhand if Briar was adding groups or not, but that's not federated.
The only practical issue raised by https://nebuchadnezzar-megolm.github.io/ which we didn’t already fix is the question over whether servers or clients should control group membership. Our position is that it’s okay for the server to control it as long as clients are warned if malicious users/devices are added. Fixing it properly is Hard: for instance, if you are chatting in a room and it turns out that a remote user kicked another remote user, but the kick was delayed in reaching you, you could keep chatting away encrypting messages for a user who is no longer in the room and theoretically should not be receiving them. Is this a security flaw? Or is this just how causality works? So we’re dealing with problems similar to that; hopefully we will be able to switch to client controlled membership by end of year.
tptacek’s derision is not very constructive.
https://matrix.org/blog/2022/09/28/upgrade-now-to-address-en...