December 2003 - cypherpunks-legacy

New rules for Internet sales to CA buyers
by Greg Broiles 17 Dec '03

17 Dec '03

The following subsection of California Business & Professions Code section 17538 took effect 1/1/97 and may be of interest to people following state attempts to regulate net sales: [...] (d) A vendor conducting business through the Internet or any other electronic means of communication shall do all of the following when the transaction involves a buyer located in California: (1) Before accepting any payment or processing any debit or credit charge or funds transfer, the vendor shall disclose to the buyer in writing or by electronic means of communication, such as E-mail or an on-screen notice, the vendor's return and refund policy, the legal name under which the business is conducted and, except as provided in paragraph (3), the complete street address from which the business is actually conducted. (2) If the disclosure of the vendor's legal name and address information required by this subdivision is made by on-screen notice, all of the following shall apply: (A) The disclosure of the legal name and address information shall appear on any of the following: (i) the first screen displayed when the vendor's electronic site is accessed, (ii) on the screen on which goods or services are first offered, (iii) on the screen on which a buyer may place the order for goods or services or (iv) on the screen on which the buyer may enter payment information, such as a credit card account number. The communication of that disclosure shall not be structured to be smaller or less legible than the text of the offer of the goods or services. (B) The disclosure of the legal name and address information shall be accompanied by an adjacent statement describing how the buyer may receive the information at the buyer's E-mail address. The vendor shall provide the disclosure information to the buyer at the buyer's E-mail address within five days of receiving the buyer's request. (C) Until the vendor complies with subdivision (a) in connection with all buyers of the vendor's goods or services, the vendor shall make available to a buyer and any person or entity who may enforce this section pursuant to Section 17535 on-screen access to the information required to be disclosed under this subdivision. (3) The complete street address need not be disclosed as required by paragraph (1) if the vendor utilizes a private mailbox receiving service and all of the following conditions are met: (A) the vendor satisfies the conditions described in paragraph (2) of subdivision (b) of Section 17538.5, (B) the vendor discloses the actual street address of the private mailbox receiving service in the manner prescribed by this subdivision for the disclosure of the vendor's actual street address, and (C) the vendor and the private mailbox receiving service comply with all of the requirements of subdivisions (c) to (f), inclusive, of Section 17538.5. --- Legislative history can be found at <http://www.leginfo.ca.gov/cgi-bin/postquery?bill_number=ab_3320&sess=PREV&h ouse=B> -- Greg Broiles | US crypto export control policy in a nutshell: gbroiles(a)netbox.com | http://www.io.com/~gbroiles | Export jobs, not crypto.

4 3

it's back up again
by cybersource＠pwrnet.com 17 Dec '03

17 Dec '03

Hi, I just wanted to take a moment and let some of the folks with whom we've participated in online discussion on the Usenet boards know that our website if finally back up! Please feel free to visit us there. Have a great New Year! The Downline Experience http://lifequest.net/tronix/ 1-800-678-5522 ext 8056 "Timing is everything... but positioning is critical!" (Larry Thompson -- Mentor to the Millionaires 1996)

1 0

Re: OCR and Machine Readable Text
by Bill Stewart 17 Dec '03

17 Dec '03

It's really embarassing to have to pay salaries of "public employees" who can't come up with better arguments than the paper/magnetic/OCR nonsense but don't have the guts to stop trying and admit they've wrong. Does the President still make $200K/year salary? You'd think he'd either read what he signs or tell his employees to only ask him to sign at least half-way credible stuff. The old regulations used to pretend that foreigners were too dumb to implement computer programs from algorithms; now they're pretending that foreigners are too dumb to type.* People used to say we have the best politicians money can buy, but you ought to be able to buy better politicians than that. At 10:31 AM 12/30/96 -0800, Tim May wrote: >And not only is OCR able these days to handle general fonts easily enough, >but almost all printed code is in fixed-width fonts, i.e., non-proportional >fonts. This makes OCR easy. The basic difference between "easily OCRed source code" and "not easily OCRed source code" is pretty much limited to two things 1) Half-decent print quality (black on white in Courier at 300dpi should do....) As Tim says, this stuff is child's play. Back when OCRs were $10,000 machines with cutting-edge 68010 processors, reading Courier was pretty easy but it helped to put in checksums; these days you don't really need that. (It also didn't like wet-process 240-dpi laser printing or faxes, but modern OCR software can generally deal with good-quality faxes and 2) Bound pages vs. loose pages (printing with perforated pages or selling the source code in loose-leaf might count as an "attractive nuisance" :-), but a band-saw can solve that problem for the OCR user unless it's printed on Tyvek or something silly :-) In the Karn case, the Feds made the silly argument that the floppy disk version had the files neatly separated, while the paper version split files between pages and had page numbers at the bottoms of the pages that weren't part of the source code. Even the $10K 68010 wonderbox could handle page headers/footers and margins, and modern software can do decent translations into different word processor formats. >For just the amount of money we've spent (in our consulting fees) on >discussing just this issue of OCRing, the entire content of the MIT PGP >source code book AND Schneier's AC could have been manually inputted by >Barbadans or Botswanas, or probably even by Europeans. There's one German university that OCRed the MIT PGP source code book. The PGP folks passed out copies of their new 3.0 Pre-Alpha and an update at a recent Cypherpunks meeting. See http://www.pgp.com/newsroom/sourcebook.cgi for ordering informaiton. It's been donated to some local libraries, such as San Jose CA, and I hope they'll send it to the Library of Congress and various non-US university and other public libraries - the recent rules change clarifying that it's ok to export source code should make this much easier. [* OK, it's not really possible to type or proofread perl code accurately :-) More to the point, OCRs aren't always real good about `backquotes' and other little blotchy marks that some languages use, and even humans don't always get them right.] # Thanks; Bill # Bill Stewart, +1-415-442-2215 stewarts(a)ix.netcom.com # You can get PGP outside the US at ftp.ox.ac.uk/pub/crypto/pgp # (If this is a mailing list, please Cc: me on replies. Thanks.)

1 0

"Onion Routing" Pipenet-like project at NRL
by Bill Stewart 17 Dec '03

17 Dec '03

http://www.itd.nrl.navy.mil/ITD/5540/projects/onion-routing/overview.html Michael G. Reed, Paul F. Syverson, and David M. Goldschlag have a bunch of papers on the Naval Research Laboratory Information Technology Division web site about Onion Routing, a pipenet-like anonymous communication system that sets up chains of encrypted IP tunnels between servers. # Thanks; Bill # Bill Stewart, +1-415-442-2215 stewarts(a)ix.netcom.com # You can get PGP outside the US at ftp.ox.ac.uk/pub/crypto/pgp # (If this is a mailing list, please Cc: me on replies. Thanks.)

1 0

EAR Doc
by John Young 17 Dec '03

17 Dec '03

We've prepared a hyperlinked version of the Export Administration Regulations (EAR) to assist analysis, evaluation and commentary on interim rules for encryption export: http://jya.com/eartoc.htm It's sobering to study the EAR and see the lethal weapons to which encryption is wed -- the most mass-murderous of high-technology calmly described as commercial warfare for the commonweal. Ponder the Commerce Control list to see the mayhem elite minds concoct.

2 1

Re: cookies
by kimkl＠calweb.com 17 Dec '03

17 Dec '03

>Return-Path: <rwright(a)adnetsol.com> >Comments: Authenticated sender is <rwright(a)adnetsol.com> >From: "Ross Wright" <rwright(a)adnetsol.com> >Organization: King Media and RW Marketing >To: kimkl(a)calweb.com (Kimberly Leahy) >Date: Wed, 1 Jan 1997 23:01:11 -0800 >Subject: Re: cookies >Priority: normal >X-UIDL: f3b0b16d616765cf37b9c5fa5150407f > >Send an inquiry to cypherpunks(a)toad.com You will get many >informative answers! >I be looking for your inquiry, I read that list also! > >On or About 1 Jan 97 at 21:55, Kimberly Leahy wrote: > >> Rossta, >> please enlighten on cookies that invade a browser's >> computer. where can i get more info? i was told that >> a utility is available to track and/or crush cookies. >> can you tell me where to get it or get info on such a >> thing? >> hopefully, >> kimmer >> >> > >=-=-=-=-=-=- >Ross Wright >King Media: Bulk Sales of Software Media and Duplication Services >http://www.slip.net/~cdr/kingmedia >Voice: 415-206-9906 > Cypherpunks, would you please send me infor or direct to a location where I may acquire information of these "cookies"? Thank You Ever So Much.

1 0

Cypherpunk Elitism and Spam Filters
by Alan Olsen 17 Dec '03

17 Dec '03

I have been watching the debate on Cypherpunk Extremism, filtering spam, and the like and have a few comments. When Tim May claims that Cypherpunk solutions lead to elitism, he is more correct than Vullis or any of his ilk are willing to realize. The reasons for this are out of implementation, not out of any ill-will or evil intent. It is because it requires special knowledge and/or software to be able to implement the "solution(s)". (Note that I am only aware of his comments through quotes of his material. I have blocked him at the procmail level, so I cannot go back through trash and read the originals. Probably a good thing, as it keeps me from sinking to the level of flames and personal attacks. Attention Vullis revels in...) I have watched the conversations on filtering and have seen few, if any, methods that would be usable by a poster of average experience without alot of extra frustration and/or time involved. For a filtering or posting method to be useful (or used), it has to be uncumbersome to use, no matter the platform. Charging for posting is not (in my opinion) a good method because conversions from real cash to e-cash are not very easy and/or available at this time. It would leave the posting to the "elite" who have connections to e-cash acceptable to the list management. Tokens are nice, but most plans for them make it a pain to post with any sort of e-mail software. (Cut and pasting a token will work for one or two sites, but if a user posts to many lists, keeping track of all those tokens could become quite a pain. There is also the risk of people posting their tokens for general use or the token being used to track anonymous posters. PGP signatures are a solution, but not a very adequate one at this point. Most autosign software has one or two minor problems. The first is that they do not line wrap before signing the text. This causes the sig to break. The second thing that people get bitten by is that some signing software only takes the "default" key. This means that, without special effort, they are stuck with one key to use for signing. (Which makes anon postings a bit of a pain.) The reason anon.penet.fi became as popular as it did is because it was easier to use than the alternatives. A solution that is difficult to use will be left to an "elite" to use. (If used at all.) A good example of this is the PGP aware version of Majordomo. The traffic on one list using that software is little to none. I believe that this is because the "ante" to post is too high. (It also has strange desires for specific linefeed formats, as well as other things that make posting a chore.) The "solution" to this is to design tools that make use of these things usable, not only for the "elite", but for the rest of the user community. (Or at least the upper 70-90%. There has to be some level of knowledge for entry into the game. The difficulty is knowing where to set that "bar".) Netscape is a good example of "transparent" crypto. It has problems though. How many sites do you connect to that use SSL? Damn few I will bet. How many encrypt everything, not just the "important stuff". Next to none. Why? Getting a secure server costs a fair chunk of change. It is possible to get one for "non-commercial use", but it is still going to cost you a bit for the certificate needed to run the server. ($295 bucks and the list of hoop to jump through. Verisign usually wants you to be a corporate entity.) Any chance of a CPunk CA coming into existence any time soon? A better chance for "transparent" security is with the IPSec FreeSwan project. How many of you out there are willing to put in the effort to get it to work though? It does have a pretty high cost in knowledge and effort. (It also seems to have some places that need work. Non-Unix clients and sites feeding off of dynamic IPs are going to be a future hurdle.) It does have probability of making things a whole lot more difficult for the busybodies at the various TLAs. (The NSA krill nets will no longer be as effective.) Until the bugs are worked out, it will be an "elitist" solution. There is no escaping that. (And since there are people who would rather concentrate on personal feuds instead of technical hurdles, it will probably remain one for alot longer.) I would like to see alot less of the "elitist" solutions. My reasons are very plain. Elitist solutions take far too much of my time to use. They do not have to be that way. There are Cypherpunks doing work to make these tools more usable. Most of them are doing it in the background and not looking for the "glory". Because of the self-centered ranting of a few, most of those who were the strongest supporters of "Cypherpunk goals" no longer associate with the list. The ones who have my highest respect are those that have actually done something to accomplish those goals, instead of writing (semi-)anonymous flames and personal attacks against Tim May and/or John Gilmore. (I sometime what Vullis has done to promote privacy and security for individuals. His pissing in the list pool certainly has done nothing positive that I have seen.) [Note that I do not always agree with Tim May. There have been many time I have read his posts and wondered if he was indulging in chemical recreation. (And he has probably wondered the same about some of my posts. probably about this one...) Sometimes he is dead on and well worth reading. But his posts are at least thought out and lack the most of the vitriol that some others on this list have been spitting. Part of the problem with reputation schemes is that humans are not always consistent. Sometimes they do not fit into the "yes" or "no" boxes we try and stuff them into.] Those who are working towards "elitist" solutions are at least working towards solutions. I think people need to ask themselves what goals they desire for themselves and what it will take to get there. You don't need to write code necessarily, but you do need to do something other than just bitch and moan. What have you done to support privacy today? --- | If you're not part of the solution, You're part of the precipitate. | |"The moral PGP Diffie taught Zimmermann unites all| Disclaimer: | | mankind free in one-key-steganography-privacy!" | Ignore the man | |`finger -l alano(a)teleport.com` for PGP 2.6.2 key | behind the keyboard.| | http://www.ctrl-alt-del.com/~alan/ |alan(a)ctrl-alt-del.com|

4 3

Re: OCR and Machine Readable Text
by Alan Olsen 17 Dec '03

17 Dec '03

At 08:06 PM 1/2/97 -0800, Bill Stewart wrote: >It's really embarassing to have to pay salaries of "public employees" >who can't come up with better arguments than the paper/magnetic/OCR nonsense >but don't have the guts to stop trying and admit they've wrong. >Does the President still make $200K/year salary? You'd think he'd either >read what he signs or tell his employees to only ask him to sign >at least half-way credible stuff. The old regulations used to pretend that >foreigners were too dumb to implement computer programs from algorithms; >now they're pretending that foreigners are too dumb to type.* >People used to say we have the best politicians money can buy, >but you ought to be able to buy better politicians than that. Or beter excuses. >At 10:31 AM 12/30/96 -0800, Tim May wrote: >>And not only is OCR able these days to handle general fonts easily enough, >>but almost all printed code is in fixed-width fonts, i.e., non-proportional >>fonts. This makes OCR easy. > >The basic difference between "easily OCRed source code" and "not easily >OCRed source code" is pretty much limited to two things >1) Half-decent print quality (black on white in Courier at 300dpi should do....) > As Tim says, this stuff is child's play. Back when OCRs were > $10,000 machines with cutting-edge 68010 processors, > reading Courier was pretty easy but it helped to put in checksums; > these days you don't really need that. (It also didn't like > wet-process 240-dpi laser printing or faxes, but modern OCR software > can generally deal with good-quality faxes and >2) Bound pages vs. loose pages (printing with perforated pages > or selling the source code in loose-leaf might count as an > "attractive nuisance" :-), but a band-saw can solve that problem > for the OCR user unless it's printed on Tyvek or something silly :-) Even an exacto-knife would work. For proportional fonts it depends on how nasty the kerning gets and the shape of the characters. (And a san serif font without too many kerning pairs should go though fine.) The technology for this has progressed quite a bit in the last few years. Next thing you know, OCR software will be export controlled as well. (Or they will require something silly, like having all code samples in caligraphy fonts.) >In the Karn case, the Feds made the silly argument that the >floppy disk version had the files neatly separated, while the >paper version split files between pages and had page numbers at the >bottoms of the pages that weren't part of the source code. >Even the $10K 68010 wonderbox could handle page headers/footers and margins, >and modern software can do decent translations into different >word processor formats. And even if it didn't, just selecting and deleting the margin areas would not be all that difficult. (Ooohhh... A couple of extra hours is really going to slow someone down.) >>For just the amount of money we've spent (in our consulting fees) on >>discussing just this issue of OCRing, the entire content of the MIT PGP >>source code book AND Schneier's AC could have been manually inputted by >>Barbadans or Botswanas, or probably even by Europeans. I used to work for a company that would transfer entire archives of medical journals. Much of it we would just OCR. Some of it we would send off shore. The OCR software was about 95% reliable and this was over 5 years ago. (And we were using 286 boxes for much of the OCR work. Not a heavy technoligical investment.) I am sure that things have improved a great deal since then. (My new scanner included OCR software. I will have to run a test and report the findings. >There's one German university that OCRed the MIT PGP source code book. >The PGP folks passed out copies of their new 3.0 Pre-Alpha and an update >at a recent Cypherpunks meeting. See >http://www.pgp.com/newsroom/sourcebook.cgi >for ordering informaiton. It's been donated to some local libraries, >such as San Jose CA, and I hope they'll send it to the Library of Congress >and various non-US university and other public libraries - the recent >rules change clarifying that it's ok to export source code should make >this much easier. The page listed does not contain order information. Do you know costs and/or order info? >[* OK, it's not really possible to type or proofread perl code accurately :-) Yeah, just look at what happened with John Orwant's _Perl 5 interactive Course_. The book is being recalled due to all the typographical errors from the pubisher. Reading some Perl code is also quite impossible. (For the reasons behind this, i recommend Charlie Stross's article on the tpoic on page 36 of _The Perl Journal_ #4.) >More to the point, OCRs aren't always real good about `backquotes' and other >little blotchy marks that some languages use, and even humans don't always >get them right.] Many character sets are not very good at displaying "little used" characters clearly. (Some of the cheaper fonts do not even include them.) Backticks are a special problem. The latest Camel book has all sorts of problems with hard to recognise backticks. BTW, there is an article on Perl and randomness in The Perl Journal #4 by John Orwant. Pretty basic for most Cypherpunks, but good reading none the less... --- | If you're not part of the solution, You're part of the precipitate. | |"The moral PGP Diffie taught Zimmermann unites all| Disclaimer: | | mankind free in one-key-steganography-privacy!" | Ignore the man | |`finger -l alano(a)teleport.com` for PGP 2.6.2 key | behind the keyboard.| | http://www.ctrl-alt-del.com/~alan/ |alan(a)ctrl-alt-del.com|

6 5

[IMPORTANT] One-time pads
by nobody＠zifi.genetics.utah.edu 17 Dec '03

17 Dec '03

Timmy Maya styles his facial hair to look more like pubic hair. _ >@) Timmy Maya (V(_ ^^\<

1 0

Re: Crypto reg clarification from Commerce Department
by Bill Stewart 17 Dec '03

17 Dec '03

http://jya.com/bxa123096.txt has the Federal Register text of the interim export administration rules. I haven't waded through all the comparisons of which interim amends what paragraph of what subplot of the revised prohibitions, etc., but there's one paragraph that may be relevant to the SWAN project. "This interim rule also amends part 744 to add a general prohibition in Sec. 744.9 with respect to technical assistance in the development or manufacture abroad of encryption commodities and software controlled for EI reasons and makes conforming changes throughout the EAR." Lucky Green has been talking with Commerce to try to get clarification of some of the requirements on a related issue; they say not to worry about some of the paragraphs because they only apply to missiles, nukes, and similar Real Munitions, but the paragraph above sounds like it's still talking about crypto. I'm not sure if "technical assistance" is clearly defined, and I'm not sure if hiring some foreigner to build something for _you_ counts as providing technical assistance to _them_, but it makes it more difficult to do the right thing while debugging non-US systems. Excerpts from Lucky's post: >From: Lucky Green <shamrock(a)netcom.com> >Subject: Crypto reg clarification from Commerce Department >Date: Mon, 30 Dec 1996 15:14:56 -0800 >To: cypherpunks(a)toad.com >.... >I just got of the phone with Bruce Kutz, Export Policy Analyst, Office of >Strategic Trade and Foreign Policy Controls. (202) 482-0092. He seems to be >the contact person for the new regs. > >I pointed Mr. Kutz to the section that alarmed me: >Sec. 736.2 General prohibitions and determination of applicability. [stuff you can't do about financing, supporting, proliferation etc.] >Mr. Kutz seemed surprised. Apparently he had not been aware that this >section was included in the new crypto regs. He then assured me that >1. Proliferation in the context of this paragraph applies only to >proliferation of >a) nuclear (bomb) technology b) missile technology ... >2. The Department of Commerce has no intention of banning the financing and >contracting of non-US crypto development. >3. Technical assistance to non-US parties requires a license. # Thanks; Bill # Bill Stewart, +1-415-442-2215 stewarts(a)ix.netcom.com # You can get PGP outside the US at ftp.ox.ac.uk/pub/crypto/pgp # (If this is a mailing list, please Cc: me on replies. Thanks.)

1 0