sql-guessing-advantage-analyser

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

Both sides previous revision Previous revision Next revision | Previous revision | ||

sql-guessing-advantage-analyser [2019/06/05 20:25] alisa [Quick guide] |
sql-guessing-advantage-analyser [2019/10/01 13:53] (current) |
||
---|---|---|---|

Line 11: | Line 11: | ||

Compared to [[sql-derivative-sensitivity-analyser|combined sensitivity analyser]], the data objects of a model also have schemas and data tables, but now there are no explicit table norms. The distance measure for differential privacy will be determined in a different way. | Compared to [[sql-derivative-sensitivity-analyser|combined sensitivity analyser]], the data objects of a model also have schemas and data tables, but now there are no explicit table norms. The distance measure for differential privacy will be determined in a different way. | ||

- | Clicking on //Analyze// button opens a menu entitled //Analysis settings// on the right side of the page (in sidebar). The emerging slider allows to set desired upper bound on attacker’s advantage, which ranges between 0% and 100%. | + | Clicking on //Analyze// button opens a menu entitled //Analysis settings// on the right side of the page (in sidebar). In addition to the error level confidence slider that we have in [[sql-derivative-sensitivity-analyser|combined sensitivity analyser]], there is another slider allows to set desired upper bound on attacker’s advantage, which ranges between 0% and 100%. |

- | {{slider.png}} | + | {{slider2.png}} |

- | The user has to specify a particular subset of attributes that the attacker is trying to guess, within given precision range. To characterize the attacker more precisely, the user defines prior knowledge of the attacker. | + | The user has to specify the attacker's goal. Similarly to [[sql-derivative-sensitivity-analyser|combined sensitivity analyser]], user can define constraints on table attributes that are known in advance. There are two buttons for this. |

- | There are now two extra buttons to define bounds for used attributes. | + | |

- | === Sensitive attributes === | + | === Table constraints === |

- | This input starts with the keyword ''LEAK''. It defines a set of sensitive components, which the attacker is trying to guess. For each sensitive attribute, the guess can either be ''exact'' (discrete attributes), or ''approx r'' (approximated by r > 0 units). The guesses can be combined into an expression using AND and OR operation, describing the case where leakage is considered successful. The expression can be followed by a sequence of statements of the form ''FROM table WHERE condition'', which describes which rows of the considered tables are treated as sensitive. The statements can in turn be followed by a single line containing keyword ''cost'' and a number that defines the cost of leaking that combination of attributes. By default, the cost is set to 100. The delimiter '';'' finishes the description of the sensitive components. | + | The syntax for table constraints is similar to [[sql-derivative-sensitivity-analyser|combined sensitivity analyser]], with some extensions. The keyword ''exact'' states that the attacker already knows some attribute precisely, and ''total'' says how many elements there can be, without specifying their values. More options can be found in [[sql-derivative-sensitivity-analyser_advanced|analyser advanced settings]]. |

<code> | <code> | ||

- | LEAK | + | table_1.attr_1 exact; --attacker knows the exact value |

- | ship.latitude approx 5 AND | + | table_2.attr_2 total int; --there are n possible values |

- | ship.longitude approx 5 | + | table_3.attr_3 set v1 ... vn; --there are values {v1 ... vn} |

- | FROM ship WHERE cargo > 0 | + | table_4.attr_4 range lb ub; --the values come from range [lb,ub) |

- | cost 100; | + | |

</code> | </code> | ||

- | In this example, the attacker wins iff he guesses //both// attributes ''latitude'' and ''longitude'' of some row of the table ''ship'' within 5-unit precision. The definition of "unit" depends on the data table, e.g. if the location was defined in miles, then a unit is also a mile. We only worry about location of ships that carry some cargo. | ||

- | If we want to express that the attacker wins if he guesses //either// ''latitude'' or ''longitude'', we replace AND operation with OR. | + | === Attacker goal === |

- | | + | |

- | === Attacker settings === | + | |

- | This input defines prior knowledge of the attacker by setting pre-known bounds on attributes, defined either as ''exact'', ''range a b'', or ''total a'' (the latter is used only for discrete data). | + | |

+ | Attacker goal is given in form of an SQL guery. It defines a set of sensitive components, which the attacker is trying to guess. Even if the attacker cannot guess the location precisely, it can still be bad even if he guesses the location precisely enough, so we need to introduce approximation. For each sensitive attribute, the guess can either be ''exact'' (discrete attributes), or ''approx r'' (approximated by r > 0 units). The delimiter '';'' finishes the description of the attacker goal. | ||

<code> | <code> | ||

- | ship.latitude range 0 300; | + | SELECT |

- | ship.longitude range 0 300; | + | t.x approx 5 AND |

+ | t.y approx 5 | ||

+ | FROM t; | ||

</code> | </code> | ||

+ | In this example, the attacker wins iff he guesses both ''t.x'' and ''t.y'' within 5-unit precision. The definition of "unit" depends on the data table, e.g. if the location was defined in miles, then a unit is also a mile. | ||

- | In this example, the attacker knows that both ''latitude'' and ''longitude'' range between ''0'' and ''300''. | + | Additional syntax for specifying attacker goal can be found in [[sql-derivative-sensitivity-analyser_advanced|analyser advanced settings]]. |

=== Running analysis === | === Running analysis === | ||

- | Click on //Run analysis// button to run analysis. The analyser internally converts these values to a suitable ε for differential privacy, and computes the noise required to achieve the bound on attacker’s advantage. The results (entitled //Analysis results//) appear in the sidebar as well. The result is given for each of the input tables, and it consists of the following components. | + | Click on //Run analysis// button to run analysis. The analyser internally converts these values to a suitable ε for differential privacy, and computes the noise required to achieve the bound on attacker’s advantage. The results (entitled //Analysis results//) appear in the sidebar as well. The result consists of the following components, which are the same as for [[sql-derivative-sensitivity-analyser|combined sensitivity analyser]]. |

- | Click on //Run analysis// button to run analysis. The results (entitled //Analysis results//) appear in the sidebar as well. The result is given for each of the input tables, and it consists of the following components. | + | |

- | * **Relative error (additive noise / query output)** is the quotient of the additive noise and the query output. It shows how far the differentially private result gets from the actual result. | + | * **actual outputs y** are the true outputs of the query, without noise. |

- | * **Expected cost** tells how much we lose in average if we let the attacker observe the output, in addition to what we had lost if the attacker has not observed the output. | + | * **p%-noise magnitude a** is the additive noise magnitude, i.e. the noise stays below this quantity with probability p%. |

+ | * **p%-realtive error |a|/|y|** is the quotient of the additive noise and the query output. If there are several outputs, it is the quotient of corresponding vector norms. | ||

- | To see more precise values of prior and posterior guessing probabities, click //View more//. This can be useful for choosing appropriate value on the guessing advantage slider. For example, if the prior guessing probability was already 75%, then any value above 25% makes no sense since it would mean that the attacker is allowed to learn everything. | + | To see more precise values of prior and posterior guessing probabilities, click //View more//. This can be useful for choosing appropriate value on the guessing advantage slider. For example, if the prior guessing probability was already 75%, then any value above 25% makes no sense since it would mean that the attacker is allowed to learn everything. Clicking //View more// also provides more information about how the noise should actually be generated, and it does it for Cauchy and Laplace noise distributions. |

===== Source code ===== | ===== Source code ===== | ||

The source code of SQL guessing advantage editor is available at [[https://github.com/pleak-tools/pleak-guessing-advantage-editor|pleak-sql-guessing-advantage-editor]] and the source code of SQL sensitivity analysis tools at [[https://github.com/pleak-tools/pleak-sql-analysis|pleak-sql-analysis]] repositories. Installation details can be found at [[sql-derivative-sensitivity-analyser_install|analyser installation guide]]. | The source code of SQL guessing advantage editor is available at [[https://github.com/pleak-tools/pleak-guessing-advantage-editor|pleak-sql-guessing-advantage-editor]] and the source code of SQL sensitivity analysis tools at [[https://github.com/pleak-tools/pleak-sql-analysis|pleak-sql-analysis]] repositories. Installation details can be found at [[sql-derivative-sensitivity-analyser_install|analyser installation guide]]. |

sql-guessing-advantage-analyser.1559755556.txt.gz · Last modified: 2019/10/01 13:53 (external edit)