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…
From Edupage, 27 Dec 1994: GOV'T RECOMMENDS ELECTRONIC COPYRIGHT RESTRICTIONS The draft report on copyright law issued last July is drawing fire from some academics and librarians, who say it gives copyright holders too much power and "ought to maintain the balance that is maintained in the print world," according to a law professor who moderates an Internet forum on copyright law. One particular sticking point is U.S. Patent & Trademark Office Commissioner Lehman's opposition to allowing libraries to ship books electronically to patrons, because an extra copy would show up in each recipient's computer. "To me, the burden on those who would say that ought to be a fair use is extraordinarily high. You would see massive dislocation of the market for that work," says Lehman. The draft report was used to represent the U.S. position in recent meetings of the World Intellectual Property Organization, and Lehman says a basically unaltered final report will be ready in the spring. (Wall Street Journal 12/27/94 B5) [To subscribe to Edupage: send a message to: listproc@educom.edu and in the BODY of the message type: subscribe edupage YourName (assuming that your name is YourName; if it isn't, substitute your own name) ... To cancel subscription to Edupage: send a message to: listproc@educom.edu and in the BODY of the message type: unsubscribe edupage.]
An Open Letter to Our Colleagues In the Online Communications Community: The announcement by CompuServe and Unisys that users of the GIF image format must register by January 10 [1995] and pay a royalty or face lawsuits for their past usage, is the online communications community's equivalent of the sneak attack at Pearl Harbor. The announcement of the CompuServe-Unisys GIF Tax on December 29, during the lull between Christmas and New Year's Day, was clearly timed to cause maximum damage while an unsuspecting public celebrated the holidays. We at TeleGrafix Communications have no quarrel with those who seek to protect their intellectual property and profit from it. Indeed, we are in business to do the same. We believe those who develop software are entitled to reap financial rewards from their labors. But in our opinion, the timing and circumstances of the CompuServe-Unisys action indicates this is a shakedown of the online communications community by two powerful corporations, rather than a reasonable effort to protect intellectual property. The GIF format has been in widespread public use since 1987. Its widespread use and royalty-free licensing has been encouraged by CompuServe for years. Neither CompuServe or Unisys have made any significant improvements to GIF or its underlying LZW algorithm and compression process to justify charging for what has been free. Giving GIF users only 14 days to comply with sudden, unexpected demands to pay the private CompuServe-Unisys GIF Tax or face prosecution for past usage of what had been promoted for seven years as free, open standard software is unconscionable. It is especially outrageous since CompuServe and Unisys admit in writing that they decided to require licensing SIX MONTHS AGO in June, and didn't announce it to the public until now. According to the CompuServe-Unisys GIF licensing agreement, the settlement of the patent dispute was executed on June 21, 1994. CompuServe agreed to implement the agreement "as soon as reasonably practicable and in no case later than six (6) months after the date this Agreement is executed..." That six month period ended on December 21, 1994 — but CompuServe did not make the licensing terms public until December 28. Indeed, CompuServe appears to have violated the terms of its own settlement agreement with Unisys. While many of the messages we have read online in reaction to the CompuServe-Unisys GIF Tax decree express both dismay and disbelief, virtually none have analyzed the actual provisions of the licensing agreement. It is in this area that TeleGrafix Communications wishes to contribute to the dialogue. In our opinion, the CompuServe-Unisys licensing agreement is both illogical and overly broad. Let's examine some of its key provisions. All quotes cited are directly from the agreement. 1. CompuServe will license Developers who want to use GIF technology. The term "developer" is defined as "the other undersigned party to the agreement," and it seems to apply to ANYONE who contemplates distributing any product that uses the GIF format. 2. Developers will be licensed to sell or distribute "Products" that "use and exploit GIF...solely within the Field of Use." The term "Field of Use" is defined as "primarily for accessing the CompuServe Information Service and for manipulating and viewing data received through the CompuServe Information Service." The licensing agreement further defines the term "Products" as being "software that is developed or distributed...which is designed for and used primarily for accessing the CompuServe Information Service and for manipulating and viewing data received through the CompuServe Information Service." IT APPEARS THAT THE ONLY LAWFUL USE OF GIF WILL BE FOR COMPUSERVE-RELATED PRODUCTS. Using GIF images in any other manner, such as on CD-ROMs or bulletin board systems, is prohibited. Most of the thousands of products that have used GIF in some manner are henceforth contraband. 3. Developers may no longer "use, copy, modify or distribute the GIF specification, except as expressly permitted by CompuServe." This states that the GIF specification can no longer be shared, published or uploaded in any manner without the express consent of CompuServe. 4. Members of the public are prohibited from using any software product containing GIF until they have become a REGISTERED user of the product. The customer also must agree to use the product "primarily for accessing the CompuServe Information Service and for manipulating and viewing data received through the CompuServe Information Service." This virtually eliminates the concept of freeware or shareware containing GIF capabilities, since prospective customers can no longer try out these software products without registering them first. 5. Software developers must pay $1.00 for a license to use GIF, PLUS a fee equal to the GREATER of 1.5% of the selling price of the product, or $0.15 per "Disposition." Disposition is defined as "the sale, lease or license or any other grant of rights to a Product or any new Product." All royalties must be paid quarterly. Noncommercial and freeware usage of GIF technology is NOT exempted from the royalty requirement. Because the royalty provisions and definition of "Disposition" are so broad in scope, it appears that a GIF Tax payment may be due to CompuServe-Unisys each time a GIF image is transmitted via BBS or Internet. The operators of a BBS or World Wide Web site with hundreds or thousands of GIF images online could easily be bankrupted by these licensing requirements. 6. CompuServe must be notified of ANY new product using GIF when it is first offered to customers. 7. Persons using GIF must keep records of its use, and CompuServe has the right to audit those records every year upon seven days notice. Persons using GIF must pay the cost of the audit if a royalty underpayment of 10% or more is discovered, along with 12% interest on any underpaid royalties. 8. Even if the patent is later found by the courts or the U.S. Patent Office to be invalid and unenforceable, or if the patent expires, any developer must "return all copies of the GIF specification and any confidential information of CompuServe then in its possession or control to CompuServe, (ii) stop using the Licensed Technology, and (iii) stop distributing Products." This states that EVEN IF THE PATENT IS OVERTURNED OR EXPIRES, YOU MUST STOP USING OR DISTRIBUTING GIF. 9. Even though CompuServe has publicly disseminated the text of the agreement it wants GIF users to sign, the terms of the agreement are to remain confidential. This is illogical, to say the least, since they have posted it for public download on their own system. 10. Developers have to indemnify and hold CompuServe harmless for any damages if their CUSTOMERS somehow use GIF technology in a way not permitted by the licensing agreement. 11. Unisys has the right to enforce the agreement, as well as CompuServe. Further, Unisys has the right to pursue legal action or seek damages against Developers even after the agreement has terminated. TeleGrafix Communications Inc. will not sign such a licensing agreement. We think most other software developers, BBS sysops and Web site operators also will refuse to sign. We encourage our colleagues in the online communications community to evaluate the CompuServe-Unisys action, and to lodge appropriate protests directly with those companies. We believe that the CompuServe-Unisys GIF Tax drives a stake through the heart of Internet development. It will cripple the World Wide Web, NCSA Mosaic, and other Internet multimedia technologies that rely heavily on GIF imaging. Fortunately, we at TeleGrafix Communications do not depend on GIF imaging in our new RIPscrip 2.0 online multimedia technologies. We chose to implement the JPEG image format and only recently decided to add GIF support as a convenience to our customers. Due to the restrictive conditions of the CompuServe-Unisys GIF Tax and licensing agreement, we must now reevaluate our plans for supporting GIF use in the upcoming release of RIPscrip 2.0. While our company hopes to profit financially from our advanced RIPscrip 2.0 technology, we will not demand royalties from those who have used the freeware versions of our earlier RIPscrip 1.54 products and/or technical specifications. The RIPscrip 2.0 specification also will be made public for third-party use after it is finalized. We expect that the CompuServe-Unisys action will spell the death of GIF as a commercially viable technology, shifting the attention of the online communications community to JPEG imaging. Sincerely, Pat Clawson President & Chief Executive Officer TeleGrafix Communications Inc. Huntington Beach, CA Voice: (714) 379-2140 Fax: (714) 379-2132 BBS: (714) 379-2133 Internet: rip.support@telegrafix.com
"You are invited to discover Wired magazine - free" I received a pretty snazzy advertisement for Wired magazine 2 weeks ago and I decided to order the "free sample copy". I have placed the postage paid reply card in the mail 3 times, and 3 times a day or so later the same reply card has returned. It turns out that the reply card has my name and address on the flip side in the same position as the address of Wired magazine on the "correct side." Additionally the postal service 5+4 bar coding is on both sides of the card - once for Wired magazine and once for "me". I'll toss it in the mail once again. Curtis Keller 713-953-8309 curtis@neosoft.com curtis@kinesix.com
I am currently using a fourth-generation language called NOMAD2. NOMAD2 stores dates internally as the number of milliseconds since a date in the 1580s when the Gregorian calendar was first put into use. At least the version of NOMAD2 that I use does (1). For the most part, this seems to work out very well. Much of the fears about what happens with computer-stored dates on January 1, 2000 are groundless for NOMAD2. But perhaps not all of them. Using an appropriate date data type may have led to a false sense of security. Most years are entered in the application system I'm working with as two digits. NOMAD2 allows this and effectively adds 1900 to years entered as two-digit years. When the system date changes to 2000, I'm not sure whether NOMAD2 will start adding 2000 to the years entered. (There may even be a system variable for setting this.) Regardless, on 1-Jan-200, it will still not be appropriate to add 2000 to years from the now previous century or 1900 to years from the now current century. Any arbitrary scheme to treat, say, the entered years 30 through 99 as 1930 through 1999 and 00 through 29 as 2000 through 2029 would lead to problems (2) since the system I'm working with could involve birthdates of 1929 and before. Since the department I am working in has chosen to stay with the current version of NOMAD2 (1), any new schemes for handling this problem may be lost to my application. The whole topic of staying with a stable release of a system and not getting improvements or fixes to existing errors versus going to new releases that have improvements, may fix existing faults, but may introduce new ones is a rich risk management topic. NOTES: 1. A new application system in another operating environment is replacing the one I am maintaining. As a consequence, no further upgrades are being planned for NOMAD2 in our operating environment. The vendor of NOMAD2 continues to make upgrades. The vendor's most release dealt with a date problem from one its clients. The client was storing uninitialized dates on its DB2 database as something like January 1 of the year 0 which DB2's date data type allows. NOMAD2 can map DB2 databases, but its date data type did not allow dates before the introduction of the Gregorian calendar. (I assume they haven't had any clients who wanted to store archaeological data.) The client was stubborn and the new release of NOMAD2 contains a fix for the problem. I'm not aware of the implementation details. 2. As Brian Hayes noted in "Waiting for 01-01-00" on p. 14 of January-February 1995's _American Scientist_.
There is no way to obtain the system date and time in one statement in COBOL. A program could get the date just before midnight and then get the time relative to the day after the date it got. A timestamp of 31-Dec-1994 00:00:01 indicates just after midnight between 30-Dec-1994 and 31-Dec-1994, but it could have been obtained from a COBOL program running around midnight between 31-Dec-1994 and 1-Jan-1995. 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). No one knows how often such a check is performed in existing COBOL code, but I would guess it is very rare. No one knows how likely such an error would occur or what consequences it might have. But it certainly is not desirable. (It's a little like the Pentium FDIV bug.) 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.)
Application software typically draws the current date and time directly from the system. Not using data hiding, that is, drawing the current time from another application module, may cause problems with testing and could lead to faults due to the difficulty of testing if it is not possible to change the system date and time during a test. A realtime financial application may want to close the books for the now previous day when the time goes past midnight. I've heard of such an application and the developers did not use data hiding. As a result they had to run their tests when the system (and actual) time changed to midnight. Therefore, only one test could be run each night and in this case they had to rearrange their normal 8-5 working hours to center around midnight. Introduction of changes and fixes were more easily introduced when the programs were modified to access the "current" date and time through a common module that could shift the time during a test. However, as with most things, the tradeoff of using data hiding instead of directly accessing the system date and time opens up the potential risk of accidentally using test times in a production environment. (This risk might still be present if a test was allowed to alter the system date and time thereby moving data hiding to another level.)
In a few IBM 1401-based programs at the insurance company I was working at in the late 1960s, the year was stored as a one-character field! Fortunately the problem of going from 1969 to 1970 in these programs was recognized in time, the programs were few in number and modest in size (our 1401s had a maximum main memory of 8K), and the programs were corrected in time.
Stating the fact that COBOL has a default date format used in its special-registers bypasses the fact that COBOL has no date data type for the storing of fates (Freudian-slip, make that dates). This has left the coders of the billions of lines of existing COBOL code free to invent as many date formats as human creativity will allow. In my reading, use, and maintaining of COBOL code in over twenty-six years of information system programming, this is a surprisingly large number. This is one of the reasons "dusty deck" COBOL systems are such a problem as the year 2000 draws near. No assumptions can be made as to how dates are stored in COBOL-based systems and files. Also, the manipulation of a given format varies from one COBOL program to the next. There is no guarantee that any installation-wide modules are used for date manipulation. (Installation-wide is pretty much the best you can hope for; COBOL itself has no date manipulating modules.) Actually, there is no guarantee that date routines will even be concentrated and re-used within a given COBOL program. Date processing is often scattered throughout the program, with each date variable having not only its own unique processing but different code for the same operations on a given date at different points in a program. Obviously, some of this date code may contain errors. In many cases the errors are compensated for, consciously or unconsciously, by the program's developers or maintainers. So correcting a date computation at one point may lead to an error because the next use of the date has an existing correction for the previous error. [Thanks to Fred, who also pointed out an error on Page 88 of my RISKS book, which should have read "COBOL uses a two-character YEAR field" (instead of DATE). Sorry! PGN]
Typeset copies of the CFP are available via anonymous ftp from ftp.csl.sri.com
in /pub/compass95-cfp.{txt|tex|dvi|ps} and /pub/compass95-cfp-a4.{dvi|ps}
or via WWW from http://www.csl.sri.com/compass95.html .
CALL FOR PAPERS
COMPASS '95
10th Annual IEEE Conference June 26--30, 1995
on COMPuter ASSurance (COMPASS) Gaithersburg, MD USA
Sponsored by IEEE Aerospace and Electronic Systems Society
and IEEE National Capital Area Council
In cooperation with The British Computer Society
The purpose of this conference is to bring together researchers,
developers, integrators, and evaluators who work on problems related
to specifying, building, and certifying high-assurance,
high-consequence computer systems. What distinguishes COMPASS from
similar conferences is its emphasis on bridging the gap between
research and practice. For researchers this provides an opportunity
to present new results, theories, and techniques both to other
researchers, and to practitioners who can put them to use. They can
also learn from practitioners of issues and problems encountered in
building real systems. Practitioners have an opportunity to share
lessons learned, to hear of new research, and to influence future
research directions.
The conference will be held at the National Institute of Standards
and Technology in Gaithersburg, Maryland, which is a suburb of
Washington DC (4 miles from the Shady Grove Metro Station).
The proceedings will be published by the IEEE.
Papers should present advances in the theory, design, implementation,
evaluation, or application of high-assurance systems, or report on
experiments, evaluations, and open problems in the use of new
technologies for computer assurance. Special consideration will be
given to presentations (either single papers or paper pairs) by
practitioners and researchers who have worked on the same problem.
There will also be a tools fair and the conference will be preceded by
one or two days of tutorials. Papers, panel session proposals,
tutorial proposals, and tools fair proposals are solicited in
relevant areas including the following:
Software Reliability Software Safety Computer Security
Formal Methods Tools Human-Computer Interfaces
Real-Time Systems Networks Embedded Systems
V&V Practices Certification Standards
Measurement and Metrics Organization Theory Lifecycle Processes
Representative application areas of interest include but are not
limited to: communications, military systems, avionics, road and rail
transport, space systems, nuclear and conventional power generation,
plant and process control, and medical systems.
INSTRUCTIONS TO AUTHORS:
Send five copies of your paper, panel session proposal, tutorial
proposal, or tools fair proposal to John Rushby, Program Chair, at
the address given below. Abstracts, electronic submissions, late
submissions, overlength papers and papers that cannot be published in
the proceedings will not be considered. Papers submitted from
outside North America should be sent via overnight courier service or
express mail. Exceptionally, authors in countries where copying or
printing facilities are limited may submit a single copy in any form
available to them (including electronic mail).
Papers must be received by January 17, 1995 and must not exceed 7,500
words. Authors are responsible for obtaining prior to acceptance any
and all necessary permissions and clearances for publication and are
expected to present their paper in person if it is accepted.
Authors will be notified of acceptance by March 14, 1995.
Camera-ready copies are due not later than April 17, 1995.
Papers that describe use of technology presented at a previous
COMPASS conference are eligible for a special award. Papers of
exceptional quality and appropriate subject matter are eligible for
inclusion in a special issue of the Journal of High Integrity Systems
or the Journal of Computer Security.
Limited financial assistance will be available for student authors.
PROGRAM COMMITEE
Robin Bloomfield Adelard, UK
Connie Heitmeyer Naval Research Laboratory, USA
John Gannon University of Maryland, USA
Rich Gerber University of Maryland, USA
Jon Jacky Radiation Oncology, University of Washington, USA
Jeremy Jacob York University, UK
John Knight University of Virginia, USA
Carl Landwehr Naval Research Laboratory, USA
Keith Marzullo University of California, San Diego, USA
John McLean Naval Research Laboratory, USA
Jon Millen MITRE Corporation, USA
Steve Miller Collins Commercial Avionics, USA
Peter Neumann SRI International, USA
Hans Rischel Technical University Denmark
Jeannette Wing Carnegie-Mellon University, USA
FOR FURTHER INFORMATION CONCERNING THE SYMPOSIUM, CONTACT:
Bonnie Danner, General Chair John Rushby, Program Chair
Computer Science Laboratory
TRW Systems Division SRI International
One Federal Systems Park Drive 333 Ravenswood Avenue
Fairfax, VA 22033, USA Menlo Park, CA 94025
Tel: (703) 876-4383 Tel: (415) 859-5456
Fax: (703) 876-4304 Fax: (415) 859-2844
BONNIE.DANNER@trw.sprint.com Rushby@csl.sri.com
Paul Anderson, Publicity Chair
Space & Naval Warfare Systems Command
SPAWAR 224-1B
Washington DC 20363
Tel: (703) 602-3179
FAX: (703) 602 4485
andersop@smtp-gw.spawar.navy.mil
Additional and typeset copies of this call for papers are available via
anonymous ftp from ftp.csl.sri.com in /pub/compass95-cfp.{txt|tex|dvi|ps}
or via WWW from http://www.csl.sri.com/compass95.html .
Please report problems with the web pages to the maintainer