The more I look at the list of issues you present, the more I am convinced that storing SSNs as they currently are is a *bad* thing. Perhaps storing them in general is a bad thing?
I am not sure can we not store SSNs. Here they are collected wherever you do business. Transmitted over phone to marketers, asked pretty much where ever your identification is of question. Currently every staff member here has access to every patrons' SSN. Patron Editing/Registration - Do you show the full value by default, or provide a change/update interface that can load the full value (provided you have permissions to see the un-sanitized current value)? We can access the full SSN along with the rest of the patron data in the edit view of our current ILS. We were planning for Evergreen to display the full SSN as well in the patron edit view (as is). Also the sanitized SSN would be displayed as well with a description of the filter used to sanitize the SSN. A better solution may be to define a new table for storing one or more pieces of data for identifying the patron. Permissions can then be used to allow enforcement of who is allowed to see the information, complete with whether or not they can see the un-sanitized data. (This could, in theory, allow Massachusetts libraries to store this data and still comply with the law.) That definitely is an idea worth considering. To me it looks like an ugly solution where we have multiple columns representing the same identification data. But considering that it might be a significantly easier approach to compatibility and security, ofcourse sounds great. "Sanitizing" the data as it comes out requires flagging it as to be ignored going back in, unless non-sanitized data comes back. This will really screw with the code paths for patron editing and retrieval. Note that currently the *only* place I know of with protection for US-style SSNs is the patron sidebar view. Hitting "Edit" shows you the full thing anyway. If we take non-sanitized data for the patron editing view, we will push it back as well. Reporter - It tends to bypass permissions. Maybe we could make another Evergreen database user, evergreen-secure, to have access to the separate SSN-table? On 08/13/2012 06:36 PM, [email protected]<mailto:[email protected]> wrote: Re: Feature proposal: SSN-censoring functionality -- Olli-Antti Kivilahti Open Library 2013 Library of Joensuu
