December 6, 1999

Mr. James Lewis
Bureau of Export Administration
Department of Commerce
P.O. Box 273
Washington, D.C. 20044

Re: CDT Comments on November Draft Encryption Regulation

Dear Mr. Lewis:

Thank you for the opportunity to comment on the draft encryption export regulations circulated on November 19, 1999. The Center for Democracy and Technology (CDT) appreciates the Administration¼s efforts to seek broad input on the regulations before they are released in "interim final" form.

The draft regulations do hold out the promise of real reform in U.S. export policy. If realized, the Administration¼s approach of largely removing most export controls on a broad category of encryption tools regardless of bit length and algorithm would be a welcome step forward. However, as released the draft regulations fall short of that promise in several important ways. For example:

• The definition of "retail," without further clarification, appears to a leave out a great deal of mass-market encryption that should be exportable. For example, the draft covers only retail products that are "sold," while today much software is transferred for free. Thus the regulations as drafted would fail to allow online distribution of some of the most popular browsers and other encryption software.
  
• Screening and reporting requirements, intended to keep U.S. encryption products from a few terrorist countries, could make it impractical to distribute even retail products the way most people get them ‚ through mass-market channels or over the Internet. This particularly impacts small business or individuals that do not have the resource to comply with complex mechanisms.
  
• Non-retail export limits, especially the broad definition of "government," make export of non-retail products extremely difficult, particularly for small businesses or individuals.
  
• The provision on source code exports appears to apply to "non-proprietary" source code so narrowly defined as to be of little help, and the limitation on downstream use in foreign products, unless clarified, threatens to chill source code exports.

CDT has long believed that encryption is essential to the protection of privacy and security online, and that U.S. export controls have harmed personal privacy on the Internet. There are two metrics against which reform in U.S. export controls should be measured:

• Do the new export controls allow people around the world to get access to the strong encryption tools they need to protect their privacy? In particular, can people get strong encryption the way they need to in the Information Age ‚ built-in to the products they use everyday, available in software packages sold over the counter, and available for download over the Internet?
  
• Do the new export controls allow people to participate in the information economy without running afoul of U.S. export law? Do the regulations allow, for example, individuals exchanging software with a family member abroad, graduate students working on open source projects, human rights groups equipping their field workers, or information entrepreneurs distributing new products or services online, to do so easily without violating export laws?

The Definition of "Retail"

The potential relaxation of controls on retail products is the area likely to achieve the most widespread advances in protecting privacy by giving consumers access to strong encryption in the popular products they use every day. However, as written the draft appears to limit this relaxation so that it might not apply to many important encryption products. Fast-paced changes in the computer industry, and the Internet in particular, are making traditional concepts of product distribution and marketing obsolete. The regulations need to reflect an understanding of the unique nature of the new online medium. Some specific problems include:

• "Sold" instead of "transferred" ‚ In Part 740.17(3) of the draft, the definition of retail in parts (a) and (b) refer to products which are "sold." Popular products containing encryption such as web browsers, ISP software, or Pretty Good Privacy (PGP) are not always sold, but often distributed online for free.

• "Sold directly by the manufacturer" ‚ Important encryption products like browsers or e-commerce tools are often not obtained by consumers directly from the manufacturer, but rather through an intermediary such as an ISP or a distributor. For example, PGP is widely distributed through MIT¼s web site. Browser software may be distributed by ISPs. Such products appear left out of the current definition of retail.

• "Specifically designed for individual consumer use" ‚ It would be helpful to make clear that retail treatment will apply to products that have both individual consumer use and other uses. For example, a web browser may be designed for consumer use but also have business applications.

Screening and Reporting Requirements

As online activity becomes an important part of life for more people and the information economy grows, encryption may increasingly be distributed by small companies, non-commercial organizations, and individuals. These potential exporters are not likely to be familiar with U.S. export regulations, not will they have the resources to comply with complex procedures for export. Thus reporting procedures or requirements for screening out certain kinds of export recipients ‚ such as the seven designated "terrorist" countries (the "T-7" countries) ‚ threaten to chill a great deal of encryption export without further clarification. Even for larger organizations, onerous screening or reporting requirements could make it difficult to distribute strong encryption through retail channels.

• Screening: Depending on the screening measures required for compliance, screening for T-7 countries or other types of end-users could be impractical for many individuals and organizations. The ultimate effect of the regulations will depend on what level of certainty the Department is willing to accept. It is extremely difficult, if not impossible, for most exporters to guarantee that no T-7 citizens access an encryption product through a retail channel or anonymous download. Even some of the most likely possible approaches may be at the edge of the practical capabilities of many encryption distributors. Domain-name lookups are already beyond the resources of some potential exporters. Web-based questionnaires likely add little effective protection.

  The final regulation should include some examples of procedures that could be used to comply with the screening requirements. (If the Department makes these examples illustrative it should be able to avoid the pitfalls of driving the market for any one distribution mechanism.) In general, the final regulations should not allow screening to destroy the ability of individuals and organizations large and small to distribute encryption through mass-market channels and over the Internet.

• Reporting: Software is increasingly distributed by anonymous downloads, and reporting requirements should support anonymous downloads of otherwise exportable encryption products and source code. The reporting exemptions in 740(g) should be clarified to make this clear; in particular the exemption for retail products exported to individuals in 740(g)(1)(iv) should reflect the fact that for Web distribution it will be very difficult to distinguish between individual consumers and others.

As written, the regulations make distribution of non-retail encryption extremely difficult. By defining "government" to include quasi-governmental agencies, government corporations, and state enterprises, the regulations would appear to place exporters at risk for failure to identify the employees of local or regional governmental entities in foreign countries, state-run corporations, or even corporations that are seemingly public but may be partially state-owned. A narrower definition, as well as an explanation of what screening will be required for compliance, is badly needed.

Encryption Source Code

While the Administration¼s attempt to liberalize source code exports is welcome, the problems with screening requirements and incorporation in foreign products raise special concerns in the context of non-commercial source code. The open source movement in particular is based on the widespread, repeated, and (by necessity) low cost exchange of source code among a diverse group of individuals and small and large organizations. Source code exporters, and especially those who work on open source projects, are less likely to have either a good understanding of complex export regulations or the resources to comply with them. Further clarification is badly needed for what is meant by the T-7 screening requirements, the foreign use restrictions, and the definition of "non-proprietary."

• Screening for T-7 Exports: Simple, easy-to-implement safe-harbor procedures should be established for non-commercial source code exporters to demonstrate compliance with a prohibition on exports to T-7 countries. Especially for those without experience in export control compliance, expensive screening requirements could chill any potential exports of encryption source code. For example, a complex web-based questionnaire seeking to record and/or verify addresses and nationalities of recipients would likely prove impractical for many open source contributors.

• Downstream Foreign Use of Source Code: Further explanation is badly needed for the provision requiring that, "Source code released under this provision remains of U.S. origin even when used or commingled with software or products of any origin." The regulations should clearly state that U.S. source code exporters would not be liable for downstream distribution or incorporation into foreign products. The regulation should also make it clear that a foreign software developer who uses source code legally exported from the U.S. does not somehow violate U.S. export laws if they incorporate the source code into their products outside of the U.S. For example, a German developer using U.S. source in their product should not violate U.S. law by exporting that product from Germany to the U.K.

• Definition of "Non-Commercial:" As written, the provision allowing export of source code applies only to source code that is "not subject to any proprietary commercial agreement or restriction." On its face, the language of the draft seems to exclude a vast amount of publicly available source code from export relief. For example:
  • Source code may be distributed for non-commercial purposes ‚ such as scientific research or information exchange ‚ while the author still retains a copyright.
    
  • Free source code might implement algorithms which are patented and therefore subject to a "proprietary commercial ä restriction".
    
  • Open source code is often exchanged freely but ultimately subject to proprietary arrangements for distribution under commercial circumstances.
  Would such exports be allowed? Since many source code distributors in particular do not have lawyers to interpret regulations for them, unless clarified this provision is likely to do little to free much source code for export.

Conclusion

Thank you for the opportunity to comment on the draft regulations. If we can offer any further assistance or clarification to the points raised here, please feel free to contact us.

Sincerely,

Alan Davidson
Staff Counsel

Center for Democracy and Technology
1634 Eye Street NW Suite 1100
Washington, DC 20006
(202)637-9800
abd@cdt.org

Free Speech | Data Privacy | Government Surveillance | Cryptography | Domain Names | International | Bandwidth | Security | Internet Standards, Technology and Policy Project | Terrorism | Authentication | Right to Know | Spam

Our Mission / Get Involved / Staff / Publications / Links / Search CDT / Jobs / Action! Previous Headlines | Legislative Tracking | CDT's Privacy Policy