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…
The Dutch radio station Radio 538 (http://www.radio538.nl [in Dutch] has set up a "Virtual Casino" on their web server, as a protest against legislation-in-the-making against Internet gambling. The "casino" consists of a virtual slot machine. Playing is free of charge, and you can win real prizes, presumably paid by the sponsors whose company logos appear prominently. So far so good. The amusing part is that the constructor of the Web site missed one little detail: If you lose in a turn of the game, you just click on "BACK" on your Web browser, and you undo your loss! Erling Kristiansen [The object is probably to let you win, gaining free publicity. It would be a risk if there is no limit on individual winnings. But this should certainly be a reminder to future webgame developers. PGN]
We have recently started using the Borland 5.01 C/C++ compiler[*], and came across an interesting anomaly. The minimal "short" integer, as defined in the ANSI-standard file <limits.h>, is -32768. Curiously it is defined as "(-32767-1)". At first I attributed this format to symmetry; the maximum "short" small integer was defined as 32767. However I soon noticed "long constants" and "possible loss of precision" error messages with any code which initialized a "short" integer to -32768. If this were human generated code, these values could be easily changed to "SHRT_MIN", but this code was state tables output by Gnu Flex. Turning off these error messages is risky since a fair number of bugs (in my experience) are related to precisely this type of logic flaw, especially when the software needs to run on multiple platforms. On the other hand, leaving the error messages enabled prevented me from compiling this program, due to "excessive errors or warnings." Still, this situation is better than I would face when using a personal copy of Microsoft Visual C++ 1.5. It limits SHRT_MIN to -32767. [*] A bit of research shows that the problem goes back to a least Borland 4.0. Bear Giles bear@indra.com
For the past year I've lived on Martha's Vineyard, but I spent the summer in Boston. Eager to have my mail forwarded the 80-mile jump, I filed a temporary change-of-address with the US Post Office. The forwarding order expired on September 4th. Now, it has been widely reported here and elsewhere that the US Post Office sells its national change of address register to the nation's top bulk-mailers so that they can automatically update their addresses. I've also documented how this information is used for target-marketing purposes, even though such uses are strictly forbidden by the Post Office. What I discovered this summer, though, was that either the Post Office or the users of the databank do not distinguish between temporary change of addresses and permanent change of addresses. During the summer, I had many magazines and financial statements delivered with the "corrected" address, which was a rented post office box in Boston. I had my insurance company call me up and ask me why I had moved without telling them. I had a lot of confusion. What makes the confusion all the worse is that my rented mail box was cancers a week after the mail forwarding order was canceled. All mail sent there will be returned-to-sender. And, no, the post office will not forward paper mail that is destined for a rented post office. Now I'm trying to find every company that I do business with that updated its copy of my address, and tell them that they shouldn't have updated the address, even though they thought they were doing the right think. All of this has been a huge waste of time --- not just mine, but the roughly three dozen companies that I've had to deal with. What is the most frustrating, though, is that I did everything exactly the way I was supposed to, and still I got screwed by the system. On the other hand, I don't see any way that I could have gotten my mail forwarded and not had to suffer with these problems. Simson Garfinkel PO Box 4188, Vineyard Haven, MA 02568. 508-696-7222 http://www.packet.com/garfinkel
The names of over 4,000 AIDS patients were secreted out of a Pinellas County, Florida, computer and sent to the *St. Petersburg Times* on 18 Sep 1996. William B. Calvert III, 35, one of only three people allegedly with access to the computer containing the files has been placed on administrative leave (with pay!) while investigations continue. The computer disc was accompanied by an anonymous letter claiming that Calvert had been showing and bragging about the disc and its contents at a Treasure Island gay bar, Bedrox. The *St. Pete Times*a said they did not look at the names on the list. Preliminarily, the security controls over the list are said to have included: - A double-locked room - A computer (no type specified) with a lock (unspecific) - A single-attempt password system. (no specifics.) I have been talking to the local reporters to see if we can determine any additional details like: - Is there any other connectivity to the machine, despite the locked room? - Are there audit records? - What were the real security controls - Why there was no encryption - Why officials do not consider such data bases confidential. This story is making major headlines here in the St. Pete area where I live, especially since no one knows how many other disks have been circulated and where they might be sent, or worse posted. According to some reports, Calvert was a disgruntled employee, with a history of allegations. This one incident may be the largest single case of AIDS related disclosures ever. In 1993 a Miami data base of 6,000 HIV positive people was stolen, but investigators said the list was a corollary part of a hardware theft. The RISK we face, beyond the obvious leakage of the names and the possible disruptions of people's lives already disrupted by this terrible disease, is that others may not come forward for testing and treatment for fear that their names, too, will be publicized. Winn Schwartau - Interpact, Inc. Information Warfare and InfoSec V: 813.393.6600 / F: 813.393.6361 Http://www.infowar.com Winn@infowar.com
In the message following this one, I've provided a detailed update on the
current Lexis-Nexis "P-TRAK" personal information database furor, based on
my own research. Since the situation has been changing very rapidly, this
represents the most up-to-date information I'm aware of regarding both the
service and your options for dealing with it if you so choose.
With concerns over databases and personal information running at such a high
level, this seems like the appropriate time to announce the first program
from the PRIVACY Forum's new effort: "PRIVACY Forum Radio". As longtime
readers of the forum know, one of my major concerns is getting the word out
to people that privacy really matters, and that there are actions they can
take to help protect themselves, *before* troubles arise. Whether related
to computer, telecommunications, or database privacy issues, or the less
esoteric aspects of privacy in our personal lives, to be forewarned is
critical.
PRIVACY Forum Radio will be an ongoing production of the PRIVACY Forum. It
initially will include audio interviews, discussions, and other programs
conducted with all manner of persons involved in the privacy, security, and
related areas. Participants will include persons from business, industry,
government, concerned organizations, and other individuals. Both the
well-known "movers and shakers" and the unknown folks affected by privacy
problems will be featured. All aspects of privacy in our personal,
commercial, and public lives will be topics for various guests. Initial
programs will be prerecorded, but shortly we'll begin live broadcasts
offering listeners the ability to call in by phone, or send in e-mail
queries, to directly participate in the discussions.
The primary distribution medium for these PRIVACY Forum Radio materials is
the Internet, via the Xing "Streamworks" system. Versions of the shows,
including live programs, will be available for access by listeners at
network connection rates as low as 14.4 Kbps per second. Some materials
will also be made available at higher rates for those with the appropriate
capabilities. In the very near future, we also plan to make some items
available with accompanying video ("PRIVACY Forum TV"), using the same
system.
These shows are also available, by arrangement, for conventional radio
syndication. Since my primary goal is to try get the word out about these
issues as widely as possible, PRIVACY Forum Radio is also making available a
short (e.g. 60-second) "Privacy Bites", suitable for use by regular
broadcast radio stations who want to help their listeners not only become
aware of privacy risks, but to learn what they can do about them. Inquiries
regarding any of these materials should be directed by e-mail to
privacy-radio@vortex.com, or by voice to (818) 225-2800.
The first special program from PRIVACY Forum Radio is an interview I
conducted a few days ago with Lexis-Nexis Corporate Counsel Steven Emmert,
on the subject of concerns over the "P-TRAK" database, and on the topics of
personal information and databases in general. It provides fascinating
insight into views of privacy from the "database industry" side of the
fence. To hear this program, follow the PRIVACY Forum (and PRIVACY Forum
Radio) links from
http://www.vortex.com
Links are present within the PRIVACY Forum Radio area explaining the
technical details of hearing the interview and other materials, and for
downloading the (free) Streamworks software for your system that you'll need
if you don't have it already.
This is an exciting step in the evolution of the PRIVACY Forum, one that I'm
hoping will be a major stride towards helping people worldwide deal with the
ever-encroaching loss of privacy that has become part and parcel of our
modern societies. Please direct any questions about accessing or obtaining
PRIVACY Forum Radio materials to the e-mail address or phone number
mentioned above. Thanks much!
--Lauren--
This is going to be a longish message, but I urge you to read it in its
entirely. As many of you are no doubt aware, considerable controversy has
been raging around the Internet, and now in the mainstream press, concerning
the Lexis-Nexis "P-TRAK" personal information database. Since the
transmission of P-TRAK related messages here in the PRIVACY Forum early this
month, various information, some accurate, some inaccurate, has been widely
disseminated. In some cases, I've seen versions of the original PRIVACY
Forum items in excerpted and usually unattributed form, sometimes having
been modified or addended in manners that significantly alter the original
content.
Concern over P-TRAK has mushroomed around the country, perhaps especially
due to Lexis-Nexis' high visibility. Many people are concerned about their
personal information, however innocuous some might consider it to be,
residing in publicly accessible databases. They want some measure of
control over their personal data. It is this concern that has brought this
story to national prominence.
Lexis-Nexis has put forth an official statement concerning P-TRAK
(accessible via http://www.lexis-nexis.com) which is accurate as far as it
goes--but in my opinion leaves out some *very* important points which people
should be aware of and that I'll describe in detail below.
Adding to the confusion is the fact that over the last couple of weeks the
mechanisms available for people to request removal from the P-TRAK database
have been changing, largely due to the high volume of requests that
Lexis-Nexis has been receiving. Callers to various Lexis-Nexis numbers were
at times told conflicting or apparently inaccurate information, and the
exact mechanisms for requesting removal, and what such a request really
meant in practice, has been in a state of flux.
Early deletion requests were taken by operators, then by voicemail systems,
and then later callers were told all requests had to be by mail or fax.
Most callers were asked for their Social Security numbers. Some were told
that it was essentially useless to request removal, since they could easily
pop right back on the database again later. Questions about how to verify
removal persisted.
Given all this, I decided to take it upon myself to go directly to the
source, and had a number of detailed conversations with the Lexis-Nexis
Corporate Counsel, Steven Emmert. Since Lexis-Nexis was in the process of
making decisions on some of these issues, I held off this update until now
to give Mr. Emmert time to get me the latest information, which he has done.
As described in the previous message, I'm also pleased to announce that
PRIVACY Forum Radio is presenting a detailed audio interview with Mr.
Emmert, via the PRIVACY Forum web page (access via http://www.vortex.com).
Mr. Emmert and yours truly discuss both the details of the P-TRAK
controversy and some of the more philosophical aspects of personal
information databases. If you're at all concerned about these topics, you
will probably find the interview quite interesting.
Where do the P-TRAK issues stand right now? First off, it should be noted
that Lexis-Nexis is a reseller of the data in P-TRAK, not the collector.
They don't verify or otherwise amend the original information. The
information itself is the so-called "credit header" data which FTC and other
decisions ruled were not covered under the FCRA (Fair Credit Reporting Act)
and could be openly disseminated. This includes name, address, phone
number, Social Security number, and other related data. Lexis-Nexis obtains
this info from one of the big credit data agencies (published reports have
suggested that this is Transunion). Lexis-Nexis receives this data, which
includes more than 300 million records, on a monthly basis.
While Lexis-Nexis notes that their marketing focus is to government, law
enforcement, and the legal profession, it's important to realize that
the P-TRAK database is not *restricted* in any way to ensure that
only persons in those categories are using the data. Anyone who
wants to the pay the appropriate fee can obtain search data. This is
a crucial problem in the database industry--the almost total lack of even
rudimentary "need to know" requirements before gaining access to
information that many persons consider (obviously erroneously in many
cases!) to be private.
Lexis-Nexis points out that you cannot view Social Security numbers through
P-TRAK. This is true. When the database was originally established in June
of this year, SS#'s were available for viewing, but in short order concerns
led to their display being terminated. So, you can't derive a SS# from
someone's name via P-TRAK.
HOWEVER--this does not mean that SS#'s are not in the P-TRAK database. In
fact, they are there, and if you already have an SS# you can use it to
search in P-TRAK for all of the other data associated with that number
(e.g., name, address, phone number, and so forth). Lexis-Nexis considers
the SS# to be the only reliable personal identifier, and in fact has told me
that when a person requests removal from the P-TRAK database (more on this
below) the best chance of actually getting removed exists when that person
provides their SS#. Name and address are considered less desirable for this
purpose, due to name duplications, name or address changes, etc. This is
the reason that callers asking to be removed have typically been asked for
their SS#'s.
To Lexis-Nexis' credit, it should be noted that they have competitors (some
on the Internet) who don't restrict SS# information at all, and don't offer
any opportunity to be removed from their databases either. Still, it's
important to understand that SS#s *are* in the P-TRAK database, and that you
still can search *by* SS# in that database.
Information available for direct view in P-TRAK includes name, maiden name
(if any), current address, up to two previous addresses, phone number, and
year/month of birth. Mother's maiden name is not included. The source of
phone numbers is of particular interest. Lexis-Nexis in their statements
has likened all this data to the telephone company "white pages", pointing
out that it is all based on publicly available information. But the
definition of "publicly available" is very broad--much broader than most
people realize.
Phone numbers in P-TRAK are *not* derived from telephone company (e.g.,
white pages) information. They are obtained from a variety of other
sources, notably data provided by businesses that have conducted
transactions or other business with a person, to whom that person may have
provided their phone number. As such, unlisted (non-published) phone
numbers *can* appear in P-TRAK, since an unlisted designation only affects
phone company records, not all the other places where you have provided a
number, probably with the expectation that the number would not be provided
to commercial databases! There are no legal restrictions on the
dissemination of such phone numbers, even though many persons keep their
phone numbers unlisted for quite valid and serious reasons.
OK, let's say you've decided that you consider the information in P-TRAK to
be significant to you, and you want your record deleted. First off, be
aware that it could take up to 60 days for a deletion to occur. This is due
to the 30 day cycle on the database source; the deletion request needs to be
present long enough for a complete cycle to process.
Can you verify (for free) that a deletion has taken place? No, not easily;
you need to pay for a regular P-TRAK search. Previously there was a contact
person for verification of deletions, but due to the high volume of requests
that option is apparently no longer being offered.
Will you stay off the list once a deletion request has been processed?
Maybe. It would seem to depend strongly on how much information you
provided with your original request. If you provided a SS#, you probably
have a better chance of not finding yourself with a new record in a future
cycle due to non-identical name or address information appearing for you in
a future load of incoming data. Do you want to provide your SS# with your
request for deletion? That's a personal decision of course.
What if perchance you don't currently have a record in P-TRAK? Will your
deletion request be held until a record does come in? No, it will not. If
you don't have a matching record at the time your deletion request is
processed, that request will be flushed, and if a record for you appears in
future data that record will enter the P-TRAK database. There is no
mechanism present for a "permanent" deletion request that would deal with
such situations.
As noted above, the methods for requesting deletion have changed over the
last two weeks. In fact, they've even changed in the few days since the
recording of the interview with Steven Emmert (a different fax number and
the re-establishment of voice requests on a new number). So be sure to use
the information specified below, not the number that Mr. Emmert provided
during the interview.
The following is the most up-to-date information as of this writing, and
comes directly from my communications with Lexis-Nexis. Here are your
options:
Telephone (toll free): 1-888-965-3947
Please note that this is a new number at Lexis-Nexis and
is not scheduled to be working until this Monday morning (9/23)
Eastern Time. It is currently scheduled to go to live operators,
but if volume is very high it might be switched to voicemail.
FAX (toll free): 1-800-470-4365
Again, this number is scheduled to become functional
on the morning of 9/23, Eastern Time.
Mail: P-TRAK, P.O. Box 933, Dayton, OH 45401
E-mail: p-trak@prod.lexis-nexis.com
A web form for removal requests is also available at Lexis-Nexis
via http://www.lexis-nexis.com.
The minimum information required to request removal is full name and mailing
address. As noted above, Lexis-Nexis feels that the strongest likelihood of
a successful removal will occur when Social Security number is also provided.
The web form (as of this writing) doesn't request SS#, and you of course
should use your judgment about choosing to send your SS# in e-mail. My own
recommendation would be to use the telephone or fax options.
By no means is P-TRAK the most onerous database of personal information
now available. But I believe the furor that has erupted demonstrates
the deep-seated concerns that many people have with details of their
personal lives being collected and sold merely as "information
commodities", with the subject of that data having virtually no input
on how it will be used, or abused.
It's time for a detailed examination of what information should and should
not be considered to be "public", who should have access to that data, and
under what circumstances. Some database companies themselves admit that this
is not an area that they can unilaterally address in any general way--they
have competitive concerns. Only through serious legislative efforts can we
really begin working toward reasonable changes in the commercial database
field. And we'd better get started now, unless we want the 21st century to
be a time when the word "privacy" becomes nothing more than an amusing
anachronism in the history books.
--Lauren--
P.S. Be sure to check out my audio interview with Steven Emmert of
Lexis-Nexis on PRIVACY Forum Radio if you can. Just follow
the PRIVACY Forum links from http://www.vortex.com to
PRIVACY Forum Radio.
["Michael J. Chinni" <mchinni@PICA.ARMY.MIL> noted a change in the web
address reported by Pease in RISKS-18.47. He suggests searching down
from main address, noted above. PGN]
Rory's description of his close encounter with a dodgy ATM machine reminded me of a more than annoying incident I suffered recently. Needing to withdraw a large amount of cash in a hurry, I went to my local ATM machine, and requested $700.00 in cash. The machine normally gives out $20.00 or $50.00 notes, and obviously I was expecting the latter. Unfortunately, it gave me the former. Of course, this consists of 35 bills. It spent some time shuffling bills behind the scenes (which was where I started to get the idea that something was not well). Some clunking noises later, and it gave me some bills. Eleven of them to be exact. It then gave me a receipt. Needless to say, it deducted the full $700.00, even as I could hear it withdrawing the bills back into the bowels of the machine. The cause: it simply couldn't fit that many bills through the slot. So it sent through what it could, and took back the rest. The RISK: Somewhere in the bank there are teams of programmers, writing and maintaining the software for the ATMs. They handle many types of exceptions, and error conditions. Elsewhere, there are many engineers, carefully poring over the design of the ATM, its cash dispenser, checking that there are no foulups, or possible causes of mechanical failure. Then there is the person who takes the hardware, loads the software, and sends the ATM out. The programmers never see an ATM (except when they are withdrawing their money), and are likely never told its physical characteristics. Similarly, the engineer is simply told that some software is loaded on the computer that he (or she) has bolted into the case. I'm sure it has just not occurred to the managers that mere physical constraints can affect the operation of ATM software ... The even greater RISK? How do I get a message to the programmers responsible for the problem? There is no mechanism in the bank for you to write a complaint to the support staff. And what do you think are the chances of them having the time to think about the problem and discover the cause for themselves? James PS. It took over a week for them to finally get my money back into the account. Several checks almost bounced as a result. James Robertson * jamesr@desklaw.com.au Coding * Design * Layout * Newton * Windows "Beyond the idea"
Several years ago, several authors published details of a flaw in the design of TCP allowing denial of services via sending a SYN packet and not following up. In the last week or so, several magazines have published code for a SYN flood attack, and now many ISPs are going down because of their lack of defense and inability to trace the attacks to the sources. I thought I would note that the CERT has now decided to advise all on the Internet to use the techniques against IP spoofing published some months ago in Network Security Magazine (Elsevier) in an article on IP spoofing (part of the "Internet Holes" series. This article was also published in the BoS mailing list (although they should not have done so because of copyright violation). The basic defense is for the Internet community as a whole to refuse to route packets from known forged addresses. For example, we shouldn't be routing packets from 0.0.0.0 and 255.255.255.255 or the IP addresses associated with internal-use-only IP ranges or - most importantly - packets from IP addresses not in the range appropriate to an incoming link. (If you service IP range 204.7.229.*, don't let inbound packets from that port with from IP addresses not in that range). FC
Also see AWST Sep 9, p82. The RTCA is a non-profit organisation that evolves avionics and other electrical standards for aviation. It reports on RTCA Special Committee 177, formed in 1992 to consider just this potential problem.
Please report problems with the web pages to the maintainer