Explain how to trigger a key exchange #293
Comments
yes, but keys are exchanged as well for existing contacts, so a deletion would not make things better.
the person who cannot read a message eg. because of a new device should send a message "hey i cannot read your message, please send again" - the answer should be readable and the keys will be exchanged. |
Is the person who cannot read a message getting an error that explains this? Like, "If you already have a prior deltachat installation you should transfer your keys from the other installation using the export/import or transfer message function. (If you send messages to contacts without having imported the preexisting key (using the new key of this installation), the encrypted answers of your contacts won't be readable on your other, older installations (which have the preexisting key). |
currently, there are no really clear advices, this could be improved. |
|
Is there a current error message in the code to improve? |
|
not yet, but i've just modified the code to have such an error message. the following text is currently shown in the message bubble if a message cannot be decrypted. Any suggestions and improvements welcome before we give this to the translators (@comradekingu :) |
|
Is there another regular cause for this than a re-installation? It could be more sensible to advice the local user towards key transfer instead of asking (all) contacts (and them get accustomed) to re-sending messages to and with a new key. |
|
I modified the text to also be shown whenever DC finds non-decryptable messages on the server (after installation), and not only when viewing a new message. |
|
The setup wizard could also emphasize to import a preexisting setup, if one exists. But I can't find it's text with the search function in the code. |
|
Shorter, without any explanation and problem warning: (could not find the commit) |
might be that the sender used a key from a keyserver - either an old key or an key that was uploaded by another user. |
|
Ok, new try: |
|
As the text will be written directly into the mail body (the "bubble") i would prefer Next iteration :) |
Makes sense then. |
r10s
changed the title
|
The term What do you think? EDIT: I changed the title, it took me ten minutes to find this issue by the old title :) |
|
Yea, some basic explanation is needed. Don't you think it would make sense to list the case first
|
Not sure. I think a typical DC user has never used PGP before and uses only one device. These users may more likely be confronted with users that encrypt to an unknown key. I like your explanations, however, maybe we can make it a little shorter: I dropped the hint regarding the number of messages - typically, when the users is confronted with the situation, there is only one message - more errors may follow, but the user cannot know. I think we get closer :) |
|
Yea, right the user may only see one at a time. Kept it shorter and with should vs may, hopefully clearing up the options, and removed typos.
Changed this to keeping the old instead of sending from the new: |
OTOH it may also be relevant when typical users buy or switch to a new device. |
Have not discussed so much about a single message :) however, i think it is worth the effort :) |
|
"The sender may mistakenly didn't encrypt for your setup" - not sure about the grammar btw. |
|
Yes, it's worth here, because good advice should make things "easy in the end", EDIT: and avoid worse problems down the road, including puzzled and likely negative users. I used "should vs. may", to avoid users stumbling into the problems of using two keys on different devices. To keep the "advice flow" maybe the second point could start with "Otherwise, the sender may mistakenly not have encrypted for your setup". (I think it's "have".) |
|
Great, we're getting really close.
|
|
OTOH, your |
|
I fear it is not so obvious, what is meant by "the setup". |
|
@Ampli-fier This is Autocrypt-slang :) we do not want to speak about keys as this is even more abstract for unaware people. And Autocrypt-clients use eg. the term "Setup message", "Transfer Setup" and so on. |
Ampli-fier is right, the use of setup in this variant is confusing. Setup should probably only refer to the private key part? Edit: Oops, other version has the same problem. "To share your current setup" => "To use your current setup"? |
|
Right.
|
Yes, that's why this message is rather crucial. It can be the first contact with this feature, and the single chance to shine and explain. |
|
@testbird |
|
Sure, the user does not have to know every detail about the server, pgp, db setup etc., but the first thing the app is used for, if I am not mistaken, seems to be: The user configures the email setup. Thus "setup" seems to be a useful, basic word with a common meaning, nothing special. Of course the configuration in DC could make sure to also actually use the word "setup", if it is not already used, to make it better recognizable when referring to it in the error message advise. |
|
What about: May that improve it in your sense, Ampli-fier? Edit: made the adaptions in the last version above |
worst case: if the receiver decides to import his new setup after sending a message to the contact (because he did not read the full message ...), this message will pop up again and he can "repair" the keys by sending a key again.
The other device may be a non-delta-client, so instruction will probably get too long, I think @Ampli-fier suggestion (#293 (comment)) is still fine. |
|
this is what the message looks like in delta then; btw. maybe a direct link is not a good idea as this may make it easier for phishers to trick users that have learned to click on links in messages that cannot be encrypted ... maybe we should just write "see 'Help' for details". btw. it's not necessarily a re-installation of Delta Chat causing the problem in the second point - it may also be Thunderbird, K-9 or others. so maybe "In case you re-installed Delta Chat or another E-Mail-Program on this or another device ..."
|
|
update: i also removed the hint to the help - the help should be opened on the newly installed device / E-Mail-Prorgram, so I think the user should search for help there. Added a hint to the Autocrypt Setup Message instead, more experienced users will know what other pgp-alternatives they have, i think.
|
|
Encrypted Message - [This message cannot be decrypted.
Should users get accustomed to re-send messages to new keys upon requests?
So what is the average user supposed to do after reading this? The user notices this was not a meaningful message, rather a reference blob. Go read the doc? Learn what applies and decide between options? I think this message doesn't yet help the user as much as it should.
Right, it might be some other autocrypt install. The |
A specific risk of the seemingly easy "just reply" advice would be to lead to a very frustrating ping-pong effect, or not? |
|
What could still be improved seems to be the consistency of managing the (Delta Chat) autocrypt setup.
|
well, it's the request from a known friend they've contacted before, i think this could be a working "social" protocol. if there's any doubt they can ask or do an out-of-band verification.
no. the sender gets the new key when receiving "please send the message again" and is able to encrypt correctly then.
Yes, on install, we can be more specific, but this is another issue :)
Yes, "Send Autocrypt Setup Message" is far better; K-9 will also use this term, see thunderbird/thunderbird-android#3342 btw. what does K-9 or Enigmail display in these cases? |
That's only one half of what happens, if I understand this correctly: Suppose, user A has made new install a2 and receives a message from an old friend F (designated for a1). Instead of importing the a1 setup, A replies to the message from a2 and asks to re-send the message. F gets the reply and re-sends the message to a2. Now, A can read the message at its second installation a2. However, the message is now not readable at the first installation a1, and following the "just reply" advice on a1 will just lead to a frustrating ping-pong loop, switching back and forth between a1 and a2. |
|
that's correct if the user has made a second installation which requires an Autocrypt Setup Message that is handled in advice 2. if there is no new installation (i think this is the more frequent case) and the message is shown, the advice to "just reply" would normally fix the problem. i think this is fine. maybe we can just give the current text a try, and see what will happen. |
Ok, then the message should definitely handle that case first, just as discovered before...
It's an easy condition to exclude for a user anyway. As the ping-pong consequence warrants it, using "should" or even "need" in the message even simplifies it further.
I made adapted versions for both drafts: |
|
The first one is too hard to read For the second, there's a repetition, but it's easier to read :
|
|
|
Thanks Ji-eF, I removed the repetition as you suggested, but kept the ", eg." to hint that there are other ways to export and import the key, ok? Or, adapting with your draft: The drawback (ping-pong) is even worse, but maybe it doesn't need to be mentioned with clear "you should/only otherwise" wording. |
I have qualms about that. See what can happen, if users follow that advice: Suppose again, the user A is at a new installation (a2), and reads:
Then simply tries this. But afterwards can't read further messages on the old installation (a1). So this time decides to follow the second advice:
Accordingly, user A sends a setup message from a2, which leads to overwriting the old a1 setup, and the key is lost, at least not send-able in setup messages anymore. :-( I'd say the adapted Ji-eF inspired version (one post above) should be safer. |
|
I'll just provide a pull request to change the order of the advice, and saying "if used another ...should import, otherwise, ..." |
|
maybe this makes sense, but i personally would prefer the wording from @Ampli-fier , so what about: |
|
If you read this or that above, doesn't it recommend to import from the re-installed (new) deltachat or email? I can't be sure? What about a new device/installation? And, it could be hard to find the "send autocrypt message" in any other email program. That's why the text in the pull request differs in the first point, and tries to associate things to the same words that are used in the menus and options (autocrypt, setup, verify), to enable the users to find their way with it. Generally, I don't know if basic liking is a first rank criteria for error and help texts. Nevertheless, maybe I would like a little addy to the main error and "might have to" better than the "should": |
i do not think that "you may want to" is more a recommendation than "you might still have to". it is true optional in my understanding.
this is true, but we cannot help on a little error message on this point - esp. as the "otherwise" part is the more likely one imho. however, maybe it already gets too technical, also "share" may be misunderstood as being to close to a setup messages, see #293 (comment) btw. asking the sender to "verify" - what would es expect the sender to do? all in all, I think we cannot solve this 100% here, maybe this needs ui testing and more feedback. i also think, the current text is not that bad and has no larger issues. so, for now, i would just keep it and go forward to other problems :) |
|
Yes, sure, nevermind. It's just an uncomfy experience, that going forward with other problems, leaving small an reachable fixes aside "for now", tends to create more problems later (which are harder to re-approach (and take longer) later when things have evolved and the issue faded away).
Yes it's optional, but IMHO it would make sense to stress (even if just so lightly) that one should make sure to import the old setup, if not already done so (too avoid unecessary key changes (and thus further views of that error message, when old contacts write).
I don't know the new features, thought you just implemented that, and that using a new setup makes users "unverified" at their contacts (and confuses contacts).
What about erroneous advising to send setup message from the newer install (tablet -> phone, or new phone -> old phone)? #293 (comment) If some nerd friend couln't manually set up an autocrypt key, thats not much of an issue, but unnecessary announcing a new setup (fork) still seems to be one to me?
Yes, good point, maybe "announce"? |
|
|
@comradekingu hi :)
|
That recommendation may, unfortunately, just go a little too far. The word key is well known and generally understood -- only the "public key" concept has no analog --, it's easily understood that a key is needed to decrypt, and it should not be given away. |
|
|
i think, we can close this issue for now - if ui testing brings up new insights, we can think it over. |
0.16
Expected behavior
When a contact deletes and reinstalls Delta chat, my app still has his old, now invalid key, so it doesn't decrypt his messages, which show as unencryptable messages in regular mail client.
Deleting the contact would probably lead to a new key exchange. But unfortunately, deleting a contact which is "in use" is disallowed.
How to trigger a new key exchange?
Please repair!
The text was updated successfully, but these errors were encountered: