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 rjones@oz.net (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 <72400.1525@compuserve.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 msb@sq.com 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 <72400.1525@compuserve.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