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…
[From Paul A. Strassmann, National Defense University
and William J. Marlow, SAIC, via Dorothy Denning]
We find that a report by a Mr. Viktor Mayer-Schoenberger [e.g., RISKS-17.87] citing our alleged statements at a Harvard University Conference has been widely quoted on Internet, out of context.
Specifically, he attributed to us statements that a number of anonymous remailers in the US are run by government agencies and that the most popular remailers in France and Germany are also run by government agencies. What Mr. Viktor Mayer-Schoenberger reported as facts are his interpretations. Our comments were of a general academic nature. We were not attributing remailer activities to any specific governments, but rather commenting on the general situation where much of the research on the use of networks has been paid for by governments and therefore one can assume that they would know how to make use of such facilities. We have no specific knowledge of any particular agency of any government offering remailers services. Whether or how they use remailers is not known to us. Online users just need to be "aware of the risks."
Paul A. Strassmann, National Defense UniversityA University of California computer system administers U.C.'s $20 billion retirement program. A recent report by Infortal Associates concludes that the security of the system was very weak, and that the audit trails were flimsy and easily disabled. Furthermore, no one had responsibility for reviewing the audit trails. The system can be accessed from the Internet, and Infortal was able to do so using a widely known password. However, a University spokesman observed that no adverse penetrations had actually taken place, no money has been lost, and the security flaws have been fixed. [Source: *San Francisco Chronicle*, 14 Mar 1996]
[Well, in the absence of good audit trails, you may not know you have been penetrated. Also, even if a few security flaws may have been fixed, such a system is never totally invulnerable to attack (whether on the Internet or not). But you all know that by now? PGN]
[This is from mini-AIR (e-mail synopsis of the Annals of Improbable Results).]
1996-03-05 PGP-Y Ill Advised
Reader Andrew Rock has been investigating our foolproof data security protocol, PGP-Y (Pretty Good Parapsychology). He intuited this missive to us:
"You were ill-advised to release the details of your PGP-Y — "Pretty Good
Parapsychology" protocol on an international mailing list such as mini_AIR.
US law prohibits the export of such highly secure transmission technology,
defining it as munitions. Your proposal must await government-approved key
espcrow [sic] systems rumoured to be under consideration by the NSA. The
approved systems will prohibit the possession or transmission of ideas
beyond the imagination of government officers. Please do not carelessly put
the publication of AIR at risk while I have nearly two years left on my
subscription."
Investigator Trevor Green and a large team at the University of Saskatchewan have also been laboring in the field. Green reports:
"After an initial trial period of PGP-Y within our department, we have had
some disappointing initial results. While the transmission rate is nothing
short of paraphenomenal, the security mechanism is, alas, not wholly
foolproof — everything worked fine, until my friend Steve started imagining
that he was intercepting the telepathically-transmitted data. We are sure
that this technical loophole may be overcome but wish to alert your
paranormal engineers to the oversight. Meanwhile, I am pleased to report
that the credit-card fraud charges against Steve will be settled out of
court."
[And it is not even April yet! PGN]
Recent discussion of appropriate renaming of v.r. systems prompts one to note that being an attractive sink for funding often involves production of a two-word nonsequitur comprising an adjective and a noun. The juxtaposition of the incompatible modifier with the noun yields a conflicted notion that makes possible a degree of cognitive friction generating new ideas, permits wild and unsubstantiated claims to flourish, and empowers marketing hyperbole that has no equal.
Examples include not only "virtual reality" but also "artificial intelligence" and "expert systems". In each, the combination is unlikely to the same degree as a zen koan. Although the metaphor may be a little overextended, proponents seem to regard contemplation of the terms as one means of achieving the experience of satori.
While the clever use of language is required to initiate funding flows, it is generally unable to sustain it for more than about a decade. Skilled operators are able to generate a new term-pair every decade or so to ensure continued flow of funds for research and development.
Richard I. Cook, MD Cognitive Technologies LaboratoryI agree that denormalise database design may be better, but not for the same reasons Phil suggests. What Phil has described is an example of poor coding and understanding of relational design rather than a case for denormalisation. The use of a unique key that refers to the product number (and name) would overcome this problem.
The RISK here is confusing the theory with the (bad) practice.
Rob rbagnall@be.oracle.comOur school has some servers that run Solaris and some that run SunOS. I discovered that when I posted to USENET on the Solaris machines, my name showed up as "-Hwa Huang" instead of "Wei-Hwa Huang". After we traced down the problem recently, it turned out that inews on the Solaris machines assumed that the names in the passwd file looked like
foo-John Smith(bar)
where foo and bar are used to mean stuff that doesn't concern the user's name. On the other hand, inews on SunOS used
John Smith,foo,bar
instead. Obviously, the Solaris machines saw
foo-Wei-Hwa Huang(bar)
and got confused.
The RISKS are obvious. Whomever compiled inews on the Solaris machines made the assumption that the hyphen was a safe delimiter that would never appear in a user's name. Of course, with the SunOS method, names with commas in them would confuse the system instead. If there are people out there with strange names, or perhaps use 2-byte characters, these "standard" systems wouldn't fare too well. On the other hand, while using something strange such as $ for a delimiter would work in more cases, it certainly makes for difficult reading of the source. What's a designer to do?
Kudos to my excellent sysadmins for pinpointing and fixing the problem so rapidly, by the way.
Wei-Hwa Huang, whuang@cco.caltech.edu, http://www.ugcs.caltech.edu/~whuang/I recently changed ISPs and suddenly mail from one individual I correspond with had a change in her address, so that my replies to her messages were coming back with the User Unknown response. Since I also obtain her postings at a second ISP, I checked and found that her address was still the original address at the second ISP.
[Incidentally, my mailer automatically uses the reply-to address if supplied, or falls back to using the from address. In this case, the "From:" address was being used, and was being changed at *my* ISP when it was received, whether in a Usenet message or a personal e-mail message.]
Having discovered this, I called the new ISP's technical support group and explained my discovery. While laughing, the support person tested my contention internally on their system and discovered that, lo and behold, I was correct in my theory. For some reason, the @ns.net was being translated to @norm.net by their system. They name each of their machines, and one had been named "norm". For some reason, they had, somewhere in their system, a conversion where ns=norm. While this may have been required for some purpose, it was being applied for a different purpose, totally unintended. [Whether they could have discovered this via testing is unknown to me.]
It took two days, but they HAVE fixed the problem - without letting me know when they had it fixed, and without letting me know exactly where the problem occurred.
The risk is obvious, if you only have one ISP... When mail is returned as undeliverable, it may be that the address is incorrect because of something your ISP has done and is totally unaware of. Believe me, this CAN result in annoyance and frustration, both on your part and on the part of the person you correspond with, half way around the world. Fortunately we were not involved in any correspondence where time was of the essence, or the problem would have been far worse.
R.S. (Bob) Heuman Willowdale, ON. Canada <heuman@mtnlake.com> <rsh@inforamp.net> <rn.1886@rose.com> <aa969@torfree.net>The message from Bob Heuman reminds your moderator that I have been itching to grumble again about the ongoing RISKS bouncemail problems — along the lines of Phil Agre's posting on the risks of e-mail (Bouncemail Top 10) in RISKS-16.76. In the past week alone, I have had at least 20 new subscribers using the majordomo listserv whose "From:" address or other explicitly provided address was not a valid address, so that they could not receive mail at their own given addresses! This is truly ridiculous, although it may be attributed to the rapid growth of the Internet community among folks not used to the subtleties of life on the net. I sometimes get as many as 100 bounces a day; even if I have just pruned away all the previous hard bounces, I still get a bunch of *new* ones on the next issue. The good news is that the Internet is dynamic. The bad news is that the Internet is dynamic.
If you do not get RISKS for a long while, you should check the archives to see whether you have been dropped from the list because of prolonged bounces (or whether I have just been otherwise occupied).
The first risk is that of including `live' code fragments in a publication, especially one which is subject to several media.
The second risk is that of using an automated process to construct and publish information on the Web — especially if the input to that process is e-mail.
Just to expand on the above: ``Live code'' can stealthly come into documents. Any web site that offers to take online "feedback" or "comments" has an open invitation to such trojan codes — for example, an attacker can simply type in applet code into an online form.
Moreover, it is perhaps more convenient to collect and sort these feedback automatically and then view them through a web browser (instead of an editor such as Emacs or MS Wordpad). Thus, the risk is often there if one uses a java-capable browser to do something useful.
On the other hand, there is the tendency that a newly discovered attack will quickly lead to a patch that disables a useful feature in the browser or interpreter. Soon the features list is shortened to almost zero and ones starts to ask why the language is needed at all.
Li Gong, SRI International, http://www.csl.sri.com/~gong/A mate of mine, whom I will call Skip and his computer ralph.nomame.edu, decided to look himself up on the "Who Where?" database. He found his name, selected it, and was rewarded with the response:
* Name: ??? Console E-mail: skip@ralph.nomame.edu Organization: cornell university, ithaca Last Updated: --This is all fine and good, except that a) he never registered himself with the server and b) ralph.noname.edu is not a mail server and all mail there will bounce. So the question is, how did this E-mail address show up? So, I looked at my entry.
* Name: Brian Kelley E-mail: brian@piglet.cam.cornell.edu Organization: cornell university, ithaca Last Updated: --Now, piglet.cam.cornell.edu is also not my e-mail address.
We did a little digging and discovered that the standard unix command "finger @ralph.noname.edu" responded with
[ralph.noname.edu]and "finger @piglet.cam.cornell.edu" responds with
Login Name TTY Idle When Where skip ??? console 10:30 Tue 22:22
[piglet.cam.cornell.edu]So, our assumption is, which is also a risk in itself, that some program is fingering computers and "grep"ing the return info which, in the case of skip is incorrect.
User Real Name What Idle TTY Host Console Location brian Brian Kelley 4 piglet 357 Theory Center
However, the real question is, how did these machines get registered with the page? The answer is, Netscape. My best guess is that by selecting the "Who Where?" page, or some other page, automatically registers your machine
with the database which then fingers your machine for information. To test this theory, just look up the entries for "root." (Which indicates many more risks, i.e. root running Netscape, et. al.)
This would be fine if there was a notice that entering this page automatically registers you (and everyone currently logged onto your computers) with the database. However, the page highlights and underlines the phrase "Add Your Listing" which indicates that it has not been added already.
The risks, in the case of skip, are obvious. However, it was just another reminder to myself about the propagation of personal information (that may indeed be inaccurate.)
Brian Kelley 357 Rhodes Hall Cornell University Ithaca, N.Y. a14850 brian@ee.cornell.edu (607) 255-0963A brief note of appreciation to Bear Giles (RISKS-17.89):
I had been focussed on Y2K as a technical problem. At the risk of showing my age, here's how I lost my innocence.
Our timesharing mainframe's OS failed on December 1, 1979. Operations was able to restart it; it would run a short while and fail again in the supervisor. I won't mention the OS since we had extensively modified it and it wouldn't be fair to sully the vendor with our self produced problem.
The memory dump showed a data exception in our online accounting routine, it was doing a packed decimal operation on a field that contained the hexadecimal sequence '000197AF'. You grey beards (Yes, I have seen *you*, Mr. Moderator.) out there will recognize the problem. Even though the field had the century indicator, our assembly language programmer had chosen to increment only the year portion. He extracted the 4 bits, incremented the year, and stored the year back. This subroutine worked for years 1970 through 1979 but 197A is not the next year, at least not until we replace decades with hexadecades.
(sidebar ALC lesson, of '000197AF', the 'F' means a positive number. This representation is packed decimal; the programmer used binary arithmetic operators on a packed decimal number.)
This code calculated the billing period, lived in our operating system, and was executed at the end of each batch job or timesharing logoff.
A lot of the popular writing on the Y2K problem (I'd been calling it, the century end problem) has focussed on application data, cobol, database, accounting, and reporting issues. These are certainly the larger part of the problem and the 'suit' consulting companies will have their hands full.
Because I have seen and debugged an operating system catastrophic failure caused by a calendar issue, I believe this problem has a darker, more ominous side. There are subtle Y2K problems that are not revealed by scanning the external data. Some of these problems are implemented in assembly language. Some of the assembly language source code has been lost over the decades. There are very few of us left who can read and write machine language.
Contrary to reports in the popular press, the world does not run on PCs and client/server systems. It runs on big water cooled mainframes and a lot of old, old software maintained by aging staffs. Each year, a substantial percentage of the machine language programmers leave this business.
Who is going to fix the hard problems?
Cory Hamasaki> A leap second is a 61st second in a minute (always just before UT
> midnight), so ... some date specifications such as "23:59:60 Dec 31
> 1972" are actually perfectly valid.
Yep — but that particular date and time combination is valid only if the time zone is assumed to be UTC. In the Newfoundland time zone, for example, 23:59:60 would never be a valid time, but on days with a leap second, one of 20:29:60 or 21:29:60 is valid. 22:29:60 could have been valid too if there had been a leap second in the summer of 1988 when Newfoundland tried double daylight saving time, but there wasn't one then. In other words, true validation of a time of day requires knowledge of the time zone.
Of course, this is true anyway even without regard to leap seconds, since you also need to know about daylight saving time transitions.
Which reminds me of something instructive — a few weeks ago, Dafydd Price Jones (dafyddpj@dafyddpj.demon.co.uk) asked in rec.puzzles: "What was the longest month of 1995 in New York?" The right answer is October, when daylight saving time ends. But there must have been half a dozen readers who forgot that, remembered the latest leap second, and leaped to post the wrong answer "December".
The moral? Merely what we've been saying already. Date and time computations are surprisingly tricky.
(There was also a wonderful "cook" of the puzzle, with its own Risks
implications. Chris Best (cab@col.hp.com) said that the longest month was the only 9-letter one, September! Peter will remember the time that comp.risks itself was bitten by a longer-than-average spelled-out date.)
Joe continues:
| This has worked reasonably well so far, but I've read predictions
| that within only a couple of decades we'll first start needing leap
| seconds every year, then twice a year, then even more and more often...
| What shall we do then? Redefine the second? Keep two separate time
| standards, one with a fixed second and another with a stretchy second
| that changes to accommodate the Earth?
Already done — those would be TAI and UT1 respectively. Neither one is what's used for civil time, though. Civil time is based on UTC, which is called *Coordinated* Universal Time precisely because it is derived from *both* TAI and UT1. And this is exactly why we have leap seconds. UTC uses the fixed-size seconds of TAI, but keeps its time within 900 ms of the current time according to UT1, by using a leap second (or, as Joe noted, in theory an anti-leap second) when needed.
But maybe Joe meant that people would actually need to use both kinds of seconds in everyday life. It'll be a *long* time before things come to that, and I think we can safely defer the problem for now.
Incidentally, while TAI is an acronym in French, UTC is not; it's in English, but the C is last because it's effectively a subscript. Both UT1 and UTC are considered variations of UT, Universal Time; there are others too.
Mark Brader, msb@sq.com, SoftQuad Inc., Toronto| [The] Explanatory Supplement to the Astronomical Almanac ... raises the
| interesting point (in section 12.13) that the U.S. legal code specifies
| no official national calendar. Our use of the Gregorian calendar stems
| from a 1751 Act of Parliament of the U.K.
In 1992, Clive Feather obtained a copy of this Act for me, and I typed it in and posted it to the net. That posting, with a few additional remarks, can be found at <http://www.urbanlegends.com/legal/calendar_act.html> or obtained by e-mail from me.
The for those who don't want to browse through 500-odd lines to find it, the key part of the Act that defines the leap year pattern decrees:
# That the several Years of our Lord, 1800, 1900, 2100, 2200, 2300, or
# any other hundredth Years of our Lord, which shall happen in Time to
# come, except only every fourth hundredth [sic] Year of our Lord,
# whereof the Year of our Lord 2000 shall be the first, shall not be
# esteemed or taken to be Bissextile or Leap Years, but shall be taken
# to be common Years, consisting of 365 Days, and no more;
# and that the Years of our Lord 2000, 2400, 2800, and every other
# fourth hundred Year of our Lord, from the said Year of our Lord 2000
# inclusive, and also all other Years of our Lord, which by the present
# Supputation are esteemed to be Bissextile or Leap Years, shall for the
# future, and in all Times to come, be esteemed and taken to be
# Bissextile or Leap Years, consisting of 366 Days, in the same Sort and
# Manner as is now used with respect to every fourth Year of our Lord.
except that in the actual Act, all of the numbers are written out in words.
Pope Gregory's original proclamation would also be of interest, but I presume it was in Latin; anyway, I've never seen a copy of it.
Mark Brader msb@sq.com SoftQuad Inc., TorontoBroadening the Perspective for the Next Century 1996 SEPG Conference, Preliminary Program
May 20-23, 1996, Atlantic City, New Jersey Trump's World Fair Casino Hotel & The Atlantic City Convention Center
Software practitioners meet once a year to share experiences, discuss current issues, and explore models and trends for the future. The focus of the 8th SEPG Conference is exploration of the view of process improvement for the year 2000 and beyond. The annual event is sponsored this year by the North Jersey Software Process Improvement Network (SPIN) and the Software Engineering Institute. The 8th Software Engineering Process Group (SEPG) Conference includes keynote presentations, speakers, panels,
tutorials, exhibits, poster sessions, and informal birds-of-a-feather meetings.
Deadline for Registration Discount: 29 April 1996
The SEI is a federally funded research and development center sponsored by the U.S. Department of Defense and operated by Carnegie Mellon University. CMM, Capability Maturity Model, and IDEAL are service marks of Carnegie Mellon University.
Conference Schedule [meals, breaks, etc., omitted]
Monday, May 20, 1996 Tutorials Tuesday, May 21, 1996 General Sessions, Keynote, Presentations, Reception Wednesday, May 22, 1996 General Sessions, Keynote, Presentations Thursday, May 23, 1996 Tutorials
Keynote Presentations: * Fagan Defect-Free Process, Michael Fagan, Michael Fagan Associates
* The Silver Bullet Experiment - Challenges for the Future, Robert Martin,
Bell Laboratories
* The Software Challenge--The Next Imperative, John Major, Motorola
* Inside the Information Systems Blackhole 1996!, Howard A. Rubin, CUNY
Topics to be addressed include * IT Performance--how are the frontiers of performance changing?
* An industry-by-industry view of spending patterns, infrastructure, and
priorities.
* 1995 performance--how does the U.S. rate against the world?
* The IT performance "envelope"--how should you assess your position?
* Offshore performance--India, low-wage countries, myths vs. realities, and
outsourcing.
* How to assess and set your performance priorities...forward-looking
measurement.
For information, Phone 412 / 268-7388 or
Customer Relations-- 412 / 268-5800
FAX 412/268-7401
E-mail registration@sei.cmu.edu or
customer-relations@sei.cmu.edu
World Wide Web http://www.sei.cmu.edu
Please report problems with the web pages to the maintainer