Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
(slightly edited/reformatted for clarity) http://www.law.com/jsp/nylj/PubArticleNY.jsp?hubtype=TopStories&id=1202422872356 Mark Hamblett, Mistaken Identity in Civil Rights Lawsuit Bronx [NYC] resident William Hallowell filed suit in the Southern District yesterday claiming police and prosecutors blundered by wrongfully arresting him for an e-mail he never sent. Mr. Hallowell was working part time at the Riverdale Country School Library in April 2007, and exchanging e-mails about the return of a library key with his supervisor, Robin Berson, when Ms. Berson inadvertently typed the wrong e-mail address - to a Ben Hallowell. She received in return an unsigned e-mail saying the recipient had sold the key for "hookers," a "handful" of drugs and a gun. The writer also professed his desire for Ms. Berson and proposed a sexual liaison in the library. The lawsuit alleges that, on a complaint from Ms. Berson, New York City police, "Despite the obvious lack of evidence against him," arrested William Hallowell and held him for more than 30 hours. The complaint, charging false arrest and malicious prosecution, states, "Determined to make an arrest, any arrest, defendants bluntly violated Mr. Hallowell's rights by turning a blind eye to the overwhelming evidence of his innocence," and blames prosecutors for waiting for four months to dismiss the case. The Bronx County District Attorney's Office declined comment.
San Francisco IT worker arrested in hijacking of city network, CNET <http://news.cnet.com/8301-1009_3-9991769-83.html?part=rss&subj=news&tag=2547-1_3-0-20> A disgruntled city worker is in jail on $5 million bail after allegedly locking other administrators out of the city's wireless network. The Risk? The same one the Intelligence Community faces daily: the people often are the problem... [Jim Horning noted "S.F. officials locked out of computer network" in the *San Francisco Chronicle*. PGN] <http://www.sfgate.com/cgi-bin/article.cgi?f=/c/a/2008/07/14/BAOS11P1M5.DTL>
Potential risks in preprogrammed emergency message systems: About 2,000 State Farm employees spent almost two hours Thursday afternoon in the lower level of the company's corporate headquarters [in Bloomington, Illinois] after a passer-by reported seeing a man with a "long gun" outside the building. A preprogrammed tornado announcement sent people to the lower level when the company had intended to send out an emergency warning. Police eventually determined the person actually saw a custodian holding what probably was a pipe. [Source: Pantagraph.com State Farm, police pleased with response to security threat; see link for full article and some further risks. PGN] http://www.pantagraph.com/articles/2008/07/08/news/doc487256756564f585165529.txt
Mr Justice Stephen Breyer was apparently among the over 2000 people affected by a personal data breach caused when an employee of a financial services firm installed Limewire on a computer he used for work, was careless about how he configured it, and shared some directories containing the data in question. Brian Krebs' piece in *The Washington Post* [1] missed both of the important points; the one I made above in how I (correctly) characterized what (probably) actually happened — not glossing over the fact that p2p servent software is not inherently black-hat, as the piece encourages the reader to assume — and the other one, covered by the comment I posted, which I reproduce here: I'm more than a little bit disappointed that this piece fails to mention the root cause of *why* this breach bothers so many people — because the last clear chance to avoid it did not happen when the file sharing program was installed. It happened when AT&T, and the credit card companies, and whosoever, saw fit to treat as *authenticators* the mere knowledge of birthdates and SSNs. That someone knows my bday, or SSN, *does not prove they're me*, and this problem will not go away until large corporations cease acting as if it does... which is a point privacy activists have been making loudly in public places since at least 1992 that I know of, and likely longer. If you want to authenticate me, do a better job. And don't make *me* responsible for paying to deal with the consequences of you not being smart enough to do so. That's my manifesto. Maybe if enough other people say it too, loudly, it will stop. This is why I customarily refuse to give out my SSN. This is not an idea original to me, of course, and I originally stole it either from RISKS or from Lauren Weinstein's Privacy Forum, to which I've CC:ed this message. But the risks here are multiple, and subtle (at least to some :-), so I'll enumerate them: 1) Thinking that p2p software is all inherently bad because a) a p2p servent producer picked a bad default and a non-savvy user accepted it. 2) Blaming the subsequent breach on p2p software inherently, and painting it as a bad thing — when indeed several major companies are developing legit p2p distribution networks for various things. 2a) The fact that so many supposedly technology-centric reporters miss the most important points on stories where technology intersects with society and the law — which is most of them these days, right? 3) Blaming the breach on even the bad guys, when the root cause is an excrescently poor process design decision on the part of the good guys, to wit: choosing to use, as absolute proof that an applicant is who they claim to be, the fact that they know a birthdate, SSN, mother's maiden name, or city of birth. Just as with reusable password security: one of the reasons you use different passwords for different services (or at least, different security classes of service) *is because you can't trust the operator of the service not to leak them*. Well, this is worse: just like with biometrics, *you can't change the things these companies are asking for*. And nowadays, you can't even lie about them, since apparently, violating the terms of service of a *free* website is a felony[2]. Does anyone see any reasonable way out of this conundrum? 'Cause I don't. [1] http://www.washingtonpost.com/wp-dyn/content/article/2008/07/08/AR2008070802997.html [2] http://www.secureworks.com/research/falsepositive.php Jay R. Ashworth, Ashworth & Associates, St Petersburg FL USA +1 727 647 1274 http://baylink.pitas.com
MIT's *Technology Review* has an article "Plug and Play" Hospitals: Medical devices that exchange data could make hospitals safer. Just the title is enough to excite my "oh yeah?" reflex. <http://www.technologyreview.com/Biotech/21052/?a=f>. The body of the article focuses entirely on the benefits of the new technology. Speaking of the ventilators, which are potentially life-preserving, it says the following without even a hint that there may be a risk: Goldman says that as a result of his demonstration, standards for ventilators are in the process of being revised so that future versions of the devices will include a pause function and will be subject to network control, moving toward interoperability. Don't hold your breath. [What about the nurse who takes a nap on the remote controller? And of course the veterinarian in the missing L-wing is "Pug and Pay". PGN]
http://tech.slashdot.org/article.pl?sid=08/07/16/2220232&from=rss "Have you ever wanted to know the name of admin@gmail.com? Now you can. Through a bug in Google calendars the names of all registered Gmail accounts are now readily available. All you need to find out the names of any gmail address is a Google calendar account yourself. Depending on your view this ranges from a harmless "feature" to a rather serious privacy violation. According to some reports, spammers are already exploiting this "feature"/bug to send personalized spam messages."
Opening paragraphs: "If you're using encryption software to keep part of your computer's hard drive private, you may have a problem, according to researchers at the University of Washington and British Telecommunications. They've discovered that popular programs like Word and Google Desktop store data on unencrypted sections of a computer's hard drive — even when the programs are working with encrypted files." http://www.itbusiness.ca/it/client/en/home/News.asp?id=49190
This morning, I received an e-mail message purporting to be from UPS (I have an account at ups.com) and reading in part as follows: *Attention Virus Warning* We have become aware there is a fraudulent e-mail being sent that says it is coming from UPS and leads the reader to believe that a UPS shipment could not be delivered. The reader is advised to open an attachment reportedly containing a waybill for the shipment to be picked up. (I'm sure we've all seen the spam to which the warning is referring.) My full name is not mentioned anywhere in the message. The numerous links in the message are all encrypted query strings and point at rm04.net rather than ups.com. The e-mail header contains a bunch of randomized garbage (for example, the envelope address looks like this: v-dj_dklajdn_ndk_jccfkkddpdkkkkhkbk_@bounce1.rm05.net), and ups.com doesn't appear anywhere in it. I'm savvy enough to know that this is /probably/ a legitimate e-mail message from UPS, but a savvy attacker could craft a message that looks exactly like this one, so I'm also savvy enough to know not to be foolish enough to click on any of the links. On the other hand, checking out the links with lwp-request (a Perl command-line HTTP client) is safe enough. I checked the "Privacy Policy" link, and it redirects to http://www.ups.com/content/us/en/privacy.html, so at least one of the encrypted links in the message is legitimate. In this day and age, it is amazing to see a corporation as large as UPS failing to use the two easiest and most well-known methods of differentiating legitimate e-mail from scams — put the customer's name in the e-mail, and make sure that all the links point directly at your site. Are there any RISKS readers with connections inside UPS to whose attention they might bring this matter?
[quoting from <http://isc.sans.org/diary.html?storyid=4729>:] DR/BCM lessons from the Vancouver fire Published: 2008-07-14 by Daniel Wesemann (Version: 1) An fire in an underground power distribution room today knocked a good portion of Vancouver's inner city power grid offline. Several news media like the Vancouver Sun are carrying the story by now. As bad as this event is on its own, the e-mail provider Hushmail reports on its web page some additional interesting details. What happened, apparently, was that Vancouver's "Harbour Centre" web hosting location brought their emergency generator successfully online when the power dropped. But as soon as the fire department started drawing massive amounts of water in their attempt to contain the fire, the water pressure in the mains was reduced to a level where the (water cooled) emergency generator couldn't operate any more. Poof. Darkness. Now, let me guess how many BCM/DR plans out there didn't think of that one... Time to update!
After additional research, this particular error may not be a conversion error at all, but a more classical error. Apparently, the "Gap" fire was originally reported to have started at the "Gap", which does indeed reside at the original coordinates close to Highway 154. However, this original report was in error, so the naming of the "Gap Fire" after the "Gap" was actually a misnomer. Unfortunately, once the fire had been named the "Gap Fire", it would have been even more confusing to change its name, so the name has stuck, even though (so far) the fire hasn't come near the actual "Gap". This naming error is entirely analogous to the naming of mathematical theorems, very few of which are named after their actual/original discoverors.
Fortunately, InciWeb is not part of the command and control system for fighting fires, but is an informational database which attempts to supply information on incidents nationwide. Hence the consequences of an error in location of a fire are not catastrophic. However, InciWeb has been plagued by instability (possibly server overload) during the California fire emergency of the past couple of weeks. As I write this, the Plumas National Forest has set up a Google group to release information on the Canyon Complex of fires in a timely fashion. From the PNF homepage: "Due to the unstable nature of InciWeb, updated information about the Canyon Complex can temporarily be found here [URL for the Google group]". Al Stangenberger, Univ. of California at Berkeley, Center for Forestry 145 Mulford Hall # 3114 1-510-642-4424 Berkeley, CA 94720-3114
On day 3 of the new law, we were speculating whether forcing people to use headsets would have the effect of encouraging people to talk longer, increasing overall risk. During our discussion, a friend called to say she'd be late. While fumbling for her headset she had hit a curb and blown a tire.
The *Los Angeles Times* is reporting that the city is using $16,000,000 of "anti-terrorism" money to install faregates on their rail lines. Both Los Angeles Mayor Antonio Villaraigosa and state Homeland Security Advisor Matthew Bettenhausen said the turnstiles will enhance security at the rail lines, as well as stop fare jumpers, although a transportation security expert said the gates by themselves will have only a nominal effect on stopping potential terrorist attacks. Of course, someone, in this case Don Surber of the Charlston Daily Mail, HAD to mention the "Gov. William J. Le Petomane Thruway" <http://blogs.dailymail.com/donsurber/2008/07/16/turnstiles/> approach. Why am I reminded of "Terrorists Can't Type" yet again? RISK 1: Throw enough money into the air, and it's amazing how many problems shall appear that need it... for some value of "need"... RISK 2: With enough RISK 1's, and the fighting over the spoils that results; real honest-to-gosh threats can be, well, lost in the dust.
Firefox 3's Step Backwards For Self-Signed Certificates
http://lauren.vortex.com/archive/000402.html
Greetings. If you've switched over to Firefox 3 as your Web browser already
-- and in general it's a fine upgrade — you may at some point discover that
rather than encourage (or at least not overly discourage) the use of
self-signed security certificates, Firefox 3 makes it *less* likely that
anyone other than an expert user will ever accept a self-signed certificate.
This is particularly of concern to me since I've urged an expansion of
self-signed certs deployment as a stopgap measure toward pervasive
encryption ( http://lauren.vortex.com/archive/000339.html ).
Compared with Firefox 2, version 3 throws up so many barriers and
scary-sounding warnings to click through to accept such certs, that it would
be completely understandable if most persons immediately aborted.
What's going on is that Firefox is now putting so much emphasis on identity
confirmation that it's making it even harder for people to use the basic
encryption functionality of the browser, which works just fine with
self-signed certificates (which admittedly are not good carriers for
identity credentials).
But in many situations, we're not concerned about identity in particular, we
just want to get the basic https: crypto stream up and running.
I am fully aware of the associated identity considerations, and I know that
basic signed certificates that will work in Firefox and some other browsers
(but last I heard not in Internet Explorer at this time) can be obtained for
free. If browser acceptance of free signed certs broadens out (and
especially if wildcard certificates also become freely available) the need
for self-signed certificates could significantly diminish.
But for now, Firefox 3 is going overboard with its complicated and alarming
warnings, which if nothing else could include improved explanatory text, so
that users would be able to better judge whether or not they should accept
any particular self-signed certificate. The current wording is unreasonably
judgmental given the range of perfectly legitimate situations where
self-signed certificates might be used.
I'm not saying to give self-signed certs the same invisible, automatic
acceptance as signed certificates, but Firefox 3 has simply gone too far
toward making self-signed certs unusable — from a practical standpoint --
in many situations where they otherwise would be completely adequate and
suitable.
Lauren Weinstein +1(818)225-2800 http://www.pfir.org/lauren
Co-Founder, PFIR and NNSquad (Network Neutrality Squad,
http://www.nnsquad.org) PRIVACY Forum - http://www.vortex.com Lauren's Blog:
http://lauren.vortex.com
The Zimbabwe government is facing a money printing crisis: the government has been able to maintain power by printing more and more money to pay the security forces. Now there is a threat to the paper supply needed to print more and more money. No computer risk there, but the last paragraph has a kicker. Besides needing paper to print more money, they use computer software to design the ever larger denominations required to keep pace with the hyperinflation, and there is a risk: "that its software license for the European banknote design technology that it uses could be withdrawn because of new sanctions threatened against the Mugabe government." http://www.sfgate.com/cgi-bin/article.cgi?f=/c/a/2008/07/15/MNR011OT0Q.DTL
The best proportional system I've come across requires ranking but doesn't seem to have been covered here so far. The voter lists all the candidates they wish to in order of preference. If you don't list the candidate, they don't count as far as your vote goes. When counting the votes, it's treated as a series of two-horse races - for each pair of candidates you count how many people list A above B, and B above A. Unless you get a very weird result (i.e., it's statistically very unlikely), one candidate will win all his individual contests. That person should be elected. Failing that, someone will almost certainly lose all his contests and should be eliminated. When they're removed from consideration the win-lose cycle can be repeated until you're left with a winner. (Effectively, you're voting FOR the people you DO want, AGAINST the people you DON'T want, and ABSTAINING for people you DON'T CARE about.)
I ran across this problem with ComCast in Harrisonburg, VA about a year ago. The Linksys router's "MAC Address Clone" feature was sufficient to fix the problem. The ethernet adapter in a PC and the ethernet "WAN Port" on a router both have a unique six byte identification known as a MAC (Medium Access Control) address. The first three bytes identify the manufacturer (i.e. Linksys), and the other three bytes identify the specific device. Default values are assigned by the manufacturer and programmed into the hardware. A "MAC Address Clone" merely allows you to change the factory assigned external MAC address on a router. Basically, ComCast's DHCP server just takes each distinct MAC address and assigns an Internet Protocol (IP address). From the pathological behavior that we've seen, I assume that ComCast programs their DHCP server to reject equipment made by Linksys, Belkin, DLink, and so on. In most consumer routers that I've worked with, the MAC Address Clone is somewhere in the advanced configuration pages of the web configuration system. It will probably default to clone the MAC address of your PC's ethernet adapter, but if not, you can get your PC's mac address from "IPCONFIG /ALL" in a Windows XP command window or the WINIPCFG program in Windows 98. If this doesn't work, I would turn off remote management, "Universal Plug and Play," and anything else that might allow the cable company to interact with your router over the network and recognize its specific behavior. Greg Fife <greg@frozenfog.com> 1-540-447-4038
> To sum up, the implication is that at the same instant that ComCast chose to > refuse to work with Firefox browsers on Win98 machines they also were > (allegedly) in collusion with Lynksys to obsolete a model of wireless > router, all scheduled to occur just in time for the July 4th holiday. ... This sounds fishy at best (albeit it's unclear where the fishiness is). At the point where you're doing DHCP negotiation, it's impossible for the ISP to know what browser you're using. It may be a little easier to know which router or other machine is attached to the cable modem, but the motivation for keeping a list of allowed and disallowed routers (especially given the possibilities for spoofing) seems unclear to me. What I do know is that customer service representatives are typically graded on their ability to get a customer off the line quickly, and if telling them "We don't support X" will do it faster than "One of our internal routers just went belly-up" then that's likely what they'll do. On the other side of the argument, ComCast is pretty much known for doing thorough inspection, aka wiretapping, of the packets its customers send out, and for sending packets that misrepresent the state of machines with which their customer is communicating. So it seems they would be perfectly capable of bollixing someone's connection in this way, with the only question being where the profit is.
The US Federal Trade Commission issued a request for comments on issues such as security and privacy of contactless payments last month, but the FTC has extended the deadline to submit comments. If you have any comments for the FTC on privacy for contactless payments, do submit ASAP. Here are the comments received thus far. http://www.ftc.gov/bcp/workshops/payonthego/index.shtml#comments http://www.ftc.gov/os/comments/payonthego/index.shtm You may submit either by e-mail or the Web form. Kevin Fu, Assistant Professor, Computer Science Department, Univ. of Massachusetts Amherst 413-545-4006 http://www.cs.umass.edu/~kevinfu/
Please report problems with the web pages to the maintainer