Court filings contained in PACER are public documents, and are, in theory, open to the public. But, in the past, the fact that these materials were either maintained in individual courthouses or, once digitized, were behind password-protected log-ins and per-page charges generally prevented them from being widely disseminated. Open society advocates have long criticized PACER for charging the public itemized fees to access public court filings, arguing that this pay-as-you-go system effectively removes public filings from the public domain and discourages a fully transparent legal system. 

Princeton University's Center for Information Technology Policy, with assistance from Harvard University's Berkman Center for Internet and Society, unleashed the latest salvo against PACER in the form of RECAP (“PACER” spelled backwards, not by coincidence). RECAP is a free open-source software plug-in for the popular Firefox web browser that automatically uploads all PACER documents a user is viewing onto a growing archive maintained by the non-profit group Internet Archive. When the next RECAP user attempts to view a PACER document that has already been archived, the RECAP plug-in automatically uploads the copy to prevent that user from paying for those materials. This system essentially allows users of PACER to slowly create a secondary archive of these public documents that can be accessed for free.

I have previously discussed the controversy surrounding PACER's security failings and pricing. After the jump, my colleague Aaron Wright and I discuss whether the RECAP plug-in  magnifies or minimizes PACER's security problems and risks of identity theft, the pushback RECAP has received from courts, and RECAP's creators' response to criticism about the plug-in's security and privacy safeguards.

As Ramzi Ajami wrote earlier, the PACER system is littered with filings containing very sensitive information about individuals, including Social Security numbers. While various court rules require that this information be redacted, that obligation is placed firmly and solely on the filer and is not subject to any additional screening. Therefore, if a filer forgets or refuses to redact certain sensitive information, that information may appear in the public system. 

The RECAP plug-in poses an obvious risk of creating a more freely-accessible archive of materials that mirrors PACER’s mistakes and contains documents containing very sensitive personally-identifiable information. However, RECAP also poses the unique risk of creating an “outdated” secondary archive of non-redacted PACER documents that are later redacted in PACER, but that have already been copied and archived by RECAP in non-redacted form. 

RECAP’s creators acknowledge these privacy concerns in their Privacy and Security FAQs, and have instituted what appear to be promising safeguards, including a scanning program that identifies and excludes any documents with Social Security numbers:

 * At our request, the Internet Archive has disallowed search engine indexing of the documents we submit. (This may be changed in the future if we develop better ways of addressing privacy concerns.)

 * The RECAP servers automatically scan all submitted documents for Social Security numbers before they are uploaded to the Internet Archive. Any document in which we detect such information is automatically suppressed.

 * We’re relying on RECAP users to report privacy problems. Please email us if you find a document in the repository that contains inappropriate personal information. Your feedback will not only allow us to suppress the document you found; it will also help us improve our automated filters so that fewer problem documents slip through in the future.

However, aside from Social Security numbers, the FAQs do not address whether RECAP screens documents for other sensitive information that must also be redacted from court filings, and that individually or collectively may also pose a serious risk of identity theft, including taxpayer identification numbers, financial account numbers, and full dates of birth. 

While it remains unclear whether the creators of RECAP will implement further safeguards to address filings containing sensitive information aside from Social Security numbers, the plug-in’s creators have extended an invitation to courts and the public to submit suggestions to enhance the program’s overall security.  

Courts, at least, appear to have rejected that offer, and have so far signaled serious skepticism about the plug-in. Over the past two weeks, various courts have posted bulletins warning filers from using RECAP pending further review of the plug-in, claiming that the open-source software format renders RECAP vulnerable to malicious users who can modify the plug-in for improper uses, and also warning that RECAP may upload filers’ materials (available to attorneys through the EMF log-in) that are not publicly available on PACER.  (See, for example, bulletins here and here.) The creators of RECAP responded by clarifying that RECAP only downloads and copies documents through the public PACER portal (and not attorneys’ EMF system), and reiterated that “users can continue using RECAP with the knowledge that it’s designed with privacy as our top priority.” 

Whether courts will actually engage in a meaningful dialogue with RECAP's creators to strengthen the program’s security protocol, or whether RECAP’s screening protocol for sensitive information may actually provide a roadmap to strengthen PACER’s own security failings, remains to be seen.

Links:

• Center for Information Technology Policy homepage
• Berkman Center for Internet and Society homepage
• Firefox homepage
• PACER homepage
• RECAP homepage
• Internet Archive homepage
• Security Privacy and the Law, “Electronic Access to Court Filings Potentially Exposing Sensitive, Personal Information,” Ramzi Ajami (4/09/09)
• Wired “Firefox Plug-In Frees Court Records, Threatens Judiciary Profits,” by Ryan Singel (8/14/09)

What has received considerably less media attention, however, is the SSA's muted response to this fiasco, and, quite the opposite, the alarmingly broad set of explanatory guides and almost-complete SSNs that the Agency makes available to the public on their website.

The SSA is right: the Agency's website contains user-friendly guides that explain, in sometimes surprising detail, the SSN assignment system. The excerpt below, for example, is from the section helpfully titled “Structure of the Social Security Number (SSN)”:

The SSN consists of nine digits separated into three parts by hyphens (i.e., 000-00-0000) representing the area, group, and serial numbers.

1. Area Number The first three digits of the SSN are the area number. The area number reflects the State as derived from the ZIP Code in the mailing address the number holder provided on his/her application for an original SSN card.

 2. Group Number The middle two digits of the SSN are the group number. The group number ranges from 01 to 99, but group numbers are not released for SSN assignment in consecutive order. Instead, for administrative reasons, group numbers are released in the following sequence:

Odd numbers from 01 through 09; then even numbers from 10 through 98; then even numbers from 02 through 08; and finally, odd numbers 11 through 99.

3. Serial Number The last four digits of the SSN are the serial number. The serial number represents a straight numerical series of numbers from 0001-9999 within each group.

The SSA website also provides a chart that enables any lay person to make a very reasonable guess at the first 3 digits of any person’s SSN if a person’s State of birth is known -- and with extreme accuracy if that individual is born in smaller-sized States, such as Hawaii or Rhode Island.  Other resources include:  

• a list, updated monthly, of the Area Number and Group Number (or the first 5 digits of the SSN) that have been assigned each month beginning December, 2003;
• instructions on how to access the Death Master File, which researchers used to deduce the statistical patterns by which SSNs are assigned, and, presumably, any statistically savvy third party can do the same; and
• FAQs, directed to employers that, among other things, lets us know which SSNs are invalid: “no SSNs with an area number in the 800 or 900 series, or ‘000’ area number, have been assigned. No SSNs with an area number above 772 have been assigned in the 700 series.”

To its credit, the SSA at least acknowledges the obvious reality that “the use of the SSN as a general identifier has grown to the point where it is the most commonly used and convenient identifier for all types of record-keeping systems and data exchanges in the U.S.,” and that identity theft associated with SSNs is a pressing concern. While the SSA has for decades refused to adopt the most obvious safeguard of completely randomizing SSN assignment, the Agency has finally announced that it is currently developing a system to randomize all SSNs beginning next year.  That system, however, would only apply to the assignment of new SSNs – and would in no way help the hundreds of millions of Americans alive today whose SSNs remain vulnerable. 

Links

• The report “Predicting Social Security Numbers from Public Data” (.pdf).
• Coverage of the report by the NYTimes, CNN, and PCWorld.
• The SSA’s website, and table of contents for general SSN information.

Conficker (also known as Downup, Downandup, Conflicker, and Kido), a computer worm that attacks Microsoft Windows operating systems, was pegged by the media to wreak havoc worldwide on April Fool’s Day of this year. In the weeks leading to what some experts dubbed our “digital Pearl Harbor,” numerous reports surfaced documenting the sheer scope of the worm’s reach: in addition to infecting millions of Windows operating systems worldwide, the worm also reportedly infiltrated the French government’s naval systems – forcing the French to ground their warplanes – and the British Parliament’s computer network.

Despite the massive media furor, April Fool’s Day passed with relatively little disruption. However, recent reports suggest that Conficker not only remains active – but that it has begun its bid to steal users’ private and financial information.

Despite its aggressive success in infecting computers worldwide, however, Conficker’s purpose still remains relatively unclear. Experts warned that, in theory, infected computers would essentially be transformed into “zombie machines” that follow almost limitless commands and download software from remote servers -- whatever those instructions or software may be, suspected to range from keystroke logging to spam generators. 

Not surprisingly, Conficker’s recent activity confirms that at least one of its purposes is to steal users’ financial information. Beginning in April, 2009, infected computers have begun installing bogus security software (or "scareware") in a bid to defraud users into paying for fake anti-virus programs. The software alerts users that their computers are infected with Conficker -- but unwitting users who agree to pay for the fake anti-virus software not only lose $50 in exchange for more malicious software, but also risk having their financial information stored and stolen, opening a gateway to identity theft. 

It is unclear if the worst is over. Conficker remains active, and its “commands” from remote servers can prompt infected computers to download further malicious software compromising users’ security and hijacking their computers in any number of ways. While the "scareware" tactic that Conficker has displayed so far may be transparent to even mildly sophisticated PC users, it should serve as a warning that the worm is actively pursuing users' private and financial information -- and may employ any number of methods to access it.  

Links

• Microsoft has posted general information about the Conficker worm.
• The “Conficker Eye Chart” is a simple, non-downloadable diagnostic to determine if your PC is infected. A detailed discussion about the Chart is also available.

The problem can originally be traced to the E-Government Act of 2002 (.pdf) (P.L. 107-347, Title II, § 205). This federal statute requires all federal courts to make their electronic filings available to the general public online. Since nearly every federal court implements an electronic filing service, this provision applies to virtually all documents filed in federal court -- greatly increasing the risk that sensitive information is inadvertently published. 

To safeguard against the publication of individuals' sensitive information, the E-Government Act broadly directed the federal judiciary to adopt uniform rules to protect sensitive information contained in court filings. These rules eventually culminated into amendments, effective December 1, 2007, to the Federal Rules of Appellate Procedure (Rule 25), Civil Procedure (Rule 5.2), Criminal Procedure (Rule 49.1), and new Bankruptcy Rule 9037. These new rules require parties to redact specific categories of information from all filings, including Social Security and taxpayer identification numbers (except for the last four digits), all names of minor children (except for initials), all financial account numbers (except for the last four digits), all dates of births for persons (except for the year of birth), and in criminal cases, all home addresses (except for the city and state).

A weakness in these privacy provisions, however, is that they depend solely on the conscientiousness of whomever is filing the documents to identify, and then redact, the sensitive information. This holds true whether the filer is an attorney, or a layperson with no legal background. Courts are not required to review these filings before publishing them online, and in some instances, courts explicitly state that they will not review filings for any redaction. (See, for example, the press release from the District Court for the Southern District of West Virginia (.pdf) on compliance with the E-Government Act and the notice from the Distict Court for the District of Rhode Island (.pdf).)  Therefore, at present, there is absolutely no filter or other protection that prevents a person from filing sensitive personal information in federal court and publishing this information for the general public to access. 

As cases grow more and more document-intensive, it is unsurprising that people filing documents in court may overlook redacting sensitive information.  This is particularly true where the sensitive information is not the client's, but instead relate to a non-party that has no reason to be policing the court docket.  For example, where an employer is sued, sensitive information of its employees may be included in the employer's financial spreadsheets and filed in court as an exhibit during motion practice.  With courts' hands-off approach to filings, we are all in danger of having our sensitive information published online for cases that we may not even know exist.  

The Judicial Conference recently issued a response to Sen. Lieberman's letter. In its response, dated March 26, 2009 (.pdf), the Judicial Conference squarely blames litigants, and not courts, for the infractions arising from the publication of non-redacted sensitive information online,  asserting that litigants alone are responsible for redacting materials under the relevant privacy rules; courts are only charged with publishing those materials.  The Judicial Conference defended this policy: “[t]he litigants and lawyers are in the best position to know if such [sensitive] information is in the filings and, if so, where…Moreover, requiring court staff unilaterally to modify … documents that are filed in court was seen to be impractical and potentially compromising the neutral role the court must play.”  The letter did not explain how instructing court clerks to assist in the ministerial task of redacting sensitive information, even of non-parties unrelated to the case, would "compromis[e] the neutral role the court must play."

However, the Judicial Conference did acknowledge that the reported instances of electronic filings containing sensitive information is “disturbing and must be addressed,” and insisted that its Privacy Subcommittee is continuing to assess whether any additional privacy rules should be implemented to safeguard that information. Moreover, the Judicial Conference explained that while it continues to assess the issue more carefully (including by exploring empirical data on the number of infractions), it has encouraged all clerks of court to remind all parties about their obligations to redact sensitive information, and has encouraged all courts to submit privacy recommendations for possible national adoption.

In the meanwhile, the safekeeping of our sensitive information in federal court filings, available to the public online, remains solely in the hands of whomever is filing those materials. 

Links

• The April 2009 press release from PACER (.pdf) - also available from PACER website here (.pdf).
• The text of the E-Government Act  (.pdf) - also available from the GPO website here (.pdf) (see especially Title II, § 205).
• Sen. Lieberman’s February 27, 2009 news release (.pdf) - also available from the Senator’s website here (.pdf).
• The Judicial Conference’s March 26, 2009 response to Sen. Lieberman (.pdf) - also available from Public.Resource.Org here (.pdf).
• An overview of PACER services, including pricing information. 
• The New York Times story documenting Carl Malamud’s exposé of PACER.
• Malamud’s organization, Public.Resource.org.

Recently, the FTC has responded (.pdf) to the AMA by articulating the legal support for its interpretation.  In its response, the FTC unambiguously endorses the broad construction of the term “creditor” to include any and all entities that regularly permit payment after the provision of goods or services -- “even [if only] in the normal course of a traditional billing process.” The FTC claims this broad reading is necessary to deter identify theft because “[i]dentity thieves look for opportunities to obtain produces or services that do not require payment up-front.” (emphasis added).

The FTC, with unusual frankness, emphasizes that no industry is exempt as a “creditor” because the definition of “creditor” is “activity-based, not industry based.” In other words, the test of whether you are a “creditor” does not depend on what goods or services you provide, but on the way you bill your clients. The FTC also pulls no punches when identifying potential “creditors,” listing a wide range of industries and businesses, including physicians, lawyers, merchants, repair persons, and even “a local store where a customer runs up a tab.” 

The FTC primarily supports this interpretation with commentary from the Federal Reserve Board on parallel regulations: "[i]f a service provider (such as hospital, doctor, lawyer or merchant) allows the client or customer to defer the payment of a bill, this deferral of a debt is credit for the purposes of the regulation, even though there is no finance charge and no agreement for payment in installments."  While this commentary has some appeal, the FTC seems unable to find direct support in court decisions and only cites a judicial aside ("obiter dicta") from the district court in Barney v. Holzer Clinic, Ltd., 902 F.Supp. 139 (S.D. Ohio 1995) -- a case in which the healthcare provider was ultimately held not to be a "creditor."  The FTC also attempts to distinguish Reithman v. Berry and Shaumyan v. Sidetex Co., the two appellate court decisions cited by the AMA.  All in all, the FTC letter contains an extended explanation of the FTC's posiiton, but legal scholars will find the FTC letter devoid of any substantive court decision or controlling legal precedent that justifies applying the FTC's broad interpretation of "creditor" to most businesses. 

While the FTC's position may be unyielding with respect to which entities are covered by the Rules, the FTC does appear to be taking a softer approach with respect to compliance. "We are, of course, sensitive to the concern that the Rule requirements could be burdensome for health care providers, potentially leading to unintended costs for consumers."  The FTC’s letter suggests that the Red Flag Rules are highly flexible with respect to what security measures are required.  According to the FTC, covered entities should design identity theft prevention programs commensurate to their level of risk: “high risk entities would tend to have more elaborate [Identity Theft Prevention] Programs, while low risk entities could have streamlined and less complex Programs.”  The FTC lists several security measures that healthcare providers should consider:

• checking photo identification at the time a patient seeks healthcare services,
   
• placing a "hold" on efforts to collect debts when notified that a patient's identity has been stolen,
   
• not reporting fraudulent transactions to credit reporting agencies, and
   
• maintaining information about a known identity thief separately from the records of the original patient.

The FTC thus continues to maintain its position with respect to the broad scope of the Red Flags Rules and its attempt to push the healthcare industry, among others, to develop risk-based information security programs.

Links

• The February 4, 2009 letter sent by the FTC to the AMA is available here (.pdf).
• The September 30, 2008 letter sent by the AMA to the FTC chairman is available here (.pdf) or from the AMA's website here (.pdf).

If you are hoping that federal lawmakers have used the HITECH Act to finally set a national standard for patient medical information, however, you will be disappointed.

The HITECH Act, like HIPAA, preempts any contrary state laws, but leaves intact any state laws and regulations that impose stricter requirements on the handling of patient information. As a practical matter, this means that if you are covered by HIPAA and the HITECH Act you must meet new minimum standards while continuing to monitor and comply with the ever-increasing patchwork of laws governing patient information in every state in which you operate.

What follows is a more detailed discussion of the provisions of the HITECH Act and how it attempts to provide additional security for patients' health information.

The HITECH Act provides a "floor" for notification requirements regarding any security breach of patients' "unsecured protected health information." The definition of "protected health information" (or "PHI") is imported from HIPAA, and generally includes any part of a patient's medical record or payment history. The definition of "unsecured" PHI is broadly defined and generally means any PHI that is not secured by technology rendering that information unreadable or unusable in an accredited manner.  The Secretary of Health and Human Services has been charged with issuing more definite guidance within 60 days.

The HITECH Act's security breach notification requirements specify the timing, manner, and substance of any breach notification, among them:

• notifying the Secretary of Health and Human Services "immediately" if the breach is with respect to 500 or more individuals;
   
• notifying each individual whose unprotected health information is reasonably believed to have been accessed, acquired, or disclosed as a result of the breach;
   
• providing notice to prominent media outlets in each State where the unsecured protected health information of 500 or more residents is reasonably believed to have been accessed, acquired, or disclosed as a result of the breach;
   
• completing all notifications to affected individuals and media, if applicable -- "without unreasonable delay and in no case later than 60 days," unless delayed notification is authorized for certain law enforcement purposes (so as not to "impede a criminal investigation or cause damage to national security");
   
• specifying in each notification to an individual a description of what happened, the types of information believed to have been accessed, and contact procedures for affected individuals to ask questions or learn more information; and
   
• requiring all affected entities to provide the Secretary of Health and Human Services an annual log tracking every breach.

While all affected entities will need to update their notification protocol to comply with these requirements, affected entities in those six states that do not require data breach notification (Alabama, Kentucky, Mississippi, Missouri, New Mexico, and South Dakota) will have some significant catching up to do.

• The HITECH Act is available here (.pdf), or directly from the Government Printing Office here (.pdf)
• [Note that the HITECH Act begins at H.R. 1-112 through 1-165 (pp. 112 through 165 in the document). The security and privacy provisions are found at Subtitle D ­ Privacy, beginning H.R. 1-144 (p. 144)]