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…
http://www.latimes.com/technology/la-fi-internet2jun02,0,622125.story?coll=la-home-headlines "The Justice Department said Thursday that it was not seeking to have the contents of e-mail archived, just information about the websites people visit and those with whom they correspond." "Sounding the Alarm on Government-Mandated Data Retention" http://lauren.vortex.com/archive/000175.html This is a critical topic. The impracticality and cost issues associated with the new DOJ Internet data retention proposals are relatively obvious. It's difficult to even understand who would be required to comply with such demands. Only the big Web service companies? ISPs? (via packet tracking of their subscribers running their own servers?) Every small firm, organization, or even individual who operate their own e-mail and Web servers? Are the existing privacy policies of such entities instantly negated if they conflict with the DOJ wish list or data retention legislation? It's also obvious how e-mail contact information could be abused. But there's something even more insidious in this situation. In the recent DOJ vs. Google case, Google and most unbiased observers correctly noted that "Web destinations" (URLs) frequently contain all manner of personal and private information. Names, addresses, social security numbers, dreams, hopes, interests, fears, medical queries — all manner of details of our lives are embedded in the URLs we submit to search engines and other Web sites. For all practical purposes, URLs in the Web context are very much like the content of phone calls in the conventional telecom context, judging by the level of detailed data that URLs provide and their ability to allow complete tracking of our every related Internet action in most cases. If Internet users must live in fear that their actions on the Net are subject to retrospective analysis — not only based on today's criteria but potentially on tomorrow's as well — the effects on how we view and use the Net will be drastic, with vast unintended negative consequences that strike to the heart of our democracies. This issue is ultimately more important than network neutrality, Internet governance, or most (if not all) of the other technically-related concerns that we bandy about here in IP or in most other forums, because it strikes to the very core of basic privacy concerns and personal freedoms. Government-mandated Internet data retention could be the most potent single technological move in recent history toward enabling future tyranny against both individuals and groups. We must not allow this issue to be "managed" through private meetings requested by government officials, or as a mere footnote in the public discourse or hastily passed legislation — to be treated as a fait accompli by this or future administrations. Lauren Weinstein +1 (818) 225-2800 http://www.pfir.org/lauren PRIVACY Forum - http://www.vortex.com DayThink: http://daythink.vortex.com
> ...understand the horrible collateral damage that their proposals would do. Here in the UK (where plans for ID cards are well advanced), it's difficult to avoid the feeling that legislators and their backers **do** know that their proposals may well have undesirable side-effects, but they feel that these are worthwhile in the fight against child pornography, international terrorism, financial fraud, or whatever, and anyone who suggests caution (such as pointing out the RISKs of large-scale IT projects) and a more-considered approach is accused of wantonly obstructing their efforts. A cynic may feel that legislators are often inclined to brush objections aside just to show how tough they are being in dealing with serious problems, and as governments want to be seen to be doing something and people (voters) like to be reassured, intrusive but ineffective measures are favoured over effective but discreet ones. The deeper trouble seems to be modern politicians' liking for legislation as a fix for every problem; few people probably want to live in a country like 1970s East Germany, but some of us seem to be getting there anyway.
CNNMoney reports that about 243,000 Hotels.com credit-card numbers were stolen back in February via the theft of a laptop computer. They believe that the theft was of the computer, with no idea of the information on the hard drive, and, likely as well, no intention of using the information on the hard drive. That it takes from February to June to determine what was on the hard drive is difficult to accept, however, and leaves unanswered what MIGHT have happened in the intervening three months respecting identity theft or misuse of the credit cards. Lots of unanswered questions, but typical of the problem when a laptop gets stolen... [Source: CNNMoney.com, 2 Jun 2006]
Aznar Government deleted all the Spanish Government Presidency computer systems in "La Moncloa" Official Palace after the elections (3 days after the terrorism attacks in Madrid-Atocha train station). There is a 12 thousand Euros bill just for deleting everything, even data back-ups. We are trying to find ways to ask for political and criminal responsibilities, and right now we need international cases, news, and references of official data deleted in government systems. As far as we know, in USA is not possible to do anything like that, and even Henry Kissinger files will be known in the years to come. I mean that USA presidents can encrypt and legally protect that information, but they can not erase as Aznar did. You can find a lot of information (in Spanish) and our criminal accusation at http://www.cita.es/borrado We expect expensive lawyers fees and a bail in order to keep the case alive in a Spanish Court of Law, so we need financial help and international media broadcasting. We found some support in archivists from several Spanish speaking countries already and I shall appreciate any help or expert witnessing support in order to explain to the judge how serious is the case documented at http://www.cita.es/borrado Please do not hesitate to contact me for further information and forward a copy of this message to anyone you consider more appropriate. Miguel A. Gallardo O., Engineer, Criminologist and Forensic Cryptologist President of APEDANICA at www.cita.es/apedanica CV con fotos en http://www.cita.es/conmigo Skype: m.a.g.o. Tel: (+34) 914743809 móvil 619776475 www.cita.es Apartado (P.O. Box) 17083-28080 Madrid, Spain
Associated Press item, 3 Jun 2006 One of the world's most notorious spammers has settled lawsuits with the state of Texas and Microsoft Corp. that cost him at least $1 million, took away most of his assets and forced him to stop sending the nuisance e-mails. Ryan Pitylak, 24, who graduated from the University of Texas last month, has admitted sending 25 million e-mails every day at the height of his spamming operation in 2004. http://www.quote.com/home/news/story.asp?story=58948931
I just ordered copies of my free annual credit report from www.annualcreditreport.com. One of the new options is to hide the last 4 digits of your Social Security Number in the report output. That's mildly nice, in case the printed report falls into the wrong hands. At least one of the three major credit-reporting companies who participate in the web site, Equifax, also hides details of account numbers by blanking the last four digits. Again, a nice touch: somebody who gets your report can't get a list of all your credit-card numbers. Problem 1: most other credit-card handlers (e.g., Web vendors) blank all BUT the last four digits. I frequently get invoices and packing lists saying "card ending in 1234". So between one of those and the credit report, nothing is hidden. Problem 2: I have some student loans with Sallie Mae. It turns out that their account numbers are formed by appending 3 digits to the end of the SSN. So despite Equifax's kind blocking of 4 digits of my SSN, in reality only 1 digit is hidden from anybody who acquires my copy of the report. Needless to say, if I print the report it'll get shredded when I'm done with it, and my on-disk copy will be encrypted. But what about my non-security-savvy neighbor? Geoff Kuenning geoff@cs.hmc.edu http://www.cs.hmc.edu/~geoff/
PGN reported on the DART-satellite collision (Risks-24.29) and Robert Schaefer (Risks-24.30) noted that ITAR restrictions may have been a contributing cause. The incident took place on April 15, 2005, so the report comes a year later. Frank Morring, Jr. reported extensively on the investigation in Aviation Week and Space Technology, May 22, 2006, pp37-8. An on-line report by Morring, freely available, may be found by searching www.aviationnow.com for the two words "DART morring". For those who like to paste pieces together, the URL is http://www.aviationnow.com/avnow/search/autosuggest.jsp?docid=600549&url=http%3A%2F%2Fwww.aviationnow.com%2Favnow%2Fnews%2Fchannel_space_story.jsp%3Fview%3Dstory%26id%3Dnews%2FITAR05176.xml A U.K. firm, Surrey Satellite Technology Ltd., supplied the DART prime contractor Orbital Sciences Corp. with the primary GPS receiver used for the rendezvous manoeuvre. The GPS receiver registered a spacecraft velocity in error by about 0.6 m/sec. This led to a significant difference between estimated and measured positions, which led to the DART spacecraft resetting its position computations, with the biased data, which led through the same discrepancy to repeated resets, because the feedback "gain" was such that the estimated and measured positions could not have converged. "The anomaly caused excessive consumption of the spacecraft's ... fuel. It also led to the collision with the target satellite,..." (Morring, Avweek op.cit. p37) The bias in the Surrey GPS receiver was known, but the software fix for it had never been implemented by the DART team, and the bias was not reflected in the software model simulating the GPS receiver in preflight testing, so this simulation failed to elicit the reset problem, says the report (Morring, op.cit, p37-8). Morring's article, and the report, also consider the human, organisational and developmental weaknesses and failures that led to this anomaly arising in operations. The redacted summary of the report says "In the case of DART, the MIB concluded that insufficient technical communication between the project and an international vendor due to perceived restrictions in export-control regulations did not allow for adequate insight" (op.cit., p.37). (I read this to mean restrictions *derived from* export-control regulations.) Peter B. Ladkin, Causalis Limited and University of Bielefeld www.causalis.com www.rvs.uni-bielefeld.de
Geoff Kuenning reported an *LA Times* humor photograph featuring a self-pay parking kiosk with a mis-set date of 16 May 1943, showing an amount due of $8,082,022.84. And he commented, "Sanity checking, you ask? Not bloody likely. An auxiliary display shows the fee in larger characters; it reads 8.1E+6. When you have an programmer so clueless as to calculate money values in floating point, there is little hope for subtleties like sanity checking." And continued, "As a side point, I'm fascinated that things like parking kiosks now use chips powerful enough to have floating-point support, at least as a library. A 4-bitter would be adequate for the task, though it's not clear to me that this particular programmer could have written the code needed to compute the fee on a 4-bit machine." Assuming that the photo is genuine, it seems at least plausible that the programmer used a software library for calculating cost based on elapsed time rather than explicitly using floating point. Regarding the chip's bitness, unless the programmer is writing assembler code (risky business for such a mundane application), it seems unlikely that modern programming languages are supported by 4-bitters. Sanity check? Sure, programming insanity is easily detected in hindsight. The kiosk should have refused a date earlier than some epoch. But what was the 1943 date? The kiosk's "current" date? The date a car was supposedly parked? The fee calculation might have refused to present an amount greater than some number. But what specs was the programmer coding from? What government agency requirements were the specs derived from? Why didn't a simple test case involve feeding the kiosk a prehistoric date? I guess the computer risk is debugging and proposing a solution based on a photograph of an incorrect result, not to mention blaming the anonymous programmer for (perhaps) just coding to design. And the manufacturer for using current technology vs. (perhaps) obscure and hard-to-program minimalist hardware. Though, of course, there's likely a big-city market (New York, certainly) for parking meters displaying fees in floating point. [Similar comments from Ray Blaak. PGN]
I get these all the time. All spam that is caught going to our mailing lists is forwarded to me and appropriately filed away automatically. I get about 3000 spam messages a day. I got 6 identical phishing emails for some bank today and forwarded one of the messages to both abuse@domain and security@domain. Those addresses often exist. I don't bother looking up addresses at their sites.
BKSWCMUV.RVW 20060514
"Software Configuration Management Using Vesta", Allan Heydon et al.,
2006, 0-387-00229-4, U$59.95
%A Allan Heydon
%A Roy Levin roy@Levin.net
%A Timothy Mann
%A Yuan Yu
%C 233 Spring St., New York, NY 10013
%D 2006
%G 0-387-00229-4
%I Springer-Verlag
%O U$59.95 212-460-1500 800-777-4643 matthew.giannotti@springer.com
%O http://www.amazon.com/exec/obidos/ASIN/0387002294/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/0387002294/robsladesinte-21
%O http://www.amazon.ca/exec/obidos/ASIN/0387002294/robsladesin03-20
%O Audience s Tech 3 Writing 1 (see revfaq.htm for explanation)
%P 262 p.
%T "Software Configuration Management Using Vesta"
The preface tells us that Vesta is a system for version and build control
suitable for projects of all sizes, from the small, to those large and
distributed to such an extent that the standard software management tools
are inadequate.
Part one provides a general description of Vesta. Chapter one is an
introduction, both to the common versioning (and related debugging and
testing) problems, and to the principles of Vesta: versioning of source code
and tools (with automated handling of relevant object code), "immortal"
storage of all versions, and storage of complete system model descriptions
of all builds and options used in compilation. ("Sources," in Vesta, are
not limited to source code: tools introduced into the system are treated in
similar ways. In addition, immortality is limited to source code: when a
derived entity; one that is built or compiled; is unused for some period it
may be weeded.) Various development related concepts from UNIX are listed
in chapter two. The reason for this is not completely clear, but some of
the ideas are used in chapter three, which describes Vesta at an abstract
level.
Part two outlines the view of a Vesta user: the perspective of the
programmer or developer. Chapter four reviews the management of versions
and sources. The notion of a name space is similar to the UNIX file system
or the Internet's domain name system (which it partially uses), with
additional linking and restrictions on reuse. There is no specific support
for merging of changes, in Vesta, but the tools can be modified to call for
a merge utility from another source. Chapter five outlines the System
Description Language (SDL), a scripting language for specifying "building"
in Vesta. An example of the use of the language is given in chapter six.
Part three looks inside Vesta. Chapter seven examines internal operations
of the repository. The Vesta evaluator is essentially responsible for
compilation of the software project: chapter eight reviews the
characteristics that allow it to manage complex development efficiently,
reusing as much prior material as possible as the changes are made
incrementally. The weeder attempts to deal with the issue of a system that
can expand forever on a finite disk: the algorithms for making the balance
between keeping too much (running out of space) and keeping too little
(having too spend to much time recreating needed parts) are given in chapter
nine.
Part four allows us to assess Vesta. Chapter ten reviews some competing
systems: RCS (Revision Control System), CVS (Concurrent Versions System,
Make, and a few CASE (Computer Aided Software Engineering) tools.
Performance, in terms of various speeds, memory loads, and storage
requirements, are examined in chapter eleven. The data is, unfortunately,
not from recent projects that used the system, but does show that Vesta
convincingly outperforms Make, even for relatively small projects.
(Suggestions are also given for enhancements to improve the system even
further.) The conclusion, in chapter twelve, repeats much of the material
in the preface.
An appendix provides a reference manual for the SDL. Vesta is available as
an open-source tool at the www.vestasys.org Web site.
The authors admit, in chapter twelve, that there would be a learning curve
involved in persuading developers to use the Vesta programming environment:
Vesta does work in ways that would, initially, be mysterious to coders
familiar with the currently popular tools. In addition, there would be some
overhead involved in teaching programmers to use SDL. (On the other hand,
new programmers would probably take to it quite readily.)
The book is intended as a research report rather than a user manual
(although part two can be used to get started with the system). Much of the
material concentrates on the internals of the system, and the aspects that
assist in the excellent performance: these operations will never be seen by
the user, although the system response will be satisfying. The authors have
made no attempt to understand the information (and writing style) that would
be helpful to developers attempting to use the system, and managers trying
to decide whether or not to implement it. Open source devotees wanting to
understand and extend the project will find this an invaluable resource.
Researchers in the fields of software development and system performance
will also find much of interest in these pages.
copyright Robert M. Slade, 2006 BKSWCMUV.RVW 20060514
rslade@vcn.bc.ca slade@victoria.tc.ca rslade@computercrime.org
http://victoria.tc.ca/techrev/rms.htm
BKPRFPWD.RVW 20060420 "Perfect Passwords", Mark Burnett, 2006, 1-59749-041-5, U$24.95/C$34.95 %A Mark Burnett %C 800 Hingham Street, Rockland, MA 02370 %D 2006 %G 1-59749-041-5 %I Syngress Media, Inc. %O U$24.95/C$34.95 781-681-5151 fax: 781-681-3585 amy@syngress.com %O http://www.amazon.com/exec/obidos/ASIN/1597490415/robsladesinterne http://www.amazon.co.uk/exec/obidos/ASIN/1597490415/robsladesinte-21 %O http://www.amazon.ca/exec/obidos/ASIN/1597490415/robsladesin03-20 %O Audience i- Tech 1 Writing 1 (see revfaq.htm for explanation) %P 181 p. %T "Perfect Passwords: Selection, Protection, Authentication" Those of us in the security field know that users are generally bad at creating passwords, and that passwords that are easily guessed or found account for huge numbers of security incidents. Therefore, I am in full sympathy with a book that attempts to lay out some guidance on password choice. However, Burnett's work calls to mind the old joke that lists all kinds of restrictions on password selection, and finally admits that only one possible password actually fits the criteria, and will all users please contact tech support to be issued with that password. Chapter one tells us that people choose weak passwords, and gives a number of lists of such poor choices, without an awful lot of explanation. (Burnett also states that the choice of strong passwords provides non-repudiation, which is a rather strange position. One could make a case that the deliberate choice of a vulnerable password would allow the user to later claim that their account had been hacked, and therefore assist with repudiation, but the reverse doesn't necessarily hold.) Various types of password cracking techniques are given in chapter two. This begins to show the inconsistencies and contradictions that plague the text: at one point we are told that any password less than fifteen characters is "immediately" available to attackers, but elsewhere it is suggested that a ten character password is a wise choice. (Although brute force cracking is discussed extensively, there is, oddly, no mention of the implications of Moore's Law.) There is a good discussion of the vital issue of randomness in chapter three, although there are numerous gaps, and, again, erratic suggestions. Chapter four covers character sets and address space. Unfortunately, it is rather impractical (as are other areas of the manual) due to a lack of recognition of character restrictions. Password length is addressed in chapter five, covering many of the same concepts as in four. It is also the most useful of the material to this point in the book, suggesting ways to lengthen and harden passwords already chosen and preferred. (Some of the advice is suspect: bracketing is easy to add to automated password cracking programs, and even Burnett admits that "colorization" is a weak idea due to the limitations on selection.) Chapter six takes an extremely terse and abbreviated look at password aging, but all that is really said is that it is inconvenient. Miscellaneous advice about using, remembering, storing, and managing passwords is given in chapter seven. Chapter eight provides password creations tips, but these are, after some of the previous material in the book, rather weak, and typically boil down to the use of passphrases and long passwords. Five hundred weak passwords are listed in chapter nine, but the purpose of the list is not clear. As with chapter one, the passwords are not analysed for strength in any way, and, even if you want to check your favourite against the list, it isn't in alphabetical order. Additional password creation tips are in chapter ten, these slightly more useful. We are told, in chapter eleven, to make complex passwords, uncommon passwords, and not to tell anyone our passwords. Chapter twelve suggests having a regular "password day" set aside to concentrate on changing passwords and creating strong ones. Other forms of authentication are discussed in chapter thirteen. While the advice and information given in the book is not bad, it seems to posit a fairly ideal world. A number of practical items can assist users with password choice, but a number of realistic considerations are ignored. Readers may also be confused by the lack of constancy in the recommendations. Certainly the structure of the text could use work: concepts are repeated in different chapters, and the advice seems to be aggregated and presented at random. There is good advice in this manual, but it lacks focus. The average computer user would probably receive a lot of benefit, but is unlikely to purchase or read anything this size on this topic. (A pocket sized volume, along the lines of the O'Reilly "Desktop Reference" series would be ideal.) System administrators would be able to understand and use the material in the book, although much of the content is either known or available. On balance, I would recommend that this primer is important, but definitely needs work. copyright Robert M. Slade, 2006 BKPRFPWD.RVW 20060420 rslade@vcn.bc.ca slade@victoria.tc.ca rslade@computercrime.org http://victoria.tc.ca/techrev/rms.htm
Please report problems with the web pages to the maintainer