No option to force-ignore someone's textsecure account

[rigaac]

From the "Manage Identity Keys" screen there is no way to remove a key

[hunleyd]

+1

[daryltucker]

This is frustrating, especially now that I cannot toggle the contact's preferred contact method (cleartext or TextSecure ciphertext) in the current version of TextSecure.

(ie: I convince a friend to install TextSecure. We exchange keys. They stop using TextSecure because of lack of Emoji or QuickReply. Now, I cannot disable encryption for this user by removing their key nor by changing the method as described above)

[L3st3r]

@daryltucker: You can just end the secure session by clicking on the lock symbol in the chat window. After that TextSecure should stop sending encrypted texts

[daryltucker]

@L3st3r This was available to me when I started using TextSecure, but is no longer available to me.

I will verify this problem and report it as it's own bug shortly. Thanks.

[frewsxcv]

@L3st3r Did you ever find a solutions for this? One of my friends was using an Android phone with TextSecure and his key was put into my phone. He recently switched to an iPhone but my phone still attempts to contact him with his key. Attempting to end the session does nothing. There's still a lock next to a blue arrow.

[generalmanager]

@frewsxcv If he still has the old phone, he just needs to put his sim card in there and turn push messages off in the settings. If TS isn't installed any more he'll have to install TextSecure and reregister.

If he doesn't have his old phone installing TextSecure on another Android phone, registering and unregistering from push will work.

[frewsxcv]

That is definitely not an appropriate workflow. Is there an open Issue fixing this?

[KayuHD]

I completely agree with him.

[moxie0]

@frewsxcv What would be an appropriate workflow?

[generalmanager]

@frewsxcv Yes: #845.
Locally removing/blocking the key is not a good solution, because every TS contact of somebody who uninstalled without unregistering would have to do so.
Thus there would need to be a way to unregister trough other means. GCM apparrently unregisters you if you haven't been reachable for some time (default waiting time until a message is forgotten is 4 weeks, so that's the minimum wait time).

Somebody came up with a ruby script that unregisters the user from whisper push, but using it for the TextSecure (whispersystems) server should only require changing some parameters:
https://github.com/daveio/whisperpush-unregister

ctso from cyanogenmod is also working on a web based unregister utility which would be very easy to adapt for the whispersystems server.

When email addresses are allowed as identifiers this should become even easier.

[tinloaf]

The problem I see is that with a web based unregister utility, trolls will have a really convenient way of making the TS server send a lot of SMS messages...

[frewsxcv]

Does TextSecure keep track of when messages are received on the receivers device?

[tinloaf]

Yes, but how does that help?

[frewsxcv]

Are there plans to show if a message was received in the UI on the senders device? With the current app, if the receiver stops using TextSecure, the sender has no indication that their messages aren't reaching the receiver. It'd be helpful to know that messages aren't reaching the sender and allow the sender to take action.

[generalmanager]

@frewsxcv #957

[frewsxcv]

My main issue is the lock button at the top doesn't seem to end the secure connection with the other user. This is probably a bug? As of now, I have no way of messaging my ex-TS-user friend through TS

[generalmanager]

That's not what the "end secure session" button is for in the first place. It's only needed for some cases where the sessions got messed up and people get "bad encrypted message" errors. And if somebody with SMS starts to write cleartext SMS.

And this option will get scrapped in the future anyways.

I told you several ways to fix this and also linked a thread with more information. The easiest way to contact him once or twice via sms (to ask him to unregister properly) is to turn off your wifi and mobile data while sending the message.

[frewsxcv]

@generalmanager I'm not worried about my particular case, I'm worried for the other end users who will run across this problem. If this is ever going to be an app targeted at everyday end users, this issue needs to be addressed. Asking end users to go through such a manual process cannot result in anything good

[ThomasWaldmann]

when trying out textsecure with a friend (first attempt some weeks ago, 2nd attempt yesterday), we ran into a deadend situation somehow:

because I sold my old phone (had cyanogenmod and whisperpush) and switched to textsecure on the new phone (but with same phone number, which also caused registration issues, but that's a different topic) I guess he still had my old key on his phone.

we could not communicate using textsecure, so we thought "ok, let's rescan the keys and start from scratch", but there was no way to do so. we ended up trying to completely remove textsecure and all related data from the phone - which is for sure no option for serious use of textsecure.

In general my impression is that textsecure could be a really cool app for everybody and improve secure communications a lot, IF only the UI / UX was better. Currently even highly motivated geek users run into too many issues, so one better doesn't recommend it to a "normal" user yet.

[mcginty]

@ThomasWaldmann re-registering for push and having your friend refresh their directory should solve the problem unless I'm not understanding something

[alexh3791]

I'd like to see an option to select and remove contact keys in the app. I see no reason to keep keys around for users that don't have the app anymore.

[daryltucker]

I've noticed that you can click the lock box on your conversation view, and then click "End Secure Session". Give it a second, and then you can click the lock box again, and "Initiate Secure Session" (or something similar), which will re-request an exchange.

This will remove the old key and replace it with the new key.

[alexh3791]

@daryltucker Problem is, that flow doesn't get rid of the old key without establishing a new one. That flow doesn't work well when a user leaves TextSecure.

[daryltucker]

Thank you for clarifying my misunderstanding. I assumed that, when the session was terminated, the key was removed vs being replaced upon receipt of a new key.

Maybe we should suggest this be the default behavior until true 'Key Management' functionality can be built.

[alexh3791]

@daryltucker No problem. I think your idea on default behavior is a good interim solution.

[seppi91]

+1

[black-puppydog]

After looking at some similar (mostly locked/closed) issues this one seems to be the best I can comment on as a non-collaborator.

I have had this happen to with friends a couple of times.
I tell them about TS, they try it, maybe even like it, then someone in a "clique" stops using it and suddenly everyone uninstalls.
The reason is quite simply that always having to remember to long-press is annoying enough for them to uninstall it entirely.
And no, there is absolutely no way that I will make them lift a single finger on their part to "properly unregister".

I think that is the problem here: Once someone decides to not use TS any longer, that's it. We cannot reasonably expect them to re-register and/or go through a complete unregister after they decided they don't care about the app.
And to be quite honest: I love TS for many reasons, even compiled my own from a feature branch I wanted badly, but even I find myself wondering if it is really worth the trouble for exactly this reason.
It is like an inverse network effect. :/

[Diapolo]

I also have problems with contacts who uninstalled Signal but still show up in my list as Signal users. There is no way to force them to be NO Signal users, so I always have to manually switch to insecure SMS... this is a big UX mess! :-/

[FeuRenard]

This issue would be solved by implementing #2285, right?
So this is some kind of duplicate.

[2-4601]

Lot's of old TextSecure specific discussion here and two-issues-in-one syndrome. Closing in favour of #2285 and #4678.