The Petname Model is a systematic way to personalise global identities.
Systems implementing this model allows users to relate identities with some kind of personal media. For instance names, text strings, images or even sounds.
2.5.1 Zooko’s triangle
Zooko presented in [82] three desirable properties that a name should have, but cannot have at the same time. Those three properties is known as Zooko’s triangle. These properties areDecentralized,Secureand Human-Meaningful. As proposed by Stiegler in [72] we will use "Global"
instead of "Decentralized", as "Global" is a more understandable concept.
"Memorable" instead of "Human-Meaningful" and "Unique" instead of
"Secure". The last renaming might not be as clear as the other two, the reason for the change is that the security of a name lies in its uniqueness.
Zooko’s triangle is shown as it is commonly depicted in Figure 2.9 on the following page. A triangle with Global, Unique and Memorable as its corners.
The Domain Name System is probably the closest naming system to incorporate all three properties, however since it is possible for a third-party to register domain names with small changes it is vulnerable to mimicking and thereby phishing. Stiegler points out "In general, phishing depends on mimicry, not forgery" [72].
The properties of names in Zooko’s triangle are:
Global
The name is public and global. It can be exemplified with names of companies, persons or every day objects.
Unique Memorable Global
Petnames No names land
Nicknames
Pointers
Figure 2.9: Zonko’s triangle with elements from a Petname System Unique
A name is unique syntactically within its domain. For instance phone numbers.
Memorable
A name is easy to remember and recognise. One example often used is the "moving bus test". You see a bus with some name or address on the side and you still remember it when you get home.
When the Petname Model is added into Zooko’s triangle, we get different types of names as connections between each property: Pointers, Nicknames and Petnames. These are the connections between the corners in Figure 2.9. The different name types that connects the corners in Zooko’s triangle are as follows:
Pointers
They are Global and Unique, but not Memorable. It has also been called "True Name" by Shapiro [69] and "Key" by Miller [58] and Stiegler [72]. The pointer is a unique identifier for one specific person, document, system etc. Social security number combined with nationality is one example of a unique identifier for persons in Norway.
Nicknames
A Nickname isGlobalandMemorable, but since a nickname can mean different things to different people, it is not Unique in the global domain. A person’s given name is such a nickname.
Petnames
Both Memorable and Unique, but not Global as this is personal and
might also be context dependent. Petnames is a chosen name for one person by another person e.g. "dad" or "grandma".
2.5.2 What is the Petname Model?
We need to distinguish between a Petname Model and a Petname System.
The model is the idea of a system and its properties, while the system is an implementation of the model.
A Petname Model is a way to relate a personal nickname to a globally known identifier. It lets the user give their important services a personal property, e.g. a name, picture, sound or any combinations of these [72].
One example of a Petname System is a phone book on a mobile phone [22].
When the phone is ringing it shows the name related to the number in the phone book. A smart phone also allow the user to set specific ring- and message tones as well as a picture to a contact.
The same can be done for a list of hostnames, by giving a personal text or image for each website the user visits. An extra function that can be performed in a Petname System is to check its list for similar hostnames and warn the user about a possible phishing attack. It is not in the model itself but would be a useful feature. There might also be possible to extend the system to check cryptographic signatures in the Secure Sockets Layer or other persistent information.
A Petname System can help the user to easily confirm that the service is the same service as he or she already has cognitively authenticated. The user would remember the authentication process that was done when the Petname was created when it is shown. Such a remembrance will help the user to get into the same mindset as when the authentication took place.
2.5.3 Requirements
Ferdous et al. describes multiple requirements for a Petname System [22]. These are listed in Appendix B on page 97 and consist ofFunctional Properties(in Table B.1) andSecurity Usability Properties(in Table B.3). The Functional Properties consists of requirements to how the Petname System should function. The first is the basis for the system, requiring that a Petname System should at least have one set of Pointers and Petnames.
F2 states thatNicknames are optional. For Pointers to be resistant against forgery is property F3. The last functional property (F4) is a one-to-one bi-directional relation between the Pointer and the Petname within each domain. However, F4 has been augmented in a later publication by some of the authors [23]. In the new publication the authors have gone from a strictbi-directional one-to-one mappingbetween thePetnameand thePointer, to allow a bi-directional one-to-many mapping as long as the Pointer refers to the same entity (see Table B.2 on page 97). The change is justified by pointing out that one entity can have several pointers and the user should be able to use the samePetnamefor the same entity.
The second category of properties is the Security Usability Properties and focuses on the system-user interaction. These can be sorted into two
subcategoriesSecurity ActionsandSecurity Conclusions. The first describes possible actions the user can perform in the system. The other are which conclusions the user can arrive at using the information given by the system.
The Security Usability Properties fits into the usability principles for security proposed by Jøsanget al. in [44]. These are calledSecurity Action Usability PrinciplesandSecurity Conclusion Usability Principles. Both of these has four points as shown in Table B.3 and B.5 in Appendix B on page 97.
They are related to one another in a way that the action describes what must be done by the user, and the conclusion describes how the user can assess the security. For instance A2 requires that the user must have the knowledge and ability to make the correct security action. C2 requires that the system provides the information necessary to come to the correct conclusion. A1 and C1 cover the user’s understanding of these principles.
A3 and C3 describe a tolerable mental and physical load by performing an action or arriving at a conclusion. The two last principles are A4 and C4 they cover the mental and physical load must be tolerable for multiple actions and conclusions.
Some of these properties are relying on each other, e.g. the use of Nicknames. F2 describes that the Nickname isoptional. If this property is not satisfied by a system, the system is non-compliant with a number of other properties where the Nickname is the main or secondary focus.
2.5.4 Already existing tools
In [22] they evaluated two Petname System Add-Ons for the Mozilla Firefox web browser, called Petname Tool and the TrustBar. These were evaluated against the properties in Table B.1 and B.3 in Appendix B on page 97. In Table 2.2 on the facing page there is a summery of how these two systems satisfy the properties. Both systems allowed the user to add the same Petname to different pointers, which contradict F4 as there is no longer a one-to-one mapping. This also affect SA7 as the system does not make sure if the new Petname is sufficiently different from existing Petnames. They do not ask the user if he or she would like to add a Petname for highly sensitive data, not meeting the requirement in the SA9 property.
The Petname Tool had some limitations. For example it was not possible to enter nickname (F2) nor did it give the user any Petname suggestions. It did alert the user if a new Petname was resembling an already exiting one.
The TrustBar supported nicknames and provided Petname suggestions based on these nicknames. It did not alert the user if the new Petname resembles the Nickname or an already existing Petname.
As mentioned shortly in Section 1.5.1 on page 4, it has come to our attention that both of these projects are no longer updated and can be considered defunct.Petname Toolwas last updated on the 30th of June 2009 [16]. The information page forTrustBar[35] was last updated late january 2006. It is likely that the development stopped around the same time.
It is hard to determine why these two projects are defunct. It might be
F SA SC System 1 2 3 4 1 2 3 4 5 6 7 8 9 1 2 3 4 5 Petname Tool Y N Y N Y Y Y N N N N Y N Y Y Y N Y TrustBar Y Y Y N Y Y Y Y Y Y N N N Y Y Y Y N Table 2.2: Summary of how Petname Tool and TrustBar satisfies the properties fromFerdous et al.
Figure 2.10: How a mobile Petname System is working
because of low number of users. Petname Toolis used by 179 users [16].
The reviews of this Add-On shows that it was attractive by users who understood its purpose. The TrustBar was discontinued before Add-On manager was released as a part of Firefox in the summer of 2008. There is no information about the number of users for this Add-On.
The most likely reason is that the developers did not have the time nor resources required to keep up with the development of these solutions for new versions of Firefox. It has also been introduced a big number of reputation services for web sites over the last years. Some of these services are extensions to web browsers [7], others as search tools or even built in to the browser [73, 62]. These solutions are being actively updated and may have contributed to the decline in the popularity of the Petname Systems.
2.5.5 Mobile Petname System
Most users are moving between different computing platforms. We access different platforms at work, at the university and at home. The amount of work required to keep one set of Petnames updated on one platform can be considered acceptable. The challenge arises when we introduce two or more sets. It becomes hard to keep track of additions, deletions and other changes that have been done in the different systems. This might even render the browser specific systems unusable.
One solution for this is to make the system mobile, giving the user the freedom to take his set of Petnames with him and use it on every computer he interacts with. Figure 2.10 illustrates with a simple diagram of how this Mobile Petname System works. Where the information about the request is first sent to the OffPAD (1), the OffPAD sends its response back to the computer (2). Depending on the result, the request is sent over the internet (3) and get the requested data in return (4).