Text File

RISKS-LIST: RISKS-FORUM Digest Thursday, 28 January 1988 Volume 6 : Issue 17

FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

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)

The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, nonrepetitious. Diversity is welcome. Contributions to RISKS@CSL.SRI.COM, Requests to RISKS-Request@CSL.SRI.COM. For Vol i issue j, FTP SRI.COM, CD STRIPE:<RISKS>, GET RISKS-i.j. Volume summaries in (i, max j) = (1,46),(2,57),(3,92),(4,97),(5,85).

----------------------------------------------------------------------

Date: Thu, 28 Jan 88 18:49:10 EST From: rsk@s.cc.purdue.edu (wombat) [Another cryptonymous contributor] Subject: Two recent stories with lessons to be learned

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]

------------------------------

Date: Thu, 28 Jan 88 16:50 CDT From: Mike Linnig <LINNIG%eg.ti.com@RELAY.CS.NET> Subject: Ada Standard Time (RE: RISKS-6.15)

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]

------------------------------

Date: Thu, 28 Jan 88 01:00:30 EST From: msb@sq.com (Mark Brader) Subject: Preventing Train Collisions by Technology

> 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

------------------------------

Date: 28 Jan 88 16:38:00 EST From: "G ANSOK" <ansok@scivax.stsci.edu> Subject: Tax form iteration

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

------------------------------

Date: 28 Jan 1988 12:39-PST From: Kenneth Sloan <sloan@tanga.cs.washington.edu> Subject: Re: A feedback loop in tax preparation algorithms

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]

------------------------------

Date: Thu, 28 Jan 88 14:30:07 PDT From: ladkin@kestrel.ARPA (Peter Ladkin) Subject: Boisjoly receives award

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

------------------------------

End of RISKS-FORUM Digest ************************