User Tools

Site Tools


sql-derivative-sensitivity-analyser_demo

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
sql-derivative-sensitivity-analyser_demo [2019/06/01 15:47]
alisa [Running guessing advantage analysis]
sql-derivative-sensitivity-analyser_demo [2019/10/01 13:53] (current)
Line 85: Line 85:
 ==== Running sensitivity analysis ==== ==== Running sensitivity analysis ====
  
-We are now ready to run the analysis. Click the blue button //​Analyze//​. Let us first set ε = 1 and β = 0.1. Click the green button //Run Analysis//. The most interesting value in the output that we see is the //relative error//. This can be interpreted as an upper bound on the relative distance of the noisy output from the actual output, which holds with probability ​80%. There is unfortunately no strict upper bound on the additive noise, and it can potentially be infinite, though with negligible probability. Hence, we can only give a probabilistic upper bound on the noise, which is in our case hard-coded to 80%.+We are now ready to run the analysis. Click the blue button //​Analyze//​. Let us first set ε = 1 and β = 0.1, and set the slider "​Confidence level of estimated noise" to 90%. Click the green button //Run Analysis//. The most interesting value in the output that we see is the //relative error//. This can be interpreted as an upper bound on the relative distance of the noisy output from the actual output, which holds with probability ​90%. There is unfortunately no strict upper bound on the additive noise, and it can potentially be infinite, though with negligible probability. Hence, we can only give a probabilistic upper bound on the noise.
  
 We can now play around with the model and see how the error can be reduced. We can now play around with the model and see how the error can be reduced.
Line 96: Line 96:
 ==== Running guessing advantage analysis ==== ==== Running guessing advantage analysis ====
  
-Our model is also ready for [[sql-guessing-advantage-analyser|guessing advantage analysis]]. Open the model in GA analyzer mode (e.g. clicking the button //Change analyzer//​). We see that the table schemas, the data, and the query are the same as they were in the combined sensitivity analyzer.+Our model is also ready for [[sql-guessing-advantage-analyser|guessing advantage analysis]]. Open the model in GA analyzer mode (e.g. clicking the button //Change analyzer//​). We see that the table schemas, the data, and the query are the same as they were in the combined sensitivity analyzer. However, there is no tab for table norm anymore.
  
 Click the blue button //​Analyze//​. We need to specify what the attacker already knows and what he is trying to guess. Click the blue button //​Analyze//​. We need to specify what the attacker already knows and what he is trying to guess.
  
-=== Attacker settings ​===+=== Table constraints ​===
  
-From the data table, we can already infer possible values of ship locations. Let both ''​latitude''​ and ''​longitude''​ be bounded by the range (-300,300). We insert the following code into the window that opens after clicking //Attacker settings// button.+From the data table, we can already infer possible values of ship locations. Let both ''​latitude''​ and ''​longitude''​ be bounded by the range (-300,300). We insert the following code into the window that opens after clicking //Table constraints// button.
 <​code>​ <​code>​
 ship.latitude range -300 300; ship.latitude range -300 300;
Line 108: Line 108:
 </​code>​ </​code>​
  
-=== Sensitive attributes ​===+=== Attacker goal ===
  
-If the attacker guesses the location precisely, this is bad. However, it can be bad even if he guesses the location precisely enough. Let us assume that we want to avoid guessing within 5 units of precision. We insert the following code into the window that opens after clicking //Sensitive attributes// button.+If the attacker guesses the location precisely, this is bad. However, it can be bad even if he guesses the location precisely enough. Let us assume that we want to avoid guessing within 5 units of precision. The attacker goal is stated in form of an SQL query with some additional special syntax for approximation. We insert the following code into the window that opens after clicking //Attacker goal// button.
 <​code>​ <​code>​
-ship.latitude ​approx 5 AND +SELECT 
-ship.longitude ​approx 5; +ship.longitude ​approx 5 AND 
-cost 100+ship.latitude ​approx 5 
 +FROM ship;
 </​code>​ </​code>​
  
-In this example, the leakage cost is set to 100. The cost does not affect ​the noise level in anyway, ​and its only goal is to give alternative interpretation to the guessing advantageIt can always be set to default value 100so that the average cost would equal the advantage.+In this example, the attacker wins if he guesses both the latitude ​and the longitude withing 5 units of precisionHence, the set of successful guesses looks like a 10-unit square centered around the actual location. Intuitively,​ we would like it to be a circle. We can state attacker'​s goal as approximating ​the location w.r.t. Euclidean distance, i.e. l_2-norm.
  
 +<​code>​
 +SELECT
 +(ship.longitude,​ ship.latitude) approxWrtLp(2) 5
 +FROM ship;
 +</​code>​
  
-We can now play around with the model and see how the error can be reduced.+It is possible that not all ships are private, and the attacker is only interested in some of them. We can add a filter to attacker'​s goal. Let us select only those ships that have sufficiently much cargo on them. 
 + 
 +<​code>​ 
 +SELECT 
 +(ship.longitude,​ ship.latitude) approxWrtLp(2) 5 
 +FROM ship 
 +WHERE ship.cargo >= 50; 
 +</​code>​ 
 + 
 +=== Experiments === 
 +We can play around with the model and see how the error depends on different parameters.
   * Increasing allowed guessing advantage decreases the error. At extreme cases, we get the error ∞ if we want advantage 0%, and the error 0 if we allow advantage 100% (more precisely, if we allow posterior probability 100%, which happens for even a smaller advantage).   * Increasing allowed guessing advantage decreases the error. At extreme cases, we get the error ∞ if we want advantage 0%, and the error 0 if we allow advantage 100% (more precisely, if we allow posterior probability 100%, which happens for even a smaller advantage).
-  * Try to decrease the allowed guessing ​radius ​(e.g. set it to 1). In general, it becomes more difficult for the attacker to make a guess, so the error decreases.+  * Try to decrease the allowed ​precision of guessing (e.g. change ​it from 5 to 1). In general, it becomes more difficult for the attacker to make a guess, so the error decreases.
   * Try to increase and decrease the initially known ranges on latitude and longitude. While it directly affects the prior probability (which can be viewed by clicking //View more// in the analysis result), the upper bound on posterior probability may change less. Technically,​ differential privacy makes the "​sensitive area" similar to its neighbouring surroundings,​ and not the entire set of possible values, so increasing the range may have little effect on the posterior probability. As the result, if the advantage level is kept the same, increasing the range may also increase the error.   * Try to increase and decrease the initially known ranges on latitude and longitude. While it directly affects the prior probability (which can be viewed by clicking //View more// in the analysis result), the upper bound on posterior probability may change less. Technically,​ differential privacy makes the "​sensitive area" similar to its neighbouring surroundings,​ and not the entire set of possible values, so increasing the range may have little effect on the posterior probability. As the result, if the advantage level is kept the same, increasing the range may also increase the error.
sql-derivative-sensitivity-analyser_demo.1559393267.txt.gz · Last modified: 2019/10/01 13:53 (external edit)