androidclient
androidclient copied to clipboard
kontalk
Make invitations more user friendly
Right now a user must manually accept a fingerprint for new users. I think a better way to handle this would be to auto accept new invitations and provide a warning "So and so added with fingerprint blah click here to view the fingerprint". Basically do a little more like what signal does. For new users who have no idea of crypto it is sorta hard to get them on kontalk with the manual process now.
I think auto accept new invitations is not really a option for a secure messenger.
If you blindly trust the key, you can blindly click "accept". It's not a big thing 😉
What you want sounds like the "Backdoor" in WhatsApp. Isn't it?
I think a warning is not blindly accepting. just a more convenient way of adding new user/friends. 99% of time a new friends request is going to be the person you intend to talk to and you are more worried about that fingerprint changing later on, in case of a mitm. Signal also a secure messaging app that has this kind of functionality where it does not require one to click accept before chatting. another alternative is to have a orange/broken lock icon/some sign to show you have not validated the users fingerprint yet but are still able to speak to them. it is confusing for new users to have some one in their contacts and be written to from said persons and have to accept the invitation.
all i am saying there should be a better way. signal does it why can't we? ;)
On February 3, 2017 1:41:30 PM HST, webratte [email protected] wrote:
I think auto accept new invitations is not really a option for a secure messenger.
If you blindly trust the key, you can blindly click "accept". It's not a big thing 😉
What you want sounds like the "Backdoor" in WhatsApp. Isn't it?
-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/kontalk/androidclient/issues/947#issuecomment-277393187
I only can speek for me. Maybe @daniele-athome or other people have other preferences.
I like the way that I have to accept the invitation first. IMHO it's also a way to keep spammer outside because the can first write to me until I have accepted the invitation 😉
Sure, I can block spammer. But better way is to never let they in. Espasially if Kontalk will sommetime implement Profile pictures like in WhatsApp.
But don't forget. It's only my opinion.
BTW. Just seen in the current Beta. There is user preference: "accept invitations automatically" I have not tested it yet. But it's off by default.
Accept invitations automatically was implemented already before the beta.
@webratte, you also forgot something - If you didn't accept someone's key but the "spammer" did he can still write to you but you can't write back.
Diese Nachricht wurde von meinem Android-Gerät mit K-9/p≡p gesendet.
Oh, my fault, I accidentely thought of invitations and keys as the same. Maybe because this function sonehow does too.
Diese Nachricht wurde von meinem Android-Gerät mit K-9/p≡p gesendet.
no worries. I think you proved my long that this could be done nicer and less confusing.
On February 4, 2017 9:53:09 AM HST, OfficialMITX [email protected] wrote:
Oh, my fault, I accidentely thought of invitations and keys as the same. Maybe because this function sonehow does too.
Diese Nachricht wurde von meinem Android-Gerät mit K-9/p≡p gesendet.
-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/kontalk/androidclient/issues/947#issuecomment-277471495
I've always been tempted by autoaccepting the first key (and chat invitation) presented by a new contact for the sake of ease of use, but part of keeping Kontalk secure is also accounting for such things. I believe we shouldn't go for disabling security-related features, instead we should improve them to make them more easy to use. For example, a "security level" preference used for different level of power users (e.g. high for paranoid mode, medium for security-aware users, low for everyone else, but still keeping enough checks).
P.S. the "accept invitations automatically" switch is used for automatically accepting chat invitations, not keys. Key approval is always needed for unknown or changed keys.
I agree. I suggested a few different ways that we don't ignore the security. What you have suggested works as well. Let the user choose on account creation what mode they want and allow them to change at anytime later would be great.
On February 5, 2017 9:18:45 AM HST, Daniele Ricci [email protected] wrote:
I've always been tempted by autoaccepting the first key (and chat invitation) presented by a new contact for the sake of ease of use, but part of keeping Kontalk secure is also accounting for such things. I believe we shouldn't go for disabling security-related features, instead we should improve them to make them more easy to use. For example, a "security level" preference used for different level of power users (e.g. high for paranoid mode, medium for security-aware users, low for everyone else, but still keeping enough checks).
P.S. the "accept invitations automatically" switch is used for automatically accepting chat invitations, not keys. Key approval is always needed for unknown or changed keys.
-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/kontalk/androidclient/issues/947#issuecomment-277541857
I'm currently in the process of reviewing the invitation process. I'll list some recent changes (not released yet):
- messaging will always be possible unless blocked
- the latest available key will be used to encrypt outgoing messages
- the latest verified (or ignored) key will be used to verify incoming messages
- chat invitation will be used only for presence subscription (i.e. ability to see last seen)
Key approvals will be following the Blind Trust Before Verification method. I consider it to be an "automated way" of implementing the security level setting, in a way that take into consideration users awareness about security. Changes to the code are still underway though.