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.

Permalink


Copyright © 2015 Clif Burns. All Rights Reserved.
(No republication, syndication or use permitted without my consent.)