Conceptually wrong / misleading labeling of contacts

x368 commented 8 years ago

Labels in the contact list must be chosen/written by the list owner, not by the contacts themselves. The problem formally expressed: mixing incompatible name spaces. This leads to confusion of the users, perpetuating of bad practices and eventually loss of security.

Not a problem to also show in the list the meta-information a contact likes to supply - like her/his "what I like to be called" aka nick and "what I am doing right now" but the entry in the list represents an identity and as such must either/both show the real Tox ID (the public key of the other party) and/or a label the person adding the contact chooses. A proper place for choosing the label would be an additional field in the "friendship request" dialogue:

What I am going to to call this new friend: Mom The contact ID: a636f768c739a5c34d35638041e5440e1a1b88d61.... The text to introduce yourself: Hi mom, Jane here, thoroughly check the sender IDs !!

Possibly resulting in an entry like (if the mother chose the nick for the sake of her coworkers)

Mom (Alice_Andersson_at_3rd_floor_building_11) (having coffee break)

The current (as of 2015-08-29) situation makes the friend list inconsistent and misleading/dangerous as the user does not have any power over the labels.

It also utterly confuses the users about the semantics of what they believe are their "nicks". The "nicks" are the same kind of volatile information as their "mood" or "currently doing", nothing else and nothing in common with a verifiable identity.

Such inconsistent information can not be relied upon to find a certain contact in the list and it should not look/pretend to be suitable. The users are already mislead by the practices and UIs of the centralized chat services like Skype who are actually motivated to keep the users naive. Let's do better.

(Names are not identities and names belong also to many different name spaces, which does not seem to be well understood in the discussions of using names for finding new Tox contacts. The current uTox UI contributes unfortunately to these misunderstandings.)

Other than the above I appreciate the UI which looks both complete (even if some features are not there yet), concise, usable and comfortable. Thanks!

Jeeppler commented 8 years ago

+1

tsudoko commented 8 years ago

Couldn't that problem be solved with setting aliases?

x368 commented 8 years ago

@tsudoko I am not entirely sure what you mean by aliases but hopefully exactly what I suggest: explicit labeling of the Tox identities in the contact list, by the person whom the list belongs to.

The term "aliases" can be misleading as it has the nuance of "being optional" while I insist that the explicit labeling must be mandatory, to reflect the fact that this is the only meaningful and reliable way of naming.

"Alias" in this context would mean a possibility to have multiple such labels on a single entry but would this make much sense? Instead of having an alias "Mom" to "Dad's_wife" (in contrast to "My_biological_mom" being another entry) you could simply label it "Mom_aka_Dad's_wife" which hopefully would be shown both while searching in the list for "mom" and for "dad's".

It is also nice to avoid introducing an extra concept ("aliases") and the corresponding term. The less to define and explain for the user the easier and safer it is.

tsudoko commented 8 years ago

It's already implemented, though, just doesn't have an UI item in the stable version. An alias can be set by typing /alias newname in the chat window. It currently replaces the name set by the contact. I think mandatory name-setting for every contact would be too much pain for most people.

x368 commented 8 years ago

@tsudoko This is a clear example of an interface misleading the users. A fundamentally vital operation is hidden, declared "optional" and named as it would only have some decoration functionality.

This causes a huge cost in the long run as the users remain confused about the semantics of their contacts/identities/accounts/nicks and so on.

As of "pain", setting the labels is hardly a pain, for a lazy person it is one keypress per new contact entry. Like a couple of dozen keypresses per lifetime :)

The crucial point is to show/tell the user: this is the name you give to this identity who you are going to talk to, the rest is not a name. If the remote metainfo changes, the identity does not change, nor the name of the identity. Again, a name only has sense in the context of a certain name space, the contact list name space (local) is incompatible with whatever any contact may put into their "metainformation". The only reasonable other reference would be the public key of the contact!

If you really feel filling an extra field is a burden, assign automatically generated local names to new contacts (like "1", "2", "3" or whatever). But the users' own choices of labels would feel much nicer for themselves, wouldn't they?

In any case never allow remote information write over the local labels. The chat messages e.g. must be tagged with locally given names not the remotely set nicks. Otherwise you expose the users to a can of worms. This is not about reducing usability at all.

GrayHatter commented 8 years ago

thinking of and setting a name is likely a 4 second task, that either the owner of the name can do once. Or each of his 50 friends can do it for themselves, 5 seconds or 250s... I'll take the 5 seconds rather than forcing a feature that you think is mandatory...

Also @tsudoko is correct, this was fixed by him and that patch is currently in the develop branch.

uTox will never force the user to create a name/alias/ident for their friends/contacts. But does offer the ability for the user to do so. And I have yet to see a succinct or convincing argument for it to do so.

x368 commented 8 years ago

@GrayHatter The first word in your comment is the crucial one. It is thinking which the user really really (did I emphasize enough? :) should do before sending or accepting a contact request.

Regrettably you seem to ignore the difference between accepting whatever the other party tells you about her/himself and having your own idea about who you are talking to.

Not all "friends" in the contact list are equally friendly or trustable. A "SomeNiceGuy" can the next day pretend to be "Mom".

Tox goes to great lengths to make communication with a certain peer secure but then uTox by default accepts unverified handles (list entry names) to the peer identities. This is not anything like a secure design.

In other words you try to spare 4 minutes in the user lifetime for the price of perpetuating her confusion and insecurity.

A program which is meant for secure communication and announced as such may not offer insecure defaults, simply to remain honest.

The deepest harm is the confusion - confusing the users ultimately reduces their security. In the long run the inconsistent handling of identities hardly helps the user satisfaction and the acceptance of uTox either.

For the moment what I see is a lookalike imitation of Skype interfaces but with quite different semantics of the involved information pieces. This suggests that not only the users but even the developers do not fully understand/realize the semantics. I have a great respect for your and others' programming skills and did not yet notice any apparent design flaw in toxcore - but the UI needs to be rethought to live up to the task (that is, make-security-straightforward and the difference between blind trust and awareness apparent).

I appreciate uTox technically (compact code, nice interface and functionality) but for the moment it has the misfeature being discussed here which makes-insecurity-straightforward and secure-use-obscured/complicated (and unreliable? depends on whether the result of /alias can become overridden again by a remote nick change and which info is being shown in the list, chat and so on).

GrayHatter commented 8 years ago

Sadly I have to say welcome to alpha software, it can be feature incomplete. But utox not only tracks name changes in the message window, but allows you to set an alias for any contact or EVERY contact.

I'l agree with you about making security easier, and that's on my to-do list, but I disagree that forceing the user into setting an alias is the correct way to go about it.

@GrayHatter https://github.com/GrayHatter The first word in your comment is the crucial one. It is thinking which the user really really (did I emphasize enough? :) should do before sending or accepting a contact request.