December 2003 - cypherpunks-legacy

Technical Remailer Analysis.
by bogus＠no.return.address 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Yow, I have been trying to send this for a week! BTW, yes I am using the bug to add this note. From: Louis Cypher (Elswhere) In this message I will analyze message reordering in remailers, and traffic analysis in remailer webs. Remailers which immediately resend incoming messages provide no security against an attacker who is able to watch all traffic to and from the remailer. Two proposals have been suggested to solve this problem, latency and reordering. In recent discussions, the consensus was that message reordering was superior to (and the actual intent of) latency. Reordering is not sufficient, a form of latency is required to make it effective. In this analysis, I assume that the reordering is accomplished by keeping a group of n messages at the remailer, and sending a random one whenever a new message comes. This is superior to simply waiting for n messages to arrive, then sending them all at once (I will show this later). The attack on the reordering remailer is simple. The attacker sends a stream of marked messages through the remailer. After the waiting messages have been flushed out, any incoming real message will be flushed out of the remailer before more arrive, allowing it to be uniquely identified coming and going. The defense against this is to only check the group and send excess messages after a time delay. This delay should be the typical time for n real messages to arrive. A mixing of approximately n messages is ensured by this process. If there is no attack, then the mixing is not quite as good as keeping a group of 2n messages. Here is the math on the reordering schemes: 1) Wait for n messages, then mix and send them all. The message is known to be one of those 10 (duh). 2) Keep a group of n messages. Send one of the n+1 when a new one arrives. The message could be any message ever sent after arrival. That is not useful. How many messages does it take before we are 90% sure that the message has been sent? prob that the message has not been sent after x messages is (n/n+1)^x Prob that it has been sent = 1 - (n/n+1)^x Messages till 90% prob: x=ln(.1)/ln(n/n+1) For n=10, x=24, which is much better then 10 for scheme 1. 3) Accumulate b messages, then send a of them (Scheme 2 is a=1, b=n) x = ln(.1)/(ln(a) - ln(b)) This gives the largest x for a=1. In my example of how to defend against the flood attack, a=n, b=2n x = 33 This is misleading, because it will introduce twice the delay as scheme 2. Given the same delay, a=n/2, b=n, one finds that x=16.6 That is better than batching, but not as good as scheme 2. The smaller x is worth it, because a reordering of at least some minimum number of messages is ensured. Some writer proposed changing n randomly to protect against this attack. Obviously that would not work. The attack will consist of many many more than n messages. The second issue for consideration is: Given a web of perfect remailers, how easy is it to identify corespondents? Tim has been asking this one for a while. I assume that there is sufficient traffic through all remailers that any message entering the web could be any message leaving the web. This can be achieved, even with light traffic, by sending fake messages through the web to bit buckets. While they do not improve the security of the web as a whole, they help ensure that no tracking of messages within the web is possible, forcing it to be treated as a black box. I assume that no correspondents are remailers themselves, and that all communications are random (random times with random people). This assumtion that all communications are uniformly distributed is terrible but.... This analysis only applies to indistinguishable messages. Each standard packet size can be thought of as having its own black box (a good argument for message splitting and having only one packet size). To simplify the problem, I am going to treat the web as though it were clock driven. Some number of messages enter and leave the web each "tick" with no messages staying in the web between ticks. This is a reasonable approximation, with the "tick" being the mean time of passage through the web. Define "f" as the fraction of remailer using population sending a message in a given tick. This is also the probability that any individual will send a message in a given tick. The probability of a given pair of corespondents in a given tick is f^2 The probability of a pair of corespondents occurring m times in n ticks is m p= 1 - Sum [(f^2)^i (1 - f^2)^(n-i) n! / (i! (n-i)!)] i=0 Lets put some numbers in there. If people send 1 message per day on average, and one tick is 30 min., then f=1/48. If you watch the web for a month you will see 1440 ticks. If the chance probability of your sending m messages to your co-conspirator is too small then you have been nabbed. The condition for that is: p << (1/population) The results for m=0 to 12 (using the above numbers) are: m = 0 p = 4.64811E-1 m = 1 p = 1.30173E-1 m = 2 p = 2.56257E-2 m = 3 p = 3.86587E-3 m = 4 p = 4.71498E-4 m = 5 p = 4.81967E-5 m = 6 p = 4.23687E-6 m = 7 p = 3.26538E-7 m = 8 p = 2.23961E-8 m = 9 p = 1.38336E-9 m = 10 p = 7.77044E-11 m = 11 p = 4.00273E-12 m = 12 p = 1.91774E-13 So, for a remailer using population of 10,000 you had better send less than 5 messages per month to your accomplice. This only gets worse the longer you keep it up. You can not send 4 per month, month after month. So, that is enough typing for one night. I hope this will staunch the RC4 legality debate for a few seconds. Summoned from Elsewhere: Louis Cypher Here is my key: - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6 mQCcAy52rloAAAEEAK2NyOHpG+yHmhbhu1wFmH7JpDUEs2q6VtYBoiQHhrbr/Duj cva9huWHP8OFWGWIRYQXGVNdYQTENqZ84C6uTtMZad2THzU6OWCKhC6GUTnzea9c kNKWj/BFI9n1461r7/y03nyZkoRT91QscQ+9vKNfDFqNy/I5W6yHUAO76TvRAICA AAAAAAAAAAAAAAAAAAADtBhMb3VpcyBDeXBoZXIgPEVsc2V3aGVyZT6JAJUDBRAu dq6UrIdQA7vpO9EBAf4YBACDO08fVgfsIU25rweXiNFUDZlj/ShOok6NPfXp7v4A w1AOzG+abIWd6w3Hl/bwLzN/7d3VwEj4MlPrsr3mVPWc2UhrV/KZ729Kyrlui1Xw 1nzWorHUGTfNtlmPcbSQkojKFpid5EcHJgtOI/fEnSQcvkux5IBtBWB1VoWGrj8l +w== =c18C - -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAwUBLopED6yHUAO76TvRAQHotwQAlkXA9esn+OjVM1hrl5qcWL+MpfNEtmn6 dn5Y8vKmyu/CJUddI+8UHmeMFAQrKczIRAetJHfN3+Vz+NARqafskpmAUDJAdCZ3 ON6G45ERrecgb6MvbFSwzKa5+80ksysVVa3Ql74Vi0cYf4x04OUblpVBPLPKgaUP GyD3E0EOWY0= =BGnr -----END PGP SIGNATURE-----

4 3

FWD: Safe-Tcl meets PGP!!!!
by nobody＠shell.portal.com 17 Dec '03

17 Dec '03

This is from the Safe-Tcl list, which discusses a variant on tcl which provides a "safe" subset of capabilities appropriate for letting incoming mail bring in programs which can run autonomously on your computer. I mentioned this a few weeks ago and I've been on the list, although I haven't looked at it in much detail. Nathaniel Borenstein is very active in the email community so this may turn out to be an influential technology. He is using PGP to authenticate incoming messages and grant them more privileges as appropriate: > From hfinney(a)shell.portal.com Sat Oct 1 13:30:26 1994 > Date: Sat, 1 Oct 1994 15:44:46 -0400 (EDT) > From: Nathaniel Borenstein <nsb(a)nsb.fv.com> > Subject: Safe-Tcl meets PGP!!!! > Cc: Marshall Rose <mrose(a)dbc.mtview.ca.us>, > John Ousterhout <John.Ousterhout(a)eng.sun.com>, > Philip Zimmermann <prz(a)acm.org>, > Trent Jaeger <jaegert(a)engin.umich.edu> > > For over a year now, people have been asking me about extending safe-tcl > to make use of digital signatures so that it can grant more powerful > capabilities to programs from trusted senders. My position all along > has been "the hooks are there, but nobody has put all the pieces > together." > > Today, after a message from Trent Jaeger that got me to thinking about > this again, I took a new look at the situation, the first time I'd done > so since becoming a regular PGP user. It turns out -- amazingly enough > -- that integrating these technologies was almost trivial! I am happy > to report that I now have integrated safe-tcl, pgp, the Internet Draft > on MIME/PGP, and metamail, to do "the right thing". Best of all -- you > don't need to compile anything, the "hooks" all work. > > With this hack -- which works for all metamail-based mail readers, and > which I expect will be easy to replicate for mhn and others -- I believe > that Safe-Tcl now has the last bit of functionality where Telescript was > previously superior. We now have a completely open platform for sending > around programs with differential capabilities dependent on the level of > trust that the receiver has in the sender. > > Getting this working is trivial. The assumption here is that you have a > message with a content-type of "application/pgp; format=mime" which, > when after its signature is checked (and after it is decrypted if > necessary) contains a MIME entity with a content-type of either > "application/safe-tcl" or "multipart/enabled-mail" (or some other > multipart, with one of these two types nested inside it somewhere). The > basic scheme is to make the PGP-smart process put signature information > into an environment variable, PGP_SIGNATURE, which is then checked by > the safe-tcl interpreter. Obviously, if you implement this, you want to > make sure that you don't usually have PGP_SIGNATURE set in the process > you use to read your mail! > > Anyway, to make this work there are two steps: > > 1. In your .safetclrc file, add the following: > > catch { > global SafeTcl_Services > set SafeTcl_Services(authentication) $env(PGP_SIGNATURE) > } > > This will ensure that SafeTcl_Services is set properly if the > PGP_SIGNATURE variable is set. > > 2. Configure your mail reading tool so that it understands > application/pgp and text/pgp, and sets the PGP_SIGNATURE variable. For > metamail-based systems, this consists of adding the following mailcap > lines: > > text/pgp; decode-pgp %s ; needsterminal > application/pgp; decode-pgp %s mime; needsterminal; \ > test=test %{format} = mime > application/pgp; decode-pgp %s ; needsterminal > > and then installing the "decode-pgp" script on your search path. That > script is a twelve-line shell script: > > #!/bin/csh -f > set viewprog=cat > if ($#argv > 1) then > set viewprog=metamail > endif > set prog="pgp" > set infile=$1 > pgp $1 -o /tmp/outputfile.$$ |& tee /tmp/shotputfile.$$ > set PS=`grep "Good signature" /tmp/shotputfile.$$ | sed -e "s/Good > signature from user//"` > setenv PGP_SIGNATURE "$PS" > $viewprog /tmp/outputfile.$$ > rm /tmp/*putfile.$$ > > I think that's all you need to do! If I'd known it was going to be this > simple I would have done it months ago! > > As an example of how to USE this facility, you can put the following > code in your .safetclrc: > > proc readsharedfile {nm} { > set fd [open $nm r] > set result [read $fd] > close $fd > return $result > } > catch { > if {[regexp "nsb(a)nsb.fv.com" $SafeTcl_Services(authentication)]} { > declareharmless readsharedfile > } > } > > In this case, if you get a safe-tcl program that is signed (and, > optionally, encrypted) by ME, and I'm on your keyring, it will be able > to read any file YOU can read. Otherwise, the readsahredfile procedure > will be undefined in the restricted interpreter. > > Pretty cool, eh? I encourage folks to try it out. -- Nathaniel > > PS -- Assuming no problems turn up, I will probably put "decode-pgp" and > the relevant mailcap entries in the next metamail release, and will > build the few lines that set SafeTcl_Services based on PGP_SIGNATURE > into the stuff done automatically in the next safe-tcl release. -- > Nathaniel

1 0

Feds & Ecash! Yikes!
by vvallopp＠eniac.seas.upenn.edu 17 Dec '03

17 Dec '03

Anyone have any enlightening info about this????? <forwards deleted> Path: netnews.upenn.edu!news.amherst.edu!news.mtholyoke.edu!world!mkj From: mkj(a)world.std.com Everybody knows that Al Gore is hot on this "National Information Infrastructure" thing. What many people may not fully appreciate -- or at least, what I'm just discovering myself -- is the sheer enormity of the disaster going on as we speak, under the banner of the "Information Infrastructure Task Force" (IITF). If you haven't already done so, I highly recommend an enlightening browse on the iitf.doc.gov site (ftp & gopher at standard ports, http at port 70). ^^^^^^^^^^^^ (NOTE: Individuals in fragile health should always consult a physician before exposing themselves to detailed information about their government's activities. Have you ever felt like an ant in the path of a steamroller? YOU WILL ...) Although I've barely scratched the surface, I've already run across a number of items which might be of interest to folks here. The DOE, for instance, reports that they are working on "Developing electronic cash systems that would maintain the privacy of individuals from merchants and banks, but would allow law enforcement to trace the flow of the electronic cash, given proper court orders." Other spectacularly dubious achievements include the report of the Privacy Working Group, which never once acknowledges any individual right to privacy, and in fact devotes most of their report to various ways to increase the "willingness" of the public to divulge personal data; and the draft report of the Intellectual Property Working Group, which with a straight face characterizes most current Internet activity as illegal, and then goes on to outlaw the rest of it, while blandly noting that the public will require "education" in these matters. Also, of course, there are any number of hints of NII projects involving various intelligence agencies. Enjoy. --- mkj ------------------------------+---------------------------------------------- Vinod Valloppillil | Even if you're one in a million, Telecom/MIS/Strategic MGMT | there's still a thousand more of you Engineering/Wharton | in China..... vvallopp(a)eniac.seas.upenn.edu | ------------------------------+---------------------------------------------- "It is often easier for our children to obtain a gun than it is to find a good school." -- Joycelyn Elders "Maybe that's because guns are sold at a profit, while schools are provided by the government." -- David Boaz

1 0

Cpunk list check
by merriman＠metronet.com 17 Dec '03

17 Dec '03

Haven't heard anything out of the list for a while, so just sending this out to see if the list is still up. Sorry. Dave Merriman - - - - - - - - - - - - - - - - - - - - - - - - - - Finger merriman(a)metronet.com for PGP/RIPEM public keys and fingerprints. Unencrypted Email may be ignored without notice to sender. PGP preferred. Remember: It is not enough to _obey_ Big Brother; you must also learn to *love* Big Brother.

1 0

H.E.A.T. BEAT
by Sandy Sandfort 17 Dec '03

17 Dec '03

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SANDY SANDFORT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . H.E.A.T. seeking C'punks, "Code Name: Assassin" In this episode, we see the return of H.E.A.T. archnememis, Neil Strake. (For those who haven't seen Acapulco H.E.A.T., Strake is played by James Healing who does an extremely bad imitation of bad (French?) actor, Louis Jordan.) Anyway, forget the plot, it is even more Byzantine and illogical than usual. Suffice it to say that Strake shoots Mike--on Mike's birthday--in an attempts to kill him. Mike is in a coma through most of the show. The special cartridge has "Happy Birthday" written on it; the bullet is inscribed, "Mike." (Wow, talk about a bullet having your name on it.) This episode was unique in the number of flashbacks and fantasies it offers: (1) Mike goes into cardiac arrest on the operating table. Instead of having the currently popular NDE (near death experience; dark tunnel, white light, life review, etc.), Mike has a fantasy dream of fighting in a boxing match. (He gets knocked out.) (2) When the Team fingers Strake, Ashley has a flashback to the previous Strake episode, thus practicing the parsimony of recycling. (3) Later at Mike's bedside, Ashley has another flashback about the two of them. She then sweet talks him in his coma and tells him not to die. (4) After Ashley talks to him, Mike has another fantasy dream boxing match in which he KOs his opponent. (5) Finally, Strake goes to a disco for no apparent reason. There he first dances with a beautiful quadroon. He drops her for an Anglo-looking woman. During his dance with the Anglo, he fantasized that she is Ashley (he has an obsession with Ashley). The dance is meant to be erotic, but it's just silly, even when they virtually fornicate on the dance floor. Here are the crypto/techno elements: (1) The cartridge is a ".223 nitro express," which is made by only one man, a guy named Sabross. (2) Krissie uses the H.E.A.T. computers headquarters to "patch" into the surveillance camera system of the prison in which Strake is supposedly incarcerated. This takes her all of 10 seconds. (3) The person in prison is not Strake, but an imposter whose appearance has been altered by plastic surgery to look, sound and act just like Strake. (4) Strake plants a radio controlled bomb at Mike's "funeral" (don't ask), which the Team discovers in a sweep of the chapel. There were several good lines in this episode. In a face-to-face encounter between Ashley and Strake, he says something about how he sees the world and Ashley says, "Don't they call that schizophrenia?" To which he replies, "Only the people who get paid to put a name on it, then get paid even more to cure it. While Strake is putting his bomb together he opines, "I love the smell of C4 in the morning." During the funeral, Strake pulls out the radio detonator and says, "One flick of my finger and you're all taco meat." (Don't laugh, have you ever eaten a taco in Mexico?) There were tons of bikinis in the beech scenes (strangely, there were only beautiful women on the beach). The disco people looked hot, and there was no Fabio! Tune in next week--same H.E.A.T. channel, same H.E.A.T. time--for the further adventures of Acapulco H.E.A.T. S a n d y ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

Nom de guerre public key
by nobody＠jpunix.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I'm new at both remailing and PGP, but having read the Cyphernomicon (OK, skimmed it) and various other FAQs, I haven't seen this issue addressed: I've created a pseudonym and a PGP key pair for that pseudonym. Now, how do I secure signatures for my public key, given the fact that (a) to sign it, you should be sure that it really belongs to me, and (b) I have no intention of revealing who "me" actually is? You can't call me on the phone, or meet me face to face, or do any of those other standard practices for confirming the key before signing it. But I sure don't want to use an unsigned, untrusted public key, since I want to make and keep a reputation and I can't risk someone spoofing my public key. ======================================================================= Crim Tideson Privacy is its own justification. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ My public key: - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6 mQCPAy51e6kAAAEEAMLIkYRAJqKnrQL7Xxmu7hNycUU06YZuR2i3WVxN9Jc6vnoF i7gT6/u7zVI4gmZCTA6mF6SYEFeOiENHaz0wyBNe+8AOIgdaezUsPODMh7UC64k0 YVQTNOiPN9jQAnyCGjPrplSliWT4gHGC796whwJ8CFkwPdpQf6vOblMnt4MdABEB AAG0DENyaW0gVGlkZXNvbg== =pwyo - -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAwUBLo3MxqvOblMnt4MdAQH0jwQAvzbd7b7KpcKdaeGzWUx8aav4WxWJWD9W qwYaVF/WNFFg89+m0K8TztTEcc9QVz3wYvKz1ojOx7IOJl10ZUBXbXrChaDYhbKJ YTU3QeOHN7o8VdzJ3o7z6lK9QqLZhhzQd4VgF9VxR++8LcBVS8AYaVWsfGLv7L2q W+4h4FIR0GE= =Vu2X -----END PGP SIGNATURE-----

1 0

list test
by Gary Jeffers 17 Dec '03

17 Dec '03

testing to see if list ok.

1 0

Re: Technical Remailer Analysis.
by bogus＠no.return.address 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- From: Louis Cypher Hal Writes: >Good point. There is a related attack which Chaum pointed out in his >1981 CACM paper: the attacker intercepts and keeps a copy of an incoming >message, then later re-sends it. This one will go to the same place and >by repeating this multiple times we can figure out where the original >message went. This raises a fundamental problem with current remailers. It is clear that next generation remailers will have to encrypt all messages sent between them, on top of any nested encryption of the message done by the originator. Timothy C. May Writes: >157.3. Some possible fixes: > > 157.3.1. remailers can recognize duplicates and agree not to >remail them, or to remail them off in different directions (adding their own >hop-wrappers) > > 157.3.2. digital postage helps a bit, as the attacker at >least has to spend money > > 157.3.3. (If the inner layers of a message each have some >digital money, or a "one-use" coupon, then an attacker who copies and resends >the whole message is effectively double-spending and this should be detected. >Most simply, the "use once" coupon will only allow one passage through the >remailer.) If the remailers also batched messages to a given destination, or padded outgoing messages before encrypting them, they would be far less susceptible to this kind of attack. Re-encrypting the message with padding (to some standard size) would prevent attackers from recognizing their own messages in a flood attack, except by noting destination (which could be a giveaway). Batching would do the same, but would also hide the number of messages trashed or locally delivered. Neither of these does much against the concerted "spam attack". I think in the end, remailers will need to run something like encrypted links, sending a constant volume of data between them, which would be random garbage when not a real message. This leaves open the denial of service attack of sending more data per hour then the link supports, therefore causing long queues at the remailers. Sigh, I really need to get down to a library and dig up the Chaum articles I hate to always reinvent the wheel. While waiting for good digital postage, a substitute could be used. If one added a "Msg-ID:" header similar to the Ghio remailer's "Cutmarks", which contained a large random number, this number could be stored at the remailer, and messages with the same ID simply send to /dev/null. This would be simple to do with remailer chaining scripts like "premail". Hal writes: >If I follow this, the attack is something like, every time Alice sends >a message Bob receives one. Observing this happening over a period of >time we conclude they are communicating. Could this be defeated by >sending dummy messages so that Alice sends exactly 10 messages every day? >Then the fact that Bob receives messages on some day can't very well >be associated with Alice. Since I assumed that a typical user sends one message per day, Alice may draw attention to herself through this mechanism. 10 messages is not enough, it would leave some correlation. Alice needs to send at least one message per tick (e.g. 48 in my example), in which case she shown 100% correlation with all recipients always. There is no way to know that she is sending to Bob, but I suspect she will be on a short list at the FBI unless everyone else is doing the same (which violates my assumptions). If everyone sent a message every tick, traffic analysis would be impossible. Matthew J Ghio writes: >This attack can be defeated if both Alice and Bob are running remailers. >Then their correspondence is hidden in the 100 messages a day of >remailer traffic. An observer can not tell wether the messages were for >Alice or Bob, or if they were for the remailer (assuming latency was >used) or if they were bit bucket messages. Alice could even forward her >personal messages to a bitbucket (after saving a copy for herself) to >further increase security. This is why everyone should be running a >remailer if they are concerned about their privacy. I do not think that the "everyone is a remailer" idea works. At the assumed one message per day, and an average message chain of 5 remailers, then only 5% of users can maintain remailers with a real traffic flow of 100 messages per day. Other than that, this idea is functionally similar to Hal's. Sending messages on to bit buckets is a nice idea. Assuming cutmarks, or standard message sizes, and reordering are used, this is indistinguishable from a remailer which just delivers the local mail, and also sends out periodic junk messages to various bit buckets. As I mentioned in my original message, this should be done anyway to ensure complete mixing of all messages within the web during any given tick. -Louis Cypher -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAwUBLo557qyHUAO76TvRAQFSJwQAmenSoAZAkOtGww9F/giy80AmJJk30I6D y5Fp0d8fgNy3MiCnG6onlvvJdBShgonvsbKRF0r94cYtYgtnczK/rqmhIDyc/UB2 a0V55YRdb84YwGpGPmrFepH8yXdueEgQvUq5Fs1FV9jNtSAK9kK2G1+QmSVdq/Uy pkRIf8iPbJA= =xZdv -----END PGP SIGNATURE-----

1 0

The benefits of commercialness
by sameer 17 Dec '03

17 Dec '03

As you can see, the remailer running with a profit motive (or at least a not-go-deeply-into-debt motive) is the most reliable. Last ping: Sun 2 Oct 94 17:00:01 PDT remailer email address history latency uptime ----------------------------------------------------------------------- c2 remail(a)c2.org **+-******** 13:29 99.99% wien remailer(a)ds1.wu-wien.ac.at ****#+**--#* 21:01 99.99% chaos remailer(a)chaos.bsu.edu ***####**+## 2:54 99.99% leri remail(a)leri.edu ****#**#**** 6:45 99.99% portal hfinney(a)shell.portal.com **##*#+***#* 3:59 99.99% ideath remailer(a)ideath.goldenbear.com +*****-*+- * 1:53:42 99.99% =), -- sameer Voice: 510-841-2014 Network Administrator Pager: 510-321-1014 Community ConneXion: The NEXUS-Berkeley Dialin: 510-549-1383 http://www.c2.org (or login as "guest") sameer(a)c2.org

1 0

Filing FOIA Requests
by ozymandias G desiderata 17 Dec '03

17 Dec '03

A large group of my friends and I are interested in finding out exactly what the cheeseballs over in Intelligence, Inc. have on file about us. Does anyone have handy the details necessary to file a Freedom of Information Act request for your own file? Do y'all have some hints so that we can expect the best possible yield? On the same note, do any of you have any humorous / chilling stories about what you found out when you got your file? Thanks in advance for the info, ozymandias G desiderata

2 1