Closed M4v3r1cK87 closed 9 years ago
yes, that's the current intended behaviour, have to think about this...
I have still no clue what to do here. Ok, the user should see a least a warning when the key changes, but the option to refuse the new key seems useless...
@abika if you click the reject button (actually "block") it unsubscribes from the user and blocks it. Why do you think it's useless?
oh ok, sorry. I thought only the new key is just ignored. But that behaviour clearly makes sense.
Will the Android client recognize it if the Destop client does the same?
It should: the blacklist is per-user.
quick question here: why unsubscribing? When the contact is blocked no presence stanzas are received for this contact anymore, so isn't blocking enough?
I thought removing it from the roster entirely would be more "complete" (you are indeed blocking a person and you don't want to see him/her again :-)
okay, but I think only blocking is more appropriate here: Most of the time a key change occurs the reason is legitimate, and if the user is really unsure about it blocking is enough to prevent insecure communication but makes it easier to reestablish communication maybe after the key was verified using some other channel. (Key change-> I'm unsure & block -> call the contact: ok, not the CIA -> unblock)
Thus the Desktop client will only block
You're right. I will align the Android app.
It seems the Desktop client auto-accepting key changes.
I write a message to my friend that show in the contacts list, i sent a message to you and you sent message to me, and so far so good... But when I enter in the chat from the android app the client show me the request to chat (saying that the encryption key was wrong).
From the desktop app:
From the android app: