> The plaintiffs believe that because Social Security numbers had a fixed format, GitHub should have been able to identify and remove this data I don't see how they can expect to enforce this with 100% accuracy. SSNs do have a fixed format but other things could potentially follow the same format. For example what if you had a library that lets you configure randomly generated codes in a XXX-XX-XXXX format and it jus…
I even have trouble with this premise, in addition to general agreement with a lot of the other comments in this tree arguing that SSN detection is a red herring.
I agree that displaying SSNs for human consumption has an agreed upon standard format. This doesn't imply that code (and therefore any tests or distributions of data) working with SSNs is handling them as XXX-XX-XXXX.
I've seen plenty of clients storing them without dashes in database tables. I saw one storing them as INTs and handling padding in display logic. I don't know if an SSN can start with a leading 0, but they guarded against that.
Especially given the storage and memory implications of a 32-bit integer vs a 9-11 character string, I see lots of reasons to work with SSNs in code as ints. Should we flag all ints as SSNs? Or maybe we can be "reasonable" and flag any integer in the range 100,000,000-999,999,999 (aka 100-00-0000 to 999-99-9999) as an SSN?
I can trivially generate a list containing all valid SSNs with a simple loop. Should I hesitate to publish code with loops over integers in the range above? That code could easily be used by a malicious hacker to generate the SSN list!