The RISKS Digest
Volume 6 Issue 17

Thursday, 28th January 1988

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

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…

Contents

Two recent stories with lessons to be learned
Rich Kulawiec
Ada Standard Time
Mike Linnig
Preventing Train Collisions by Technology
Mark Brader
Tax form iteration
G. Ansok
Kenneth Sloan
Boisjoly receives award
Peter Ladkin
Info on RISKS (comp.risks)

Two recent stories with lessons to be learned

wombat <rsk@s.cc.purdue.edu>
Thu, 28 Jan 88 18:49:10 EST
First story: a friend of mine works in a chain drugstore in Indianapolis.
They have an alarm system which is connected to a computer at a security
company's central offices.  Periodically, the store manager conducts a
test by calling the security company, giving a password of some sort that
authenticates him as someone empowered to do this test, and then deliberately
setting off the alarms in the store one by one.  He then calls them back,
and finds out if all this worked.  On their end, they instruct their computer
that this particular system should be put in "test" mode for the duration
of the test, and then they put it back in "armed" mode.

On January 7th, the store conducted a test.  On January 23, the store was
burglarized and the police weren't called.  You guessed it: the system was
still in test mode, and thus the alarms were ignored even though the sensors
worked correctly.  It is unclear whether the store manager didn't call back
or whether the computer operator failed to reset the status on their alarms;
but what appalled me was that their software didn't flag this system as
having been in test mode for over two weeks.

                                [The burglar could plead No Con Test?  PGN]


Second story: our local cable company recently revamped their system, forcing
everyone to get new converters.  These new boxes have some additional features,
one of which is that they can be programmed to turn on at a preset time on a
preset channel.  (This makes videotaping a bit easier; it's now possible to
tape two programs on different encrypted channels in one session by instructing
the converter to switch channels.  Previously, one would have to set the
converter to one channel, program the VCR to tape that program, and then hope
somebody at home would remember to switch channels on the converter in between
programs.)

Well, the central cable clock is broken at the moment, and so none of this is
working very well.  It turns out that the converters don't have a free-running
clock which is periodically sync'd to the central office master (which was how
I figured they had implemented this function), but that the converter is told
to increment the clock every now and then (the person on the phone couldn't
tell me the interval) and thus it becomes helpless if the central clock fails.

Given the low cost of adding a local time-keeping function of the converter,
I'm surprised that this wasn't done.  The centralization of this function
may mean that it's more accurate--when it works; but it also means that
when it's broken, it's *really* broken.

                         [Moral: A glitch in time slaves lines.  PGN]


Ada Standard Time (RE: RISKS-6.15)

Mike Linnig <LINNIG%eg.ti.com@RELAY.CS.NET>
Thu, 28 Jan 88 16:50 CDT
Doug Jones is quite correct.  The current version of the Ada Standard
MIL-STD-1815A (1983) still has 2099 as the maximum year.  I assume they picked
such a limited range for error-checking reasons (i.e., having 88 as a year
would be an error if you meant 1988).  For the reasons Doug Jones stated I
would prefer to see the upper end of the range as 3099 or some such —  far
enough into the future that no device programmed in Ada need ever worry about
surviving that long.
                                Mike Linnig, Texas Instruments

      [Don't you think Fortran '77 will someday mean 2077?  or 3077?  
      It has already been around almost forever.  Why not forever?  PGN]


Preventing Train Collisions by Technology

Mark Brader <msb@sq.com>
Thu, 28 Jan 88 01:00:30 EST
> The FCC's private radio bureau reported [of the Chase, MD, accident]
> that "This terrible collision could have been avoided had the
> locomotives been under the control of a central computer."

It could also have been avoided if the turnout in question had had
a "derail".  This device, as the name suggests, would derail one train --
in this case, the locomotives — rather than letting it onto the through
line where it could (and did) collide with, in this case, the passenger
train.  Derails are commonly seen on this continent, but generally only
at sidings where both switch and derail are manually controlled.

On the other hand, there was a famous accident in Britain in 1940
where a similar device called "trap points", operated in conjunction
with the turnout, did prevent the otherwise certain collision of
two passenger trains by allowing one to derail.

(The flip side of this method, of course, is that the derail, even if
properly used, could cause a derailment when there was no train nearby
on the main line and no chance of a collision.)

Mark Brader


Tax form iteration

"G ANSOK" <ansok@scivax.stsci.edu>
28 Jan 88 16:38:00 EST
Actually, this has been thought of before.  The preferred procedure,
according to the Fed's 1040 instructions, is to deduct the state taxes
withheld during 1987 on your 1987 federal return.  If you get a refund, that
must be declared as income on your 1988 federal return :-).  However, if you
need to send more money to the state, this isn't deducted until your 1988
return, either :-(.  Both this method and the figure-the- actual-state-tax
method are allowed.

I believe that some states have been pegging state taxes to the federal return
for years.  If so, no doubt you will hear from RISKS readers in those states.
This is not a new problem — just new in California.
                                                        Gary Ansok


Re: A feedback loop in tax preparation algorithms

Kenneth Sloan <sloan@tanga.cs.washington.edu>
28 Jan 1988 12:39-PST
Well...without looking at the specifics, and relying only on general
principles of similar "loops", here's what I've always understood to be the
case.  Source: IRS instructions which dealt explicitly with the "problem".

You prepare the Federal return first.  On the Federal form, you show
the state taxes actually paid during the previous year.  The fact that
you may have to pay MORE state tax, or get a state REFUND, is
irrelevant.  The extra payment, or the refund, will affect NEXT year's
Federal tax.  Note that this principle holds even if there is no "loop"
(that is, you live in a state which does not peg it's taxes to Federal
tax policy).  In general, the Federal form is only interested in money
which actually flowed into and out of your pockets LAST YEAR.

The state return wants line items transferred from the Federal form
because they want to follow the same rules, but don't want to deal with
yet another copy of the forms.

So, "PGN's solution" is correct as far as it goes, but for other reasons.
Note that NEXT year, the Feds will want to know about the state tax refund
that you are getting THIS year (it's INCOME this year) or the extra tax you
actually paid THIS year (it's a state tax, paid NOW).

Of course, all of this is wrong if indeed there are explicit instructions
telling you to make "many successive iterations through the state and
federal computations if you want to be precise".  If you can cite them,
don't both to tell me about them, fire your state legislators.

But, I don't think that's so.  My guess is that the flaw is the idea that
"you cannot complete your federal return until you have completed your state
return".  I think that's simply wrong.

It's true that you can get a larger Federal deduction by overpaying you
state tax.  BUT, you get a larger income next year.  Somehow, this doesn't
look like a money making proposition.  It seems MUCH more likely that you
can make money by UNDERpaying (to the amount allowed) this year, taking a
hit on the deduction this year, getting the smaller income next year (you
get to deduct the final state tax payment), and having the money to use for
a year.
                                  -Ken Sloan

     [Of course there are no explicit instructions to go around the loop
     until you converge.  I think the author was musing on the difficulty 
     of calculating the exact tax due without over- or underpaying either 
     state or federal.  But the article seems to imply something more
     insidious than actually exists in practice.  PGN]


Boisjoly receives award

Peter Ladkin <ladkin@kestrel.ARPA>
Thu, 28 Jan 88 14:30:07 PDT
The New York Times for Thursday, Jan 28 has an article on page 9 entitled
`Whistle Blower To Get Award', mentioning that Roger Boisjoly, the former
Morton Thiokol engineer about whom there has been some recent risks discussion,
is to be awarded the Scientific Freedom and Responsibility Award by the
American Association for the Advancement of Science. The article also notes
that Boisjoly hopes his suit against Morton Thiokol results in `a drastic
improvement in ethical conduct'.
                                               peter ladkin

Please report problems with the web pages to the maintainer

x
Top