Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
In 1987, CompuServe designed the Graphics Interchange Format (GIF) specification for graphics files. The GIF specification incorporated the Lempel-Zev-Welch (LZW) compression technology on which Unisys Corporation was independently pursuing a patent filing. In early 1993, Unisys notified CompuServe of patent rights granted to LZW. At that time, CompuServe began negotiating with Unisys to secure a licensing agreement. This agreement was reached in mid-1994, and CompuServe then initiated a process to secure a similar license that would benefit its GIF developer community. Following the agreement reached between CompuServe and Unisys, CompuServe announced the Graphics Interchange Format (GIF) Developer Agreement, shortly after its completion, on December 29, 1994. This agreement is aimed at GIF developers who are developing programs and shareware primarily for use in conjunction with CompuServe. The service offers a license to these developers to use LZW technology in programs written to the GIF specification. CompuServe remains committed to keeping open the GIF 89a specification both within CompuServe and in areas outside CompuServe. CompuServe continues to strongly support the use of the GIF specification in the entire online community including the Internet and World Wide Web. This agreement will be transparent to end-users and will not result in any charges for people using viewers or transmitting GIF images. The agreement offers software and shareware developers who use the LZW technology in their GIF programs protection under a software license that CompuServe is authorized to grant under the agreement with Unisys. Developers who choose to take advantage of this service would acquire the rights to use the LZW technology in certain software and shareware developed primarily for use in conjunction with CompuServe. Developers who choose to participate in this agreement within the implementation period will also benefit in that Unisys has agreed not to pursue royalty claims for past use of the LZW technology in GIF. The implementation period has been extended to January 31, 1995. CompuServe has presented this new agreement as a service to its GIF developer community. Cost to developers will be a $1.00 one-time licensing fee and a royalty payment of 1.5 percent or $0.15, whichever is greater, per registered copy of a program containing the LZW technology. CompuServe will not profit from this service. CompuServe encourages developers to work with Unisys directly if the GIF Developer Agreement does not meet their needs. Unisys is continuing to make the LZW technology available to any interested parties under reasonable and non-discriminatory terms. Developers are not required to register with CompuServe. Registering with CompuServe is simply one option for addressing the Unisys LZW patent issue. Developers may want to consider consulting with legal counsel. CompuServe is committed to keeping the GIF 89A specification as an open, fully-supported, non-proprietary specification for the entire online community including the World Wide Web. Whether they choose to register with CompuServe or not, developers are encouraged to continue use the GIF specification within their products. A copy of the GIF Developer Agreement is available in the Library section of the CompuServe Graphics Support Forum (GO GRAPHSUP) and will shortly be posted to CompuServes World Wide Web page (HTTP:\\WWW.COMPUSERVE.COM). Developers who are not developing software primarily for use in conjunction with CompuServe should contact Unisys directly at: Welch Patent Desk, Unisys Corp., P.O. Box 500, Bluebell, PA 19424 Mailcode C SW 19. Sincerely, Tim Oren, CompuServe Vice President, Future Technology
The Reuter newswire reports on last year's Datastream case: RTw 94.01.03 05:55 EST Teenage hacker taps into U.S. defence secrets LONDON, Jan 3 (Reuter) - A British teenager allegedly hacked into sensitive U.S. government computers and was able to monitor secret communications over the North Korean nuclear crisis last spring, the Independent newspaper reported on Tuesday. The boy tapped into several defence computers for seven months in what U.S. officials conceded was one of the most serious breaches of computer security in recent years, the paper said. The article continues with the following key points: * The youngster posted the data on the Internet and was labelled "Datastream" because of the volume of information he supplied. * He "was finally caught by special U.S. investigators because he left his terminal on-line to a U.S. defence computer overnight." * The child was arrested in July in Britain. * "...[P]rosecutors are expected to decide this month whether he can be charged, the Independent said." * "...[T]he U.S. Air Force Office of Special Investigations acknowledged the hacker could have accessed and read the Korean files. M.E.Kabay,Ph.D./DirEd/Natl Computer Security Assn
German Information Security Agency (GISA, in German: Bundeasamt fuer Sicherheit in der Informationstechnik, BSI) has prepared a CD-ROM containing the draft (version 0.9) of the Common Criteria presently being issued by a committee of experts from USA, Canada and European Union. This (unclassified) version will be sent to every interested person together with accompanying material guiding comments (deadline of comments: March 1,1995). Interested experts should send a fax to German Information Security Agency Attention Dr. Kreutz Post Box 20 03 63 D 53133 Bonn FAX: +49-228-9582-427 Most regrettably, the CD-ROM is designed for PC work. When trying to mount the CD-ROM in the mode usually adapt to read PC CD-ROM formats, we succeeded to crash our SUN OS 4. As our SOLARIS systems have no CD-ROMs, we could not test whether this may work. (Nice to crash insecUNIX with INFOSEC material :-). Klaus Brunnstein (Dec.30,1994) PS: I asked BSI whether we may offer the CDROM material via our ftp-site. BSI informed me that they wish to be sure that the letter with guidance to the comment process accompanies the CD-ROM so I cannot offer this material via ftp :-)
The Associated Press newswire (via CompuServe's Executive News Service) reports on addiction to computers on an article datelined 94.12.26 @ 00:00 EST: Computer Addiction By PATRICE GRAVINO, Associated Press Writer KANSAS CITY, Mo. (AP) — It answers immediately and makes few demands. It can introduce you to new friends and lovers, entertain you, organize your bills and provide expert information about almost any topic. It's the nearly perfect companion: your computer. But many people, from industry experts to social scientists, are beginning to ask — and debate — whether there's such a phenomenon as "computer addiction" and whether it's becoming a problem. The author goes on to cite several anecdotal cases: o A "former computer instructor in Kansas City" explains the breakup of his 16-year marriage in part to the time he spent at his computer. o "[F]uturist Andre Bacard, a physicist and author based at Stanford University in California, where he researches the social impact of technology," reports several acquaintances who spend an inordinate amount of time online. Some "belong to a half-dozen computer networks, and they log-on to one after another. Their entire social world is vicarious." He adds, "I think it both encourages and cultivates psychosis in many people." o Some psychologists report having to help parents pull their children away from their computers because they are neglecting schoolwork and withdrawing from social interactions not mediated by computers. o "Steve Spaw, a computer graphics consultant in Kansas City," reports that he has to force himself not to spend _all_ his time with his system. o "Dr. James Donley, medical director of outpatient psychiatry at the University of Kansas Medical Center in Kansas City, Kan.," reports few obvious cases of computer addiction so far, but feels that there's certainly a potential. He draws parallels with the potentially excessive involvement in the world of pets that some enthusiasts display. He also points to the "inherently self-centered" activity where "people have a fairly simple relationship, where you can kind of predict or dictate what happens.... It can be used as an avoidance of social relationships." He argues that susceptibility to computer addiction "more to do with their personalities than with computers." <<Comments by M.K.: As I have mentioned before, computer addiction, if it exists, conforms to what University of Chicago Professor Mihaly Csikszentmihalyi has defined as "autotelic" behaviour. He describes this complex of behavioural cues in his book, _Flow: The Psychology of Optimal Experience_ (1990). Harper & Row (New York). ISBN 0-06-016253-8. xii + 303. Basically, his research suggests that highly enjoyable activities share certain attributes (p. 48 ff): o Challenging activity that requires skills o Merging action and awareness o Clear goals an feedback o Concentration on the task at hand o Sense of control o Loss of self-consciousness o Transformation of time. Flow is certainly not inherently dangerous; however, as in any human experience, some outliers will cross the fuzzy boundaries from wholesome involvement and commitment into crazy excess. Perhaps it would be appropriate for such people to glue timers to their computers! I can imagine someone writing a TSR which alerts them with a voice warning: "Susan, it's time to stop using your computers now: you've been working steadily for [fill in appropriate time limit] hours." <grin> Have any RISKS readers experienced such involvement with computer programs that they worry about the possibility of harmful effects on their relations with others? Do social relations through network communications supplant live interactions? Is there any reason to be any more concerned about spending, say, three hours online in a multi-user dimension than three hours chatting on the phone or--for that matter--three hours in one's own living room serving a friend tea?<> M.E.Kabay,Ph.D./DirEd/Natl Computer Security Assn
I recently bought a copy of a book called "The Virus Creation Labs" by George C. Smith (American Eagle, ISBN 0-929408-09-8) and it contains material, bulleted below, which may be of interest. ----The hiring of a hacker called Priest (who programmed the Satan Bug and Natas viruses) by Norman Data Defense, the developer of anti-virus software. The author writes that the initial job offer was carried by US Secret Service agents questioning the hacker after the agency's network was trashed by Satan Bug in 1993. ----A look back at the AIS Security Branch bulletin board system and the bruhaha surrounding its archive of hacker utilities and virus code. The coverage by the Washington Post and Associated Press is reviewed, and there are some interviews and comment from some of the people involved. ----A revealing look at the cozy relationship between some virus writers (who were looking for a little press) and some anti-virus software producers (who were looking for even more press and copies of the viruses in question).
The AP newswire (via CompuServe's Executive News Service) for 94.12.30 @ 20:02 EST reports on a murder plot ruined by use of a cordless phone: Scanner Plot MEMPHIS, Tenn. (AP) — A woman listening to a police scanner she had gotten for Christmas picked up a conversation over cordless telephones and heard what turned out to be a murder plot unfolding, investigators say. The article explains that Donna McGee heard a woman and her boyfriend plotting to kill the woman's husband and then collect insurance money. As the family gathered around in horror, "Mrs. McGee's daughter recognized a playmate's name" and the family figured out "the identity of the intended victim." Law enforcement officials said that because Mrs McGee was not purposely zeroing in on a specific conversation but only scanning across the bands, she had broken no laws in listening to the murder plot. <<MK: People who live in glass houses shouldn't throw binoculars.<> M.E.Kabay,Ph.D./DirEd/Natl Computer Security Assn [Also noted by firstname.lastname@example.org (Ry Jones).]
>From the Reuter newswire 94.12.29 @ 15:07 EST (via CompuServe's Executive News Service): JERUSALEM, Dec 29 (Reuter) - The Israeli army has taken its best shot at a formidable new foe — an insatiable craze for cellular phones, which have fast become an essential extra in soldiers' kit. The article explains that cell phones have become a problem for the army because "soldiers, especially reservists, have begun taking them on army duty, vexing commanders by making stock market deals and chatting to loved ones even during live-ammunition exercises." It is now forbidden to carry cell phones on duty and officers may "forbid a soldier from having a cellular phone at all." <<Comments from MK: The article did not say, but RISKS and NCSA Forum readers will agree, that using unencrypted cellular phones for _military_ matters would be a serious mistake.<> M.E.Kabay,Ph.D./DirEd/Natl Computer Security Assn
>Would English speakers have reacted equally strongly to a — no pun intended >-- comparable bug in the instructions for comparing and branching? I think >they would not. On the contrary, it would be far worse: the computer would be accused of not being able to make up its mind! — Mark
->->-> Date: 01 Jan 95 21:30:57 EST From: Fred Ballard <email@example.com> Hmm... <grin> do you think the mail program that generated that header was written in COBOL? In fact, 8 out of 9 articles accepted for that issue of Risks had Date lines with 2-character years! Mark Brader firstname.lastname@example.org SoftQuad Inc. Toronto
I'd like to respond to a few statements made in RISKS-16.69. Fred Ballard pointed out the risk of a COBOL program running near midnight and retrieving the system date and time as two separate operations. He suggests looping, getting the date, the time, and the date again, to make sure the date and time came from the same day. I have used that technique in all the code I have written, and have wondered whether anyone else worried about such things. The good news is that the COBOL language now provides a way to get the date and time in a single statement. The ANSI COBOL 1985 standard was officially updated in 1989 with the Intrinsic Function module, which I believe many vendors have implemented. There is now a CURRENT-DATE function that provides, with a single function reference, the system date, time, and local time differential from Greenwich Mean Time (if known). Several other of Mr. Ballard's concerns were also addressed in the same addendum to the COBOL standard. The CURRENT-DATE function returns the date and time in a standard 21-character format that includes four digits for the year. Addressing the multiplicity of date formats in use, the updated standard defines three: standard date form (YYYYMMDD), Julian date form (YYYYDDD), and integer date form (a numeric value representing the number of days counting from January 1, 1601, of the Gregorian calendar). The standard addresses date processing by providing functions to convert between integer date form and the other two forms. In summary, the COBOL language has addressed the problems. Now it's up to COBOL programmers to learn and start using what the language provides. Walter Murray
Fred Ballard <email@example.com> writes: > There is no way to obtain the system date and time in one statement in COBOL. Because most operating systems separate the request for time from the request for date. I can't think of any system where the date and time are returned in a single request; there probably are but I can't think of any. OS/MVS on IBM mainframes, Decsystem 20 on Digital Mainframes, RSTS/E and RT11 on Digital Minicomputers, MSDOS, VS/9 on Univac Mainframes, none of these returned date in the same call as time. > The only way in a COBOL program to assure that the time > obtained is for the date obtained is to loop getting the date, > then the time, and then the date again until both dates match > (as would usually be the case). I guess it's because with the exception of batch jobs being run at that time, most jobs run at some time other than exactly midnight - usually it's during business hours - and thus the problem only exists for two minutes of the day, e.g. during the one minute before midnight and the one minute after. The other 1438 minutes of the day, it's not a problem. Actually it's less than that. The problem is during the last one second of the last minute of the day and the first second of the first minute of the next day, since unless the call for date and time occurs exactly at that precise instant, and that one of them occurs just before 00:00:00 and the other just after. This means, that during 86,398 seconds of the day this isn't an issue, and is during "alpha and omega, the first and the last", is when the problem occurs. This sort of issue pops up so rarely that it's not something one thinks about much. In fact, a lot of reports print date only, so the time doesn't matter one way or the other. > I haven't heard of any problems actually caused by this, but the potential > risk is there as it is in any language that makes accessing the date and > time simultaneously impossible. (I believe BASIC shares this problem with > COBOL.) I captured a print out from running GW Basic: Ok PRINT TIME$ 22:33:44 Ok PRINT DATE$ 01-03-1995 Ok The question is how fast is the timing here. Just how many date and time requests can a basic program issue in one second. Using an MSDOS version of BASICA under MSDOS 6.0 running on an AMD 386 DX 40 with turbo on, I wrote the following program, called "TICK.BAS": 110 REM FIRST START WITH A NEW SECOND 120 T1$=TIME$ 130 IF T1$=TIME$ THEN 130 135 REM NOW COUNT NUMBER OF ACTIONS IN ONE SECOND 140 J = 0 : T1$=TIME$ : D1$=DATE$ 150 T$=TIME$ : D$=DATE$ 160 J = J+1 : IF T$=TIME$ THEN 160 170 PRINT J When I ran this program, twice, the printed result was: 3023 Basica typically isn't fast, yet in one second, this program, running in Interpreted basic, issued 3023 date and time requests. Actually, it issued 3023 date requests and 6046 time requests. This means that, for example, on a computer such as mine, it has to be issuing a request for the date and the time during the 1/3023rd of one second between the last second of one day and the first second of the next. If there is even 2/3023rds of a second before midnight, there would be enough time to get both date and time in the same second: A#=1/3023 : PRINT USING "##.##########";A# 0.0003307972 Or a 3 in 10,000 chance of this happening in the cases of someone running a program in Basic which would hit within the time required to cause an error of this type. And in a compiled language the chance is even less since the time to do two MSDOS calls. Using Turbo Pascal 6, I wrote the following file called "TICK.PAS": uses dos; var yr,mo,day,dow, hr,min,sec,tick, hr2,min2,sec2,tick2:word; I:longint; BEGIN getdate(yr,mo,day,dow); gettime(hr,min,sec,tick); repeat gettime(hr2,min2,sec2,tick2); until sec2<>sec; I := 0; repeat gettime(hr,min,sec,tick); inc(i); until sec <> sec2; writeln(i:1); end. The results I got for this were: 6767, 6229, 6229, 6575, 6571, 6201, 6205, 6202, 6228, 6575, 6229, 6228, 6229, 6574, 6229, 6575, 6229, 6571. Figuring worst case at 6200 tests, it means that there would have to be less than 2/6200 of one second before midnight for the possibility of this happening. 1/6200 of one second means that if a program of this type was executed every day in such a manner as to cross midnight, during the moment the date and time were collected, the chances are an error of this type happening would strike one execution every 16.9 years, since it can only happen once a day, and it can only happen during the 1/6200 of a second before midnight. No wonder I never thought about such a thing. It may be crass to put it this way, but how many people worry about an error that *might* happen once every 16.9 years?
Please report problems with the web pages to the maintainer