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

[Ben Shum]

Well, in our consortium, we also do not use any SSN identifiers for 
similar reasons to the others listed thus far.  We actually use the 
ident_value field to store student ID numbers for our school library 
patrons as an alternate means of identifying students separate from 
barcodes, etc.  The student ID numbers usually match up with data from 
other distinct school software used to manage student records in a 
non-library capacity.  Our public libraries are not usually making use 
of Evergreen's identification field due to this particular reservation 
in our system.  We wouldn't want to hide or mask these student ID values 
as far as I know.

That said, I wouldn't object to the originally stated proposal to create 
an enhancement for Evergreen to allow for customized masking of any 
ident type based on specific patterns.  To me, I would envision that the 
default loading of patron data would just continue to assume you wanted 
it in clear text unless configured otherwise. That way, libraries who 
don't care about protecting or using the field can keep it simple, and 
libraries that do want to protect sensitive data stored in the field 
(whatever that is or for whatever reasons) can be allowed to do so.

Keeping it generalized rather than pinning it specifically to SSN (and 
all the issues known to exist for us crazy US folk) seems like a 
reasonable course of action to me.

To the last question though about tracing bad patrons for punishment... 
while some Evergreeners may follow the Technical discussion lists, I 
would imagine you'd get more potential responses from library 
administrators / policy makers if you were to pass the question along to 
the General list instead.

-- Ben

On 8/29/2012 3:29 AM, Kivilahti Olli-Antti wrote:
> I agree with Mr. Peters that the default ident_type SSN should be
> removed to not teach bad habits.
> It is rather unfortunate that you see this solely as an en-US question,
> considering how much you push for an International Evergreen Community.
> The customizable SSN-censorer I came up with is a overkill atm, but if
> somebody would like to store their SSN's in-db, and if we think of a
> larger International scope that is highly probable, we should expect
> this functionality to be used, not just in Finland. Just thinking on
> large scale.
>
> If we were to implement this, and would like to use it, is there
> anything which objects to it's integration to master branch? This forces
> no-one to use SSN's that's for sure, this general filter could be
> applied to any ident_type really, if needed.
>
> But there was an idea of a arbitrary identification number. We could use
> a external program to store the SSN, accessible via this arbitrary id. I
> don't think our staff will endorse this idea though.
>
> Less time consuming alternatives are abundant, but unfortunately might
> end up as very individual.
>
> The main reason why we need to store SSNs, is the traceability of
> patrons in case of offences. I think we could trace 90% of the cases
> anyway, but how could we legally prove that this very person is the
> culprit? Well I'll look into that.
>
> How do other Evergreensters deal with the traceability of patrons in
> case of offences, and press charges if needed? Or is your only tool of
> punishment, expulsion?
>

-- 
Benjamin Shum
Open Source Software Coordinator
Bibliomation, Inc.
32 Crest Road
Middlebury, CT 06762
203-577-4070, ext. 113