After the uproar generated by the proposed amendments to the Export Administration Regulations to implement the Wassenaar Arrangement’s rules controlling “intrusion software,” the Bureau of Industry and Security (“BIS”) tried to calm things down by issuing some FAQs on the proposed rules. Sadly, I don’t think these FAQs are as helpful as BIS apparently thinks that they might be.

To understand the difficulty here, let’s focus on the problem I discussed in this post indicating that the new controls could reach auto-updaters, like the one in Chrome, that bypass operating system protections designed to prevent installation of new software without user interaction. The FAQs now say explicitly that auto-updaters are not covered. That is a good thing, and you (that means you, Google) can take that statement to the bank.

But the reasoning that BIS uses to reach this conclusion is dicey at best. Here it is:

Does the rule capture auto-updaters and anti-virus software?

No. Software that permits automatic updates and anti-virus tools are not described in proposed ECCN 4D004. ECCN 4D004 software must be specially designed or modified for the generation, operation or delivery of, of communication with, “intrusion software,” which is separately defined. Software that automatically updates itself and anti-virus software may take steps to defeat protective countermeasures, but they are not generating, operating, delivering, or communicating with “intrusion software”.

The problem with this analysis starts with the fact that BIS admits that an auto-updater is “intrusion software.” That’s an inescapable conclusion, of course, because the auto-updater overides operating system requirements that require user interaction to install new programs and does so to modify system data by installing the new program. But, we are told by BIS, the auto-updater doesn’t generate, operate, deliver, or communicate with “intrusion software.” Well, that might make sense if the auto-updater is a cyber-version of parthenogenesis and pops into existence completely unaided. That, of course, is nonsense. Some program, either the auto-updater itself or some other lines of code in the programbeing updated have to be specially designed to operate, deliver or communicate with the auto-updater for it to work at all. And so that code, either as part of the updater or the program itself, is covered by the ECCN. In short, an auto-updater unless accompanied by a program covered by the new ECCN is useless and will not work at all.

The problem here is unavoidable because of the EAR’s broad definition of program:

A sequence of instructions to carry out a process in, or convertible into, a form executable by an electronic computer

The lines of code in Chrome that deliver the auto-updater are, without question, a sequence of instructions convertible in a form executable by a computer, i.e. a program, specially designed to deliver other lines of code to defeat operating system protections requiring user interaction before modifying system data. If Chrome is exported with those lines of code that deliver the auto-updater it needs a license; if those lines of code are stripped from Chrome, it can be exported but it will not auto-update.

Of course, BIS has made it clear that it does not think auto-updaters are covered, so I don’t think Google needs to worry about violating the law. Unfortunately, the reasoning that BIS used to reach this conclusion is nonsense.

At long last, and well after the E.U. and many other members of the Wassenaar Arrangement, BIS has released proposed (but not final) rules implementing the December 2013 changes adopted by the Arrangement and which imposed export controls on “intrusion detection software” and “IP network communications surveillance” systems and equipment. After the E.U. adopted the 2013 changes in October 2014, we speculated that the delay by BIS beyond its announced September 2014 date for releasing a proposed rule was that it perhaps was struggling with the impact of Wassenaar’s overbroad definition of “intrusion detection software.” But we were wrong.

The proposed rule adopts the Wassenaar changes without clarification of the scope of coverage of intrusion detection software. Instead, the delay seems to have been wholly occasioned by housekeeping matters: specifying the reasons for control, deciding that no license exceptions would apply, and so forth. The proposed BIS rules also grapple with a rather esoteric problem: what to do with intrusion detection software with encryption functionality. And it decides that the software is classified, and must comply with, both ECCNs, which, at last, concedes something BIS long said was impossible: that an item could have two ECCNs. Finally, and I’m not joking, so I’ll quote the agency itself to prove that I’m not

[a] reference to §772.1 is proposed to be added to ECCNs 4A005, 4D001 and 4E001 to point to the location of the ‘‘intrusion software’’ definition, as this rule may be of interest to many new exporters that would not otherwise know that double quoted terms in the EAR are defined in §772.1.

Seriously? Now BIS starts to worry about the indecipherability of the EAR and the secret rules of interpretation that must be applied? What next? Will proposed rules start spelling out “n.e.s.”?

But, all joking aside, the problems with the definition of intrusion software remain

‘‘Software’’ ‘‘specially designed’’ or modified to avoid detection by ‘monitoring tools,’ or to defeat ‘protective countermeasures,’ of a computer or network-capable device, and performing any of the following: (a) The extraction of data or information, from a computer or network-capable device, or the modification of system or user data; or (b) The modification of the standard execution path of a program or process in order to allow the execution of externally provided instructions.

The notes indicate that protective measures include “Data Execution Prevention (DEP), Address Space Layout Randomization (ASLR) or sandboxing.”

Many have pointed out this definition would cover programs that permit auto-updating without user intervention, such as, for example, the Chrome browser, which updates itself in the background and circumvents protections normally imposed by the operating system to prevent installation or modification of programs without user intercession. Address Space Layout Randomization (ASLR) loads program components into random addresses in memory as a security measure against buffer overflow attacks and yet legitimate programs that must “hot-patch” operating servers or systems must scan memory to locate the program components, thereby both extracting data and defeating ASLR. The definition of sandboxing as a protective measure will subject programs that permit rooting or jailbreaking of mobile telephones to export controls.

I don’t normally try to look into a crystal ball and make predictions about the future, but I see clearly a flood of classification requests by software developers.