Monday, 18 July 2011
DHS reply to my arguments for release of travel records
Late last Friday night, lawyers for U.S. Customs and Border Protection (one of the divisions of the DHS) filed their reply to my motion for summary judgment in Hasbrouck v. CBP, my lawsuit under the Privacy Act and Freedom Of Information Act (FOIA) seeking release of PNR data and other information from and about the CBP "Automated Targeting System" (ATS) and other records of the travel of innocent US citizens neither accused nor suspected of any crime.
I've added CBP's latest pleadings and self-serving (and often false) declarations to the Identity Project's page of documents from the case.
My legal responses are due to be filed with the court by July 29th, followed by oral argument before Judge Seeborg of the U.S. District Court for the Northern District of California in San Francisco on August 25th.
In the meantime, the government's latest filings raise disturbing new legal and factual claims:
First, CBP's main response to my Privacy Act arguments is to claim the authority (a) to delay action indefinitely on Privacy Act requests ("The Privacy Act contains no provisions addressing processing procedures or deadline", they say), and (b) to promulgate new Privacy Act exemption rules applicable retroactively to pending requests and appeals, even ones made years earlier.
If these arguments are accepted by the courts, the result would be that the Privacy Act cannot be relied on to provide any guarantee of "rights" with respect to future access to personal information. Whenever an agency receives any request it doesn't want to fulfill -- for access to records about an individual, for an accounting of disclosures of those records, or for correction of inaccurate records -- the agency could simply delay acting on the request (without even needing any reason or excuse for the delay) while it promulgates a new rule retroactively exempting the system of records from the requirement to act on the request. Or the agency could simply delay action indefinitely, effectively denying the request without the need for any formal exemption, denial, or statement of reasons.
Anyone considering relying on the Privacy Act, or on the (current) rules for any particular system of records should be aware that this is now officially the DHS interpretation of the Privacy Act.
Second, CBP claims (paragraph 11) that the "audit logs" of access to ATS records (including PNR data) were not likely to contain any information responsive to our requests because they are "neither intended nor designed to be used to generate reports to memorialize the terms used [to] search for records."
CBP thus appears to be admitting that -- despite the claims in its Privacy Impact Assessment and reports to the European Union that "ATS retains audit logs for all user access", those audit logs show only who logged in to the ATS system, not what PNR data they retrieved.
Apparently, once an "authorized" user logs in, they can retrieve any PNR -- of a politician, of a celebrity, of their personal enemy, or of anyone else -- without any record being kept of which PNRs they have retrieved.
The absence of logs showing which PNR data is retrieved, when, and by whom make a mockery of any reliance on these logs as proving or disproving whether CBP misuses its access to PNR data.
I've often said in the past that the absence of access logs for access to PNR data held by commercial computerized reservation systems makes it impossible for those CRSs to comply with EU or Canadian privacy law. But I've taken at face value CBP's claim to maintain logs of access to the copies of PNR data in CBP's ATS database.
Now we know that there are no meaningful access logs -- logs showing which PNRs are retrieved when, and by whom -- for ATS either. There is thus no way for anyone to know who has retrieved your PNR data, when, or from what other countries, and no way for anyone to carry out any meaningful audit of compliance with policy restrictions on access.Link | Posted by Edward on Monday, 18 July 2011, 17:51 ( 5:51 PM) | TrackBack (0)