Jun 22 2018

Arguments for and against TSA Form 415

We’ve finally begun receiving records from the TSA of how the public responded to the TSA’s proposal in 2016 to start requiring travelers to show ID in order to fly.

Since 2008, TSA and contractor staff at airport checkpoints have been demanding that some travelers who do not have ID, do not show ID to checkpoint staff, or show ID that is initially deemed “unacceptable” fill out and sign TSA Form 415, “Certification of Identity”, and answer questions about the information in the (secret) file about them maintained and made available to the TSA by the commercial data broker Accurint.

Before any Federal agency such as the TSA starts collecting information from the public, whether verbally or through a written form, the agency is required to obtain approval for the “information collection” from the Office of Management and Budget (OMB).

The TSA has never requested or obtained approval for any version of Form 415. But in 2016, the TSA gave notice that it intended to seek OMB approval for Form  415, and accepted comments on that proposal from the public by email. After submitting our own objections to the TSA’s proposal, the Identity Project made a Freedom Of Information Act (FOIA) request for the complete administrative record related to the TSA’s contemplated request.

The TSA has not yet actually submitted a request to OMB for approval of Form 415, but has continued to use it illegally without OMB approval.

In May 2018, we received a heavily redacted version of the TSA’s procedures for “ID verification” including use of Form 415.

Now we’ve received a first partial set of excerpts from the “administrative record” related to the TSA’s proposal, consisting mainly of comments submitted by the public.

Most of the comments were from civil liberties and human rights organizations opposed to the TSA’s proposal, including the Identity Project, the Cyber Privacy Project,  the Constitution Alliance, and the Electronic Privacy Information Center.

But the TSA also received comments questioning the TSA proposal from at least one state government, and a single frighteningly revealing comment urging the TSA to use even more intrusive measures to track people who try to fly without “acceptable” ID.

Read More

Jun 19 2018

Coding Amtrak’s collaboration with US Customs and Border Protection

We’ve received and posted the latest installment in a continuing trickle of responses to a Freedom of Information Act request  we made in 2014 for records related to Amtrak’s collaboration with US and foreign law enforcement and “border control” agencies.

The most recent batch of records released by Amtrak consists mainly of email correspondence between Amtrak IT staff responsible for supporting ticket sales through travel agencies  (most of which occur through computerized reservation systems), programmers with Amtrak’s in-house ARROW  reservation system, and Amtrak’s technical contacts at  the four major CRSs used by travel agencies: Sabre, Apollo, Worldspan, and Amadeus.

Most of these exchanges relate to Amtrak’s decision in 2005 to start feeding information about all passengers on cross-border (USA-Canada and Canada-USA) Amtrak trains to US Customs and Border Protection, and to require all passengers on these trains to provide Amtrak with passport or travel document info to pass on to CBP.

This was not required by any US law or regulations,  but was a voluntary decision by Amtrak. Some travel agents complained about this, but we’ve still seen no indication that they were given any answer about why Amtrak was doing this or what travelers or travel agents who didn’t want to provide this information could do. Amtrak’s own programmers were falsely told that this was required by order of CBP.

The messages we have received show that requiring travel agents to enter names and details of ID documents in PNRs for Amtrak travel created in the CRSs, and getting this information to flow through in standardized form to ARROW records and transmissions to CBP, proved more difficult than had been expected.

Read More

Jun 08 2018

“Governance” of the REAL-ID database

[Attendance at the most recent face-to-face (F2F) meeting of the AAMVA S2S Governance Committee, Milwaukee, WI, March 22, 2018]

We’ve been trying for years to find out who is really in charge of the national ID database being created to enable states that choose to do so to comply with the  Federal REAL-ID Act of 2005.

The national ID records system includes the SPEXS database and the S2S data network and system of central-site applications. S2S, including SPEXS, is operated by AAMVA (a non-governmental non-profit organization whose members are the directors of state driver licensing agencies) and Clerus Solutions (a for-profit  private contractor most of whose executives are revolving-door former staff of AAMVA).

But who is setting policy? Who decides what information from state drivers’ license and ID records is included in the central “pointer” database? Who decides what other entities are able to retrieve, mine, or otherwise obtain or use these records?

Are state governments really in control of their residents’ data once it is uploaded to the central site (outsourced to Microsoft as a cloud hosting provider)? Or is Is the US Department of Homeland Security, AAMVA, or Clerus Solutions in the driver’s seat?

Documents we’ve recently received in response to a request to the state of Alaska under that state’s public records law don’t answer many of our questions, but shed more light on on this little-known, aggregated, privately-held database of personally identifying information obtained from state records that already contains data about roughly 50 million US citizens and residents.

We also received explicit confirmation from the minutes of a June 2017 meeting (p. 64 of this PDF file) that AAMVA staff and state driver licensing officials expect that participation in S2S and SPEXS will be added to the criteria used by the DHS to determine whether to certify or re-certify states as “compliant” with the REAL-ID Act: The latest batch of records we received (see related records released to us earlier here) is a disordered jumble bundled into a single PDF file. Below are some of the other noteworthy details, with references to page numbers in this PDF file:

Read More