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…
As one involved in malware research, I should note the fifth anniversary of CastleCops. (Actually, five years ago it was computercops.biz: it's only been CastleCops for a couple of years now.) CastleCops is a company, but promotes efforts involved in community and communication, primarily aimed at malware, spam, and phishing. In regard to phishing, a recent project is Phishing Incident Reporting and Termination (PIRT, http://wiki.castlecops.com/PIRT). This project identifies phishing sites and gets them shut down, as well as providing information to law enforcement for prosecutions. It's been running less than a year, but has already saved an estimated (very conservatively) U$22 million in prevented losses. (Anybody who wants to can submit phishing messages that you receive or URLs you identify to the project.) To find out more about CastleCops you can visit www.CastleCops.com, or de.CastleCops.com if you Speak German, or wiki.CastleCops.com if you are into Wikis. For their fifth anniversary, they are, naturally, having a contest: http://www.castlecops.com/a6737-100_000_Contest_Celebration.html (Brian Krebs (*The Washington Post*) blog: http://blog.washingtonpost.com/securityfix/2007/01/in_praise_of_the_phish_fight er.html) rslade@vcn.bc.ca slade@victoria.tc.ca rslade@computercrime.org http://victoria.tc.ca/techrev/rms.htm
A second site, Paytrust, has followed Vanguard, in "improving" security. They now have one screen for userid and then a second screen for password. The theory is that if I don't see my selected picture and secret phrase on the screen then I shouldn't enter my password. I think this is "security theater" at best? While it makes phishers work a little harder. They have to be ready to execute a true man-in-the-middle attack. Not very difficult imho. I don't understand how this helps ME. I understand that it gives them a more plausible defense should someone break in. Saying we tried. It also asks me pre-established "extra" questions should I say I'm using a public computer. Knowing the answers to questions that can be relatively easily found out, ain't gonna cut it. How this stops replay or a keystroke logger beats me? This is all kabuki as opposed to real security. If they want a security model to follow, I like GoToMyPC's one time passwords. That's protection. Arghhh! Ferdinand John Reinke, Kendall Park, NJ 08824 http://www.reinke.cc/ blog: http://www.reinkefaceslife.com/
Boy, did you pick the wrong thing to complain about! The floating point arithmetic including on the X86 machines follows the IEEE 754 standard. Before 754 was developed, a programmer using floating point had to deal with many wild problems arising on every machine. Every new computer had a new floating point arithmetic which would bite you in unexpected ways. Ordinary problems included cases where X times 1 was not equal to X, or Y plus 0 was not equal to Y. These particular cases involve having insufficient extra precision, called guard digits, in the registers to accommodate fully accurate results, especially when the result required renormalization. In the bad old days you could thus not even count on add and multiply giving accurate results. Portable software, accurate to the bit, was well nigh impossible. If you research the standard, you will find very well documented reference code for square root and even large collections of test cases suitable to guarantee that the results of allegedly conforming implementations really did meet those demands of the 754 standard. The current state of affairs is already far better than what you seem to be seeking. Without actually attending the working group meetings, you would have no idea how much care is embodied in that standard. Richard Karpinski, World Class Nitpicker, 148 Sequoia Circle, Santa Rosa, CA 95401 dick@cfcl.com Home +1 707-546-6760 Cell +1 707-228-9716
Al Mac refers to a well-known Excel "bug" involving whether or not 1900 is considered to have been a leap year. What is apparently not so well known is the reason behind Excel's behavior: compatibility with Lotus 1-2-3. I did some research on this a few years ago, and I wasn't able to trace the behavior further back than the first version of Lotus 1-2-3, so that seems to be when the actual bug was introduced. You can read Microsoft's statement on it here: http://support.microsoft.com/kb/214326 (Although that article refers specifically to Excel 2000, the issue was present long before that. I first learned of it in connection with Quattro Pro, which exhibits the same behavior for the same reasons, in 1992 or thereabouts.) Steve Schafer, Fenestra Technologies Corp. http://www.fenestra.com/
It gets better: Microsoft is attempting to fast-track its weird, wholly messed up, snafu'ed, tarfun'ed, version of an OOXML standard as ECMA 376, and that particular stupidity is BUILT RIGHT IN!...That is, rather than correct the error, any 'standardized' program must REPLICATE the error. Full story on groklaw, scroll down. Read the whole thing. BTW, the drop dead date for objections to the fasttrack process is February 5th. I cannot find anyone at the Standards Council of Canada who even knows that the proposal exists and that Microsoft will win approval for the fasttrack process by default if nothing is done.
It is hard for me to believe that nobody at Microsoft thought about another solution than they think about (maintaining the epoch and increment the day numbers for all days from 1 Mar 1900). The most obvious solution would be to decrement the day numbers before 1 Mar 1900, effectively setting the eopch one day later... The incompatibilities listed would only occur when dates before 1 Mar 1900 were used. And as is noted, that is rare. And the error noted is corrected. But perhaps this solution is too rational? dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131 home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
That is inaccurate. The change is by four weeks in some years and five weeks in others. That shows the dangers of believing the media. Actually, DST is now always 34 weeks; it used to fluctuate. The change of DST rules actually occurs on March 1st, according to the Act. <URL:http://www.merlyn.demon.co.uk/uksumtim.htm#AA> refers. John Stockton, Surrey, UK http://www.merlyn.demon.co.uk/ [Note spelling correction: Daylight saving (singular) time. PGN]
There were actually a number of these in operation. The Internet Security Operations Task Force (ISOTF) had quite a frenzy of activity on Friday, and most sites were taken down in short order. The sites attempted to use the VML vulnerability, so only those who had been unpatched for quite some time were at risk.
I think the RISK here is running a Windows webserver/OS on a high-traffic website. http://www.reptilelabs.com http://www.ecis.com/~alizard http://www.pgpi.org Disaster prep info: http://www.ecis.com/~alizard/y2k.html
I've read Paul Robinson's topic with great interest. We (large institutional investor) use a system that's developed in APL by the supplier. The product is offered in the kitchen model, you can have the basic product which functions very well, you can also add numerous modules, the supplier knows how much time this takes on average. The fact is that this is indeed a niche market. Furthermore, it's driven by external force. The financial markets determine the products the application should support. The market determines how those products are calculated. For example, we had a minor valuation issue with some special government bonds and I could determine the cause by just setting the market's calculation up in Excel. It turned out we forgot to set the right rounding rule . Those calculations are provided in detail by external parties, in this case the French Government. If a supplier would invent it's own standards, this was not possible. Also, it's a market where little mistakes do have large impact. The rounding error was on the 5th decimal, but on our holdings this could be several thousand Euros or more. Since there is a large impact on error, companies are willing to pay. So that covers the financial aspects of development. The financial market is also constant developing. New instruments seem to appear on daily basis. That also calls for modular set-up of the application. Then this market for systems is small. There are not that many investment companies that can afford these kinds of systems. There are only a few suppliers. If a company screws up big time once or twice, it's out of business. It's hard to compare this market to other markets. Most markets don't have customers with the financial power this market has. The market is driven by external forces (the financial markets) and not the developing companies. The financial products have clear specifications. You can compare the market for railway systems or air traffic systems to ours. Those are markets with the same financial power, customer driven, clear specifications and high risk for the individual customer. It's not that there are many huge errors out there. It's the same as the rounding 'error' we experienced. For many it's not significant. Only it could have an enormous impact in those systems. Most of the time it's some kind of configuration mistake that leads to errors. Those happen in any system, even our modular APL based one. Jos Buurman, System Administrator Investment Management
Paul Robinson wrote: > There is a guy named Louis Savain who ... wants to create for software > what the transistor and the printed circuit did for electronics ... Having rigidly defined interfaces between components doesn't help when you have large numbers of components. The interactions between groups of components can become *very* complex and can lead to bugs. We can draw an analogy with the game of Go. It has very simple rules governing the rigidly defined interfaces between board, players and pieces, but the interactions between them lead to complexity such that precisely what will happen during a game is unpredictable. This is of course a Good Thing as it means a mediocre player like me can still beat the computer at *something*. > An example I gave was on the comparison between buying a kitchen makeover > and a maintenance change to a software package. A new kitchen is a fairly small, simple construction project. Small simple software projects are likewise frequently delivered on time, on budget, and working first time. You just don't hear about them because something that happens all the time ain't news. What you do hear about are the failed software projects of a complexity similar to that of the larger physical projects such as are par for the course in (for example) the defence industry. > In short, we get away with the great kind of racket in our business that no > one would tolerate from a Taiwanese manufacturer of toasters! But we accept it from the manufacturers of our fighter aircraft, the builders of railways, and so on.
I remember looking at Savain's web site http://www.rebelscience.org/ a few months ago. He isn't completely wrong, but he does set off a lot of my kook alarms. Your summary of his ideas about programming is a fairly good description of Erlang, which has proven to reduce error and increase productivity and reliability, and it has been used on some large and successful commercial and open source projects. Savain's ideas boil down to diagrammatic programming and as far as I can tell he doesn't talk about abstractions larger than a statement or perhaps a procedure, i.e. he doesn't say how to build software in the large. On the other hand, Erlang does have a coherent answer to this problem - have a look at the thesis of Joe Armstrong, one of Erlang's creators. http://www.sics.se/~joe/thesis/armstrong_thesis_2003.pdf f.a.n.finch <dot@dotat.at> http://dotat.at/
> If I understand his proposals, what he wants to do is develop software > visually in terms of components, and "wire" the components together. > Hardware has rigidly defined interactions and race conditions can't > occur because asynchronous operations are not possible. Please take a look at some device drivers in an open source operating system. High-level hardware components such as PCI devices often have very complex interactions, massive internal parallelism, and timing characteristics that are hard to predict - and that's even if they don't have a processor and "firmware" of their own. It's generally far cheaper to work around hardware bugs in a device driver, if that's at all possible, than to re-spin the hardware. So I don't think computer hardware provides a particularly good example to us. > An example I gave was on the comparison between buying a kitchen makeover > and a maintenance change to a software package. With a kitchen, you can > generally buy off-the-shelf components and have an almost exact estimate > of the complexity, the time to finish and the cost. And everything will > fit together and work right the first time. Well, it makes a change from the tired old-car analogy. Yes, you can buy these components off the shelf. They have fairly simple interactions with reasonably well standardised utility supplies. (Yet the sink does not abstract away the pipes below it; you have to remember not to put things down the plug hole that might build up in the pipe.) Your refrigerator isn't expected to interact with your hob. (Yet it does in an unfortunate way if you put them too close together.) When you cook a meal, all the burden of coordination is on you, not on the appliances and storage that are involved. This is not what people expect from software: they expect a far higher degree of automation. A kitchen is not a good example either. That's not to say that software can't be modular, with well-defined, tested, interfaces between modules. But I'm not sure that that's entirely possible or desirable for whole applications. Many of the requirements for an application will be a good deal "softer". And if the requirements change, that may require the interfaces between modules to change. If you wanted to do that in your kitchen, you'd be out of luck. But because you know software is more flexible, you expect to be able change the definitions of the components at any level - even if you don't know how long that will take! > As it stands now, things are "good enough" to get by and even with all the > failures we have, there is so much value for such little costs that we keep > stumbling along. In general, yes - though there are still seem to be many big projects with insufficient oversight from the customer that yield far less value than they cost - or even negative value. The software industry isn't going to stop doing this until its customers take charge and insist on ongoing refinement of requirements, phased delivery of and payment for working features, and other practices that help to reduce risk and increase value for money. (They may even encourage greater modularity!)
Paul Robinson talks about "software integrated circuits" (pluggable software components with well-defined interfaces); we've heard it before. The reason it appears that we don't have such things today is that the proponents are comparing incomparable levels of abstraction. If fact, we do have them, in the form of if..then..else expressions, quicksort routines, TCP/IP stacks, etc. These are what correspond to off-the-shelf integrated circuits. And most software developers _do_ use these components off the shelf. What we don't have are things like pluggable accounting packages. It's true that software components of this sort, ones that could potentially be abstractable into generic packages, just aren't available. But hardware functionality of equivalent specific complexity isn't available, either. Instead, those who want to implement that kind of functionality in hardware turn to application-specific integrated circuits (ASICs), and ASIC development pretty much parallels software development: a) Implement. b) Test. c) Debug. d) Repeat from step (a). There do exist modern programming languages that provide a much higher level of abstraction than do mainstream languages like C/C++ and Java, without the extreme terseness of APL or the verbosity of Cobol. Haskell and other languages of the ML lineage come to mind. Ironically, one of the reasons they're not very popular is that they require the programmer to do more up-front thinking about the problem to be solved; i.e., they require more mental abstraction.... Steve Schafer, Fenestra Technologies Corp. http://www.fenestra.com/
Paul Robinson <paul@paul-robinson.us> writes: > Basically he wants to create for software what the transistor and the > printed circuit did for electronics ... People keep coming up with this idea, and it keeps failing. Software components don't work this way. Things that are so rigidly defined so as to be perfectly reliable in unknown circumstances tend to be not very interesting or useful. Visual programming tends not be expressive enough for the really useful types of things. > Personally I believe he has some wonderful ideas and if he isn't > right he's very close. But right now, that's all he has, ideas. That point is accurate. If he can make a system that proves he is right, then that would be a great success for everyone, really. > Almost two years ago I wrote an article for comp.risks.[...] was wrong. > Most of them not only didn't get the analogy, they didn't realize > that most of their comments reinforced my points. You only addressed one of the points. What about the others? In particular, I had said (in RISKS-23.74): >> If you have small components that you know are right, and you then >> combine those components to manipulate each other according to their >> published interface specifications, the results should be consistently >> correct. The results will be predictable, the usage will be consistent >> every time. > This is false. The results will not necessarily be correct at all. > "Know are right" is not possible except in very specific and controlled > contexts. When components are used in new situations, any existing > assumptions cannot be relied on at all, without tedious and careful work > to reestablish them. > Software components are not physical components. They do not scale > the same way. > > That the software industry does not offer the same reliability and > quality as physically engineered products is not because software > practitioners are pulling at fast one (although they often are, but for > different reasons). > > They don't offer the same guarantees, not because they don't want to, but > because they cannot. Getting software right is hard. Very hard. So > hard that even really really smart people are not willing to be on the > hook for it. > > Customers have to tolerate software with mistakes, because that is > the only way they can get affordable software at all. If they insisted > on the same guarantees, they wouldn't be able to pay for it. > > Yes, we need to make better software. We need to try. Things can be > improved. They must be. The current situation is not acceptable. > > But it is not easy. Humans don't seem to be good at it. There is clearly a software problem that needs to be improved. How to do it is another question. Probably a mixed approach of little things will work over time (some formal methods, some better languages, etc.), but most of all it will require a greater attention to care and quality and a reduction of simple laziness. > The lessons of history teach us - if they teach us anything - that > nobody learns the lessons that history teaches us True enough. Ray Blaak rAYblaaK@STRIPCAPStelus.net
> ... The "big thing" in APL was to write a "one liner," an attempt to > write a complete working application in one line of code. Writing long complex expressions was not considered a positive aesthetic by experienced APL programmers when I was at STSC (the major APL timesharing service bureau) in the heyday of the late 70s. We preferred (and taught clients) to write good styled code, particularly avoiding long lines, and of course to put comments on them. Of course, one can write poor style code in APL, as in any language, and perhaps you saw some. I would take issue with the characterization that APL "failed dismally", although unfortunately it is not very popular today outside of the actuarial and other niche markets. APL was quite popular for while, and represented a major success story for many organizations. I don't understand your statement that during that time it "became difficult to work with", or that its abstraction capabilities had anything to do with it's lack of popularity. It is possible to write bad, incomprehensible, unmaintainable code in any programming language. The difference with APL is that you have a language in which it is possible to express certain things concisely and more clearly. (Other languages let you express certain other things very well, too. And some other languages seem most conducive to certain loud vocal expressions.) I don't understand your comment about "subroutine libraries" at all; it seems to be a nonsequitur. The APL language consists of a large number of primitive operators that correspond to what would have to be subroutines in other languages. APL vendors provided systems which additionally included hundreds of library packages for database, graphics, and many kinds of sophisticated application libraries. > Some people have said similar things about Lisp and the increase in > productivity they have seen from that as well. Well, people say all kinds of things, but that doesn't mean that they know what they are talking about. I have used, and continue to use, a lot of programming languages since I started programming in 1973. I haven't used APL since the 1970s; I switched to Lisp for most of my work around 1981, and Lisp is I'm using right now for most of my projects. I would heartily agree that Lisp and APL are powerful tools that allow good programmers to maximize their productivity. Everyone agrees that appropriate abstractions are essential for good programs, and that some languages are better at facilitating that. Unfortunately, most discussion of particular languages consist of repetition of myths and misunderstandings and misinformation, with religous overtones and attendant rationalizations. There are many Risks involved in analyzing the various aspects of programming languages and their effectiveness. One of the most common failures is trying to correlate popularity of a language with vague assertions or just plain wrong information about its technicalities. I hope that Risks Digest doesn't engage in such endless religious "language wars". It would however be instructive to illustrate both general and language-specific flaws, traps, and risks by analyzing systems failures that have actually occurred.
Sidney Markowitz writes, "The article on converting a camera to a 'taser' incorrectly talked about disposable digital cameras, which do not currently exist." I happened to see one on the shelf at a CVS Pharmacy today: http://www.cvs.com/CVSApp/cvs/gateway/detail?prodid=274180 &previousURI=/CVSApp/cvs/gateway/search?ActiveCat=499 ^Query=camera+digital (URL manually broken across lines.) Steve Schafer, Fenestra Technologies Corp. http://www.fenestra.com/
Well and thoroughly debunked. The initial report was from a US intelligence analysis group, with no details. When tasked on the matter, they first asserted it was true, and finally admitted that there was no evidence at all to support the claim. The idea of bugging coins was widely seen as a stupid idea, since most such devices would have ended up in vending machines ... [Noted by many of you. PGN]
And it would be easy enough to have the voice/video file mail itself out to email addresses harvested on the machine, turning it viral ...
Please report problems with the web pages to the maintainer