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…
An amusing tidbit on unexpected risks of technology:
The Reuters news wire reports on an odd form of interference from
cell phones and pagers:
RTw 01/30 0425 Israeli rabbi pulls plug on cellular phones
JERUSALEM, Jan 30 (Reuter) - An Israeli rabbi has banned cellular
telephones and pagers from synagogues, saying they interfered
with worshippers' communication with God.
Rabbi Mordechai Eliahu, a renowned sage and a former chief rabbi
of the Jewish state, published the edict on Monday.
Interestingly, the cell phones are called, "Miracle Phones."
Maybe G-d needs spread-spectrum channels.... <g>.
M.E.Kabay,Ph.D., Director of Education, NCSA (Carlisle, PA); Chief Sysop,
NCSA CompuServe Forum, Mgmt Consultant, LGS Group Inc. (Montreal, QC)
Unknown attackers interrupted, Wednesday Feb.1,1995, 7 glas fibre cables near Frankfurt/Main airport. As parts of the cables were cut out, about 15.000 telephone lines were interrupted. The cables also carried data for Lufthansa's booking computers; consequently, new reservations had to be made manually. As Lufthansa's main computers (installed at Frankfurt airport) were cut off for some time, delays of up to 30 minutes were caused. According to diverse German media, police has no information about backgrounds of this criminal attack. Klaus Brunnstein (February 2,1995)
I was recently asked to participate in an opinion survey feedback to management in order for them to compare their own views, superior views, peer views, and subordinate views. This data is then to be used by the reviewee as a self improvement tool. In order to get honest feedback, a commercial P.C. software package called "2020" was used as a survey tool. This package is supposed to protect your anonymity. It also uses a user supplied password on each diskette to prevent anyone reading your responses. The responses are then collected by a master program and combined with everyone else's responses. Only the combined result is seen, individual responses are not ever seen or tracked. At least, that's the theory. Since privacy and encryption have been a long time interest of mine, I decided to take a look at the files. The first thing I saw was that both my name and my reviewee's name were embedded in the data area. The next thing I saw was that free form comments were stored in clear ascii. You lose the formatting, but any file viewer could see the comments. I used a hex editor to change some of the comments then reinvoked the program to see if it would detect the changes. It never noticed a thing. It obviously didn't use a digital signature or even a simple checksum. The cherry on top was the password. It only uses 0-9 & A-Z (uppercase). The password was stored encrypted: down-1 and backward. Thus a password of "simple6" was stored as "5DKOLHR". This took me all of the commercial breaks while watching Star Trek Voyager to find and figure out. The net result was that I chose not to participate in the anonymous feedback survey. dave.moore@tcbbs.cais.com
Today I received an interesting letter from NYNEX (nee NY Telephone, the local telephone service provider in NY City): Our records indicate that you requested All-Call Restrict Service on your telephone line... During a recent system check, we discovered that All-Call Restrict Service was not in place on some lines which it had been requested. We are in the process of checking every All-Call Restrict line and correcting this problem where it exists. As soon as we complete the checking and correction process, we will confirm the status of All-Call Restrict on your line through a special notification. In other words, you might have thought you had Caller-ID disabled when you make calls from your line, because you ordered it and NYNEX sent you a confirmation notice six or seven months ago, but unless you independently verified that it was in place, you might have been sending your number all this time. I can tell whether my line is sending caller-ID because I can call a friend with a display and ask him. But as usual, there is no way the local telco can tell you what your lines settings are. Call the billing office, and they will describe what you have ordered and what was reported to have been installed, but what is actually on the line? It would be nice if you could dial a number and have a voice robot read back to you the settings actually in place — surely this is possible with today's digital exchanges, if anyone thought to implement it. Given how many different settings you can have with today's phone lines in the USA (call forwarding, speed dialing, send or don't send Caller ID, choice of long distance carrier, etc), we already need it.
So reported the Schenectady, New York Gazette on 2/1/95. The report said Now, [Nynex] has discovered that All-Call Restrict feature doesn't always work. "The company is indicating to our staff that roughly between 10 percent and 15 percent of people who believe they have All-Call blocking may have a situation where it doesn't work." That means as many as 82,500 people's numbers are being divulged when the think those numbers are being blocked. Nynex officials say they are investigating the problem and should have a cause identified sometime next week. "After this, one of the important things we'll do after we identify the cause is implement new processes that will prevent this from happening again." New England Telephone, Nynex's subsidiary, is checking to make sure its call blocking is working. The problem was revealed by an Albany man who depends on anonymity for hit livelihood. He tried for weeks to convince Nynex that his call blocking was not working, only to be told it was. Eventually [the man] took his story to the local press. The company's routine maintenance tests in its 600 central switching offices hadn't discovered this glitch. To me the risk here is the arrogance that allows people to argue that such large complex, distributed systems can ever be built flawlessly. Any claim that the system will always protect the customers privacy is fatuous. It happened already and it will certainly happen again sometime somewhere. Dick Mills Power Technologies, Inc. P.O. Box 1058 Schenectady, NY 12301-1058 rj.mills@pti-us.com +1(518)395-5154
[It didn't start out this way, but this seems to be the start of a "mini" series of reviews on the topic of PGP. Garfinkel's review is due to be sent in another two weeks, Schneier's a week after that; Peachpit has one due out in February while Zimmerman's own, I found out yesterday, is due out in April. - rms] BKPRTPRV.RVW 941214 "Protect Your Privacy", Stallings, 1995, 0-13-185596-4, U$19.95 %A William Stallings ws@shore.net %C 113 Sylvan Avenue, Englewood Cliffs, NJ 07632 %D 1995 %G 0-13-185596-4 %I Prentice Hall PTR %O U$19.95 (515) 284-6751 FAX (515) 284-2607 camares@mcimail.com %P 302 %T "Protect Your Privacy" This is the first-released of at least three books on PGP (Pretty Good Privacy), the encryption and authentication package by Phil Zimmerman. It covers the concepts of encryption, public key encryption, authentication and key management, as well as the installation and operation of PGP on MS-DOS and Macintosh platforms. There is also some overview of front end shells for DOS and Windows, plus helpful supplementary information on password/phrase choice key servers, and where to get PGP. (The promise of coverage for Windows, UNIX, OS/2 and Amiga in the promotional literature is overkill, but these interfaces will be almost identical to those covered.) Stallings' material is generally very clear and well written. Many times, however, concepts are introduced early in the book but not explained until much later. This is particularly true of key management. In most cases, I can assure the reader not to worry--all will be made clear, eventually. (In some few cases, the explanation may remain confusing until you actually run the program.) The book echoes the assertion by many that PGP has become the de facto standard in Internet privacy and authentication. Certainly no commercial product has anything like the same range of use. Full acceptance of PGP, though, has been hampered by the version incompatibilities and the legal difficulties caused by the US weapons (!) expert control laws. Given the touchy nature of this subject, it is not terribly surprising that both Stallings, and Michael Johnson in the access document, comment only briefly on the subject. These passages are somewhat calming, but hardly calculated to inspire confidence. Solid background on the technology, if sometimes disjointed. Terse, but serviceable documentation on the program. Readable and informative. copyright Robert M. Slade, 1994 BKPRTPRV.RVW 941214 Vancouver Institute for Research into User Security Canada V7K 2G6 ROBERTS@decus.ca Robert_Slade@sfu.ca rslade@cue.bc.ca p1@CyberStore.ca
The journal "Information Technology and People" has just published a special
issue, edited by Roger Clarke <roger.clarke@anu.edu.au> entitled
"Identification Technologies and Their Implications for People". As the
title suggests, it's about computer technologies that identify particular
human beings, as well as applications of those technologies to automated
tracking of highway traffic. Here are the contents:
Roger Clarke
"Human Identification in Information Systems:
Management Challenges and Public Policy Issues"
Simon Davies
"Touching Big Brother:
How Biometric Technology Will Fuse Flesh and Machine"
Marcus Wigan
"The Influence of Public Acceptance on the Realisability of
the Potential Benefits of Intelligent Vehicle-Highway Systems"
Philip E. Agre and Christine A. Harbs
"Social Choice About Privacy:
Intelligent Vehicle-Highway Systems in the United States"
Full details on the issue, including abstracts for the papers, are available
on the web at:
http://weber.ucsd.edu/~pagre/identification.html
Or through e-mail by sending a message that looks like this:
To: rre-request@weber.ucsd.edu
Subject: archive send identification
Phil Agre, UCSD
I've recently started using the Seyon terminal program to dial in to my university account from my home Linux system, and have discovered an interesting risk that is found in Seyon, and perhaps other terminal programs. One thing I use Seyon for is uploading and downloading files using the Zmodem protocol. To down load a file, you simply enter "sz filename" on the host machine, and like magic, the file is downloaded. That is the risk. Apparently, the sz program used to download files sends some special character sequence that Seyon is set up to recognize, and then automatically start the download. While this makes downloading nice and easy, it is entirely possible that this sequence could take place without the user noticing what was happening - there are no confirmations from the user required for the download to take place. It is not hard to imagine someone building a virus based on sending the Zmodem startup sequence, and then simply downloading a file to the remote system. I would imagine this could be even embedded into a regular text posting. Thus a naive or tired or busy user could have some unknown file downloaded to their system simply by reading some posting. I imagine you can configure Seyon to avoid this behavior, but it is apparently the default mode — and one that is likely to be used by bunches of people. It is likely that other downloading protocols and terminal emulation programs allow similar actions. I think it is important to recognize the risk in this, and at the least, any program that allows automatic downloading should by default require the user to confirm that it is OK to proceed. Power users can turn off the confirmation. New and casual users would have some protection from unintentional downloads. Bruce E. Wampler, Ph.D. (wampler@cs.unm.edu) Adjunct Professor, Department of Computer Science, University of New Mexico
Hello. My name is Bashir Jiwani and I am a graduate student in philosophy at the University of British Columbia in Vancouver, Canada. I began looking into ethical issues of information technology for a course I was taking this past semester. I have developed an interest in these issues and have decided to pursue this interest further. To this end I am pleased to announce that with the help and support of the UBC Centre for Applied Ethics a new mailing list that is intended for discussion of topics in this area has been created. This list is to be different from existing lists in this area in several important respects. Firstly, the list is to be moderated. That is, all submissions to the list will not automatically be posted to the list members. Rather, they will first arrive at the moderator's mailbox. The moderator will then put together the various submissions, screening for length and administrative content, and then send them out to the list subscribers. Secondly, and perhaps most importantly, there will be an established agenda of topics that will serve to guide discussion on the list. Rather than just waiting around for something to happen to get people talking, I have put together a list of topics that the discussion will progress through. For each topic I have tried to gather a few relevant articles as background reading and have placed them at the list's WWW site. As well I have prepared some basic notes for each topic that fleshes out some of the issues that are thought to be of concern. In this way I have availed myself as the presenter of these topics. I have prepared so far presentations in three topic areas. My hope is that the role of presenter will be shared with the members of the group who are interested in specific issues in information technology ethics and who are willing to put together a small package of background materials for the group's benefit. So as we get to the last of the topics I have set out, I am hoping someone else will have a specific area of interest and will present this area to the list by sketching some of the arguments at issue and by locating various articles that will give participants some background information. The third most significant difference is the WWW site that the list is associated with. The web site is to serve various functions. It is to make available the presenter's background materials either by providing links to copies which may be located here or at other sites. The web pages are also intended to archive list discussions. As well, any links that members might feel may be useful can also be set up on these pages through the administrative moderator. As I have mentioned, I will be both administrative moderator and topic presenter for the duration of the first three discussion topics after which it is my hope that other members will take on the role of topic presenter and I will refine myself to administrative duties. I believe that the list will be attractive to all users of information technology. The participation of philosophers as well as business professionals is especially encouraged. Due to the guided nature of the discussion, the list will officially open as soon as a critical mass of members have signed up. This mass has been set at 40. So as soon as forty people are subscribed to the list, the first set of moderator's discussion notes will be mailed to all members. To subscribe to the list, send the one-word message "subscribe" in the body of an e-mail message to "infotech-ethics-request@ethics.ubc.ca". For a more detailed description of the list or to access the articles and moderator's notes on the various topics or just to surf some interesting waves, visit the web site at url: http://ethics.ubc.ca/people/grads/bashir/infotech.html. Feedback on or about the list can be sent via the web pages or to the moderator directly at infotech-ethics-moderator@ethics.ubc.ca. Bashir Jiwani bashir@ethics.ubc.ca Vancouver, BC
Call for Participation
Third International Workshop on Feature Interactions
in Telecommunications Software Systems
Kyoto, Japan
October 11-13, 1995
Description
This workshop is the third in a series, whose mission is to encourage
researchers from a variety of computer science specialties (software
engineering, enterprise modeling, protocol engineering, distributed
artificial intelligence, formal techniques, software testing, and
distributed systems, among others) to apply their techniques to the feature
interaction problem that arises in building telecommunications software
systems (see the back page for a description of the problem). We welcome
papers on avoiding, detecting, and/or resolving feature interactions using
either analytical or structural approaches. Submissions are encouraged in
(but are not limited to) the following topic areas:
- Classification of feature interactions.
- Modeling, reasoning, and testing techniques for
detecting feature interactions.
- Software platforms and architecture designs to aid
in avoiding, detecting, and resolving feature interactions.
- Tools and methodologies for promoting software
compatibility and extensibility.
- Mechanisms for managing feature interactions
throughout the service life-cyle.
- Management of feature interactions in PCS, ISDN, and
Broadband services, as well as IN services.
- Management of feature interactions in various of the
operations support functions such as Service
Negotiation, Service Management, and Service Assurance.
- Feature Interactions and their potential impact on
system Security and Safety.
- Environments and automated tools for related
problems in other software systems.
- Management of Feature Interactions in various other
enterprises, such as banking, medicine, etc.
Format
We hope to promote a dialogue among researchers in various related
areas, as well as the designers and builders of telecommunications software.
To this end, the workshop will have sessions for paper presentations,
including relatively long discussion periods. Panel discussions and tool
demonstrations are also planned. The first day of the workshop, October 11,
is devoted to tutorials and discussions on areas related to feature
interactions.
Attendance
Workshop attendance will be limited to 100 people. Attendance will be
by invitation only. Prospective attendees are asked to submit either a paper
(maximum 5000 words) or a single page description of their interests and how
they relate to the workshop. Proposals for tutorials and discussions are
also requested (maximum 3000 words). About 16-20 of the attendees will be
asked to present talks; a small number of tutorials and/or discussions will
also be selected. We will strive for an equal mix of theoretical results
and practical experiences. Papers will be published in a conference
proceedings.
Submissions
Please send five copies of your full original paper or interest
description to:
Kong Eng Cheng
Department of Computer Science
Royal Melbourne Institute of Technology
GPO Box 2476V
Melbourne, Victoria
AUSTRALIA 3001
E-mail: kec@cs.rmit.edu.au
Tel: +61 3 660 3266
FAX: +61 3 662 1617
Important dates are:
February 28, 1995: Submission of contributions.
May 15, 1995: Notification of acceptance.
June 26, 1995: Submission of camera-ready versions.
Workshop Co-chairpersons
Tadashi Ohta (ATR, Japan)
Nancy Griffeth (Bellcore, USA)
Program Committee
Co-Chairpersons:
Kong Eng Cheng (Royal Melbourne Institute of
Technology, Australia)
E. Jane Cameron (Bellcore, USA)
Jan Bergstra (CWI and University of Amsterdam,
The Netherlands)
Ralph Blumenthal (Bellcore, USA)
Rolv Braek (SINTEF DELAB, Norway)
Bernie Cohen (City University of London, UK)
Robert France (Florida Atlantic University, USA)
Haruo Hasegawa (OKI, Japan)
Dieter Hogrefe (University of Bern, Switzerland)
Richard Kemmerer (UCSB, USA)
Victor Lesser (University of Massachusetts, USA)
Yow-Jian Lin (Bellcore, USA)
Luigi Logrippo (University of Ottawa, Canada)
Jan van der Meer (Ericsson, The Netherlands)
Robert Milne (BNR, UK)
Leo Motus (Tallinn Technical University, Estonia)
Jacques Muller (CNET, France)
Jan-Olof Nordenstam (ELLEMTEL, Sweden)
Yoshihiro Niitsu (NTT, Japan)
Ben Potter (University of Hertfordshire, UK)
Henrikas Pranevicius (Kaunas University of Technology,
Lithuania)
Martin Sadler (HP, UK)
Jean-Bernard Stefani (CNET, France)
Greg Utas (BNR, USA)
Jyri Vain (Institute of Cybernetics, Estonia)
Hugo Velthuijsen (PTT Research, The Netherlands)
Yasushi Wakahara (KDD R&D Laboratories, Japan)
Ron Wojcik (BellSouth, USA)
Pamela Zave (AT&T Bell Laboratories, USA)
Workshop Statement
The feature interaction problem is a major obstacle to the rapid
deployment of new telephone services. Some feature communications system.
Telecommunications software is huge, real-time, and distributed; adding new
features to a telecommunication system, like adding new functionalities to
any large software system, can be very difficult. Each new feature may
interact with many existing features, causing customer annoyance or total
system breakdown. Traditionally, interactions were detected and resolved on
a feature by feature basis by experts who are knowledgeable on all existing
features. As the number of features grows to satisfy diverse needs of
customers, managing feature interactions in a single administrative domain
is approaching incomprehensible complexity. In a future marketplace where
features deployed in the network may be developed by different operating
companies and their associated vendors, the traditional approach is no
longer feasible. How to detect, resolve, or even prevent the occurrence of
feature interactions in an open network is now an important research issue.
The feature interaction problem is not unique to telecommunications
software; similar problems are encountered in any long-lived software system
that requires frequent changes and additions to its functionality.
Techniques in many related areas appear to be applicable to the management
of feature interactions. Software methodologies for extensibility and
compatibility, for example, could be useful for providing a structured
design that can prevent many feature interactions from occurring. Features
are typically design to suit the purposes of a user or business, hence
Enterprise modeling will play a role in the identification of certain
classes of interaction, in particular the solution of an interaction in one
enterprise may not be desired by another. Formal specification,
verification, and testing techniques, being widely used in protocol
engineering and software engineering, contribute to the detection of
interactions. Several causes of the problem, such as aliasing, timing, and
the distribution of software components, are similar to issues in
distributed systems. Cooperative problem solving, a promising approach for
resolving interactions at run time, resembles distributed planning and
resolution of conflicting subgoals among multiple agents in the area of
distributed artificial intelligence. This workshop aims to provide an
opportunity for participants to share ideas and experiences in their
respective fields, and to apply their expertise to the feature interaction
problem.
Workshop Announcement
3nd International Workshop on Feature Interactions in
Telecommunications Software Systems, October 11-13, Kyoto, Japan, Sponsors:
IEEE Communications Society. In cooperation with ACM SIGCOMM and ATR, Japan.
Contact Tadashi Ohta, ATR, 2-2, Hikari-dai, Seika-cho, Soraku-gun, Kyoto,
619-02, Japan, Tel: +81 7749 5 1230, Fax: +81 7749 5 1208, e-mail:
ohta@atr-sw.atr.co.jp.
Please report problems with the web pages to the maintainer