From: "E. Allen Smith" <EALLENSMITH@ocelot.Rutgers.EDU>
Date: Wed, 5 Mar 1997 14:50:12 -0800 (PST)
To: gbroiles@netbox.com
Subject: Re: The Pro-CODE Bill could make things worse!
Message-ID: <01IG5GWYDFLG8Y5EZW@mbcl.rutgers.edu>
MIME-Version: 1.0
Content-Type: text/plain


From:	IN%"gbroiles@netbox.com"  "Greg Broiles"  5-MAR-1997 10:04:19.81

>I don't think that Pro-CODE can be used to control the dissemination of
>remailers. The bit of Pro-CODE at issue here (section 5(c)(3)(B) "The
>Secretary shall prohibit the export or reexport of particular computer
>software and hardware *described in this subsection* to an identified
>individual or organization . . if the Secretary determines that there is
>substantial evidence that such software and computer hardware will be . .
>(iv) intentionally used to evade enforcement of US law or taxation by the
>US or by any State or local government." (emphasis added)

>I read "described in this subsection" to refer to Section 5(c), and the
>best description I can find in 5(c) of computer hardware and software is
>"computer hardware, computer software, and technology with encryption
>capabilities, except computer hardware, computer software, and technology
>that is specifically designed or modified for military use, including
>command, control, and intelligence applications", in section 5(c)(1).

>So I don't think that this creates a new ability to control the
>dissemination of non-crypto hardware or software. (The Mixmaster remailer
>software, which does include crypto, would still be controlled.) 

Umm... non-encrypting remailers aren't much use. While something could
be worked out (as for most current Type 1 remailers) allowing hooking in
PGP or whatever, I would wonder whether that would make the remailer
program itself have "encryption capabilities" - a la the "crypto hooks"
restrictions in current export regulations. This would be even more of
a problem for remailers using socket links and DH superencryption to
prevent remailer operators from being pressured to decrypt intercepted
messages.

These prohibitions would also prohibit or at least restrict export of
technologies such as decense and the anonymizer in versions (as is
preferable) using encryption, except _possibly_ (see above) those
hooking in encryption from outside. Circumstances in which such
could be used to defeat US laws include a decense server being used to
prevent the tracing of an in-US pornographic site, if (heaven forbid)
the CDA (or a lesser version, such as one requiring labeling or going
by a "harmful to minors" standard) is found constitutional.

>The prohibitions on export to named individuals and organizations will be
>effectively useless with respect to those parties getting strong crypto -
>the only utility I can see in such a clause is to be used as a club against
>domestic sympathizers/allies of unpopular groups/people abroad. It also
>seems likely to lead to yet another round of worrying about whether the
>format of a particular distribution site on the Internet is sufficiently
>configured - if ProCODE passes, instead of asking "Are you a US citizen?",
>distribution sites will ask "Are you on the list of forbidden people?" Same
>difference. 

It is rather reminiscent, yes. If, for instance, all it requires is a check
on whether the domain name indicates the _certainty_ of being from such a
country, then it won't be extremely onerous... but I'm certain that the
government will try to interpret it in the most restrictive way possible.
	-Allen