We have identified the following requirements that our access control model must satisfy:
• Requirement 1
The access control model must allow users to specify who is entitled to obtain their sightings in terms of users, LBSs, or both users and LBSs.
Users may base their security specifications on the identities of the users, as indirect requesters, with whom they are willing to share their sightings.
Indeed, Lederer, Mankoff, and Dey found that the indirect requester’s identity is a significant determinant of users’ security specifications [49]. This type of security specification can be represented using a permission that contains a single subject to represent the indirect requester. However, such a permission can be used with many different LBSs, as proxy requesters, and this might not be in accordance with the user’s security specification.
Alternatively, users may base their security specifications on the identities of the proxy requesters, with which they are willing to share their sightings.
For example, Barkhuus and Dey found that the proxy requester’s identity is a significant determinant of users’ security specifications [9]. This type of security specification can be represented using a permission that contains a single subject to represent the proxy requester. However, such a permission can be used with many different indirect requesters, and this might not be in accordance with the user’s security specification.
However, there may be occasions when users will want to base their secu-rity specifications on the identities of both the indirect requesters and the proxy requesters simultaneously. This has the effect of allowing a user to ei-ther increase or decrease the level of trust that he/she has in the requesters if they cooperate with each other. For example, consider the simplified ex-ample where a user, Stefano, is willing to let another user, Carlotta, obtain his sightings with a low sighting accuracy using any LBS. Therefore, Stefano creates a permission in which Carlotta is the subject. Carlotta can use this permission with an LBS called FriendFinder that displays Stefano’s location on a map, and Stefano’s privacy will be respected because FriendFinder will
only be able to obtain his sightings with a low sighting accuracy. Now con-sider another LBS called NearbyFriendFinder that enables Carlotta to obtain Stefano’s sightings with a very high sighting accuracy, but only if both Ste-fano and Carlotta are currently sighted very close to each other. Carlotta will be unable to use NearbyFriendFinder to obtain Stefano’s sightings, because NearbyFriendFinder requires Stefano’s sightings with a high sighting accu-racy, and Stefano is only willing to let Carlotta obtain his sightings with a low sighting accuracy. However, since NearbyFriendFinder only releases Stefano’s sightings in very limited circumstances, he is willing to let it obtain his sight-ings with a high sighting accuracy. Stefano cannot specify this permission in terms of NearbyFriendFinder alone, because NearbyFriendFinder would then be able to obtain Stefano’s sightings with a high sighting accuracy at any time.
Therefore, Stefano’s security specification is based on both Carlotta and Near-byFriendFinder. This type of security specification can be represented using a permission that contains both a subject to represent the indirect requester and a subject to represent the proxy requester.
However, representing a security specification using a single permission that must contain both a subject to represent the indirect requester and a subject to represent the proxy requester is neither efficient nor scalable. Consider an example where Stefano wants to base his security specifications on m indirect requesters and n proxy requesters. In this example Stefano will need to create m ∗ n different permissions. Stefano must then create n new permissions for each new indirect requester that he wants to include in his security specifi-cations. The creation of these new permissions for every proxy requester has the effect of allowing a user to specify that the indirect requester can obtain his/her sightings using any proxy requester that he/she already trusts. Sim-ilarly, Stefano must create m new permissions for each new proxy requester that he wants to include in his security specifications. The creation of these new permissions for every indirect requester has the effect of allowing a user to specify that the proxy requester can obtain his/her sightings using any indirect
requester that he/she already trusts.
Therefore, the access control model must allow users to independently express levels of trust in both indirect requesters and proxy requesters, but the access control model must not allow either the trusted indirect requesters or the trusted proxy requesters to request sightings unilaterally.
• Requirement 2
The access control model must allow users to specify the circum-stances in which their sightings are released.
Users may base their security specifications on factors that are external to the access control model. For example, Anthony, Henderson, and Kotz found that users expressed different levels of willingness to share their sightings depending on their current locations [3]. Lederer, Mankoff, and Dey found that users expressed different levels of willingness to share their sightings depending on their current activities [49].
• Requirement 3
The access control model must allow users to specify the maximum sighting accuracy of any sightings that are released.
Typically, users will specify a greater sighting accuracy for indirect requesters and proxy requesters that are trusted. This sighting accuracy that is output from the access control model is then used to determine part of the input to our sighting blurring algorithm, as described in Chapter 6.
Our access control model, which supports these three requirements, enables users to create permissions that support a wide range of security specifications from very simple security specifications to very complex and personalised security specifica-tions. This ability to support a wide range of security specifications will encourage the usage of LBSs by users, according to the findings of Anthony, Henderson, and Kotz in their empirical study of users’ security requirements in the context of LBSs [3].
Since our access control model is required to allow users to create permissions regarding their own sightings, our access control model provides a form of Discre-tionary Access Control (DAC).
In Section 5.6 we will compare our access control model and its requirements with the related research described in Section 3.3.