[OPEN-ILS-DEV] Feature proposal: SSN-censoring functionality

[Thomas Berezansky]

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?

Disclaimer: MVLC has local laws preventing us from even considering  
storing SSNs or Drivers License numbers, so we don't store that  
information at this time.

"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.

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.)

Each piece of information to be stored in that manner could then have  
one or more regular expressions for sanitizing. I would implement that  
as one or more search/replace sets, with capture group(s) being used  
in the replacement.

If these data pieces are never exposed via things like pcrud then they  
will be very difficult to get out of the database.

Two remaining issues I see off the top of my head are:

Reporter - It tends to bypass permissions.

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)?

Thomas Berezansky
Merrimack Valley Library Consortium


Quoting Kivilahti Olli-Antti <olli-antti.kivilahti at jns.fi>:

> Goood moorning Evergreeners!
>
> As a fruit of our migration planning work, I present to you... the  
> schematics to an internationalizable SSN-censorer!
>
> Currently Evergreen only hides the sensitive letters from a  
> us-standard SSN number. It seems to be that almost every nation has  
> their own SSN-format. While we have been looking for ways to improve  
> this handicap in Evergreen we have given great concern to make this  
> modification as internationalizable as reasonable.
> A challenge in designing a solution is the fact that even inside one  
> installation, we can have SSNs from multiple SSN-formats.
> In our case it seems to be that such cases are rare. Maybe <2% of  
> our clientele has a SSN of other formats than Finnish (then Swedish  
> or Russian, and fringe cases). I believe the case is same in the  
> states as well. For this reason I am planning to have filtering done  
> according to SSN-format relevancy.
> We have a list of SSN-filters, and the top one is the most used one.  
> If it won't match the given SSN, then we try the next relevant one,  
> until a match is found or error is given to add a new filter.
> Here are the more detailed steps to complete the task, in other  
> words, the implementation plan.
> http://193.65.112.189:8080/browse/EGDEV-28
> The task is waiting for planning review and feedback from the community.
>
> This functionality will be implemented by The Regional Library of  
> Joensuu as a high priority modification during our migration period  
> to Evergreen.
>
> --
> Olli-Antti Kivilahti
> Open Library 2013
> Library of Joensuu
>