December 2003 - cypherpunks-legacy

Re: Libertarians for whom Jim Bell tolls...
by EFF 17 Dec '03

17 Dec '03

-------Fwd: Private Email (Identities XY'ed)------- Subject: Re: Libertarians for whom Jim Bell tolls... Date: Tue, 29 Jul 1997 11:32:11 -0800 From: XXXXXXXX To: YYYYYYYY >> "In the plea agreement, BELL also admitted that on March 16, 1997, he >> conducted a chemical "stink bomb" attack on the IRS office in Vancouver, >> Washington, using the noxious chemical mercaptan. ... > This is interesting, since they had no evidence that he did so. >However, they managed to get him to "confess" by illegally holding >without bond for crimes which they never intended to charge him with >in the first place. > I hope that Jim's lawyer is suitably rewarded for his part in selling >Jim down the river. Nancy Lord has had a lot of success in cases like this, and was interested in helping Bell's public defender file briefs challenging a lot of the IRS' charges and behavior, on First Amendment grounds. She tells me the public defender never even returned her calls. >> "IRS Inspectors indicated that the mercaptan attack may have been linked >> to the Feb. 20, 1997 seizure of BELL's vehicle by the IRS for unpaid taxes. > In effect, they are saying that since they didn't have any evidence >against Jim for the crime that they wanted him to "pay" for, that they >used the threat of major criminal charges to convince him to "confess" >to the crime, and held him without bail to let him know that the Justice >system is under the control of the IRS, and not the defendant. More or less. The big fuss, and the reason for holding without bail, was supposedly that his web postings constituted evidence he was planning to assassinate IRS agents. Yet, curiously, he was never charged with anything like "conspiracy to solicit murder." Instead, people go to jail for years for the equivalent of pouring skunk urine on someone's welcome mat, and for "using false SS numbers." Funny, I thought the folks who gave us SS numbers swore they'd always be confidential between us and our SS retirement fund manager, and would "never be used as a national ID number." Since I'm sure the SocSec Administration would never confirm or deny for the IRS Mr. Bell's REAL SS number, I wonder who they knew which ones were bogus? Are we to believe SocSec has never made a mistake, and issued one person two numbers? Anyway, was Mr. Bell accused of using the bogus numbers to fraudulently extort wrongful benefits from the SocSec Administration? Apparently not. So. since money will be withheld from your paycheck no matter WHAT SS number you file, the only possible "fraud" can have been to work different jobs under different numbers -- with no chance of ever collecting any "benefits" from the "bogus" accounts. An odd kind of "fraud," that pays money to the government with no hope of ever getting any back. >Vin, > Did you know that the IRS used the information gleaned from Jim Bell's >hard drive to send the "chilling" details of Jim Bell's plea agreement >to the individuals and mailing lists he corresponded with? > Did you know that when he arrested, there were no Assassination Bot's >in existence, and that there are now at least six prototypes currently >in operation? > > God Bless AmeriKa. > >XXYYZZMonger Hi -- It would probably be considered (by overzealous pro-government extremists) a violation of some bogus new enactment if I proposed that it would be a good idea for someone to widely and publicly post the names and home addresses of every employee of the IRS ... and possible the FBI, DEA, and ATF, to boot (after all, those people have no problem accessing the intimate details of OUR personal lives, on a moment's notice. We all live in more or less constant fear of THEIR midnight knock on the door.) So I won't suggest that. I don't suggest that. I hope no one ever does that. And if anyone ever does, I CERTAINLY hope such lists are not widely downloaded and disseminated. X.Y.

1 0

Screw SAFE / Re: Majority in house support SAFE encryption bill, from SPAlert
by nobody＠REPLAY.COM 17 Dec '03

17 Dec '03

> MAJORITY IN HOUSE SUPPORT PASSAGE OF ENCRYPTION BILL > "On the other side of Capitol Hill, however, the > ghost of J. Edgar Hoover lurks in the cloakrooms of the Senate. Rather > than taking a courageous stand for America, some Senators would rather > follow the administration's play book, trading personal freedoms for what > they themselves admit is only marginal improvement." Screw SAFE, and screw the Senate. The Military-Industrial complex is switching their web network to utilize the tools developed by the free market. The reason is that the anal-retentive robots that they employee are incapable of producing products and services at the same level as those which are produced by free men. Let the fascist fucks in the Senate and at the DOD fiddle while D.C. burns. Let them fuck up the American crypto industry with Brave New Clipper Chips while free men in other countries develop the technology that will enable them to slip the Pentagon a cold, hard one up the butt and free us from the bulimic Senate swine. It's better that we should let foreigners with strong crypto take care of nuking D.C. for us. Perhaps this is what Clinton's Chinese campaign contributors have in mind. Perhaps the Chinese are actually the ones behind the scenes calling the shots in the Whithouse stand on opposing strong U.S.-developed encryption. No doubt foreign spies and terrorists are vocal supporters of the Whitehouse's stance on encryption and key escrow. (As are the money-grubbers who can't wait to take advantage of having access to corporate America's private communications.) I guess those who have given up their guns to those who oppose the Constitution should start taking some foreign language classes. TruthMonger

1 0

National Security Agency markets commercial ASICs
by Alan Olsen 17 Dec '03

17 Dec '03

http://techweb.cmp.com/eet/news/97/965news/national.html National Security Agency markets commercial ASICs By Loring Wirbel SNOWMASS, Colo. -- On a scale unprecedented for a government intelligence arm, the National Security Agency (NSA) is expanding its selling of ASICs and design services, even offering commercial semiconductor designs for selected space-based and terrestrial applications. Terry Brown, NSA deputy chief of microelectronics, said the customer list will still be so specialized that the agency won't compete directly against developers of military ASICs and rad-hard devices. "Any customer of ours would still require a government sponsor at some level," he said. Nevertheless, at an IEEE conference held recently, representatives of Harris Semiconductor and UTMC Microelectronic Systems wondered how and why a secret government agency would compete against them. One representative of a commercial IC house, who asked not to be identified, said, "Whenever the government thinks it can sell products to OEMs, it inherently raises some problems." The commercial efforts involve NSA's 6-inch CMOS fab, run by National Semiconductor Corp., at NSA headquarters in Fort Meade, Md., and a Microelectronics Research Lab run by NSA at an undisclosed Maryland location. The agency has developed special ASICs for selected customers ever since National helped open the fab in the late 1980s. Some, such as the Mykotronx division of Rainbow Technologies Inc., were partners in crypto chips, while others sought NSA expertise in radiation-hardness for space applications. Looking to expand that customer base, the agency has named Leland Miller its first director of marketing for microelectronics. At the IEEE Nuclear and Space Radiation Effects Conference, NSA had a large trade booth advertising the capabilities of "NSA Microelectronics." Brown said NSA has special talent in data-path design, used in signal and image processing but ignored by many ASIC vendors. NSA's fab has a library of more than 100 standard cells, optimized for CMOS feature sizes from 0.5 to 1.2 microns. The fab handles double- and triple-metal designs and is just beginning to add non-volatile EPROM and E2PROM cell capabilities.

1 0

0728dod.html
by Damaged Justice 17 Dec '03

17 Dec '03

[1][ISMAP] [2] [LINK] [LINK] [1.][January..] ___Audio ___Video __ [3][ISMAP]-[4][USEMAP] [5][ISMAP]-[6][USEMAP] July 29, 1997 Internet Technology Invades Dept. Of Defense (07/228/97; 4:00 p.m. EDT) By Saroja Girishankar, [7]CommunicationsWeek When it comes to embracing Web technologies, no organization in the world has mobilized its forces as extensively as the U.S. Department of Defense. In what could become a textbook example for other nations and major businesses, the DOD's deployment of Web servers and browsers is expected to encompass 2 million users across an assortment of military and civilian agencies, making it the world's largest single community of Web users. To date, 1.5 million Web browsers have been installed across DOD's classified and nonclassified intranets. Already, Web servers at 16 major server sites, applications across 530 military command sites and an additional 37 component command sites provide a secure environment for tens of thousands of high-level Army, Navy and Air Force personnel, plus the joint chiefs of staff. They will use it to plan military exercises, perform logistics for troop movement, ready medical services and other operations related to combat. The ultimate goal is to provide all military personnel in need with a single, multimedia view of military command, control, communications and intelligence information, regardless of where they are located, according to Frank Perry, technical director for the engineering and interoperability directorate and the joint interoperability and engineering organization. Perry said Web technologies, from basic E-mail, newsgroups and Internet chat rooms to more advanced Java programs, are making that possible. Extending DOD's Reach "The Web browser and applications have made a profound difference in getting more and more things to more and more people in the DOD, and basically have given us a broader, faster and simpler reach for various applications in a truly network-centric way," Perry said. One area where this plays out is managing the movement and deployment of U.S. troops in Bosnia. According to Lt. General Albert Edmonds, who last month retired after a three-year stint as director of the Defense Information Systems Agency (DISA), and who oversaw the Web implementations, critical information related to the deployments were downloaded and easily replicated across secure Web servers that could be accessed by all parties involved. Regardless of the different desktops and laptops, personnel could download and access information, and the distributed format reduced bandwidth congestion as well. Before the Web rollout, most databases were on mainframes and could be accessed only by a small group of people. The DOD, along with other government agencies, has for some time relied on commercial products and technologies for faster development and lower costs. DISA, which is responsible for operating four networks -- the Defense Information Systems Network (DISN), Global Command and Control System (GCCS), Global Combat Support System (GCCS) and the Defense Messaging System (DMS) -- under the umbrella organization called the Defense Information Infrastructure -- has been moving its antiquated mainframe-based networks to distributed [8]TCP/IP[LINK] networks and other emerging technologies. According to Perry, all GCCS users are being moved to Windows NT desktops outfitted with browsers from both Netscape Communications and Microsoft. This enables them to exchange E-mail and participate in newsgroups and Internet relay chat for planning military exercises. For GCCS and GCSS users who have real-time needs of even more reliable and secure access, existing Unix clients will be retained. Users who have traditionally been using Unix-client software are being gradually moved to thin clients that use browsers with Java applets. Over time, all GCSS users will also be given similar software. Lastly, both GCCS and GCSS are moving to Java-based applications with authentication and cryptographical capabilities required for high security. Perry said Microsoft's [9]ActiveX[LINK] has not been an option because it allows executable content to move around distributed environments in a mobile mode and raises security questions. Java Virtual Machine and its sandbox construction offer better assurance, he said. Perry said GCCS and GCSS operate over a high-security TCP/IP router network called the Secret Internet Protocol Router Network that has 500 core routers as well as hundreds of routers at regional and local networks linked to a WAN using a [10]T3[LINK] line. A nonclassified network, called the Nonclassified Internet Protocol Router Network, which is made up of [11]ATM[LINK] switches and TCP/IP routers, provides the basic infrastructure for all of DOD. Although only data traffic now goes over ATM, plans are for future transmission of all voice, data and video over that cell network. DMS Affected By Web Technologies The adoption of Web technologies is affecting plans for the DMS. Perry and Tom Clark, the DMS program manager, said they will adopt the emerging Internet Message Access Protocol 4 -- the Internet E-mail standard that promises to let disparate E-mail clients and servers talk to each other. DMS, which is expected to have 250,000 users by year's end and 2 million during the next few years, is an X.400 electronic messaging backbone under construction at DOD. DISA said the GCCS, which replaced the older mainframe-based Worldwide Military Command and Control System, was completed in 21 months instead of the typical five years previously required. In addition, the agency said it expects savings of $260 million in the systems and operational costs of its networks during the next five years. "Using and adapting the commercial Web technologies permits [the DOD] not to spend 20 years building military-unique systems from scratch and it requires less training of our users," said Emmett Paige Jr., president and COO at OAO, a Greenbelt, Md., systems integrator. Paige was the Assistant Secretary of Defense (Command, Control, Communications and Intelligence) until he retired last month. He headed the DOD's adoption of a common operating environment and the move to TCP/IP and Web technologies. end Related articles from: [12]Techsearch Search TechWire & CMP Archives [All CMP Publications] ____________________ ______ [13]Get TechWeb Delivered -- Subscribe now for FREE! Sponsored By: [14]In the time it takes to read this, SnapShot (TM) can duplicate your enterprise data. (IBM) [15]TechWire + [16]Headlines + [17]Top Stories + [18]Industry + [19]Financial + [20]Internet Daily + [21]Software + [22]Networking + [23]Components + [24]Hardware + [25]International [26]Techsearch Search the archives: _______________ ___ TechWire ___ All CMP Pubs ______ [27][LINK] = Link to our [28]tech encyclopedia for more info. [29]Click here to visit NetGuide [30][ISMAP]-[31][USEMAP] _________________________________________________________________ [32][USEMAP] References 1. http://192.215.107.71/general/logos/brandbar.gif.map 2. http://www.techweb.com/cgi-bin/ad_client.cgi?creativeId=1986&pubId=16&cmd=c… 3. http://www.techweb.com/ads/graphics/tw/right2.map 4. LYNXIMGMAP:http://192.215.107.71/wire/news/jul/0728dod.html#right2 5. http://192.215.107.71/general/logos/secbar.map 6. LYNXIMGMAP:http://192.215.107.71/wire/news/jul/0728dod.html#SECBAR 7. http://www.techweb.com/cw 8. http://www.techweb.com/encyclopedia/defineterm.cgi?sstring=TCP/IP 9. http://www.techweb.com/encyclopedia/defineterm.cgi?sstring=ActiveX 10. http://www.techweb.com/encyclopedia/defineterm.cgi?sstring=T3 11. http://www.techweb.com/encyclopedia/defineterm.cgi?sstring=ATM 12. http://www.techweb.com/search/search.html 13. http://192.215.107.71/delivery/delivery.html 14. http://www.techweb.com/cgi-bin/ad_client.cgi?creativeId=4246&pubId=16&cmd=c… 15. http://192.215.107.71/wire/wire.html 16. http://192.215.107.71/wire/news/news.html 17. http://192.215.107.71/wire/wire.html 18. http://192.215.107.71/wire/industry/industry.html 19. http://192.215.107.71/investor/newsroom/newsroom.html 20. http://192.215.107.71/wire/online/online.html 21. http://192.215.107.71/wire/software/software.html 22. http://192.215.107.71/wire/networking/networking.html 23. http://192.215.107.71/wire/chips/chips.html 24. http://192.215.107.71/wire/products/products.html 25. http://192.215.107.71/wire/international/international.html 26. http://www.techweb.com/search/search.html 27. http://www.techweb.com/encyclopedia/ 28. http://www.techweb.com/encyclopedia/ 29. http://www.techweb.com/cgi-bin/ad_client.cgi?creativeId=8606&pubId=16&cmd=c… 30. http://192.215.107.71/general/toolbar/toolbarPB.gif.map 31. LYNXIMGMAP:http://192.215.107.71/wire/news/jul/0728dod.html#promomap 32. LYNXIMGMAP:http://192.215.107.71/wire/news/jul/0728dod.html#toolbarmap

1 0

Gone for vacation
by William H. Geiger III 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Hi, I will be on a much needed vacation for the next couple of weeks in Chicago. If any CP's wish to get together this weekend while I am up there please let me know by Wed afternoon. I'll be droping my subsrciptions down to only the ssz list for the duration of my vacation. Thanks, - -- - --------------------------------------------------------------- William H. Geiger III http://www.amaranth.com/~whgiii Geiger Consulting Cooking With Warp 4.0 Author of E-Secure - PGP Front End for MR/2 Ice PGP & MR/2 the only way for secure e-mail. OS/2 PGP 2.6.3a at: http://www.amaranth.com/~whgiii/pgpmr2.html - --------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.3a Charset: cp850 Comment: Registered_User_E-Secure_v1.1b1_ES000000 iQCVAwUBM96F3Y9Co1n+aLhhAQEeTAP/ecq7igtdSWV1bFnBAz+FydZd+e8+WDai G9FMA7nMw2Bn7ERf5oaBl1yDnVj+LGUOPO6+/aa2iRL7vXvgSzWuNDG2HkQYD8GB GnAuYljAyLmKjCYChtIaaEgfax5r9NYOgEV8U3beRYoUlAZNY9icn6tZ1+MOGxlo wH1aIdbXKPU= =e4Q4 -----END PGP SIGNATURE-----

1 0

Re: Attorneys: RSA patent invalid
by Tim Dierks 17 Dec '03

17 Dec '03

Michael C Taylor <mctaylor(a)nb.sympatico.ca> wrote: >At 05:29 PM 23/07/97 -0700, you wrote: > >$25K upfront is prohibitively expensive for freeware and > >for garage-shop programmers. It's a drop in the bucket for a > >large project such as Netscape that wants to add some security, > >but in a 3-person-month email widget it's excessive. > > > >On the other hand, it's now possible to license RSAREF for a much > >more reasonable fee from Concentric; I think it's just per-copy > >rather than a big up-front hit. > > As of March, 1997 Consensus Development (www.consensus.com) stopped > licensing RSAREF for a very reasonable amount (~$200 US + 2-3% range I > think it was??) > > Consensus' "SSL Plus" toolkit requires licensee to also license BSAFE from > RSADSI. > > Maybe too many people were using commerical RSAREF licenses rather than the > BSAFE toolkit. In truth, issues surrounding the functionality and licensing requirements of RSAREF meant that it wasn't a sustainable business for us, so we decided to return the rights to RSA. The license fee was no upfront + 5%. While the upfront was cheap, the percentage was significantly higher than what can be negotiated for BSAFE from RSA. This, plus the limited functionality of the RSAREF toolkit (both technically and due to license restrictions), meant that most customers preferred to just get BSAFE. This limited commercial demand is the same reason why we currently don't support RSAREF in SSL Plus. Please cc me on any responses, as I don't read Cypherpunks any more. (I found this posting on Bob Hettinga's e$pam). - Tim Tim Dierks - timd(a)consensus.com - www.consensus.com Software Haruspex - Consensus Development Developer of SSL Plus: SSL 3.0 Integration Suite

1 0

y2k problem *serious*
by Vladimir Z. Nuri 17 Dec '03

17 Dec '03

some people have talked about the y2k problem here, the "year 2000 problem". as programmers know, is the name given to the glitches that are caused by software malfunctioning because it only used 2 characters for the date field. I have mentioned that I think government agencies are going to be particularly hard-hit by this situation. I envisioned delays in payments etc. of something like a few weeks or so. however some recent new data and analysis by someone named Gary North causes me to rethink my position. it's somewhat alarmist, but he's got some excellent evidence. he believes the year 2000 problem is vastly more serious than anyone has realized. he thinks it may even lead to bank panics and instabilities in the entire worldwide economic system. he quotes Yourdon, a very respectable software professional, who talks about the domino effect in software such that even if parts of it are fixed, the erroneous sections can cause the system as a whole to fail. I suspect that we will be seeing some major, major news events related to y2k over the next year, all the way up to 2000. more info on this perspective can be found at www.garynorth.com this will be an incredibly important issue for virtually all programmers in the information field. (some cryptoanarchists here might rejoice at the potential here for mass social disruptions. may you live in interesting times.) The Yourdon Report Vol. 1, No. 4, June 1997. © Copyright 1997 by Cutter Information Corp. The Personal Consequences of Year 2000 Dear Colleague, Where will you be on New Year's Eve, 1999? If you're involved in the computer field in any way, there's a high likelihood that you'll be frantically working on the last-minute details of a year-2000 project. Yes, I know, not everything is written in COBOL and not every hotshot Java programmer is interested in the problem. But if you're an application programmer who normally develops business applications in Visual Basic, PowerBuilder, Smalltalk, or COBOL, there's a good chance that your organization will give you a temporary assignment to help out with converting mission-critical systems that are too important to fail. If you're a new-age Java programmer in a Silicon Valley startup company, maybe you'll be able to ignore the whole thing; but for many of the people who write software, 1998 and 1999 will be the years of year-2000 death march projects. I assume that anyone who reads this newsletter is familiar with the basics of the year-2000 problem; I won't bore you with a repetition of the details, or how we managed to get ourselves into this state. What I do want to talk about is the notion that it's our organizations that got themselves into this state, and that we have to make sure we distinguish between the problems and demands of our organizations, versus the problems and demands of our own lives and the lives of our families and friends. First, let's deal with the basic moral issue of culpability and responsibility. As you well know, there are some enormous legacy mainframe systems that will fall over and collapse on January 1, 2000, unless a thorough, expensive, and time-consuming effort is made to make them year-2000 compliant. But it's highly unlikely that you wrote the original code for those systems; indeed, the original programmers are probably long gone, maybe even dead. Or, ironically, those programmers may have been promoted: They may be your boss, or your boss's boss, or the CIO of the whole shop. In the rare case where you actually worked on the applications that now require year-2000 maintenance, chances are that nobody paid attention 15-20 years ago if you recommended that the date be coded with a four-digit year field. You were told how expensive memory was, and that none of these systems would last through the 1970s, or the 1980s, or the 1990s. In other words, with very, very few exceptions, the year-2000 problem is not your fault. Maybe we should have been smarter 20 years ago, and maybe we should have staged a mass revolt when our business users told us that they didn't want to spend the money for an extra two bytes of storage every time a date field was required within an application. Maybe they didn't really understand the significance of the short-term tradeoff that we made on their behalf. But after all, it was their money and their systems. In any case, there's a good chance that you can look at yourself in the mirror and honestly say: It's not my fault. Perhaps you feel that, as a member of a more-or-less professional category of "knowledge" workers, we all share collective responsibility for letting society get itself into the year-2000 dilemma. After all, what if mechanical engineers told us that a flaw in their calculations would lead to bridges and buildings falling over and crashing on January 1, 2000? What if they collectively shrugged their shoulders and said, "Well, it's not our fault. Newton, Galileo, and Einstein made a few miscalculations in their basic laws, and we just realized the problem." From that perspective, none of us really wants the IT community to end up with a huge black eye, or with the blame for having caused a massive economic and social disruption associated with year-2000 software problems. I'm willing to contribute some time and energy to help solve the problem. I'm willing to say, "Well, it doesn t really matter whose fault it is at this point. The most important thing is to fix the problem, and then move on." But what if the problem cannot be fixed? What if January 1, 2000, arrives and half of your company's software has not been converted? What if your organization collapses as a result? At that point, where does your responsibility lie? The interesting thing about this is that almost every organization could have fixed its year-2000 problem if it had begun addressing the problem in 1995 or before. But if the year-2000 conversion team is just forming now, in mid-1997, then the conversion almost certainly won't be finished when New Year's Eve rolls around two years from now. And that part of the problem is the fault of senior management, which was too busy worrying about other issues to focus on the biggest software project of all time. Let me stop for a moment and address a basic point: Many software professionals believe that the year-2000 problem will be somewhat annoying, and somewhat expensive to fix, but they can't bring themselves to believe that it could be a major, fundamental problem. It's like asking the residents of Southern California if they really believe that they're going to wake up one day and find that the San Andreas Fault has finally ruptured, and that California is now an island floating in the general direction of Hawaii. "We've lived with plenty of earthquakes, and some of them have been pretty serious," these folks will tell you. "Someday, the Big One will hit, but I really can't believe it's going to happen this year, or next year, or the year after." So here's the question: Do you believe the year-2000 problem is going to be really serious? Do you think it could shut down telephone service, banking systems, and airline systems for a few days, or a few weeks, or even a few months? I've been thinking about all of this during the last several months, and I'm becoming increasingly worried about the "ripple effect" problems that will be difficult to anticipate, and almost impossible to avoid. It won't be the end of civilization, but the year-2000 problem could indeed trigger a depression on the scale of the Great Depression in the U.S. during the 1930s. For example, consider XYZBank, which has 300 million lines of legacy code. Assume that XYZ has the time and resources to convert 200 million lines, and it has done a triage to ensure that the mission-critical systems are converted. That leaves 100 million lines of unconverted code that won't run at all, or will spew out gibberish. Since this unconverted code is associated with noncritical systems, it won't have a fatal impact on XYZ though it could incur a nontrivial cost. My real concern is that the applications XYZ considers noncritical might be very critical to some of XYZ's customers, partners, suppliers, etc. So it's quite possible that XYZ's failure to convert some of its software will cause little, tiny ABCWidget Company to go bankrupt, which causes slightly larger DEF Corp. to fold, and so on. Meanwhile, XYZ can't operate entirely alone; without electricity, phone service, and water, the offices can't function; without transportation services, none of its employees can come into work, and none of its customers can visit the bank to transact business. Let's assume for a moment that these basic utilities do continue operating properly after January 1. But what if the Federal Reserve Bank, S.W.I.F.T., and all the other banks that XYZ interacts with are having problems? What if XYZ's ability to print monthly bank statements depends on PQRPaper Corp. supplying laser-printing paper on a "just in time" basis? And what if PQR has a staff of three overworked programmers who maintain an ancient legacy system written in assembly language? If PQR stops shipping paper, then XYZ stops sending bank statements. Not forever, perhaps just for a month or two, but that's enough to cause a lot of confusion. There's also going to be a lot of confusion resulting from bugs injected into the converted programs. If XYZBank converts 200 million lines of code between now and December 31, 1999, then there will be an enormous amount of testing, and with that much code it's inevitable that some bugs will slip through. Maybe not fatal bugs that delete the database or shut down the bank's systems, but perhaps the kind of bug that will send incorrect monthly statements to 100,000 of the bank's 3 million customers. A problem like this might not be noticed until January 31, or when the year-end statements are produced on December 31, 2000. The problem with 100,000 incorrect statements is that it will generate 100,000 angry phone calls. Indeed, officials at the Social Security Administration (SSA) are quoted as saying that if the SSA has a 1% error rate in its retirement checks and other benefits, it will lead to somewhere between 43 and 50 million phone calls, starting the day after the checks are mailed. If the problem isn't resolved right away, then those people are likely to call back the next day, and the day after that, and the organization is likely to be in a state of paralysis. Back to the banks again: Do I really think that Citibank, Chase, Chemical, and BankAmerica (along with all the huge Japanese and European banks) are going to shut down on January 1, 2000? No, of course not. But I won't be surprised if the XYZSavings and Loan in South Poobah discovers that it can't process deposits and withdrawals for a week or two. That problem might cause a run on the bank, or an outright bank failure, and similar problems are likely to occur for a number of other small organizations as well. General Motors (GM) won't go bankrupt, but ABCWidget and PQR Paper could. Indeed, if ABCWidget goes bankrupt, it could cause serious problems for large companies like GM. Suppose ABC is one of the 100-odd companies that supply parts for GM cars and the widgets manufactured by ABC are an essential element of the transmission system. Because of the lean manufacturing system used throughout U.S. industry today, there's a good chance that GM doesn't have an inventory of widgets; ABC is supposed to deliver the appropriate number of new widgets to the GM plant every day. To ABC's surprise, its computers fail on January 1, 2000, and its widget production line shuts down. A week later, GM's production line grinds to a halt until it can find a replacement widget manufacturer. Meanwhile, GM's factory workers are furloughed without pay. By now, I'm sure you get the drift of my concerns. The interesting thing is that while software professionals and systems analysts are well-equipped to understand the reasons why the software could fail, and the possible consequences of those failures, they prefer to deny it. I wasn't aware of this until I watched Peter de Jager's year-2000 presentation at our recent Summit 97 conference, which ended with a question to the audience: "How many of you really believe these problems will occur?" To my surprise, a significant number of people raised their hands to indicate they did NOT believe that serious year-2000-related failures would occur. They couldn't disagree with any of the technical points that de Jager raised, just as you probably won't find anything fundamentally wrong with my arguments here. But de Jager's audience, and many of the people reading this newsletter, don't want to believe things could be this bad. "Surely," people will argue, "companies will find a way to solve this problem." Given our track record for normal software projects over the past 30 years, this argument borders on hysterical optimism. More likely, it's cognitive dissonance: If the facts disagree with the conclusions you were hoping for, then ignore the facts. What does all of this have to do with your job? Well, first you need to realize that a "denial of reality" may be taking place within your own organization today. Has your CEO or board of directors made a public commitment that all of the organization's systems will be year-2000 compliant, and that there is a detailed plan for coping with the organization's non-year-2000-compliant vendors, suppliers, customers, etc.? Do some arithmetic: If your company has 100 million lines of code in its application portfolio, then as of June 1, it would need to convert more than 100,000 lines of code per day, every day, in order to finish the job on time. Do you see the plans, the people, the tools, and the management commitment to make that happen? If not, what will be the impact on your job? Chances are that your company will go into panic mode sometime in 1998, halt all of its development work, and assign everyone in the IT department to work on year-2000 conversions. When I say everyone, I mean everyone. Secretaries will be drafted into the testing effort, and the managers will be expected to begin writing COBOL code. Is that the kind of environment, with everyone putting in double overtime, that you want to work in? And if the year-2000 conversion isn't finished on time, who will be blamed? You can be sure there will be lawsuits; are you sure you'll escape the wrath of the lawyers? If your company's year-2000 problems are very severe, what happens if it goes bankrupt? Will you be able to get another job? (An even more interesting question: At that point, will anyone want to admit that he or she is a programmer, or will it be a social stigma after January 1, 2000?) If you're out of work for six months, do you have enough money in the bank to support your family? Speaking of banks, what if your savings account is in XYZSavings and Loan of South Poobah? If depositors begin to worry about XYZ's year-2000 compliance in late 1999, will they begin withdrawing all of their money? If they do, will you be able to withdraw your money on January 3, 2000? Indeed, given the delicate balance of the fractional reserve system used by banks, it doesn't take a very large percentage of panicky customers to cause a bank run. The worst-case scenario in this area is pretty scary -- it might not be just the XYZSavings and Loan that suffers a bank run, but the big banks too. If the banks close for more than a couple of days, then how does the government collect taxes? If the government can't collect taxes, what happens to the value of its bonds, T-bills, and other financial instruments? Meanwhile, how many non-year-2000-compliant railroad and trucking companies will it take to disrupt the transportation infrastructure? While you're thinking about this, keep in mind another aspect of the lean manufacturing system -- the average grocery market, especially in urban areas, has to be restocked every 72 hours. I don't have answers for all of these questions, and I spend a portion of each day wanting to believe that none of these crises will occur. But I can't find a way to deny the possibility that they could occur, not exactly in the way I've described, but as a series of domino-effect problems that ripple through society. And if my software experience allows me to anticipate some of this, then your experience should provide similar insights. Think about this, and try very hard to avoid the cognitive dissonance problem. If the problem is anywhere near as bad as I think it could be, then you have to think very carefully about your loyalties and priorities. Will your employer get first call on your loyalty, or will it be your family and loved ones? On January 1, 2000, will you be at your keyboard, still converting two-digit year fields? Think about this now, while things are still calm. It won't be so easy two years from now. Ciao! Ed Internet: ed(a)yourdon.com Web site: http://www.yourdon.com

7 6

upside of y2k
by Antonomasia 17 Dec '03

17 Dec '03

Vladimir Z. Nuri wrote: > Speaking of banks, what if your savings account is in XYZSavings and > Loan of South Poobah? If depositors begin to worry about XYZ's > year-2000 compliance in late 1999, will they begin withdrawing all of > their money? If they do, will you be able to withdraw your money on > January 3, 2000? Indeed, given the delicate balance of the fractional > reserve system used by banks, it doesn't take a very large percentage > of panicky customers to cause a bank run. The worst-case scenario in > this area is pretty scary -- it might not be just the XYZSavings and > Loan that suffers a bank run, but the big banks too. If the banks > close for more than a couple of days, then how does the government > collect taxes? If the government can't collect taxes, what happens to > the value of its bonds, T-bills, and other financial instruments? On Tue, 29 Jul 1997, Anonymous wrote: > There is an underground computer organization in place which is > actively working toward sabotaging government and corporate efforts > to resolve the Year 2000 problems. This all reminds me of the old Polish joke.... Man takes week's wages into his bank, and he hands it over the counter he has second thoughts, so he asks the teller "What if the bank collapses ?" T: "Easy, sir. We're in a federation that will bail us out." C: "And if it's widespread, beyond the scope of the federation ?" T: "Then the government bails us out." C: "What, our Polish government ? It could be too much for them." T (getting bored): "Then the _Soviet_ government gets involved." C: "It could get really big, affecting a number of satellites what if it gets beynd the reach of the Soviet gov ? I mean, it could result in the collapse of communism!" T: "And isn't that worth a week's wages ?" -- ############################################################### # Antonomasia ant(a)notatla.demon.co.uk # # See http://www.notatla.demon.co.uk/ # ###############################################################

1 0

National Security Agency markets commercial ASICs (fwd)
by Jim Choate 17 Dec '03

17 Dec '03

Hi, This has to be a first. Usually the central government wants its citizens to pay taxes. What a novel idea investing our tax dollars this way. When can we expect to get our dividends as tax payers and therefore inherent investors in this little enterprise? Sounds like somebody in the NSA is getting ready to have their collective butts fried... ____________________________________________________________________ | | | _____ The Armadillo Group | | ,::////;::-. Austin, Tx. USA | | /:'///// ``::>/|/ http:// www.ssz.com/ | | .', |||| `/( e\ | | -====~~mm-'`-```-mm --'- Jim Choate | | ravage(a)ssz.com | | 512-451-7087 | |____________________________________________________________________| Forwarded message: > From owner-cypherpunks(a)ssz.com Tue Jul 29 15:59:12 1997 > Message-ID: <33DE5CF2.2424(a)nwdtc.com> > Date: Tue, 29 Jul 1997 14:13:22 -0700 > From: Alan Olsen <root(a)nwdtc.com> > Organization: Xerox Business Services - NW DTC > X-Mailer: Mozilla 3.01 (X11; U; SunOS 5.5.1 sun4m) > MIME-Version: 1.0 > To: cypherpunks(a)algebra.com > Subject: National Security Agency markets commercial ASICs > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > Sender: owner-cypherpunks(a)ssz.com > Precedence: bulk > X-Mailing-List: cypherpunks(a)ssz.com > X-List-Admin: list(a)ssz.com > X-Loop: ssz.com > http: //techweb.cmp.com/eet/news/97/965news/national.html > > National Security Agency markets commercial ASICs > By Loring Wirbel > > SNOWMASS, Colo. -- On a scale unprecedented for a government > intelligence arm, the National Security Agency (NSA) is expanding its > selling of > ASICs and design services, even offering commercial semiconductor > designs for selected space-based and terrestrial applications. > > Terry Brown, NSA deputy chief of microelectronics, said the customer > list will still be so specialized that the agency won't compete directly > against > developers of military ASICs and rad-hard devices. "Any customer of ours > would still require a government sponsor at some level," he said. > > Nevertheless, at an IEEE conference held recently, representatives of > Harris Semiconductor and UTMC Microelectronic Systems wondered how and > why a secret government agency would compete against them. > > One representative of a commercial IC house, who asked not to be > identified, said, "Whenever the government thinks it can sell products > to OEMs, it > inherently raises some problems." > > The commercial efforts involve NSA's 6-inch CMOS fab, run by National > Semiconductor Corp., at NSA headquarters in Fort Meade, Md., and a > Microelectronics Research Lab run by NSA at an undisclosed Maryland > location. The agency has developed special ASICs for selected customers > ever since National helped open the fab in the late 1980s. Some, such as > the Mykotronx division of Rainbow Technologies Inc., were partners in > crypto chips, while others sought NSA expertise in radiation-hardness > for space applications. > > Looking to expand that customer base, the agency has named Leland Miller > its first director of marketing for microelectronics. At the IEEE > Nuclear > and Space Radiation Effects Conference, NSA had a large trade booth > advertising the capabilities of "NSA Microelectronics." > > Brown said NSA has special talent in data-path design, used in signal > and image processing but ignored by many ASIC vendors. > > NSA's fab has a library of more than 100 standard cells, optimized for > CMOS feature sizes from 0.5 to 1.2 microns. The fab handles double- and > triple-metal designs and is just beginning to add non-volatile EPROM and > E2PROM cell capabilities. >

1 0

Boylovers, NAMBLA, and Net-vigilantes, from The Netly News
by Declan McCullagh 17 Dec '03

17 Dec '03

---------- Forwarded message ---------- Date: Tue, 29 Jul 1997 10:03:46 -0700 (PDT) From: Declan McCullagh <declan(a)well.com> To: fight-censorship(a)vorlon.mit.edu Subject: Boylovers, NAMBLA, and Net-vigilantes, from The Netly News ----- http://pathfinder.com/netly/opinion/0,1042,1222,00.html The Netly News (http://netlynews.com/) July 29, 1997 This Boy-Lover's Life by Declan McCullagh (declan(a)well.com) Anne Cox is nothing if not determined. For months the Net-vigilante has been unwavering in her crusade against pedophiles, undaunted by insults, threats and even the "horrible things" done to pictures of her as a baby that she had digitized and placed online. She fought back with just about every possible tactic: argument, public humiliation and sometimes-spurious threats of legal action. Now, the war is escalating. It started in May, after Cox launched an assault on "boy-lover" web sites in an attempt to force them offline. But she and her allies ran into a serious obstacle: the sites aren't illegal. They're filled not with child pornography -- which is banned by federal law -- but, instead, photos of boys in swimsuits. "They shouldn't be doing these things with the children's pictures," Cox says. [...] Some argue that Cox and her allies have gone too far. Besides boy-pix sites, this team of Net-vigilantes has attacked a group of gay teens organizing "to fight against" discrimination. They've tried to take down a consensual spanking page for gay adults, and even an archive of sexually-explicit stories that specifically rejects tales about pedophilia. Then there's the murky Children's Protection and Advocacy Coalition, which Cox claims to run -- yet she refuses to name its member organizations. [...]

6 7