RISKS-LIST: Risks-Forum Digest Thursday 16 July 2009 Volume 25 : Issue 73 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/25.73.html> The current issue can be found at <http://www.csl.sri.com/users/risko/risks.txt> Contents: 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 (http://www.cnn.com/2009/US/07/15/quadrillion.dollar.glitch/index.html). 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] http://www.cnn.com/2009/US/07/15/quadrillion.dollar.glitch/index.html http://blogs.usatoday.com/ondeadline/2009/07/man-racks-up-23-quadrillion-bill-at-the-gas-pump.html ------------------------------ 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] http://www.h-online.com/security/Loss-of-data-has-serious-consequences-for-German-electronic-health-card--/news/113740 ------------------------------ 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 http://www.wired.com/threatlevel/2009/04/company-caught/ 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 <http://www.wired.com/images_blogs/threatlevel/files/Liquid_Motors_v_Lynd.pdf> 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 law."' [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. http://translate.google.com/translate?u=http%3A%2F%2Ftw.myblog.yahoo.com%2Fjw!g_pKUviaAxDWs.F9XXuQMb0y%2Farticle%3Fmid%3D4439&sl=zh-TW&tl=en 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] http://finance.yahoo.com/news/Federal-Web-sites-knocked-out-apf-2773092122.html?x=0&.v=3 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. ... http://www.dailytech.com/article.aspx?newsid=15661 ------------------------------ 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? ... http://ethicist.blogs.nytimes.com/2009/07/13/when-texting-is-wrong/ ------------------------------ 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. http://www.techflash.com/TV_station_forced_to_go_old_school_after_fire_at_Seattles_Fisher_Plaza_49893982.html 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)" <http://ntsb.gov/Pressrel/2009/090713.html> 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 Series.... 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 same. 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 station. 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: http://ocw.mit.edu/Saltzer-Kaashoek 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 measure.' 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> To: Cc: 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 https://myonlineaccounts2.abbeynational.co.uk/CentralLogonWeb/Logon?action=prepare 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 ([24.72.38.106]) by SHOPWEB.PCSECURITYSHIELD.COM And http://www.ip-db.com/24.72.38.106 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 application. 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 exceptions.) 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 http://oakland10.cs.virginia.edu/cfp.html 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: 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_at_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_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. <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_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: <http://www.acm.org/joinacm1> ------------------------------ 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