RISKS-LIST: Risks-Forum Digest Tuesday 8 August 2006 Volume 24 : Issue 36
ACM FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)
Peter G. Neumann, moderator, chmn ACM Committee on Computers and Public Policy
***** See last item for further information, disclaimers, caveats, etc. *****
This issue is archived at <http://www.risks.org> as
<http://catless.ncl.ac.uk/Risks/24.36.html>
The current issue can be found at
<http://www.csl.sri.com/users/risko/risks.txt>
Contents: (Backlogged. Good trip to Vancouver for Secure USENIX and EVT.)
Electrical Fires in Queens (R. Mercuri)
AOL releases 500K users' search queries -- The Last Straw (Lauren Weinstein
with included analysis by Seth Finkelstein)
Digital retouching of photos to make a propaganda point (Jeremy Epstein)
Voting machines in Ireland and The Netherlands (Erling Kristiansen)
Dutch energy company Eneco sends huge bill (Leon Kuunders)
Robot car park holds cars hostage (Steve Klein)
German road pricing system should help fighting crime, politicians say
(Harald Vogt)
Unexpected consequences of airport random-screening glitch (Steve Summit)
RFID Clonable (Brad Malin via Dave Farber's IP)
Re: The Risks of retro computing? (Tom Watson)
IEEE e-mail alias service with Comcast (Christopher Stacy)
REVIEW: "Symbian OS Platform Security", Craig Heath (Rob Slade)
Abridged info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Mon, 24 Jul 2006 11:05:43 -0400
From: "R. Mercuri" <mercuri@private>
Subject: Electrical Fires in Queens
I don't know why the National news, or RISKS, isn't covering the electrical
fires in Queens. There's been a series of power outages, exacerbated by
fires that start off more fires. The news footage on NY TV stations is
astonishing -- burning wires in the air, and explosions in manholes. The NY
Times had an article at:
http://www.nytimes.com/2006/07/22/nyregion/22cnd-power.html?hp&ex=1153627200&en=c53052af5d9b3841&ei=5094&partner=homepage
and there's a community paper with a scary photo at:
http://www.zwire.com/site/news.cfm?newsid=16946439&BRD=2731&PAG=461&dept_id=574903&rfi=6
but otherwise there hasn't been much or consistent coverage by the major US
media (see google news: electrical fires astoria), even though thousands
have been without power, now for a week. Residents, business owners, and
local leaders are becoming peeved at being ignored (including by Governor
Pataki who's been refusing to declare the area a disaster).
[The outage lasted for about a week, but the aging underground
infrastructure is most likely still fragile and vulnerable to more
such outages. Some of the wiring apparently dated to the beginning
of the previous century. PGN]
------------------------------
Date: Mon, 7 Aug 2006 09:55:15 -0700 (PDT)
From: Lauren Weinstein <lauren@private>
Subject: AOL releases 500K users' search queries -- The Last Straw
Greetings. I've written and spoken many times about the sensitivity of
search engine query data. We all know about Google's stance in DOJ vs.
Google early this year, where Google wisely attempted (for several reasons)
to prevent release of such data to a government fishing expedition related
to "child protection" legislation. We also know that Gonzales, et al. are
merrily pushing mandated data retention laws -- again mainly in the name of
child protection -- that would leave Internet users vulnerable to all manner
of unreasonable surveillance of their Internet activities. All of this is
already enough to be sounding alarm bells regarding the lack of reasonable
legislated protections for such data.
The AOL action in releasing the search records of a reported 500K AOL users
-- assuming it took place as outlined below -- is probably the most
egregious violation of users' search privacy in the history of the Internet,
despite the half-hearted attempt at crude anonymization. The unbelievable
lack of responsibility or good judgment shown by AOL in this case should be
enough to cause any remaining AOL subscribers (or users of their free
services) to strongly consider ceasing any further contact with AOL.
Furthermore, we need to accept the fact that search query data is incredibly
sensitive and often contains extremely personal data that does not lose its
potential for abuse via simplistic forms of anonymization. Nor can we
necessarily depend indefinitely on some individual search engines' honest
and praiseworthy desires to protect such data (e.g. Google) in the face of
intense competition and intrusive government actions.
Search query data can contain the sum total of our work, interests,
associations, desires, dreams, fantasies, and even darkest fears.
We must demand that this data be protected.
--Lauren--
P.S.
I have removed URL reference (3) from the forwarded message below. Anyone
who tried to forward that original message to an AOL user may have been in
for a surprise.
At least in my experiments just now, AOL rejects that message since URL
reference (3) contained a numeric IP address rather than a domain address.
Ironic, isn't it? AOL "protects" users by blocking messages with IP
addresses in URLs (can such addresses be suspect? Yeah, but they can easily
be legit, too) -- yet they happily release the most private aspects of
users' search activities.
It's like a Fellini movie over there, but much less amusing.
Lauren Weinstein +1 (818) 225-2800 http://www.pfir.org/lauren
lauren@private or lauren@private Lauren's Blog: http://lauren.vortex.com
From: Seth Finkelstein <sethf@private>
Date: August 7, 2006 1:05:50 AM EDT
To: Dave Farber <dave@private>
Subject: AOL Releases Search Logs from 500,000 Users [From IP]
AOL Releases Search Logs from 500,000 Users
[1] Adam D'Angelo - 8/5/2006
AOL just released the logs of all searches done by 500,000 of their users
over the course of three months earlier this year. That means that if you
happened to be randomly chosen as one of these users, everything you
searched for from March to May (2006) is now public information on the
Internet.
This was not a leak - it was intentional. In their desperation to gain
recognition from the research community, AOL decided they would compromise
their integrity to provide a data set that might become often-cited in
research papers: "Please reference the following publication when using this
collection..." is the message before the download.
This is a blatant violation of users' privacy. The data is "anonymized",
which to AOL means that each screenname was replaced with a unique
number. "It is still a research question how much information needs to be
anonymized to protect users," [9] says Abdur from AOL. Here are some examples
of what you can find in the data:
User 491577 searches for "florida cna pca lakeland tampa", "emt school
training florida", "low calorie meals", "infant seat", and "fisher price
roller blades". Among user 39509's hundreds of searches are: "ford 352",
"oklahoma disciplined pastors", "oklahoma disciplined doctors", "home
loans", and some other personally identifying and illegal stuff I'm going to
leave out of here. Among user 545605's searches are "shore hills park mays
landing nj", "frank william sindoni md", "ceramic ashtrays", "transfer money
to china", and "capital gains on sale of house". Compared to some of the
data, these examples are on the safe side. I'm leaving out the worst of it -
searches for names of specific people, addresses, telephone numbers, illegal
drugs, and more. There is no question that law enforcement, employers, or
friends could figure out who some of these people are.
I hope others can find more examples in the data, which is up for [10]
download over here. The data set is very large when uncompressed which makes
it pretty hard to work with, but someone should set up a web interface so
people can browse it (or even 10% of it) without having to download the
400mb file. If you make a mirror or better interface to the data, or find
other examples, let me know and I'll put a link up here.
This is the same data that the DOJ wanted from Google back in March.
[11] This ruling allowed Google to keep all query logs secret. Now any
government can just go download the data from AOL.
It's unclear if this is the type of data AOL released to the government
[12] back when Google refused to comply. If nothing else, this should be a
good example of why search history needs strong privacy protection.
Thanks to Greg Linden for pointing this out [13] here.
Update 2: The md5 of the file AOL posted (and now removed) is
31cd27ce12c3a3f2df62a38050ce4c0a. I'm posting it so you can make sure you
have a valid copy, but so far none of the copies I've seen are fake.
Update: Seems like AOL took it down. There are some mirrors of the data in
the comments of the digg story, linked below. I estimate about 1000 people
have the file, so it's definitely going to be circulated around. The [2]
main AOL research page is still up, with some other data collections. The
[3] google cache of the download page is still up, but you can't get the
data. Here's discussion at other sites:
* [4] siliconbeat
* [5] techcrunch
* [6] digg
* [7] reddit
* [8] zoli's blog
References
1. http://www.ugcs.caltech.edu/~dangelo/
2. http://research.aol.com/pmwiki/pmwiki.php?n=Main.Home
3. [ removed to avoid AOL block ]
4. http://www.siliconbeat.com/entries/2006/08/06/aol_research_exposes_data_weve_got_a_little_sick_feeling.html
5. http://www.techcrunch.com/2006/08/06/aol-proudly-releases-massive-amounts-of-user-search-data/
6. http://digg.com/tech_news/AOL_Releases_Search_Logs_from_500_000_Users
7. http://reddit.com/info/cfvt/comments
8. http://www.zoliblog.com/blog/_archives/2006/8/6/2204969.html
9. http://research.aol.com/pmwiki/pmwiki.php?n=Research.500kUserQueriesSampledOver3Months
10. http://research.aol.com/pmwiki/pmwiki.php?n=Research.500kUserQueriesSampledOver3Months
11. http://googleblog.blogspot.com/2006/03/judge-tells-doj-no-on-search-queries.html
12. http://www.boingboing.net/2006/01/20/aol_we_did_not_compl.html
13. http://glinden.blogspot.com/2006/08/chance-to-play-with-big-data.html
Seth Finkelstein Consulting Programmer http://sethf.com
Infothought blog - http://sethf.com/infothought/blog/
Interview: http://sethf.com/essays/major/greplaw-interview.php
------------------------------
Date: Mon, 7 Aug 2006 11:50:15 -0700
From: Jeremy Epstein <jeremy.epstein@private>
Subject: Digital retouching of photos to make a propaganda point
Digital retouching of photos isn't unusual, whether to make a teenagers acne
go away or to make a joke. It gets serious though when it's used for
propaganda.
Reuters yesterday withdrew photos that purported to show smoke rising from
buildings in Beirut after an Israeli bombing. After bloggers showed obvious
evidence of tampering (such as buildings repeated through a picture, smoke
that's duplicated), Reuters investigated and admitted that "photo editing
software was improperly used on this image". They have now suspended the
photographer. There are allegations by bloggers of other image tampering by
the same photographer, Adnan Hajj.
http://www.ynetnews.com/articles/0,7340,L-3286966,00.html describes the
Reuters action. http://littlegreenfootballs.com/weblog/ is one of the blogs
that first reported the Photoshopping.
Certainly not the first time there's been distortion in time of war; the
ease of manipulations combined with the power of bloggers to reveal what's
going on may be part of a balance of power.
------------------------------
Date: Fri, 21 Jul 2006 22:20:30 +0200
From: Erling Kristiansen <erling.kristiansen@private>
Subject: Voting machines in Ireland and The Netherlands
According to EDRIGRAM, the on-line newsletter of "European Digital Rights",
number 4.14:
On 4 July 2006, the Irish Commission on Electronic Voting released its
second report on the secrecy and accuracy of the e-voting system purchased
by the Irish Government.
The summary remarks at the beginning of the 200 page report say: "The
Commission concludes that it can recommend the voting and counting equipment
of the chosen system for use at elections in Ireland, subject to further
work it has also recommended, but that it is unable to recommend the
election management software for such use."
The "further work" includes, among others:
1) add a voter verified audit trail;
2) replace the election management software (which prepares election
data, reads votes from "ballot modules", and calculates results) with a
version that is developed to mission critical standards;
3) modify the embedded software within the voting machines to bring it
up to mission critical standard;
4) make certain modifications to the machines themselves;
5) test all components to mission critical standard;
6) modify the specification for the PC that is to be used for vote management;
7) test the system as a whole (including end-to-end testing) to mission
critical standard;
8) rectify the security vulnerabilities identified in the way data is
transferred within the system.
This is quite a mouthful. In particular, the "mission critical standards"
may be quite difficult to achieve as a retrofit. The article speculates
that the responsible minister, who declares his intention to continue the
project, "may not realize the extent of the changes required". [Or is it a
polite way of saying "No thank you"? -EK]
Full article at http://www.edri.org/edrigram/number4.14/evotingireland
The article includes several links, including a link to the full report.
As far as I can make out from various sources, the voting machines in
question are essentially the same as the Nedap machines used in The
Netherlands for years. Little public criticism of these machines appears in
the general press.
But they do, indeed, have problems: According to the "Bits of Freedom"
newsletter:
In a local election, one candidate got 1, 3, 7, and 181 votes, respectively,
in the 4 polling stations where he was a candidate. The candidate not only
was en election official in the high-vote station, he operated the machine!
Peter Knoppers, according to the article an expert on voting machines, is
quoted saying that manipulation of the machine by a voting official is "a
piece of cake". For example, if a key is turned at the exact moment of the
vote being acknowledged by the voter, the vote will not be counted. The
missed votes can then be added manually at a later time, for any candidate
of your choice.
Full story (in Dutch) at
http://www.bof.nl/nieuwsbrief/nieuwsbrief_2006_14.html
This article also has several links, all in Dutch.
------------------------------
Date: Tue, 25 Jul 2006 13:16:47 +0200
From: Leon Kuunders <leon@private>
Subject: Dutch energy company Eneco sends huge bill
Apparently the Dutch energy supplier Eneco send an invoice for **euro
2.144.607 and 90 cents [which in the US would be written as 2,144,607.90] to
a man for his two month energy usage. The man would have used **20.000.000
kW electricity and 102.284 m3 gas.
When he called the energy supplier the call-center operator replied with:
"It can be that this invoice isn't correct sir. We can sort it out, but you
will have to pay the bill first. We can setup a payment arrangement if you
like."
The cause of the error remains unknown.
------------------------------
Date: Tue, 8 Aug 2006 12:01:16 -0400
From: Steve Klein <steveklein@private>
Subject: Robot car park holds cars hostage
The city of Hoboken, New Jersey owns a parking garage with an automated
car-parking system. The software that runs the hardware is licensed from
Robotic Parking of Clearwater, Florida.
Following a recent contract dispute, the software license was allowed to
expire and hundreds of cars were trapped in the garage for several days.
More details here:
http://www.wired.com/news/technology/0,71554-0.html?tw=wn_index_1
Steve Klein, Your Mac Expert Phone: (248) YOUR-MAC or (248) 968-7622
------------------------------
Date: 4 Aug 2006 06:55:03 -0700
From: harald.vogt@private
Subject: German road pricing system should help fighting crime, politicians say
When the German Toll Collect system was put into operation in January 2005,
it was accompanied by a law regulating the use of the data that is collected
for billing. In particular, the system takes photographs of vehicles passing
the scaffolds on which cameras and reading devices are mounted. According to
this law, passing that information on to government agencies other than
customs and the "Federal Agency for Commercial Transport" is illegal. This
applies -- for now -- especially to the police, who cannot use the data for
criminal prosecution. This is in accordance with German privacy regulations
demanding that data collection has to serve a well-defined and well-stated
purpose and cannot be done for future, yet unknown needs, such as not yet
committed crimes.
It seems that a current case might turn that law upside down rather sooner
than later. After an 18-year old female student was found dead in a Autobahn
parking lot, it became clear through DNA testing that the murderer is
actually a serial killer who is wanted for a murder in 2003 and an attempted
murder in 2004. As he is suspected to be a truck driver, the Toll Collect
recordings may give a clue on his identity. However, the police is not
allowed to get their hands on that data.
This case has sparked off a lively discussion in the political scene. Some
(mostly right-wing politicans and police officials) say, the Toll Collect
data should be used freely by police to investigate crimes. Others, such as
data protection officers, reject that on grounds of data protection and
privacy. As an obvious risk, they see the freedom of communication (which
includes anonymous mobility) endangered by tendencies to promote
surveillance. There are also some moderate voices who do not rule out the
passing of data fundamentally but require high legal standards to do
so. Members of the left-right coalition currently running the German federal
government have announced to pursue a change in the aforementioned law that
would allow to use the data for prosecution.
Apparently, police are currently trying to exploit a loophole in the
system. While they are not allowed to use the Toll Collect data directly,
police have asked shipping companies to look through their own files and
report truck drivers that may have passed the parking lot during the night
of the murder. If they comply, this would yield basically the same
information to the police.
Interestingly, some politicians seem not so much concerned about the privacy
of citizens, but rather whether there will be enough money left for building
new roads after the Toll Collect infrastructure is extended into a
surveillance tool. Today, the system is already very costly -- a quarter of
the collected money is spent on its operation -- and would be even more if
continuous surveillance was in operation. This money would then be lacking
in the maintenance and building of roads. It seems the risk here is that a
road surveillance tool could be created for which there exist no roads to
monitor.
------------------------------
Date: Fri, 21 Jul 2006 17:52:45 -0400
From: Steve Summit <scs@private>
Subject: Unexpected consequences of airport random-screening glitch
This doesn't seem to have been covered in the media yet and I don't have
full details, but according to an acquaintance who just traveled through
there, a computer or computers unknown at Newark airport this morning
(2006-07-21) mysteriously started selecting 20% of passengers for the random
intensive security screening, instead of the normal 2%. No one felt
authorized to countermand the computer's selections, so screeners were
compelled to carry out all the excessive screenings, resulting in huge
delays and many missed flights. A small glitch in a random selection
process can have large and unexpected consequences.
------------------------------
Date: July 25, 2006 10:10:47 AM EDT
From: Brad Malin <b.malin@private>
Subject: RFID Clonable [From Dave Farber's IP]
Hi Dave, remember a couple of years ago when you said you wanted to clone
and repeat RFIDs - apparently someone has built the system to it.
-brad
http://www.engadget.com/2006/07/24/verichips-human-implatable-rfid-chips-clonable-sez-hackers/
VeriChip's human-implatable RFID chips clonable, sez hackers
Posted Jul 24th 2006 4:14PM by Donald Melanson
Filed under: Misc. Gadgets, Wireless
[Note: "implatable" is "mispelt" in both the URL and the title of the
article, but the URL works as of when I am putting out this issue, and
"implantable" is used in the text of the article! PGN]
In case anyone needed more proof that we're all living in a Philip K. Dick
novel, a pair of hackers have recently demonstrated how human-implantable
RFID chips from VeriChip can be easily cloned, effectively stealing the
person's identity. Annalee Newitz and Jonathan Westhues showed off their
handiwork at the HOPE Number Six conference in New York City this weekend,
with Newitz herself playing the role of guinea pig, implanting a VeriChip
RFID chip in her right arm. To clone the chip, Westhues first red Newitz's
arm with a standard RFID reader, then scanned it again with a homebrew
antenna connected to his laptop, which recorded the signal off the chip. He
then used the same RFID reader to read the signal from his laptop, which
promptly spit out Newtiz's supposedly unique ID. For its part, VeriChip has
only said they haven't yet had a chance to review the evidence but still
insist that "it's very difficult to steal a VeriChip."
IP Archives at: http://www.interesting-people.org/archives/interesting-people/
------------------------------
Date: Mon, 24 Jul 2006 11:34:55 -0700
From: "Watson, Tom" <t_wtom@private>
Subject: Re: The Risks of retro computing? (RISKS-24.35)
The story mentions that the IBM 1401 computer "Can't Add Doesn't Even Try".
This is the wrong computer. The IBM 1620 is the computer that "Can't
Add...". The computer museum has a working example. Later the IBM 1620,
Model 2 could add, but still needed a table to multiply (but knew that
multiplying by zero was a simpler operation). I can't vouch for the
operations in the IBM 1401, as I haven't used the machine, but I am very
familiar with the IBM 1620. Both machines hit the streets in the 1959-1960
time frame.
Not very Risks oriented, but a bit of history.
------------------------------
Date: Thu, 20 Jul 2006 19:36:02 -0400
From: Christopher Stacy <cstacy@private>
Subject: IEEE e-mail alias service with Comcast
Pete Klammer writes about losing email due to spam blacklisting due to the
IEEE forwarding service's use of BrightMail. His analysis is that
BrightMail is an "unaccountable third party" because IEEE could supposedly
not obtain confirmation, logs, or rule sets describing the lossage of his
messages.
But the other involved mail carriers, such as his ISP, IEEE, or even his own
desktop software are all potentially filtering by using blacklist databases
and rules which may be inscrutable. The problem is the unavailability of an
audit trail.
The victimhood tone of the story and the suggestion that society is placing
undue trust in third parties fails to identify a more straightforward
accountability problem. His forwarding service (IEEE) has contracted with
BrightMail for filtering services, but is then dismissing him when there's a
problem with the forwarding service. This is simply poor customer service,
and tantamount to "blaming the computer" as was very common in the 1970s.
In the unlikely scenario that BrightMail customers cannot get the necessary
information, then what's happened is that IEEE made poor contract with that
vendor. But I am pretty sure that BrightMail is not such a black box, and
does indeed have the necessary audit trails. So the most likely explanation
is that the IEEE folks were just too inept, lazy, or otherwise disinterested
to bother accessing those resources when asked to investigate the problem.
This does not call for the elimination of a system in which third parties
can be contracted for valuable email processing services. BrightMail is no
more a "third party" in this scenario than IEEE. The risk is that if a
computer is involved, people will accept lame blame-passing excuses from
their various service providers.
------------------------------
Date: Thu, 03 Aug 2006 10:44:52 -0800
From: Rob Slade <rmslade@private>
Subject: REVIEW: "Symbian OS Platform Security", Craig Heath
BKSYOSPS.RVW 20060615
"Symbian OS Platform Security", Craig Heath, 2006, 0-470-01882-8,
U$70.00/C$90.99
%A Craig Heath
%C 5353 Dundas Street West, 4th Floor, Etobicoke, ON M9B 6H8
%D 2006
%G 0-470-01882-8
%I John Wiley & Sons, Inc.
%O U$70.00/C$90.99 416-236-4433 fax: 416-236-4448
%O http://www.amazon.com/exec/obidos/ASIN/0470018828/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/0470018828/robsladesinte-21
%O http://www.amazon.ca/exec/obidos/ASIN/0470018828/robsladesin03-20
%O Audience a Tech 2 Writing 2 (see revfaq.htm for explanation)
%P 249 p.
%T "Symbian OS Platform Security"
Part one is an introduction to the Symbian mobile (cellular) phone operating
system, and particularly its security provisions. Chapter one examines the
reasons for the emphasis on security in a mobile phone: the users'
perception of it as a more personal (and therefore more trusted) device and
the acceptability of remote network installations and administration.
Therefore, the developers of Symbian were faced with the challenge of
creating an "open" development platform, while implementing security
constraints. "Platform Security Concepts," in chapter two, presents an
interesting basic catalogue, but concentrates on capability lists. (In
this, the term may not be used in a standard manner: the capabilities appear
to be preset, rather than being taken from the calling capability.)
Part two looks at application development for platform security. Chapter
three describes the basic functions of the Symbian security environment. A
decent, basic list of suggestions for writing secure applications is in
chapter four, but there are few details. How to write secure servers
(common processes), in chapter five, provides only generic advice, and has
oddly little information that is distinctive to Symbian. Chapter six, on
the development of plug-ins, is more code and architecture specific. The
safe sharing of data, in chapter seven, is addressed with a useful list of
threats and countermeasures, and an outline of various security related
components and provisions.
Part three deals with the management of platform security attributes.
Chapter eight examines the native software installer, concentrating on
encryption key certificates. How developers obtain and use these
certificates is reviewed in chapter nine. Some of the public key
infrastructure behind the system can be inferred from the description (by
those familiar with the concepts) but little detail is provided.
Part four, on the future of mobile device security, consists of chapter
fourteen, which mentions a variety of potential functions for mobile phones.
For those wanting an introduction to the security provisions of the Symbian
operating system, this work provides a useful starting guide. Developers,
however, may need a bit more. For example, the statement is made that the
platform is "less prone" to buffer overflows, but there is no discussion of
why this is so, how it is achieved, or to what extent a developer can rely
upon the operating system to protect against the problem of buffer overflows
(or other types of malformed data). Given that most Symbian security is
based on capability tables and certificates (and particularly with a
somewhat non-standard definition of capabilities) these concepts, and their
limits, should probably be explained more fully.
copyright Robert M. Slade, 2006 BKSYOSPS.RVW 20060615
rslade@private slade@private rslade@private
http://victoria.tc.ca/techrev/rms.htm
------------------------------
Date: 2 Oct 2005 (LAST-MODIFIED)
From: RISKS-request@private
Subject: Abridged info on RISKS (comp.risks)
The ACM RISKS Forum is a MODERATED digest, with Usenet equivalent comp.risks.
=> SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent)
if possible and convenient for you. The mailman web interface can
be used directly to subscribe and unsubscribe:
http://lists.csl.sri.com/mailman/listinfo/risks
Alternatively, to subscribe or unsubscribe via e-mail to mailman your
FROM: address, send a message to
risks-request@private
containing only the one-word text subscribe or unsubscribe. You may
also specify a different receiving address: subscribe address= ... .
You may short-circuit that process by sending directly to either
risks-subscribe@private or risks-unsubscribe@private
depending on which action is to be taken.
Subscription and unsubscription requests require that you reply to a
confirmation message sent to the subscribing mail address. Instructions
are included in the confirmation message. Each issue of RISKS that you
receive contains information on how to post, unsubscribe, etc.
=> The complete INFO file (submissions, default disclaimers, archive sites,
copyright policy, etc.) is online.
<http://www.CSL.sri.com/risksinfo.html>
The full info file may appear now and then in RISKS issues.
*** Contributors are assumed to have read the full info file for guidelines.
=> .UK users should contact <Lindsay.Marshall@private>.
=> SPAM challenge-responses will not be honored. Instead, use an alternative
address from which you NEVER send mail!
=> SUBMISSIONS: to risks@private with meaningful SUBJECT: line.
*** NOTE: Including the string "notsp" at the beginning or end of the subject
*** line will be very helpful in separating real contributions from spam.
*** This attention-string may change, so watch this space now and then.
=> ARCHIVES: ftp://ftp.sri.com/risks [subdirectory i for earlier volume i]
<http://www.risks.org> redirects you to Lindsay Marshall's Newcastle archive
http://catless.ncl.ac.uk/Risks/VL.IS.html gets you VoLume, ISsue.
Lindsay has also added to the Newcastle catless site a palmtop version
of the most recent RISKS issue and a WAP version that works for many but
not all telephones: http://catless.ncl.ac.uk/w/r
<http://the.wiretapped.net/security/info/textfiles/risks-digest/> .
==> PGN's comprehensive historical Illustrative Risks summary of one liners:
<http://www.csl.sri.com/illustrative.html> for browsing,
<http://www.csl.sri.com/illustrative.pdf> or .ps for printing
------------------------------
End of RISKS-FORUM Digest 24.36
************************
This archive was generated by hypermail 2.1.3 : Tue Aug 08 2006 - 10:54:59 PDT