The other day my account on the Sun Java Forums stopped working because an account screening system had found a match between some details of my account and the names on the DRPL defined by Sun as an agglommeration of various Government lists.

The basic reason behind this is, I think, fairly extraordinary. In essence, the government list had an entry that was just "David" and since there were no other details for Sun's system to check against, my account name that included "Dave" was caught.

I have nothing but contempt for these government lists. They strike me as being the worst kind of bureacracy; they will prevent nothing and inconvenience only the honest people caught by them and the companies that are required (by law) to implement them even for software, the world's most easily smuggled commodity!

On the other hand, I don't want to be too scathing about Sun. They have a legal obligation to honour these lists that they cannot duck. While they definitely cocked up slightly on the implementation, bad data in the original government lists was the primary cause and I have to give Sun points for the following:

• They had a manual process to catch problems
• They were fairly swift about fixing the problem
• They were admirably open about explaining the cause of the problem

That last point is, to me, extremely important. What follows is the full explanation that I was given of the problem, with personal contact details removed:

Dear Dave,

As [redacted], indicated in her message to you earlier this evening, she and I worked together so that I could provide you with an explanation for the online access denial you experienced this week.

I'm a senior manager in Sun's International Trade Services organization (ITS). Since I'm responsible for the Sun Denied and Restricted Party screening process (DRPL), we decided that the explanation should come directly from me. First, let me apologize for the online access denial that you experienced.

I'll explain the following:

• Why it happened
• What's been done to fix it
• The longer term corrective action

WHY IT HAPPENED

There were three factors driving your access denial:

• In migrating from a less robust DRPL screening service, previously registered customers were automatically subjected to re-screening
• Out of 25,000 entries that the U.S. government publishes for use in screening customers or transactions, we found there are two listings that only contain the name "David". Existing customers, such as yourself, whose name included "David" or "Dave" in their online account registration were automatically denied service because of an apparent match to a U.S. government listing
• Sun uses an alias feature in this new DRPL screening service that enables it to automatically to search against matches for common equivalent names, such as Dave=David, Robert = Bob etc.

In order to avoid a high number of false DRPL matches, Sun's International Trade Services organization (ITS) had decided on the following high threshold for an exact match:

customer name OR address AND city AND country

However, since two DRPL listings only contained the name "David", the address, city and country information of a customer were disregarded for screening purposes, and exact matches were flagged by the DRPL screening application. Compounding this problem was the use of the equivalent name functionality, so that not only were customers flagged whose name included "David", but also those such as yourself whose online registration included "Dave".

WHAT'S BEEN DONE TO FIX IT

Two corrective actions have been taken:

• The ITS DRPL operations team was mobilized to remove any DRPL holds against online accounts that had triggered a match because of the name "David" or "Dave". This effort was completed on Wednesday afternoon, Pacific Standard time
• We nullified the future screening of customers against these "David" entries, the fix was tested successfully and was migrated to the production instance of our compliance application on Wednesday afternoon

We also searched the DRPL and found an additional 24 single names on the DRPL without complete name, address, city and country data. We used a feature of the compliance application called an "exclusion list" to remove the two "David" entries and these additional 24 single names for future screening purposes.

THE LONGER TERM CORRECTIVE ACTION

Although the ideal corrective action would be to convince the U.S. government that it should only include parties on the DRPL if it can publish complete, name, street address, city and country information, this lobbying effort would take too long. So, my team and I are already working with our DRPL content provider, who consolidates the various government agency listings into a usable format, to determine the feasibility of systematically excluding any DRPL content that doesn't meet our data completeness requirements.

In addition, we intend to evaluate the technical feasibility and cost of differentiating when the same online customer may be engaged in activity that doesn't warrant DRPL screening from events that do, such as downloading software that comes under the scope of the U.S. Export Administration Regulations.

Sincerely,

[redacted]

Note that I have permission from Sun to publish the above and the following two additional comments.

I did have a couple of concerns about this, which were also answered quickly:

Dave: If you do not provide feedback to the US government about problems arising from the DRPL, who will? Your DRPL content provider, if a third party, is not a disinterested party since they evidently stand to gain from complexity and problems.

Sun: Your point is well taken. My answer should have been more clear.

Sun's International Trade Services organization (ITS) has a senior manager in Washington, D.C. who actively lobbies for needed changes in the U.S. Export Administration Regulations, as well as in the Bureau of Industry and Security's compliance processes. However, I don't want to rely on lobbying to drive the longer term solution to the DRPL data completeness issue we encountered. It doesn't mean that ITS is unwilling to make a case for such changes.

Dave: It worries me that you are expanding the list by searching for aliases (Dave for David etc.) I can see the technical allure of a "clever" solution, but personally I would be inclined to a grudging literal interpretation if I couldn't duck the requirement in the first place.

Sun: While your concern is understandable, using alias or equivalent name functionality in automated DRPL screening is a standard feature of such applications. It's quite common for people to engage in transactions that are within the scope of the U.S. Export Administration Regulations without using their legal name or names, so equivalent name screening mitigates the risk that we could fail to detect a match simply because of this.

I don't completely buy that last one. However standard a feature it is, I would be reluctant to do more than the absolute legal minimum for this sort of application; whether aliasing is required by law I don't know, but it seems unlikely.

I still can't quite believe that I got snagged as an undesirable for being called "Dave." My friend Ian Griffiths submitted the initial blog entry on this to Slashdot (not accepted) with the title "Dave Considered Harmful", and I considered that an amusing exaggeration. Truth, it seems, really is as strange as fiction.

Ah well, at least I can go to JavaOne this year! Let's just hope the No Fly List isn't based on the same crummy data...