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 pol-abuse <pol-abuse@igc.apc.org> Posted dadoner@chesco.com Sun Feb 25 06:25:48 1996 http://www.phillynews.com/inq/city/JAIL25.htm] Clerical glitch kept dozens in jail too long: Up to 100 people stayed in Phila. jails after judges had freed them. By Suzanne Sataline [PGN-Abstracted From the Philadelphia Inquirer: City & Region, 25 Feb 1996] As many as 100 citizens were locked in Philadelphia's overcrowded jails for weeks and months after judges had ordered them freed. Sentences, paroles, work releases, and drug rehabilitation orders remained unrecorded for several weeks, mostly from a single courtroom (Rocket Docket) specializing in disposing of something like 150 cases each day. Apparently, the paperwork was generally OK. However, after a lot of finger pointing, it seems that the paper orders were not being entered fast enough into the new computerized system, and that that system was the driving force for putting orders into effect.
I went to NYNEX's page looking for ISDN information, and attempted to open the appropriate link. For whatever reason, NYNEX's ISDN page is named "iixxxpg1.html." SurfWatch, deftly noting the "xxx," decided I was trying to access something naughty and blocked the page. This might not be so problematic for just one page, but a large number of NYNEX's pages have the forbidden xxx in them. Not just potential ISDN buyers, but those requesting information on phone cards, home products, NYNEX grants, towns which NYNEX serves, business and home-office services... Anyone running SurfWatch will be blocked from all of this information. Granted, there are far more pages with xxx in their names that contain questionable material, rather than NYNEX info. But it is an issue that people--especially large companies who want as wide an audience as possible--now have to keep in mind. David
IEEE Software seeks articles for this special issue, scheduled for publication in May, 1997. Software development is an inherently risky business, but risk is not spread evenly over all software projects. The most risk-prone projects are likely to be the very ones to offer the most attractive opportunities. The tradeoff between risk and opportunity must necessarily involve a disciplined approach to the capture, assessment and tracking of risks. This special issue will focus on the practice of software risk management. We seek original articles on: o case histories of risk management in action o risk assessment and tracking tools o legal and social issues pertaining to risk o software risk management in practice Authors should present their work in terms that are useful to the software community at large, emphasizing lessons learned. Please submit one electronic copy in RTF interchange format or eight printed copies by August 1, 1996 to either of the special issue editors: Barry W. Boehm Tom DeMarco TRW Professor The Atlantic Systems Guild University of So. California Computer Science Department PO Box 160 Los Angeles, CA 90089-0781 Camden, Maine 04843 T: 213 740-8163 T: 207 236-4735 F: 213 740-7285 F: 207 236-8432 boehm@pollux.usc.edu tdemarco@shore.net Articles should be 10-20 double-spaced pages, including illustrations. Submissions are peer-reviewed and are subject to editing for style, clarity, and space. For detailed author guidelines, contact Angela Burgess, IEEE Computer Society, PO Box 3014, Los Alamitos, CA 90720; fax 1 (714) 821-4010; aburgess@computer.org. ===Tom DeMarco, The Atlantic Systems Guild: tdemarco@shore.net===
>[Perhaps this explains (in part) the
>number of articles regarding air safety in comp.risks ;-) ]
Not content to let them lie, Shaw has suffered the consequences. His note,
with follow-ups in RISKS-17.72, is included in my `Incidents and Accidents
with Fly-By-Wire Commercial Aircraft' Compendium:
http://www.techfak.uni-bielefeld.de/~ladkin/
New items of potential RISKy interest are:
*) Three papers which discuss the notion of `cause' and use as examples the
X-31 accident and the Warsaw A320 accident:
1. `The X-31 and A320 Warsaw Accidents: Whodunnit?' by Peter Ladkin, which
discusses articles from RISKS (16.89, 17.45, 17.46, 17.47, 17.60) and
elsewhere.
2. `A Model for a Causal Logic for Requirements Engineering', by Jonathan
Moffett, Jon Hall, Andrew Coombes and John McDermid, to appear in the
Journal of Requirements Engineering.
3. `Reasons and Causes' by Peter Ladkin, which continues discussion arising
from the first article, and comments extensively on Moffett et al.
*) The full text of AAIB Bulletin 3/95, reported on in RISKS-16.92 and 16.96.
*) `Computer-Related Factors in Incident to A320 G-KMAM, Gatwick on 26 August
1993' by Peter Mellor, which comments on the incident reported in
AAIB Bulletin 2/95.
*) The NTSB Press Release on the December 1995 B757 Cali accident;
`Comments on Confusing Conversation at Cali' by Dafydd Gibbon and Peter
Ladkin, which comments on some linguistic features of the ATC/pilot
communications as reported in the NTSB Press Release.
(Concerning Cali: a limited analysis only is possible from the Press
Release. The FMS may be peripherally involved, since I understand the pilots
were using it to obtain navigational information just before impact, and the
turn which led to impact was initiated by an autopilot selection. This by
itself wouldn't justify RISKy comment. However, there has been discussion in
the non-specialist press and on some newsgroups about other aspects of the
accident so I thought it as well to include some available reliable info.)
Planned to appear shortly:
*) Clive Leyman has just finished an analysis of the braking distances
at Warsaw, which I hope will be available before March 1.
*) a summarised version of AAIB Bulletin 2/95 (see above).
David Lesher (wb8foz@netcom.com) writes: > I'm beginning to seriously consider that advice [Dyson?] to withdraw > ALL your money on 30 Dec 1999 & keep it cash for a day or two.... Now there's risk of the year 2000 that I hadn't thought of. What if *lots* of people take that advice seriously, and as December 1999 passes, there are increasing intense runs on all the banks? Now throw in a few news reports of particular banks whose cash reserves run low to the point of possible failure — and add to that the even faster Net of 3 years from now, and its even greater ability to propagate misstatements ahead of their corrections. A vicious circle follows, and banks start collapsing left and right — a process ended only after massive economic damage by government intercession in the form of a Rooseveltesque banking holiday. (One which incidentally extends into 2000, giving the surviving banks time to detect and correct their remaining serious bugs, so the computer-disaster scenario that started the process is forestalled after all.) Do I believe it? Well, no. Do I believe it *couldn't* happen? Well, no. Do I intend to withdraw all my money in *November* 1999? Well, no... Mark Brader SoftQuad Inc. Toronto msb@sq.com
On Sunday, 25 Feb 1996, the Bar-Ilan University Library Alpha VAX was working with only one third of the cpu. An attempt to reboot stopped the computer completely. The Digital technician changed the memory board and found a real dead bug in the old board. It seems that even the best of computers are not bug proof. Chaim Seymour, Chairman, Cataloguing and Classification Department Wurzweiler Library, Bar-Ilan University, Ramat Gan 52100 Israel 03-5318127
In an offline correspondence, Li Gong noted that the circumstances when files were accidentally deleted after pressing the space bar were somewhat unclear, including a system upgrade and system disk formatting, so this may have been a one-off incident. In any case, neither Li Gong nor I were able to reproduce the problem. Please note that I am in no way suggesting that this incident did not happen. The Macintosh has an extremely robust file system (especially given its design and usage constraints) with some automatic repair capability. If it appears that something may have been lost, I recommend that users run the Apple "Disk First Aid" utility, which can repair many file system inconsistencies. Also, there are third-party utilities, such as Symantec's "Disk Doctor" that repair and test an additional set of problems, including hardware errors and bizarre file creation dates, that Disk First Aid does not address. In all circumstances, however, the best remedy is to realize that these problems can happen, and use a consistent backup strategy to provide reasonable assurance against data loss, whether by operating system glitches or one's own dumb mistakes. Indeed, in our offline correspondence, Li Gong noted that the missing files were quickly recovered from a recent backup. Martin Minow, Apple Computer Inc. minow@apple.com [Thanks to the many of you who also responded on this curiosity. PGN]
We do not view the risks of the Java problem (RISKS-17.77) in the same light as Sun. Please see http://www.cs.princeton.edu/~ddean/java for our rebuttal to Sun's reply. Drew Dean <ddean@cs.princeton.edu> Ed Felten <felten@cs.princeton.edu> Dan Wallach <dwallach@cs.princeton.edu>
> ... Playboy now prints the e-mail addresses of people who send electronic > Letters to the Editor. If I send Playboy anything in the future, I will > be sure to send it on paper. Most publications that accept 'Letters to the Editor' via e-mail will, on request, publish only the traditional Name,City,State. But ONLY IF YOU ASK. Risk? Never assume nuthin' ....
>If I were going to censor anything about the WWW, it would be the use, >by those of us who should know better, of the term "publish" to >describe the act of making data available from a server. While publishing isn't the only purpose of web pages, publishing is exactly the purpose of my web pages. My goal was to make information available to others and to distribute it. This is what a publisher does. I do not interact with any viewer or reader, and have no desire to do so. If I didn't use the Web, then I would have had put together a booklet or pamphlet. >Most people do not understand that surfing the net is much more like >placing 'phone calls than reading a magazine found lying on a chair. No, it's more like wandering through a library or bookstore, looking at the spines or covers, and occasionally opening a book up to decide if its the one you're looking for. > Publishers are required to register with the government, for goodness' sake. This is not true in the United States. Except for business licenses for tax purposes, or for special mailing rates, the registering of publishers would (and should) get immediate response, not just from publishers organizations but from the ACLU. I can (and do) publish a newsletter without getting anyone's permission. >Magazines may be mailed to non-subscribers; but only computer geeks >know that the images on the web-browser's screen appear only when the >user calls for them. This is akin to saying that the pages of a book are blank until I turn to them. The information that is used to create a particular web page exists on its server independent of the number of people who happen to be viewing it at any one time. >Links to other folks' pages are akin >to giving out a 'phone number--no one who does so should be thought >responsible for any message which may be heard by calling it. Wrong again, they are more like giving out a card catalog number, ISSN, ISBN, or simply a book's title. A list of links is like a bibliography. All, including URLs, describe how and where to find a particular publication or source of information. And like a book, magazine or newsletter, no one sees my web pages unless they make an effort and decision to see them, by clicking on the link or typing it in. There seems to be an attempt here to split semantic hairs, confusing the fact that while information may exist on the server, it can only be read through a client. The only novel item introduced by the Web in the publisher/reader relationship is that the information presented is sent on demand (and perhaps individually tailored) to the person requesting the information. -HK hkoenig@halcyon.com
I have been working on a large document for the British Standards Institution. They use Word 6, and provided me with a diskette containing the latest master so that I could make my amendments electronically. One thing that had surprised me about the printed draft was that the words "reliability's" and "non-conformance's" occurred all over the place, whereas I had originally written "reliabilities" (as in: "The same software may show different reliabilities on different installations.") and "non-conformances" (as in: "The purpose of Fagan inspection is to detect non-conformances between code and design before these become faults in the delivered software."). When I ran the Word 6 spelling checker, the reason became obvious. The dictionary did not allow for a plural of either of these words. The typist who had originally input my text had taken its suggestions at face value and done a global change. The checker also insisted that I was either "Mellow" or a "Melon", and that M.E. Fagan of inspections fame was either a "Pagan" or a "Fagot"! :-) Peter Mellor, Centre for Software Reliability, City University, Northampton Square, London EC1V 0HB, UK. Tel: +44 (171) 477-8422, p.mellor@csr.city.ac.uk
This problem has been independently verified by other WFW 3.11 users.
We have a mail file on the subject, including a message from
Rick Mayell[101323,2073] , Project Engineer, South Western Electricity.
It appears to be verified by Microsoft (obliquely) in Document Q110092.
Subject: Data loss: VCACHE with BDE, problem??
Windows For Workgroups Caching Problem
This problem was discovered using Borland Delphi, however the engine
is the same, and the same problem may be apparent on Paradox...
We have discovered a problem where the WFWG 3.11 VCACHE caching
mechanism appears to stop committing data to the local hard-drive
and is lost following a hard reset or power-off. Disabling 32-bit
access and using Smartdrv appears to correct the problem (see note 5).
Known factors:
(1) We have so far only observed the problem when the system is running
our application which is written in Delphi 1.0 and uses the Borland
Database Engine (BDE) ver 2.51a. Note: The BDE cache is NOT the
cause of the data loss (see point 3). We have not been able to
determine whether it also occurs without our application running.
If our app or the BDE causes VCACHE to fail - we have not been
able to determine how this occurs since it seems to happen
somewhat randomly (?)
(2) A significant amount of data can be lost - even several hours worth
- so this is not the effect of write-behind cached data that has
not yet had the opportunity to commit at the time of reset. Our app
can sit idle for an hour and still lose cached data.
(3) The Borland Database Engine caching mechanism is NOT responsible
for the data loss.
Evidence:
-after each data post, each table in our app is closed and/or
flushed from the BDE cache using the dbiSaveChanges engine
call
-data is also lost from text output files written to with the
Pascal writeln command
-data is lost from all other running apps (see Notepad example
below)
(4) When VCACHE fails... all running apps fail to commit data to the
local drive. We tested Notepad running concurrently with our app -
periodically editing and saving a file from Notepad as we worked
on our app. After reset data added after a given point in time is
not included in the file. The time of failure to save data is the
same time as for our app and all other running apps. The Progress
Runtime client also acted this way in a similar test.
(5) When 32-bit file access is disabled, and only Smartdrv is used to
cache data - this problem DOES NOT exist - even when write-behind
caching is enabled (of course, in this case, the last 5-seconds
worth of editing will be lost). This suggests that even if our
app or the BDE causes the failure, then VCACHE is somehow
vulnerable in a way that Smartdrv is not. The problem does not
exist in Windows 3.10 or 3.11 (non-Workgroups) - since these do
not use VCACHE/32-bit file access. We have not tested the
behaviour yet under Windows 95.
(6) We have identified this problem using two fairly different
computer systems (one DEC and one Acer) - both running
WFWG 3.11 on a Novell 4.10 network (all patches installed)
with recent VLMs (version 1.20a).
(7) Data written to network volumes is NOT lost (of course, this
data is not cached by VCACHE)
(8) All the running apps seem to behave "as normal". not reporting
errors. Note: when the apps write data - they can re-read it
back successfully even though this data will be lost after reset,
therefore, the data does exist in the cache as valid data -
the data just has not been flushed to the disk.
(9) The problem seemed to be connected to low USER resources (<40%)
- however, we have reproduced it with fairly high (>55%) levels
so we are not sure if there is really a connection.
Does anyone recognize this problem ???
Thank you, in advance, for any help.
Contacts:
amber_computer@mindlink.bc.ca
Ted Sorensen, Systems Analyst / Programmer, Amber Computer Systems Inc.
or Dave Robinson, VP Development
Ph: 604 599-9167 Fax: 604 599-9261
WordPerfect has a feature that generates a table of contents at a chosen place (at the front by default). I had a long report which needed this feature, and to see whether I had marked enough text to make a sensible contents list I generated the table with only the 'body' of the report entered. It worked well. I then went to work to add the conventional pages before the TOC - summary, title sheet, and so on. When this was done I started improving the body, and in due course needed a new TOC. Result: summary, title sheet, and so on all disappeared. What WPF does is to mark a section of text as 'generated' using marker codes which you don't normally see. When you generate a TOC, it removes all the text between these markers and inserts what it creates. Unfortunately, moving to 'top of text' can get you above the TOC but (just) within this marked area. Result: anything you have put there gets wiped out next time you do a 'generate'. Pretty obvious when you look into it - but infuriating to a learner. John Haseler
The current thread, about Word using disk space without initializing it, seems not to be a Word problem, but an OLE problem and thus would apply to all applications that use OLE2. I have noted this problem with Word on my own workstation. Additionally, Microsoft has addressed this problem and a fix is available for Win 95 users in the recently released Win 95 Service Pack. I believe that the OLE2 update is also available as a single file download from ftp.microsoft.com. I am not defending Microsoft's products in any way. I use them because I have to and I don't care about which vendor's product is "better" as long as the one I have allows me to get the job done effectively. It appears that the Microsoft fix does indeed work and we may now direct our thoughts to other topics. I am also surprised that Microsoft addressed this problem so quickly! ;-)
Several authors have noted the presence of "extra data" within Microsoft Word files. These are frequently found in files that use the "Quick Save" feature of Word. Here a document is first saved as a baseline and subsequent saves will only update it with the changes. Another feature of Word is the "Undo" command. Any text that is deleted from the document can be "Undone" up to the point of the last save. Thus an "Undo" cannot retrieve text from a previous increment of the document. However, all of the deleted text is still within the original document. This can be verified with a disk editor. The best way to remove this undesired text is to user the "Save As" command create a new document. All of the deleted text is left behind in the original document. The obvious risk is taking a classified document and trying to remove classified data to create an unclassified document. Unless a new document is created, all the deleted data is still part of the "unclassified" document. Word will not display the deleted text, but a disk editor or non-Word word processor will be able to display it. On another note, the problem of extra data found between the end of file mark and the end of sector has been around since the beginning of DOS. DOS will fill the space with random data from memory. I have seen disk directory data and parts of documents in that space. This also is a problem when unclassified files were copied from a classified machine onto a floppy disk. Special utilities were created to zero fill these "slack bytes" as they were called. The bottom line is, if you want to be sure that unintended data is not included in a Word document, check it with a disk editor. They usually have an ASCII/HEX find feature that will scan the file. It will find any text in a document that Word refuses to display on the screen. The disk editor will also display the slack bytes in a file. These procedures are needed only if you have very sensitive data that should not be disclosed. Rich Mulligan rich.mulligan@trw.com TRW Space & Electronics Group, Redondo Beach, California, USA [Lots of submissions on this topic. Just one more follows. PGN]
I came across an interesting security problem with Word not too long ago. I was preparing a highly confidential document for release to the licensees of the technology of the company I work for, and the company lawyer had given me a paper stack of pending patent application abstracts. I was to format these and include them in the document I was preparing. For each patent application, there was a figure and a single paragraph. I also got the same information on disk. I would edit the disk information into my document and reserve white space for where the figures would be pasted in. I was given paper copies of the text, so I could match up the stuff on disk with the paper figures. A funny thing happened when I opened up the file on my Mac. The Mac version of Word is always downrev from the PC version, and so I lost all the formatting of the file. That's okay because I was going to re- format it anyway. But even after stripping out all the formatting information which had become garbage, the text itself was slightly mutilated, with large blocks of text in out-of-order sequence. Fortunately, I had the paper copies, so I could reconstruct the file fairly easily. But then I discovered I had something like a dozen paper figures and paragraphs, but more like 20 paragraphs in the disk file. The next day, when I asked the lawyer whether he had forgotten to give me paper copies of some of the stuff on disk, he was surprised I had those extra paragraphs. Those were for patent applications that hadn't even been filed yet, and were definitely NOT for release to the licensees before then! What happened was he had taken a larger file, edited out the stuff I wasn't supposed to see, then copied the file to a floppy. I converted the file to the Mac, and reconstructed the original file. When you save a file in Word, it usually does a "fast save". That means a small amount of information is saved that tells Word what changes you made to the original. That's faster than actually re-writing the whole file. You can disable this "feature". I suppose Microsoft should make that as the default. Or, you can do a "Save As", which will force the true file to be written out. Mark Thorson (eee@netcom.com)
Please report problems with the web pages to the maintainer