Secure Flight: A Lesson in What Not to Do

The Secure Flight Working Group (formed at the request of TSA) just issued a scathing report about the Secure Flight program.  Perhaps this explains why the TSA recently announced it was scaling back Secure Flight.  The report’s major conclusion is that the Working Group wasn’t given adequate data to evaluate Secure Flight:

The Working Group received limited information about the technical architecture of Secure Flight and none about how software and hardware choices were made. We know very little about how data will be collected, transferred, analyzed, stored or deleted. Although we are charged with evaluating the privacy and security of the system, we saw no statements of privacy policies and procedures other than Privacy Act notices published in the Federal Register for Secure Flight testing. No data management plan either for the test phase or the program as implemented was provided or discussed.

The main problem with Secure Flight is that it is not transparent.  Our society is one of open government, public accountability, and oversight of government officials – not one of secret blacklists maintained in clandestine bureaucracies.  Increasingly, the facts coming out about Secure Flight demonstrate that the TSA is acting like a bureaucracy run amok.  The program seems to lack clear goals; it seems to lack much thought and consideration about how to address a number of very important problems and issues.  The Working Group report concludes:

Congress should prohibit live testing of Secure Flight until it receives . . . from the Secretary of the Department of Homeland Security . . . a written statement of the goals of Secure Flight signed by the Secretary of DHS that only can be changed on the Secretary’s order. Accompanying documentation should include: (1) a description of the technology, policy and processes in place to ensure that the system is only used to achieve the stated goals; (2) a schematic that describes exactly what data is collected, from what entities, and how it flows through the system; (3) rules that describe who has access to the data and under what circumstances; and (4) specific procedures for destruction of the data. There should also be an assurance that someone has been appointed with sufficient independence and power to ensure that the system development and subsequent use follow the documented procedures.