ENHANCED PRIVACY PROTECTION FROM LOCATION-DEPENDENT ATTACKS IN LOCATION BASED SERVICES USING SPATIAL CLOAKING

Use of Internet enabled mobile devices has facilitated the rapid development of location-based services (LBS). LBS allow users to access useful information such as the nearest ATM, temple, and so on. Although users enjoy the convenience of LBS, they are being exposed to the risk of location disclosures which could lead to potential abuse of location data. Hence, location privacy protection has recently received considerable attention in LBS. There are numerous techniques presented by various researchers to protect the location-context of users. Location cloaking is an often used technique to protect location-contexts. Most of the existing location cloaking algorithms are only concerned with snapshot user locations and cannot effectively prevent users from location-dependent attacks when user location-contexts are continuously updated. This paper presents a solution to protect users from location-dependent attacks by improving the existing clique based cloaking algorithm. The main idea is to maintain maximum sized cliques required for location cloaking in an undirected graph. Thus, a qualified clique can be quickly identified and used to generate a cloaked region when a new request arrives. In addition, dummy queries are generated to protect users from unusual situations. Through maximum sized cliques and dummy query generation, more user queries get cloaked within a reasonable amount of time, thereby providing better privacy protection when using LBS applications. The experimental results showed that the proposed cloaking algorithm outperformed existing algorithms such as IClique, OptClique and MMBClique in terms of its cloaking success rate and processing time.


INTRODUCTION
Advances in information and communication technologies (ICTs) have revolutionized the way in which people perform their activities and obtain benefits from automated services. Especially mobile technologies have paved the way for getting details of services in less time; wherever the requester may be, and whenever the need arises. Location Based Services (LBSs) are a growing category of mobile applications that enable information services to be accessible with the help of mobile devices through the mobile network and to make use of the location of the mobile device. Though mobile users get benefits from the LBS applications, they have to expose their location-context to service providers (Bamba, Liu, Pesti, & Wang, 2008;Du, Xu, Tang, & Hu, 2007;Xu, Teo, Tan, & Agarwal, 2009). Malicious service providers through location-context, can determine users' life style, personal details and in extreme cases, track individuals (Cheng, Zhang, Bertino, & Prabhakar, 2006;Ghinita, Kalnis, Khoshgozaran, Shahabi, & Tan, 2008;Chow & Mokbel, 2009;Lin, Zakariah, & Mohamed, 2010;Pan & Meng, 2013;Shanthi & Balasundaram, 2015). This violates the privacy of users. Hence the location-context must be protected from adversaries, including malicious service providers (Kalnis, Ghinita, Mouratidis, & Papadias, 2007).
An efficient way to protect users is to blur the actual location-context into a cloaked region (CR) which preserves location k-anonymity property (Mokbel, Chow, & Aref, 2006;Um, Kim, & Chang, 2010;Pan, Xu, & Meng, 2012). Gruteser and Grunwald (2003) have incorporated the k-anonymity mechanism of relational databases to protect the user's location privacy. In the relational database, k-anonymity (Sweeney, 2002) used in the context of privacy preservation means that for each tuple, there is at least k-1 similar tuples. Whereas in location privacy, k-anonymity (Xu & Cai, 2007) means that for each user, there is at least k-1 users of the same location. That is to say, a minimum of k numbers of users are sharing the same location-context while issuing the location-based query to service providers. Thus, the cloaked region introduces uncertainty in finding the exact location-context of users; thereby protecting the location privacy of the users.
Most of the existing cloaking algorithms (Gedik & Liu, 2005;Mokbel et al., 2006;Um et al., 2010;Shanthi & Balasundaram, 2015;Kuang et al., 2017;Biswas & Sairam, 2017;Nguyen, 2017) have not considered the effect of continuous location updates of users. The continuous location updates may result in serious privacy breaches when different one-shot queries are frequently issued by mobile users. Towards this end, this paper proposes MClique-Dynamic cloaking algorithm with the goal of protecting users while updating their location-contexts continuously.

BACKGROUND AND RELATED STUDIES
The scenario for location-dependent attacks is given in Figure 1. Assuming that at time t 1 user Shan sends a query to 'Find the nearest ATM' and is cloaked into the region R 1 . Later, at time t 2 she issues another query to 'Find shopping mall within a km' and is cloaked into the region R 2 (users in R 1 and R 2 are shown in Figure 1). Suppose an attacker knows the historical region of Shan (i.e.) R 1 and R 2 and her speed limit, then it is easy to pinpoint the current location of Shan. The reason is that the user must be limited to the maximum movement boundary (MMB) computed at time, t 1 . The MMB is computed by extending the previous CR by a radius of 'r' and its computation is given in Equation 1. r = (t 2 -t 1 ) × speed of the vehicle (1) r = radius by which the CR generated at time t 1 is extended to form the MMB t 1 and t 2 =query sent time by the user From this inference, an attacker can deduce the user, Shan, who must be located in the overlapped area of MMB of the user at time t 1 and R 2 . The overlapped area may also be a single location point. In this case, the exact user location is disclosed with strong evidence. Similarly, the previous location of the user can also be deduced by an attacker. If an attacker knows the maximum arrival boundary (MAB) of the user, current and previous cloaked regions then the previous location of the user is limited to the intersection area of the MAB and previous cloaked region (Figure 1 -right side). The MAB is computed by extending the current cloaked region by a radius of 'r' as specified.

Figure 1. Location-dependent attacks
That is to say in continuous location updates, the mobile user's current and previous location can be predicted by LBS providers through historical information such as current and previous cloaked regions and the mobility pattern. This is known as location-dependent attacks (Pan et al., 2012;Shanthi & Balasundaram, 2014) and can be described in Equations 2 and 3: Current location (user) ═ Area (MMB ∩ Current CR) (2) Previous location (user) ═ Area (MAB ∩ Previous CR) Location-dependent attacks have been discussed in some existing work (Ghinita, Damiani, Silvestri, & Bertino, 2009;Xu, Tang, Hu, & Du, 2010). All these work only considered cloaking granularity as their privacy metric. The cloaking granularity alone preserves location privacy, but fails to protect user identity in case there is only one user in the cloaked region. To resolve this problem, Pan et al. (2012) proposed IncrementalCliqueCloak (ICliqueCloak) algorithm. This algorithm adopts both cloaking granularity as well as location k-anonymity as its privacy metrics and finds out the cloaked region for any user at time t i+1 within his/her MMB at time t i . However, this algorithm suffers from 'out-of-time' query; that is to say, some queries cannot be cloaked within the time period. Therefore, the queries cannot be answered. To minimize the 'out-of-time' queries as well as to protect users from location-dependent attacks, an efficient cloaking algorithm called MClique-Dynamic is proposed in this study.

3
(MAB) of the user, current and previous cloaked regions then the previous location of the user is limited to the intersection area of the MAB and previous cloaked region (Figure 1 -right side). The MAB is computed by extending the current cloaked region by a radius of 'r' as specified.

Figure 1. Location-dependent attacks
That is to say in continuous location updates, the mobile user's current and previous location can be predicted by LBS providers through historical information such as current and previous cloaked regions and the mobility pattern. This is known as location-dependent attacks (Pan et al., Shanthi & Balasundaram, 2014) and can be described as follows: Current location (user) ═ Area (MMB ∩ Current CR)

Previous location (user) ═ Area (MAB ∩ Previous CR)
Location-dependent attacks have been discussed in some existing work (Ghinita, Damiani, Si & Bertino, 2009;Xu, Tang, Hu, & Du, 2010). All these work only considered cloaking granula their privacy metric. The cloaking granularity alone preserves location privacy, but fails to user identity in case there is only one user in the cloaked region. To resolve this problem, Pan (2012) proposed IncrementalCliqueCloak (ICliqueCloak) algorithm. This algorithm adopt cloaking granularity as well as location k-anonymity as its privacy metrics and finds out the c region for any user at time t i+1 within his/her MMB at time t i . However, this algorithm suffer 'out-of-time' query; that is to say, some queries cannot be cloaked within the time period. The the queries cannot be answered. To minimize the 'out-of-time' queries as well as to protect use location-dependent attacks, an efficient cloaking algorithm called MClique-Dynamic is propo this study.

Previous location (user) ═ Area (MAB ∩ Previous CR)
Location-dependent attacks have been discussed in some existing work (Ghinita, Damiani, Si & Bertino, 2009;Xu, Tang, Hu, & Du, 2010). All these work only considered cloaking granula their privacy metric. The cloaking granularity alone preserves location privacy, but fails to user identity in case there is only one user in the cloaked region. To resolve this problem, Pan (2012) proposed IncrementalCliqueCloak (ICliqueCloak) algorithm. This algorithm adopt cloaking granularity as well as location k-anonymity as its privacy metrics and finds out the c region for any user at time t i+1 within his/her MMB at time t i . However, this algorithm suffer 'out-of-time' query; that is to say, some queries cannot be cloaked within the time period. The the queries cannot be answered. To minimize the 'out-of-time' queries as well as to protect use location-dependent attacks, an efficient cloaking algorithm called MClique-Dynamic is propo this study.
Algorithms such as CliqueCloak (Gedik & Liu, 2008), MMBClique, IClique and OptClique al., 2012) locate the cloaked region for a user 'u' based on a privacy value (k). Duri computation of the cloaked region, the algorithms group only neighbors whose privacy value Algorithms such as CliqueCloak (Gedik & Liu, 2008), MMBClique, IClique and OptClique (Pan et al., 2012) locate the cloaked region for a user 'u' based on a privacy value (k). During the computation of the cloaked region, the algorithms group only neighbors whose privacy value is less than or equal to that of the request of the user, 'u'. So that, for queries with high privacy value, the waiting time (which plays a major role in computation processing time) of the queries getting cloaked is increased; also in some cases, the queries cannot be cloaked. Thus, this leads to a reduced success rate and increased processing time. These issues are effectively handled in the proposed MClique-Dynamic by defining the privacy value (minimum privacy value guaranteed is 2 and maximum privacy value guaranteed is the number of users' issued queries at time 't') dynamically and generating duplicate queries. Thus, MClique-Dynamic guarantees the improved success rate of queries getting cloaked by minimizing 'out-of-time' queries and reducing processing time.
In view of protecting users from location-dependent attacks and ensuring the improved success rate of queries getting cloaked and to reduce processing time of cloaked region generation, in the proposed MClique-Dynamic, maximum sized clique is determined using greedy heuristic within the MMB of users. At the same time, this algorithm incorporates duplicate query generation in addition to location k-anonymity, reciprocity (the cloaked region contains u and at least k-1 additional users, also every user in a cloaked set generates the same cloaked set for the given k-value) and cloaking granularity (the area of the cloaked region which is larger than the userspecified threshold value) properties. We conducted a series of experiments to evaluate the performance of the proposed MClique-Dynamic algorithm using a synthetic dataset generated with the help of the mntg traffic generator (Mokbel et al., 2013).

OVERVIEW OF MCLIQUE-DYNAMIC ALGORITHM
The proposed MClique-Dynamic algorithm finds out the MMB first for each user upon the arrival of location-based queries from various users at a given time period. Then it computes the neighbors. Both users and their neighbors are modeled in an undirected graph. Next, the algorithm checks whether a clique set that satisfies location k-anonymity is formed in the modeled undirected graph. If any such clique set is found, then the minimum bounding rectangle (MBR) of the clique set is compared with A min and A max (minimum and maximum area covered by the cloaked region) values. The MBR (which will be given as a cloaked region) should be greater than or equal to A min in order to prevent location disclosures.
Consider a case in which the clique set satisfies the location k-anonymity but fails to satisfy cloaking granularity. In this case, the MBR of the clique set is extended in such a way that it satisfies the cloaking granularity. Similarly, if the cloaked region exceeds A max then it will be reduced to be equal to A max in order to avoid the larger cloaked region. The above mentioned criteria are stated as follows: Let MS = {u 1 , u 2 …, u n } be a user set that forms the clique, MBR is R u,ti at time, t i and S u is the speed of a user. The previous cloaked region of each user u is denoted by R u,ti-1 . The set MS is a cloaking set if and only if it satisfies the following conditions for any user u in MS: In order to defend against location-dependent attacks, the users in the cloaked region must satisfy the first two conditions. The third condition states the location k-anonymity requirement to protect user identity. Finally, the fourth and fifth conditions ensure that the area of the cloaked region is not too small (populated area) and not too big, respectively. Here, distance (R i , R j ) is the Euclidean distance between a point in R i and its closest point in R j .
There is a possibility for a situation in which the location k-anonymity property may not be satisfied. In this situation, the anonymizer generates duplicate queries with random users whose location-context is bounded within the MMB of the actual query issuer. The results returned in the duplicate queries are cached by the anonymizer for future use. By this random duplicate generation, the anonymizer maintains k-anonymity value as a minimum of 2. In the following section, a detailed discussion on steps associated with cloaked region construction is described to effectively and protectively answer location-based queries.

PRIVACY PROTECTION
Procedure for protecting the location privacy of users by generating k-anonymous cloaked regions using MClique-Dynamic is given in the following subsections.

Location Anonymization in Dynamic Context
In movement (continuous location updating), instead of one single query with snapshot location, a list of queries with different snapshot locations are sent to the LSP. In this scenario, if a cloaked region is constructed for each snapshot location using existing clique based cloaking algorithm, a malicious LSP can easily uncover the real location. For instance, assume a user uses the LBS app at 9.00 a.m. for obtaining a route suggestion for a particular destination. Later at 9.20 a.m., he/she issued the query about the POI (fuel station) during mobility. In order to protect the user, existing CliqueCloak generates two separate cloaked regions (without considering any query dependency) CR 1 and CR 2 at time 9.00 a.m. and 9.20 a.m., respectively. From the cloaked regions, the LSP can easily conclude the traveling route as well as the current location of the user. : Cloaked Region-CR Step 1: begin Step 2: for i←1 to | FP | do Step 3: construct MMB Step 4: end for Step 5: for i←1 to | FP | do Step 6: compute neighbor Step 7: end for Step 8: construct graph G ← (V, E) Step 9: for i←1 to | V | do Step 10: find clique existence with its neighbors Step 11: if (clique exist) then Step 12: if Amin ≤ MBR(clique) ≤ Amax then The reason is that the current location of the user must be limited to the MMB of the CR 1 (previous cloaked region). As per the CliqueCloak, the CR 2 (current cloaked region) may or may not be completely residing inside the MMB. If the CR 2 is not completely residing inside the MMB, then the user must be in the intersection area of the MMB and CR 2 . Hence, by correlating the MMB, previous and current cloaked regions, the service provider can easily pinpoint where the user is currently located. Similarly, the previous location of the user can also be determined. To prevent users from this type of attack, CliqueCloak has been modified in order to accommodate continuous location updating.
When a user (while in movement) wants to make a request to LBS, the anonymizer hides the location-context using clique based cloaked region construction algorithm in such a way that the current cloaked region always completely resides inside the MMB. For that, whenever a query is issued by various users, the anonymizer computes the MMB (as mentioned above) and then determines the neighbors. For a user 'u', the neighbors are the ones where the MMB is contained in each other. Next to neighbor computation, graph construction, clique computation and cloaked region construction are performed. The pseudo code for the proposed MClique-Dynamic cloaking is given in Algorithm 1.
With the computation of the clique, the size of the problem is reduced by 1 every time the clique is not formed. This is expressed by the recurrence Equation 4 as follows: The function f(n) accounts for the time needed to reduce an instance to a smaller one and to extend the solution of the smaller instance to that of n = number of mobile users issued the queries T = time to compute the clique a solution of the larger instance. Applying backward substitution, the above equation are peformed by Equations 5 and 6. (5) In the worst case, the problem size should be reduced to two; hence, substitute in the above equation 6, yield Equations 7 and 8.
In order to verify the pairwise connection between the users, the algorithms have two for-loops each with n iterations. Hence, f(i) takes n 2 time as in Equations 9.
(9) Thus, in the worst case scenario, clique computation takes O(n 3 ) time and in the best case scenario, clique computation takes only O(n 2 ).

Dummy Location-Contexts Generation
For the generation of duplicate queries, two important pieces of information are needed. One is service specific information (SSI) and another one is the location-context from where the query is posed to the LSP. Both the information can be generated at random. The random generation of SSI may not affect users' location privacy. However, the random generation of locationcontexts may reveal users' location privacy. The reason is the distribution of the location-contexts. For example, if k-1 location-contexts are chosen randomly within the MMB, there may be a possibility for these k-1 positions to be very close to the user's position in which the privacy region is generated. This can have negative consequences such as (a) malicious LSP will probably ignore outliers and may deduce the user's location-context with high certainty and (b) the privacy area that is the cloaked region generated may be a smaller e function f(n) accounts for the time needed to reduce an instance to a smaller one and to extend the lution of the smaller instance to that of a solution of the larger instance. Applying backward bstitution, the above equation becomes ( ) = ( − 1) + ( ) the worst case, the problem size should be reduced to two; hence, substitute = − 2 in the ove equation 6.
order to verify the pairwise connection between the users, the algorithms have two for-loops each th n iterations. Hence, f(i) takes n 2 time.
us, in the worst case scenario, clique computation takes O(n 3 ) time and in the best case scenario, que computation takes only O(n 2 ).

mmy Location-Contexts Generation
r the generation of duplicate queries, two important pieces of information are needed. One is SSI rvice specific information) and another one is the location-context from where the query is posed to e LSP. Both the information can be generated at random. The random generation of SSI may not fect users' location privacy. However, the random generation of location-contexts may reveal users' e function f(n) accounts for the time needed to reduce an instance to a smaller one and to extend the lution of the smaller instance to that of a solution of the larger instance. Applying backward bstitution, the above equation becomes ( ) = ( − 1) + ( ) the worst case, the problem size should be reduced to two; hence, substitute = − 2 in the ove equation 6.
( ) = (2) + (−3) + ⋯ + ( ) order to verify the pairwise connection between the users, the algorithms have two for-loops each th n iterations. Hence, f(i) takes n 2 time. ( rwise connection between the users, the algorithms have two for-loops each f(i) takes n 2 time.

Contexts Generation
of duplicate queries, two important pieces of information are needed. One is SSI formation) and another one is the location-context from where the query is posed to information can be generated at random. The random generation of SSI may not n privacy. However, the random generation of location-contexts may reveal users' he reason is the distribution of the location-contexts. For example, if k-1 locationrandomly within the MMB, there may be a possibility for these k-1 positions to be ser's position in which the privacy region is generated. This can have negative as (a) malicious LSP will probably ignore outliers and may deduce the user's ( ) = ( − 1) + ( ) n) accounts for the time needed to reduce an instance to a smaller one and to extend the smaller instance to that of a solution of the larger instance. Applying backward ( ) = (2) + (−3) + ⋯ + ( ) ify the pairwise connection between the users, the algorithms have two for-loops each s. Hence, f(i) takes n 2 time.
orst case scenario, clique computation takes O(n 3 ) time and in the best case scenario, tion takes only O(n 2 ).

ion-Contexts Generation
tion of duplicate queries, two important pieces of information are needed. One is SSI c information) and another one is the location-context from where the query is posed to the information can be generated at random. The random generation of SSI may not cation privacy. However, the random generation of location-contexts may reveal users' y. The reason is the distribution of the location-contexts. For example, if k-1 locationosen randomly within the MMB, there may be a possibility for these k-1 positions to be he user's position in which the privacy region is generated. This can have negative uch as (a) malicious LSP will probably ignore outliers and may deduce the user's The function f(n) accounts for the time needed to reduce an instance to a smaller one and to extend t solution of the smaller instance to that of a solution of the larger instance. Applying backwa substitution, the above equation becomes ( ) = ( − 1) + ( ) In the worst case, the problem size should be reduced to two; hence, substitute = − 2 in above equation 6.
Thus, in the worst case scenario, clique computation takes O(n 3 ) time and in the best case scenar clique computation takes only O(n 2 ).

Dummy Location-Contexts Generation
For the generation of duplicate queries, two important pieces of information are needed. One is S (service specific information) and another one is the location-context from where the query is posed the LSP. Both the information can be generated at random. The random generation of SSI may n affect users' location privacy. However, the random generation of location-contexts may reveal use location privacy. The reason is the distribution of the location-contexts. For example, if k-1 locatio contexts are chosen randomly within the MMB, there may be a possibility for these k-1 positions to very close to the user's position in which the privacy region is generated. This can have negati consequences such as (a) malicious LSP will probably ignore outliers and may deduce the use e function f(n) accounts for the time needed to reduce an instance to a smaller one and to extend the ution of the smaller instance to that of a solution of the larger instance. Applying backward stitution, the above equation becomes ( ) = ( − 1) + ( ) the worst case, the problem size should be reduced to two; hence, substitute = − 2 in the ove equation 6.
us, in the worst case scenario, clique computation takes O(n 3 ) time and in the best case scenario, que computation takes only O(n 2 ).

mmy Location-Contexts Generation
r the generation of duplicate queries, two important pieces of information are needed. One is SSI rvice specific information) and another one is the location-context from where the query is posed to LSP. Both the information can be generated at random. The random generation of SSI may not ect users' location privacy. However, the random generation of location-contexts may reveal users' ation privacy. The reason is the distribution of the location-contexts. For example, if k-1 locationntexts are chosen randomly within the MMB, there may be a possibility for these k-1 positions to be ry close to the user's position in which the privacy region is generated. This can have negative nsequences such as (a) malicious LSP will probably ignore outliers and may deduce the user's region and therefore the malicious LSP can easily pinpoint the user's locationcontext.
To counter these problems, some control is needed over the distribution of dummy location-contexts while generating duplicate queries. For this purpose, modified grid based dummy generation algorithm called DLC (Dummy Location-Context) is proposed and is described as follows.
A uniform square grid is created with an area (A) equal to the MMB of the user (to whom the CR is generated), and is composed of n vertices. Among the n vertices, one is the user position p, the other n-1 vertices will be used as dummy locations for duplicate query generation. The pseudo code of the DLC is given in Algorithm 2, and steps involved in the algorithm are stated as follows.
Step 1: Calculate the number of vertices, n as the square root of G, where G is a square number (the value of G is taken by the anonymizer).
Step 2: Attach the user position, p to one of the vertices, by randomly generating x, y indices.
Step 3: Determine the side length of the grid cells, L s by dividing the area of the grid (A) by the square root of G.
Step 4: Calculate the position for each grid vertex in row-major layout.
Step 5: Select k-1 number of vertices and enter its position into the dummy location-context array K d .
Step 6: Return K d .
Algorithm 2 : DLC INPUT: p-user location-context, k-privacy value, A-MMB of the user OUPPUT: K d -array of k numbers of location-contexts Step 1: begin Step 2: initialize K d ←{p};count ←1 Step 3: Step 4: Step 5: Step 6: for i ←1 to n do Step 7: for j ←1 to n do Step 8: x 1 ←(i -x)• L s +p x Step 9: y 1 ←(j -y)• L s +p.y Step 10: K d ← K d ∪(x 1 ,y 1 ) Step 11: count ←count +1 Step 12: if count ≤ k then Step 13: continue 5: Select k-1 number of vertices and enter its position into the dummy location-context array K d .
Step 6: Return K d .

5:
Select k-1 number of vertices and enter its position into the dummy location-context array K d .
Step 6: Return K d .

5:
Select k-1 number of vertices and enter its position into the dummy location-context array K d .
Step 6: Return K d .

PERFORMANCE EVALUATION
We have implemented the proposed MClique-Dynamic cloaking algorithm using Java, executed on Intel(R) Core (TM) 2 Duo 2.00GHz machine with 3.00 GB of RAM and Windows 7 Operating System. For experimental purposes, approximately 2.5 MB of data was generated with the help of the mntg traffic generator (http:// mntg.cs.umn.edu). The input parameters of the generator are shown in Table 1, and the simulated traffic pattern is shown in Figure 2.

Results and Discussion
The proposed MClique-Dynamic algorithm is compared with three algorithms, namely MMBClique, OptClique, and IClique. MMBClique refers to the revised version of the cloaking algorithm proposed by Gedik and Liu (2005). In this algorithm, the tolerable maximum cloaked region is replaced with the MMB to prevent from location-dependent attacks; so that it generates larger cloaked regions as users' privacy area. Thus MMBClique increases cloaking time. In order to reduce cloaking time, Pan et al. (2012) has proposed IClique and OptClique. IClique adopts both cloaking granularity as well as location k-anonymity as its privacy metrics and finds out the cloaked region for any user at time t i+1 within his/her MMB at time t i . Hence compared to MMBClique, IClique can generate a smaller cloaked region to serve as users' privacy area. Thus, IClique reduces cloaking time. The optimized version of IClique is OptClique algorithm which further reduces the size of a cloaked region. In this algorithm, the MMB is set to infinity. Even though this algorithm does not protect users from location-dependent attacks, it is included for comparison to show the cost required for defending against location-dependent attacks. However, all the above mentioned algorithms (MMBClique, IClique, and OptClique) suffer from 'out-of-time' queries. Therefore, the success rate of the queries getting cloaked is reduced. This problem is effectively handled by the proposed MClique-Dynamic cloaking algorithm and is shown in the following experimental results.
The experimental parameters are shown in Table 2, and for evaluation purposes, metrics such as success rate, time to generate dummy locationcontexts (DLC) and cloaking time are used. As shown in Figure 3, the success rate of IClique and OptClique decrease with much more diversified privacy levels. They reach 89% and 87%, respectively when the privacy level reaches 25. The reason is that the attempts by both IClique and OptClique to find out cloaked regions by incrementally maintaining maximal clique takes more time to cloak users' requests for larger k values. Therefore, some queries would have expired before they are cloaked successfully, and this is reflected in the reduced success rate. In addition, the success rate of MMBClique decreases significantly with increasing k. Its success rate drops to about 66% when the privacy level reaches 25. The main reason is that MMBClique finds the cloaking set only from neighbors whose privacy levels are less than that of the new request. Thus, a request with a higher privacy level is difficult to be cloaked successfully in the MMBClique. In contrast, MClique-Dynamic has the best performance. Its success rate is about 99%, even with increasing k values. This is mainly because MClique-Dynamic employs duplicate query generation to find a cloaking set with a larger k-value and in situations where sufficient requests are not available for cloaking. As a result, all the requests are cloaked before they expire. Therefore, this indicates a significant difference in the cloaking algorithm of the proposed MClique-Dynamic.  Figure 3. Success rate. Figure 4 shows the cloaking time of all algorithms. In most cases, waiting time dominates the overall cloaking time of cloaked region generation, and cloaking time increases with increasing k values. In particular, MMBClique cannot scale up to a larger privacy level and its processing time gets worse dramatically. In contrast, IClique and OptClique require a much shorter processing time than MMBClique. The reason is that both these algorithms can quickly find the cloaking set from the set of incrementally maintained maximal cliques.  Although the proposed MClique-Dynamic algorithm employs DLC to protect users from extreme situations, the cloaking time of the proposed MClique-Dynamic can be further reduced. The reason is that the duplicate queries are generated in a reasonable amount of time (in milliseconds). Figure   12 find a cloaking set with a larger k-value and in situations where sufficient requests are not available for cloaking. As a result, all the requests are cloaked before they expire. Therefore, this indicates a significant difference in the cloaking algorithm of the proposed MClique-Dynamic.

Number of Dummy Location-contexts
DLC 5 show that the DLC takes only 0.029ms when the privacy value reaches 25. This signifies that the proposed location cloaking algorithm does not delay cloaking time. Besides, the proposed algorithm speeds up the process of finding the cloaking set only from neighboring nodes, thereby eliminating time taken to incrementally maintain maximal cliques. Figure 6. Spatial Resolution. Figure 6 compares the size of the cloaking areas of IClique and MClique-Dynamic. As can be seen, cloaking areas are less than 2km 2 for lower privacy values (k=5), less than 4.5 km 2 for medium privacy values (k=10 or k=15) and less than 5km 2 for higher privacy values (k=20 or k=25). That is MClique-Dynamic generates a smaller (better) region than IClique when privacy values increase. This is mainly because MClique-Dynamic imposes two threshold values (A min and A max ) while seeking out the cloaked region, but IClique employs only one threshold value (A min ). Figure 7 shows that the cloaked region computation time varies for varying A max (1-3km 2 , 4-6km 2 , and 7-9km 2 ) values. It is observed that the higher the A max value, it results in higher cloaked region computation time. The reason is that cloaked region computation time includes the time to compute neighbors, construct MBR and check for clique existence. Hence, when the A max value is increased, there may be a chance of getting more numbers of users inside the MBR, thereby increasing the time taken for checking clique existence. This is reflected in an increase in cloaked region computation time.  Figure 6 compares the size of the cloaking areas of IClique and MClique-Dynamic. As can be seen, cloaking areas are less than 2km 2 for lower privacy values (k=5), less than 4.5 km 2 for medium privacy values (k=10 or k=15) and less than 5km 2 for higher privacy values (k=20 or k=25). That is MClique-Dynamic generates a smaller (better) region than IClique when privacy values increase. This is mainly because MClique-Dynamic imposes two threshold values (A min and A max ) while seeking out the cloaked region, but IClique employs only one threshold value (A min ). In addition, threshold values influence the size of the CR. Since the size of the CR is restricted by the threshold values, spatial resolution is affected by A min and A max values. A larger A min and A max generate a larger region as users' privacy area. Similarly, a smaller A min and A max lead to a smaller CR. Therefore care must be taken while choosing threshold values. In the experiment, better cloaking is achieved when selecting A max at 4-6km 2 .
The positive side of the proposed MClique-Dynamic is a) minimization of 'out-of-time' queries and b) generation of CR that lies between two threshold values A min and A max (i.e. A min ≤ cloaked area ≤ A max ). Through minimizing 'out-of-time' queries, most of the queries are successfully cloaked and by using threshold values the anonymizer prevents the generation of cloaked regions which are neither too small nor too large. Intuitively, a smaller CR brings better performance in terms of storage cost and computation, while a larger CR makes it better from the privacy point of view.
Despite this, regions which are too small improve the level of certainty of locating users and therefore the location privacy of users is violated. On the other hand, regions which are too large may increase processing cost of the service provider which in turn leads to a reduction in the quality of query services. Thus, the proposed MClique-Dynamic algorithm balances both the privacy of users and quality of query services in terms of generating reasonably-sized CRs. In addition, it preserves the two main ingredients of cloaking namely a) location privacy-unable to locate user and b) query anonymity-unable to identify person who sent query. Average Time (ms)

CONCLUSION
In this paper, we have presented the MClique-Dynamic, cloaking algorithm which safeguards the location privacy of users from location-dependent attacks. To obtain an improved success rate, duplicate queries are generated using DLC algorithm while seeking out the cloaking set. In addition, two threshold values are used to avoid the generation of CRs which are either too small or too large. As these would reduce the certainty level of locating users in populated areas, and also maintain the quality of query services. Through generating duplicate queries and reasonably-sized CRs, the proposed MClique-Dynamic is capable of protecting users' location privacy better than existing cloaking algorithms such as IClique, OptClique, and MMBClique. The improvements are shown in the experimental results using synthetic dataset generated by the mntg traffic generator. Existing solutions to cloak users' location-contexts may degrade the usefulness of LBS applications when more numbers of requests emerge from people in different places. The reason is when query density that is user density is increased, the graph constructed by the anonymizer may become a dense graph and processing the dense graph by an anonymizer will take more time. One way to speed up the anonymization of location-context of various users is partitioning the user graph into separate units of smaller sub-graphs which can be mapped onto parallel processors of anonymity servers hosted on trusted cluster computing environment bases. In accord with this, we propose a graph partitioning based spatial cloaking algorithm in our future work.