Hacker News Reader

Here's a (partially?) non-technical justification they shared on the Community forums.

https://community.signalusers.org/t/signal-blog-removing-sms...

That post is an excellent justification. Makes perfect sense and it's hard to find fault with it.

Wonder why the blog post omitted all of that and focused on nonsense instead?

Yeah, I 100% agree with you about that and the more I've been digesting that explanation, the more I see why this is the correct thing to do.

Hopefully this even frees them to do things we've wanted for a long time... like not being tied to a phone number and offering better features than RCS/iMessage. Maybe even having multiple independent profiles/pseudonyms for compartmentalization.

That's how Signal could be growing the base and interop with SMS/MMS/RCS cruft on one platform will always lack the killer feature and be irrelevant to the other platforms. If Signal were better than SMS/RCS/iMessage people will just use it for those reasons in addition to the security and privacy.

And having just installed the beta and used the SMS export and allowed it to purge all of SMS content from Signal into Google Messages it actually sort of is nice that the app is now ONLY the "Signal" context. I'm... actually pretty okay with SMS belonging to the "Stuff that Creepy Companies Like Google Know" context.

Basically this just does what Signal already does in iOS: it must compete with the native messaging client. Google is already playing RCS as SMS upgrade and Signal is making the correct strategic decision to not make a play for RCS. SMS support is just going to lead to whining about lack of RCS. The bottom line is both Apple and Google are out to kill SMS. With SMS gone, Signal can just move on to feature parity with iMessage and beyond while leapfrogging whatever messaging clusterfuck Google keeps producing. Google can have SMS for all I care. We can't have iMessage on Android, but we can have Signal on both Android and iOS.

>Signal can just move on to feature parity with iMessage

And fragment the market even more?

Thanks. This link should really be higher up in the comments. The community forums discussion is much more interesting than the blog post.

This is a great explanation, at least for HN readers.

I found two top-level comments linking it, upvoting those might help:

- https://news.ycombinator.com/item?id=33181525

- https://news.ycombinator.com/item?id=33181647

I get these are reasons against SMS, but somehow don't convince me that removing SMS from Signal is the right thing to do right now.

They definetly should publish those points out in the open. After reading this, it just make sense they are dropping SMS, as infuriating as it is. Thanks for the link.

I guess to be fair it lets them design and support a single UX since iOS doesn't allow them to have SMS in the UX. That could have been a good argument.

Of course, they didn't bother make that argument.

And in the SMS domain Google Messages really does get annoying with the whole Google Messages vs iMessage and how nothing Google is doing with RCS benefits anyone except Google. As Google continues its war on SMS and force migration of everyone to RCS, Signal users on Android end up being the red-headed step child. That also is a good technical/strategic argument for ditching SMS.

But, again, not one that they even bothered make.

And there's always been the "tied to a phone number" issue that's been the #1 complaint about Signal. And once untethered from SMS who cares about phone numbers anymore.

Once again, not even a case they bothered to make.

The answer is this: They dont want to add RCS support or spend the time to do it. It's all bullshit top to bottom.

Google also restricts their specific flavor of RCS (or at least they did awhile ago). I wanted to keep using Textra SMS but they never let Textra into RCS land.

If they said that up top I think many more people would be accepting of it.

There are no public RCS API's. No one (besides an OEM) can make an RCS app.

Google doesn't allow 3rd-party apps to access the RCS API.

"The answer is this: They dont want to add RCS support or spend the time to do it."

... confirmed by Signal in their discussion thread:

"... and Signal can’t add RCS support because there’s no RCS API on Android. Honestly, the days of any third-party SMS app are numbered."

I guess I misunderstood RCS. I thought the whole point of RCS was to be used on Android and to allow disparate third parties to use it as an open standard.

Where is the RCS API if not on Android ? Who is supposed to use RCS ?

The API is private to system apps from the device manufacturer. Most phones ship Google's Messages app for SMS & RCS.

Improving UI/UX around to clarify the SMS function is insecure is almost impossible. Google did research around SSL cert warnings a few years back, their conclusion was that people don’t read and just dismiss warnings, no mater what UI was. A frightening percentage of people also think the security padlock icon is actually a handbag.

Most people simply lack the technical basis to understand the security implications of sms. And for Signal to be a secure messaging system by default SMS needs to be removed.

That's assuming a lot of context. Your talking about a tiny icon next to the address bar in a browser. Of course people didn't always know what that was!

Signal's primary feature is encrypted messaging. You don't get it without at least seeing the word "encrypted" somewhere.

Counter point most people think Telegram is e2ee secure messaging, but Telegram never said they were.

And that doesn't get clarified by UI that distinguishes between encrypted messages and SMS, because Telegram doesn't have such a thing to distinguish between.

My point is that all of this is orthogonal to whether Signal can successfully make UI show users when they are sending encrypted messages vs unencrypted SMS.

Most of the confusion you are citing is about whether an app does encryption or not, and that is a totally distinct problem domain.

You’ve failed to make a distinction between e2e encryption and TLS encryption, how do you explain that in UI?

The people you talk about see no sense to use signal at all. So why should they install it when they have SMS? And when Signal is installed, why should the change the app and use signal instead of SMS?

The only similarity between these two UX scenarios is that they involve encrypted network protocols. From a user standpoint there's no similarities.

Firstly, the messaging decision is presented to the user before an action (send SMS/Signal). It's capable of blocking and takes place as part of an active use flow where the user is trying to complete a task. With browsers, the differentiation in UI is displayed after a user action. It doesn't block and the user doesn't require interaction to achieve any goal. Why on earth should they pay any attention to it?

Secondly, the UX for messaging is an equivalent paths binary decision: you're asking people to choose A or B. There isn't an inherent default so a user doesn't start out with a bias toward one or the other. They can easily be required to read to proceed.

With browsers it's a yes/no binary decision: the default (yes) is insecure (for an insecure website). It requires no action from the user. The secure option (no, leave) asks the user to do something. It's a choice between inaction (insecure) or action (secure). That's heavily stacked.

Lastly, even the context surrounding the apps themselves is incomparably different. One is a security upgrade of an application everyone's been using for decades (often unknowingly; "the icon for the internet"). The other is an app people consciously download and install explicitly for security reasons (regardless of whether they understand those security reasons it's at least the motivating factor).

What kind of technical analysis would you be looking for? Reading the post, it seems like their analysis came down to (1) fundamental values, i.e. not including insecure communications within an app when they've built their brand around being secure, and (2) UX confusion resulting in additional SMS costs and/or inadvertent data leakage. The former is a straightforward question of product strategy. Are you looking for e.g. some numbers from their UX research? This doesn't seem to ultimately be a decision about underlying technology.

> Definitely the end of my Signal usage anyway. It's my main SMS app: my primary motivator is SMS UX, the ability to securely message a tiny subset of my friends is a very nice but ultimately non-vital bonus.

I think this is the crux of it. Your primary motivator may be for a better SMS UX. But Signal's primary motivator is to provide universal secure messaging, but your typical use of Signal doesn't do that. So it's no surprise that their plans mismatch your expectations.

> your typical use of Signal doesn't do that

All centralised & protocol-locked messaging apps are subject to network effect. People moving away from Signal doesn't help the goal of universal secure messaging, regardless of whether those people are you or I.

That said, it seems they're between a rock & a hard place here since Google are defacto deprecating support for 3rd-party SMS apps.

That's just wishful thinking. Any opportunity for a network effect to assist with Signal's adoption is long gone. It never managed to hit the necessary threshold and without platform ownership, there's little chance it will.