The BlackBerry wireless e-mail service from Research In Motion appears to have suffered a widespread outage starting on the evening of 17 Apr (about 5:15pm PDT). The outage reportedly persisted into the following morning throughout North America. [Source: John Blau, Problem sending and receiving e-mail from BlackBerry devices appears to be limited to North America, IDG News Service, 18 Apr 2007; PGN-ed] http://www.infoworld.com/article/07/04/18/HNblackberryoutage_1.html
Intuit (which makes TurboTax and ProSeries tax software) expected to hear from the Internal Revenue Service today (the day after taxes were due) whether any taxpayers who used its e-filing system would be penalized for submitting late returns. A flood of last-minute tax filers swamped the servers of Intuit Inc. on Tuesday, causing hours-long delays in getting forms sent in electronically to the government. As the midnight filing deadline approached, the problem got worse. During times of peak demand, Intuit was processing 50 to 60 returns per second. [Source: Lisa Leff, Associated Press, 18 Apr 2007; PGN-ed] "Don't wait until the last minute is the moral of the story." [Intuit spokesperson] Last I checked, the IRS sets a legal deadline, and Intuit's FAQ on e-filing doesn't say — maybe your filing will go through at 11:30, maybe it won't, so file early. Cameron Cameron Wilson, Director of Public Policy, Association for Computing Machinery 1100 Seventeenth Street, NW, Suite 507 Washington DC 20036 1-202 659-9712 www.acm.org/usacm
[I include only the SECOND of two messages from Mahlon. The first gave a detailed account of repeated attempts to file electronically. PGN] Update: At 11:54 PM, with just 6 minutes on the clock, TurboTax finally accepted my tax return. No doubt now that the East Coast is past the deadline, the load on the servers abated. (But not before I made an emergency run 40 minutes across town to the only post office open this late!) In all, I attempted to transmit 27 separate times, receiving many nonsensical error messages. The error message that made least sense was this "no-error" error: "No error. The transmission was unsuccessful. Please try again later." [Link to image of the "no-error" error: http://farm1.static.flickr.com/218/463746848_7b53305130_o.png ] Recommendations to Intuit: 1. Size your servers and network for peak volume plus contingency. 2. Provide meaningful error messages so your stressed-out users don't have to guess what's going on. 3. If the user is preparing a return during an expected high-volume period, provide a warning at the beginning of the process that servers may be busy, and to file a preemptive extension while the local post office before the local post office closes. [Perhaps quite counter to popular opinion, but not counter-INTUIT-ively, the IRS announced that it would accept Intuit's overly delayed returns. (Only fitting, in that the IRS has had its own series of computer difficulties!) An interesting RISKS question is raised, namely has the definition of MIDNIGHT on tax-due-day been adequately specified? relative to the time zone of the server from which the return is filed? or the location of the filer? What if you are filing from your laptop in Hawaii via your home or office system in NY? PGN]
I have a Windows program written in C++ using Microsoft Foundation Class structures. It gathers data and stores it in XML format. I store associated time stamps for the data using ISO8601 date format, and store the dates in UCT. (I use the ATL classs ATL::CTime for most of my time manipulation stuff, including the FormatGmt() method.) I do not run my own date arithmetic. I only use the library calls for switching between local time and UCT. I use standard library calls for getting the time. In running log files from the past few weeks I've noticed that the times seem to be an hour off from what I remember the time would have been when the data was taken. Things are more complicated, because I'm teleworking from a location that is two hours away from where the data was originally taken. (The office is in Dallas TX, I'm in Seattle WA.) I have no idea if the various patches I've applied to the systems I've been using have been applied only to the operating system, the C Run time libraries, or only half, and making sure that they are only applied once and not multiple times. I think that this US DST switch is going to continually bite us in small ways for several years. The only solution I see is to operate computers on UCT without any time zone translation enabled, which isn't really a viable solution.
time.windows.com - the system Microsoft windows machines use to set their clocks is currently reporting seemingly random times up to 150 seconds off. It is correctly reporting stratum 16 "unsynchronized" so if the windows time client is well written it shouldn't be a problem ....
Local and foreign computer hackers will be invited to break into an Internet-based voting system that will be pilot-tested by the country's Commission on Elections (Comelec) 10 to 30 Jul 2007 for 26,853 registered absentee voters in Singapore. The results of the polls, which will use survey questions, will be non-binding, which means it will not affect official elections results. Comelec commissioner Florentino Tuason Jr. told local reporters they have already asked the help of the International Foundation for Electoral System (IFES), a Washington-based IFES non-profit organization, in getting professional hackers to test the security of the Internet voting system. "When Scytl presented the system, everybody was impressed on the security features. It is covered by international patent and it has been declared secured by no less than Switzerland and everyone in the global community should respect that decision," Tuason told reporters in a conference Tuesday. Scytl's computerized voting system is also being used in countries such as the U.S., Switzerland, and Belgium. The Comelec has earlier batted for the full implementation of the Internet voting system in Singapore but Senator Richard Gordon succeeded in stopping it. Gordon wanted a computerized casting and counting system to be deployed instead in selected provinces in the country. The Comelec had to back off, however, because it lacked enough time to prepare for this type of system. [Source: Geoffrey Ramos, Hackers Invited To Break Into Philippine Internet Voting System, *All Headline News*, Manila, Philippines (AHN), 17 Apr 2007; thanks to Paul Lambert for spotting this one] http://www.allheadlinenews.com/articles/7007075062
So, why would spam go away? The economics of spam will eventually decide whether spam will go away or not. If somebody can make money from it, it will stay. I tried to grasp the total picture of the economics of spam in the following text. I am sure I missed something. Who gains at the present situation: * spammers get paid by crooks and businesses * backbone providers get to sell more bandwidth * BOTnet providers get paid for their BOTnets * ISPs can sell extended security packages and filtering services * Spam-filter companies make their living off the spam * politicians can get new laws accepted that will give them more control * virus writers get paid for writing BOTnet creating viruses and trojans Who loses at the present situation: * users have to pay more for their connections * ISPs have to pay more for their backbone * software companies have to use substantial resources to make security updates * companies, whose employees waste time to sort through loads of spam before work can be done IF spam should go away, who gains: * users should get cheaper prices * ISPs would have cheaper backbones because of less traffic * software companies would have less incentive to make safe software * companies, whose employees no longer waste time to sort through loads of * spam before work can be done IF spam should go away, who loses: * back bone providers will lose about half their market * BOTnet providers will lose most of their market, leaving only virus and attack parts * virus writers would lose their main source of income * ISPs would lose the market for filtering services * spam-filter companies would lose their whole market * spammers would lose their income * politicians would have less excuse for controlling the Internet * some businesses would have to find more expensive advertising channels So, why do you think spam would ever go away. Who would want it to go away? Sten Carlsen
I have yet to discover the exact nature of the software "designed to monitor the flow of electricity" and would appreciate any more details. Follow-up coverage indicated the problem software was in the newest model (6000-series) cars, as well as older (2000- and 3000 series) cars that Alstom was contracted to refurbish. Metro operates a total of 190 cars with the monitoring software package that malfunctioned. Officials had replaced the software with an older version in about 150 cars by Friday, April 13. The previous version of software was to be reinstalled in about 40 additional rail cars during offpeak hours Friday night and Saturday morning. Reverting to the old software takes about 20 minutes for each rail car, and all fixes were to be paid for by Alstom. http://washingtontimes.com/metro/20070412-104206-9871r.htm An extensive December 2006 audit report by the Washington Metropolitan Area Transit Authority identified deficiencies in Alstom's software quality processes, but none seem to relate specifically to this problem. http://www.wmata.com/about/parp_docs/Internal_Audit_Rail_Car_Report_010307.pdf
The "Software causing hardware problems" phenomenon can be a troubling one. It has been a fundamental tenet of modern systems engineering that the advantage of software-based systems over hard-wired ones is that additional functionality can be added at much lower cost, especially in the basic qualification of the hardware elements. For example consider a mission computer in a modern military fast jet. This would be initially integrated onto the aeroplane and in the process it would be tested for all the usual things - shock, bump, thermal environment, EMC etc etc. Some time later it is decided to integrate a new type of sensor array into the starboard tachyon emitter, and this requires a small amount of additional code in the mission computer to enable the sensor to be controlled from the existing pilot controls and to direct the sensor output to the cockpit displays (and over the sub-ether JTIDS net back to Starfleet HQ). Now obviously the upgraded mission computer software would have to go through the normal integration test/qualification process - everyone can see that. And equally obviously the physical clearances on the mission computer *hardware* could just be read across, because we haven't changed anything, have we? After all, we only changed the software. Well unfortunately this isn't true. Firstly this sensor presents primarily hi-resolution, rapidly changing video images, so the video processor in the MC is now running at five times the utilisation that it was with the previous software, and thus runs hotter. This influences the thermal environment inside the MC and knocks onto the cooling requirements of other internal sub-systems so that now the numeric processor overheats and fails after 10 minutes. There are some people who spot this one, so whilst it's rare it's not unheard of to consider whether the thermal qualification of the equipment should be revisited as part of the design process. But what about the EMC qualification? We've changed nothing *outside* the box and the new sensor is only communicating over the existing Mil-Std-1553 databus, so this [expensive] testing surely doesn't need repeating. Or does it? The MC was designed with upgrade capacity in all major respects, and one of these is I/O - there are a number of unused interfaces or a variety of types in the I/O subsystem. But that's not a problem because they're all clamped low in the software. So when an unintended coding error inadvertently unclamps one of the inputs (a high impedance one) and admits external signals the condition is not checked in testing. This signal is then picked up by an adjacent small-signal navigation input which IS used, and corrupts its data - something that isn't discovered until the system enters service and is illuminated by Klingon sensor beams. Of course this is a purely hypothetical case, and has certainly never happened on any major military fast jet programme in the western world. Not ever. No sir, absolutely not! The very idea! But it is perhaps worth remembering that software changes the characteristics of hardware, so when designing ANY software change the qualification of the hardware (and the required test cases) should ALWAYS at least be formally reviewed and repeated where necessary. PDR
The idea of a digital notary was patented some time ago, and a company (Surety Technologies, Inc.) started to provide the service. But it was not a great commercial success. http://www.interesting-people.org/archives/interesting-people/199403/msg00100.html http://www.math.columbia.edu/~bayer/papers/Timestamp_BHS93.pdf http://www.sciencenews.org/pages/pdfs/data/1995/147-09/14709-15.pdf http://www.oasis-open.org/committees/dss/ipr.php [Also noted by Jeremy Epstein. PGN]
Ferdinand Reinke suggests a digital notary service, and describes a number of cases, and a number of keypairs. There might be a simpler orp protocol. 1. I want to notarise my wonderful protocol document, before showing it to the venture capitalists. So I send an SHA1 sum of it to the notary. 2. The notary publishes it on a webpage (or a newsgroup or a mailing list), along with the list of all the similar sums they've seen today, or this week, or this month. They let the Internet back it up; I'll certainly hold on to a copy. 3. At the same interval as the notary publishes that list, they publish its checksum in some suitable newspaper of record. In fact, you could do step 3 yourself, and short-circuit the whole process, but where's the VC fun in that? In fact, something like this has been running since 1995, at <http://www.itconsult.co.uk/stamper/stampinf.htm>. It's concerned with the slightly more elaborate problem of corroborating when a document was PGP signed, and publishes its summaries to comp.security.pgp.announce (the only thing there apart from spam, as far as I can see). I fear a single chequebook may continue to be sufficient... All the best, Norman Gray : http://nxg.me.uk eurovotech.org : University of Leicester, UK
It is said that 'security is inversely proportional to convenience', and a recent contribution to RISKS illustrates this proposition quite well. In 24.63, David Brunberg, writing on the British crushed car fiasco, says: > As has been reported elsewhere, > http://www.cs.cmu.edu/afs/cs.cmu.edu/user/wbardwel/public/nfalist/rip/index.html > the NFRTR has been in deplorable condition for some time. > Many registration documents have been lost by ATFE, and some were even > willfully destroyed by ATFE contract employees in a well documented > case. My apologies for the wrapped URL... but lets take a closer look *at* that URL, shall we? Oh, my: it seems to be an Andrew File System path, exposed via the campus's CS department webserver. Convenient? Certainly. But making the individual components of a) CMU's internal DNS and b) the pathnames of files on individual machines in that domain visible to the general public at large is a decision that, perhaps, could use some additional review? We know now not only that user's internal id, but also the name of his machine, and several details of his internal directory structure, which might leak useful information to the outside world. In this *particular* case, of course, the machine is the central CS machine, and the file in a user's public subdirectory. But students or staff at that university might well be able to take advantage of their knowledge of internal conventions on such issues... There's a second possible layer of the same problem in the fact that AFS uses DNS for it's second address layer, if in fact that's wired into the protocol — I'm not that familiar with AFS. But all these versions of this problem imply a certain requirement for administrative and architectural care — designing a network where these requirements won't leak information useful to a Bad Guy, if possible — and possibly also user training — if you can't tighten things all the way, then your users will have to exercise due care. Similar examples exists where @aol.com e-mail addresses are generally usable for attempting to contact someone via AIM, and where SMS addresses are generally the same as the voice number for a cellphone; these are both instances where some circumstances would make it useful for those namespaces to be disjoint... Certainly readers can discern other similar namespace overloading situations for themselves, and intuit the potential problems... Jay R. Ashworth, Ashworth & Associates, St Petersburg FL USA +1 727 647 1274 http://baylink.pitas.com firstname.lastname@example.org
This sort of thing happens in North as well as South America. One reason I closed my US bank account was that I couldn't use its web site because it insisted on being told my 5-digit zip code. New Zealand and Australia use 4 digits, and UK uses varying numbers of letters and digits, and also a blank space in the middle. The obvious conclusion was that the bank didn't want its non-US customers. (The bank wasn't the same one I had opened an account at in Evanston, IL, when living there for a few months, but was the one that took over the one that took that one over.) New Zealand's provinces were abolished in November 1876, but many North American web sites ask for my state or province. I know which one Wellington was in, and I duly tell the inquirers, but what do they do with data 130 years out of date? John Harper, Statistics and Computer Science, Victoria University, PO Box 600, Wellington 6140, New Zealand (+64)(4)463 5341
I was staying at a major hotel chain, returned to my room to find that the key card would not work. I was retrying it, jiggling door etc. when another guest came to the door. He had just checked in, my stuff was still in the room from me getting there earlier. We went to front desk together to get this straightened out. Turns out, the hotel key card system is on a different computer than the hotel reservations and guest billing system. They check us in, write down our # on the little envelope the key card goes in, then in the door security system, rescramble that door password & the computer writes it onto the magnetic strip given to latest guest. When transcribing guest room # from billing computer to envelope, or into the door security system, in the words of the desk clerk "Mistakes happen ALL THE TIME." In our case, they had intended to give the new guest some other room than the one for me. There are other combinations of what can go wrong with the system. So when you get into your room, be sure to lock yourself in ... you could be taking a shower, in bed, along comes another guest. In wee hours, the front desk not attended, you have to ring the bell a lot. Seems to me the computer systems accessible to some crook who would not ring the bell. When I got back home, I told co-workers about this. It had been on a business trip. Co-workers who travel more often than me told me that this sort of thing is not unusual.
The First ACM Computer Security Architecture Workshop (CSAW, pronounced SEE-SAW) will be held 2 Nov 2007 at George Mason University in Fairfax, Virginia, in conjunction with the 2007 ACM Conference on Computers and Communications. Papers on system security architectures, their interfaces, implementations, and implications are due by 17 Jun 2007. See the website for details: http://www.rites.uic.edu/csaw
2007 USENIX Annual Technical Conference June 17-22, 2006, Santa Clara, CA Early Bird Registration Deadline: June 1, 2007 http://www.usenix.org/usenix07/proga Jeff Chase, Duke University Srinivasan Seshan, Carnegie Mellon University USENIX '07 Program Co-Chairs email@example.com
BKMSITIL.RVW 20070119 "Measuring ITIL", Randy A. Steinberg, 2006, 1-4120-9392-9 %A Randy A. Steinberg RandyASteinberg@aol.com %C Suite 6E, 2333 Government Street, Victoria, BC V8T 4P4 %D 2006 %G 1-4120-9392-9 %I Trafford Publishing %O 888-232-4444 FAX 250-383-6804 sales@trafford.Com %O http://www.amazon.com/exec/obidos/ASIN/1412093929/robsladesinterne http://www.amazon.co.uk/exec/obidos/ASIN/1412093929/robsladesinte-21 %O http://www.amazon.ca/exec/obidos/ASIN/1412093929/robsladesin03-20 %O Audience s- Tech 1 Writing 1 (see revfaq.htm for explanation) %P 154 p. %T "Measuring ITIL" Chapter one is supposed to be an introduction to the book. Unfortunately, it jumps right in without bothering to define some basics (such as what ITSM is, and why we should want to measure it). (It probably stands for Information Technology Services Management, since ITIL, the Information Technology Infrastructure Library is about that topic.) Purportedly an overview of metrics, chapter two is actually an exhortation to measure things. Aspects of a metrics model framework are listed in chapter three, although the details don't do much to explain any overall structure or operation. Chapter four is a set of tables of incident response metrics. Unfortunately, the material is cyclically self-referential, without ever explaining real details. Similar non-definitions are given for various management areas in subsequent chapters: problems in five, change in six, release in seven, configuration in eight, service desk (no management) in nine, service levels in ten, availability in eleven, capacity in twelve, service continuity in thirteen, IT financials in fourteen, and IT workforce in fifteen. (If you are well familiar with ITIL you will recognize the structure, but the book does not explain it.) Chapter sixteen suggests that if you have very few sources of metrics, then you should collect and display a few metrics. Chapter seventeen describes the DICE (Duration, Integrity, Commitment, Effort) model that attempts to predict the likelihood of success of an ITIL (the first time the Information Technology Infrastructure Library is materially mentioned in the book, despite the title) implementation. Unfortunately, the text stops short of really explaining how to use the model, or calculate the parameters you are to enter. There is a tiny bit more information on the ITSM Metrics Model Tool, in chapter eighteen, but unfortunately the detail is on the output side, rather than input. Chapter nineteen outlines a full program (including an enormous staff) for using the metrics, but, since everything is based on measurements that have not been fully explained, it is hard to say how useful all of this is. If you are fully versed in ITIL, this book might help you decide how to measure your operations. Mind you, if you are completely familiar with ITIL, and are using it, you probably already have your own metrics in hand. copyright Robert M. Slade, 2007 BKMSITIL.RVW 20070119 firstname.lastname@example.org email@example.com firstname.lastname@example.org http://victoria.tc.ca/techrev/rms.htm
Please report problems with the web pages to the maintainer