If this were an in-depth announcement with a long and well-structured technical justification attached, I could understand. Though I suspect I'd likely disagree with the decision, I could probably accept it as a simple different of opinion if the arguments were evidently well-thought-through and considered.
This blog-post is so lightweight. There's no technical analysis. There's barely any justification. Yes we know SMS is insecure and yes - it seems plainly obvious that having them in the same UI could pose UX challenges & user confusion issues. So improve the UX and clarify the distinction. Did anyone in Signal consider the userbase or the advantages of this feature at all?
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. Having a separate app for those people isn't worth my while (they're on other platforms I use more).
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.
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."
... 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 ?
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.
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.
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.
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).
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?
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.
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.
If this were an in-depth announcement with a long and well-structured technical justification attached, I could understand. Though I suspect I'd likely disagree with the decision, I could probably accept it as a simple different of opinion if the arguments were evidently well-thought-through and considered.
This blog-post is so lightweight. There's no technical analysis. There's barely any justification. Yes we know SMS is insecure and yes - it seems plainly obvious that having them in the same UI could pose UX challenges & user confusion issues. So improve the UX and clarify the distinction. Did anyone in Signal consider the userbase or the advantages of this feature at all?
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. Having a separate app for those people isn't worth my while (they're on other platforms I use more).
The migration off it will be an unwelcome pain...