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
