September 2004 - cypherpunks-legacy

Remailers an unsolveable paradox?
by Nomen Nescio 06 Sep '04

06 Sep '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Are remailers an unsolveable paradox? We want to be able to provide the means for whistleblowers and others to communicate in a secure and anonymous fashion. Yet we need to make sure we're not abused too much since sooner or later laws will catch up with the remailers should abuse sky-rocket. Once upon a time all email servers were open relays. This was a friendly time and spam wasn't invented. As time changed the focus turned on securing the relaying procedures and has continued until this day. Yet as we know the flow of spam (most of it coming directly or indirectly from US) continued to increase, despite even existing legislation today. What are the possible solutions for the remailers? Make all remailers middleman only and adding the ability to opt-in for delivery outside the network? Having a network of middleman remailers and some nymservers that only delivers to other nymserver or opted-in servers will at least provide some means for people to communicate between themselves. It would in practise destroy the ability to contact anyone outside the network though, making the network an isolated place for a few. Using techniques like Hashcash should be more or less mandatory even today to make it harder to mailbomb or send large amounts spam? Why is it not? Regardless of what any hardcore cypherpunk or old-timers in the remailer community may think about any ideas imposing restrains on the useability of remailers something just have to be made about the abuse of the system. I also predict that the abuse will increase so time is ticking in a sense. Making sure we have robust remailing services in one shape or another and at the same time have some kind of at least indirect acceptance from legislators and also a low degree of spam flowing through are essential goals. The average naive and ignorant redneck will never ever understand the principal arguments for free speech that makes remailers useful. The average american do not think and analyze what is told to him. You will probably today find millions of americans who believe that Saddam and Al-Qaeda did business just because Bush and the administration lied about that initially, even though it's more or less confirmed today that those links were not there. The rednecks also vote however (to some extent) and that's why it will be a piece of cake to strike against the remailers if the politicians would like to. And they will, if and when serious abuse were to happen more often utilizing remailers. What would happen if it was found (or simply suspected or claimed) that some terror deed was planned using remailers? How long time would it take for us to see new laws being proposed? Not long. And don't forget that anyone (like Tom Ridge himself) could send bogues messages through the system trying to Since providing a true non-censoring remailing service and at the same time safeguard against spam and abuse are therotically incompatible I guess remailers are indeed a paradox waiting to be shut down sooner or later by politicians if we're not open to at least discuss some aspects of how these services are operated. Johnny Doelittle -----BEGIN PGP SIGNATURE----- Version: Tom Ridge Special v1.01 iQA/AwUBQTWdszVaKWz2Ji/mEQJlUwCfT/jWnw/p2ydTJTKMYKA5/hs+Dm8AoNoE r9bl2EtJ3CQpZPgfkSPfGBWB =B8dt -----END PGP SIGNATURE----- > Effective today, Lemuria will be going middlemen. > > Sometime around the middle of the month, Lemuria will go away. > > This is final. > > > The main reasons are that I've lost my faith in the usefulness of > the remailer network. I have indications that the remailer network > is > being massively abused, on the scale where the legitimate mails are > a tiny fraction that would be better served using other means. > > There are two main reasons for my thoughts. One is I have looked at > the bounces I receive, and compared their numbers to my statistics. > According to that data, without having run a statistically > significant analysis, the major traffic coming through Lemuria is > Spam, with > threats and harrassment a second. I realize that in the no-bounces, > the fraction of legitimate mails will be higher, but even assuming > a factor of 10, it is still a negligable part. > > Second, I've the mail attached below yesterday. In case you can't > read german, it is essentially spam advertising the mixmaster > software and some book and/or software I haven't tested, might be a > mixmaster > client, might be a trojan. This is a sign for me that the anonymous > remailer network is being used systematically for abuse, on a large > scale. I don't want to be a part of that. > > As mixmaster has no features whatsoever to prevent this crap, and > the "encrypted only" switch doesn't do what it should do, and > legitimate traffic is close to zero anyways, I'll be taking Lemuria > down and > leaving the remailer community. > > It was an interesting time, and between frog, the SciTol fanatics > (from both sides) and a couple really cool people, I've learned a > lot about society that I'm not sure I really needed to know. :)

5 4

Vote for nobody
by Sarad AV 06 Sep '04

06 Sep '04

hello, the election commision of india had a proposal to the govt. that the voter should be able to vote for 'none of the above'. Though one can predict that such a proposal will never be approved by the government, it makes a lot of sense. Is any other democratic country seriously thinking of implementing such an option? Sarath. __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail

4 3

Re: Remailers an unsolveable paradox?
by Tyler Durden 06 Sep '04

06 Sep '04

Variola wrote... > > Making sure we have robust remailing services in one shape or > >another and at the same time have some kind of at least indirect > >acceptance from legislators and also a low degree of spam flowing > >through are essential goals. > >Any legislator seeking to control how people use a communications >medium needs killing. Well, although the sentiment is appreciated, I'm not sure it's well applied in this case. What this guy seems to be saying is that it's better to 'solve' the SPAM problem now rather than waiting for legislators to use Spam as a reason to try to shut down the remailers (and this seems distinctly possible particularly if George W makes it to his 3rd term!). I don't think the guy is looking for state-ish 'OK', but pointing out that things get a lot more difficult if/when remailers or their use is outlawed. Like back in the day when I used to toke on a regular basis...I sure was going to keep scoring nicklebags and whatnot, but my count would probably have been better at my potstore if it were legal. (And yes, a potstore...there's tons of them in NYC with plexiglass walls and a few canned food props lying around. You stand in line and order your nickel/dime bag just like buying tokens.) The hascash idea is OK, and obviously will work (as of now...the dividing line between human and machine is clearly not static, and smarter spam operations will start doing some segmentation analysis and then find it worthwhile to pay up). But the kind of person that may have legitimate need of a remailer may not understand and/or trust what would probably be necessary to use hashcash. And OK "that's their tough luck", but then I always feel there's safety in numbers. -TD _________________________________________________________________ Get ready for school! Find articles, homework help and more in the Back to School Guide! http://special.msn.com/network/04backtoschool.armx

2 1

Private GPS tracking
by Major Variola (ret) 04 Sep '04

04 Sep '04

GLENDALE, Calif. - Police arrested a man they said tracked his ex-girlfriend's whereabouts by attaching a global positioning system to her car. Ara Gabrielyan, 32, was arrested Aug. 29 on one count of stalking and three counts of making criminal threats. He was being held on $500,000 bail and was to be arraigned Wednesday. "This is what I would consider stalking of the 21st century," police Lt. Jon Perkins said. Police said Gabrielyan tracked the 35-year-old woman, who was not identified, after she ended their relationship, showing up unexpectedly at a book store, an airport and dozens of other places where she was. Police said Gabrielyan attached a cellular phone to the woman's car on Aug. 16 with a motion switch that turned on when the car moved, transmitting a signal each minute to a satellite. Information was then sent to a Web site that allowed Gabrielyan to monitor the woman's location. The woman learned how Gabrielyan was following her when she discovered him under her car attempting to change the cell phone's battery, police said. http://story.news.yahoo.com/news?tmpl=story&cid=519&ncid=718&e=10&u=/ap/200… ----- Beslan, coming to a school near you

1 0

University Students in California Warned of Possible Identity Theft
by R. A. Hettinga 04 Sep '04

04 Sep '04

<http://online.wsj.com/article_print/0,,SB109417629363709000,00.html> The Wall Street Journal September 2, 2004 10:03 p.m. EDT University Students in California Warned of Possible Identity Theft Associated Press September 2, 2004 10:03 p.m. LOS ANGELES -- California university officials have warned nearly 600,000 students and faculty that they might be exposed to identity theft following incidents where computer hard drives loaded with their private information were lost or hacked into. Since January, at least 580,000 people who had personal information about them stored in university computers received warnings they might be at risk. The latest instance of missing equipment occurred in June at California State University, San Marcos. An auditor lost a small external hard drive for a laptop computer. Personal data, including names, addresses, Social Security numbers and other identifiers for 23,500 students, faculty and staff in the California State University system were contained on the missing hard drive. At the University of California, San Diego, and San Diego State University, hackers broke into computers and obtained access to files of personal data for more than 500,000 current or former students, applicants, staff, faculty and alumni. Officials from the Cal State system and UC San Diego said they have no evidence any personal data were stolen. At the University of California, Los Angeles, a stolen laptop in June led officials to notify as many as 145,000 blood donors that their data might be in the open. A California law requires people be notified when they might be exposed to identity theft went into in July 2003. Officials say that might explain the rash of notices. "There's no reason to assume that suddenly in July 2003 all these computer security breaches started occurring," said Joanne McNabb of the Office of Privacy Protection in the California Department of Consumer Affairs. "It's just that we know about them now, when we didn't hear before." -- ----------------- R. A. Hettinga <mailto: rah(a)ibuc.com> The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

1 0

whatever is necessary
by Major Variola (ret) 03 Sep '04

03 Sep '04

At 08:57 AM 9/3/04 -0400, Tyler Durden wrote: >Well, W did say he'd do "whatever is necessary". I caught the last bit of Bush's rant. The scary part was him talking about the "resurrection" of NYC. Given how his little bubble-brain is addicted to xianity, and his coterie has geo-political messianic delusions, this is not good. Just heard Clinton's going in the hospital to get a heart. Maybe W can get a brain? And Rummy some courage? Maybe Frances is Nature reminding FLA to shape up this time..

2 1

Re: Anonymizer outsourcing customer data?
by Anonymous via the Cypherpunks Tonga Remailer 03 Sep '04

03 Sep '04

On Tue, 17 Aug 2004, Nomen Nescio wrote: > > They claim they have over 1 million users. Is a class action suit in > > order? Their privacy policy clearly states > > > > "We consider your email address to be confidential information. We will > > never rent, sell, or otherwise reveal it to any other party without prior > > consent, except under the conditions set forth in the User Agreement for > > spamming and related abuses of netiquette, or unless we are compelled to > > do so by court order." > > > > As if that's not bad enough, I emailed their (useless) support about > this and some retarded drone emailed back claiming that the email came > from Anonymizer not lyris.net (even though I pointed out the IP address > in the email belonged to lyris.net) > > *sigh* > Such incompetance :( Oh, look! Anonymizer has fixed the problem in their latest HTML-laden email! Return-Path: <bounce-XXXX-XXXX(a)wecare.anonymizer.com> See, they >>care<<! Oops: Name: anonymizer.lyris.net Address: 64.62.197.139 Aliases: wecare.anonymizer.com Methinks they are mocking us. What happened to them? They were a fine company once. Did Cottrell sell the brand? What other parts of the privacy policy are they willfully violating?

1 0

PGP Identity Management: Secure Authentication and Authorization over the Internet
by R. A. Hettinga 03 Sep '04

03 Sep '04

<http://www.pgp.com/resources/ctocorner/identitymgmt.html> Click for illustrations, etc... Cheers, RAH -------- PGP Corporation - Resources - CTO Corner United States | International? Resources > CTO Corner > Guest Contributors > PGP Identity Management Welcome CTO Corner Data Sheets Flash Government Regulations Webcasts White Papers PGP Identity Management: Secure Authentication and Authorization over the Internet By Vinnie Moscaritolo, PGP Cryptographic Engineer 3 September 2004 Abstract Access to computer services has conventionally been managed by means of secret passwords and centralized authentication databases. This method dates back to early timeshare systems. Now that applications have shifted to the Internet, it has become clear that the use of passwords is not scalable or secure enough for this medium. As an alternative, this paper discusses ways to implement federated identity management using strong cryptography and the same PGP key infrastructure that is widely deployed on the Internet today. Beyond Passwords The inherent security weakness and management complexities of password-based authentication and centralized authorization databases make such systems inadequate for the real-world requirements of today's public networks. However, by applying the same proven cryptographic technology used today for securing email, we can construct a robust authentication system with the following goals in mind: * Provide a single sign-on experience in which users only need to remember one password, yet make it less vulnerable to "cracking" (hacking) attempts. * Employ strong user authentication, extendable to multi-factor methods such as tokens or smart cards. The only copy of the authenticating (secret) material is in the possession of the user. * Design such a system so it does not depend on any trusted servers and so that the compromise of any server does not affect the security of other servers or users. * Build on existing and well-accepted infrastructures that scale to fit a very large base of users and servers. * Enable users to sign on to the networks of more than one enterprise securely to conduct transactions. Authentication with Cryptographic Signatures Email communications via the Internet face a security challenge similar to network user authentication. Messages traveling through public networks can be eavesdropped or counterfeited without much effort. Yet we have been able to successfully mitigate these risks by using public key cryptography to digitally sign and authenticate email messages. With public key cryptography, each user generates a pair of mathematically related cryptographic keys. These keys are created in such a way that it is computationally infeasible to derive one key from the other. One of the keys is made publicly available to anyone who wishes to communicate with that user. The other key is kept private and never revealed to anyone else. This private key can be further secured by either placing it in a hardware token, encrypting it to a passphrase, or sometimes both. The holder uses the private key to digitally sign data. This digital signature can later be checked with the matching public key to ensure the data has not been tampered with and that it originated from the holder of the private key. Because the holder of the private key is the only entity that can create a digital signature that verifies with the corresponding public key, there is a strong association between a user's identity and the ability to sign with that private key. Thus, a digital signature is strong testimony to the authenticity of the sender. Cryptographic Challenge-Response Because the public key functions as a user's identity in cyberspace, we can apply digital signatures to strongly authenticate users of network services. One way to do this is to challenge the user to sign a randomly generated message from the server. The server then verifies the identity of the user with the public key. This process is illustrated below. 1. The user initiates network service access. 2. The server looks up the user's public key in its authentication database. The server then generates a random challenge string and sends the challenge to the client. 3. The client digitally signs the challenge string and returns the cryptographic signature to the server. The client also sends a counter-challenge string, which is used to verify the server's authenticity. 4. The server then checks the client's signature, and if successful, grants access. It also signs and returns the client's counter-challenge. The use of such cryptographic user authentication offers a number of advantages over password-based systems. For example, if we employ the same key used to sign email, user authentication becomes as strong as the applied cryptographic digital signature algorithm. This approach reduces the need for users to periodically change the password, yet means they only need to remember one passphrase for all servers using this system. In addition, because the user maintains the only secret material in the system, compromising a server's user database results in only limited damage. All this can be accomplished without the risks associated with passphrase caches or key chains. PGPuam - Proof of Concept A public key login system was originally prototyped by the author as PGPuam and later distributed as sample code by Apple Computer in 1998 [PGPUAM]. Consisting of an AppleShare-IP client and server plugin, the system enabled a user to perform two-way strongly authenticated logins to an AppleShare-IP server from a Mac OS client. The cryptographic routines were provided by the PGP Software Development Kit (SDK) shipped with PGP 6.0. The user interface was an extension of the existing AppleShare login and is illustrated below. Although entirely functional, the PGPuam sample was never intended to be a shipping product. Rather, it was meant to be a practical demonstration of why public key cryptography should be treated as a core operating system component. Unfortunately in the late 1990s, cryptography was mired in both commercial and political constraints and widespread public key infrastructure (PKI) was slow to solidify. Nevertheless, PGPuam was successful in demonstrating that cryptography could be used for more than encrypting email. (Note that AppleShare-IP was just a convenient test platform. This concept is portable to file servers that support plugin authentication modules such as Apache modules or Windows GINA Authentication DLL.) Authentication vs. Authorization Although the PGPuam authentication effectively addresses most password management and single sign-on issues, it does nothing for user authorization. File servers still have to maintain some form of user-file access control database. Managing and maintaining these user authorization databases securely quickly become cumbersome for server administrators when more than a handful of servers are involved. Consider, for example, what happens when a new user wishes to gain access to a server. The system administrator must create an account and add the user's name and access information to the appropriate server database. If the user wishes to access a number of servers, this process must be duplicated and kept synchronized on each server. This process is further exacerbated when the servers are owned by different organizations. Conversely, when a user departs from an organization, each of the servers must then be updated to reflect this change. Often, removed users are overlooked and left active on servers managed by different departments, thus creating a security risk. Although have been a number of attempts to create automated systems to replicate or centralize the authorization databases, such as Kerberos, they all seem to share the following drawbacks: * The authorization server itself must be physically secure and is a critical link in the security chain. * Each server must be in communication with the authorization server to verify user identity and authorizations. This could be an unreasonable requirement for remote sites or devices such as a door badge reader, for example. * The authorization server is an ideal target for denial-of-service attacks because they affect all the servers managed by it. PGPticket - Secure Federated User Authorization A number of papers have described ingenious alternatives for distributing network service authorization [BFL] [SPKI]. In particular, the Simple Public Key Infrastructure (SPKI) model introduces a change in how authorization is performed for network services. Instead of maintaining a per-server database of users' names, passwords, and their corresponding access rights, we can apply digital-signature technology to create an authorization certificate. Think of this certificate as a digital "permission slip," valid only for a specific user's key over a certain period of time. The authorization certificate is signed by the organization or a proxy that owns the server and presented by the user upon accessing a restricted service. One way to encapsulate these certificates is in the form of an OpenPGP standalone signature packet [OPENPGP]. These packets, known as PGPtickets , form the basis of a lightweight but very secure federated authorization protocol [PGPTICKET]. Each PGPticket contains the following fields: * The ISSUER who generates and signs the certificate, represented by a PGP Key-ID. * The SUBJECT, the principal or set of principals to which the certificate grants its authorization. A combination of KeyID, algorithm ID and key fingerprint is used to represent the subject. * VALIDITY is some combination of dates or online tests specifying the validity period/conditions of the certificate-typically, a creation and expiration date. This field might be useful for a school that wants to allow access to facilities for a limited period such as a term. * AUTHORIZATION is a structured field expressing the authorization this certificate grants to the subject. This data could be represented as SAML or some form of XML. * DELEGATION is a flag that indicates if the subject is allowed to delegate the specified authorization further. PGPtickets can be issued in or out of band and are uniquely identified by the hash of the ticket packet, known as its Ticket-ID. The issuer verifies the subject's key information through standard practice, such as key fingerprint. Unless there is a specific requirement to encrypt the signed tickets, they can be returned via cleartext email or even placed on a public website and accessed by the Ticket-ID. The subject can even store the ticket in a database, smart card, or token. The following illustrates the process of accessing a service with a PGPticket: 1. The user requests server access from the system admin. The user provides either a copy of his/her public key or makes the key available on a keyserver. The issuer verifies the validity of this key. 2. The administrator generates the PGPticket with appropriate authorizations and validity information, signing the ticket with the server admin key. The ticket is either posted in a public place or sent by email to the user. 3. The user retrieves the PGPticket and stores it in a local ticket database. 4. When the user attempts to access a network service, the client searches its ticket database for the appropriate ticket and sends a copy of it along with the access request. 5. The server checks the validity of the ticket by verifying the admin signature and expiration date of the ticket. The server then generates a random challenge string and sends the challenge to the client, requesting that the key specified in the ticket sign it. 6. The client signs and returns the challenge, which is checked by the server and, if successful, access is granted with the authorizations specified in the ticket. The server only requires a copy of the root issuer's public key. It does not need to store copies of the subject's public keys because the key fingerprint is signed into the ticket body. The subject public key can be provided by request from the client and cached for later use. The same is true for delegated tickets. There is no specific requirement for a certifying authority, although its use is certainly not precluded and would make PGPtickets usable for small sites as well as enterprises. One of the more interesting features of this design is that it enables the servers to function without access to a keyserver, independent of outside influences and resilient to denial-of-service attacks. This approach allows the use of PGPtickets for standalone devices where no network connection is practical, which opens a number of possibilities. PGPtickets can be transported in a token or Bluetooth device, and not only used for such things as Web Service or VPN access but also for restricted door access. In essence, PGPtickets could extend the usefulness of the PGP PKI to the physical world. PGPcoupon - Building on XML Web Services Other interesting possibilities occur when you consider that PGPticket piggybacks on the flexibility of the PGP key infrastructure. Consider a system that produced tickets automatically through some pay-per-use service and combine that with anonymous keys. Or what about using the key-splitting features to create a ticket that needs a certain amount of shares for service access? Another possibility is to mix the technologies of PGPticket and XML object Web Services. A client could post a Web request for a proposal whereby vendors could reply with a PGP-signed coupon that would be honored by various distributors for a given period. For example, imagine a school wants to purchase a number of books; various vendors compete for the order and send replies. In the replies is a 20% off PGPcoupon that Amazon or BN.com would honor. The client could then present this coupon upon purchase and have the transaction processed automatically. Conclusion I have outlined a number of alternate uses for PGP technology that go far past email encryption. Most of these designs have been around for a number of years, but were untapped because of political or commercial restraints and, at times, lack of vision. Fortunately, the environment has changed and cryptographic technology can be used to solve a number of real-world identity management problems today. References [OPENPGP] Callas, J., Donnerhacke, L., Finney, H., Thayer, R. "OpenPGP Message Format." RFC 2440, November 1998 [SPKI] Ellison, C. "SPKI Requirements." RFC 2692, September 1999 Ellison, C., Frantz, B., Lampson, B., Rivest, R. "SPKI Certificate Theory." RFC 2693, September 1999 [BFL] Blaze, M., Feigenbaum, J., and Lacy, J. "Decentralized Trust Management." Proceedings 1996 IEEE Symposium on Security and Privacy. [PGPTICKET] Moscaritolo, V. "PGPticket - A Secure Authorization Protocol." Mac-Crypto Workshop, October 1998 Moscaritolo, V., Mione, A. draft-ietf-pgpticket-moscaritolo-mione-02.txt [PGPUAM] Moscaritolo, V. "PGPuam - Public Key Authentication for AppleShare-IP." Mac-Crypto Workshop, October 1998 "Now that applications have shifted to the Internet, the use of secret passwords is not scalable or secure enough. Instead, there are ways to implement federated identity management using strong cryptography and same PGP key infrastructure that is widely deployed on the Internet today." - Vinnie Moscaritolo, PGP Cryptographic Engineer Related Links * Expert advice from Jon Callas: "Encryption 101 - Triple DES Explained" * Video: HNS interview with Jon Callas * Summary: HNS interview with Jon Callas Company | Privacy Statement | Legal Notices | Site Map )2002-2004 PGP Corporation. All Rights Reserved. -- ----------------- R. A. Hettinga <mailto: rah(a)ibuc.com> The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

1 0

gmail as a gigabyte of an external filesystem
by Thomas Shaddack 03 Sep '04

03 Sep '04

Cuuuute! :) Could be even more interesting if combined with a suitable kind of encryption; I don't know how much I should trust Google, they are way too big to not be more than attractive "focus point" for "carpet-watching" people. The author is aware of this issue. Question for the crowd: How difficult it would be to write a suitable crypto engine as a plug-in module for FUSE itself? Then we could have support for encrypted files on any filesystem accessible through FUSE. ----------- http://www.boingboing.net/2004/08/29/turn_gmail_storage_i.html What to do with all that extra, network-based storage that comes with your Gmail account? If you're using Linux, you can turn it into a mountable filesystem with GmailFS. GmailFS provides a mountable Linux filesystem which uses your Gmail account as its storage medium. GmailFS is a Python application and uses the FUSE userland filesystem infrastructure to help provide the filesystem, and libgmail to communicate with Gmail. GmailFS supports most file operations such as read, write, open, close, stat, symlink, link, unlink, truncate and rename. This means that you can use all your favourite unix command line tools to operate on files stored on Gmail (e.g. cp, ls, mv, rm, ln, grep etc. etc.). Link (via Waxy) <http://richard.jones.name/google-hacks/gmail-filesystem/gmail-filesystem.ht…> posted by Cory Doctorow at 08:21:29 AM

2 3

RE: [FoRK] Veeery Intewesting... (fwd from beberg@mithral.com)
by Tyler Durden 03 Sep '04

03 Sep '04

Well, W did say he'd do "whatever is necessary". -TD >From: Eugen Leitl <eugen(a)leitl.org> >To: cypherpunks(a)al-qaeda.net >Subject: [FoRK] Veeery Intewesting... (fwd from beberg(a)mithral.com) >Date: Fri, 3 Sep 2004 11:10:24 +0200 > >----- Forwarded message from Adam L Beberg <beberg(a)mithral.com> ----- > >From: Adam L Beberg <beberg(a)mithral.com> >Date: Thu, 02 Sep 2004 22:39:09 -0500 >To: FoRK <fork(a)xent.com> >Subject: [FoRK] Veeery Intewesting... >User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) > >http://www.sianews.com/modules.php?name=News&file=article&sid=1062 > >There over 800 prison camps in the United States, all fully operational >and ready to receive prisoners. They are all staffed and even surrounded >by full-time guards, but they are all empty. These camps are to be >operated by FEMA (Federal Emergency Management Agency) should Martial >Law need to be implemented in the United States and all it would take is >a presidential signature on a proclamation and the attorney general's >signature on a warrant to which a list of names is attached. Ask >yourself if you really want to be on Ashcroft's list. > >... > >-- >Adam L. Beberg - beberg(a)mithral.com >http://www.mithral.com/~beberg/ >_______________________________________________ >FoRK mailing list >http://xent.com/mailman/listinfo/fork > >----- End forwarded message ----- >-- >Eugen* Leitl <a href="http://leitl.org">leitl</a> >______________________________________________________________ >ICBM: 48.07078, 11.61144 http://www.leitl.org >8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE >http://moleculardevices.org http://nanomachines.net > >[demime 1.01d removed an attachment of type application/pgp-signature] _________________________________________________________________ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/

1 0