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…
Here is a press release from the U.S. Department of Justice.
National Criminal Justice Information Conference in New Orleans
To: City and Assignment desks
Contact: Stu Smith of the Office of Justice Programs,
U.S. Department of Justice, 202-307-0784 or
301-983-9354 (after hours)
WASHINGTON, Sept. 23 — A national conference on federal-state criminal
justice information sharing will be held from Wednesday, Sept. 23, through
Saturday, Sept. 26, in New Orleans, the Department of Justice announced today.
Jointly sponsored by the Bureau of Justice Statistics (BJS) and the Justice
Research and Statistics Association (JRSA), the conference participants will
discuss "Federal and State Information Sharing to Effectively Combat Crime and
Ensure Justice."
Specific topics that will be aired include "New Measures in the Criminal
Justice System," "'Weed and Seed' and New Drug and Crime Prevention
Initiatives," "Challenges and Reforms to the Justice System in the 90s," "Uses
of Incident-based Reporting Systems," "Recent Developments in Criminal History
Improvements" and various research issues in corrections, prosecution and law
enforcement. Among the approximately 250 people expected to attend will be
officials from state and local government and various federal agencies as well
as leading criminal justice researchers and scholars. Other participants will
be the directors of State Statistical Analysis Centers (SACs) and other
members, associate members and guests of JRSA.
BJS has provided funding to state justice statistics and information systems
through a network of SACs since 1972. There are currently SACs in 48 states,
the District of Columbia, Puerto Rico, the Virgin Islands, and the Northern
Mariana Islands. The SACs provide a wealth of data about crime and the
operation of the criminal justice system to state and local governments,
legislatures, and Attorneys General for policy analysis and planning purposes.
This year is the 20th anniversary of the SAC program. It also marks the
beginning of a new initiative to establish a truly national system of federal,
state and local government information-sharing and readily accessible data
bases.
Additional information about BJS programs and publications may be obtained
from the Bureau of Justice Statistics Clearinghouse, Box 6000, Rockville, Md.
20850. The telephone number is 800-732-3277.
Canada Remote Systems - Toronto, Ontario
World's Largest PCBOARD System - 416-629-7000/629-7044
I wasn't going to contribute this until I read David Paschich's contribution
(Wed, 16 Sep 1992) concerning potential confusion of users on electronic
networks.
Working within a computer-oriented university department, a lot of internal
work (memos, reminders etc) gets distributed by e-mail. Such distribution
lists exist for staff, postgraduate students and so on. This afternoon, a
postgrad. student was surprised to receive complaints from postgraduates at a
neighbouring institution about an e-mail message he had sent for internal
distribution.
What had happened was that an electronic mail address had become truncated and
passed through the smart address matching path. None of the machines on that
path flagged the address as invalid and the mail was sent on up the chain.
When it reached the other institution, it was distributed to their
postgraduates.
This incident illustrates the potential for embarrassing disclosures,
particularly in view of two results from a recent e-mail survey we carried out:
Q: Have you sent or received confidential/sensitive information by
electronic mail ?
Yes: 75%
Q: Was the material encrypted or protected in any way ?
No: 91%
Do you know where your e-mail messages are ?
STF
sfleming@uk.ac.hw.cs or sfleming@cs.hw.ac.uk or ...uknet!cs.hw.ac.uk!sfleming
David Paschich writes in Risks 13.81 about one of the risks of getting account names mixed up, the fact that you could inherit someone's reputation (good or bad). While at University I came across another aspect of this problem. When people left their accounts were put on tape and deleted. I have a fairly common name (ask Douglas Adams) and there was someone in the year above me also called Martin Smith. Account names were normally first name and initial of surname but their account wasn't called MartinS, presumably because there'd been a name clash in the past. Thus I was known as MartinS. I came back from the summer holiday and guess which account had been deleted? Things then became even more confusing when I went to get my files back. There was *another* Martin S* (the surname escapes me) just arrived in the new intake who had already been given my old account name. My account had to be renamed to MartinSm. I can't help wondering who got deleted when I left. (not necessarily THE) Martin Smith
The Economist (Aug 15) reports that the National Galleries in both Washington and London have plans to digitally record images of all their paintings, because digital images "last for ever". London hopes to scan their pictures "repeatedly over time ... to track how their colours change": "Since human colour memory is poor, and photographs change colour themselves, the only way to do this is by using a computer." I have trouble here dealing with image files I created a couple of years ago: we have new hardware, software, and file formats. I have all but given up hope that colors will look similar on the screen, when printed, and when scanned in. I hope the museums will give careful thought to such problems. -John Sullivan, The Geometry Center, University of Minnesota
Last time I heard about this incident (Here on comp.risks I believe) it was
told that _both_ "squats" had failed. I.e. there where considerations towards
reliability and safety of the devices.
An interesting question pops up now. Should these devices be wired in an "and"
or in an "or" fashion? I guess that it would be safest to wire them in such a
way that when they agree, they can override the pilot, but if they disagree,
the pilot should be able to take responsibility.
Roger
EMail: wolff@duteca.et.tudelft.nl ** Tel +31-15-783644 or +31-15-142371
I know nothing about planes. I can understand preventing deployment of spoilers or thrust reversers while in the air, but I don't understand preventing brake application. Leslie J. Somos ah739@cleveland.Freenet.edu
re "Airliners playing chicken" from RISKS digest 13.81:
I agree that it is better to have an occasional accident due to a safety
interlock system that fails than to have more accidents due to people
accidentally doing fatal things like engaging the thrust reversers or deploying
the spoilers while the plane is in the air.
However, the better solution is to have an emergency override system that is
simple enough to engage quickly, that cannot easily be engaged by accident and
that warns that it is engaged. And, of course, there must be severe penalties
for anyone who uses it except under emergency conditions.
To use a computer analogy, there can be serious accidents if everyone has
superuser privileges enabled all the time. But there are also problems if you
cannot get privileges when you really need them — like at 9pm when no one is
around and you just have to read that protected file!
Larry
Or, we can realize that failures and "impossible" circumstances do occur, and
install overrides so the pilot can tell the system it's wrong. People deal
with unforeseen circumstances better than computers.
Marc
A few quick comments on items in RISKS-13.81: David Wittenberg reports on airliners playing chicken, and suggests that we "not panic when a safety device does cause damage" even though switches "used in all sorts of safety devices ... will eventually fail". I'd like to see an overridable switch: if the pilot engages the brakes or thrust reversers, and the computer thinks the plane is in the air, it shouldn't just quietly fail to engage them, but should tell the pilot what is going on, and leave some way to override the ground/flight switch. Daniel Burstein is concerned about the post office's plans to send images of hand-written envelopes via computer to remote sorting sites, and the possibility that addresses could be stored in a database. Of course letters with typed addresses are already sorted by machines with OCR software, so these addresses are even easier to store. Overnight delivery services must enter each item sent into some kind of computerized tracking and billing system: who knows if any of them have thought to keep a database indexed by sender/recipient pairs? There has been much discussion of the real phone number used in 'Sneakers' for the NSA agent. The movie also shows phone numbers being typed in on a numeric keypad (when they first test the decoder), and at least one instance where touchtones are audible. I didn't try to identify any of these, but I'm sure someone will. -John Sullivan, The Geometry Center, Univ. of Minn. sullivan@geom.umn.edu
In RISKS-13.81, Daniel Burstein relays US Postal Service plans to use remote video technology to allow remote sorting of mail, and notes: "given OCR technology, it would be quite trivial to have EVERY piece of correspondence going through the USPS scanned, and a data list of who sent what to whom could be generated." I want to point out several issues related to this article: 1. The RISK of stored communication matrices--having a record of who communicates with whom--is perhaps simplified, but certainly not created by the use of computer sorting technologies. In small town days, the local postman and telephone operator knew exactly who communicated with whom. 2. OCR Technology is already very widely used by the USPS. If you place a letter in a mailbox that is designated "for envelopes with typed and printed addresses only," that envelope is read by an OCR and a bar code is put on to the envelope corresponding to the zip code. (Try sending yourself a letter in this manner!) 3. There was a front-page article in the LA Times (Sunday, 20 Sept?) that describes how firms in general are using remote technologies to move jobs to remote locations. It's generally a benefit to both the company and the workers. The company gets better workers and lower costs. The workers are happier because their wages go a lot further in the remote geographic location, allowing a better standard of living. Why not let workers in Vermont sort mail that is going through a plant in New York City?
In RISKS-13.81 Daniel Burstein wrote about Remote Video Encoding in use by the
USPS, a procedure involving scanning a letter and sending the envelope's image
to a remote site to be ZIP and barcode processed. [...]
Those who fear this type of data collection are certainly under no obligation
to include a return address on any envelope. In this case (for once!), the
default in mailing a letter is "no return address" and one must override this
default by putting one on the envelope.
-gene-
Gene LeDuc (leduc@nprdc.navy.mil), Navy Personnel R & D Center,
San Diego, CA 92152-6800
Terry Gerritsen quotes The Lawyers Weekly as saying that the 9-year libel action, ultimately successful, of a company against Lloyd's bank for erroneously returning cheques marked "Refer to drawer", is believed to be the first of its kind to reach British courts this century. Actually I am aware of a case identical in all pertinent respects, and while I do not remember the date I am reasonably certain it was within this century. I remember finding it in a search of important libel decisions when I was in the UK and it stuck in my mind. Given such a clear precedent, it's appalling that it took nine years to come to a decision. Peter J. Scott, Member of Technical Staff | pjs@euclid.jpl.nasa.gov Jet Propulsion Laboratory, NASA/Caltech | SPAN: GROUCH::PJS
Mobile data terminals (MDT's) in police cars are nothing new around here (Phoenix, AZ area), and have been in use for years. My experience has ranged from working for an organization which serviced these devices (and thus using them in testing), thoroughly studying the computer system that works in the background, to accompanying on-duty police officers from various departments on many ride-alongs, and viewing the system in action. These systems are in use with virtually every police agency in the Phoenix area, as well as the Department of Public Safety (Highway Patrol), but not with the sheriff's office. The systems are nothing more than data terminals on a radio network. Data traffic is NOT encrypted (risks obvious), and converting an installed base to handle encryption is not feasible for most departments. Log on practices vary, with identification information ranging from officer ID, to shift/beat code, with usually short (and few different) passwords. The "base computer" is connected to several databases, including the National Crime Information Computer (NCIC), the Arizona Crime Information Computer (ACIC), and motor vehicle records. Information retrievable includes driving license records (including traffic violation history), vehicle registration records (including vehicle description), arrest warrant information, stolen motor vehicle records, stolen firearm records, etc. Data retrieval is notoriously slow during busy times (Friday & Saturday night), sometimes taking as long as 30 minutes for a license plate check. Terminal to terminal messaging is possible. Communication with dispatchers is also possible. All transactions are recorded/printed. Accident Risks: A few years ago, the Phoenix Police Department, after experiencing numerous problems with officer's driving and operating the terminals at the same time, improved the ergonomics by mounting the terminal higher and closer to the driver. This way, the drivers eyes are not completely averted from the road while using the terminal. Privacy Risks: It is common practice for officers to "run" license plates on vehicles which they observe, for no reason whatsoever, or for any trivial reason. Information retrieved via the computer includes name, address, SSN, and driving license number of the current registered owner, vehicle identification number, lien holder (usually bank/loan institution), original lien amount, date vehicle first registered, date registration expires, vehicle description, and whether the vehicle is stolen. Registration violations are most commonly found this way. As newer officers (who often are less techno-phobe) take to the streets, use of the system is increasing. False Arrest Risks: Arrest warrant information obtained through the computer (term is "CAPRI Hit") will find the listed individual in handcuffs (i.e. existence of a computer arrest warrant record is sufficient probable cause for arrest). Again, we know how infallible information entered into computers is. These computer warrant records must then be verified against the actual warrant (on paper), before the arrestee can be arraigned (brought before a judge). These warrants are stored in filing cabinets at the sheriff's office of the warrant issuing jurisdiction (here it is the Maricopa County Sheriff's Office, and I have seen the actual filing cabinets stuffed with warrants). This process can be slow, since there are hundreds of thousands of outstanding warrants in these filing cabinets, some going back over half a century. Michael Kielsky, Arizona Public Service Company, P.O. Box 53999, Phoenix, AZ 85072-3999 602-250-2897 (W) 602-919-0182 (M) ...sunburn!overlord!mkielsky
Lauren Weinstein writes about the classic treatment of the "computer- induced" nightmare through "minor" errors: > (A clue: at the end of the piece, the governor's order to stop the > execution is accidentally misrouted...) Actually, the order was to be sent by a special urgent-mail system --- but it was held back because the Governor didn't get it authorized by his supervisor ... (I think I read this short story in a science-fiction collection named _The Astounding-Analog Reader_.) Lars Mathiesen (U of Copenhagen CS Dep) <thorinn@diku.dk> (Humour NOT marked)
Consumer car phones are already shipping with voice dialing. Extending that to replacing the keyboard by speaking letters as opposed to something as fancy as full word recognition would be straightforward. Given not only the safety risk but the awkwardness of using a keyboard in a car along with the compelling value of using the device while driving, I'd be surprised if voice is not added very soon. Let's start the timer going and see how long it takes to get the technology deployed.
>Given the alleged facts here the amount in question must have been >on the order of $3; An incident with similar background but (so far) less outrageous conclusion happened to me. Early in my consultancy I had my business checking account at a small bank. Through a bookkeeping error on my part I bounced a check. The check was small, the account was small, the error was small and the overdraft was small. In what I hope and believe was a complete coincidence, the bank was closed by federal regulators between the time the check was bounced and the time I received notice of it. The check was not honored but the overdraft charge ate up the balance in the account plus a few dollars. Since I couldn't find anybody who had a clue what was going on I just abandoned the account. The bank was purchased by Texas Commerce Bank, one of the largest in the area. For several months they accrued overdraft charges to my old account because it now had a negative balance. The end result was that they wrote off the account with about $75 owing and sent me a nice registered letter to the effect that I had "caused a loss" of $whatever to the bank. The way I see it they made off with the $12 I had in there when they bought the old bank, but I suspect they could have one of those stealth arrest warrants issued for me by including my case on a list of other "losses" and mailing it to the district attorney. I also managed to spend a couple of hours in jail once due to a parking ticket that was over five years old. It was legitimate and once I was told about it I vaguely remembered having gotten it, but I had completely forgotten it. The arresting officer could not tell me what I was being charged with at the time of the arrest, which I found pretty offensive. All he knew was that a warrant existed. What I don't understand is why they can't send out letters to people instead of lying in wait for them and wasting everybody's time. It wasn't like I was going to flee the country over a parking ticket. Steve Nuchia South Coast Computing Services, Inc. (713) 661-3301
Phil Karn comments about a computer terminal mounted on San Diego police cars; these devices can be (and are) used by the driver while in motion. He points out the safety risks associated with that (typing/reading while driving). Karn also mentions that "[the police] like to drive around semi-continuously punching in license plate numbers", i.e., that they check plates in many situations that are not "only when they really suspect somebody (e.g., during a stop)". So there's a change with respect to the previous situation: now the checks on plates can be (they probably are) stored and can be manipulated much more easily; more such data is gathered; and, more relevant to RISKS, it can be easily matched with location, as police cars (will) have devices that continuously report their location. Of course, if the records exist, they will eventually be used against someone. This is yet another instance of a common risk: having more and richer data changes the possible uses of such data. Cristobal Pedregal Martin pedregal@cs.umass.edu (internet) Computer Science Department UMass / Amherst, MA 01003
Lauren Weinstein writes:
> The classic treatment of the "computer-induced" nightmare through
> "minor" errors must be the humorous (fictional) piece done by
> "Datamation" in the early 70's.
As I recall, the title of the story was "Computers Don't Argue," and
it was not original with Datamation. I think it appeared first as a
science-fiction short story in the late 60's.
Geoff Kuenning geoff@ITcorp.com uunet!desint!geoff
Please report problems with the web pages to the maintainer