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
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
@list.georgialibraries.org
Subject: Re: [OPEN-ILS-DEV] Feature proposal: SSN-censoring functionality
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
Quoting Wolf Halton wolf.hal...@gmail.com:
Storing SSNs unencrypted is a terrific mistake, in the US. Storing them at
all is a Very Bad Thing (TM).
Storing a hash that is evidence that a proper authority has seen the
number, or just a boolean true, seems like enough.
This reply is not
Quoting Jason Stephenson jstephen...@mvlc.org:
Stepping down from my soapbox, I see absolutely no reason for a US
library to store a patron's SSN. A drivers' license number, perhaps,
but not the SSN. My suggestion is to delete the field, and if
someone needs to track such an identifier
http://i.imgur.com/muy2N.gif
Justin
On Aug 27, 2012, at 10:33 AM, Jason Stephenson wrote:
Quoting Jason Stephenson jstephen...@mvlc.org:
Stepping down from my soapbox, I see absolutely no reason for a US library
to store a patron's SSN. A drivers' license number, perhaps, but not the
, August 27, 2012 11:33 AM
To: Open-ILS Dev
Subject: Re: [OPEN-ILS-DEV] Feature proposal: SSN-censoring functionality
Quoting Jason Stephenson jstephen...@mvlc.org:
Stepping down from my soapbox, I see absolutely no reason for a US
library to store a patron's SSN. A drivers' license number
Storing SSNs unencrypted is a terrific mistake, in the US. Storing them at
all is a Very Bad Thing (TM).
Storing a hash that is evidence that a proper authority has seen the
number, or just a boolean true, seems like enough.
Wolf Halton
http://sourcefreedom.com
Apache developer:
On Sun, Aug 26, 2012 at 05:04:14PM -0400, Wolf Halton wrote:
Storing SSNs unencrypted is a terrific mistake, in the US. Storing them at
all is a Very Bad Thing (TM).
Storing a hash that is evidence that a proper authority has seen the
number, or just a boolean true, seems like enough.
pLease,
All true and understood, but probably a different issue. The reality of what
the SSN equivalent is in jurisdictions other than USA likely varies. It may
be perfectly legal and acceptable to use that SSN equivalent (be it passport
number or some other ID), because there may not be a different
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,
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
I also believe that storing SSN's is a Very Bad Thing. This may be because I'm
coming from an overwhelmingly enterprise/academic environment where FERPA is
taken very seriously, but in general I treat SSN's as I would credit card
numbers or personal medical information. I don't see reason for
13 matches
Mail list logo
