Another post about differential privacy
In the wake of Apple’s announcement that they incorporating differential privacy in many of the Apple products, I think it’s high time to continue my quest to have a firm grasp on differential privacy. I wrote an introductory note on differential privacy in my old blog , but it was over 3 years ago. One could be forgiven in thinking that I should have become an expert by now. Yeah, no.
It was typical Apple not disclosing any information that would have justified the move as visionary, and that would also have satisfied many security researchers. There are two ways to see it, and they are not mutually exclusive. First, it’s testament to how the technology has matured that it would soon become the norm. Second, there are tremendous risks in adopting this technology without transparency, as it is teemed with non-technological trade-offs. The most important consideration is how to trade privacy for utility. Of course the fact that Apple even bring this consideration into a table is hugely encouraging, but this effort would be but all for nothing if they did not make their decisions public. It is essential for the users to understand the risks before sharing, and concealing them would completely offset the benefit of differential privacy.
Though papers on differentially private algorithms and mechanisms still fill me with dreads, I have started to comprehend and appreciate some of the very cool properties of differential privacy, thanks to two awesome lecture notes I found online [2, 3]. The rest of this article I will try to articulate these properties as much as I understand them.
Differential privacy is only applicable to randomized algorithm ( can be a probability space, hence the correct formula is ). It means applying on the same input will give different results, based on the whatever randomness embedded in (or its coin toss). It’s easy to image that is the database of rows, and is the space of vectorized results .
Ideal privacy. We want to not reveal information about a given individual , given arbitrary auxiliary information. This means publishing the result of does not violate any privacy. This, however, is impossible to achieve. A counter example is that is an associate professor, and on the database of university staff reveals that an average salary of an associate professor is (approximately) . Thus, we know that salary is in average — new information being revealed as the result is published.
Relaxed (differential) privacy. The ideal privacy is impossible, meaning that performing an analysis task on the data inevitably leads to leakage. Differential privacy attempts to relax the requirement in order to beat the impossibility result. It requires analysis result to be almost the same whether is in or not. It means that can opt out of the analysis without affecting the result. It also means that ’s privacy is not decreased if she is in . Hence the name differential.
Formal definition. Algorithm is -differentially private if for all and where and differs by at most 1 entry, then:
Different notations. Equation can be expanded or re-written as in the following ways:
- When is small, . Thus:
- Because , we have:
Differential privacy written in Equation (3) be stated as: the probably of outputting the same value given the input is similar to that given the input .
Privacy budget The value is called privacy budget, which embodies the differences between two output distribution of the algorithm. This can be viewed as the amount of privacy violation allowed by the user, and the algorithm must work within this amount. Large budget means large differences between the two distribution is allowed. Strong level of differential privacy means small budget.
The formal definition (Eq. 2) expresses the bound of leakage in information theoretic sense, which is useful in most statistical analysis. Most mathematicians or statisticians can work comfortably with this definition. For people coming from a security background like me, a definition based on a security game would be easier to grasp. And I was glad to finally find such a definition in . It was truly refreshing seeing the same problem in a new light.
The game, as usual, involves a challenger (Alice) and an adversary Bob. It proceeds as follows:
Alice generates .
Alice sends , and to Bob.
Bob guesses .
Bob wins if it can guess correctly with a probability greater than a random guess.
The winning probability of Bob is the level of privacy decrease that suffers, i.e. the advantage the adversary would have had in identifying in the dataset. We can prove that if is -differentially private, the probability of Bob winning the above game is bound by .
For simplicity, let and for . Furthermore:
(A1) Alice chooses by flipping an unbiased coin, i.e. .
The best guessing strategy by Bob is maximum likelihood estimation, i.e.
Combining Eq.4 with assumption A2 gives us .
Eq.5 suggests that if is small, so is the leakage. In particular, if for a negligible function , the definition reduces to the indistinguishibility notion found in traditional cryptography. In practice, however, is quite substantial (in the range of ) for the analysis to be useful. Thus, there is a real risk of decrease in privacy when an individual is included in the data.
The definition of differential privacy implies three key properties that are instrumental in designing differential private systems.
When a differentially private algorithm (analysis) is run times over the same dataset, the privacy deteriorates. The consequence is that if the analyst doesn’t want the privacy to get worse (and eventually lost), he should bound the number of runs. Publishing the result is a special case when the analysis is done once then the data is discarded.
Formally, let for be independent -differentially private algorithms. Then the algorithm made up from a sequence of , i.e. is -differentially private.
Proof. For any sequence of , and and different by at most 1 entry, we have:
Recall that is called privacy budget, and the lower it is the better for privacy. An implication of composition is that every time you make a pass through the data with a -differentially private algorithm, the overall privacy budget is decreased by . A common practice is to fix the budget at the beginning and ration it out to sub-analyst tasks. For example, let be consists of a sum () and a product () operation over the data. Suppose the user wants differential privacy with budget , then we can design with budget and with budget . There is no privacy guarantee after running . Once the budget is exhausted, discard the data.
Note that sequential composition property considers multiple algorithms computing over the entire dataset. When different algorithms touch different part of the data, then we have better bounds in terms of privacy budget. An example is the algorithm computing the histogram of the data, which is essentially a set of range count queries over disjoint ranges. More specifically, consider consisting of 2 fields: Smoker (Y/N) and Age (0..120). Then the histogram of the numbers of smokers for different ages can be constructed by executing count operations over range [0..10), [10,20),… The count operations touches different parts of , i.e. removing one entry would change the result of only one query.
Formally, let be the partitions of the original data. Let be algorithms working on the corresponding partitions, and is -differentially private. Then the algorithm is -differentially private.
Proof. Consider and differing in at most 1 entry. Without loss of generality, assume the difference is in the first partition, i.e. and .
Histogram algorithm can be made differentially private with very low budget because it works on partitioned data. The budget is independent of the unit width. For example, if the count query is -differentially private, any histogram producing either bar or bars are -differentially private.
How the result of a differentially private algorithm is used does not affect individual privacy. Note that this post processing — applying another algorithm on the result — is different to sequential composition of different algorithms. Post processing does not compute over the data, but sequential composition does.
Formally, let be a post-processing function. If is -differentially private, then is also -differentially private.
Proof. For any , let such that . For any two differing in at most one entry:
This property is significant to the practicality of differential privacy. It basically says that if you perform an analysis whose results can be reused in future analysis, user privacy is not affected by the future analysis. Thus the data can be safely thrown away. Take histogram as an example. Initial histogram computation may incur an privacy budget. Once done, however, any useful function (arbitrary range count queries) can be done over the histogram without changing the initial privacy budget. A more complex example is linear regression , which publishes -differentially private objective (loss) function. The process of optimizing the function is complex (SGD algorithm), but the final regression result will still preserve differential privacy.
The key take away from this property is that: in designing a differential private mechanism, look for a simple pre-processing step that can be done with small privacy budget. It’s better to shift complexity to the post-processing step.
One minor property that I don’t want to leave out is group privacy. What happened when the data is changed by more than 1 entries. This makes sense in settings where data entries are related to each other, and removing one also removing the other.
The main result is that if the user want privacy for a group of rows, he must assign a bigger privacy budget, i.e. times bigger for group of .
Formally, Let be -differentially private for two datasets differing in 1 entry, then is -differentially private for two datasets differing in entries.
Proof. Let be datasets in which and differ in entries. Furthermore, and differs in 1 entry.
The definition above states the conditions which a randomized algorithm must satisfy for it to be considered differentially private. Also, any differentially private algorithms will enjoy the three properties: sequential composition, partitioning and immune to post-processing. Here, I will discuss how to design such in practice. Given an algorithm , the goal is to transform it to a differentially private version with a privacy budget of . The transformation is done by adding carefully crafted noises to the output of . So far, is being restricted to classes of rather simple algorithms, for the main difficulty is to maximize the utility of for a fixed budget . I wouldn’t be too surprised if there is (or will be) an impossibility result claiming that there are certain classes of not amenable to differential privacy.
In any analysis task, there are two steps: data collection and analysis. The second step can be repeated many times. In practice, there steps are combined in two different system models. In the first, there is a trusted party who collects the data and answers queries on a differentially private manner. In the second, no trusted party is assumed, thus the data collection process must be made differentially private. Note that in this case, all subsequent analysis on the collected data is differentially private (due to the post-processing property).
The figure shows three typical models for deploying differential privacy in practice. They differ mainly in which entities are considered trusted (blue), which leads to different places to enforce differential privacy.
No trusted curator
In this settings, data owners have to make sure their data is differentially private before sending it to the curator. The idea is to add noise in order to hide the true value.
Randomized response is an algorithm having been used by social scientists for very long time. Assume the data is a binary value (0 or 1). The algorithm proceeds as follows
- Flip a coin. If it comes up head, answer the true value.
- Else, flip another coin and answer Y if head and N if tail.
This algorithm is -differentially private, for the following:
The partitioning property can be applied here, to ensure that if all data owners follow the same algorithms, then the combined published data is -differentially private. More important, the post-processing property is also applicable here. As a consequence, any subsequent analysis on the data procured by is -differentially private. Note that the analysis must account for the error in the data: the probability of a randomized response returning the true value is only . One way to mitigate to lower the analysis error is to collect more and more data so that important patterns can eventually appear.
Google is employing this approach in their system called RAPPORT  which collects data from Chrome users about their settings and preferences. The main challenges addressed in RAPPORT is how to offset the error due to randomized response, for which the system uses hashing, Bloom filter and complex statistical techniques for the analysis. If I have to bet on what Apple is doing with differential privacy, with words like hashing being passed around, I’d go for the same approach like RAPPORT. But one caveat is that RAPPORT aims for data which rarely changes or changes very slowly. How would Apple modify it for fast-changing data like philological, locational data will be interesting to see.
Although randomized response is intuitive and can offer a reasonable amount of privacy, its major drawback is poor utility (only 75% chance of a published value being the true one). Thus, the analyst (curator) will have to work with inaccurate data. By trusting a curator in not leaking the data and only computing differentially private function, the analyst can get more accurate results.
Interactive vs. non-interactive. Interaction between the curator and analyst can be interactive (a) or non-interactive (c). In the former, the curator exposes an interface to which the analyst can issue queries. Like a database, the curator takes a query, computes and returns the result. This approach, however, is limited by the sequential composition property. In particular, each query consumes a certain amount of the overall privacy budget. Suppose the user only allows for a budget of , and there are queries (count, sum, average, etc.), for each query the curator must perform a -differentially private algorithm such that . When another query comes and there an left, the curator can refuse the query, or accept it and perform the query with tight budget (which often lead to highly inaccurate result).
Designing an interactive system like the above is highly complex, as it involves managing the budget and perhaps predicting the future queries. A more interesting approach is to leverage the post-processing property of differential privacy: the curator publish a single representative function of the data, like histogram. Unlike the interactive case, there is only one operation over the data, hence the privacy budget can be fixed to a very low value. A function like histogram can output very useful result to be used by other queries (range queries, counts, etc.). A majority of papers I read on differentially privacy algorithm focus on this non-interactive settings. There is even a framework, called DPBench, for benchmarking these different non-interactive algorithms .
Laplace noises For a numerical algorithm , the most common method to make it differentially private is to add noises drawn from a zero-centered Laplace distribution.
More formally, let be the global sensitivity of . represents the maximum change ’s output when the data is changed by one item. Let where the Laplace distribution has mean. Then the algorithm is -differentially private.
The proof for this can be found on Wikipedia. For some algorithms, like count and average, this mechanism introduces noises not too large for the outputs to be useful. Lots of research effort have been trying to minimize the overall noise by means of minimizing .
Complex algorithms Note that Laplace method is applicable to numerical algorithms. Many other algorithms do not output simple numbers. For example, machine learning algorithms produce models which are often sets of parameters in a complex, non-convex function. One way to make them differentially private is to add noise to the model parameters. But reasoning how much noise to be added is hugely challenging, because the parameter sensitivity to the input/training data is difficult to analyse. Another way is to make the objective function differentially private, as opposed to the model itself. In fact, the model essentially estimates the objective function’s local minima. The process of training the model (SGD) then can be considered as post-processing step and therefore omitted in the privacy analysis. This is a huge reduction in complexity, but the remaining step of making the objective function differentially private is by no means trivial.
As a consequence, state-of-the-art studies in differentially private machine learning are restricted to a simple set of machine learning models: linear classifier, decision tree, regression, etc. As deep learning is rapidly becoming the norm, differential privacy for deep learning models could become the new focus of the field, especially considering how much data needed for training the models.