Next, we present the design of the Fuzz system, which represents one specific point (the lower left quadrant) in the solution space from Table3.1. This point is a good first step because it works with existing programming-language technology and is relatively easy to implement.
3.5.1 Overview
Fuzz consists of three main components: a simple programming language, a type
checker, and apredictable query processor. The programming language rules out chan-
nels based on global state or side effects, simply by not supporting any primitives that could produce either. The type checker rules out budget-based channels by statically checking queries before they are executed and rejecting any query that can- not be guaranteed to complete with the available balance. Finally, the predictable query processor closes timing-based channels by ensuring that each microquery ter- minates after very close to exactlya specified amount of time. Figure 3.4 illustrates our approach.
Network Querier Database Type checker Admission control Predictable query processor Fuzz runtime Privacy budget
Figure 3.4: Scenario. Queries are first type-checked by Fuzz and then executed in predictable time.
3.5.2 Language and type system
Fuzz queries are written in a simple functional programming language whose func- tionality is roughly comparable to PINQ. The Fuzz language contains a special type dbfor databases, which is not a valid return type of any query. We say that a primitive
iscritical if it takesdbas an argument. Our language ensures that critical primitives
either return other values of type db (and nothing else) or add noise to all of their return values. Fuzz determines the correct amount of noise to add by using the sensitivity analysis and type system from (Reed and Pierce,2010).
Fuzz currently supports four critical primitives (Table3.2): mapapplies a function f to each row in one database and returns the results in another database; split applies a boolean predicate p to each row in a database and returns two databases, one with all rowsrfor which p(r) =trueand the other with the rest;countreturns the (noised) number of rows in a database; and sumreturns the (noised) sum of all the rows. sum’s type ensures that it can only be applied to databases with numeric rows.
3.5.3 Predictable query processor
To close timing channels, the query processor must ensure that all critical primitives take a predictable amount of time that depends only on the size of the database. This
is trivial forsumandcount. However,mapandsplitinvolve arbitrary microqueries, and it can be difficult to statically analyze how much time these will take.
To avoid the need for such an analysis, Fuzz instead relies onpredictable transac-
tions. A predictable transaction is a primitive p-trans(λ,a,T,d), where λ is a func-
tion, aan argument, T a timeout, and d a default value. p-trans takesexactly time T, and returns λ(a) if λ terminates within time T, or d otherwise. Note that an implementation of p-trans may have to (a) add a delay if λ terminates early, and (b) abortλ slightly before T expires to ensure that any resources allocated byλ can be released in time. In Section 3.6, we describe two approaches to implementing
p-transin practice.
When evaluatingmaporsplit, Fuzz invokesp-transfor each microquery, using the specified timeoutT and—in the case of map—the specified default value (split has an implicit default oftrue).
All values of type db internally have representations of the same size, i.e., they consume the same amount of memory and (conceptually) have the same number of rows as the original database. If necessary, they are padded with dummy rows. For example, if the original database has 1,000 rows and consumes 1 MB of memory, the two databases returned by a split both consume 1 MB, and an invocation of mapon either of them will invoke 1,000 microqueries—though of course the results of microqueries on dummy rows will be discarded.
3.5.4 How Fuzz protects privacy
We now briefly summarize how Fuzz protects against covert channels. First, the only observations a querier can make that depend on the contents of the database are the completion time of the query and its return value. This is because of (a) our threat model from Section3.3.1, (b) the fact that the language contains no primitives with side-effects, such as mutating global state, and (c) the fact that the type system rules out abnormal termination.
Second, the return value of the query is differentially private. Since db is not a valid return type and critical operations return only values of typedbor else appro- priately noised values (based on the sensitivity that has been statically inferred (Reed and Pierce, 2010)), the return value cannot depend on non-noised values from the database directly. Also, the language does not contain any primitives for observing side-effects within the query, such as memory consumption or the current wallclock time. The only time-related primitives are the timeouts on the microqueries; these have a sensitivity of 1 because (a) each microquery operates on only one row from the database at a time, and (b) microqueries have no access to global state and therefore cannot communicate with one another. Thus, if we add or remove one individual’s data from the database, this affects only one row, so this can only cause one more (or less) microquery to time out and add a default result to the output.
Third, the completion time of a query depends only on the size of the database (which we assumed to be public) and data that has already been noised. To see why, consider that the only operations that have access to non-noised data are the microqueries, for which Fuzz enforces a constant runtime (by aborting or padding them to their timeout), and that values of type db cannot affect the control flow directly, only indirectly through return values of critical operations, which are noised. It is perfectly OK for the completion time of a query to depend on noised data, since such data is safe to release and could even have been returned to the querier directly. In summary, Fuzz is designed to ensure that everything observable by the querier—whether directly through the data channel or indirectly through the timing channel—either does not depend on the contents of the database or has been noised appropriately.