[RISKS] Risks Digest 25.73

From: RISKS List Owner <risko_at_private>
Date: Thu, 16 Jul 2009 14:28:47 PDT
RISKS-LIST: Risks-Forum Digest  Thursday 16 July 2009  Volume 25 : Issue 73

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
The current issue can be found at

Massive Visa overcharge (Steven M. Bellovin)
German electronic health card system failure (Martyn Thomas)
Boston Ballet School data breach (Concerned Parent)
Risks of the Cloud: Liquid Motors (Gene Wirchenko)
Facebook fraud about to get more interesting? (Paul Wallich)
Taiwan man rescued after getting lost via GPS (jidanni)
July 4 Fireworks cyber-attack (PGN)
Twitter Attack Raises Flags on Security (PGN)
Teenager Falls Into Manhole While Texting (Michael Barkoviak via Monty Solomon)
When Texting Is Wrong (Randy Cohen via Monty Solomon)
TV station forced to go old school after fire (Denise Caruso)
Re: More on the DC Metro collision 22 June 2009 (Steven M. Bellovin,
  Rick Dickinson, David Lesher)
Saltzer-Kaashoek Computer System Engineering book finally published (PGN)
paypal accounts (Toby Douglass)
SPAM: Phishing - the state of the art? (Dirk Fieldhouse)
Re: Bozeman (D.F. Manno, Mark Brader)
Oakland 2010, IEEE Symposium on Security and Privacy, CFP (Ulf Lindqvist)
Abridged info on RISKS (comp.risks)


Date: Wed, 15 Jul 2009 22:12:09 -0400
From: "Steven M. Bellovin" <smb_at_private>
Subject: Massive Visa overcharge

According to CNN, about 13,000 customers of Visa found a charge for
$23,148,855,308,184,500 on their statements
Since that's rather larger than the combined GDPs of all the world's
economies, Visa did acknowledge the problem and reversed the charge,
and even reversed the $15 overdraft fee...

Where did that amount come from?  If you multiply by 100 to get cents and
convert to hex, you get 2020202020201250.  0x20 is an ASCII blank, which
suggests that someone copied a character string, rather than converting to a
long int or unsigned long int.  And the 0x1250?  Perhaps that's the
converted amount of $46.88.  (We can also learn that Visa is using 64-bit
integers, which means they're ready to handle charges greater than ~$21M or
perhaps $43M, and that they're using a non-EBCDIC platform at some point...)

Steve Bellovin, http://www.cs.columbia.edu/~smb

  [Several other RISKS readers reported on this one, including Jeremy
  Epstein.  PGN]


Date: Sun, 12 Jul 2009 10:06:32 +0100
From: Martyn Thomas <martyn_at_thomas-associates.co.uk>
Subject: German electronic health card system failure

"Test runs with Germany's first-generation electronic health cards and
doctors' "health professional cards" have suffered a serious setback.  After
the failure of a hardware security module (HSM) holding the private keys for
the root Certificate Authority (root CA) for the first-generation cards, it
emerged that the data had not been backed up. Consequently, if additional
new cards are required for field testing, all of the cards previously
produced for the tests will have to be replaced, because a new root CA will
have to be generated."

href="http://en.wikipedia.org/Hardware_Security_Module" rel="external"

  [Also noted by Joe Loughry.  PGN]


Date: Thu, 16 Jul 2009 07:45:40 -0700 (PDT)
From: Concerned Parent <bostonballetschooldatabreach_at_private>
Subject: Boston Ballet School data breach

On July 13, the Boston Ballet School inadvertently mailed to many people a
spreadsheet containing personal information on over 3,700 students, alumni
and supporters.

Details are available at http://bostonballetschooldatabreach.blogspot.com/.


Date: Mon, 13 Jul 2009 18:07:09 -0700
From: Gene Wirchenko <genew_at_private>
Subject: Risks of the Cloud: Liquid Motors

Company Caught in Texas Data Center Raid Loses Suit Against FBI

The first four paragraphs are a good synopsis.  In particular, note
paragraph three.

'A company whose servers were seized in a recent FBI raid on Texas data
centers applied for a temporary restraining order to force the bureau to
return its servers, but was denied by a U.S. district court last week.

The company, Liquid Motors, provides inventory management and marketing
services to national automobile dealers, such as AutoNation. It was one of
about 50 companies put out of business last week when the FBI seized the
servers at Core IP Networks, one of two
<http://blog.wired.com/27bstroke6/2009/04/data-centers-ra.html> data centers
and co-location facilities raided by the FBI’s Dallas office in the last
month in an investigation into VoIP fraud.

Although Liquid Motors was not a target of the investigation, the FBI took
all of the company's servers and backup tapes in the raid.

"As a result, Liquid Motors, Inc. has been put out of business and is in
breach of its contracts with automobile dealers throughout the country," the
company wrote in its application for the restraining order (.pdf). "Those
automobile dealerships may hold Liquid Motors responsible for all of their
lost business, and may terminate their contracts with Liquid Motors, causing
permanent and irreparable harm -- for which there is no adequate remedy at

  [Cloud Computing of course raises some enormous security and privacy
  issues, especially in having to trust untrustworthy third parties... PGN]


Date: Sun, 28 Jun 2009 20:13:03 -0400
From: Paul Wallich <pw_at_private>
Subject: Facebook fraud about to get more interesting?

A friend's facebook account was hacked recently (a neat little short-term
scam of contacting friends by FB chat, claiming to have been robbed in a
foreign country and needing money wired) and it got me to thinking about
possible interactions between Facebook's security and plans to open
user-generated content to public search and aggregration.

Scams that involve impersonating someone in a medium such as e-mail or chat
are necessarily fairly low-volume. Impersonations seen only/mostly by a
computer scale much better. So when people talk about the possibility of
selling data-mined analyses for content from facebook for marketing or other
purposes, fraudulent ways to manipulate the underlying data may become
attractive. If someone could use Facebook security holes to fake posts,
comments, fanhood, cause-joining and so forth, their clients could profit
when the misinformation shows up in the data-mining stream (and the
data-mining stream could become significantly less valuable).

As with spamming services, fraudsters wouldn't actually have to generate
profits for their customers, just the perception that hijacking facebook
identities wholesale would be a good idea...


Date: Sat, 04 Jul 2009 10:01:56 +0800
From: jidanni_at_private
Subject: Taiwan man rescued after getting lost via GPS

East Branch of the police force to remind the public that although the
satellite navigation to find a way to save time, the public or in front of
the first re-start done its homework in order to avoid disappointed and go
out to the ages.

No kidding :-)


Date: Wed, 8 Jul 2009 2:33:30 PDT
From: "Peter G. Neumann" <neumann_at_private>
Subject: July 4 Fireworks cyber-attack

Federal agency Web sites knocked out by massive, resilient cyber attack
[Source: Lolita C. Baldor (Associated Press), 7 Jul 2009; thanks to
Marv Schaefer]


A widespread and unusually resilient computer attack that began on 4 Jul
2009 knocked out the Web sites of several government agencies, including
some that are responsible for fighting cyber crime.  The Treasury
Department, Secret Service, Federal Trade Commission and Transportation
Department Web sites were all down at varying points over the holiday
weekend and into this week, according to officials inside and outside the
government. Some of the sites were still experiencing problems Tuesday
evening. Cyber attacks on South Korea government and private sites also may
be linked.  U.S. officials refused to publicly discuss details of the cyber
attack.  But Amy Kudwa, spokeswoman for the Homeland Security Department,
said the agency's U.S. Computer Emergency Readiness Team issued a notice to
federal departments and other partner organizations about the problems and
"advised them of steps to take to help mitigate against such attacks."

  [Vireworks? Vir-works? Pyreworks? Ireworks? PGN]


Date: Thu, 16 Jul 2009 9:13:58 PDT
From: "Peter G. Neumann" <neumann_at_private>
Subject: Twitter Attack Raises Flags on Security

Someone hacked into a Twitter employee's e-mail account, which apparently
led to Twitter execs realizing that their system is not very secure.  (A
Sophos study from last year is quoted, claiming 40% of web users use the
same password on multiple sites, increasing their vulnerabilities.)
[Source: Claire Cain Miller and Brad Stone, *The New York Times*, 16 Jul
2009; PGN-ed]


Date: Thu, 16 Jul 2009 08:18:15 -0400
From: Monty Solomon <monty_at_private>
Subject: Teenager Falls Into Manhole While Texting

Michael Barkoviak - July 13, 2009 7:46 AM

A teenager walking along the streets in Staten Island recently suffered an
embarrassing mistake when she walked into an open sewer while sending text
messages on her cell phone.  Alexa Longueira, 15, suffered deep cuts and
bruises after she fell through a manhole that was uncovered and reportedly
left unattended.  Two New York City Department of Environmental Protection
workers were planning on flushing the sewer, left the manhole cover off, and
walked away without putting up a warning sign or orange cones. ...


Date: Wed, 15 Jul 2009 01:06:47 -0400
From: Monty Solomon <monty_at_private>
Subject: When Texting Is Wrong

Randy Cohen, The Moral of the Story - The Ethicist's take on the news:
When Texting Is Wrong, *The New York Times*, 13 Jul 2009

The Issue:

You're having dinner with your teenage kids, and they text throughout: you
hate it; they're fine with it. At the office, managers are uncertain about
texting during business meetings: many younger workers accept it; some older
workers resist. Those who defend texting regard such encounters as the clash
of two legitimate cultures, a conflict of manners not morals. If a community
- teenagers, young workers - consents to conduct that does no harm, does
that make it O.K., ethically speaking? ...



Date: Thu, 9 Jul 2009 09:17:18 -0700
From: Denise Caruso <caruso_at_private>
Subject: TV station forced to go old school after fire

This is a little late as I just read it in a friend's Facebook update, but I
thought you should see it.


For some reason, the photo makes me smile every time I look at it. I think
it's the flag and the fireworks. You don't often get to see images on TV
that look like someone actually made them. Like, arts-and-crafts made
them. Kinda sweet.

I'm not sure what you'd file it under -- the risks of operations in formerly
cool climes being unprepared for heat spikes? -- but certainly it's a case
study for why drawing and painting should continue to be taught in school!


Date: Mon, 6 Jul 2009 15:43:49 -0400
From: "Steven M. Bellovin" <smb_at_private>
Subject: Re: More on the DC Metro collision 22 June 2009 (Thompson, R-25.71)

David Lesher notes, when speaking of the train not showing up, that "the
above is exactly what 100+ years of railroad signaling supposedly makes
impossible."  True -- but there's another layer here that might play
either way: the computerized control system.

Yes, the circuitry is supposed to be designed so that failures always
result in a "train present signal.  Why there was a failure that could
do the opposite is an important question.  But what about the
computer?  Did it misprocess some analog signal?  There's clearly a
logic failure, since it let a train disappear.  If there's a train in a
given spot at time T, at time T+delta, there is only a short stretch of
track where it can be.  Surely a computerized system should be able to
take that into account, and mark all of the blocks occupied until it
reacquires the train's location.  A simple system -- one that just
emulated the old relay-based logic -- might not have that ability,
since it would be stateless, but the DC Metro system's train-tracker is
almost certainly stateful, since it's operating location displays and
time of arrival displays at every station.  What happens to the state
object when a train vanishes?  Is it silently deleted?  Does the train
simply become invisible?  Is there a memory leak?  The first two, in my
opinion, are a definite safety bug.

Steve Bellovin, http://www.cs.columbia.edu/~smb


Date: Mon, 06 Jul 2009 14:47:14 -0500
From: Rick Dickinson <rtd_at_private>
Subject: Re: More on the CD Metro collision (Stangenberger, RISKS-25.72)

Taking as given that some (supposed to be all?) track sections have train
detectors that can identify specific trains, it's easy to think of at least
two ways to keep track of which trains are where within the system:

1) Poll each track section periodically to see which trains it currently
   sees, or
2) For each train, maintain a list of the last track section (or last few
   sections) where it was seen.

Option 1 runs into difficulty as soon as you have a faulty detector anywhere.
Option 2 may report a train being on an adjacent section if you have a
faulty detector, but it will never show *no train*.

It appears that the train control system in this case used some variation
of Option 1.

The RISK?  Failing to plan for graceful degradation in the event of sensor
failure.  Reporting the stalled train in a slightly incorrect position along
that track would have certainly been preferable to having it simply
"disappear" from view entirely, and might have saved some lives.


Date: Tue, 14 Jul 2009 00:56:35 -0400
From: wb8foz <wb8foz_at_private>
Subject: Re: More on the DC Metro collision 22 June 2009

The National Transportation Safety Board today issued an urgent safety
recommendation to the Washington Metropolitan Area Transit Authority (WMATA)
calling for enhanced safety redundancy of its train control system.  "The
accident has shown that the train control system is susceptible to a single
point failure because it did not fail safe and stop the following train when
train detection was lost."  It called upon WMATA to install software such
that the higher level Supervision system would in effect, observe and track
train positions, and if/when a train "vanishes" from the basic ATP's view;
raise an alarm.  It also issued a broader recommendation to the FRA:

"Advise all rail transit operators that have train control systems capable
of monitoring train movements to determine whether their systems have
adequate safety redundancy if losses in train detection occur. If a system
is susceptible to single point failures, urge and verify that corrective
action is taken to add redundancy by evaluating track occupancy data on a
real-time basis to automatically generate alerts and speed restrictions to
prevent train collisions.  (R-09-7) (Urgent)"

Some early comments/observations/speculations:

The basic reason NTSB's said what they did appears to be that they simply do
not [yet...] know why/how the track circuit failed, or how to predict when
other failures may happen. The failure was replicable for several days but
now is not.

0) WTH ?!%^&*%^??? "Failsafe" track block signals go back to 1872. AC track
circuits are newer but still were around to see the Cubbies win the World

1) No such product as NTSB wants exists at present; WMATA can't just slap
cash on a vendor's palm and walk away with a fragulator to install. They are
already dealing with the vendor of their current ATS platform to create

2) The ATP runs on railroad standard components [vital relays, etc...]. The
ATS system now runs on Windows.

3) But the ATP unquestionably failed in a way that Just Can't Happen. So is
a secondary system that also relies on Windows a step back or going ahead?

4) The 'bright line' border between ATP and systems above is already fuzzy
in places; the higher-level stuff relies on ATP, for example.

5) Seldom does a major safety disaster have a single cause; this is no
exception. Train 214 was stopped short of the Ft. Totten platform because
there had been a breakdown 10-15 miles ahead, at Friendship Heights
station. They were using another train to push the dead one out of the

6) Thus far there is no smoking gun. [Someone whose sole job it was to
constantly watch that track circuit but was instead texting etc; a safety
switch jumpered across, etc....]. Yes, the ops center might have noticed the
disappearing train 214, but it's a busy place, especially with #5 going on.

7) An obvious issue will be building a system that does NOT cry wolf
multiple times a day. Metrorail moves a lot of people every rush-hour, and
repeated line shutdowns will not be well-received.

8) There's a RISKS textbook sure to be written re: the whole saga.


Date: Sat, 11 Jul 2009 8:55:27 PDT
From: "Peter G. Neumann" <neumann_at_private>
Subject: Saltzer-Kaashoek Computer System Engineering book finally published

Jerry Saltzer and Frans Kaashoek have been turning the class notes that have
evolved over the past 40 years for M.I.T. subject 6.033 Computer System
Engineering into a book.  They have now concluded the effort.  The first six
chapters have been published by Morgan Kaufman as *Principles of Computer
System Design*:

  1. Systems
  2. Elements of Computer System Organization
  3. The Design of Naming Schemes
  4. Enforcing Modularity with Clients and Servers
  5. Enforcing Modularity with Virtualization
  6. Performance

The remaining chapters 7 through 11 are posted online with a Creative
Commons license as part of MIT's OpenCourseWare:
This material should be of considerable interest to RISKS readers, who will
find some familiar cases -- including pithy examples on network protocols
(Chapter 7), fault tolerance (Chapter 8). atomicity (Chapter 9), consistency
(Chapter 10), and security (Chapter 11).

Chapter 11, Information Security, is particularly relevant here, including a
modernization and reworking of the formative 1975 Saltzer-Schroeder paper
that included widely cited security principles.


Date: Wed, 24 Jun 2009 22:42:36 +0200
From: Toby Douglass <trd_at_private>
Subject: Paypal accounts

I recently came to buy a pair of clip-on LED lamps.  The merchant supported
only VISA card payment via Paypal.  In 2004, much against my will, I opened
a Paypal account.  I knew then with the exquisite clarity of foretelling how
much pain it would bring into my life.

At the time, I lived in the UK, with a UK bank account and a UK address for
my VISA card.

I now live in the Netherlands and while retaining my UK bank account to
retain a VISA card (VISA doesn't really exist in the Netherlands) I now have
a Dutch address for the card.

Paypal *insists* on retaining your card address in an account (rather than
letting you enter it when paying) and so I needed to update my card address
so I can pay.  I manage to remember both my old e-mail address and password
and log into Paypal.

*Turns out you cannot change the country of your account.*

Paypal is a credit card billing processor who require the card address to be
stored in an account but do not permit the country to change.  I may be
wrong, but this seems an amazing design flaw.

So I couldn't pay and canceled the order.  A risk here is the silent loss
of business due to apparently broken intermediation systems.

However, I was then curious why this was so.  I contacted Paypal.

The exchange of e-mails that ensued is a wonderful thing, proving - as if
proof were needed - that with the correct use of incentives, rational,
sentient creatures wonderfully evolved over millions of years can be reduced
to drooling imbecility.

The dialog so far has been thus;

Me: 'Why can I not change the country in my Paypal account?'
PP: 'Be aware you cannot change the country in your account.  You must
    set up an account for each country you live in.'

Me: 'Isn't that an awkward way to change the country?'
PP: 'It's a security measure.  If people can have multiple accounts per
     country, they could use it for fraud.'

Me: 'But they can create multiple accounts anyway, just by making them.
    [Anyway, how does having multiple accounts permit fraud?']
PP: 'All computers have an IP address.  Paypal only permits users to
    log in from the computer they created the account from.  It's a security

Me: 'You reply is totally factually incorrect and completely irrelevant
    in every way to my previous question.'
PP: 'Having carefully reviewed your concern, and I see you would like
    to know if you use your Paypal account on multiple computers.  You can.'

Me: 'That was not my question.  I want to know why I can't change the
    country in my account.'
PP: 'Be aware you cannot change the country in your account.  You must
    set up an account for each country you live in.'

Suddenly, the inability to change country all made sense.


Date: Tue, 23 Jun 2009 19:55:27 +0100
From: "Dirk Fieldhouse" <fieldhouse_at_private>
Subject: SPAM: Phishing - the state of the art?

I received two e-mail messages purporting to be from Abbey National, a UK
bank that is a subsidiary of Banco Santander.

Both were flagged as spam. As I have some sort of relationship with this
company (unlike, say, Wells Fargo, a popular phishing target), I
investigated further. Here's what Abbey's web site says:

"Important warning about Internet banking fraud

Customers of several UK banks have recently been the target of a fraud which
uses fake e-mails to encourage customers to enter their card or security
details into a counterfeit copy of their website. Abbey will never send you
an e-mail asking you to enter, reconfirm or change your security
details. ..."

That sounds good. Let's see if it's true ...

Message #1, "*** IMPORTANT *** Ensure The Safety Of Your Online Banking
Account", was a clear phisher, a multipart message with a text/plain
repeating the subject and text/html containing a 'security notice' with a
supposed login link to Abbey, actually to 185.143.broadband7.iol.cz.

"Dear Abbey National online account holder,

This is an important message from the Abbey National Security Centre and
has been issued due to a recent upgrade of our secure servers. All current
customers are required to update their personal details by simply logging
into their online banking accounts.

For security reasons, your access to sensitive account features has been
limited until your details are updated on our servers. However, failure to
update your details will further lead to a temporary restriction of your
online access.

Update your account now in just one easy step, click the "Log On" link
below and enter your personal login details to restore your access and
enjoy the benefits of online banking and finance avoiding fra

<Log On>

Apart from the fragmentary paragraph preceding the phish-hook, this is
really quite good, reasonably grammatical and plausible enough unless you
happen to see the actual link behind the 'Log On' hyperlink. It certainly
wouldn't be the first time a company had used some external service to send
its e-mail, so the fraudulent From: address nxqbpf_at_private is nicely
constructed, the choice of MessageLabs adding a further glint of security.

Now message #2.

"From: "Abbey National" <noreply_at_private>
Subject: Security
Date: Tue, 23 Jun 2009 02:36:14 +0100

Important Information

In order to make your online experience even more secure we have introduced
a new security feature that allows us to detect unusual activity on your
online account. If we detect unusual activity, we will call you to make sure
that it's really you.

As a result, we need you to visit our online service site by following the
reference given below and provide your urgent phone number where you can
be reached anytime during the day.

<For banking with a higher level of security, please click here.>

How does it work?

If we detect a sign in with your user name from another country we may
decide to confirm that it's really you. You must provide your urgent phone
number within 2 weeks from receiving this e-mail otherwise you will not be
able to use the online service until we contact you and complete additional
security checks. This can be avoided simply by following our online service
link above. ..."

Is this is a real attempt by the bank to find my phone number?

If it is, see effectively how they have simulated a phishing e-mail by

* not including the customer's name in the text;

* using slightly unnatural English phrases like "your urgent phone
  number", "anytime" and "otherwise" as a conjunction;

* actually including a banking login link in HTML mail, for heaven's sake;

* using three pointlessly different top-level domains (abbey.com,
  abbeynational.co.uk, abbey.co.uk) in one communication.

On the other hand the security system that's proposed sounds all too
plausibly like something that a retail bank might propose: apparently when I
try to maintain my Abbey account from abroad, Abbey will phone my number,
not be able to contact me (since I am away), and consequently prevent me
from maintaining my account. So I might as well have stayed with telephone
banking, then.

Most weirdly the login link is to
which is just the same as I get at www.abbey.com (which in turn is linked
from www.santander.com).

But the SMTP headers look extremely phishy: instead of an Abbey server the
initial sender is

Received: from User ([])        by SHOPWEB.PCSECURITYSHIELD.COM

And http://www.ip-db.com/ indicates that User is a cable modem
in Regina, Saskatchewan, which is a pretty unlikely outsourcer for Abbey.

So is this really a new turn in the phishing war -- a psych-ops attempt to
disprove the bank's credibility and possibly increase the hit-rate of
future phishery like message #1?

Or did the phisherman just incorrectly bait the hook by forgetting to
change the domain part of the link?

At least the ObRisk of e-mail messages with embedded links can only be
restated. Always navigate to secure sites manually using a trusted domain
name that you found outside the e-mail.

Dirk Fieldhouse, London,UK


Date: Wed, 08 Jul 2009 15:32:39 -0400
From: "D.F. Manno" <dfmanno_at_private>
Subject: Re: Bozeman (RISKS-25.71)

Andrew Koenig asked what would happen if a prospective employer were to
require all applicants to sign a contract that assigns the applicant's
fourth-amendment rights to the employer as a condition of consideration for
employment, specifically whether said employer could require said applicant
to agree to give the company power of attorney to authorize police searches
of your home and possessions in exchange for the company looking at your job

The Fourth Amendment applies only to governments. Absent a specific law to
the contrary, a private employer could demand the right to search an
applicant's (or employee's) home and possessions. The applicant's recourse
is to refuse the job, the employee's is to quit.

(By the way, the police will not search a premises solely at the request of
a private employer, no matter what powers of attorney have been signed.
Without a warrant, police can't conduct searches, with a few specified

Since the City of Bozeman is a government, the Fourth Amendment does apply
and it could be enjoined from enforcing such a contract provision.  With
media reports indicating that it has backed off the original provision
regarding online accounts, it appears that the policy will not be tested in
court, making its constitutionality moot.


Date: Mon,  6 Jul 2009 15:05:16 -0400 (EDT)
From: msb_at_private (Mark Brader)
Subject: Re: Bozeman (Koenig, Risks-25.72)

The difference is that in the Bozeman case, they would *additionally*
be giving the employer power of attorney to *impersonate* them.
If I give you my password, you don't just get read access to my files!

Mark Brader, Toronto, msb_at_private | "Well, *somebody* had to say it."


Date: Wed, 08 Jul 2009 13:33:44 -0700
From: Ulf Lindqvist <ulf.lindqvist_at_private>
Subject: Oakland 2010, IEEE Symposium on Security and Privacy, CFP

I am happy to let you know that the Call for Papers for the 31st IEEE
Symposium on Security and Privacy ("Oakland 2010") is now available.
      31st IEEE Symposium on Security and Privacy - Call For Papers

Important Dates (all deadlines are 23:59 PST)

    Workshop proposals due: Friday, 21 August 2009
    Research papers due: Wednesday, 18 November 2009
    Systematization of Knowledge papers due: Tuesday, 24 November
    Acceptance notification: 1 February 2010
    Final papers due: 1 March 2010

Since 1980, the IEEE Symposium on Security and Privacy has been the
premier forum for computer security research, presenting the latest
developments and bringing together researchers and practitioners.

We solicit previously unpublished papers offering novel research
contributions in any aspect of computer security or privacy. Papers may
present advances in the theory, design, implementation, analysis,
verification, or empirical evaluation of secure systems.  S&P is
interested in all aspects of computer security and privacy.  Papers
without a clear application to security or privacy, however, will be
considered out of scope and may be rejected without full review.

*Systematization of Knowledge Papers*.  In addition to the standard
research papers, we are also soliciting papers focused on
systematization of knowledge. The goal of this call is to encourage work
that evaluates, systematizes, and contextualizes existing knowledge.
These papers will provide a high value to our community but would
otherwise not be accepted because they lack novel research
contributions. Suitable papers include survey papers that provide useful
perspectives on major research areas, papers that support or challenge
long-held beliefs with compelling evidence, or papers that provide an
extensive and realistic evaluation of competing approaches to solving
specific problems. Submissions will be distinguished by a checkbox on
the submission form. They will be reviewed by the full PC and held to
the same standards as traditional research papers, except instead of
emphasizing novel research contributions the emphasis will be on value
to the community. Accepted papers will be presented at the symposium and
included in the proceedings.

*Workshops*.  The Symposium is also soliciting submissions for co-located
workshops.  Workshop proposals should be sent by Friday, 21 August 2009
by e-mail to Carrie Gates (carrie.gates_at_private).  Workshops may be
half-day or full-day in length.  Submissions should include the workshop
title, a short description of the topic of the workshop, and biographies
of the organizers.

See the full CFP at
for more information including detailed submission instructions.


Date: Thu, 29 May 2008 07:53:46 -0900
From: RISKS-request_at_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:
 Alternatively, to subscribe or unsubscribe via e-mail to mailman
 your FROM: address, send a message to
 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_at_private or risks-unsubscribe_at_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.
 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_at_private>.
=> SPAM challenge-responses will not be honored.  Instead, use an alternative
 address from which you NEVER send mail!
=> SUBMISSIONS: to risks_at_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 for current volume
     or ftp://ftp.sri.com/VL/risks for previous VoLume
 <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
==> Special Offer to Join ACM for readers of the ACM RISKS Forum:


End of RISKS-FORUM Digest 25.73
Received on Thu Jul 16 2009 - 14:28:47 PDT

This archive was generated by hypermail 2.2.0 : Thu Jul 16 2009 - 15:26:21 PDT