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…
TCI's cable-TV provider in Springfield, Missouri, was testing its planned inclusion of the Playboy Channel (to begin in February), when the Cartoon Network channel suddenly began airing the Playboy video along with the regularly programmed Flintstones' audio. The results were perhaps more noticeable than they might have been, because bad weather had closed the local schools and children were at home. [Source: Associated Press item in the *San Francisco Chronicle*, 17 Jan 1997, AS2. Maybe the program was something about Sharon kissing the Barney Stone?] There seems to be something magnetically RISKS-attractive about the Playboy Channel, which last summer appeared unscrambled in the Palo Alto area because of a power-failure-induced chip failure (RISKS-18.50). A PC program [a nicely overloaded acronym, since the program was presumably not politically correct!] had previously appeared in the *Jeopardy* time-slot in the Chicago area for 10 minutes, due to a screwup (RISKS-18.22). Of course, what comes around goes around; 10 years ago the Playboy Channel was intentionally disrupted by a CBN employee, with satellite-spoofed programming declaiming ``Repent Your Sins'' (RISKS-10.62).
Being the technophile, or perhaps just temporarily insane, I decided to try filing my taxes using the IRS's and State of Missouri's "Telefile" system. These systems allow the user to key in the figures from a simple return on their touch-tone phone. The systems also compute several values and speak them back to the user so that said user can record them for future reference. Observations: 1. Both systems provided my authentication information in an unsealed packet through the USPS, even though I had not requested this. Ergo, it would be quite simple for someone else to file for me. Ugh. (Hmm, if I couldn't file because someone beat me to it, would that count as "Denial of Service"?) 2. Both systems use a number as a "user id". The IRS number seemed suitably mysterious, but the Missouri number was quite familiar, being of the form "ABACADADB". Familiar, that is, because that pattern is also a perfect match for my Social Security Number. Ugh. 3. The user-interface for the IRS system was nice enough, albeit somewhat tedious. The Missouri system, on the other hand, had the annoying habit of rattling off figures at unexpected moments without providing the rattled user a means for having them repeated. Ugh. Each item seems to involve a poor solution to a problem that has superior solutions that are well-known and relatively simple. Mike Coleman http://ctr.cstp.umkc.edu/~coleman
I notice that AltaVista's inline advertisements link to a server outside Digital, "ad.doubleclick.net", and that the URL includes the user's list of keywords being searched. I'm concerned that these URL's may occasionally leak information about the user's interests and inclinations to third parties, information which the user may prefer to keep private. This is not a new problem that appeared with the inline ads, since also the Referer: field of the HTTP protocol discloses to a target server exactly what AltaVista index page led the user to it. However, this requires that the user willfully follows that link. If sensitive information being leaked via the Referer: field is a problem, the user may obtain client software that withholds Referer: data, either conditionally or unconditionally. Also, a user who has asked AltaVista for "gay" pages is probably not too concerned about accidentally disclosing this fact to the maintainer of said "gay" pages. However, the doubleclick.net ads appear to bear no relationship to the keywords being searched, and they appear not only in the URL for the hyperlink to follow, but also in the IMG SRC URL. This means that in order to avoid disclosing my keyword lists to doubleclick.net, I have to disable automatic loading of inline images when using AltaVista! Why is it that when I perform a search for, say, "gay OR nazi AND scientology", AltaVista tricks my browser to give this very search string away to an advertising company by means of an inline image (the contents of which has nothing to do with my search)? I think I can trust the AltaVista maintainers not to save my keyword lists for future analysis, but what about an advertising company? It's kind of serendipity reversed. When you open a book to look up information on a specific subject, the book scans your mind to find out what other interests and hobbies you have. Anders Andersson, Dept. of Computer Systems, Uppsala University Box 325, S-751 05 UPPSALA, Sweden +46 18 183170 andersa@DoCS.UU.SE
I was in Las Vegas between Christmans and New Year's, and decided to purchase some sunglasses from The Sunglass Hut, a large chain of sunglass retailers in the U.S. and Canada (and perhaps other countries as well). I paid for my purchases with my Visa card, the receipt was placed in a special holder, and I was asked to sign the receipt with an electronic pen. The salesman said that they can transmit the signature during the verification process as an additional check; the signature sent is compared with what Visa has on file. I was told that the signature isn't sent always, only in circumstances where a card might be being watched for unauthorized charges. All this information came from the salesman; I'd be interested to hear if anyone has any details about this system. David Finkelstein, Xcert Software Inc., davef@xcert.com http://www.xcert.com 604.640.6210 (tel) 604.681.6220 (fax)
The latest issue of PRIVACY Forum Digest, Friday, 17 January 1997,
Volume 06 : Issue 02, Moderated by Lauren Weinstein (lauren@vortex.com),
has an excellent piece of analysis on the United Parcel Service (UPS)
use of handwritten signatures:
YOUR SIGNATURE FOR SALE? — A PRIVACY Forum Special Report
by Lauren, who reports on the results of his investigations on this problem.
Information on how to find that issue on the web, or to subscribe to either
of the privacy digests is noted further on in this issue.
Story from the Boston Globe via Institute for Global Communications <labornews@igc.apc.org>: To summarize, a company's president has been arrested for manslaughter after two of his workers were killed in separate accidents, a year apart. One was pulled into a machine which lacked basic (and legally required) safety devices, the other was crushed by a front-end loader with inoperable brakes. The company had been fined hundreds of thousands of US dollars for dozens of previous safety violations. The RISK is contained in the following quote. Bowley is the president; Codinha is his lawyer: Codinha said Bowley had ``safety officers'' working in the junkyard when the accidents occurred. ``This should have been their [the safety officers'] responsibility,'' Codinha said. This guy seems to believe that you can ignore safety laws simply by hiring "safety officers" and blaming them when people get killed. Joshua Levy <joshua@intrinsa.com> [The incidents are not particularly computer related, but the last paragraph may be more widely applicable than generally realized. PGN]
The Halifax Building Society (Savings & Loan) members who were not sent voting papers for conversion (to a bank) as they were too young - born in 1890s and ages over 100 (e.g., (19)97 - (18)93 = 4). [Reported on UK radio last week] David Vinograd, Director of Computing Services, City University, Northampton Square, London EC1V 0HB, England +44-171-477-8170 D.R.Vinograd@city.ac.uk
In *CACM*, January 1997, page 15, Robert L. Glass reveals his shocking new discovery that UNIX time, a 32-bit signed integer representing the number of seconds after 1969 TAI, will overflow in mid-January 2038. (``And even sooner for smaller-word processors.'') ``This is one of those `surely I'm wrong' kinds of findings,'' Glass writes. ``Surely the designers of Unix anticipated such a problem and have provided for it.'' Harrrumph. A certain so-called operating system stores time as a 32-bit unsigned integer representing the number of seconds after 1899. This will overflow in February 2036. Apparently Glass doesn't realize that UNIX was cleverly designed to keep on ticking for *more than a million minutes* after that other system dies of tachyon exposure. This is all very well known to UNIX programmers. (Proof: A quick search with DejaNews reveals that there was a ``UNIX will outlive your pathetic OS'' thread on comp.unix.advocacy, one of the most technical UNIX newsgroups, a few weeks ago. Q.E.D.) ---Dan P.S. In all seriousness: I'm converting my data to 64-bit signed times, stored big-endian in 8 bytes, followed by 8 bytes for nanoseconds and attoseconds just in case. This won't last for more than a few hundred billion years, but neither will the Sun, and in any case I plan to throw a big programming party on 1 January 2000000001 to upgrade to 128 bits.
For as long as I can recall, the voter registration system in Wellesley,
Massachusetts has used a three-digit field for Date of Birth. When I first
saw this, I was puzzled and figured that it was probably the result of some
elderly residents celebrating their 100th birthdays.
Why three digits instead of four? Were they conserving holes in punch cards?
Tony Lauck, P.O. Box 59, Warren, VT 05674
tlauck@cerfnet.com http://www.ultranet.com/~tlauck/
[Maybe they were hanging Chad as a warlock,
although might have better been in Salem. PGN]
In many contracting situations, it is *illegal* for the contracting agency to be involved in detailed management. On EPA contracts (with which I am familiar), for example, the EPA management specifies *what* and *when* but is forbidden to even suggest *who* or *how* — that is left for the contractor management to determine. In such circumstances (sub-sub-contracts), the "who has been fired" information will have to traverse at least 4 layers of bureaucracy (and more probably 7-10, since in the EPA case it will go through at least 2 layers of Washington bureaucracy between the prime contractor and local project management, and maybe two more layers between local management and computer operations (and computer operations and the computer-operations contractor)). Risk: It will take *weeks* to deal with the situation, not hours. Carlie J. Coats, Jr., North Carolina Supercomputing Center, 3021 Cornwallis Road, Research Triangle Park, N. C. 27709-2889 1-919-248-9241 coats@ncsc.org
Living in Maryland, I got the Taco Bell item on the local news. What was more interesting was what Taco Bell did upon discovering that somehow they were losing money. Apparently, instead of checking the receipts or asking the clerk, they immediately suspected it was a hardware/software problem and had technicians treat it as such. Apparently, they caught the guy only because he was bragging to co-workers about what he had done. The risks here are enormous. They actually brought a computer professor from a nearby college on the newscast to explain the risks. [And something else... the clerk had a history and a criminal record when he was hired. Taco Bell refused comment on that]. Vince Weaver weave@glue.umd.edu
RISKS does not generally take potshots at the often miserable service provided by some of your favorite (or least favorite) Internet service providers (as well as wannabes who still don't provide decent Internet service), although we have had a few messages in RISKS on this subject, and on the pain that is caused — particularly to list administrators. This time, my patience has run out. For a very long time, I have been getting bouncemail from "System Mailman" <usfmcsqc@ibmmail.com> on every issue of RISKS, telling me that "Your note to SSTARKEY on FORD of [date/time] could not be delivered because SSTARKEY is not currently a valid userid on node FORD." The bouncemail tells me absolutely nothing else to give me a clue. On the RISKS lists I maintain (at CSL) or know about (BITNET), there is no RISKS subscriber named STARKEY and no node named FORD. I suppose I could bother all of the altruistic folks who are already providing redirection services (.mil, .uk, .mit.edu, .xerox.com, .dec.com — many thanks!), but that seems unlikely to be productive, and, besides, I should not have to do that each time something like this happens. [Oh, yes, you guessed correctly; IBMmail is not the only offender.] So, I have sent e-mail to various addresses at IBMmail — including Postmaster, Action, Help, and "System Mailman" <usfmcsqc@ibmmail.com> — TO NO AVAIL. So, a veil is now withdrawn, and I hope that by my going public, someone else will be inspired to do something useful — such as one of the many IBMmail subscribers prodding an administrator at IBMmail to modify their BARFmail facility, or someone who knows STARKEY telling him/her to let me know what alias is being used, or anything else that might help. Not only do I *not* get a response from IBMmail with some excuse such as perhaps that they are incompetent or otherwise impaired, I also do not get a bounce that "System Mailman" could not receive my message. IBMmail administration seems to be a veritable electronic black hole. IBMmail flame off. PGN Incidentally, I'm hard-pressed to keep up with the backlog these days. (I just deleted, without reading, 15 pieces of what appeared to be unsolicited advertisements in the RISKS directory, which came in over the weekend. I just hope that none of them was a well-meaning RISKS contribution!) I notice that AOL seems to have shot itself in the foot by going to flat-rate charges. The 17 Jan 1997 media reports indicate AOL is now asking its customers not to use their services so much, because of the difficulties of other people gaining access. Reportedly, many folks are threatening to sue because they cannot get the access they think they deserve — and are paying for.
When I was in grad school, I once got a letter from a professor that berated
a fellow student for not attending seminars and how he'd better get his act
together if he wanted to keep working with that prof. I could not
understand why I was "cc'd" on the letter, as it would have been
unprofessional to do so.
Looking closer at the e-mail, I figured out what had happened. The
professor had typed the subject into the "To:" field, which was something
like "Please attend all ai symposiums in the future". The only thing the
mail understood from that subject was that there was a mailing list called
"ai", which it promptly sent the letter to (even though it was busy giving
errors about the rest fo the subject).
The reply was short, "now that the whole department knows I'm lazy, can we
meet in private about this?".
Why does this happen?
- Too easy to hit the final carriage return and then say oops.
- The software (generic unix mail) failed to treat the entire
e-mail as faulty. If one of a group of instructions is faulty,
the entire group should be invalidated.
- Mail was sent to the back-end before the addresses were verified.
- Aliases set up with the same name as common words, a longer name
would have been harder to mistype.
- Apparently there was no warning that there was no subject given,
or it was ignored.
The risks?
- Software systems not keeping up with society; thus a simple system
for sending memos and ideas evolves into a full communications
paradigm that is widely used, except it's the same old software
with the same old assumptions.
- And of course, using easy technology for something that should have
been done the old-fashioned way. A tendency to sit behind the desk
and control the world from the console in front of you.
The old rule applies - never say anything on usenet or e-mail that you
wouldn't mind being posted in the office lunchroom. Chances are, it just
might end up there.
The chances of mistyping an e-mail address and getting a valid one are far
higher than Gerard A. Joseph recently suggested. On Lotus CC:mail, which use
at work, as you type a name it searches for a match in a predefined list. I
am sure many other mail systems work in a similar fashion. In my case the
list includes the entire company of a few thousand users.
I have a long time friend in California, to whom I would say just about
anything. Because of distance/time difference e-mail is our main social
means of communication. His name is Michael. My boss, about whom I might
occasionally say things that I would not want him to hear (or read), also
has the name Michael. One day about five minutes after I had sent a message
to my long time friend, my boss shouted over the partition in the office -
"Hey Niall, I think you meant this mail for someone else." It took about 2
seconds to realise what had happened and 2 seconds to start sweating. I had
typed Michael, and got the first Michael alphabetically. I needed only one
more letter to make the name unique and then the return key made the
selection. I had pressed an R instead of an M. Event though the wrong
address was at the top of the message as I typed, I never noticed it.
Luckily the mail was a harmless one, but I was far more careful in future.
The risk of course is that with such a system, especially if it can be
customised to select only people to whom you regularly send e-mail (I do not
know enough about CC:mail to know if this can be done), then the chances
become quite high that the misdirected e-mail goes to someone you know. This
can easily be more embarrassing than having it go to a random person
somewhere in cyberspace.
Niall Murphy
While misaddressing provides trivial access to information in the e-mail (the unintended recipient didn't go to any effort to obtain it), it's irrelevant. Far more relevant: "Nothing about the Internet" provides *any* privacy to *any* e-mail content, whether delivered to a valid address or not. Thus, you should *never* commit "intensely private" (or embarrassing, or fiscal, etc.) content to e-mail. A stamped, sealed paper mail document (or a telephone connection) is far more secure & reliable. There's also no guarantee that a message sent out actually arrives, nor that you'll hear about it if it doesn't. It is *often* the case that mail is looked at only by the addressee, mail sent to a valid address arrives there, and you get a bounce message for invalid addresses, but there are no "guarantees" on *any* of this. The system works well enough most of the time that naive users perceive it as "like paper mail, only faster and cheaper" - a perception which is deeply flawed. Lawrence H Smith, Instructional Technology Specialist, Office for Information Technology Williams College 413-597-3073 lsmith@williams.edu
Spaf's follow up was in 6.54, not 18.54 as noted by our overworked moderator. [Yes, Thanks. I fat-fingered it by force of habit — 18 is sort of an automatic number for me in the RISKS context these days, and it was getting late. As Yogi Berra once <supposedly> said, it gets late early. I caught the error as soon as I looked at the hardcopy. It is now fixed it in ftp.sri.com and catless.ncl.ac.uk archive copies, and was on the csl.sri.com website — where only the most recent issue is available. PGN]
Periodically I remind you of TWO useful digests related to privacy, both of
which are siphoning off some of the material that would otherwise appear in
RISKS, but which should be read by those of you vitally interested in
privacy problems. RISKS will continue to carry general discussions in which
risks to privacy are a concern.
* The PRIVACY Forum is run by Lauren Weinstein, with some support from the
ACM Committee on Computers and Public Policy. He manages it as a rather
selectively moderated digest, somewhat akin to RISKS; it spans the full
range of both technological and non-technological privacy-related issues
(with an emphasis on the former). For information regarding the PRIVACY
Forum, please send the exact line:
information privacy
as the first text in the BODY of a message to:
privacy-request@vortex.com
You will receive a response from an automated listserv system. To submit
contributions, send to "privacy@vortex.com".
Information and materials relating to the PRIVACY Forum may also be
obtained from the PRIVACY Forum Archive via ftp to "ftp.vortex.com",
gopher at "gopher.vortex.com", and World Wide Web via:
"http://www.vortex.com". Full keyword searching of the PRIVACY
Forum Archive is available through the World Wide Web access address.
* The Computer PRIVACY Digest (CPD) (formerly the Telecom Privacy digest) is
run by Leonard P. Levine. It is gatewayed to the USENET newsgroup
comp.society.privacy. It is a relatively open (i.e., less tightly moderated)
forum, and was established to provide a forum for discussion on the
effect of technology on privacy. All too often technology is way ahead of
the law and society as it presents us with new devices and applications.
Technology can enhance and detract from privacy. Submissions should go to
comp-privacy@uwm.edu and administrative requests to
comp-privacy-request@uwm.edu.
There is clearly much potential for overlap between the two digests,
although contributions tend not to appear in both places. If you are very
short of time and can scan only one, you might want to try the former. If
you are interested in ongoing discussions, try the latter. Otherwise, it
may well be appropriate for you to read both, depending on the strength of
your interests and time available.
PGN
The SEI Conference on Risk Management - Preliminary Program Managing Uncertainty in a Changing World. 7-9 April 1997 The Cavalier Hotel Virginia Beach, Virginia The SEI Conference on Risk Management provides a unique forum for exchanging ideas and experiences with experts and professionals who practice or study acquisition and risk management. It is a tremendous opportunity for you to increase your awareness and to advance your knowledge and skills by exposure to the latest methods, tools, techniques, and some of the best practices in the field of system development and acquisitions. The conference is geared toward government, industry, and academic managers, practitioners, change agents, and researchers. Managers will learn how to improve their ability to make informed decisions and to gain better control of their project's cost, schedule, and technical content. Practitioners will increase both their awareness of risks and their ability and skills to avoid or mitigate them. Development and acquisition professionals will gain insight from the experiences of leading experts and professionals, learn about the latest developments and technological issues, and learn how to manage uncertainty in a changing world. If you haven't attended an SEI Conference on Risk Management in the past, you may want to attend the 1997 conference. Here's why: * Recent Congressional action as well as DoD policy emphasizes the requirement to improve acquisition practices and management of risk. * The Fiscal Year 1996 Defense Authorization Act directs that "...the process for acquisition of information technology is a simplified, clear, and understandable process that specifically addresses the management of risk, incremental acquisitions, and the need to incorporate commercial information technology in a timely manner." * DoD Directive 5000.1 "Defense Acquisition" (March 15, 1996) provides for "...a streamlined management structure and event-driven management process that emphasizes risk management and affordability and that explicitly links milestone decisions to demonstrated accomplishments." For registration, contact registration@sei.cmu.edu. For additional information about the conference, contact SEI Customer Relations Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213 Phone, Voice Mail, and On-Demand FAX 412 / 268-5800 E-mail customer-relations@sei.cmu.edu World Wide Web http://www.sei.cmu.edu or specific questions to 412 / 268-7388 [Abridged for RISKS.]
Please report problems with the web pages to the maintainer