Unable to send non-encrypted SMS to previous TextSecure user

[carpenma]

A friend of mine had TextSecure installed on their device and we exchanged keys. They have since uninstalled the app. My device hasn't realized that they no longer use the service so it continues to try to send encrypted push messages to them. I have tried clearing the app data and refreshing the push directory through the settings to no avail. I have also tried ending the secure session from the padlock menu in the thread but when I do it just changes back to secure before it sends the next message (presumably because it needs confirmation from the other user?). I'm not sure if this is a bug or if I am missing something but I would appreciate some guidance either way. Thank you.

[mcginty]

@moxie0 can shed more light on this. In the mean time, my uneducated help as I understand it: GCM will eventually (emphesis on "eventually") let the TextSecure server know that your friend is no longer a deliverable destination and will deregister them once they haven't been contactable for some amount of time.

[SamWhited]

Perhapse an "Unregister" option in the advanced settings that would allow users to manually remove themselves before uninstalling the app would help alleviate this pain in the mean time? Also, even after the GCM fixes, this way users don't have a brief period where other TS users can't contact them if they remember to de-register themselves.

[moxie0]

If you just untick "push notifications" it'll unregister you. Good enough, or should we do something else?

[SamWhited]

Good to know; thanks.

[cordialc]

I think unticking "push notifications" is sufficient for a user trying to remove him/herself. The problem's a little more complicated when someone else has uninstalled TextSecure without first unticking the "push notifications" box.

I've encountered two problems here:

(1) How do I revert my ongoing conversation with my friend (who previously had, and since has uninstalled, TextSecure) to SMS? My phone still thinks he's a textsecure user.

(2) He shows up at the top of my contacts list as if he does have TextSecure. Presumably it appears this way for other TextSecure users who have him in their contacts. Is there a way to refresh the directory?

[moxie0]

Settings -> Advanced -> Refresh directory

[carpenma]

It might be beneficial to somehow let people know that they should unregister themselves prior to uninstalling the app for the good of their fellow users. Or automate it. Either would be sufficient in my opinion.

[cordialc]

Hm. I tried the [Settings -> Advanced -> Refresh directory] route to no avail. I think what's happening is that the central directory (the directory from which my phone refreshes when you hit 'refresh directory') is itself out-of-date because my friend did not unregister himself before uninstallation.

How long after someone uninstalls TextSecure (without first unregistering) would it take for his/her listing to disappear from the central directory?

[Anaron]

I've come across the same issue. A possible solution would be to unregister someone's number before they uninstall the app.

[generalmanager]

I'll just leave this here as a beacon of hope for the poor folks who deleted the app/wiped the rom/lost their phone without deregistering.

Chris Soyars is working on setting up a webinterface to deregister from WhisperPush for CM users who don't have access to their phones anymore:
http://review.cyanogenmod.org/#/c/60315/

I guess user deletion is not federated, so it won't work directly for TS users. But he is a nice guy and I'm sure he'd give the TextSecure devs access to his solution, when it's done. Adapting it should only be a matter of changing the server address and user credentials then.

[wischi-chr]

in my opinion this is the most serious problem in TextSecure because it prevents layman from using it and this is sad, because overall TextSecure is the best chat/messaging app available. what about the following ideas to solve this problem:

1. unregister push during uninstall (if possible - this would be (imo) best solution)
2. implement keep-alive push messages (which are not visible by default) to check if other clients are still available
3. an option to force a conversation into SMS-Mode (not a real solution but an acceptable workaround ^^)

[generalmanager]

I dont think unregistering during uninstall can be done. There is already a PR to manually force the next message to SMS:
#1116

The easiest solution right now is of course to tell your friend to reinstall textsecure, register for push and unregister from it. Then they can remove TS again. They only need to be able to receive SMS on this number. Unlike with WhisperPush it doesn't matter if they reflashed/lost the phone.

[thenktor]

@wischi-chr IMHO an option to force a conversation to SMS mode is really needed anyway:
Last week I got an SMS by TextSecure user that said he has no internet access for some time. He could use the SMS fallback option to send messages to me, but I had no chance to send him an answer because I could not switch to SMS.

To make thing really user friendly TextSecure even could ask if you want to answer by SMS, if the last received message is an SMS. This already indicates your chat partner currently has no internet access.

[Bluebie]

My friend was using TextSecure on an older android phone, and it's now stopped booting.. I can't text them unless I turn off push all together on my phone, or it tries to go through push and they never see the messages. It also frequently tries to send them encrypted texts, even though they're using an iphone for now (temporarily), even with push turned off. Since the old phone cannot boot anymore.. is there any way to deregister them? After going through similar dramas trying to get iMessage to stop hijacking my texts when I left iOS, I had expected TextSecure to be better than this. :/

[moxie0]

If they can put their SIM into an Android device, install TextSecure,
register, and then unregister, that'll fix it up. We need to eventually
put together a web interface for this, but there's only so much time in
the day.

On 05/22/2014 12:23 AM, Jenna Fox wrote:

My friend was using TextSecure on an older android phone, and it's now
stopped booting.. I can't text them unless I turn off push all together
on my phone, or it tries to go through push and they never see the
messages. It also frequently tries to send them encrypted texts, even
though they're using an iphone for now (temporarily), even with push
turned off. Since the old phone cannot boot anymore.. is there any way
to deregister them? After going through similar dramas trying to get
iMessage to stop hijacking my texts when I left iOS, I had expected
TextSecure to be better than this. :/

—
Reply to this email directly or view it on GitHub
#845 (comment).

http://www.thoughtcrime.org

[mlsxlist]

@thenktor is on the dead-on:
"To make thing really user friendly TextSecure even could ask if you want to answer by SMS, if the last received message is an SMS. This already indicates your chat partner currently has no internet access."

My wife travels abroad with train. She has no data connection and therefore I get an encrypted SMS from her. But I cannot reply because replies are send over data. Actually I need to turn off WIFI and mobile network to communicate with her. After the sms is sent I turn WIFI/mobile network on again. A really weird procedure no user will understand. Why to just give the user the choice? TextSecure supports SMS and data. It should ensure that communication uses always the available channel and is always possible. Just my 5 cents to make a great software I really like more usable.

[jrgifford]

Once this merged in, you will be able to use this tool to handle the re-registration. A WebUI shouldn't be that difficult to do, since this already exists.

[thenktor]

@mlsxlist
These are exactly the problems I'm talking about. Last time my girlfriend has sent me a SMS because her WiFi network has lost internet connection. I've answered by a push message because I even did not notice that I've received an SMS. Of course my answer was delayed until the next day when the internet connection has been recovered.

[alexh3791]

I'd like to see a web-interface that can manage all aspects of TextSecure registration (check status / de-register from push / de-register from TextSecure entirely) as well.

[begleysm]

To add my voice to the crowd: I recently destroyed my Android Phone while trying to replace the screen. I use TextSecure (as does my girlfriend). I have reverted to a "dumb phone" for the time being until I can get a replacement "smart phone". Similar to others (but for a slightly different) I no longer have access to my TextSecure enable Phone (and I'm on Sprint so I don't even have a SIM card!).

In my opinion: TextSecure needs a button at the top bar right next to the Padlock, the Phone, and the Overflow, that allows switching between Data & SMS Transmission Methods.

[Bluebie]

This is totally ridiculous. TextSecure has one job to do - take my message and deliver it to the person I addressed. Users on either end shouldn't have to go about deregistering numbers or thinking about transport layers and switching modes to make that work. There should be zero ambiguity. Here's how I'd like to see it happen:

When TextSecure sends a message to a TextSecure recipient via push, the recipient should non-optionally push back a delivery notification as soon as it receives the message. When a sender doesn't receive a delivery status message back from a receiver within, say, ten seconds, it should pop up a notification saying "Delivery Failed - resend over SMS?" and with one tap, resend it via SMS and also disabling the data transport permanently for that recipient until it receives a delivery status back from them or another message over data. Don't just put these messages in to a bottle and throw them in the ocean. We figured out how to do reliable messaging over the internet a long time ago. When in doubt, emulate TCP.

Deregistering numbers is bad UI and bound to make people upset. Maybe expire people from the push directory if they haven't checked in in a few weeks, but whether or not someone has a public key in the push directory should have no impact on if they can receive texts reliably, no matter what. No excuses. TextSecure's behaviour today is worse than what Apple does with iMessage.

[generalmanager]

I agree that TS should be easy to use AND reliable, but

TextSecure has one job to do - take my message and deliver it to the person I addressed

doesn't really cut it - Whatsapp does that just fine. I'd add "without anybody else being able to know what I wrote". And this adds a lot of complexity.

Your ideas are nice, but nothing new. Delivery receipts have been discussed on github for some time and a few weeks ago there was a very interesting discussion on the mailing list about the technical details of the implementation, which is beeing worked on.
Ten seconds are also a very short timeframe in the world of push notifications - not even talking about websockets.

disabling the data transport permanently for that recipient until it receives a delivery status back from them or another message over data.

From this I guess you aren't familiar with the prepaid mobile phone "contracts" which are widely used in Europe. If you have to pay 8-12 Eurocents per SMS you wouldn't ask for permanent fallbacks like this without asking the user about it.

Maybe expire people from the push directory if they haven't checked in in a few weeks

GCM already does this.

There aren't any excuses beeing made, the dev team is simply not big enough to do everything they want to do right away. I'm sure that your help would be greatly appreciated.

[moxie0]

@Bluebie The problem is that in @begleysm's case, that wouldn't work. He would be receiving unreadable encrypted SMS blobs on his feature phone.

Fundamentally, if you move your SIM card to another device, there's just no way for us to know that you're not running TextSecure anymore without you explicitly telling us. The same is true for any other messenger -- if you uninstall WhatsApp you just won't get WhatsApp messages anymore.

I think we definitely need to add delivery receipts, so that senders know when their messages aren't being delivered. This is easier said than done, though, and not just as simple as "sending a message back."

Additionally, I think we also need to make it easier to unregister by providing a web interface, for instance.

[moxie0]

@begleysm That's already checked in and will be in the next release

[begleysm]

@moxie0 Excellent! Glad to hear it.

[deutrino]

Perhaps the encrypted SMS blobs could contain a short multilingual reference to a URL at the top for former TextSecure recipients who have downgraded to feature phones. The URL could start out as an explanation of the horrible gyrations they or their contacts need to go through to re-establish contact, and as TextSecure evolves, change to something more useful.

[agrajaghh]

I guess thats not possible because of the sms length restriction...

[deutrino]

I've thought a lot more about this issue in the past day and want to record my thoughts. I've added a note regarding @agrajaghh's comment below.

I have three proposals here. One of them solves the exact problem described in this issue (Manual Fallback Proposal).

Both the Manual Fallback Proposal and the SMS URL Proposal are relatively simple to implement, based on my guesswork as a developer who is not familiar with the codebase.

Finally, I present a Degraded Contact Proposal which I believe improves the situational awareness of users in the unusual and transient state where a former TextSecure contact has lost access to TextSecure (possibly for malicious reasons, though likely not). This proposal is best illustrated with some scenarios.

None of these proposals are mutually exclusive.

Problem Statement

We need an easy way for the TextSecure user to say (required to close this issue, IMO) "As a TextSecure user, I have a former TextSecure contact with whom I no longer wish to use TextSecure, so please send only unencrypted SMS to said contact."

We would like an easy way for the non-TextSecure capable recipient of encrypted SMS blobs to say (wishlist/icebox, IMO) "As a recipient of an encrypted TextSecure SMS who does not have TextSecure to decipher it, I would like to understand what I am receiving and possibly take further action."

Finally, we need TextSecure users to be very clearly aware of a "degraded contact" state (TODO/backlog, IMO). A TextSecure contact falling back to unencrypted SMS has major security implications and is likely to be a relatively unusual and transient condition, thus making the user aware of it above and beyond the typical "message insecure" UI cues is warranted.

Manual Fallback Proposal

In all cases, TextSecure MUST provide a way for Alice to fall back manually to unencrypted SMS communication with Bob. Essentially, this amounts to giving Alice the power to mark Bob as a "non-TextSecure contact" from within TextSecure at any time and for any reason she chooses, which would solve the problem described in this particular Github issue immediately.

A "non-TextSecure contact" is a contact which is flagged in TextSecure as unable and unexpected to send/receive encrypted messages, because key exchange has never occurred. Only insecure SMS will be used with "non-TextSecure contacts." I further clarify this term in the Degraded Contact Proposal.

SMS URL Proposal

NOTE: @agrajaghh indicates this may not be practical due to SMS length limitations.

This proposal allows Bob to potentially take action himself if Alice is sending him encrypted SMSes which he is no longer able to read, and allows any random user who may have inherited Bob's SMS number to understand what is happening and potentially to take action.

The encrypted blob SMS SHOULD include a human readable string with a URL at the start: README: http://a.bc/foo This URL contains instructions for users in Bob's situation or users which may have received an encrypted TextSecure message in error, e.g. if Bob changed his SMS number. This URL would be operated by the TS server operator and the content may change over time as TextSecure evolves.

There may be objections to sending any non-ciphertext in a ciphertext payload, e.g. that it would tip off adversaries intercepting the SMSes that TextSecure is being used rather than some other program. I don't believe this objection has merit; it's a security-by-obscurity argument, and IMO sending ciphertext by SMS at all is rather obvious.

Degraded Contact Proposal

Finally, I have a more complex Proposal which I believe is very much worth considering, as there are security implications when a remote TextSecure contact - one who is expected to use encryption - suddenly reverts to not using encryption.

TextSecure SHOULD implement a "degraded contact" flag for contacts which were formerly communicating with encrypted messages and currently are not. This is an unusual situation in which users and TextSecure itself may need or want to behave differently.

To consider why and how we might implement this proposal, let us examine some scenarios.

In all these scenarios, Alice and Bob normally use TextSecure to communicate with encryption. But, Bob loses access to a TextSecure device and can now only send and receive unencrypted SMS. Alice and Bob still need to communicate, however.

Scenario 1. Alice sends a message to Bob first, after Bob loses TextSecure.

1. Alice sends an encrypted message to Bob. After sending the message via data connection fails, TextSecure MAY fall back to SMS and retransmit the encrypted message, either with Alice's intervention or not. (If secure session ends due to SMS fallback on one side when other side can't receive SMS, no way exists to restart session. #1583 is somewhat related.) Alternatively and less good, Alice MUST see no confirmation receipt. Either way, let us suppose Alice, or TextSecure in Alice's stead, either resends the original encrypted message to Bob via SMS or sends a new encrypted message to Bob via SMS.

2. Bob receives an encrypted blob SMS from Alice and sees only the ciphertext on his feature phone.

3. Bob replies to Alice via unencrypted SMS. At this point, Alice's instance of TextSecure, expecting all messages from Bob to be encrypted, knows that something is odd.

   1. TextSecure MUST alert Alice prominently that Bob has sent an unencrypted SMS. TextSecure SHOULD include a warning that it is possible that Eve is attempting to get Alice to cancel encryption, however unlikely that may be, so that Alice is fully informed.

   2. TextSecure SHOULD consider Bob a "degraded contact" until it either receives an encrypted message signed with Bob's key or Alice marks Bob as a "non-Textsecure contact."

      A "degraded contact" is a new flag, meaning "a contact who at one point has used TextSecure but currently doesn't appear to be doing so."

      A "degraded contact" is not the same as "a contact who has never used TextSecure and corresponds by unencrypted SMS" flag - I refer to these as "non-TextSecure contacts."

      These two contact states have very different security implications! If Alice expects encrypted messages from Bob and he stops sending them, a number of things may have happened which Alice would like to know about.

      • Bob has flushed his smartphone down the toilet and reverted to a feature phone
      • Bob (or Eve) has deleted or disabled Bob's TextSecure
      • Eve may be spoofing Bob with an unencrypted SMS, attempting to get Alice to talk to her or to talk in cleartext which can be intercepted

      TextSecure can't distinguish evil Eve situations from innocent Bob situations, so it must rely on Alice to figure out what to do. In order to figure out what to do, Alice must both understand TextSecure's prompts and behavior, and Alice must have, obtain or guess other information which may inform her decision. The only thing the TextSecure developers can improve in the spoofing situation is TextSecure's prompt and behavior UX.

      TextSecure SHOULD mark "degraded contacts" more prominently than "non-TextSecure contacts" in both the contacts and message sending UIs, because the condition is unusual and may have major security implications.

      These all require human intelligence and user intervention, and cannot be automatically distinguished by TextSecure. Since evil Eve situations are a legitimate threat but are likely to be far less common in the wild than innocent Bob situations, we SHOULD allow Alice the choice to intentionally degrade security.

   3. If Alice attempts to send a message to Bob while he is flagged as a "degraded contact," TextSecure MUST confirm with Alice her decision to either to fall back to unencrypted SMS or abort sending her message.

   TextSecure additionally SHOULD give Alice the option to mark Bob as a "non-TextSecure contact" and clear his "degraded contact" flag, thus falling back to unencrypted SMS for all messages.

   If Alice chooses this option, TextSecure SHOULD revert to the normal UI conventions for unencrypted messaging to "non-TextSecure contacts."

   However, TextSecure SHOULD NOT make the option to revert Bob to non-TextSecure user status a single-click "easy" UI operation; Alice needs to be fully aware of what she's doing when prompted.
   4. If TextSecure receives a properly encrypted (i.e. key signature verified) message from Bob after he has been flagged a "degraded contact," TextSecure MUST alert Alice prominently that Bob has sent her an encrypted message, i.e. Alice MUST be notified of Bob's state change away from "degraded contact." Why? This is something that again requires human intelligence.

   What if Bob's phone were stolen by Eve, Bob reverted to a feature phone, Bob sent an unencrypted SMS to Alice, and then Eve gained access to Bob's TextSecure instance and sent Alice a message posing as Bob?

    Alice should be aware of the state change away from "degraded contact" because _this awareness is an opportunity for Alice to learn that Eve is controlling Bob's TextSecure key._
   

   5. To make the above protection stronger, I suggest - subject to more thorough threat analysis - that upon receiving any encrypted message from Bob while Bob is flagged as a "degraded contact," Alice's TextSecure MAY automatically send an unencrypted SMS to Bob (thus readable by any feature phone receiving the message) notifying Bob that Alice's TextSecure has noted the state change, e.g.

      Automatic TextSecure reply: received encrypted message via [transport mechanism] from you ([Bob's fingerprint]) or someone purporting to be you. README: http://a.bc/bar

      This may seem pointless until you consider that Eve may be sending messages by data while Bob is sending and receiving messages by SMS. Thus, Bob would receive a notification of Alice's state change which was in fact induced by Eve. Again, it's an opportunity for the users to become aware that something is wrong.

   6. Upon receiving any encrypted message from Bob while Bob is flagged as a "degraded contact," when Alice is notified of the state change, TextSecure SHOULD give Alice an option to deny the "un-degrade," i.e. to deny the de-flagging of Bob as a "degraded contact" and the return to encrypted communication. If Alice selects to continue unencrypted SMS-only communication, it could be accomplished by allowing Alice to revert Bob to the status of a "non-TextSecure contact," or by setting an additional flag while keeping Bob as a "degraded contact."

      • Alice may wish to do this because she knows Bob would prefer to receive unencrypted SMS (e.g. if Bob has a wifi-only TextSecure device at home but a feature phone which he uses constantly for mobile use; or Bob is traveling internationally for several months with a feature phone and Bob's girlfriend Carol sends Alice a single encrypted message from Bob's TextSecure instance)
      • Alice may wish to do because Alice suspects Eve is spoofing Bob on a data connection, etc.

   7. In all cases, when sending or receiving cleartext SMS messages, TextSecure already displays a set of UI cues to indicate that the messages are unencrypted. Further, when sending unencrypted messages to a "degraded contact," TextSecure SHOULD display an enhanced set of UI cues emphasizing the unusual nature of the situation.

      TextSecure contacts will rarely fall back to unencrypted SMS, and it is a condition that we expect to be both unusual and transient: either Bob replaces his phone after dropping it in the toilet, or Alice manually reverts Bob to a "non-TextSecure contact." In these cases, either Alice has signaled her understanding that her communication with Bob is unencrypted, or Bob has "un-degraded" to encrypted communication with Alice's understanding and approval.

      However, until such user interventions are performed, TextSecure SHOULD make Alice aware both that her communications with Bob are insecure and that this is an unusual situation - hence my calling for an enhanced set of UI cues for unencrypted messages exchanged with "degraded contacts."

Scenario 2. Bob sends a message to Alice first, after Bob loses TextSecure.

1. Bob sends Alice a message via unencrypted SMS. At this point, Alice's instance of TextSecure, having expected all messages from Bob to be encrypted, knows that something is odd.
2. At this point, everything proceeds as above.

Conclusion

The Manual Fallback Proposal would close this issue and I believe it would be relatively easy to implement.

The SMS URL Proposal could allow Bob to take action without intervention by Alice in the situation where he has lost access to his TextSecure instance, or could simply provide instructions, or anything that the TS server operator wants to put at the URL.

I'm sure I have not covered all the bases in the Degraded Contact Proposal. It would also be the most difficult proposal to implement. However, I believe it would improve situational awareness during an unusual mode of operation, keep users better informed of the security (or lack thereof) of their communications, and thus allow users to make more intelligent decisions.

I remember very well the bad old days of OTR prompts and don't wish to go too far down a similar road here. OTR had entirely too many prompts relating to encryption state, most of which were useless from the user's point of view and which non-technical users would not understand the purpose of.

However, I believe these UI choices are a fairly decent compromise:

• prompting Alice about Bob's state changes (both into and out of "degraded contact" status) in the Degraded Contact Proposal
• providing Alice with a dialog box, hopefully including plainly-written help, to make choices when Bob's contact state switches between "TextSecure contact" and "degraded contact"

The tradeoff is between the irritating outcome of over-prompting the user versus the really bad outcome of a silent degradation in security - or a non-silent degradation which the user fails to notice. The latter is why I include suggestions for an enhanced UI distinguishment of "degraded contacts." If Alice fails to notice "degraded contact" status and corresponds with Eve because of this, it is the same as a silent degradation from Alice and Bob's perspective.

[deutrino]

Could close #1497 as well.

[deutrino]

For the "enhanced UI distinguishment" of unencrypted messages with degraded contacts, here's what I proposed in #945:

• [In normal cases,] display of historical messages' security should be enhanced beyond just the lock icons. If background is light and icons/text are dark, I would like to see a thin dark stroke of the message bubble for secure messages, and a thin greyed/muted, diagonal-dashed "warning" type stroke for insecure messages. The muting is to avoid making the user's eyes bleed when talking to their many insecure SMS contacts, but to train them for a less muted use of the visual style in potential security compromise situations, such as...
• [In the] display of insecure messages received under unexpected fallback from (apparently former) TextSecure contacts (e.g. the Degraded Contact Proposal in Unable to send non-encrypted SMS to previous TextSecure user #845) [messages] should have a thick warning-colored/non-muted, diagonal-dashed "warning" type stroke for insecure messages.

[nebulon42]

@gordon-morehouse Yes, a way to remove a user from TextSecure contacts is IMO really needed.

[edouardmenayde]

@nebulon42 +1

[s0]

The latest version has a way in which to switch to SMS mode for a conversation (although it is temporary). You need to hold down the send button, and a selection comes up.

This UI is not yet perfect and is likely to be improved soon. Additionally, would be nice to have the change permanent.

[colans]

It looks like there are three options, "Send TextSecure message", "Send secure SMS" and "Send insecure SMS". What does the middle one, "Send secure SMS", do? Is it the same as the first TextSecure one?

[jrgifford]

So with my understanding of the way TextSecure works, "Send TextSecure message” sends it via the internet and the TextSecure service, "Send secure SMS” uses the TextSecure keys on file, but uses SMS as the transport mechanism, and “Send insecure SMS” sends a plaintext SMS.=

[s0]

Correct.

[edouardmenayde]

The send button would need a little sth to know there's option and as @samlanning said it needs to remember the last choice, It can be PITA if you'r texting a lot.

[deutrino]

I opened a feature request for what was discussed in the last few comments (lack of "stickiness" in message transport method when selecting from the Send button) - please see #2285.

Incidentally, I believe having such "stickiness" might close most or all of this issue.

[wrought]

Having just gone through this issue with a friend, it seems to me that the behavior of the Lock / Unlock icon (button) is not intuitive.

When I select the closed Lock icon, I should be able to clearly end the secure session, even if I am registered to use the Push feature and currently using the Push transport mode. To me, "clearly ending the secure session" would mean that sending new messages should default to the insecure SMS transport mode, I should have an option to re-initiate a secure session, and the "Locked" lock icon should change to the "Unlocked" lock icon.

If you think that the changes ya'll have specified so far as a result of this thread deliver the experience I've described above (or an equivalent), then I am satisfied. Otherwise, please let me know.

[rhodey]

with the dropping of encrypted SMS and MMS and some bug fixes related to transport selection on the send button this should no longer be an issue, closing.

[fersingb]

@rhodey Maybe I missed something but I think it's still an issue.

When I try to send a SMS to a friend who used to have TextSecure but uninstalled it, the default behavior in TextSecure is still set to TextSecure. I've to long press on the arrow and select SMS.

Also, my friend is still appearing in the TextSecure users list.

Or have some bug fixes you talked about not been released yet?

[agrajaghh]

your friend can unregister here: http://whispersystems.org/textsecure/unregister

[fersingb]

That's the info I was missing, thanks !

[mgraupner]

@rhodey I don't understand why this is closed. Until reading this thread it was impossible for me to send a normal SMS to somebody who uninstalled but did not unregister TextSecure first. I'm an experienced user and Android developer but holding down the send button which in no way indicates that there is another option to send a message is not a good user interface design decision in my opinion.

Why is it not possible to select on a per user base if I want to use the encrypted TextSecure Channel or SMS permanently? I was under the impression that holding down the big secure Lock and selecting 'End secure conversation' would end the secure conversation and switch back to SMS. But I guess it just means that my messages are not being encrypted anymore but still sent via the TextSecure channel but I could not figure this feature out too...
After giving my contact the link you posted still does not make them available via SMS. The 'Check contact' tells me that my contact has no key anymore but the UI stays in TextSecure Channel mode and I can only send encrypted messages if I don't hold down the send button.

Being able to select by myself what channel to use would be the best user experience. I hope this will find it's way into future versions of your superb messanger App! Keep up the good work.

[xavihernandez]

@mgraupner if you long tap on send you can choose between non encrypted SMS and encrypted TextSecure message.
What I regret tho is that TextSecure does not store preference. So when I choose to talk with unencrypted SMS to someone, I think it should be stored. Then I don't need to long tap again to select unencrypted SMS