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 example of answering machines that can be easily "talked-off" by speech is but one case of a broader category — which I'll call "technology deterioration". It's not that the proper techniques for avoiding DTMF (Touch-Tone) talk-off haven't been designed (when's the last time you talked-off a dialtone on a central-office switch?), but rather that many inexpensive devices don't bother implementing all of the specs for proper performance. Many answering machines also provide a wide selection of other implementation deficiencies as well, including the frequent use of two-digit security codes, and often a total lack of incorrect entry lockouts, making "exhaustive" search trivial.
The same sorts of problems can be found in a wide spectrum of devices, from computer keyboards to automobiles. In many (perhaps most) cases, the root cause is simply the desire to cut production costs. But there is evidence that in a significant number of cases the designers simply didn't know better. To the extent that the NIH ("Not Invented Here") philosophy prevails around the world, this is an easily observed phenomenon.
What's of particular concern is how the results of these attitudes can impact devices and systems with significant RISKs associated with their use.
--Lauren-- http://www.vortex.comA possible RISK of placing your own personal information on the WWW?
Today, I received a message from a concerned person (anonymized through the anonymous forwarding service in Finland).
> Are you member of Waterloo's three-person team
> took first place at the East-Central Regionals [1995]
> in ACM Programming Contest?
[...]
> If so, I think you may be feel a little bit upset after looking at this:
> http://www.undergrad.math.uwaterloo.ca/~ecstsui/resume.html
[...]
> I noticed his resume was like this since early February;
> the first time it was copied verbatim; now, about 2 months later, it's
> not, but it's even more misleading than the first one, since he mixed
> his own information with your information.
If you dare to compare, the original is at: http://www.csclub.uwaterloo.ca/~kryee/resume.html
I had posted my resume on the WWW hoping to be able to provide convenient information for interested people and potential employers; while I imagined it feasible for someone else to imitate the style I used, I had no idea that someone would be so brazen as to copy the entire thing.
It shocked me that this had actually been happening on my very own site for over a month! Occasionally I use the search engines to check for my name to find other people's references to me, but since there is no mention of my name in ecstsui's document, it never showed up.
Beware — someone may steal your life!
(I did not previously have explicit copyright notices on my pages, but I added them today. While they may make little legal difference because copyright is automatic, they may help to deter this sort of incident.)
Ping (Ka-Ping Yee): 3A Computer Engineering, University of Waterloo, Canada CWSF 89 90 92; LIYSF 90 91; Shad Valley 92; DOE 93; IMO 91 93; ACMICPC 94 96Greg Campbell wrote a cover story for the Boulder (Colorado) Weekly on the city's sale of its sewage sludge as fertilizer (http://www.earthnet.net/~altnews/012596/cover.html). The article quotes EPA toxicologist Suzanne Wuerthele:
"We don't understand fully at what point individual people will be at risk," she says. "Theoretically, for any carcinogen, there are no safe limits. ... One or two asbestos fibers could do it (cause cancer)." [ellipsis is Campbell's]
The word "carcinogen" in the above quote is a link to our Web site, The Carcinogenic Potency Database Project (http://potency.berkeley.edu/cpdb.html); we are unaffiliated with Suzanne Wuerthele. The information at our site, if anything, would cause one to doubt the veracity of her statement.
Misquoting or misattribution is not unusual in newspapers. The widespread availability of newspapers on the Web potentially facilitates the ability to see where one is being quoted and how it's being done (a risk for the reporter).
Those who are not versed in the technology or who are not diligently Web browsing can be misquoted without their knowledge. This is true for hard-copy too — people don't always know where they're being (mis)quoted unless it's in a periodical that they happen to read.
The fact that our Web site was being pointed to by the Boulder Weekly was discovered using an AltaVista advanced query (http://www.altavista.digital.com/cgi-bin/query?pg=aq&what=web) on the following:
link:potency.berkeley.edu and not url:potency.berkeley.edu
My organization has to print and mail several thousand postcards every working day, so we want to get the best postage rates we can. This means not only sorting by zip code, but adding a full ZIP+4 whenever possible, and printing postal barcodes (Delivery Point Bar Code, or DPBC, as the post office calls it) on the cards. The program that generates the postcards is custom written by an outside group, but we use standard software (Postware Presort) to do zip code presorting and get the ZIP+4 information on the cards, and a standard printer (Mannesman Tally MT691) to print the cards (including the barcodes).
We've been doing this for quite a while, without major problems, until one day a few weeks ago when the Post Office rejected our outgoing postcards because "the barcode had too many bars". This caused us a great deal of concern. (Several thousand postcards a day, with us paying about $.02 extra postage per card, can really add up.) So, for the past few weeks, our outside group has been working with us to try and figure out what the problem was. Yesterday, everything clicked.
The standard for DPBC is one start bar, then five bars per digit, and one stop bar. The digits in a DPBC are: the ZIP+4 (9 digits), two digits from the street address, and a "correction digit" (for a total of 62 bars). We had configured our zip code
package to automatically figure out the "correction digit", and were inserting the correction digit on the
postcards after the street address and zip code data.
The MT691 printer has POSTNET barcoding (for DPBC) built-in. All you have to do is send it a control code to turn on POSTNET barcoding, send it the data you want barcoded, and a control code to turn off POSTNET barcoding, and it will print nice POSTNET barcodes on your forms. Which is what we were doing.
It turns out that the MT691 has a nice feature: in POSTNET barcode mode, it *automatically* calculates the correction digit for you. So we were sending it data that included an already calculated correction digit, and the printer was calculating a correction digit based on the data it was being sent...and adding an extra spurious correction digit.
It also turns out that this behavior is documented *nowhere* in the manual.
The moral? As Tom Clancy said, "You can't even trust the manual." (Or, for that matter, the Post Office, which took a year and half to notice this problem.)
Dwight Brown, Texas Automobile Insurance Plan AssociationThe radio in my car displays either time of day or the tuned frequency. After changing channels, it automatically shows the frequency for 10 seconds, then reverts to time. There is also a button to manually toggle display modes. Yesterday I happened to press the button to view time precisely 10 seconds after changing channels. My action canceled the automatic action thus causing a result opposite to my intention. Unfortunate timing deprived me of visual feedback of what happened. Most people would blame the radio for misbehaving.
I tried to think of a way to redesign the toggle and automatic functions to be infallible. I couldn't. This made me despair. If we can't make such a mundane device behave perfectly, what can we achieve?
Soon thereafter, I read Mr. Cross' article in CPD 17.91. He discussed inadvertent activation of a machine and continued to say:
>It is possible to say that we have advanced to such a point in so
>many areas that seemingly innocuous things in one (such as a track of
>music on a CD) can trigger *very* unexpected results in another.
This made me wonder where the *real* complexity limit lies. The boundary between reliable expected behavior and the risk of unexpected behavior. I concluded that it lies somewhere between a simple inanimate object like a knife, and a folding knife. A simple knife doesn't *do* anything, we do things to it. It has no behavior. A folding knife will, some day, fold unexpectedly and someone will blame the knife. This leads to the seemingly obvious result:
Any object, capable of any behavior, is capable of unexpected behavior.
Disregard of this simple principle is the root cause of all other risks. It could be an alternative way to define the *meaning* of the word risk.
Dick Mills +1(518)395-5154 O- http://www.pti-us.comI keep seeing all of these scary postings about netscape, but few point out that Netscape 2.0 and 2.01 do not support Java on Windows 3.x and Macintosh platforms at all. Further with 2.01, in addition to curing the two problems, you can turn JavaScript off (Options/Security).
Do you suppose that in the future, when warnings are posted for such cross-platform applications that the poster could specify *which* platforms are affected? Padgett [Excellent idea. Thanks. PGN]
>Java/Netscape security flaw (Ed Felten):
Indeed there is a more basic flaw in the URLs used in the Internet that appears to make firewalls very weak prey for attackers and enables Web sites to launch highly distributed and hard-to-trace attacks. The basic flaw was published some weeks ago (e.g., gopher://localhost:79/0 for example) and extensions have now been used to launch probes and attacks by the thousands from sites all over the net. For more details, see: http://all.net/ -> Incident at all.net
> More on list-bombing (Phil Agre):
A discussion of list spams has been started on the LACC@suburbia.net mailing list. The ideas presented to date include:
[Fred, the USENET readers of comp.risks were spammed recently, along with many other USENET groups, but our direct-mail subscribers never saw it, and I know about it only because several folks forwarded it to me! PGN]All lists should include details on how to sign off the list in each mailing.
Finally, an optional X-Mailing-List header for mail to allow lists to be easily differentiated and identified. (Again requires participation by all list owners but could work.)
-> See: Info-Sec Heaven at URL http://all.net/
Management Analytics - 216-686-0090 - PO Box 1480, Hudson, OH 44236
[Fred's fourth bulleted item was also suggested by Rick Russell <rickr@is.rice.edu>, hien@ncddenver.ncd.com (Hien D. Ngo), and
przemek@rrdjazz.nist.gov (Przemek Klosowski). Rick added a little more discussion (but not markedly different from others), and Przemek suggested checking out an item by Don Libes, (http://www.cme.nist.gov/pub/msid/pubs/libes96b.ps). PGN]
A couple of years ago I posted some information on forged e-mail and the fact that the header almost always contains sufficient information to determine if the message is bogus. For instance examination of the "Received: from" lines in the header is generally sufficient to raise doubts.
The problem is that e-mail is essentially sent "blind" and unlike interactive sessions encourages "fire and forget". Further RFC821 makes it clear that the information sent by the mailer such as the "Reply" entry was intentionally made user configurable ("isn't a bug, it's a feature").
In normal messaging this is not a problem however I have seen several newsgroups which routinely generate over a hundred messages a day.
To me, the simplest possible mechanism would be to require confirmation with a unique message. I suspect that few will be willing to go to this length so have a fallback: if the subscribing message was "Received: from" a domain other than that of the apparent requestor, then require confirmation.
PadgettPerhaps the simple solutions of a simpler world just aren't applicable in the new, now-massively-popular internet. Many protocols on the net — from e-mail to usenet to more basic routing issues, all familiar to RISKS — are based in trust. When the net was small, trust worked; now, I have my doubts.
A couple years ago I proposed a new system to the team at CERN that created the WWW. I won't bore everyone with the details, but basically 1) discussion forums existed on an invisibly sliding scale between a single-host web-annotations to a network-wide usenet group; and 2) user access varied on a scale between completely-user-initiated "browsing" through user-merely-notified "newsreading" to sent-to-the-user "mailing lists."
However, the user interaction was with the local newshost, which then if necessary dealt with remote servers. All articles, digests, summaries, etc. that are mailed to a user are sent by that users' local newshost — which incidentally gives the user one central control point. (It also completely automates mirroring and caching, which was my original aim.)
This certainly won't stop anyone from sending bogus mail. But it would be more difficult to illicitly subscribe someone to a mailing list, and it would be much easier for the user to clean up the problem.
Frederick Roeber roeber@iea.com | roeber@cern.chFidonet suffered *massive* list-bombing attacks on dislike administrators a couple of months back. What made this worse than the usually list-bombing is that once the mail entered the Fidonet,org domain, it was transported via dial-up Fidonet connections, not via the Internet.
This resulted in effective denial of service attacks, as as some of the systems couldn't handle the traffic levels, and even where they could, trying to find legitimate mail was difficult when it was mixed into the list traffic.
This was aggravated due to a couple of design "features" of Fidonet. Most Fidonet nets (the .nxxx level in the addresses) don't have a local fidonet<>Internet gateway system. So traffic for user@f111.n222.z1.fidonet.org all went to the default gateway. That system then stuck it into the low-priority routed mail system rather than wasting his money dialing direct all over North America. The routing system is hierarchical, so lots of nodes got *really* jammed by this. Even nets with local gateways still had that poor gateway system trying to make phone calls to the recipients.
This sort of thing wasn't anticipated, except that policy was that the gateways were *not* to be used for mailing lists. The end result was that on March 1st, the default gateway was discontinued. Now, only fidonet nets with explicit MX records are reachable.
Gateway operators are *still* getting huge amounts of list traffic, much of it aimed at addresses that have *never* existed. This has apparently been an organized attack by some party, and it is at least successful to the extent that it annoys the gate-ops.
My advice to list maintainers is to lock out *all* addresses in the fidonet.org domain, and if you get complaints, check to see which system the MX record points at and ask the postmaster there if he allows list traffic through his system. Nine times out of ten the answer will be along the lines of "Hell, no!". And you can then report to the complainer that he is violating the rules under which the gateway operates.
If you get a yes response from a gate-op, great. Just remember to check occasionally to see that the gateway system hasn't changed.
It's a pity that things are like this, but too many people are abusing what was meant to be a conduit for low-volume *personal* mail. <sigh>
Leonard Erickson (aka Shadow) shadow@krypton.rain.com leonard@qiclab.scn.rain.com <--last resortIt's just as easy to forge e-mail from a mainframe as from a personal computer (*). The basic problem is not simply on the client side; it's on both sides. The mail client and mail server must implement a system that confirms and records the identity (insofar as it can be determined) of the mail sender, and _rejects e-mail for which the identity cannot be confirmed_. Further, the system would have to have wide implementation, or the malicious e-mail sender could just find a non-authenticating server to his or her e-mail.
As usual, the price of security is convenience; such a system would be substantially more complex than the common SMTP protocol we have now, and would require software changes on both the client and server sides. For safety in a lab or office environment, it might also require that users enter a confirmation password each and every time they send e-mail, although Kerberos-style authentication tickets can be used to get around that problem to a limited extent.
(*) Admittedly, using a password-authenticated system for the forgery provides a better record of what transpired, leaving the miscreant open to capture. But what if the miscreant were to send e-mail via an open SMTP server in, say, Singapore? I would imagine that getting a sysadmin in a distant country to give you his or her system logs would be awfully difficult.
Rick R.To assist in those who need to cancel spams, we have set up a free (donations accepted) spam-cancelling capability on the all.net Web site.
We considered handing out a convenient shell script along with the list of over 10,000 mailing lists we are now able to cancel subscriptions to, but we decided this might add to spams instead of eliminating them.
Instead, we opted to have the user provide the site name and we provide a shell script to unsubscribe from the lists coming from that site.
For full details, use: http://all.net/ and look under CanSpam.
-> See: Info-Sec Heaven at URL http://all.net/[Can spam attacks be stopped? Canned spam controls would be of interest to Monty Python. PGN]
Another pool used in Oregon is the list of registered car owners. This, combined with a zip code that overlaps two counties, got me a Jury Duty summons for Multnomah county while I live in Washington county. Of course, the Department of Motor Vehicles representative had trouble fixing our record because the computer "knew" that our zip code was a Mult. Co. zip. As it turns out, probably everyone in our zip code in Wash Co. has this problem but doesn't know it yet. And no, the DMV would not change us all - they told us that each person has to call in individually. They didn't want to hear from a Wash. Co. official requesting a blanket change.
Risks (in any order):
In most (all?) states, whatever agency issues drivers' licenses also issues official ID cards for people who aren't eligible to drive or don't wish to. For people who don't wish to drive, or for children who look several years older/younger than they are, these cards are a necessity for things such as writing checks, watching movies with their peers, etc.
If Emily had a state-issued ID card, it doesn't take much imagination to figure out why she got called. One might try to fault a computer. But the real risks are nothing new:
Jury summoning and selection procedures are set by New Jersey state law. New Jersey has recently greatly expanded the lists from which jury duty lists may be composed. Three were concerns about non-representative juries in some urban counties, and claims that the expanded lists would add 30% more bodies to the jury pool. The new state law also ended the exemption for police officers and other professions. (Like a cop wouldn't be challenged right off a jury — what a waste of time!)
The youthful juror problem is occurring because just about any official contact with the state government now gets you onto the jury list. Little Emily's case is only one of several, but hers came to public attention because her parents are lawyers and pointed out the idiocy publicly. It seems Emily had to file a state income tax return, probably for interest income, and got onto the massive jury list that way.
[Above info as I remember it being reported in the Star-Ledger last Sunday — any errors are mine.]
One wonders how well the new expanded jury lists have been winnowed. I can see an active citizen, who drives, owns property, files taxes, has wages reported, votes, etc., being present on the list many times. It seems to me that this would lead to a non-representative jury pool, biased toward people with multiple jobs and owning property.
While a NJ juror is now exempt for three years after actually serving, certain counties in NJ are notorious for summoning large pools, then excusing most of them because the court-load is not what was expected. I for one am sick of turning my planned work schedule upside-down, then calling the juror tape on the morning of my first day and finding I'm excused, then 9-12 months later, going through the whole process again because I haven't actually _served_. I had the honor of receiving two jury summonses in the same month, so I am already unimpressed with Middlesex county's juror data handling skills, and that was _before_ the new law, when only voter and driver registrations were used. The juror questionnaire asks for SSN, but utterly lacks a privacy act statement, showing just how "up" on data issues this county is.
I'm betting that Emily's parents will be making more "Please excuse my child from jury duty" calls to the courthouse before she's 18. After all, every year she'll file a tax return, and get back onto the jury summons list.
Aside from pointing out the problems of using data collected for one purpose for an unrelated purpose, the new juror selection lists and criteria risk further annoying citizens of this state.
Dorothy Klein dklein@pluto.njcc.com[If you wonder why all these messages made it into RISKS, it might be once again to illustrate how difficult it is for bureaucracies to deal with regulations and procedures — let alone computers! PGN]
Please report problems with the web pages to the maintainer