The following item was originally published on ectn.typepad.com 11/1/2008 when the OpenBEDM project went under the name Pygar.
A Situation to Motivate the Discussion.
When might the community need a normative procedure for negotiations conducted through BEDM? Let’s consider a hypothetical, but plausible, situation.
Suppose that the Department of Homeland Security (DHS), an agency of the U.S. Federal Government, gives the New York Police Department (NYPD), a local police force, a sum of money to purchase and use a New Technology (NT) that gathers information indicative of future terrorist activities. Suppose further that the DHS requires the NYPD to share all the data gathered by the NT with the Federal Bureau of Investigation (FBI) in order to maximize the probability of detecting terrorist activity. The NYPD is naturally grateful for the grant but the last condition is troubling. The NYPD has the following worries:
- A flow of data from NYPD to the FBI turns a local police force into a surveillance team for a federal agency – a role that is neither in the charter of the NYPD nor consistent with its culture.
- Detection of actual terrorist activity will require fusing local data from the NT with information in the national FBI database; indeed, such data fusion is the goal of the required information flow from NYPD to FBI. However, the NYPD has no confidence that the FBI will respond in a timely fashion to a threat in New York, especially when threats are coming in from all over the country. The NYPD wants the option to act immediately to prevent damage in its jurisdiction.
- The NYPD likes the flow of money from DHS and plans to request more. It needs to show effective use of the NT in order to justify a request in the next year’s budget. However, the FBI controls the fused data and the NYPD cannot assess and report the effectiveness of its own efforts.
Consequently, the NYPD proposes a two-way data flow. It will provide data to the FBI if the FBI opens its database to the NYPD. Now the NYPD can perform its own data fusion for fast response to events and an independent assessment of the whole program. This proposal worries the FBI. The FBI does not believe it can trust each and every member of the NYPD. The FBI has some legitimate fears about misuse of FBI data. Among these risks are:
- an NYPD insider might discover a planned FBI operation, reveal its details and thwart the operation.
- a leak in the NYPD might expose the identity of an FBI informant.
- an insider might obtain information from the FBI database and use it for blackmail.
Given their mutual suspicion, can the FBI and the NYPD ever cooperate to exploit the New Technology? Yes they can with BEDM.
Standard BEDM Procedure.
Let us now suppose the DHS engages a neutral, disinterested, third party, say the Audubon Society, to serve as the blind agent/broker for a BEDM operation that fuses the NT data from New York City with the data in the FBI’s central database. Now, both the NYPD and the FBI keep control of their data and jealously guard access to it. The server operated by the Audubon Society fuses encrypted data from both. When the Audubon’s server succeeds, it forwards the still encrypted but fused data records to both the NYPD and the FBI. Now, both police agencies have an opportunity to act on the new data and hopefully prevent an incident.
Ideally, this outcome is a win-win situation for both agencies. In the long run, both agencies benefit. Cooperation can only become stronger when both parties benefit. Nevertheless, the temptation to defect and betray trust is always present. Cost-benefit analysis may fail to persuade the emotional side of a human agent. Let us consider what an emotional man might do.
A Defection in the Cooperative Enterprise.
Suppose the Audubon’s server fuses data records in a combination that clearly pinpoints a terrorist cell. Nobody at the Audubon Society knows this; the records are encrypted and, besides that, there are so many birds to count. The fused records go to both the FBI and the NYPD. At the FBI, the first person to realize the significance of the data is a low-level official stuck in the same grade for 8 years. Every individual has a rational element and an emotional one. The emotional side of this agent sees a clear path to getting ahead. The FBI agent acts swiftly. An FBI team closes down the terrorist cell and gathers up evidence including explosives. The story is splashed over the evening papers: “A clear and present danger was averted due to swift and competent FBI operations”. The FBI agent formerly stuck in grade is now on a fast track to a promotion.
Meanwhile the NYPD is not happy. To keep the FBI press release short and on-message, the FBI agent gave no credit to the NYPD. Thus, the NYPD has nothing to show for its use of the NT to gather information or its cooperation with the BEDM operation. According to Axelrod’s theory of cooperation, the NYPD is likely to switch to “tit-for-tat” mode. From now on, the reporting of NT data to the BEDM service will be lackadaisical and incomplete. Such a reaction punishes the FBI by reducing its chances for future successes. That is the proper rational response to what was originally an emotional choice. In the long run, it may bring the FBI around to better cooperation with the NYPD. But is a suboptimal outcome. Good work on the part of the NYPD goes unrewarded and future police work is undermined by a loss of cooperation.
Were it not for the strict encryption of all the information, the NYPD would be able to prove its contribution to the FBI’s achievement and demand proper credit. The encryption is strong, but we can provide an appeal mechanism by which the party who is wronged by a defection can obtain redress from a judge or arbitrator. Here is how it might work.
Here Comes the Judge.
Let us suppose that the DHS appoints a trustworthy arbitrator to adjudicate disputes arising in the use of BEDM. Furthermore, suppose we configure the Pygar software so that the BEDM broker keeps a historical record of the fused, encrypted data records while each party keeps a historical record of the keys that were used for each data fusion transaction. Now the following scenario is possible.
The NYPD first demands credit from the FBI but the FBI denies that it used NYPD data to break up the terrorist cell. Consequently, the NYPD appeals to the DHS appointed arbitrator. The NYPD has decoded the fused data records and could provide them as evidence to the arbitrator but the FBI could claim these records were fabricated. However, encrypted and date-stamped data records supporting the NYPD position are stored with the Audubon Society, a neutral party. The arbitrator requests a copy of the encrypted records from the Audubon Society. Meanwhile, the NYPD gives the arbitrator the transaction key necessary to decode the records. The arbitrator can then decode the fused data records, assess the merits of the NYPD claim, and rule on the validity of the claim.
We call this a normative process because it punishes bad behavior. In the long run, that helps develop a culture where people behave the right way because they must do so to avoid censure or penalty and to keep their standing in the community. In contrast, a culture in which members can get away easily with hurting or betraying each other will quickly become uncooperative and unproductive. This seems intuitively correct; moreover, the recent research on the evolution of cooperation supports the importance of normative mechanisms in developing effective cooperation between competing parties.
Consequently it is likely that the final version of the Pygar software will include the features necessary to set up a judge or arbitrator for disputes.
Postscript.
At the beginning, I said the scenario is plausible. Someone sufficiently high in the DHS would argue that the scenario is impossible because rules and regulations mandate cooperation. But that is not the real world agents and analysts live within. For a description of the real world I heartly recommend the article “Open Source Spying” by Clive Thompson in tbe Dec. 6, 2006 edition of the New York Times (or see Thompson’s blog: http://www.collisiondetection.net/mt/archives/2006/12/yesterday_the_n.php )