Privacy Policies For Local Government?

stinkydog asks: "I am in the interesting position of developing a privacy policy for a parks and recreation department for a urban local government. I have watched with interest all the complaints about government and privacy and don't necessarily want my personal data on a billboard. One the flip side, I need to collect enough data to justify a several million dollar budget. Our management wants usage and regristration data down to the Census Block Group level to make decisions. We currently gather name, address, phone and age. For some Federal programs we also gather income level and number of childern in the home. If I put all this info in the same database am I providing good customer service or being intrusive? Where should I draw the line? I have been charged with creating an understandable, user-friendly policy on what we collect and how we use it (while fighting with the lawyers all the way I'm sure). Is this possible? " I think a better question is why a Park Service needs this kind of level of information about its users to justify its funding.

Bureaucrats want justification.

[Louis_Wu]

The reason this city agency needs to collect this data, is that when budget review comes around again, the Parks agency will be told to justify the spending it has done, and to justify the proposed increase in budget for the next year.

With more data on its users, the agency can say that there were X unique visitors last year, Y visitors who came 5 or more times, and Z visitors came from outside of the county. This information, and other data, will let the Parks department get the money it needs to operate the next year. Without it, they would be sunk.

Whether this is morally or economically right is a different question. But we were talking about the real world.

Louis Wu

"One of life's hardest lessons is that life's lessons are hard to learn."

aggregate the data as frequently as possible

[sporktoast]

Keep your data sets separate from one another. Create one for EACH sort of report you'll need to generate, and have it hold ONLY the necessary kinds of info sufficient for the report as defined. Create one more data set to track individual patrons by whatever information is necessary to manage memberships and temporarily hold source data that will be used used to synthesize data for the reporting.

Move and append the patron's *historical* data to the secondary sets as frequently as practical; lose as much granularity as you can while still meeting the report requirements. Synthesize your aggregate data (Census Block Group, etc.) in the secondary sets. Be sure and *remove* that used historical data from the patron data set once it is captured in the proper secondary data sets.

This way, you will generate the trend info you need, while still insulating individuals from too strong an association to it. And you should still leave just enough historical info in the patron data set to manage memberships/access rights/whatever.

The trick is to move the behavior analysis info away from the identification info regularly and make sure the association is one-way only.

And if that's too confusing, I blame it on the late (GMT -500) hour.

Fight the power that asks for this sort of info!

[ConsumedByTV]

Why do you need to have data to justify this budget? Why not collect statistical data about the people, but no names. Then the matter is really just about who gets to see the statistics. The best policie you could put into place would probley be one that after a short amount of time (6 months) the infomation will be deleted. Only allow access to the information when it comes to the budget, nothing else. You should draw the line at make the database easy to access, take it off the net, because even if you can secure it, someone can break in ( you can hack anything if you just bring a ladder and firemans axe ). This would be alright to cross reference if you just didnt have names, lose the names. This is possible, just be really secure, and dont allow anyone to get access to the database.


Fight censors!

Milwaukee, WI (seriously)

[scotpurl]

Disparaging comments about Milwaukee aside, they have the oldest, best, most complete GIS system for any city, /in the world/.

http://www.gis.ci.mil.wi.us/

And what's GIS? Geographic Information Systems. In really overly-simplified terms, it's like a computer-aided drawing system (CAD) linked to a relational database. http://www.esri.com is the largest vendor of this sort of stuff.

Anyway, the City of Milwaukee has used this system for urban forestry management, crime analysis, poverty analysis, slum analysis, and a whooole lotta other things. If you ain't got a GIS system involved in your process (meaning you're dealing with spatial information -- information that has a specific location in space), then you're seriously not approaching things correctly.

You don't need to put it all in one database. That's the whole point of a relational database. Doing that allows you to compartmentalize things.

And compartmentalizing is what you'll have to do. I'm sure the parents will be up in arms if they knew you were posting how many kids, of what age, lived in which houses. Likewise, if you're posting phone numbers that are unlisted, or names differing from how people have chosen to list them in the phone directory, then you'll hit problems.

The strange thing is, you really need to talk with a lawyer that works for the same group you do. They'll be able to tell you what's legal, and what isn't. If you can't find a lawyer, then start talking to judges (who'll either answer, or refer you to someone they think well of).

Having said all that, I'll now take a step back. WHY do you need all this information? How will fine-grained information help? What reports will you generate based upon this data? How much will collecting, filtering, correcting, updating, maintaining, hosting, backing up, and searching this information cost? If you make a business case, meaning, it's gonna cost $X to do this, then the management folks may back down, or change their plans.