Posts Tagged ‘Privacy protection’

Do government agencies know enough about the limits of anonymization?

Monday, January 18th, 2010 by Don McIntosh

There is a new wave of open government data scheduled to crash over the US on January 22 resulting from the government’s Open Government Directive. Is the government paying enough attention to data privacy issues that this deluge could trigger, and how aware are agencies of the well-established fact that anonymizing data is often an inadequate means of protecting privacy in public sector information, and that in many cases more “scrubbing” of the data is needed before any part of it can be safely released for public use?

Until recently, many government agencies have not been motivated to provide data transparency. Compared with the work that directly aligns with their mission and funding being a visionary supporter of the principles of transparent government is not really high on the agenda. In fact, in many cases, the message from up high hasn’t really reached them at all (one senior US government official’s take on Gov 2.0 was “oh, that’s a subset of Web 2.0 isn’t it?”). If you add to this reluctance the quite significant disincentives such as the risks of being too transparent, inadvertent privacy breaches, and plain and simple costs, then it’s not surprising that the average department hasn’t been as enthusiastic as the Gov 2.0 activist community might like them to be. And if the ROI on the whole deal is often external, why bother?

Well, there’s nothing like a directive straight from the top to get things moving. As of December 8, U.S. federal agencies had 45 days to get three “high-value datasets” published online and available through data.gov. Wow! Having worked with national statistics agencies for many years, I have some grasp of how long they typically take to publish data and it’s often longer than this, especially when you are dealing with data that has not previously been published. Of course, the data in some cases might be basic lists of non-sensitive material, in which case perhaps it is not too much extra work to make it suitable for public access. What I’m interested in examining is what it will take for agencies that don’t have it that easy, who will need to derive statistics from their data, or reduce it in some way to make it “safe” for public consumption.

Firstly, why bother publishing statistics if the raw data is available? Isn’t the open data community interested in getting “raw data now”, so that it’s quick for the agency and promises maximum flexibility for users? The reality in many cases — and one that seems to still be ignored by some who work in Information Management — is that even after you “de-identify” data by stripping obviously identifying attributes from it such as names, addresses, SSNs, etc, it does not necessarily protect privacy. It can still be a fairly trivial exercise for an ill-meaning data analyst, or even a non-technical person in many cases, to re-identify many of the people in the list. That is why in many cases we’ll see statistics being released about the data, rather than the raw data itself.

Associate Professor of Law Paul Ohm from the University of Colorado released a paper about the “Surprising Failure of Anonymization” last year, citing some prominent cases where anonymized data was re-identified and pointing out that there are many laws and regulations that are based on the false assumption of anonymization being a panacea for data privacy protection. In one example he describes, a researcher demonstrated how 87.1% of people in the U.S. were uniquely identified by their combined ZIP code, birth date, and sex. He also covers the AOL search data scandal, where individuals were identified from vast volumes of data by their unique search habits, uncovering some embarrassing personal information along the way.

While the individual agencies may not all have a clear understanding of all the potential privacy issues related to open data, at least the federal administration does have a focus on this. The directive itself states that data can only be made available “subject to valid privacy, confidentiality ….. restrictions”. In addition, the “Concept of Operations” paper for data.gov does have privacy in its sights, stating that there will be working groups looking into privacy issues arising from how data is mashed up and/or used in applications. I would point out that these groups could make an early head start simply by reading Paul Ohm’s paper, and not wait until after this round of data has been released. It seems that for the moment at least, the idea of what constitutes adequate privacy protection for open data is really up to each agency to decide.

While the working groups deliberate how privacy issues that result from data mashups and the like should be addressed, many datasets will be posted to data.gov and despite the proven limits of the effectiveness of anonymization, the experience that my colleagues and I have gained from talking with people who work in Information Management in government is that key staff in at least some agencies are not sufficiently aware of this, and that in their view, anonymization is essentially all you need to do to make data safe for release. I’d be interested to know if this agrees with others’ observations.

My observation regarding government’s understanding of data privacy issues is based largely on anecdotal evidence collected by myself and my colleagues. Perhaps I am overstating things and agencies do have the required skills and knowledge to release data safely. It would be good to hear about how different agencies are dealing with the Open Data Directive and what you think about the challenges of releasing useful data without unduly compromising privacy.

Note: Ohm’s paper is fairly lengthy. For a very interesting summary of the paper, you can check out this post on ars technica, which sparked a lot of debate regarding the importance of privacy.

Protecting confidentiality - some real life examples

Sunday, November 1st, 2009 by Don McIntosh

This post blog is on how we are enabling our customers to disseminate detailed information while protecting the privacy of individuals. In the context of being providers of Official statistics, making data more available, and making governments more transparent, we show that it *can* be done - you *can* release data.

We are currently engaging with three customers and developing new requirements around the area of privacy protection on their data. For two of the three, the main goal is to deliver more detailed, useful data to their customers without compromising privacy concerns. The other key goals are around reducing the risk of accidentally releasing sensitive data (a goal of increasing importance given the Gov 2.0 fueled demand for more open data), and reducing costs associated with the application of privacy protection. I thought I’d write a short note to summarise our work in this area of late.

We have an API plugin architecture for applying disclosure control. Basically, you can build your own modules that do things like adjust, conceal, and/or annotate cell values based on certain rules, or reject a query if it’s deemed too sensitive for whatever reason. You can also record query details and use them to monitor for potential privacy intrusions.

The work we are looking at doing in relation to current customer requests includes the following:

  • Implementing plugins with customised rounding and concealment rules. This is straight forward work as far as our current architecture is concerned, and helps our customers with these requirements to implement rules that maximise the data they can make available. For one customer, we have written a plugin that will suppress numbers less than a certain value, and any related totals. So for example, if you were suppressing all numbers in a table less than or equal to 3, a simple table would show suppression of that cell, plus any totals containing that cell. The example table demonstrates how a returned table would look. By suppressing the totals, you are preventing someone from back-calculating a value that has been suppressed.
Suppressed Table

Suppressed Table

  • Allowing custom selection of different rule combinations for testing and more advanced use of disclosure control. This is useful especially where you have a few in-house specialists who are authorised to be more lenient in terms of what rules need to be applied when responding to ad hoc information requests.
  • Extending confidentiality to apply to the output of calculations (SuperSTAR field derivations). For example, you might have a function that in some cases returns “..C” instead of a real value for certain cells as per the example above. Confidentiality can be extended to work with derived data. For example, it would be useful for determining a statistical mean or median and concealing the result if there was less than a certain number of contributors.

We are really keen to hear from our customers and other interested parties. If you have some recent experience in using confidentiality in SuperSTAR or elsewhere, or would like to give us any kind of related feedback, please do feel free to leave a comment or contact us directly.

Why APIs are important for Gov2.0

Wednesday, October 21st, 2009 by Jo Deeker

I was at the Gov 2.0 conference in Canberra earlier in the week and found that compared to the talk around social engagement through Twitter and Facebook, the whole concept of open data and APIs took a back seat for much of the event. APIs were mentioned by speakers, but I did not get any sense that the majority of the attendees were thinking about APIs and mash-up-ability of data as much as I do. I also wasn’t sure that everyone knew what an API was, or why you would want one.

So we asked our Director of Product Planning, Don McIntosh to write an article about what APIs are, and why they’re important. This is what he has to say about APIs.

With social applications, there is a clear and obvious use that everyone can understand, and the staggering traffic volumes for these sites make the topic all the more compelling. But what about open data and APIs? Why should we pay them any attention and how do we benefit from them?

An API is an Application Programming Interface. Web based APIs, sometimes referred to as Web services, are growing at a phenomenal rate. Basically, instead of information being presented in a predetermined manner through Web pages, APIs allow other applications (iPhone apps, Websites, MS Windows applications….) to extract specific chunks of information and combine it with other information in all kinds of ways to serve a specific purpose. Jim Ericson from Information Management blogged about this, and he included a good description of how Web services get used:

“Now think of all the thousands of iPhone apps and how they amalgamate all kinds of Web services. You open your commuter traffic app, it calls on traffic information services, Google maps, a weather forecast and maybe an ad for public transportation. One browser app, many (API) calls.”

Jim also mentioned how prominent APIs are becoming. For many popular websites, the network traffic generated by APIs actually exceeds the direct Web traffic. And that’s expected to continue. Perhaps even more interesting is the fact that these days, you don’t even need to be a programmer to use Web APIs. If you have played with Yahoo Pipes, or similar mashup tools, you know what I mean. Basically, these tools are empowering end users to create their own custom applications. Just drag and drop – no coding required.
So, they’re useful, widely used, accessible even to non-programming types, and becoming more popular by the day but what in particular makes them so important in a Gov 2.0 context? I’d summarise it by saying that it’s about making it possible (and easy) for those outside of government to present statistics in a context that is meaningful and useful for them, and that can help facilitate informed discussion and decision making. If I want to provide a service to help people decide where to live, I could combine census statistics such as occupation, income, and age and mash it up with information about the location of shopping centres, pubs etc from a different service. I could achieve the same by gathering all the data into a database and building my service on top, but by accessing the data through an API, my information can remain current, and my queries can be run by calls to the API, saving me from the complexities and resources required to process the data myself. I can also leverage other services such as Google maps to present results. And of course, thanks to mashup platforms, this kind of application might just be something that an (non-programmer) individual does to satisfy their own interest. Either way, it makes it much more possible for people to take government information and use it in ways that government may never have chosen to do.

From a data provider’s perspective, there are many things to consider when looking at providing APIs for direct data access and querying.

1. API vs other means

An API can facilitate innovation, and help automate services that other organizations may provide based on the data. It can also provide transparency by not colouring the data in any particular way, but leaving it open to others to render analysis of the data in their own way. On the other hand, if representing the data in certain ways is useful in promoting an organization’s mission, then it might be best to concentrate on delivering the appropriate views and/or viewing tools for the data. Or in some cases, it might make sense to do both.

2. Risk of abuse

Gartner analyst Andrea diMaio noted that separating data from its source and having no clear way to let consumers understand its lineage or quality runs a great risk of it being misused, or deliberately doctored to represent the “facts” that best suit the application builder. What does this mean to the organization providing the data? Providers of official statistics go to great lengths to defend against this possibility yet by providing data through APIs, they may in some way increase the risk of this happening. Perhaps one way to look at it is to realise that this can happen anyway, without APIs. And it is probably unreasonable to expect a provider to do more than provide accurate quality information alongside their data (and even make it queryable through the API) so that users can make informed choices about what constitutes valid use of the data.

3. Data privacy protection

Many statistical agencies have “remote access data laboratory” services to give researchers the ability to perform detailed analyses on their data. There are typically manual checking processes in this, to ensure that researchers’ queries do not breach data privacy laws by identifying individuals from the data (something that is very easy to do, even when data has been anonymized). A provider would need to determine what privacy risks are posed by making the data available through an API, and ensure that appropriate safeguards are put in place.

4. Resources

An API call results in some amount of processing. Depending on the specifics, such as the type of query and the volume of data, the level of computing resources required can be quite significant. In the beginning, one option may be to limit API use to a few specific applications, and expand that over time. Alternatively, the API could impose certain limits for any single user. This is the approach that Twitter uses to manage the enormous demand it generates.