December 2003 - cypherpunks-legacy

Java & signed applets
by E. ALLEN SMITH 17 Dec '03

17 Dec '03

This has some mention of signed applets et al, so I thought it was applicable. -Allen From: IN%"rre(a)weber.ucsd.edu" 11-MAY-1996 23:06:27.24 From: Phil Agre <pagre(a)weber.ucsd.edu> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= This message was forwarded through the Red Rock Eater News Service (RRE). Send any replies to the original author, listed in the From: field below. You are welcome to send the message along to others but please do not use the "redirect" command. For information on RRE, including instructions for (un)subscribing, send an empty message to rre-help(a)weber.ucsd.edu =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Date: Sat, 11 May 1996 15:59:13 -0400 (EDT) From: "Home Page Press, Inc." <staff(a)hpp.com> To: staff(a)hpp.com Subject: JAVA BLACK WIDOWS - SUN DECLARES WAR JAVA BLACK WIDOWS - SUN DECLARES WAR Sun Microsystems' has declared war on Black Widow Java applets on the Web. This is the message from Sun in response to an extensive Online Business Consultant (OBC/May 96) investigation into Java security. OBC's investigation and report was prompted after renowned academics, scientists and hackers announced Java applets downloaded from the WWW presented grave security risks for users. Java Black Widow applets are hostile, malicious traps set by cyberthugs out to snare surfing prey, using Java as their technology. OBC received a deluge of letters asking for facts after OBC announced a group of scientists from Princeton University, Drew Dean, Edward Felten and Dan Wallach, published a paper declaring "The Java system in its current form cannot easily be made secure." The paper can be retrieved at http://www.cs.princeton.edu/sip/pub/secure96.html. Further probing by OBC found that innocent surfers on the Web who download Java applets into Netscape's Navigator and Sun's HotJava browser, risk having "hostile" applets interfere with their computers (consuming RAM and CPU cycles). It was also discovered applets could connect to a third party on the Internet and, without the PC owner's knowledge, upload sensitive information from the user's computer. Even the most sophisticated firewalls can be penetrated . . . "because the attack is launched from behind the firewall," said the Princeton scientists. One reader said, "I had no idea that it was possible to stumble on Web sites that could launch an attack on a browser." Another said, "If this is allowed to get out of hand it will drive people away from the Web. Sun must allay fears." The response to the Home Page Press hostile applet survey led to the analogy of Black Widow; that the Web was a dangerous place where "black widows" lurked to snare innocent surfers. As a result the Princeton group and OBC recommended users should "switch off" Java support in their Netscape Navigator browsers. OBC felt that Sun and Netscape had still to come clean on the security issues. But according to Netscape's Product Manager, Platform, Steve Thomas, "Netscape wishes to make it clear that all known security problems with the Navigator Java and JavaScript environment are fixed in Navigator version 2.02." However, to date, Netscape has not answered OBC's direct questions regarding a patch for its earlier versions of Navigator that supported Java . . . the equivalent of a product recall in the 3D world. Netscape admits that flaws in its browsers from version 2.00 upwards were related to the Java security problems, but these browsers are still in use and can be bought from stores such as CompUSA and Cosco. A floor manager at CompUSA, who asked not to be named, said "its news to him that we are selling defective software. The Navigator walks off our floor at $34 a pop." OBC advised Netscape the defective software was still selling at software outlets around the world and asked Netscape what action was going to be taken in this regard. Netscape has come under fire recently for its policy of not releasing patches to software defects; but rather forcing users to download new versions. Users report this task to be a huge waste of time and resources because each download consists of several Mbytes. As such defective Navigators don't get patched. OBC also interviewed Sun's JavaSoft security guru, Ms. Marianne Mueller, who said "we are taking security very seriously and working on it very hard." Mueller said the tenet that Java had to be re-written from scratch or scrapped "is an oversimplification of the challenge of running executable content safely on the web. Security is hard and subtle, and trying to build a secure "sandbox" [paradigm] for running untrusted downloaded applets on the web is hard." Ms. Mueller says Sun, together with their JavaSoft (Sun's Java division) partners, have proposed a "sandbox model" for security in which "we define a set of policies that restrict what applets can and cannot do---these are the boundaries of the sandbox. We implement boundary checks---when an applet tries to cross the boundary, we check whether or not it's allowed to. If it's allowed to, then the applet is allowed on its way. If not, the system throws a security exception. "The 'deciding whether or not to allow the boundary to be crossed' is the research area that I believe the Princeton people are working on," said Mueller. "One way to allow applets additional flexibility is if the applet is signed (for example, has a digital signature so that the identity of the applet's distributor can be verified via a Certificate Authority) then allow the applet more flexibility. "There are two approaches: One approach is to let the signed applet do anything. A second approach is to do something more complex and more subtle, and only allow the applet particular specified capabilities. Expressing and granting capabilities can be done in a variety of ways. "Denial of service is traditionally considered one of the hardest security problems, from a practical point of view. As [Java's creator] James Gosling says, it's hard to tell the difference between an MPEG decompressor and a hostile applet that consumes too many resources! But recognizing the difficulty of the problem is not the same as 'passing the buck.' We are working on ways to better monitor and control the use (or abuse) of resources by Java classes. We could try to enforce some resource limits, for example. These are things we are investigating. "In addition, we could put mechanisms in place so that user interface people (like people who do Web browsers) could add 'applet monitors' so that browser users could at least see what is running in their browser, and kill off stray applets. This kind of user interface friendliness (letting a user kill of an applet) is only useful if the applet hasn't already grabbed all the resources, of course." The experts don't believe that the problem of black widows and hostile applets is going to go away in a hurry. In fact it may get worse. The hackers believe that when Microsoft releases Internet Explorer 3.00 with support for Java, Visual Basic scripting and the added power of its ActiveX technology, the security problem will become worse. "There is opportunity for abuse, and it will become an enormous problem," said Stephen Cobb, Director of Special Projects for the National Computer Security Association (NCSA). "For example, OLE technology from Microsoft [ActiveX] has even deeper access to a computer than Java does." JavaSoft's security guru Mueller agreed on the abuse issue: "It's going to be a process of education for people to understand the difference between a rude applet, and a serious security bug, and a theoretical security bug, and an inconsequential security-related bug. In the case of hostile applets, people will learn about nasty/rude applet pages, and those pages won't be visited. I understand that new users of the Web often feel they don't know where they're going when they point and click, but people do get a good feel for how it works, pretty quickly, and I actually think most users of the Web can deal with the knowledge that not every page on the web is necessarily one they'd want to visit. Security on the web in some sense isn't all that different from security in ordinary life. At some level, common sense does come into play. "Many people feel that Java is a good tool for building more secure applications. I like to say that Java raises the bar for security on the Internet. We're trying to do something that is not necessarily easy, but that doesn't mean it isn't worth trying to do. In fact it may be worth trying to do because it isn't easy. People are interested in seeing the software industry evolve towards more robust software---that's the feedback I get from folks on the Net." # # # The report above may be reprinted with credit provided as follows: Home Page Press, Inc., http://www.hpp.com and Online Business Consultant Please refer to the HPP Web site for additional information about Java and OBC. =========================================================== ............Home Page Press, Inc. http://www.hpp.com home of Go.Fetch ........Free TEXT version - Online Business Today email: obt.text(a)hpp.com ....Free PDF version - Online Business Today email: obt.pdf(a)hpp.com OBC / Online Business Consultant, $595/year email: obc(a)hpp.com

3 2

Leaflet for First Monday
by Robert Hettinga 17 Dec '03

17 Dec '03

--- begin forwarded text Date: Wed, 15 May 1996 12:32:45 +0200 (METDST) From: Erik Barfoed <journals(a)inet.uni-c.dk> Subject: Leaflet for First Monday To: tony durham <tdurham(a)cix.compulink.co.uk>, robert hettinga <rah(a)shipwright.com>, ed krol <e-krol(a)uiuc.edu>, bonnie nardi <nardi(a)taurus.apple.com>, ian peter <ianp(a)peg.apc.org>, rich wiggins <rwwmaint(a)msu.edu>, vint cerf <vcerf(a)mci.net>, Ed Valauskas <g0094(a)applelink.apple.com>, Esther Dyson <edyson(a)eff.org>, Rishab Aiyer Ghosh <rishab(a)dxm.org> MIME-Version: 1.0 Dear Everybody Once again I forward you the plain text version of the First Monday leaflet, which I kindly urge you to distribute. Best regards Pernille Hammels| Editor Journals Division e-mail: journals(a)inet.uni-c.dk Content-Type: TEXT/PLAIN; charset=US-ASCII; name="fmleaf.txt" Content-ID: <Pine.3.89.9605151245.A25943(a)inet.uni-c.dk> Content-Description: Leaflet for First Monday CALL FOR PAPERS Editor-in-Chief Edward J. Valauskas, Internet Mechanics, Chicago, IL, USA (valauskas(a)firstmonday.dk) Consulting Editor Esther Dyson EDventure Holdings, New York, NY, USA (dyson(a)firstmonday.dk) International Editor Rishab Aiyer Ghosh, The Indian Techonomist, New Delhi, India (ghosh(a)firstmonday.dk) Editorial Board Vinton G. Cerf, Senior, Vice-Presiden at MCI Tony Durham, The Times Higher Education Supplement, UK Robert A. Hettinga, Shipwright Development Corp., USA Ed Krol, University of Illinois, USA Bonnie Nardi, Apple Computer, USA Ian Peter, Ian Peter and Associates Cathsworth Island, Australia Rich Wiggins, Michigan State University, USA First Monday is a peer-reviewed journal on the Internet - about the Internet. This scientific journal expands the frontiers of academic publishing by combining the tradi-tional values of peer-reviewing and strict quality control with a new way of publishing on the World Wide Web. Aim and Scope The aim of First Monday is to publish original articles about the Internet and the Global Information Infrastructure. First Monday will: - follow the political and regulatory regimes affecting the Internet - examine the use of the Internet on a global scale, by analyzing economic, technical, and social factors - analyze research and development of Internet software and hardware - study the use of the Internet in specific communities - report on standards - discuss the content of the Internet First Monday will appear in three formats 1. Monthly Mail from a Mail Server First Monday will appear first of all as an electronic mail posting from the First Monday listserver. This issue of First Monday will be sent to the subscribers on the first monday of every month as an ASCII text file. It will include all the articles of each issue and pointers to information resources located at various Web, Gopher, and other sites. 2. Web Site This is the place where subscribers - and newcomers - can read about the journal, learn how to subscribe, read previously published articles, and submit manu-scripts and other materials for publication. This Web Site will also provide access to objects and files that are part of the articles. These objects and files can be downloaded. All back issues of First Monday will also be available for downloading. 3. Annual CD-ROM First Monday will also appear as an annual CD-ROM, containing all articles published in a given year. This CD-ROM will be offered at a low price to subscribers at the end of the year. Will paper versions be available? First Monday is an experiment in electronic publishing, exploring the possibilities of communicating in this Internet medium. At the insistence of subscribers, we can offer printing, but only on-demand. Process The flow of a typical article, from author to publication: - An author is contacted by an Editor to write an _article, or - An author submits an article to a Editor by electronic mail. The article is forwarded by electronic mail to the Editorial Office in Chicago. - The Editorial Office starts the peer-review process by forwarding the article to reviewers by electronic mail. The Editorial Office is responsible for tracking the article, handling comments from editors and _reviewers to authors, editing, and creating a final accepted article. - This initial peer-reviewing process is private. - Articles that are accepted for publication are distributed to all subscribers in the monthly mail, and posted on the First Monday Web Site. The Web Site version of the article is likely to contain objects (illustrations, programs, and other digital items) that are not included in the monthly mailing of the plain ASCII text. - All articles published in First Monday will be included in an annual archival CD-ROM. This CD-ROM will be offered to subscribers at a low price. How to submit articles To submit an article to First Monday, simply send it _by electronic mail to the Editorial Office (Edward J. Valauskas), valauskas(a)firstmonday.dk. Preference will be given to articles which take advantage of the Internet, using graphics, programs, HTML features and components, and other features not pos-sible in print. The text of the article (exclusive of any other objects like pictures, tables et cetera) should not exceed 30.000 characters. Format The manuscript must be in its final form, as a plain ASCII text, suited for distribution in the monthly e-mail. If an Internet resource is cited, just type in the URL. _Manuscripts can be marked up in HTML, as long as the tags are recognizable by most popular Web browsers. Non-text objects, like pictures, programs, spreadsheets, audio files, and full motion video files, can be part of an article. These non-text objects must be forwarded as binary files to the Editorial Office. Non-text should conform to well established de facto standards on the net: PDF, GIF, JPEG et cetera. Priority will be given to particular items of a high scientific standard, and articles with a relevant timeframe can be published at short notice as a rapid publication. Only original papers written in English will be considered for publication. Copyright Authors submitting a paper to First Monday automatically agree to assign copyright to Munksgaard International Publishers if and when the manuscript is accepted for publication. The articles published in First Monday are protected by copyright, which covers translation rights and the right to reproduce and distribute all of the articles in the journal. Authors submitting a paper to First Monday do so in the understanding that online publishing on the Internet is a new opportunity and challenge, but also a step into a new territory, where authors and publishers do not always have the means to protect against unauthorized copying or editing of copyright protected works. --- end forwarded text ----------------- Robert Hettinga (rah(a)shipwright.com) e$, 44 Farquhar Street, Boston, MA 02131 USA "If they could 'just pass a few more laws', we would all be criminals." --Vinnie Moscaritolo The e$ Home Page: http://thumper.vmeng.com/pub/rah/

1 0

DCSB: The FSTC Electronic Check Project
by Robert Hettinga 17 Dec '03

17 Dec '03

Notice the corrected reservation deadline date (now June 1st, 1996) :-) Sorry about that... Cheers, Bob Hettinga -----BEGIN PGP SIGNED MESSAGE----- The Digital Commerce Society of Boston Presents Frank Jaffe, of The Bank of Boston and The Financial Services Technology Consortium (FSTC) "The FSTC Electronic Check Project" Tuesday, June 4, 1996 12 - 2 PM The Downtown Harvard Club of Boston One Federal Street, Boston, MA Frank Jaffe is a Senior Systems Consultant in the Applied Technology Group at the Bank of Boston. Frank is currently the project manager for the FSTC Electronic Check project which involves over 30 companies. Frank has played a leadership role in planning the amalgamation of Bank of Boston's five major retail computer systems into a single, common software system; acting as project leader for a new teller system, and leading the screen phone R&D project in cooperation with Northern Telecom and Bellcore. The FSTC Electronic Check project will develop an enhanced all-electronic replacement to the paper check. Electronic checks will be used like paper checks, by businesses and consumers, and will use existing inter-bank clearing systems. Like its paper counterpart, the Electronic Check represents a self contained "information object," which has all of the information necessary to complete a payment. Likewise, paper checkbooks are replaced by portable Electronic Checkbooks; pens & signatures are replaced by signature card functions and digital signatures using advanced cryptographic techniques; stamps and envelopes by electronic mail or other communications options such as the World Wide Web over the Internet. The fully automated processing capabilities of Electronic Checks opens the possibility of other types of financial instruments, such as electronic cashiers, travelers, and certified checks. Electronic check writing and processing will be integrated into existing applications, from cash registers to personal checkbook managers to large corporate accounting systems, to greatly increase the convenience, and reduce the costs, of writing, accepting, and processing checks. This meeting of the Digital Commerce Society of Boston will be held on Tuesday, June 4, 1996 from 12pm - 2pm at the Downtown Branch of the Harvard Club of Boston, One Federal Street. The price for lunch is $27.50. This price includes lunch, room rental, and the speaker's lunch. ;-). The Harvard Club *does* have dress code: jackets and ties for men, and "appropriate business attire" for women. We need to receive a company check, or money order, (or if we *really* know you, a personal check) payable to "The Harvard Club of Boston", by Saturday, June 1, or you won't be on the list for lunch. Checks payable to anyone else but The Harvard Club of Boston will have to be sent back. Checks should be sent to Robert Hettinga, 44 Farquhar Street, Boston, Massachusetts, 02131. Again, they *must* be made payable to "The Harvard Club of Boston". If anyone has questions, or has a problem with these arrangements (We've had to work with glacial A/P departments more than once, for instance), please let us know via e-mail, and we'll see if we can work something out. Planned speakers for the following few months are: July Pete Loshin Author, "Electronic Commerce" August Duane Hewitt Idea Futures We are actively searching for future speakers. If you are in Boston on the first Tuesday of the month, and you would like to make a presentation to the Society, please send e-mail to the DCSB Program Commmittee, care of Robert Hettinga, rah(a)shipwright.com . For more information about the Digital Commerce Society of Boston, send "info dcsb" in the body of a message to majordomo(a)ai.mit.edu . If you want to subscribe to the DCSB e-mail list, send "subscribe dcsb" in the body of a message to majordomo(a)ai.mit.edu . Looking forward to seeing you there! Cheers, Robert Hettinga Moderator, The Digital Commerce Society of Boston -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMZnOlvgyLN8bw6ZVAQEm8gP/deJ/J0ncmiUTJo82jeGMRp38q+8u+/LH zUZ3dgOCXFM9Nldni/EM0nKiRAgPJTqlcGkrE6Q44s2+ZSPtTiop2Tbx+3xoCW9t zTeKoLoTLgcS7LYS1b/VpcJqN9+q7gGxqmyAd88yZei+i4ZHw6kUGB6MyeHMPq+t CSrEOkkikXE= =SWUd -----END PGP SIGNATURE----- ----------------- Robert Hettinga (rah(a)shipwright.com) e$, 44 Farquhar Street, Boston, MA 02131 USA "If they could 'just pass a few more laws', we would all be criminals." --Vinnie Moscaritolo The e$ Home Page: http://thumper.vmeng.com/pub/rah/

1 0

Micro$oft Online Banking Strategy
by anonymous-remailer＠shell.portal.com 17 Dec '03

17 Dec '03

Extract from Micro$oft WinNews Volume 3, #17: >>>>>>> MICROSOFT ONLINE BANKING STRATEGY Microsoft announced that 58 financial institutions have committed to offering online banking using Microsoft Money through a group of leading banking-software vendors and banking-processing companies. To further help banks build their online-banking services, Microsoft is readying software-component technology for performing secure, ATM-like transactions using popular World Wide Web browsers, including Microsoft Internet Explorer and Netscape Navigator. These tools to facilitate browser-based banking are scheduled to be available by the end of the year. In addition, the Microsoft Windows NT Server network operating system includes embedded support for Internet publishing, helping facilitate an end-to-end Internet banking solution. Press release: http://www.microsoft.com/corpinfo/press/1996/may96 /hmbankpr.htm <<<<<<<

1 0

distributed keys
by Matt Smith 17 Dec '03

17 Dec '03

Has anyone heard of an algorithm for managing keys automatically in a distributed system? For instance, if some low level security were to be implemented in a a networking stack where authentication was to be implemented, you would want to have each node have it's own signature so that signature checking can take place when one node connects to another node. The trick is then getting every node's keys distributed to every other node. Here are some ideas that I had, but neither is very desireable: - Manual distribution. User configures every node's key into every node. Configuration becomes a major hassle and mistakes are a pain to debug. An advantagous side effect is the user can configure which machines can talk to which machines if they're feeling particularly facist. - At connection time, each node determines whether or not it has the other node's key. If not, a symmetric key is generated via DH and public keys are exchanged. The problem comes in if someone is spoofing the machine to begin with. Then you'll have the wrong public key. Chicken, egg. Egg, chicken. - Having a certifying node which every other node has the public key to and who has everyone else's public key. Requests are made of this server. The trick is making this server secure and forcing the user to devote resources to this endeavour. Thoughts? -- Matt Smith - msmith(a)unislc.slc.unisys.com "Nothing travels faster than light, with the possible exception of bad news, which follows its own rules." - Douglas Adams, "Mostly Harmless" Disclaimer: I came up with these ideas, so they're MINE!

3 2

(Fwd) Mail Delivery Failure.
by Jean-Francois Avon 17 Dec '03

17 Dec '03

On 14 May 96 at 19:35, Timothy C. May wrote: > (This is having yet another interesting side effect: the wealthy who > can afford digital DSS dishes are suddenly very uninterested in > local cable problems, and the impetus for improvement is lost. > Obviously the "poor" are then left with a decaying, outmoded > infrastructure. Even as a Darwinian, I have to feel for them. They > got sold a bill of goods, about how awarding "the franchise" to TCI > or Sonic or Galactronic Cable would result in "universal access," > and now they're stuck.) Hey Tim, where are your bandwith-saving manners? You should simply have said : "You asked for it, brother..." ? ;-) Regards! JFA DePompadour, Societe d'Importation Ltee Limoges porcelain, Silverware and mouth blown crystal glasses JFA Technologies, R&D consultants. Physists, technologists and engineers. PGP keys at: http://w3.citenet.net/users/jf_avon ID# C58ADD0D : 529645E8205A8A5E F87CC86FAEFEF891 Unsollicited commercial e-mail will be proofread at US165 $/h Any sender of such material will be considered as to have ac- cepted the above mentionned terms.

1 0

Anonymous message failed (wrong password)
by daemon＠anon.penet.fi 17 Dec '03

17 Dec '03

The message you sent to the anonymous server could not be processed, as your password (in the X-Anon-Password: header) didn't match the one stored in the server. Either you have made a mistake, or somebody has used your account and changed the password. If the latter is the case, please contact admin(a)anon.penet.fi. You can check your current password by sending an (empty) message to send-password(a)anon.penet.fi. Contents of failed message: ------------------------- X-Envelope-To: <nick(a)anon.penet.fi> Received: from mail.crl.com(165.113.1.22) by anon.penet.fi via anonsmtp (V1.3mjr) id sma008018; Sun May 12 06:14:37 1996 Received: from crl2.crl.com by mail.crl.com with SMTP id AA19905 (5.65c/IDA-1.5 for <nick(a)anon.penet.fi>); Sat, 11 May 1996 23:10:02 -0700 Received: by crl2.crl.com id AA10484 (5.65c/IDA-1.5 for nick(a)anon.penet.fi) Sat, 11 May 1996 22:56:53 -0700 Date: Sat, 11 May 1996 22:56:53 -0700 Message-Id: <199605120556.AA10484(a)crl2.crl.com> To: nick(a)anon.penet.fi Subject: Cyber An@rchy From: cypherpunks(a)toad.com x-anon-password: have-fun

1 0

SS Follies
by Duncan Frissell 17 Dec '03

17 Dec '03

>>Although knowingly providing a fake social security number when one >>has any expectation of gain is, I believe, a felony. >> >>42 USC. sec. 408. > >Indeed. Except that this only applies to official uses. Obtaining a gain from a particular SS "account". I don't think it applies if you lie to your employer. >Plus, should one "just make a number up," odds are good that it "won't >compute," that is, that it will either collide with an existing number (and >identity, and reported income) or that it will fail the checksum/allocation >tests. No checksums involved (scheme invented in the '30s before that sort of thing) but there are unused ranges and geographical ranges. Freeware program like ssn.exe (available in all the usual places) will let you vet numbers. >The IRS imposes penalties for faking SS numbers. (Not to mention the >punishment meted out by the Sturmgruppenfuhrers of the SS!) If you use a "wrong" SS# on a W-4 form you will (some of the time but not always) receive a computer generated note from the SS warning you that your earnings have not been deposited into the proper account and if you don't correct the error you may lose benefits. Further action almost never occurs. Obviously more of a problem if done on 1040 forms. >A simple transposition of two digits may not get you zapped, but a >large-scale transposition or outright falsification will. If and when they >catch up with you. In the case of a school or cable TV company or something that wants the SS# to use for ID or credit purposes, nothing bad is likely to happen even if you are "caught". The SS doesn't verify SS#s for the credit agencies these days so they've had to build their own databases. If caught by private parties, all you have to do is say, "the SS# is Mark of the Beast mentioned in Revelations. It is part of a Satan-inspired One-World-Government Plot to establish *His* rule over the earth. I will not abide it." They leave you alone after that. Civilians are remarkably easy to cow if you express strong opinions. Real dialog from September 1983 in a Midwest State: Officious Intermeddler: "Why aren't you in school?" 12-year-old girl: "My daddy doesn't believe in sending me to those schools. He says they're controlled by Communists." Almost real dialog from the Spring of 1996: Parent: "My child has no SS# because (he/she) has lived overseas for (his/her) entire life." College admissions bureau-rat: "But how can (he/she) have a Passport without an SS#?" Parent: "That's our problem, not yours unless you've joined the State Department in the last 15 minutes." Most SS# problems occur in cases where one interacts with official persons. Since it is rarely necessary to interact with official persons, one can easily minimize these problems. Don't return their phone calls to your voice mail. Don't go to their offices. Like Rumpole of the Baily with his letters from Inland Revenue, drop their notes into the circular file. Don't ask, don't tell. Very little prison time has (yet) been served for SS# fraud. This may change if the "Immigration in the National Interest Act of 1996" passes since it increases penalties for uttering false documents in some cases. It doesn't apply to your interactions with your cable company. DCF

2 1

Re: Past one terabit/second on fiber
by droelke＠rdxsunhost.aud.alcatel.com 17 Dec '03

17 Dec '03

> > In the April 1996 issue of Fiber Optic Product news, there is an article on > a Lucent Technologies (formerly Bell Labs...no relation...sigh...) product > which wavelength-multiplexes quantity 8, 2.5 Gb/second signals on a single > fiber, for a total of 20 Gb/sec. This is a real, purchaseable system. On > the same page is a somewhat more experimental system, done by Corning and > Siemens, in which eight channels at 10 Gb/sec each were transmitted on a > single Corning fiber. > > "Wow", I said. Far faster than the 2.5 Gb/sec transmission that is > currently fairly standard for long-haul fiber trunks. The ads say they are selling it - that doesn't mean shipping it... yet at least. (Note that my employer is a direct competitor of Lucent so I have a vested interest in setting the facts straight) > I wasn't prepared, however, for page 38, in an article titled "Research > Teams Achieve 1 Trillion bits a Second." In fact, three separate groups did > this. I copy the article below. Yes - this is still very much a lab situation only though. It will be quite a few years before we hit that in real systems. [...] > > Even if we only consider that 20 Gb/second fiber from Lucent, that is > equivalent to about 300,000 simultaneous voice calls. An OC48 signal (~2.5 Gb/sec) will handle 48 T3's or 48 * 672 voice calls. Multiply by 8 for 20 Gb/second and you get 258048 voice calls. Pretty close to 300k I guess. > With a standard, > 36-fiber cable, that represents 18x300,000 two-way calls, or about 4.8 > million calls. This is probably far greater than the maximum number of > people on LD in the US at any given time, and that's just a single cable trunk. I don't know that any number fiber cable is "standard" but 36-fiber cable is not unusual. To find the capacity of a cable, you have to cut the number of fibers in half (as you did) because generally each fiber is used only for a single direction of traffic. You then have to cut it in half again because phone companies have everything redundant. So, for a connection between two cities, there are generally 2 cables in different locations (so one backhoe doesn't get both), with on average only 1/2 the fibers in each carrying paying traffic. > If we assume that the fiber cable costs $1/meter per fiber, and the cost of > trenching, burial, and interconnects raise this to $10/meter/fiber, and if > we generously assume that the average LD call goes 3000 miles (5,000,000m), > that call occupies 1/150,000th of a $50 million fiber for a few minutes. If > we suppose that the fiber has to gross $100,000,000 per year to pay for > itself, and even if it's only operating at an average 10% load level(both > assumptions are pessimistic, that only works out to a cost of 1.3 cents per > minute per call. That's why these LD phone companies are so scared: If we > can transmit Internet on fiber, that fiber can accept this extra traffic at > very low marginal cost. I can't vouch much for your cost numbers - other than to apply the factor of 2 adjustment noted above. I would add that much of a phone companies cost is in billing and customer service, etc. Not the cost of installing and maintaining the fiber and equipement. This is how the smaller carriers buy lots of bandwidth off of the big guys, and remove all the billing, etc. problems to themselves. They big guys are still making money selling the bandwidth, and the little guy makes his profit by selling for slightly less than the big guy and somehow making his billing, customer service, etc. cost him less. Internet telephony should make the use of bandwidth even more efficient - thereby cutting costs. The big guys who own the fibers will still make money - the pipes that carry internet traffic are still needed. But the little guys will get squeezed out. (until they become ISPs ;-). Internet traffic could theoretically be carried over this large amount of protection fiber (mentioned above) that is out there for a much lower marginal cost than the current T3 or OC3 pipes that are being used. The only "problem" being that these are lower priority channels, so that if a failure occurs anywhere, the traffic on them is dropped. Most customers are demanding high uptimes so much that the idea of a very lost cost, but much less reliable service hasn't caught on yet. Dan ------------------------------------------------------------------ Dan Oelke Alcatel Network Systems droelke(a)aud.alcatel.com Richardson, TX

1 0

(Fwd) New Anonymous Remailer
by David E. Smith 17 Dec '03

17 Dec '03

------- Forwarded Message Follows ------- From: privacy(a)interlink-bbs.com Subject: New Anonymous Remailer Date: Wed, 15 May 1996 06:34:02 GMT To: info-pascal(a)ARL.MIL You may be familiar with anon.penet.fi, which give you an anonymous account. Our service allows YOU to choose what the return address will be! Please write for more info.

4 3