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…
Mac users have been crowing for some time that their system is less prone to viruses than the horrible alternative. Could this be about to change? http://www.wirednews.com/news/technology/0,1282,42586,00.html "The box contains three installation CDs — Mac OS X, Mac OS 9.1 and a CD full of developer tools, including the Cocoa programming environment, which is reportedly simple enough for school kids to use." www.pcrescue.com.au email@example.com Tel 0415 967 017 Fax: 02 9953 8772
I am deploying a custom-made server program that makes several manipulations of XML files, including an automated conversion to Word. It had been a mystery why the production server, a Pentium 700 with SCSI disks running Windows 2000, was much slower than the development server, a Pentium 500 with IDE disks. Yesterday, a particular long processing involving a 53MB RTF file just run forever. I killed it consumed after 3 hours of CPU. Then, we decided to turn off the anti-virus software. A sample task that took over six minutes now takes two and a half minutes. And the very long processing now runs in 15 minutes. Therefore, the cost of the Windows virus includes the cost of running the anti-virus software. It cripples my server to less than half its performance. My Pentium 700 becomes a Pentium 270 (usual case)! On some cases, the anti-virus software delays the computation at least 24 times, and the Pentium 700 becomes less than a Pentium 30! Linux suddenly seems a lot cheaper! Joaquim Baptista, alias pxQuim, Director, Technical Documentation firstname.lastname@example.org
In his recent (April 2001) AskTog column, Bruce Toganzzini reports on his ReplayTV which, one recent day, updated itself to disable a valuable feature. http://www.asktog.com/columns/045ReplayTV.html We saw something like this happen when Napster first tried to ban Metallica song-trading — they forced users to update to a new client which had the blocking patch installed. This is the first mass-market product (as in, people paid lots of real money for this) instance of this that I can think of. I'm certain it won't be the last. We are moving to a realm of always-on, always-connected devices. In this realm, our software will begin misbehaving without our ever doing anything to it. Alan Wexelblat, moderator, rec.arts.sf.reviews email@example.com http://wex.www.media.mit.edu/people/wex/
After a user reports his GMS handset stolen, the police start sending out one Short Message Service text message to the phone every three minutes: "This handset was nicked, buying or selling is a crime. The police." See web page story at: http://www.cnn.com/2001/TECH/ptech/03/28/SMS.bomb.idg/index.html Thomas Dzubin, Vancouver, Saskatoon, or Calgary CANADA
CNN and IDG report http://www.cnn.com/2001/TECH/ptech/03/28/SMS.bomb.idg/index.html that the Dutch police are using a kind of mailbomb technique to discourage theft of wireless phones. If a phone is believed to be stolen, police track it down with its unique identification number and send the message "This handset was nicked, buying or selling it is a crime" every three minutes via SMS. The RISK here is fairly obvious. What to do if your phone ends up mysteriously on the 'stolen' list? Go to your local police station? The phone company? Conrad Heiney firstname.lastname@example.org http://fringehead.org/
I recently sent an email to email@example.com, which was approved after being examined by the moderator. Here is the risk: Since I made the mistake of using an e-mail address from a small domain that I manage, my DNS server immediately got killed by the tens of thousands of mail servers trying to resolve my domain name.(which of course was not in anyones cache; my domain is pretty much unknown.) I saw all this traffic and didn't immediately recognize what it was. I was scared, but a little bit of investigation provided an answer. After an hour and my cable modem rebooting a few times from the sheer load, everything seemed to settle down, but I'll tell you, watching the lights on that modem flash without yet understanding what was happening sure scared me.
As RISKS readers are aware, automatic upgrades of software aren't always as innocuous as "they" would have you believe. A recent Microsoft Networks (MSN) dial-up upgrade caused some users in the Research Triangle, NC area to suddenly start dialing in via a long distance access number, as opposed to the previously local exchange. WRAL TV's consumer reporter has received 51 calls about this so far. Someone's phone bill included $361 in long distance charges to a Chapel Hill number for his Internet connection through Microsoft Networks, despite having used a local number. An MSN customer service representative told someone else that MSN "lost local numbers for several areas" during an upgrade. Several complainants had online chats where representatives insisted the Chapel Hill number was not long distance." [Source: WRAL TV online (excerpted [and PGN-ed]) http://www.wral-tv.com/features/5onyourside/2001/0329-msn-folo/] Adding additional dial-in numbers may be a good thing for a service to do. Arbitrarily changing the numbers that existing customers chose to use, without at least warning the customers first, seems rather suspect, as MSN has now discovered. Compounding the error by telling your customers that they are mistaken, while said customers are holding their long distance bills in their hands, certainly inspires confidence... Steve Holzworth, Senior Systems Developer, SAS Institute - Open Systems R&D VMS/MAC/UNIX, Cary, N.C. firstname.lastname@example.org
>Mitigation: Use RTF when you can — no hidden info, no viruses. ...unless your document includes images. Images store their pathname, even in RTF, although the ASCII characters are "hidden" as hexadecimal numbers. I have actually used this "feature" to recover the original images included in Word documents. Joaquim Baptista, alias pxQuim, Director, Technical Documentation email@example.com
We've long known the risk of course is depending on 'free' and advertiser supported services--since they are free to the user, the provider is under no obligation to continue them. Last week, EoExchange shut down their multiple advertiser-supported services they have been offering on the web for several years. These included EoMonitor (web page change monitoring better than anything else I had ever seen), EgoSurf (a name-oriented search engine) and Daily Diffs (tracked content changes across many informative sites). The real Risk here to the users was that EoExchange chose to discontinue them *without* advance notice. On Tuesday, the services were operating normally. On Thursday, the sites were inaccessible and merely forwarded to a corporate web page promoting different products. Suddenly and without warning, users of these services could no longer access the user-specific stored data they had accumulated through them. These included lists of favorite links and web sites, many of which people depended on regularly for information. The complete lack of warning meant none of the users had the opportunity to print off their personal data from the sites and preserve these lists of important sites. Adding insult to injury is the company's complete lack of an explanation, even after the fact. All users of these services simply find the URLs now redirecting to a corporate site that neither apologizes for the shutdown nor even acknowledges that these services ever existed. When I contacted the company for an explanation, I received only a vague reply that they had chosen to discontinue the advertiser-supported services and focus on their corporate solutions. So this was a not-very-subtitle reminder that when using any 'free' online services where you store personal and needed data (emails, lists of links, etc.), don't forget to make some kind of regular backup--even if only simple printouts--of your data there in case the services shut down unexpectedly. Derek Ziglar, Atlanta, Georgia firstname.lastname@example.org
In his comments to RISKS, Douglas Jones asserts that electronic, and more specifically *Internet*, voting is just like absentee balloting, and that therefore, it doesn't really merit any more special lawmaking or concern -- we just need to enforce the laws we already have concerning such ballots. I disagree. All voting systems are tradeoffs, as nearly everyone interested in the topic has been reminded repeatedly since 7 November 2000. Different tradeoffs have traditionally been made for absentee ballots, since elections as close as the 2000 Presidential election are quite uncommon, and therefore relaxing the constraints on absentee votes is an acceptable tradeoff for *getting* those votes — that is, making it possible for people who could not otherwise vote to be heard. But, these relaxed strictures are only acceptable, so far as I can see, precisely *because* those votes are such a small percentage of the total (well under 1%, usually). It would *not* be acceptable to use restrictions that loose for a voting method that might collect 30-50%, or even more, of the total balloting. The most notable criterion in question is secrecy of vote. This is in place, as <a href="http://www.research.att.com/~lorrie/voting/">Lorrie Cranor's excellent e-voting compendium</a> would remind us, to prevent vote-selling. "Oh, but no one does that these days — well, except maybe in Chicago" (:-). Nope. The restriction *works*. And, honestly, I cannot see *any way at all* to *impose* that restriction on voting which may be done from home. You can't even be *certain* that a vote came from whom it says it did; Bruce Schneier has explained fairly clearly in his Crypto-Gram newsletters the pitfalls in depending on even digital signatures, for something this important. While the various people involved, according to general press accounts, seem to properly appreciate the stringent requirements of electronic voting in precincts — chief among them the point that a "vote" needs to be a (rugged) *physical object that the voter can inspect, completed* (I'm thinking of OCR printing on Polaroid film, myself) -- I don't think the problem of Internet voting at home is soluble. Though I'm willing to be convinced otherwise. It won't be easy. Jay R. Ashworth, Member of the Technical Staff, Baylink, The Suncoast Freenet Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 email@example.com
Douglas W. Jones raised the problems of user-testing the DRE machines, citing among other reasons, that "A voter casts only one ballot, and for the voter, the voting experience is a peak moment" one may add also that voting is not a frequent activity so there will also usually be an element of uncertainty when confronted with the interface to be used... especially if the interface has changed (maybe for the better) since last time. In usability testing, an important issue is the 'Context of Use' (see http://www.ucc.ie/hfrg/baseline/filearchive.html#cou ) which boils down to the idea that a 'usability test' can be extremely misleading if carried out under conditions which do not mirror the real-life conditions in important spects. And emotionality, stress, and uncertainty are crucial features of this situation which will affect the results of any test. The basic tenet is: context of test = context of use. The best check on this kind of software would be to have the keypad or screen physically wired up to a completely separate second local system which will record the tallies using an algorithm independent of the main system, and to test it in situations as close the the real as possible. Telling pretend users to go in and punch a set of buttons is, I agree, not a very realistic way of testing; using over-the-shoulder video technology is incredibly time-consuming and will bring in its own sources of rater error. Jurek Kirakowski, HFRG, Ireland http://hfrg.ucc.ie/ http://hfrg.ucc.ie/jk/
The real risk here is the protection model used by Internet Explorer and related programs. Rather than establishing a mechanism whereby active content can be run (possibly with somewhat degraded performance) in a sandbox, it depends on all the certificants being able to ensure that their certificates and signed applets are secure. Certificates are useful as an additional mechanism on top of a secure system, to provide accountability, but they're no replacement for one.
Microsoft isn't the primary victim, WE ARE!! The only way to practically resolve this issue is for Verisign to re-issue all certs they ever verified under a new CA signing certificate. THEN, Verisign has to launch a campaign to replace it's CA certs in every online users' web browser!! Why? Because the general public (us) doesn't have a CRL-checking mechanism when our browsers verify a certificate as valid. Our browsers only look as far as the list of CA certificates that are embedded in our browser at the time we verify a cert. This isn't a minor PKI flap. THIS IS HUGE SECURITY DEBACLE FOR VERISIGN, AND A MAJOR NEW VULNERABILITY FOR THE ONLINE PUBLIC AT LARGE!!!
> [...] do not have this CRL Distribution Point field properly filled in. Unfortunately, the problem lies much deeper. The CDP field is not mandatory, it is *optional*. Complying implementations are supposed to "know" where to get the CRL in case the CDP field is not filled in. In most cases, configuring the CDP for the CA in these cases should be done at the same time as the CA certificate is given "trusted" status. That is, in theory at least. There is no real standard for how "certificates" should be filled in, issued or used. The often cited X.509 standard is very loose, and requires significant profiling to suit a particular purpose. The profiling work for Internet use has only recently produced the first IETF RFC:s. For those who are familiar with the risks caused by directory lookups based on "common names", it is interesting to note that one of the tricky parts of the IETF work was to come to an agreement as to what is part of a "unique name". I'm not sure a compromise is good risk management in this case... Current "X.509 certificates" are suitable for deployment in specialized environments, but anyone relying on them for what one might call "generic Internet authentication" needs to be aware of the pitfalls. The risk? Only a handful of people worldwide really know enough to be able to estimate the risks, but still we rely on things like SSL daily. Ask yourself - Do You know how your favorite browser responds to different PKI violations? And how would You respond? For a good, albeit rather specialized, view on PKIs, I recommend reading Bruce Schneier's book "Secrets and Lies". Bruce also co-authored a paper on "Ten risks of PKI" with Carl Ellison, which is probably a "must-read" for regular RISKS readers. > Two things need to be done, one is that software which checks certificates > must be changed to warn users that certificates lacking a CRL are much more > suspect and Verisign needs to re-place all certificates that currently lack > this critical information with new certificates that have this field > properly filled in. Also note the risk caused by implementing strict CRL checks. The CDP becomes a single point-of-failure for any relying certificates. I have experienced a situation where a software update at the CA site caused relying clients to fail in their CRL requests. If a site relies heavily on certificate-based authentication, the consequences can be very severe. Camillo Särs <+firstname.lastname@example.org> <http://www.iki.fi/+ged>
> [...] As this service had been canceled by the operator Telenor, all > train drivers had to call the train controlling central and report their > train number and the corresponding mobile phone number. This is incorrect. Telenor did not cancel NSB's phone service; the report clearly states that NSB had changed their train numbering scheme so that train numbers were no longer within the number range allocated to them by Telenor. I find it distasteful that people are still trying to invent reasons to absolve NSB of the responsibility for this and the numerous other accidents and interruptions of service they had last year. NSB's shoddy management, total lack of respect for their customers (though I have to admit they're still more customer-oriented than Oslo's public transportation authority, who seem to regard every passenger as a potentially violent criminal), and mismanagement of funds - spending billions on prestige projects with practically no ROI, while letting their infrastructure and equipment deteriorate for lack of maintenance - are the deep causes of these accidents. Dag-Erling Smørgrav - email@example.com
Back in August 1997, in RISKS 19.28, I reported the identical scam being pulled on me, involving the same bank (Wells Fargo). At that time, my local branch manager told me that she was currently working with three other customers of THAT BRANCH to put their banking accounts back in order as a result of the same scam. That was before Wells Fargo was bought by an out-of-state bank (that changed its name to Wells Fargo), and I must say that all the bank employees, both in the branch and in the fraud detection department, were cooperative and helpful, and in the end I was only out time, not cash. But it was still a damn nuisance. I didn't know about the change in California law making the DL primary id. The fake driver's license didn't have correct versions of my name, my birthdate, or my signature (all things the bank could have checked, but didn't). The gang didn't have my preprinted deposit forms, so they hand-wrote my account number on counter forms. But they didn't take quite $1,000 at a time and did it all in one banking day at multiple branches distant from my home branch, so apparently didn't trigger any real-time validation. Offline validation did bring in the fraud department. The bank notified me of the problem, rather than vice versa. As far as I know, the gang never tried again using my new accounts. Jim H.
(really about Cal. Commercial Code section 4406) While Mr. Cornell's concerns (RISKS-21.29) about the CA driver's license may be well-founded, his message's partial quote of California Commercial Code section 4406(d) leaves out important parts of the statute. Cal. Com. Code 4406 provides a "safe harbor" to banks to allocate losses from forgery onto customers who do not promptly report unauthorized transactions on their account. So long as a bank provides its customers with sufficiently detailed statement of account, the subdivisions of section 4406(a-c), which were not quoted in Mr. Cornell's message, create a duty upon a bank customer to "exercise reasonable promptness" in examining their bank statements to locate, and report, unauthorized transactions. If the customer does not do this, the customer has not exercised ordinary care, and thus, between the customer and the bank, the customer must bear the loss. However, the quoted section (d) provides an additional protection for a customer, even when failing in this duty, if the customer can prove that the bank was also negligent in accepting the forgeries. In that case, subdivision (e), a comparative negligence standard (e.g. customer 20% responsible, bank 80% responsible), is used to apportion the loss. This is not a new law. It was initially adopted in CA in 1965 as part of the Uniform Commercial Code. A 1992 revision increased the time period of subdivision (d)(2) from 14 to 30 days (which only fully applies when the same wrongdoer makes successive transactions). The UCC section was itself derived from prior statutes and case law concerning the allocation of loss from forgery and a customer's duty to provide notice of unauthorized transactions. Source: Cal. Com. Code Section 4406 (Deering 2001). The important point, which was not clear in Mr. Cornell's message, is that if you don't promptly check your bank statement for unauthorized transactions (and report any to your bank), you, not the bank, can be forced to suffer the loss. If you do suffer substantial losses from forgery, which your bank tries to stick on you, reading the unannotated versions of statutes available on the web are probably not going to constitute winning legal research: get a lawyer. I am not a lawyer. This information is presented for discussion purposes only, not as legal advice. John Rickenbrode <firstname.lastname@example.org>
Please report problems with the web pages to the maintainer