I'm Pimping a Webinar, of all things--But it's Peter Neumann on Risk

I am doing a lot of weird miscellaneous work this weekend because I expect to be out of the office for most (or all) of Monday and Tuesday. My calendar does not show anything for 5/22, which is a Good Thing, because it let me plug in an ACM Learning Webinar. What's that, you say? A Webinar? We hates us some Webinars.

But this is Lessons from the ACM Risks Forum. The Presenter is Peter Neumann, who is pretty much a
bottomless pit of qualifications, and if you don't read the Risks Digest (Forum On Risks To The Public In Computers And Related Systems, ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator) you might consider it.

It is available to the public; you do not have to belong to ACM. If you can't make it, you might want to register anyway--they become available on-demand if you do. At least I think they do. I have been an ACM member since long before they did these--possibly that feature is only available to members, but I don't think so.

You have to love a guy who has a favorite meta-limeric:

There once was a man overweaning
Who expounded the meaning of meaning.
In the limelight he basked
'Til at last he was asked
The meaning of meaning of meaning.

There is no meta- in my favorite limerics, and they mostly start with something like:
There once was a man from Nantucket
And they rapidly become NSFW. I can't even aspire to meta-limericdom.

Neumann has pointed out some important issues for a very long time. I don't know how many of you have read The Clock Grows at Midnight (1991), but that was one of the several things that taught me the importance of time. And not just from a log correlation standpoint. I have long said that time services are one of the most important network services, but this is slap-you-in-the-face important, from quite a while back.

In Colorado Springs, a child was killed and another was injured at a traffic crossing, when the school-schedule-dependent computer controlling the street crossing did not properly receive the time transmitted by the atomic clock in Boulder.

Design flaws in safety-critical embedded systems can have tragic consequences. In this case, it seems quite possible that the flaws extended to hardware. But then it often does, in the embedded world.

We are obviously not growing less dependent on accurate time-keeping, and things like supplanting classic Unix-y cron with chrony are important enough that the implications deserve thought*. Thank you, Peter Neumann. BTW, the first reference in that paper was to Leslie Lamport--Synchronizing clocks in the presence of faults. Another long-time and influential contributor, which is why I was extremely happy to post Congratulations to Leslie Lamport, winner of the 2013 Turing Award back in March.


* No, I am not knocking chrony; consideration of implications is not synonymous with Don't Do This.