This is an old revision of the document!
SQL guessing advantage analyser has a a user-facing frontend application that allows to extend models by attaching SQL scripts to its elements. SQL queries are added to tasks and SQL database information added to data objects. SQL information is attached by adding specific labels into the XML code of the model. The editor uses SQL guessing advantage analysis tool to perform an analyze on the extended model to combine and present the results. Editor and analysis tool have separate codebases, but they are both required to use the full functionality of the analyser. Communication between the two components is arranged by backend REST service.
We interpret differential privacy in terms of a more standard security measure – the attacker's guessing advantage. It is defined as the difference between the posterior (after observing the output) and prior (before observing the output) probabilities of attacker guessing the input. The analyser reports the amount of noise that need to be added to achieve a desired upper bound on advantage.
Compared to 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). In addition to the error level confidence slider that we have in combined sensitivity analyser, there is another slider allows to set desired upper bound on attacker’s advantage, which ranges between 0% and 100%.
The user has to specify the attacker's goal. Similarly to combined sensitivity analyser, user can define constraints on table attributes that are known in advance. There are two buttons for this.
The syntax for table constraints is the same as for combined sensitivity analyser, with some extensions. The keywords total
, set
and range
do not specify any probability distribution on the data, and the analyser assumes worst-case distribution by default (i.e. one for which the advantage is the largest). The keywords totalUnif
, setunif
, rangeUnif
in addition specify that the distribution is uniform. To provide even more distribution details, setPrior
allows to define a probability for each element, and rangePrior
allows to split a range into n blocks, defining a different weight to each block (inside each block, the elements are distributed uniformly).
table_1.attr_1 exact; --attacker knows the exact value table_2.attr_2 total int; --there are n possible values table_3.attr_3 set v1 ... vn; --there are values {v1 ... vn} table_4.attr_4 range lb ub; --the values come from range [lb,ub) table_5.attr_5 totalUnif int; -- there are n uniformly distributed values table_6.attr_6 setUnif v1 ... vn; -- uniformly distributed in {v1 ... vn} table_7.attr_7 rangeUnif lb ub; -- uniformly distributed in [lb,ub) -- value vk comes with probability pk table_8.attr_8 setPrior (v1, p1) ... (vn, pn) -- range [v(k-1)...vk) comes with prob.pk -- the values within [v(k-1)...vk) are distributed uniformly table_9.attr_9 rangePrior v0 (v1, p1) ... (vn, pn)
Attacker goal is given in form of an SQL guery. 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). It is possible to combine several attributes into a vector and define approximation w.r.t. some l_p-norm as approxWrtLp(p)
and approxWrtLinf
. The guesses can be combined into an expression using AND and OR operation, describing the case where leakage is considered successful. The filter WHERE condition
describes which rows of the considered tables are treated as sensitive. The delimiter ;
finishes the description of the attacker goal.
SELECT (t.x, t.y) approxWrt(5) AND t.z exact FROM t WHERE t.b;
In this example, the attacker wins iff he guesses both t.z
exactly and (t.x,t.y)
within 5-unit precision w.r.t. l_2-norm of any row of the table t
where t.b
holds. 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.
If we want to express that the attacker wins if he guesses either t.z
or (t.x,t.y)
, we replace AND operation with OR.
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 combined sensitivity analyser.
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.
The source code of SQL guessing advantage editor is available at pleak-sql-guessing-advantage-editor and the source code of SQL sensitivity analysis tools at pleak-sql-analysis repositories. Installation details can be found at analyser installation guide.