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…
Godfather's Pizza [phone (206) 223-1111] claims that they don't get told the
customer's phone number. This contradicts the previous article which claims
that they automatically receive your number, that is then used to display
your "pizza-history".
When I called them to ask about this, Godfather's claimed that they ask you
for your phone number and then set up an "account" for you. They specifically
stated that they do not automatically receive customer's phone numbers.
Can anybody account for this discrepancy? I can think of several
possibilities:
+ The previous article was in error.
+ They have discontinued this practice. (Perhaps due to poor reception
from the public?)
+ Godfather's didn't tell me the truth.
Anybody know?
--Bob
[Most likely the first one. PGN]
On a standard telephone line, it is still difficult to 'trace a call'. In all probability these businesses are using what are known as "Feature Group D" lines; which have aprox 6 to 8 wires, as compared to the 2 to 4 wires of a normal telephone line. Feature Group D service is designed to tell you both the number dialed, and the number that is doing the dialing. The extra lines are used for signaling the address information. [I know whereof I speak, our company is using FGD lines, and I had to design a program to interface with the phone company protocols. Not easy....] Yes, personally I would like one of these lines, with a smart phone to block unwanted calls. However, such phones already exist, that work over standard phone lines, the caller simply has to punch a few more digits (like a PIN) to let your phone know that they are allowed to talk to you. The nice thing about a FGD line, is that you can reject the call without actually having answered it, thereby allowing the caller to avoid paying the phone company for a call that you'd reject anyway. Edwin Wiles, NetExpress Comm., Inc., 1953 Gallows Rd. Suite 300 Vienna, VA 22180
[Note: This address for PAT is bogus, and does not work. Try
"sun!portal!cup.portal.com!username"@Sun.COM or
"sun!portal!cup.portal.com!username"@uunet.UU.NET]
A recent article here by Anonymous warned of the 'dire consequences' all of
us would face when Automatic Number Identification on a real time basis
became a routine feature.
I have to disagree, wholeheartedly. ANI will be one of the best, and most
useful additions to telephony that I can think of.
I consider an unsolicited phone call to be an invasion of my privacy. If you
feel you have the right to call me and refuse to identify yourself, then I
maintain I have the right to come to your front door and refuse to identify
myself.
While it is true, as Anonymous pointed out that phone solicitors and the like
frequently work from phones with special types of circuit numbers which cannot
be easily traced by someone with ANI, the fact remains that ANI will bring a
virtual halt to most of the hacking and phreaking and obscene calls which
plague many people. Yes, as Anonymous points out (an appropriate handle,
considering the gist of his message, no?) people can move around from one
payphone to another, endlessly, continuing to create their havoc in whatever
form it takes, but in reality, most people will not take portable modems and
terminals with them to the pay phone on the corner just so they can call
someone's BBS and harass them Anonymously.
Having ANI implemented will simply make it too inconvenient for most of the
low-life scum who hide behind their telephone to continue their practices. As
for legitimate reasons to not want your number displayed to the called party,
I can't think of any. Again, you have to make the analogy of going to see
someone in person. It is completely unfair and unrealistic to say that you
have the right to disturb someone at whatever they were doing and that they
in turn have no right to demand to know who you are.
In summary, I believe you have the right to use the phone as a method of
quick, almost instant communication with others. You do not have the right
to use the phone as a way to remain Anonymous. Having a non-published number
is a different matter altogether, since you are protecting yourself against
persons who might call you. The way you protect your privacy when calling
someone else is to *simply not make the call at all* if there is something
which will be said which you would not want traced back to yourself.
Anonymous is also making the assumption that the people who aquire your number
via ANI will automatically abuse the information. This is mostly false.
If and when ANI at the subscriber level becomes available here in Chicago, I
will be one of the first to subscribe. And when a call is received and the
read out shows that the person has deliberatly blocked their number from my
view, I will probably answer the phone and state that they are welcome to call
back making the information available, and pending that action, the present
call is being terminated now. (click).
Patrick Townson
Here are comments by Prof. Bev Littlewood - unfortunately not a RISKS reader - on Jon Jacky's report from COMPASS 88, which I am posting to RISKS on his behalf. To Brian Randell: >The recent report of COMPASS 88, if accurate, contained some pretty shocking >things. John Cullyer is quoted as saying "Let's throw out the 10**-9", a view >that brought audience applause. He went on to say, when questioned about >nuclear weapons safety, that "in the weapons area there should be no room >for probability. If something is unthinkable, don't let it happen. You >either certify it or you don't - one or zero." > >The last sentence worries me. He appears to be asserting that it is possible >to certify (note that word) that a system is perfect (i.e. that the unthink- >able will not happen). Does he really mean this? What about design flaws, >specification errors? It seems to me that this attitude, prevalent on the >wilder fringes of the formalist community in the UK, seeks to turn a wish >into a fact. Of course, we would all like to be able to remove the uncertainty >which is present in the process of building systems, but that uncertainty >is a fact of life. There is an intrinsic limit to the extent to which we >can formalise the problem domain, even if we are successful in current attempts >to formalise later stages of design. > >If an element of uncertainty is inevitable, we need a calculus of uncertainty. >The only one we have is probability (see, for example, de Finetti on the >'inevitability' of probability as a means of describing uncertainty). > >Nancy Leveson's remarks are just as bad, although possibly more amusing. >Nancy told the story of her encounter with an engineer who wanted to know >what number to fill in for the probability of the event labelled "software >failure" on a fault tree. Leveson tried to explain that there was no number >but he persisted. Finally she answered, "Just write 1.0." > >Leveson is LITERALLY correct - the software will ultimately fail with certainty >- but the engineer is asking a responsible question. He wants to know how >frequently the software will fail so that he can make scientifically informed >judgements to aid in the engineering decisions he must take. > >There is a lot of confusion in this area, and some of it seems to centre >around figures like 10**-9. Many people do not seem able to distinguish >between such a figure being MEANINGFUL (which it is), and being ACHIEVABLE >(which it probably isn't) and ASSURABLE (which it certainly isn't). > >Consider the 10**-9 failures per hour for the Airbus A320 fly-by-wire system. >This is often taken to be 'meaningless' because it is so small. However, if >we assume aircraft fly 5000 hours each year, that each has a 20 year life, and >that the fleet size is 1000, we arrive at a 100,000,000 hours in the air for >the fleet life. 10**-9 then translates into an approximate 1 in 10 chance >of failure in the life of the fleet. This is an 'ordinary' probability >which is meaningful to anyone and could, for example, be used as part of >a calculation to fix insurance rates (I wonder how they were actually fixed?). > >Digressing for a moment, it is interesting in the case of the A320 that the >manufacturers are on record as stating 10**-9 per hour is a REQUIREMENT for >this system (because, again as they say, failures cannot be tolerated). It >is obvious that achievement of this 'requirement' has not been demonstrated, >and one wonders how reliable the system actually is. Presumably it falls >far short of 10**-9. This presents a difficulty, because the manufacturers >were so confident of their ability to make it sufficiently reliable that they >did not provide a fully functioning mechanical back-up for use in the event >of complete system loss. If this were to occur, the pilot only has trim and >rudder to fly the aircraft. The aircraft has been landed in this configur- >ation, but I am told that it is not easy (an understatement) and airline >pilots will not be trained for such landings. > >Returning to the main theme, I think that probability statements representing >very high reliabilities are meaningful and necessary for safety-critical >systems. But, of course, I agree with Miller that they are essentially >inpossible to measure and so in practice we shall not be able to assure >ourselves that we have achieved what is necessary (even if, by some miracle, >such a reliability had in fact been achieved). > >Thus far I suppose we are not in too great disagreement with the likes of >Cullyer and Leveson. It is when we start to consider the implications of >our inability to assure very high reliabilities that we start to differ. >They seem to think that this is due in some way to defects in statistical >methodology and that we should therefore have no more truck with statistics >(and statisticians?). In fact, of course, the problem is due to the intrinsic >paucity of information about such systems, when compared with the very strong >statements we wish to make. Improvement of statistical methodology will not >be able to dent this problem. But that does not mean that Cullyer-type >'certification' can be used instead (unless he means by this a assurance that >the failure rate is ZERO - and I do not believe this is the case). Rather >it means that we are in a genuine impasse, and perhaps ought to face the >unpalatable view that we should not be building systems which require a >reliability which is not assurable. > > >Bev Littlewood, Centre for Software Reliability, The City University, London. > >email: sd396@city.ac.uk > > -- Brian Randell, Computing Laboratory, University of Newcastle upon Tyne JANET = Brian_Randell@uk.ac.newcastle ARPA = Brian_Randell@newcastle.ac.uk UUCP = ...!ukc!newcastle.ac.uk!Brian_Randell PHONE = +44 91 222 7923
> "...The very act of coming up with the best-effort quantification of these
>factors [flexibility, user-friendliness, net benefit, etc.] guides us
>towards success and knowing how well we are doing along the way" - Gilb and
>Finzi, quoted by Randell
This is certainly true. In the majority of risk analyses I've seen, the end
product was secondary to the learning process that took place as people did
it (and often implemented immediate simple fixes along the way). There is,
however, a quasi-religious debate between the quantitative types and the
qualitative types. Moreover, the issues of risk perception and risk
communication often dominate the technical issues (and, in my opinion,
properly so). Stu Katzke of NBS and Sylvan Pinsky of the National Computer
Security Center have developed an initial risk model for computer security,
which is published in Proc. 1st Risk Model Builders Symp., Martin-Marietta,
Denver, 1988. Copies of the entire proceedings will be given out, I am
told, to attendees at the upcoming Baltimore computer security conference
sponsored by NBS and NCSC. And much food for thought if found in a journal
I find that few computer security types get, Risk Analysis, published by the
Society for Risk Analysis, published by Plenum Press. It is the official
journal of the society, 8000 Westpark Drive, Suite 400, McLean VA 22102
(says the masthead). Many of the authors of papers here have been working
on computer and noncomputer risks for a long time.
Sample articles from the 9/87 issue: Impact of AI on the Risk Analysis
Profession; Informing and Educating the Public about Risk; Book Reviews;
Software Review (WHAZAN, for assessing chemical process hazards); and more.
You get the idea.
- Lance Hoffman, George Washington University (LANCE@GWUVM.BITNET)
> The problem occurs when the previous value is -175 or so and the new
> value is +175. What is the average? Adding and dividing by two doesn't
> cut it (zero is certainly NOT the answer).
> I don't remember how we solved this particular problem, but I have thought
> about it since then. Imagine trying to compute the average position of the
> second hand on a clock. You sample the position once a second for sixty
> seconds. Ok, now what is the average?
A good way to estimate an average angle, A, from a set of angle measurements
a[i] 0<=i<N, is:
sum_i_from_1_to_N sin(a[i])
a = arctangent ---------------------------
sum_i_from_1_to_N cos(a[i])
A very careful study of the properties of this estimator is in the book
"Statistics On Spheres", Geoffrey S. Watson, University of Arkansas Lecture
Notes in the Mathematical Sciences, 1983 John Wiley & Sons, Inc.
The importance of this to RISKS is that the problem of computing an average
angle comes up all the time in computing. An answer to the problem was
published at least as long ago as 1983 and probably known for a long time
before that.
Yet people try to calculate average angles in all kinds of ways, too many of
which give terribly wrong answers!
The problem is that the people who design and program software are not always
aware of the techniques that they need to make correct programs. There are
untold thousands of computational techniques, ... certainly more than we can
expect people who program numerical methods to know.
The average angle problem is not the only one that people regularly program
incorrectly. A recent discussion in comp.graphics illustrated how frequently
wrong solutions are given to the problem of calculating whether or not a point
is inside a polygon. Similarly, people regularly code incorrect procedures
which purport to determine whether or not two line segments intersect.
We need to better reference materials on numerical methods. Most
numerical methods books concentrate on finding solutions to {differential,
linear, integral, ...etc} equations and on computing values of special
functions. But we need references on less classical problems. For example,
how many more times are people going to program bad solutions to the point-in-
polygon problem? How many system failures are we going to tolerate because of
wrong solutions to the line intersection problem? We need to be able to look
up solutions to these problems.
Of course, if such a reference book were produced, how many programmers would
actually use it?
Please report problems with the web pages to the maintainer