This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision Next revision Both sides next revision | ||
sql-guessing-advantage-analyser [2018/11/27 10:49] alisa [Source code] |
sql-guessing-advantage-analyser [2019/09/26 14:01] alisa [Quick guide] |
||
---|---|---|---|
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%. |
+ | |||
+ | {{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 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. | ||
Line 17: | Line 19: | ||
=== Sensitive attributes === | === Sensitive attributes === | ||
- | This input defines a set of sensitive components, which the attacker is trying to guess. The definition starts from a keyword ''leak''. For each sensitive attribute, the guess can either be ''exact'' (discrete attributes), or ''approx r'' (approximated by r > 0 units). The list of attributes is followed by the keyword cost and a number that defines the cost of leaking that attribute. | + | 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. |
<code> | <code> | ||
- | leak | + | LEAK |
- | ship.latitude approx 5; | + | ship.latitude approx 5 AND |
- | ship.longitude approx 5; | + | ship.longitude approx 5 |
- | cost 100 | + | FROM ship WHERE cargo > 0 |
+ | 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. | + | 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 the attacker wins if he guesses //either// ''latitude'' or ''longitude'', we specify it as two distinct sensitive sets, each having its leakage cost. | + | If we want to express that the attacker wins if he guesses //either// ''latitude'' or ''longitude'', we replace AND operation with OR. |
- | <code> | + | |
- | leak | + | |
- | ship.latitude approx 5; | + | |
- | cost 30 | + | |
- | + | ||
- | leak | + | |
- | ship.longitude approx 5; | + | |
- | cost 70 | + | |
- | </code> | + | |
=== Attacker settings === | === Attacker settings === |