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. email@example.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 firstname.lastname@example.org +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 email@example.com %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 firstname.lastname@example.org %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 email@example.com p1@CyberStore.ca
The journal "Information Technology and People" has just published a special issue, edited by Roger Clarke <firstname.lastname@example.org> 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: email@example.com 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. (firstname.lastname@example.org) 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 "email@example.com". 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 firstname.lastname@example.org. Bashir Jiwani email@example.com 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: firstname.lastname@example.org 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: email@example.com.
Please report problems with the web pages to the maintainer