Table Servers: Protecting Confidentiality in Tabular Data Releases

Introduction. Federal statistical agencies must balance concern over confidentiality of data with their obligation to report information to the public [5]. Advances in information technology threaten confidentiality, but also new technologies can protect confidentiality while meeting user needs in innovative ways. Here we describe table servers being developed by the National Institute of Statistical Sciences (NISS) that disseminate tabular summaries of statistical data in response to user queries for marginal sub-tables of a large (e.g., 40 dimensions with 4 categories each) contingency table containing counts or sums. Table servers evaluate disclosure risk dynamically, in light of previously answered queries. Abstractions. The query space Q, which contains all 2K sub-tables of a K -way table, is partially ordered by set inclusion of variables in subtables. The set R(t) of all tables released through some time t contains direct releases in response to queries and indirect releases (previously unreleased children of direct releases); R(t) is specified by the released frontier RF (t) of its maximal elements (Figure 2). Underlying dynamic release decisions is a risk criterion RC defined on subsets of Q: at all times the system must satisfy RC(R(t)) ≤ α, where α is a risk threshold set by the operators. A typical risk criterion is accuracy of bounds based on R(t) for sensitive (small count) cells in the full table. Bounds can be computed using network methods [3, 9] and the “shuttle algorithm” [2]. There are also exact techniques for special cases. For example, if the released sub-tables constitute the minimal sufficient statistics of a decomposable graphical model [8] (Figure 1), then bounds can be expressed as explicit functions of these sub-tables [4]. Whenever an answered query releases previously unreleased information, other queries become unanswerable. Consequently (Figure 2), at t there is an unreleasable set U(t) of sub-tables whose release would be too risky, with an unreleasable frontier UF (t) of its minimal elements. Release rules determine which requests for unreleased tables will be fulfilled. The simplest is the myopic rule of releasing T at t as long as RC(R(t) ∪ T ) ≤ α. To prevent the table server from taking excessively large steps, one can allow only tables adding but one variable to a previously released table to be eligible for release. To prevent a single user (or a set of colluding users) from driving the table server into a region of Q that suits their needs but not those of other users, release rules can biased against releases that add large numbers of tables to U(t). Rules can also incorporate the value of releasing T [6, 12].