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…
Bank of America "lost computer tapes containing account details of more than one million customers who are US federal employees", reported by the BBC at http://news.bbc.co.uk/1/hi/business/4300371.stm My first question is "Why were the backups not encrypted before leaving a BofA site?". The RISK is obvious - handing unencrypted sensitive data to random third parties significantly increases the chance of them being stolen and misused. Commercial backup software offers encrypted backups these days, even. There is another more general RISK, since the theft occurred on a commercial airline flight. There is a conflict between wishing to lock your luggage to prevent theft from luggage handlers (a group of people known to steal from luggage) and being told that if you lock your luggage the lock may be forced open and destroyed by the Transport Security Administration searching your bags - you can't win. The "TSA [master] key" lock idea will just mean the thieving baggage handler will acquire one of the master keys beforehand. I doubt background checks, as suggested by Senator Charles Schumer in this article, are an effective solution. Failure to encrypt these backups before they went offsite seems negligent of BofA to me.
Some Sympathy for Paris Hilton By JOHN SCHWARTZ, *The New York Times*, 27 Feb 2005 POOR Paris Hilton! As unlikely as the preceding sentence might seem, there is ample reason to pity Ms. Hilton, the heiress, reality-TV actress, product pitchwoman and accidental porn starlet. Ms. Hilton just can't seem to get a break in the digital age. She suffered embarrassment back in 2003 when a homemade sex tape hit the Internet, and now her Sidekick - a high-tech toy that combines phone, organizer and camera and also lets users send e-mail and instant messages - has been hacked. Its contents, like her movie, were posted to the Internet for any and all to enjoy. "She was pretty upset about it," someone told MSNBC. "It's one thing to have people looking at your sex tapes, but having people reading your personal e-mails is a real invasion of privacy." ... http://www.nytimes.com/2005/02/27/weekinreview/27paris.html?ex=1267246800&en=72b477ed1c2b85ad&ei=5090
A Delaware blood bank lost a laptop computer containing sensitive information about donors when it fell off a truck (really). It was found and returned by the finder. Officials say they will now encrypt the information to prevent its unauthorized use or disclosure. Who knew? Perhaps the publicity will wake up a few others with similar data responsibility. [Source: WHYY-FM, the Philadelphia NPR station, filtered through BH]
http://www.sun-sentinel.com/news/custom/fringe/sfl-225nissan,0,2964317.story?co ll=sfla-news-fringe This system takes over the steering in some situations: "Lane Departure Prevention" combines a camera and computerized devices that control braking for front and rear wheels, nudging the car in the right direction. The feature disengages when you hit the turn signal, so you can change lanes and make turns. The RISKS are obvious.
A few years ago I was working in the US and applied for a bank account. They insisted on taking my "permanent" address, which was in England. But on entering the town, Enfield, they were then stuck - their software insisted that Enfield was in either Vermont or a couple of other US states. There is indeed an Enfield in Vermont, just not mine. Just another example of the software being made too "clever" by the programmer with "bullet-in-foot" being the result.
According to the reporter, the lawyer said that "his firm's spam blocking software automatically sidetracked the court's e-mail notice" and that "his law firm's spam-blocker software set the Internet security level too high, which blocked the e-mail notification from the court. After the security level was reset, the notification came through." One would conclude from this that the law firm had unmonitored software that was throwing away mail willy-nilly. Or perhaps that the law firm's system administrator configured it to do so. Both are serious charges that are likely to cause fear and doubt among users of email systems. It is unlikely that either is true. I submit to the court that the most likely facts are that the filter sorted the court notice into a possibly-spam folder and that the lawyer failed to look at the folder regularly. The next most likely case is the one I find the most disturbing: that the law firm's system refused the message (smtp 550) or accepted it and mailed a bounce notice back. But if this happened, why would the court issue the show-cause order? This is a vital question, because as an email system administrator, I rely on refusal as a valid way to notify senders that mail was not delivered. I expect the sender's system to generate a bounce and I expect the sender to look at it. I would be very surprised to be held responsible for failing to read a message that was properly refused. The smtp protocol has always defined the sender system as responsible until the remote side accepts. By the laws of wishful thinking I assume that the court does not ignore its bounces, and that the law firm's system does not throw away mail without notice. Therefore the court was in error. Unfortunately the filter software is not a person under law and cannot file for damages! Joseph Brennan, Academic Information Systems Columbia University in the City of New York
> 1. This would be a great site for the Malware Brigade to spoof. I hope > that it is more secure than most Web Sites. Sadly, no: Signing up for email or SMS alerts does not appear to require any address confirmation, so presumably anyone can sign up anyone else's email address or mobile phone for alerts. Also, no secure (SSL/TLS) form is provided for submission. I am also dubious about the 'ITsafe Word' scheme to protect from spoofing by the 'Malware Brigade' — http://www.itsafe.gov.uk/glossary/itsafeword.html definition: A security feature used on the ITsafe website to help reduce the risk of someone spoofing our e-mails. When you sign up to our e-mail service you are asked to type in an ITsafe Word (please keep this clean). This is not a password, so if you forget it, it is not the end of the world. You just need to be able to recognise it again in the future. All e-mails we send to you will use this word in the 'subject' line. In e-mail programs this is normally displayed just above the e-mail content. You can quickly check that the e-mail has come from us as someone else would not know your ITsafe Word. Until you forward the email, forgetting to remove it (not that it mentions that people *should* do this on forwarding etc). Or post it to USENET, or... I wonder if they have heard of S/MIME or PGP signatures? The problem here is that quite a lot of people will probably receive this as a forward, all malware would need to do is search mail folders for a legitimate bulletin (identified from mail headers) with the ITsafe Word in the subject line and use this to construct a forgery to attach itself to... ITsafe site URL http://www.itsafe.gov.uk/index.html
Several replies to Paul Robinson's "In the Matter of Component Architecture" suggest changes to the analogies. Robinson: "most likely you got out of a bed, got up and took a hot shower in your indoor bathroom...." As many replies pointed out, the components may be applied in new situations: A Linux computer instead of a Windows computer, or a faster or slower computer where the components may or not meet real-time requirements. Another reply told about a bug in the C library. There can also be a bug in the operating system or in the computer's firmware. Remember how some interrupts wouldn't preserve the BX register on the original IBM PC? The firmware may be a component to you but it's part of the environment to me. My program is expected to work in unpredictably buggy environments. So, add to the analogy: "As you were doing this, several other people attempted to take a shower with identical plumbing and heating: an astronaut on the Space Station in zero gravity, a man on Mars where the low atmospheric pressure made the hot water evaporate as soon as it left the showerhead, and a cold-adapted inhabitant of Pluto who found the showerhead couldn't deliver the ice-cube shower he wanted. "Meanwhile on Earth, a bug in your local laws of nature makes water change into sulphuric acid if its temperature is between 119.3 and 119.4 degrees F, so you have to be careful with the temperature setting or risk damage to the showerhead. You had some difficulty yesterday when the gravity server malfunctioned for a few seconds and all the water fell up to the ceiling." Mark Lutton, Dialog, a Thomson business. mark.lutton@thomson.com
I am surprised that nobody has remarked on the fundamental fallacy in comparing the "design" of software with the "manufacture" of physical items. If you want to compare software development with other engineering then you must understand the economics of design and manufacture in these two industries. The software manufacturing process typically involves copying of the software onto a CD; this is so fundamentally cheap that the practical cost of software is focused in the design stage. In physical engineering the vast majority of products that people encounter have the opposite relationship - cost is dominated by manufacturing. This doesn't invalidate the comparison but it does mean that it has to be made very carefully. When, for example, a building designer uses of the shelf components do they do it to make the design process simpler or do they do it because the construction is cheaper. All the cases where the decision is made to reduce construction costs are not applicable for comparison with the software industry. In fact software designers may make an opposite choice for exactly the same reason - in software any standard of the shelf component may bring manufacturing costs (license fees) whereas a home-grown variety is free. I believe this is an important force undermining reuse of components in software. I am in the business of producing software with a price limit from tens to hundreds of UK pounds per license. If I reuse commercial components with license fees of 20 pounds each then I very quickly destroy the economic viability of what I am doing. In most cases the functionality I am actually using in a software component that costs 20 pounds can be reproduced for a lot less than the license fees I expect to pay on predicted sales. If I were making physical objects then my custom manufactured component would probably have higher manufacturing costs than a bought in item rather than the zero cost that applies in software. The optimism that typically pervades the software development industry reinforces this process. Managers choose in house development because the initial estimates show it will be cheaper. If they were a little more aware of the typical cost overruns, additional maintenance costs and the like then there would probably be more reuse. The result of all this is that there is only widespread take up of component reuse where those components are reliable and free. The dominant source of these is the tools built into development environments. I have been in software for many years and I remember programming with assemblers and simple language compilers where at best I got 3 or 4 machine instructions for each line of code. These days the number of machine instructions and the amount of functionality for each line of code has increased dramatically. This is unquestionably reuse of components, even if many of them are very small ones, and everybody uses these tools. Steve Taylor, Technical Director, AssetCo Data Solutions 0116 2405755
During the more than ten years that I worked at an Institute for Neural Computation as a researcher, I regularly held a lecture series for students on "neural" and "non-neural" computation, their similarities and differences. One important point about "traditional" software that distinguishes it from physical systems — and that has been a major part of my introduction in the lectures — has been alluded to in this thread most clearly by Stephen Bull (RISKS 23.74) in saying that "[s]oftware is not constrained by the laws of nature." Of course, that's not really true; probably the best analogy would be to say that software is always a (strongly) chaotic system. To a physicist like me, this means that a small difference in initial condition — just a single bit, perhaps — can introduce an arbitrary difference in future state in a finite time. A physical system, for instance, is almost always dampened or low-pass filtered, to use another way of viewing it, which restricts a change in local state to a small rate of change; but in a computer system, it is equally likely for the most- as for the least-significant bit to change when something breaks (be it due to physical change such as radiation or a software malfunction). A bug such as a buffer overflow or array bounds violation can produce a knock-on effect that is unpredictable in its time-space distance. This means, to get back to Robinson's original post (or should I say diatribe 8-)?), that the component nature of a software component cannot (easily) be guaranteed, part of that nature being that components should only be loosely coupled among each other in a well-defined way. As a counter-example, you don't expect a scratch on the cabinet in one corner of your kitchen to lead to a short-circuit of the stove in the opposite corner, killing the user in the process, while the same kitchen implemented in software might quite conceivably have a bug that does that to its virtual (one does hope) user. Of course, there are physical systems that are chaotic, or where the component nature and loose coupling among components are not true -- well-known examples might be the Tacoma Narrows bridge or the Columbia accident. Such systems still manage to surprise everybody, including the experts in the field. On the other hand, sometimes a software system -- perhaps modelling a physical system — can exhibit non-chaotic behaviour in the face of errors; I particularly like the example given by Richard Feynman in the first part of his autobiography. One can clearly derive some recommendations for software development and use from these deliberations, a lot of which have been well-known for a long time. One of the not-so-obvious ones might be taken from looking at "neural" computation, to get back to the introduction: and that is to try to design algorithms that are tolerant of errors, both in their data as in the details of their implementation. That, of course, isn't easy, and I think it likely that it isn't applicable in all too many cases; but if you have a choice, select the algorithm that is perhaps slower or otherwise "worse", but that is more tolerant of errors.
> strcmp is one of the most simple, basic, fully-documented, and > frequently-used "components" there is. strcmp isn't an interchangeable > part. Your own story seems to tell us otherwise: because strcmp was "simple, basic and fully-documented", you were able to write a compatible replacement that traded off efficiency for reliability. (as your own unit tests have shown) Your story was a little vague on the details of switching all uses of strcmp to "smithcmp", but I presume the "fully-documented" part meant you were able to write an interface-compatible method that meant a simple string replace could be used on your source code to switch to the new implementation. It would thus appear that if one can get "full documentation" on "simple and basic" software components and write [unit] tests proving equivalent behaviour, interchangeability is indeed possible.
Daniel Smith gave a great example of the problems of reusable software. Clearly the bug in strcmp should have been fixed in the library. A single fix, well tested, would have filtered out to all the other products based on this reusable code. Better still, the odds on this nasty bug being identified were greatly increased because the code was used by many applications, in many different ways. Single usage code has a nasty history of bugs that are spotted so rarely that the cause and fix may never be identified. But this falls down if nobody is making money maintaining strcmp. Good-will goes only so far. Thorough design, testing and maintenance costs and someone has to pay. But development teams often fail to correctly compare hidden "do-it-yourself" costs against direct "buy-it-in" costs. So if you want quality, resuable software with timely fixes, get ready to pay. It doesn't have to be "through the nose", but it does need to be a reasonable amount.
Software patents make component reuse dead. Reuse a bunch of stuff and pay many fees, royalties, patent searches, lawyers and contract negotiations. So who will try reusing components with very real legal, financial, etc. risks when the risk of consequence for a bug (even resulting in deaths or huge financial losses,) is small? Steven Hauser http://www.tc.umn.edu/~hause011/ [That of course is precisely one of the main arguments for open-source/free software. PGN]
In comp.risks, "Peter B. Ladkin" <ladkin@rvs.uni-bielefeld.de> wrote: > I was surprised to find little of the extensive commentary on Robinson's > essay directed at his premise. (Stephen Bull and George Jansen addressed the > premise en passant.) > > The premise is obviously false, as ... most software development ... > is directed towards modifying already existing software ... Yes, but that's not entirely the same thing as OO dream of everybody assembling applications from ready-made components while everybody else is getting rich selling libraries of said components. Yes, larger businesses use custom software built from SAP or Oracle components. At the same time, smaller businesses use lowest common denominator off-the-shelf software that doesn't quite do what they want, but it's "close enough" and is something they can actually afford (speaking from experience). Of course we reuse code. We reuse entire applications all the time — nobody writes their own webserver when they can simply install Apache. When it comes to re-using components I prefer to re-use source code. Because cheap-not-quite-right off-the-shelf component is as useless to me as an overpriced custom component written to my specs which I know are going to change as soon as the users see the final product. We reuse code a lot. But that's not the same thing as building new systems out of preexisting OO components. That dream's been exciting a few decades ago but by now it's like that crazy uncle living in the attic: nobody talks about it anymore. Anybody can list at least half a dozen reasons off the top of their head why it doesn't work. As the comments clearly show. So I was rather surprised to see Robinson's essay published: not only the idea is out of date, the analogies are all flawed. I'm sure anyone who's ever renovated more than one kitchen or fixed more than one car knows exactly what's wrong with those analogies. (As the comments clearly show.) Not to mention that reasons why Sears would rather replace an $5 item no questions asked and have the customer come back for more don't have that much to do with warranty on the item.
In one interesting way, the problem with present software is not lack of components but use of them without adaptation. In modern software exactly the same program is sold to every user. In the Microsoft world, the install procedure hardly ever ask the users for intended uses of the software, level of knowledge of the subject etc. when installing. One size fits all is the norm for software and the standard executable is given to millions of users, completely ignoring any variances in knowledge, ability, interest or configuration. This is one reason why bugs in this software are so devastating. A problem in a component, such as the RPC bug that lead to Blaster, causes a problem with all systems built with that software. It is not the lack of component based development that is the problem, but the complete dependence on components that are used in places where they have not been fully tested.
If RISKS can bear one more comment on Paul Robinson's component architecture
essay...
In my experience, one reason why the decision to build new software rather
than use third-party components is one of control. Robinson mentions that
"nobody in their right mind would expect [a trucking company] to build their
own trucks"; but if the alternative was to buy trucks with the hoods welded
shut, and rely on a locked-in (and historically unresponsive) vendor for
repair and maintenance of your business's critical infrastructure, that
might just be an attractive option.
Fortunately, Free Software ("free as in freedom, not as in price") provides
us with the ability to obtain components that we can fix (or hire experts to
fix) if they break. Jay R. Ashworth's response notes CPAN and PEAR as
examples of reusable components; I think we need to emphasize that these are
not just reusable but are software libre.
Whitworth is equally good as an example of a failed attempt at standardization. By the 1900s it was just one British "standard" with the British Standard Fine (BSF), the British Association (BA) thread (metric measured in imperial units) and the Cycle Engineers Institute (CEI) threading in use. It is ironic that WWII forced the British Army to largely abandon Whitworth's standard and adopt the American standard (actually two: National Coarse and National Fine) which has threads that are easier to make (60 degree thread pitch, single cut process with flat roots and crests vs. 55 degree thread pitch, multiple cut process, varying threads per inch by diameter, rounded roots and crests) and more reliable. Metric, by the way, uses a 60 degree pitch and designates fasteners by their nominal diameter and thread pitch, both measured in millimeters. Software doesn't seem to be doing any worse with regard to standardization than did mechanical engineering.
> "Mechanical engineering has it's standard components, nuts, bolts, screws, > nails etc. Just as we have some as well, languages, editors, protocols > etc." www.screwfix.co.uk lists 33 separate major categories of screws, many divided into sub-categories, and then there are the individual sizes... It's similar for other components, and this is after over a century of mechanised production. I know I never seem to have quite the right item ready in stock for whichever DIY job I'm wanting to do. So, the kitchen-fitting analogy holds quite well - the whole thing's a mess.
Raj Mathur spotted a bug in my simple pipe. I was hoping somebody would
notice that bug! I spotted it only when the digest came out and I (vanity
of vanities) reread my posting. Actually, I'd suggest and even better and
simpler fix:
ls -l | grep '^-' | awk '{total+=$5}END{print total}'
which protects against new future file types.
But I think that my original error nicely (if unintentionally) makes the
point that plugging components together isn't a cure-all. — Geoff Kuenning
geoff@cs.hmc.edu http://www.cs.hmc.edu/~geoff/
[The identical fix was also noted by Dave Horsfall. PGN]
ls -l | awk '!/^[bcdps]/{total+=$5}END{print total}'
and with perl, one doesn't even need the ls...
Please report problems with the web pages to the maintainer