Tag: contact management

Mutually-verified contacts as a security feature for messaging and social media

Most of us who have used Facebook have found ourselves seeing a friend request for someone who is already our Facebook Friend. This is a form of account compromise where someone creates a doppleganger of our account as a way to impersonate our online personality.

Such “clone” accounts of our online presence can be used as a way to facilitate a “man-in-the-middle” attack especially when dealing with an encrypted communication setup. It is an issue that is becoming more real with state-sponsored cybercrime where authoritarian states are hacking computer and communications equipment belonging to journalists, human-rights activists or a democracy’s government officials and contractors.

Mutually-verified contacts

In most implementations, each contact has a code that is generated by the messaging or social media platform as a human-readable or machine-readable form. The former approach would be a series of letters and numbers while the latter would be a barcode or QR code that you scan with your computing device’s camera.

In a lot of cases, this code changes if the user installs the social-media app on a new device or reinstalls it on the same device. The latter situation can occur if your phone is playing up and you have to reinstall all of your apps from scratch.

Users are encouraged to verify each other using this authentication code either in person or through another, preferably secure, means of communication. In-person verification may take place in the form of one user scanning the other user’s machine-readable code with their phone.

This allows each user of the platform to be sure they are communicating with the user they intend to communicate with and there isn’t anything that is between each party of the conversation. It is similar to a classic contact-authentication approach of asking someone a question that both you and the contact know the answer to mutually like a common fact or simply using a nickname for example.

The feature is part of Signal but is being baked in to Apple iMessage as part of iOS/iPadOS 16.3 and MacOS Ventura 13.1. But I see this as a feature that will become part of various instant-messaging, social media and similar products as the market demands more secure conversation.

Zoom also implements this as part of its end-to-end encryption feature for videoconferences. Here, users can verify that they are in a secure videoconference by comparing a number sequence read out by the meeting host after they click on a “shield” icon that appears during an encrypted videoconference. Here, this feature could come in to play with Signal and similar apps that are used for group conversations.

Relevance

Primarily this feature is being pitched towards users who stand to lose a lot, including their lives because they engage in “high-stakes” activities. Such users are government officials, public servants and military in democratic states, vendors who sell goods and services to government or military in these states, journalists and media workers in states that value a free press along with human-rights activists and NGSs.

Here, these users become highly vulnerable due to them being of interest to authoritarian states and organisations or individuals that aid and abet these states.  It is also being applied to countries that have undergone a significant amount of democratic backsliding or are considered to be socially unstable.

Personally, I see this as being important for everyday use so you can be sure that whom you want as part of your social-media or online messaging circle is whom you actually want. Here, it can avoid you dealing with scams based on others impersonating you or others in your social circle such as the “relative in distress” scam. As well, it can also be seen as a way to be sure you are linking with the right person when you add a new person to your social-media list.

Conclusion

I would see an increasing number of communications, social media and similar platforms acquiring the “mutual contact verification” function as a security feature. This would be more so where the platform supports end-to-end encryption in any way or there is a reliance on some form of personal safety or business confidentiality.

The Nickname field is now of use for mobile assistant platforms

Article

Samsung Galaxy Note 2 smartphone

Android and iOS can support contacts’ nicknames with Google Now and Siri

Use Nicknames With Siri And Google Now To Reach Contacts Faster | Gizmodo

My Comments

Most smartphone operating systems have in their contact list a field called “Nickname”. This is typically of use when you have a personal nickname, relative-shortcut name like “Mum” or similar name for a contact. But in most cases, this field isn’t shown up on call logs or contact lists.

Now Siri and Google Now make use of the Nickname field to interpret instructions to call particular people. Google Now does provide inherent support for relationship-shortcut names but you can use the Nickname field for manually determining a contact’s nickname. Both voice assistants can query which person a nickname pertains to which can come in handy if you are calling one of many siblings or someone with an obscure nickname or a nickname that is spelt a certain way but pronounced another way.

How could this be improved upon?

Nicknames appearing in the contact-display context

At the moment, the nickname functionality only works in the contact-search context but I would like to see it also work in the contact-display context especailly when a call or text comes in from the contact or you browse through your contact list or recent / missed call logs. This could be facilitated through the use of a “Display As” field which shows a user-chosen field or combination of concatenated fields for a particular contact.

Support for a phonetic representation of a nickname

These systems could support the ability to store a phonetic representation of a nickname which can come in handy when you say that nickname one way but have it written another way. The phonetic representation would be used for voice-based search and voice-based call announcements.

Security issues with nicknames

Nicknames may expose security issues when they fall in to the wrong hands. It is because people use these nicknames as a “password” or “word of trust” within their community.  But confidence tricksters using familiar nicknames as a way to “get in to someone’s mind” and have them acquiesce to their inappropriate scheme. In some cases, a nickname that is a symbol of endearment may be used as a weapon against one or both of the participants.

Having nicknames as a “secure” field which is only shown to trusted users is important to preserve this kind of security. For example, if a phone shows a list of missed calls or text messages on the notification screen, it could show a standard “first-name last-name” or “company-name” while locked but show the nickname while unlocked. Similarly, voice-level biometrics can be used to authenticate a user who is “searching by nickname” using a voice-based personal assistant.

Further improvements needed for phone contact lists

Handling of common phone numbers

Another area where a lot of contact list programs miss out on is handling phone calls or other communication that comes in from pbone numbers, emails or other contact addresses common to two or more contacts.

The most common example is a landline phone number that serves as a “catch-all” number for a household, workgroup or business. In this case, you may instruct the voice assistant to call a person on that landline by saying “person-name Home” or “person-name Work” or something similar. This will place the call to that landline. The same thing will happen if you contact someone else who lives or works behind that common phone number.

The problem rears its ugly head when a call comes in from that phone number or you review your call logs and you see the first alphabetically-listed contact related to that “catch-all” number even though other contacts in your contact list are behind that number. Here you don’t know whom it was who called you or whom you placed that call to.

This could be facilitated using a dynamically-concatenated display field for phone numbers with something like [<company-name>(caller-name-1. caller-name-2, or caller-name-n] for callers with a populated company-name field; or [caller-name-1, caller-name-2 or caller-name-n] for callers missing a company-name field i.e. households. Or you may create a dedicated contact entry for the “catch-all” phone number such as a distinct “name-address-number” entry for a company or household. Then you add “common fields” like work number, home number or company name to the entries associated with the people with that same “roof” in common. The name associated with the dedicated contact entry shows up in the call log when you call that number or on your phone’s screen when they ring you from that “catch-all” telephone.

Conclusion

At least something is being done to make sure that the contact management software and voice-activated personal assistant software  is tied in to how we view our contacts so we see our contacts our way.