The threats associated with improper handling of sensitive survivor data are very real. Identity Theft, SPAM, and child predation are all serious concerns, with consequences ranging from an inbox full of annoying email all the way down to stolen funds, credit problems, and the sexual abuse of children.

In helping survivors reconnect, websites should be aware of the information they make publicly available. The Katrina Data Project has prepared the following "Best Practices" for handling sensitive data, and urges all websites, forums, lists, and data sources to review their own handling of survivor information.

The goal of these recommendations is to provide enough information that a user searching for a survivor can be confident they have found the person they are looking for, without putting the privacy of that person at risk.

Please note, these "best practices" are provided as basic recommendations. The Katrina Data Project cannot warrant that these recommendations alone will appropriately protect sensitive data, nor can it be held liable for any misuse of sensitive data, even if you follow these recommendations.

1. Mask Phone Numbers
2. Mask / Truncate Email Addresses
3. Mask Street Address House Numbers
4. DO NOT offer a full data feed as a Web Service, RSS feed, etc
5. DO NOT Offer Full/Large Listings
6. DO Offer "Contact on Behalf of" Functionality
7. DO Provide "Remove Me" Functionality
8. DO NOT Provide Data on Minors or Children
9. Be aware of how users are using your system
10. If you cannot implement the above best-practices, remove your own listings from the web send your data to someone who does.

1. Mask Phone Numbers:
   If you are capturing or displaying phone numbers they should be masked to ensure the complete phone number is not available. At the very least, the 7th and 8th digits should be replaced with "#" characters.
    
   Example: (123) 456-7890 is displayed as (123) 456-##90
    
   This gives anyone searching for an individual ample information to decide if this person is who they are looking for, while making the displayed phone number less useful to malicious users.
    
   A more secure method would be to mask more characters (Example (###) ###-##90). A searcher who knows the full phone number can still look at this and help decide if it's the right person, but the phone number is all but completely hidden from a malicious user.
    
2. Mask / Truncate Email Addresses:
   If you are using capturing or displaying email addresses for survivors or searchers, you should truncate (remove) any part of the address after the @ sign. 
    
   Example: "privacy@katrinadataproject.com" is displayed as "privacy@..."
    
   This will allow a searcher to determine if this is the person they seek, without giving malicious users the ability to add an email address to a spam list.
    
   In conjunction with this, it is recommended you offer a "Contact on Behalf of" capability (see below).
    
3. Mask Street Address House Numbers:
   Displaying only City/County/State in search results does not give a user sufficient information to be confident they have found the person they are looking for. (There is most like more than one "John Smith" who lived in New Orleans, LA). In an effort to provide more data while protecting privacy, it is recommended that all numbers in street addresses are masked with "#" characters.
    
   Example: 1234 Sample Road is displayed as #### Sample Road.
    
   This gives the searcher more detailed information about the person without violating their privacy, not making a full address available to a malicious user.
    
4. DO NOT offer a full data feed as a Web Service, RSS feed, etc
   Although the sharing of information can make it available on more websites, it is very difficult to protect the privacy of a person when you offer up a public feed containing the data you have collected. In allowing other sites to import or read your full feed, masking as described above becomes useless.
    
   Even if you allow masked data in your feed, the searching or cross-referencing of this data is less-than-useful as full fields cannot be compared.
    
   Instead, it is recommended that if you want to share data feeds, you offer up a "Search" web service, allowing another site to submit a search against your data, and you to return the masked output. This allows you to retain control over the privacy of your persons data while creating a distributed network where a single data store can be searched from multiple websites.
    
5. DO NOT Offer Full/Large Listings
   While it is very impressive in showing how much data your have collected, realistically there is no reason to show a full listing of missing/safe persons on your website.
    
   Not only does it provide poor functionality and a limited user experience (is a user really going to page through 5000 rows, 20 at a time to find who they're looking for?)... it increases server load and bandwidth usage.
    
   Instead, it is recommended you require a user to first "search" for a listing, even if it's only with a first letter of first and last name. Upon searching, you should return a limited number of records... if the search returns too many records, prompt the user to narrow down their search by adding more criteria.
    
   While this shouldn't be as great a concern if you are properly masking your results, we do consider it to be a best practice for usability.
    
6. DO Offer "Contact on Behalf of" Functionality
   If you mask email addresses and phone numbers, you might wonder how a searcher is supposed to get back in touch with the person once they find them.
    
   While this is more difficult with phone numbers, the solution is simple for email: Offer a simple form allowing a user to "send this person a message", where they can type a brief message and leave their email address or return contact info. Your system will send this via email, without displaying the email address to the user.
    
   This way, you allow the target person to retain control of their privacy, and decide if they want to contact the searcher in return.
    
   It is possible to do the same for phone numbers using an automated dialing and message system, such as in use by katrinasafe.com.
    
7. DO Provide "Remove Me" Functionality
   If you are storing data on individuals, it is recommended you provide a way for them to get themselves removed from your list entirely.
    
   How do you confirm that the person requesting to be removed is actually the person the record describes? If you are properly masking results, you should be able to have the requestor provide the details of the "masked" data...
    
   Example: If your search results display "#### Sample Road", your database says "1234 Sample Road", and the requestor can tell you "My address was '1234 Sample Road'" you can be more confident they are the "owner" of the data.
    
8. DO NOT Provide Data on Minors or Children
   While we all want to help people get back in touch, especially children who have been separated from their parents, it is NOT recommended you provide any search results containing information on persons under the age of 18.
    
   If you have information on minors, it is recommended you contact the National Center for Missing and Exploited Children.
    
9. Be aware of how users are using your system
   You should be aware how users are interpreting the fields you are asking them to complete when registering with you system.
    
   Your data entry forms should clearly explain what goes into each field, and you should have strong data-validation before the information is saved to your system to ensure users are using them as expected and instructed.
    
   Example: THIS IS FOR YOU ICRC FamilyLinks. When registering a safe or missing person, the "Family News Network of the International Committee of the Red Cross" website asks the user to complete a field labeled "Mother's Name". While this is hopefully not the intention, looking at publicly available search results some users interpret the purpose of this field as collecting their mother's MAIDEN name. Anything a user types into this field is displayed in search results, and as such, some records contain name, address, phone number, and maiden name... which may be sufficient information to gain access to financial accounts. The ICRC data capture form should either be clarified to ensure users do not enter a maiden name, or mother's name should be removed from the search results immediately.
    
10. If you cannot implement the above best-practices, remove your own listings from the web send your data to someone who does.
    If you do not have the capability to properly protect the privacy of those you collect data from, it is recommended you shut down your own forum/database/web list, send any data your have collected to a website which can, and link to them.
     
    While we all want to help out disaster victims and drive traffic to our own site as people view lists we have, it is imperative that we don't cause harm to those we're trying to help. Please place the privacy and security of survivors above site traffic and ratings.
     

Questions/ Comments? Contact privacy@katrinadataproject.com