{"id":3290,"date":"2010-03-29T05:47:39","date_gmt":"2010-03-29T12:47:39","guid":{"rendered":"http:\/\/palblog.fxpal.com\/?p=3290"},"modified":"2010-03-29T10:33:12","modified_gmt":"2010-03-29T17:33:12","slug":"toward-pragmatic-definitions-of-privacy","status":"publish","type":"post","link":"https:\/\/blog.fxpal.net\/?p=3290","title":{"rendered":"Toward pragmatic definitions of privacy"},"content":{"rendered":"

The success of de-anonymization efforts, as discussed here<\/a>, suggests that older anonymization methods no longer work, especially in light of the large amount of publicly available data that can serve as auxiliary information. The quest to find suitable replacements for these methods is ongoing. As one starting point in this broader quest, we need useful definitions of privacy.<\/p>\n

It has proven surprisingly difficult to find pragmatic definitions of privacy, definitions that capture a coherent aspect of privacy, are workable in the sense that it is possible to protect privacy defined in this way, and are sufficiently formal to provide means for determining if a method protects this type of privacy and, if so, how well.<\/p>\n

The best attempt to date is the notion of differential privacy<\/em><\/a>. Informally, differential privacy ensures that adding your data to a database will only negligibly impact your privacy. More formally, suppose K<\/em> is a randomized mechanism for information release. In other words, K<\/em> is a randomized function from a set of databases D<\/em> to the set of information releases S<\/em>. For example, D<\/em> might be the set of all possible databases containing weight information on people and K<\/em> takes the average of all of the weights contained in a database d<\/em> in D<\/em>, adds noise, and releases this noisy average. A mechanism K<\/em> is said to be differentially private<\/em> if, for every subset s<\/em> of S<\/em>, the probability that K<\/em> outputs an element of s<\/em> upon input of a database d<\/em> is close to the probability that K<\/em> outputs an element of s<\/em> upon input of any database d’<\/em> that differs from database d<\/em> in one row. Specifically, for all s<\/em> in S<\/em> and for all databases d<\/em> and d’<\/em> differing in one row, the ratio of Pr[K(d) <\/em>in s] <\/em>and Pr[K(d’) <\/em>in s]<\/em> is bounded by e^\u03b5, where \u03b5 is a privacy parameter. A smaller \u03b5 provides greater differential privacy.<\/p>\n

An important aspect of this definition is that merely defines a notion of privacy, it does not specify a means for attaining it. A variety of mechanisms for attaining differential privacy are now known, and developing further methods is currently an active area of research.<\/p>\n

Another significant property of this definition is that it makes no claim as to whether a person’s privacy will be hurt by the release. It only guarantees that a person’s privacy won’t be harmed much more by participating than by refusing to contribute her data.<\/p>\n

This definition certainly nicely captures one type of privacy. That it has led to the discovery of a variety of mechanisms for preserving this type of privacy means that it is also a useful definition. These mechanisms, and the notion of differential privacy no matter how it is attained, put stringent requirements on the amount and type of information that can be released. At the IPAM data privacy workshop<\/a> I attended, opinions ranged from a belief that differential privacy was completely inadequate and would never be adopted in real world cases to a belief that differential privacy was not only the only reasonable definition we currently have, but also the only reasonable one we are ever likely to have. I’ll probably ramble on in a future post about my thoughts on this subject. In the meantime, I’d be curious to hear initial reactions to this definition of privacy from readers of this blog.<\/p>\n","protected":false},"excerpt":{"rendered":"

The success of de-anonymization efforts, as discussed here, suggests that older anonymization methods no longer work, especially in light of the large amount of publicly available data that can serve as auxiliary information. The quest to find suitable replacements for these methods is ongoing. As one starting point in this broader quest, we need useful […]<\/p>\n","protected":false},"author":13,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[147,185,58],"tags":[189,190],"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/blog.fxpal.net\/index.php?rest_route=\/wp\/v2\/posts\/3290"}],"collection":[{"href":"https:\/\/blog.fxpal.net\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.fxpal.net\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.fxpal.net\/index.php?rest_route=\/wp\/v2\/users\/13"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.fxpal.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=3290"}],"version-history":[{"count":24,"href":"https:\/\/blog.fxpal.net\/index.php?rest_route=\/wp\/v2\/posts\/3290\/revisions"}],"predecessor-version":[{"id":3298,"href":"https:\/\/blog.fxpal.net\/index.php?rest_route=\/wp\/v2\/posts\/3290\/revisions\/3298"}],"wp:attachment":[{"href":"https:\/\/blog.fxpal.net\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=3290"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.fxpal.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=3290"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.fxpal.net\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=3290"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}