text:
Watson the Doctor is no laughing matter
For the past year, oncologists at the Memorial Sloan Kettering Cancer Centre in New York have been training IBM's Watson – the artificial intelligence tour-de-force that beat allcomers on Jeopardy – to help personalise cancer care. The Centre explains that "combining [their] expertise with the analytical speed of IBM Watson, the tool has the potential to transform how doctors provide individualized cancer treatment plans and to help improve patient outcomes". Others are speculating already that Watson could "soon be the best doctor in the world".
I have no doubt that when Watson and things like it are available online to doctors worldwide, we will see overall improvements in healthcare outcomes, especially in parts of the world now under-serviced by medical specialists [having said that, the value of diagnosing cancer in poor developing nations is questionable if they cannot go on to treat it]. As with Google's self-driving car, we will probably get significant gains eventually, averaged across the population, from replacing humans with machines. Yet some of the foibles of computing are not well known and I think they will lead to surprises.
For all the wondrous gains made in Artificial Intelligence, where Watson now is the state-of-the art, A.I. remains algorithmic, and for that, it has inherent limitations that don't get enough attention. Computer scientists and mathematicians have know for generations that some surprisingly straightforward problems have no algorithmic solution. That is, some tasks cannot be accomplished by any universal step-by-step codified procedure. Examples include the Halting Problem and the Travelling Salesperson Problem. If these simple challenges have no algorithm, we need be more sober in our expectations of computerised intelligence.
A key limitation of any programmed algorithm is that it must make its decisions using a fixed set of inputs that are known and fully characterised (by the programmer) at design time. If you spring an unexpected input on any computer, it can fail, and yet that's what life is all about -- surprises. No mathematician seriously claims that what humans do is somehow magic; most believe we are computers made of meat. Nevertheless, when paradoxes like the Halting Problem abound, we can be sure that computing and cognition are not what they seem. We should hope these conundrums are better understood before putting too much faith in computers doing deep human work.
And yet, predictably, futurists are jumping ahead to imagine "Watson apps" in which patients access the supercomputer for themselves. Even if there were reliable algorithms for doctoring, I reckon the "Watson app" is a giant step, because of the complex way the patient's conditions are assessed and data is gathered for the diagnosis. That is, the taking of the medical history.
In these days of billion dollar investments in electronic health records (EHRs), we tend to think that medical decisions are all about the data. When politicians announce EHR programs they often boast that patients won't have to go through the rigmarole of giving their history over and over again to multiple doctors as they move through an episode of care. This is actually a serious misunderstanding of the importance in clinical decision-making of the interaction between medico and patient when the history is taken. It's subtle. The things a patient chooses to tell, the things they seem to be hiding, and the questions that make them anxious, all guide an experienced medico when taking a history, and provide extra cues (metadata if you will) about the patient's condition.
Now, Watson may well have the ability to navigate this complexity and conduct a very sophisticated Q&A. It will certainly have a vastly bigger and more reliable memory of cases than any doctor, and with that it can steer a dynamic patient questionnaire. But will Watson be good enough to be made available direct to patients through an app, with no expert human mediation? Or will a host of new input errors result from patients typing their answers into a smart phone or speaking into a microphone, without any face-to-face subtlety (let alone human warmth)? It was true of mainframes and it's just as true of the best A.I.: Bulldust in, bulldust out.
Finally, Watson's existing linguistic limitations are not to be underestimated. It is surely not trivial that Watson struggles with puns and humour. Futurist Mark Pesce when discussing Watson remarked in passing that scientists don't understand the "quirks of language and intelligence" that create humour. The question of what makes us laugh does in fact occupy some of the finest minds in cognitive and social science. So we are a long way from being able to mechanise humour. And this matters because for the foreseeable future, it puts a great deal of social intercourse beyond AI's reach.
In between the extremes of laugh-out-loud comedy and a doctor's dry written notes lies a spectrum of expressive subtleties, like a blush, an uncomfortable laugh, shame, and the humiliation that goes with some patients' lived experience of illness. Watson may understand the English language, but does it understand people?
Watson can answer questions, but good doctors ask a lot of questions too. When will this amazing computer be able to hold the sort of two-way conversation that we would call a decent "bedside manner"?
Have a disruptive technology implementation story? Get recognised for your leadership. Apply for the 2014 SuperNova Awards for leaders in disruptive technology.
Posted in Software engineering, Science, Language, e-health, Culture, Big Data
Security Heartache
For the second time in as many months, a grave bug has emerged in core Internet security software. In February it was the "Goto Fail" bug in the Apple operating system iOS that left web site security inoperable; now we have "Heartbleed", a flaw that leaves many secure web servers in fact open to attackers sniffing memory contents looking for passwords and keys.
Who should care?
There is no shortage of advice on what to do if you're a user. And it's clear how to remediate the Heartbleed bug if you're a web administrator (a fix has been released). But what is the software fraternity going to do to reduce the incidence of these disastrous human errors? In my view, Goto Fail and Heartbleed are emblematic of chaotic software craftsmanship. It appears that goto statements are used with gay abandon throughout web software today, creating exactly the unmaintainable spaghetti code that the founders of Structured Programming warned us about in the 1970s. Testing is evidently lax; code inspection seems non-existent. The Heartbleed flaw is in a piece of widely used Open Source software, and was over-looked first by the programmer, and then by the designated inspector, and then it went unnoticed for two years in the wild.
What are the ramifications of Heartbleed?
"Heartbleed" is a flaw in an obscure low level feature of the "Transport Layer Security" (TLS) protocol. TLS has an optional feature dubbed "Heartbeat" which a computer connected in a secure session can use to periodically test if the other computer is still alive. Heartbeat involves sending a request message with some dummy payload, and getting back a response with duplicate payload. The bug in Heartbeat means the responding computer can be tricked into sending back a dump of 64 kiloytes of memory, because the payload length variable goes unchecked. (For the technically minded, this error is qualitatively similar to a buffer overload; see also the OpenSSL Project description of the bug). Being server memory used in security management, that random grab has a good chance of including sensitive TLS-related data like passwords, credit card numbers and even TLS session keys. The bug is confined to the OpenSSL security library, where it was introduced inadvertently as part of some TLS improvements in late 2011.
The flawed code is present in almost all Open Source web servers, or around 66% of all web servers worldwide. However not all servers on the Internet run SSL/TLS secure sessions. Security experts Netcraft run automatic surveys and have worked out that around 17% of all Internet sites would be affected by Heartbleed – or around half a million widely used addresses. These include many banks, financial services, government services, social media companies and employer extranets. An added complication is that the Heartbeat feature leaves no audit trail, and so a Heartbleed exploit is undetectable.
If you visit an affected site and start a secure ("padlocked") session, then an attacker that knows about Heartbleed can grab random pieces of memory from your session. Researchers have demonstrated that session keys can be retrieved, although it is said to be difficult. Nevertheless, Heartbleed has been described by some of the most respected and prudent commentators as catastrophic. Bruce Schneier for one rates its seriousness as "11 out of 10".
Should we panic?
No. The first rule in any emergency is "Don't Panic". But nevertheless, this is an emergency.
The risk of any individual having been harmed through Heartbleed is probably low, but the consequences are potentially grave (if for example your bank is affected). And soon enough, it will be simple and cheap to take action, so you will hear experts say 'it is prudent to assume you have been compromised' and to change your passwords.
However, you need to wait rather than rush into premature action. Until the websites you use have been fixed, changing passwords now may leave you more vulnerable, because it's highly likely that criminals are trying to exploit Heartbleed while they can. It's best to avoid using any secure websites for the time being. We should redouble the usual Internet precautions: check your credit card and bank statements (but not online for the time being!). Stay extra alert to suspicious looking emails not just from strangers but from your friends and colleagues too, for their cloud mail accounts might have been hacked. And seek out the latest news from your e-commerce sites, banks, government and so on. The Australian banks for instance were relatively quick to act; by April 10 the five biggest institutions confirmed they were safe.
Lessons for the Software Craft
Heartbleed for me is the last straw. I call it pathetic that mission critical code can harbour flaws like this. So for a start, in the interests of clarity, I will no longer use the term "Software Engineering". I've written a lot in the past about the practice and the nascent profession of programming but it seems we're just going backwards. I'm aware that calling programming a "craft" will annoy some people; honestly, I mean no offence to basket weavers.
I'm no merchant of doom. I'm not going to stop banking and shopping online (however I do refuse Internet facing Electronic Health Records, and I would not use a self-drive car). My focus is on software development processes and system security.
The modern world is increasingly dependent on software, so it passes understanding we still tolerate such ad hoc development processes.
The programmer responsible for the Heartbleed bug has explained that he made a number of changes to the code and that he "missed validating a variable" (referring to the unchecked length of the Heartbeat payload). The designated reviewer of the OpenSSL changes also missed that the length was not validated. The software was released into the wild in March 2012. It went unnoticed (well, unreported) until a few weeks ago and was rectified in an OpenSSL release on April 7.
I'd like to avoid apportioning individual blame, so I am not interested in the names of the programmer and the reviewer. But we have to ask: when so many application security issues boil down to overflow problems, why is it not second nature to watch out for bugs like Heartbleed? How did experienced programmers make such an error? Why was this flaw out in the wild for two years before it was spotted? I thought one of the core precepts of Open Source Software was that having many eyes looking over the code means that errors will be picked up. But code inspection seems not to be widely practiced anymore. There's not much point having open software if people aren't actually looking!
As an aside, criminal hackers know all about overflow errors and might be more motivated to find them than innocent developers. I fear that the Heartbleed overflow bug could have been noticed very quickly by hackers who pore over new releases looking for exactly this type of exploit, or equally by the NSA which is reported to have known about it from the beginning.
Where does this leave systems integrators and enterprise developers? Have they become accustomed to taking Open Source Software modules and building them in, without a whole lot of regression testing? There's a lot to be said for Free and Open Source Software (FOSS) but no enterprise can take "free" too literally; the total cost of development has to include reasonable specification, verification and testing of the integrated whole.
As discussed in the wake of Goto Fail, we need to urgently and radically lift coding standards.
Posted in Software engineering, Security
gotofail and a defence of purists
'The widely publicised and very serious "gotofail" bug in iOS7 took me back ...
Early in my career I spent seven years in a very special software development environment. I didn't know it at the time, but this experience set the scene for much of my understanding of information security two decades later. I was in a team with a rigorous software development lifecycle; we attained ISO 9001 certification way back in 1998. My company deployed 30 software engineers in product development, 10 of whom were dedicated to testing. Other programmers elsewhere independently wrote manufacture test systems. We spent a lot of time researching leading edge development methodologies, such as Cleanroom, and formal specification languages like Z.
We wrote our own real time multi-tasking operating system; we even wrote our own C compiler and device drivers! Literally every single bit of the executable code was under our control. "Anal" doesn't even begin to describe our corporate culture.
Why all the fuss? Because at Telectronics Pacing Systems, over 1986-1990, we wrote the code for the world's first software controlled implantable defibrillator, the Guardian 4210.
The team spent relatively little time actually coding; we were mostly occupied writing and reviewing documents. And then there were the code inspections. We walked through pseudo-code during spec reviews, and source code during unit validation. And before finally shipping the product, we inspected the entire 40,000 lines of source code. That exercise took five people two months.
For critical modules, like the kernel and error correction routines, we walked through the compiled assembly code. We took the time to simulate the step-by-step operation of the machine code using pen and paper, each team member role-playing parts of the microprocessor (Phil would pretend to be the accumulator, Lou the program counter, me the index register). By the end of it all, we had several people who knew the defib's software like the back of their hand.
And we had demonstrably the most reliable real time software ever written. After amassing several thousand implant-years, we measured a bug rate of less than one in 10,000 lines.
The implant software team had a deserved reputation as pedants. Over 25 person years, the average rate of production was one line of debugged C per team member per day. We were painstaking, perfectionist, purist. And argumentative! Some of our debates were excruciating to behold. We fought over definitions of "verification" and "validation"; we disputed algorithms and test tools, languages and coding standards. We were even precious about code layout, which seemed to some pretty silly at the time.
Yet 20 years later, purists are looking good.
Last week saw widespread attention to a bug in Apple's iOS operating system which rendered website security impotent. The problem arose from a single superfluous line of code – an extra goto statement – that nullified checking of SSL connections, leaving users totally vulnerable to fake websites. The Twitterverse nicknamed the flaw #gotofail.
There are all sorts of interesting quality control questions in the #gotofail experience.
- Was the code inspected? Do companies even do code inspections these days?
- The extra goto was said to be a recent change to the source; if that's the case, what regression testing was performed on the change?
- How are test cases selected?
- For something as important as SSL, are there not test rigs with simulated rogue websites to stress test security systems before release?
There seems to have been egregious shortcomings at every level : code design, code inspection, and testing.
A lot of attention is being given to the code layout. The spurious goto is indented in such a way that it appears to be part of a branch, but it is not. If curly braces were used religiously, or if an automatic indenting tool was applied, then the bug would have been more obvious (assuming that the code gets inspected). I agree of course that layout and coding standards are important, but there is a much more robust way to make source code clearer.
Beyond the lax testing and quality control, there is also a software-theoretic question in all this that is getting hardly any attention: Why are programmers using ANY goto statements at all?
I was taught at college and later at Telectronics to avoid goto statements at all cost. Yes, on rare occasions a goto statement makes the code more compact, but with care, a program can almost always be structured to be compact in other ways. Don't programmers care anymore about elegance in logic design? Don't they make efforts to set out their code in a rigorous structured manner?
The conventional wisdom is that goto statements make source code harder to understand, harder to test and harder to maintain. Kernighan and Ritchie - UNIX pioneers and authors of the classic C programming textbook - said the goto statement is "infinitely abusable" and it "be used sparingly if at all." Before them, one of programming's giants, Edsger Dijkstra, wrote in 1968 that "The go to statement ... is too much an invitation to make a mess of one's program"; see Go To Statement Considered Harmful. The goto creates spaghetti code. The landmark structured programming language PASCAL doesn't even have a goto statement! At Telectronics our coding standard prohibited without exception gotos in all implantable software.
Hard to understand, hard to test and hard to maintain is exactly what we see in the flawed iOS7 code. The critical bug never would have happened if Apple too banned the goto.
Now, I am hardly going to suggest that fanatical coding standards and intellectual rigor are sufficient to make software secure (see also "Security Isn't Secure). It's unlikely that many commercial developers will be able to cost-justify exhaustive code walkthroughs when millions of lines are involved even in the humble mobile phone. It's not as if lives depend on commercial software.
Or do they?!
Let's leave aside that vexed question for now and return to fundamentals.
The #gotofail episode will become a text book example of not just poor attention to detail, but moreover, the importance of disciplined logic, rigor, elegance, and fundamental coding theory.
A still deeper lesson in all this is the fragility of software. Prof Arie van Deursen nicely describes the iOS7 routine as "brittle". I want to suggest that all software is tragically fragile. It takes just one line of silly code to bring security to its knees. The sheer non-linearity of software – the ability for one line of software anywhere in a hundred million lines to have unbounded impact on the rest of the system – is what separates development from conventional engineering practice. Software doesn't obey the laws of physics. No non-trivial software can ever fully tested, and we have gone too far for the software we live with to be comprehensively proof read. We have yet to build the sorts of software tools and best practice and habits that would merit the title "engineering".
I'd like to close with a philosophical musing that might have appealed to my old mentors at Telectronics. We have reached a sort of pinnacle in post-modernism where the real world has come to pivot precariously on pure text. It is weird and wonderful that engineers are arguing about the layout of source code – as if they are poetry critics.
We have come to depend daily on great obscure texts, drafted not by people we can truthfully call "engineers" but by a largely anarchic community we would be better of calling playwrights.
Posted in Software engineering, Security
Security Isn't Secure
That is, information security is not intellectually secure. Almost every precept of orthodox information security is ready for a shake-up. Infosec practices are built on crumbling foundations.
UPDATE: I've been selected to speak on this topic at the 2014 AusCERT Conference - the biggest information security event in Australasia.
The recent tragic experience of data breaches -- at Target, Snapchat, Adobe Systems and RSA to name a very few -- shows that orthodox information security is simply not up to the task of securing serious digital assets. We have to face facts: no amount of today's conventional security is ever going to protect assets worth billions of dollars.
Our approach to infosec is based on old management process standards (which can be traced back to ISO 9000) and a ponderous technology neutrality that overly emphasises people and processes. The things we call "Information Security Management Systems" are actually not systems that any engineer would recognise but instead are flabby sets of documents and audit procedures.
"Continuous security improvement" in reality is continuous document engorgement.
Most ISMSs sit passively on shelves and share drives doing nothing for 12 months, until the next audit, when the papers become the centre of attention (not the actual security). Audit has become a sick joke. ISO 27000 and PCI assessors have the nerve to tell us their work only provides a snapshot, and if a breach occurs between visits, it's not their fault. In their words they admit therefore that audits do not predict performance between audits. While nobody is looking, our credit card numbers are about as secure as Schrodinger's Cat!
The deep problem is that computer systems have become so very complex and so very fragile that they are not manageable by traditional means. Our standard security tools, including Threat & Risk Assessment and hierarchical layered network design, are rooted in conventional engineering. Failure Modes & Criticality Analysis works well in linear systems, where small perturbations have small effects, but IT is utterly unlike this. The smallest most trivial omission in software or in a server configuration can have dire and unlimited consequences. It's like we're playing Jenga.
Update: Barely a month after I wrote this blog, we heard about the "goto fail" bug in the Apple iOS SSL routines, which resulted from one spurious line of code. It might have been more obvious to the programmer and/or any code reviewer had the code been indented differently or if curly braces were used rigorously.
Security needs to be re-thought from the ground up. We need some bigger ideas.
We need less rigid, less formulaic security management structures, to encourage people at the coal face to exercise their judgement and skill. We need straight talking CISOs with deep technical experience in how computers really work, and not 'suits' more focused on the C-suite than the dev teams. We have to stop writing impenetrable hierarchical security policies and SOPs (in the "waterfall" manner we recognised decades ago fails to do much good in software development). And we need to equate security with software quality and reliability, and demand that adequate time and resources be allowed for the detailed work to be done right.
If we can't protect credit card numbers today, we urgently need to do things differently, standing as we are on the brink of the Internet of Things.
Posted in Software engineering, Security
Designing Privacy by Design
I am speaking at next week's AusCERT security conference, on how to make privacy real for technologists. This is an edited version of my conference abstract.
Privacy by Design is a concept founded by the Ontario Privacy Commissioner Dr. Ann Cavoukian. Dubbed "PbD", it's basically the same good idea as designing in quality, or designing in security. It has caught on nicely as a mantra for privacy advocates worldwide. The trouble is, few designers or security professionals can tell what it means.
Privacy continues to be a bit of a jungle for security practitioners. It's not that they're uninterested in privacy; rather, it's rare for privacy objectives to be expressed in ways they can relate to. Only one of the 10 or 11 or more privacy principles we have in Australia is ever labelled "security" and even then, all it will say is security must be "reasonable" given the sensitivity of the Personal Information concerned. With this legalistic language, privacy is somewhat opaque to the engineering mind; security professionals naturally see it as meaning little more than encryption and maybe some access control.
To elevate privacy practice from the personal plane to the professional, we need to frame privacy objectives in a way that generates achievable design requirements. This presentation will showcase a new methodology to do this, by extending the familiar standardised Threat & Risk Assessment (TRA). A hybrid Privacy & Security TRA adds extra dimensions to the information asset inventory. Classically an information asset inventory accounts for the confidentiality, integrity and availability (C.I.A.) of each asset; the extended methodology goes further, to identify which assets represent Personal Information, and for those assets, lists privacy related attributes like consent status, accessibility and transparency. The methodology also broadens the customary set of threats to include over-collection, unconsented disclosure, incomplete responses to access requests, over-retention and so on.
The extended TRA methodology brings security and privacy practices closer together, giving real meaning to the goal of Privacy by Design. Privacy and security are sometimes thought to be in conflict, and indeed they often are. We should not sugar coat this; after all, systems designers are of course well accustomed to tensions between competing design objectives. To do a better job at privacy, security practitioners need new tools like the Security & Privacy TRA to surface the requirements in an actionable way.
The hybrid Threat & Risk Assessment
TRAs are widely practiced during requirements analysis stages of large information systems projects. There are a number of standards that guide the conduct of TRAs, such as ISO 31000. A TRA first catalogues all information assets controlled by the system, and then systematically explores all foreseeable adverse events that threaten those assets. Relative risk is then gauged, usually as a product of threat likelihood and severity, and the set of threats to be prioritised according to importance. Threat mitigations are then considered and the expected residual risks calculated. An especially good thing about a formal TRA is that it presents management with the risk profile to be expected after the security program is implemented, and fosters consciousness of the reality that finite risks always remain.
The diagram below illustrates a conventional TRA workflow (yellow), plus the extensions to cover privacy design (red). The important privacy qualities of Personal Information assets include Accessibility, Permissibility (to disclose), Sensitivity (of e.g. health information), Transparency (of the reasons for collection) and Quality. Typical threats to privacy include over-collection (which can be an adverse consequence of excessive event logging or diagnostics), over-disclosure, incompleteness of records furnished in response to access requests, and over-retention of PI beyond the prima facie business requirement. When it comes to mitigating privacy threats, security practitioners may be pleasantly surprised to find that most of their building blocks are applicable.
The hybrid Security-Privacy Threat & Risk Assessment will help ICT practitioners put Privacy by Design into practice. It helps reduce privacy principles to information systems engineering requirements, and surfaces potential tensions between security practices and privacy. ICT design frequently deals with competing requirements. When engineers have the right tools, they can deal properly with privacy.
Posted in Software engineering, Security, Privacy
Let's talk about privacy, in engineering terms
I have come to believe that a systemic conceptual shortfall affects typical technologists' thinking about privacy. It may be that engineers tend to take literally the well-meaning slogan that "privacy is not a technology issue". I say this in all seriousness.
Online, we're talking about data privacy, or data protection, but systems designers tend to bring to work a spectrum of personal outlooks about privacy in the human sphere. Yet what matters is the precise wording of data privacy law, like Australia's Privacy Act. To illustrate the difference, here's the sort of experience I've had time and time again.
During the course of conducting a PIA in 2011, I spent time with the development team working on a new government database. These were good, senior people, with sophisticated understanding of information architecture. But they harboured restrictive views about privacy. An important clue was the way they referred to "private" information rather than Personal Information (or equivalently, Personally Identifiable Information, PII). After explaining that Personal Information is the operable term in Australian legislation, and reviewing its definition from the Privacy Act, we found that the team had failed to appreciate the extent of the PI in their system. They overlooked that most of their audit logs collect PI, albeit indirectly and automatically. Further, they had not appreciated that information about clients in their register provided by third parties was also PI (despite it being intuitively "less private" by virtue of originating from others). I attributed these blind spots to the developers' weak and informal frame of "private" information. Online and in data privacy law alike, things are very crisp. The definition of Personal Information -- namely any data relating to an individual whose identity is readily apparent -- sets a low bar, embracing a great many data classes and, by extension, informatics processes. It's a nice analytical definition that is readily factored into systems analysis. After the team got that, the PIA in question proceeded apace and we found and rectified several privacy risks that had gone unnoticed.
Here are some more of the many recurring misconceptions I've noticed over the past decade:
- "Personal" Information is sometimes taken to mean especially delicate information such as payment card details, rather than any information pertaining to an identifiable individual such as email addresses in many cases; an exchange between US data breach analyst Jake Kouns and me over the Epsilon incident in 2011 is revealing of a technologists' systemically narrow idea of PII;
- the act of collecting PI is sometimes regarded only in relation to direct collection from the individual concerned; technologists can overlook that PI provided by a third party to a data custodian is nevertheless being collected by the custodian, and they can fail to appreciate that generating PI internally, through event logging for instance, can also represent collection
- even if they are aware of points such as Australia's Access and Correction Principle, database administrators can be unaware that, technically, individuals requesting a copy of information held about them should also be provided with pertinent event logs; a non-trivial case where individuals can have a genuine interest in reviewing event logs is when they want to know if an organisation's staff have been accessing their records.
These instances, among many others in my experience working across both information security and privacy, show that ICT practitioners suffer important gaps in their understanding. Security professionals in particular may be forgiven for thinking that most legislated Privacy Principles are legal niceties irrelevant to them, for generally only one of the principles in any given set is overtly about security; see:
- no. 5 of the eight OECD Privacy Principles
- no. 4 of the five Fair Information Practice Principles in the US
- no. 8 of the ten Generally Accepted Privacy Principles of the US and Canadian accounting bodies,
- no. 4 of the ten old National Privacy Principles of Australia, and
- no. 11 of the 13 new Australian Privacy Principles (APPs).
Yet every one of the privacy principles is impacted by information technology and security practices; see Mapping Privacy requirements onto the IT function, Privacy Law & Policy Reporter, Vol. 10.1& 10.2, 2003. I believe the gaps in the privacy knowledge of ICT practitioners are not random but are systemic, probably resulting from privacy training for non-privacy professionals being ad hoc and not properly integrated with their particular world views.
To properly deal with data privacy, ICT practitioners need to have privacy framed in a way that leads to objective design requirements. Luckily there already exist several unifying frameworks for systematising the work of dev teams. One example that resonates strongly with data privacy practice is the Threat & Risk Assessment (TRA).
The TRA is an infosec requirements analysis tool, widely practiced in the public and private sectors. There are a number of standards that guide the conduct of TRAs, such as ISO 31000. A TRA is used to systematically catalogue all foreseeable adverse events that threaten an organisation's information assets, identify candidate security controls (considering technologies, processes and personnel) to mitigate those threats, and most importantly, determine how much should be invested in each control to bring all risks down to an acceptable level. The TRA process delivers real world management decisions, understanding that non zero risks are ever present, and that no organisation has an unlimited security budget.
I have found that in practice, the TRA exercise is readily extensible as an aid to Privacy by Design. A TRA can expressly incorporate privacy as an attribute of information assets worth protecting, alongside the conventional security qualities of confidentiality, integrity and availability ("C.I.A."). A crucial subtlety here is that privacy is not the same as confidentiality, yet many frequently conflate the two. A fuller understanding of privacy leads designers to consider the Collection, Use, Disclosure and Access & Correction principles, over and above confidentiality when they analyse information assets.
Lockstep continues to actively research the closer integration of security and privacy practices.
Posted in Software engineering, Security, Privacy
A software engineer's memoir (work in progress)
I'm an ex software "engineer" [I have reservations about that term] with some life experience of ultra high rel development practices. It's fascinating how much about software quality I learned in the 1980s and 90s is relevant to info sec today.
I've had a trip down memory lane triggered by Karen Sandler's presentation at LinuxConf12 in Ballarat http://t.co/xvUkkaGl and her paper "Killed by code".
The software in implantable defibrillators
I'm still working my way through Karen Sandler's materials. So this post is a work in progress.
What's really stark on first viewing of Karen's talk is the culture she experienced and how it differs from the implantable defib industry I knew in its beginnings 25 years ago.
Karen had an incredibly hard and very off-putting time getting the company that made her defib to explain their software. But when we started in this field, every single person in the company -- and many of our doctors -- would have been able to answer the question What software does this defib run on?: the answer was "ours". And moreover, the FDA were highly aware of software quality issues. The whole medical device industry was still on edge from the notorious Therac 25 episode, a watershed in software verification.
A personal story
I was part of the team that wrote the code for the world's first software controlled implantable cadrioverter/defibrillator (ICD).
In 1990 Telectronics (a tragic legend of Australian technology) released the model 4210, which was just the fourth or fifth ICD on the market (the first few being hard-wired devices from CPI Inc. and Telectronics). The computing technology was severely restricted by several design factors, most especially ultra low power consumption, and a very limited number of microprocessor vendors that would warrant their chips for use in medical devices. The 4210 defib used a semi-customised 8 bit micro-controller based on the 6502, and a 32 KB byte-organised SRAM chip that held the entire executable. The micro clocked at 128kHz, fully eight times slower than the near identical micro in the Apple II a decade earlier. The software had to be efficient, not only to ensure it could make some very tough real time rendezvous, but to keep the power consumption down; the micro consumed about 30% of the device's power over its nominal five year lifetime.
Software development
We wrote mostly in C, with some assembly coding for the kernel and some performance sensitive routines. The kernel was of our own design, multi-tasking, with hard real time performance requirements (in particular, for obvious reasons the system had to respond within tight specs to heart beat interrupts and we had to show we weren't ever going to miss an interrupt!) We also wrote the C compiler.
The 4210's software was 40,000 lines of C, developed by a team of 5-6 over several years; the total effort was 25 person-years. Some of the testing and pre-release validation is described in my blog post about coding being like play writing. The final code inspection involved a team of five working five-to-six hour days for two months, reading aloud and understanding every single line. When occasion called for checking assembly instructions, sometimes we took turns with pencil and paper pretending to be the accumulators, the index registers, the program counter and so on. No stone was left unturned.
The final walk-through was quite a personnel management challenge. One of the senior engineers (a genius who also wrote our kernel and compiler) lobbied for inspecting the whole executable because he didn't want to rely on the correctness of the compiler -- but that would have taken six months. So we compromised by walking through only the assembly code for the critical modules, like the tachycardia detector and the interrupt handlers.
I mentioned that the kernel and compiler were home-grown. So this meant that the company controlled literally every single bit of code running in its defibs. And I reiterate we had several individuals who knew the source code end to end.
By the way, these days I will come across developers in the smartcard industry who find it hard working on applets that are 5 or 10 kilobytes small. Compare say a digital signing applet with an ICD, with its cardiac monitoring algorithms, treatment algorithms, telemetry controller, data logging and operating system all squeezed into 32KB.
We amassed several thousand implant-years of experience with the 4210 before it was superseded. After release, we found two or three minor bugs, which we fixed with software upgrades. None would have caused a misfire, neither false positive or false negative.
Yes, for the upgrade we could write into the RAM over a proprietary telemetry protocol. In fact the main reason for the one major software upgrade in the field was to add error correction because after hundreds of device-years we noticed higher than expected bit flips from natural background radiation. That's a helluva story in itself. It was observed that had the code been in ROM, we couldn't have changed it but we wouldn't have had to change it for bit flips either.
Morals of the story
Anyway, some of the morals of the story so far:
- Software then was cool and topical, and the whole company knew how to talk about it. The real experts -- the dozen or so people in Sydney directly involved in the development -- were all well known worldwide by the executives, the sales reps, the field clinical engineers, and regulatory affairs. And we got lots of questions (in contrast to Karen Sandler's experience where all the caridologists and company people said nobody ever asked about the code).
- Everything about the software was controlled by the company: the operating system, the chip platform, the compiler, the telemetry protocol.
- We had a team of people that knew the code like the backs of their hands. Better in fact. It was reliable and, in hindsight, impregnable. Not that we worried about malware back in 1987-1990.
Where has software development gone?
So the sorts of issues that Karen Sandler is raising now, over two decades on, are astonishing to me on so many levels.
- Why would anyone decide to write life support software on someone else's platform?
- Why would they use wifi or Bluetooth for telemetry?
- And if the medical device companies cut corners in software development, one wonders what the defense industry is doing with their drone flight controllers and other "smart" weaponry with its countless millions of lines of opaque software.
Posted in Software engineering, Management theory
Programming is like playwriting
The software-as-a-profession debate continues largely untouched by each generation's innovations in production methods. Most of us in the 90s thought that formal methods, reuse and enforced modularity would introduce to software some of the hallmarks of real engineering: predictability, repeatability, measurability and quality. Yet despite Objected Oriented methods and sophisticated CASE tools, many of the human traits of software-as-a-craft remain with us.
The "software crisis" – the systemic inability to estimate software projects accurately, to deliver what's promised, and to meet quality expectations – is over 40 years old. Its causes are multiple and subtle, and despite ample innovation in languages, tools and methodologies, debates continue over what ails the software industry. The latest skirmish is a provocative suggestion from Forrester analyst Mark Gualtieri that we shift the emphasis from independent Quality Assurance back onto developers' own responsibilities, or abandon QA altogether. There has been a strong reaction! The general devotion to QA I think is aided and abetted by today's widespread fashion for corporate governance.
But we should listen to radical ideas like Gualtieri's, rather than maintain a slavish devotion to orthodoxies. We should recognise that software engineering is inherently different from conventional engineering, because software itself is a different kind of material. Its properties make it less amenable to regular governance.
Simply, software does not obey the laws of physics. Building skyscrapers, tunnels, dams and bridges is relatively predictable. You start with site surveys and foundations, erect a sturdy framework and all sorts of temporary formers, flesh out the structure, fill in the services like power and plumbing, do the fit-out, and finally take away all the scaffolding.
Specifications for real engineering projects don't change much, even over several years for really big initiatives. And the engineering tools don't change at all.
Software is utterly unlike this. You can start writing software anywhere you like, and before the spec is signed off. There aren't any raw materials to specify and buy, and no quantity surveyors to deal with. Metaphorically speaking, the plumbing can go in before the framework. Hell, you don't even need a framework! Nothing physical holds a software system up. Flimsy software, as a material, is indistinguishable from the best code. No laws of physics dictate that you start at the bottom and work your way slowly upwards, using a symbiosis of material properties and gravity to keep your construction stable and well-behaved as it grows. The process of real world engineering is thick with natural constraints that ensure predictability (just imagine how wobbly a house would be if you could lay the bricks from the top down) whereas software development processes are almost totally arbitrary, except for the odd stricture imposed by high level languages.
Real world systems are thoroughly compartmentalised naturally. If a bearing fails in an air-conditioning plant in the basement, it's not going to affect the integrity of any of the floor plates. On the other hand, nothing physically decouples lines of code; a bug in one part of the program can impinge on almost any other part (which incidentally renders traditional failure modes and effects analysis impossible). We only modularise software by artificial means, like banning goto statements and self-modifying code.
Coding is fast and furious. In a single day, a programmer can create a system probably more complex than an airport that takes more than 10,000 person-years to build. And software development is tremendous creative fun. Let's be honest: it's why the majority of programmers chose their craft in the first place.
Ironically the rapidity of programming contributes significantly to software project overruns. We only use software in information systems because it's faster to make and easier to modify than wired logic. So the temptation is irresistible to keep specs fluid and to accommodate new requirements at any time. Famously, the differences between prototype, beta and production product are marginal and arbitrary. Management and marketing take advantage of this fact, and unfortunately software engineers themselves yield too readily to the attraction of the last minute tweak.
I suggest programming is more like play writing than engineering, and many programmers (especially the really good ones!) are just as manageable as poets.
In both software and play writing, structure is almost entirely arbitrary. Because neither obey the laws of physics, the structure of software and plays comes from the act of composition. A good software engineer will know their composition from end to end. But another programmer can always come along and edit the work, inserting their own code as they see fit. It is received wisdom in programming that most bugs arise from imprudent changes made to old code.
Messing with a carefully written piece of software is fraught with danger, just as it is with a finished play. I could take Hamlet for instance, and hack it as easily as I might hack an old program -- add a character or two, or a whole new scene -- but the entire internal logic of the play would almost certainly be wrecked. It would be "buggy".
I was a software development manager for some years in the cardiac pacemaker industry. We developed the world's first software controlled automatic implantable defibrillator. It had several tens of thousands of lines of C, developed at a rate of about one tested line of code per person per day. We quantified it as the most reliable real time software ever written at the time.
I believe the outstanding quality resulted from a handful of special grassroots techniques:
- We had independent software test teams that developed their own test cases and tools
- We did obsessive source code inspections on all units before integration. And in the end, before we shipped, we did an end-to-end walkthrough of the frozen software. It took six of us two months straight. So we had several people who knew the entire object intimately.
- We did early informal design reviews. As team leader, I favoured having my developers do a whiteboard presentation to the team of their early design ideas, no more than 48 hours after being given responsibility for a module. This helped prevent designers latching onto misconceptions at the formative stages.
- We took our time. I was concerned that the CASE tools we introduced in the mid 90s might make code rather too easy to trot out, so at the same time I set a new rule that developers had toturn their workstations off for a whole day once a week, and work with pen and paper.
- My internal coding standard included a requirement that when starting a new module, developers write their comments before they write their code, and their comments had to describe 'why' not 'what'. Code is all syntax; the meaning and intent of any software can only be found in the natural language comments.
Code is so very unlike the stuff of other professions – soil and gravel, metals and alloys, nuts and bolts, electronics, even human flesh and blood - that the metaphor of engineering in the phrase "software engineering" may be dangerously misplaced. By coopting the term we have might have started out on the wrong foot, underestimating the fundamental challenge of forging a software profession. It won't be until software engineering develops the normative tools and standards, culture and patience of a true profession that the software crisis will turn around. And then corporate governance will have something to govern in software development.
Posted in Software engineering, Language, Culture
We're not ready for genetic engineering
Update September 2012
The recent discovery that junk DNA is not actually junk rather reinforces my long standing thesis, espoused below, that we don't know enough about how genes work to be able to validate genetic engineering artifacts by testing alone. I point out that computer programs are only validated by a mixture of testing, code inspection and theory, all of which is based on knowing how the code works at the instruction level. But we don't have a terribly complete picture of how genes interact. We always knew they were massively parallel, and now it turns out that junk DNA has some sort of role in gene expression across the whole of the genome, raising the combinatorial complexity enormously. This tells me that we have little idea how modifications at one point in the genome can impact the functioning at any number of other points (but it hints at an explanation as to why human beings are so much more complex than nematodes despite having only a relatively small number of additional raw genetic instructions).
And now there is news that a cow in New Zealand, genetically engineered in respect of one allergenic protein, was born with no tail. Now it's too early to be able to blame the GM for this oddity, but equally, the junk DNA finding surely undermines the confidence that any genetic engineer can have in predicting that their changes cannot have had unexpected and really unpredictable side effects.
Original post, 15 Jan 2011
As a software engineer years ago I developed a deep unease about genetic engineering and genetically modified organisms (GM). The software experience suggests to me that GM products cannot be verifiable given the state of our knowledge about how genes work. I'd like to share my thoughts.
Genetic engineering proponents seem to believe the entire proof of a GM pudding is in the eating. That is, if trials show that GM food is not toxic, then it must be safe, and there isn't anything else to worry about. The lesson I want others to draw from the still new discipline of software engineering is there is more to the verification of correctness in complex programs than tesing the end product.
Recently I've come across an Australian government-sponsored FAQ Arguments for and against gene technology (May 2010) that supposedly provides a balanced view of both sides of the GM debate. Yet it sweeps important questions under the rug.[At one point the paper invites readers to think about whether agriculture is natural. It's a highly loaded question grounded in the soothing proposition that GM is simply an extension of the age old artificial selection that gave us wheat, Merinos and all those different potatoes. The question glosses over the fact that when genes recombine under normal sexual reproduction, cellular mechanisms constrain where each gene can end up, and most mutations are still-born. GM is not constrained; it jumps levels. It is quite unlike any breeding that has gone before.]
Genes are very frequently compared with computer software, for good reason. I urge that the comparison be examined more closely, so that lessons can be drawn from the long standing "Software Crisis".
Each gene codes for a specific protein. That much we know. Less clear is how relatively few genes -- 20,000 for a nematode; 25,000 for a human being -- can specify an entire complex organism. Science is a long way from properly understanding how genes specify bodies, but it is clear that each genome is an immensely intricate ensemble of interconnected biochemical short stories. We know that genes interact with each other, turning each other on and off, and more subtly influencing how each is expressed. In software parlance, genetic codes are executed in a massively parallel manner. This combinatorial complexity is probably why I can share fully half of my genes with a turnip, and have an "executable file" in DNA that is only 20% longer than that of a worm, and yet I can be so incredibly different from those organisms.
If genomes are like programs then let's remember they have been written achingly slowly over eons, to suit the circumstances of a species. Genomes are revised in a real world laboratory over billions of iterations and test cases, to a level of confidence that software engineers can't even dream of. Brassica napus.exe (i.e. canola) is at v1000000000.1. Tinkering with isolated parts of this machinery, as if it were merely some sort of wiki with articles open to anyone to edit, could have consequences we are utterly unable to predict.
In software engineering, it is received wisdom that most bugs result from imprudent changes made to existing programs. Furthermore, editing one part of a program can have unpredictable and unbounded impacts on any other part of the code. Above all else, all but the very simplest software in practice is untestable. So mission critical software (like the implantable defibrillator code I used to work on) is always verified by a combination of methods, including unit testing, system testing, design review and painstaking code inspection. Because most problems come from human error, software excellence demands formal design and development processes, and high level programming languages, to preclude subtle errors that no amount of testing could ever hope to find.
How many of these software quality mechanisms are available to genetic engineers? Code inspection is moot when we don't even know how genes normally interact with one another; how can we possibly tell by inspection if an artificial gene will interfere with the "legacy" code?
What about the engineering process? It seems to me that GM is akin to assembly programming circa 1960s. The state-of-the-art in genetic engineering is nowhere near even Fortran, let alone modern object oriented languages.
Can today's genetic engineers demonstrate a rigorous verification regime, given the reality that complex software programs are inherently untestable?
We should pay much closer attention to the genes-as-software analogy. Some fear GM products because they are unnatural; others because they are dominated by big business and a mad rush to market. I simply say let's slow down until we're sure we know what we're doing.
Posted in Software engineering, Science


text:
Sort: publication date | titles A - Z
Page: | 1 |
This book is full of ideas to help children aged 4 -11 with a speech or language delay or disorder. It is packed with activities to develop skills such as articulation, vocabulary development, breath control, and non-verbal communication. Tips for personalising and shaping the activities are also provided, and a comprehensive theory section. more »2011, Paperback: £19.99/ $32.95
Keywords: child development, communication, education, health care, intellectual disabilities, Key Stage 1, Key Stage 2, PSHE, social skills, speech and language therapy
This book uses an evidence-based CBT treatment model to assist children and adolescents aged 9–15 years to resolve trauma symptoms and increase their coping skills. The approach is made up of 16 step-by-step sessions to carry out with the young person, and includes worksheets and fun activities using arts and crafts. more »2010, Paperback: £19.99/ $34.95
Keywords: adolescence, anger management, anxiety, arts therapies, attachment, bereavement, bodywork, challenging behaviour, child development, child protection, child psychiatry, child psychology, children, cognitive behavioural therapy, communication, counselling, death, depression, domestic abuse, early intervention, families, grief, health care, mental health, mental illness, psychiatry, psychology, psychotherapy, resilience, safeguarding children, self esteem, sexual abuse, social care, social skills, social work, teenagers, trauma
This is an entertaining social skills storybook that will help children with ASDs to understand the importance of taking care of their bodies. Fully illustrated with colour photographs, it sets out fun, simple steps that explain what caring for yourself actually involves – how you can do it, where it is done and why it is important. more »2007, Hardback: £25.00/ $39.95
Keywords: Asperger syndrome, autism, child development, child protection, children, families, health care, high functioning autism, inclusive classroom, occupational therapy, parenting, personal hygiene, sensory issues, social skills, social stories, special education
Page: | 1 |
(3 titles match the current selection)

subset: commoncrawl


text:
Free Kindle Version of A Duel in the Somme
A week ago, Amazon released a new app for publishing comics for Kindle. I grabbed it to try it out, and published my 2010 comic project with Ben Bova and Bill Holbrook, called A Duel in the Somme. The app worked pretty well, and was easy to use.
Anyway, if you have a Kindle, the 24-page comic is available as a free download for the next few days. If it seems worthwhile, I'll convert Erfworld Book 1 soon, too.


text:
Clover student council receives gold honor
CLOVER The Clover High School Student Council received the Gold Level Honor Council Award at the 65th annual Association of Student Councils State Convention in Pawley's Island March 8 to 10.
The award was given to the students based on the type of activities that they sponsor at the high school and in the community.
Senior Kate Stewart was inducted into the Terry McCoy Leadership Hall of Fame for her dedication, teamwork and leadership skills.
In addition, Clover junior Adam Moore was elected to the office of state recording secretary. He will be representing Clover and Student Council District Four in all future state meetings.
Staff advisors include Rhonda Morris and Taylor Black.
York students have art displayed
YORK Students in York schools have been chosen to have their art displayed at the district office. The following students have art on display:
• York Middle: Lauren Lackey, Kobi McNeely, Nicholas Dickson, Hailey Lattimore, Owen Mobley, Christopher Lloyd Watson, Ben Watkins.
• Jefferson Elementary: McKenzie Justice, Jack Peeler.
• Harold C. Johnson Elementary: Josh Johnson, Jacob Roberts.
• Hunter Street Elementary: Emily Grace Watson, Hayden Lee Ford.
• Hickory Grove/Sharon Elementary: Savannah Moore, Weston Hance, Eryn Taylor Canupp, Chance Dean Patterson, Bailee Lee-Ann Ayers.
• York Intermediate: Brooke Taube, Kayleigh Benko, Dylan Sakach, Joseph Loggins, Abby Fields, Alyssa Carter.
Brady Watson to attend Naval Academy summer program
CLOVER U.S. Air Force JROTC cadet Brady Watson at Clover High School has been accepted into the U.S. Naval Academy summer seminar at Annapolis, Md.
The summer seminars are a fast-paced, six-day experience for high school students who are high achievers. The selection process is very competitive with only 3,000 students selected; more than 18,000 students apply.
The program teaches students about life at the naval academies and how academics, athletics, and professional training all play roles in developing leaders. The seminars also help educate, motivate and prepare students who are considering applying for admission to a service academy.
Watson is deputy group commander in the school's Air Force JROTC.
York Intermediate names Cool Cougars
YORK York Intermediate School has named the following students Cool Cougars. They are, Team 6-2, Megan Elliott, Jordyn Burton, Adam Whitesides and Tytianna Allen.
Conservation district offers scholarship
YORK The York Soil and Water Conservation District will provide a scholarship for a York County student to attend the S.C. Conservation District's Youth Workshop June 24-28, 2013 at Lander University in Greenwood.
This is an opportunity for students to study the environment in the areas or wildlife, forestry and natural resource conservation. Included is instruction in outdoor recreation such as canoeing and kayaking.
Students in grades nin to 12 are eligible to attend. Applications must be received in the office by April 19. For an application or details, contact coordinator Barbara O'Connell at 803-684-3137, ext. 101 or email her at firstname.lastname@example.com .
Send us school news
Send school news and JPEG photographs for publication to firstname.lastname@example.com. All submissions become the property of the Enquirer-Herald and may be published in any format.


text:
CHARLESTOWN - The Charlestown Town Council will hold a public hearing tonight regarding the potential purchase of the 78 acres, known as the Whalerock property, to use as open space.
Developer Larry LeBlanc was in the midst of a public hearing before the Charlestown Zoning Board for permission to erect two 410-foot wind turbines on the site.
The zoning board hearing was stalled once the town began pursuing an option to purchase the property.
The hearing regarding purchasing the property will be held tonight at 7 p.m. at Charlestown Elementary School.
HOPKINTONŌĆĢ Even though the town council would like to give more money to the town's two libraries, the state-mandated ŌĆ£maintenance of effortŌĆØ makes increases fiscally risky. If the town were to add to its library funding, it would be required to maintain that level in future years regardless of unpredictable budgetary shifts.
ŌĆ£The 'maintenance of effort' says you cannot give any less than you gave the prior year. Once you give, you cannot take away. It's a permanent increase,ŌĆØ said Council President Frank Landolfi at Monday night's council meeting.
WOOD RIVER JUNCTION ŌĆö The Affordable Healthcare Act (AHA) will have ŌĆ£dramatic financial implicationsŌĆØ for the Chariho Schools according to Chariho Solicitor Jon M. Anderson, who made a presentation of the AHA's potential ramifications to the school committee on Tuesday night.
HOPKINTON ŌĆō Ed James of Hopkinton canŌĆÖt forget the day last summer when he received a phone call from his father telling him, ŌĆ£They just found an old grave in the sandbank behind the barn.ŌĆØ
The Rhode Island Guard Games took place last week with a variety of teams of lifeguards from beaches like Narragansett, Scarborough, Westerly and East Matunuck.
CHARLESTOWN - The CrossŌĆÖ Mills Public Library is celebrating 100 years of service to the Charlestown community this weekend. The library has a rich history, which began in 1913.
CHARLESTOWN ŌĆö Despite protests from town residents, the Charlestown Town Council decided to continue the Copar Quarries and Westerly Granite Company (WGC) hearing until the councilŌĆÖs September meeting.
On TuesdayŌĆÖs nightŌĆÖs council agenda was the discussion and potential action of a resolution that would ask the Rhode Island Attorney General to look into whether WGC is in compliance with state laws.
Weekend of fun at the Charlestown Seafood Festival
HOPKINTONŌĆö Although Hopkinton was approved for $96,000 in grants to mitigate the effects of Hurricane Sandy, the funds are now in question because Housing and Urban Development (HUD) is currently denying the generator portion of the applications.
RICHMOND ŌĆō The Richmond Town Council regrettably accepted the resignation of Michelle Cole from the Chariho Regional School Committee Tuesday.


text:
The Tribune-Democrat
GEISTOWN — HORNICK – Robert B. "Bob," 89, Geistown, resident of Richland Woods for more than two years, died Oct. 28, 2012. Born Oct. 24, 1923, in Johnstown, son of the late Frank G. and Mary C. (Disch) Hornick. Also preceded in death by wife of 57 years, Frances C. (Ball), and sister, Elizabeth Hornick. Survived by daughters, Barbara Hornick-Lockard (Dennis Lockard), Corning, N.Y.; Frances (Terry) Smith, Silver Spring, Md.; Karen Hornick (Fred Smoler), New York, N.Y.; and Michelle Hornick Crowley (Steve Crowley), Carlisle, Pa.; and grandchildren, Ben and Mark Lockard, Gillian and Laura Smith and Joe and Cecile Crowley. Brother of Mary Frances Stevons, Louise Hoffman and Ronald Hornick, and brother-in-law of Janet Hornick and Edmund T. and Henry E. Ball, all of Johnstown. Bob was devoted to his family. He served as an Army combat engineer in World War II and retired as a clerk from the Gautier Division, Bethlehem Steel, Johnstown Plant. Lifelong member of St. Benedict Catholic Church, Geistown. Bob built his own home and could repair anything. He took pride in his blueberry bushes and loved being outdoors, reading about science and American history, and listening to classical music. Friends received from 2 to 4 and 6 to 8 p.m. Friday at Harris Funeral Home, 500 Cherry Lane, Richland, where vigil service will be held. Funeral Mass will be held at 10:30 a.m. Saturday at St. Benedict Church, Father David S. Peles, pastor. Committal, St. Joseph Cemetery Mausoleum, with military rites by Menoher Post 155, VFW Ritual Team. Family suggests donations to Robert B. and Frances C. Hornick Family Fund at Community Foundation for the Alleghenies, 116 Market St., Suite 4, Johnstown, Pa. 15901. Online condolences may be posted to and obituary shared by going to www.wharrisfuneralhome.com and use "share" button.


text:
Across town in Newbury Park, Megan Barroso was also enjoying the holiday. She had spent the evening at a barbecue and later, watching fireworks at Silver Strand beach, her best friend, Lindsay Gross, told the grand jury.
One of Barroso's friends had brought a container of red glitter and playfully tossed some on Barroso's head. At 2:45 a.m., Barroso kissed Lindsay goodbye and headed toward her Moorpark home.


text:
Posted by Tarika (2904 days ago)
Need a Moving Quote?
This is probably a stupid question, but how do you cook sago? Thanks for replies!
(I am based in Hong Kong)
Find what you are after in our Hong Kong A-Z Directory
Need a Part Time Maid?
Commission-Free Flats
Buy a Car?
2 for 1 Dinner
Posted by Claire (2904 days ago)
Sago is often added to soups etc. as a thickened or as a base for desserts.
Basic recipe for sago pudding is:
600ml Milk (full)
40g Sago or Semolina
15g Butter
2 tbsp Sugar
1/4 tsp Ground Cinnamon or Nutmeg or Mixed Spice (your choice)
Pre-heat oven to 180C.
Heat the milk in a saucepan until lukewarm, then gradually add the sago or semolina, stirring constantly.
Add the butter and sugar, cook for 10 minutes or until thickened, stirring regularly.
Transfer into a greased 1.1 litre oven-proof dish.
Sprinkle with your chosen spice.
Bake for 30-45 minutes - till a golden brown crust has formed.
Serve hot or cold, with fruit or a generous blob of jam.
(I am based in Unspecified)
Posted by bananarama (2904 days ago)
You can find it in Wellcome supermarket. Ask the manager. I think it's in the dried food section (dried fruits, nuts, beans.
Posted by bluepoppy6 (2902 days ago)
The stuff you buy in Wellcome makes tiny tiny pearl balls only - wonder where RBT and the other bubble tea places get their supply.
Posted by beancurd (2901 days ago)
How you cook sago? just put it in a boiling water, it must be very quick to cook and if you see it turned transparent, remove from the water and drain it in cold water.
Posted by Taps (2900 days ago)
Following the above, lightly boil coconut milk, add sago and sugar(accdg to taste) and a drop of vanille.
Cool, add diced ripe mango before serving(optional).
Top with coconut cream.
Otherwise, buy pounded rice cake(Japanese mochi), some taro(yam) which should be washed thoroughly, both should be cut into tiny squares.
Boil half a can of coconut milk and taro, add water, adjusting accdg to needs, next put sago and sugar while taro is still firm, a drop of vanilla(not more) and add mochi last.
Top with coconut cream, serve hot or cold.
Both should be soupy.
Please do not blame me if you put on weight.
(I am based in Guangzhou)
Posted by raincatcher (2900 days ago)
Taps, are you Japanese? How do you make the rice dish with stir-fried beef on top?
Posted by Taps (2899 days ago)
If you can get hold of Japanese or California rice, that is best.
Chinese do a mean version as well, for us no MSG though.
Below is a housewife version:
Slice the beef into bite-size, add into it some sake(Japanese cooking wine), egg white, white pepper and cornstarch.
Cook in high heat for a minute or so, set aside.
Prepare the vegs in advance, not too much though..broccoli or cauliflower, carrot and bell pepper.
We like to add some Chinese cabbage too since beef is expensive in Japan.
Boil broc and cabbage in salted water(go easy), it keeps the colour.
Also prepare in advance the condiments mixed together..some Kikkoman, sesame oil, 2 tbsp of chicken stock and oyster sauce.
Cook in a flash:
Heat vegetable oil(not sesame nor olive oil, too cloying), add garlic and ginger, followed by onion, vegs, beef and condiments.
Beef is tender, vegs still crunchy.
Pour over hot rice.
Serve with clear soup, in a pan add water, boil and add dashi(powdered stock from bonito), wakame(seaweeds) and finely chopped scallions.
As to your q, nope, I went to university in Japan.
Posted by etnad (2897 days ago)
Is the question how to cook the "dried sago" or how to use the sago in a dish?
Posted by A me (2895 days ago)
Oh, we've a great Indian recipe for sago! But, a bit complicated for probably you guys to understand. It's yum!
Posted by real_human1996 (1955 days ago)
Step 1-put the sago in the boiled water (only when the water is boiling)
Step 2-let it boiled for about 10-15 min (stir occasionally or when needed)
Step 3-let it cool for half - 1 hour
Step 4- repeat the first step
Step 5- repeat step 2
Step 6 - put it in the fridge when it cooled down, for overnite (preferably, otherwise you may leave it in the fridge for about 4 - 5 hours)
Step 7 - If you are cooking with the beans, put the sago in when your beans are almost really. remember to stir.
If you are not putting it in the fridge (to forgo step 6)
you may like to prolong the boiling time of the sago for about half an hour (step 2 and step 5). (btw have not tried this method yet, let me kown if it works)
(I am based in Singapore)
Posted by Sanyahingoo (1614 days ago)
As mentioned by A me we have an excellent Indian recipe for sago. Its made a little spicy and similiar to a stir fried rice. Its difficult to put it down here coz I think its important to see how its made. And perhaps you wont be able to get the right results by reading it and trying it out.....hence you need to see how it is prepared first and then try it....here's my number 51832650. I take Indian cooking classes so let me know if you wanna learn it the Indian way.


text:
Margaret Bishop
Margaret Bishop, 83, of Christiansburg, passed away on Sunday, January 20, 2013.
She was preceded in death by her husband, Griff Bishop, Sr. She is survived by her sons, Larry & wife Linda, Oden & wife Pat, Michael & wife Donna, Jimmy & wife Teresa, and Colen & wife Amanda; 9 grandchildren and 4 great-grandchildren.
After retiring from Hills Dept. Store Margaret was active in the Ladies Auxiliary of the Christiansburg Rescue Squad, the American Legion, and the Red Hat Society.
The family will receive friends on Tuesday, January 22, 2013, from 5-8 pm at Horne Funeral Home. The funeral service will be held on Wednesday, January 23rd at 2 pm at the Horne Funeral Home Chapel, with Pastor Steve Lackey officiating. Interment will follow in Sunset Cemetery, Christiansburg. After the funeral service there will be a reception at the Rescue Squad building.
In lieu of flowers, the family requests memorial donations be made in Margarets name to the Christiansburg Rescue Squad, 110 East Main Street, Christiansburg, VA.


text:
Event outline
Registered Teams
Competition for Object Creation and Design
Student Formula Japan (SFJ) is an opportunity for students to develop skills for object creation "MONO-ZUKURI", which in turn contributes to the expansion of the Japanese automotive industry. This competition was started in 2003 as a public activity for self-motivated students to cultivate various skills involved with object creation, and as training for those who will one day play critical roles in the future of the automotive industry.
2013 Competition Sep.3 to Sep.7 at ECOPA (Ogasayama Sports Park)
2014 Student Formula Japan Competition
Sep. 2 (Tue.) to 6 (Sat.), 2014
ECOPA (Ogasayama Sports Park, Shizuoka-ken)
Registered Teams
(Feb. 14, 2014 up)
Event outline
(Dec. 20, 2013 up)
2013 Competition Sponsors
Copyright © Student Formula Japan All Rights Reserved.


text:
The following public information from the Suffield Police Department is accurate as of Oct. 4, 2012. Items on this list reflect charges filed, not convictions. It is not the policy of Suffield Patch to omit any misdemeanors or felonies from this log.
Sept. 24
Lee M. Sheppard, 45, of 237 Fern St., Apt 111-E, West Hartford, was charged with conspiracy to commit 3rd-degree burglary and conspiracy to commit 5th-degree larceny, 9:04 p.m.
Sept. 25
Heather Warren, 33, of 39 Old Kennedy Rd., Windsor, was charged with 3rd-degree burglary and 5th-degree larceny, 5:20 a.m.
John E. Onofrey, 57, of 14 Michigan St., Indian Orchard, MA, was charged with operating under the influence and failure to keep right, 9:06 a.m.
Let Patch save you time. Get great local stories like this delivered right to your inbox or smartphone every day with our free newsletter. Simple, fast sign-up here.
Sept. 28
Jordan Gaxiola, 22, of 361 Lakeview Dr. Ext., Suffield, was charged with possession of marijuana, use and possession of drug paraphernalia and carrying weapons in a motor vehicle, 3:03 p.m.
Sept. 30
Kristen J. Wilcox, 29, of 23 Brandywine Ln., Suffield, was charged with 3rd-degree assault and disorderly conduct, 6:39 p.m.
Richard C. Wilcox, 32, of 201 Regan Rd., Apt. 8-A, Vernon, was charged with 3rd-degree assault and disorderly conduct, 7:12 p.m.
Oct. 2
Heidi F. Messenger, 37, of 1063 Sheldon St., Suffield, was charged with disorderly conduct, 12:50 a.m.
Lauren Boucher, 19, of 3 Candlewood Ln, Granby, was charged with violating a protective order and disorderly conduct, 9:38 p.m.
Oct. 3
Matthew J. Madley, 32, of 572 Pilgrim's Harbor, Wallingford, was charged with 3rd-degree burglary and 6th-degree larceny, 1:35 p.m.
Leanora M. Frechette, 21, of 572 Pilgrim's Harbor, Wallingford, was charged with 6th-degree larceny and violation of probation, 1:38 p.m.


text:
About Us, AOL College Toronto
Academy of Learning College Toronro provides the following services, resources and events for AOLC students:
- Student Referral Program
- Admission Requirements
- Policies and Procedures
- Financial Aid
- Placement Assistance
- Student Testimonials
Exam Services
For more information. Read More
Student Referral Program
The Academy of Learning College is pleased to introduce our new and improved Referral Program!
Admission Requirements
The first step in your educational journey starts here. We welcome you to come and visit our friendly campus and meet with one of the qualified representatives on our admissions team. Read More
Financial Aid
The decision to invest in education and career training is one of the most important decisions you'll ever make. Read More


text:
FORT MILL — Members believe the first afternoon meeting of the Fort Mill Garden Club was held on the front porch to escape the heat. Last week, with cooler temperatures inside, members only ventured onto the porch long enough for a picture.
Turns out more than the weather changes in 75 years.
"To me it's awesome to be a part of something that happened 75 years ago," said Gerrie Merritt, who passed the presidency at the Sept. 3 meeting to Betty Thomas.
Eight ladies first met at the gray house at the top of Main Street in 1938. Founding members planted trees, worked at Confederate Park, decorated town roadways and gave gifts to establish a library and town festival. They started a garden plot on Main Street that current members maintain at the Post Office just down the street.
The group has 12 members, who come by invitation. Group members say they're part of the oldest garden club in the area and that it helped establish at least six other clubs.
Last week, members considered those founders and how different their lives must have been, even to the dues that have skyrocketed all the way to $10.
"One thing they discussed, they set a fee," Thomas said of the first meeting. "Every month they paid a fee – 10 cents. They just thought that was terrible, but they still passed it."
Club accounts show some members thought that initial price too high. Members joked last week that some today might offer similar complaints. But the group isn't entirely looking to the past. They're planning a float in the Christmas parade this year. This past weekend they provided information on their group for display at the Fort Mill History Museum.
Merritt believes gardens aren't the only things that grew these past 75 years, and that those founding members would enjoy seeing what they started reach full bloom.
"I think they're very proud of what we have become," she said.


text:
Hostel Pekarna
Real Reviews
Real reviews from fellow travellers
These are trusted reviews from guests who have actually stayed here. We hope you find them helpful.
Note: we only give a property a rating once it has received a minimum of 3 reviews.
- Page:1/1
- " However a bit far from the central trainstation, this is a high class hostel, almost like a hotel in standard. If you prefer high standard and nice surroundings to social interaction and lots of people to meet - this is the place! Fancy, high class and well worth its money! "
- 11 Aug 2013 Anonymous Sweden
- " It is like hotel with 5 stars.If you will go to Slovenia,you should stay in there :) "
- 19 May 2013 tuğba Turkey
- " The night that we were going to leave, we ended up returning late and the reception desk was closed. The security guy, attending Sept 25th evening (thru Sept 26th morning) did go above and beyond to get a hold of the manager to understand what needs to be done about our security deposits for the room and bike, he made sure that he frequently stopped by to let us know the state, he also checked twice in the morning to make sure that we are awake to catch our train. He was amazing! "
- 24 Sep 2012 Anonymous


text:
This 1967 Shelby GT500 is one of many that enjoyed a dealer installed 427 side-oiler block, early in its life. The original Police Interceptor... More
1967 FORD SHELBY MUSTANG GT500 Exotic Classics is pleased to present this authentic 1967 Shelby GT500 featured in Red with Black interior. This is... More


text:
WGN Radio to Air Special Honoring Orion Samuelson on 50 Years of Broadcasting
21st Sep, 2010 | Posted in Broadcasting
Legendary agribusiness broadcaster Orion Samuelson celebrates 50 years on WGN Radio Sept. 26. In honor of this milestone, WGN Radio is presenting a one-hour special, "An Evening with Orion: Celebrating 50 years of Orion Samuelson on WGN Radio" on Sunday, Sept. 26 from 8-9 a.m. with an encore presentation from 8-9 p.m. The program will also be available at wgnradio.com following the broadcasts.
WGN Radio afternoon host John Williams hosts the intimate one-on-one interview with the Radio Hall of Fame broadcaster. The special is being recorded on Sept. 22 at a private station event honoring Samuelson.
About WGN Radio
WGN Radio 720, the 2011 IBA Large Market Station of the Year, is dedicated to being the #1 source of Chicagoland news, information, entertainment and sports. WGN Radio is the official broadcaster of the Chicago Cubs, the Chicago Blackhawks and Northwestern University and celebrates over 85 years as "The Voice of Chicago." Listen online or on your iPhone, Droid or Blackberry – details at wgnradio.com/listen. Find us on Facebook at facebook.com/wgnradio and follow us on Twitter @WGN_Radio.


text:
Buying a pair of shoes seems simple enough, but a few considerations should be made. Your shoes are probably the most important clothing item to determine comfort, so a little extra time when buying can be well worth the effort.
Difficulty: Easy
Time Required: 20 minutes
Here's How:
- Have your feet measured by a salesperson.
Many people jump ahead to trying on the shoes without checking the length and width of each foot. It is important to know to proper size of your feet and if your feet are slightly different sizes.
- Shop for the larger foot.
If your feet are different sizes, buy a shoe that best fits the larger foot. If you need, buy an insole to fill space in the other shoe.
- Make sure the shoe fits your heel and your toes.
The toebox should provide ample wiggle room, and the heel should not slip up when walking.
- Go for a walk in the store.
Make sure the shoe is comfortable for a short walk around the store--any pain is only going to be worse on a long walk.
- Don't expect a shoe to 'break-in.'
This is a common misconception that shoes should be purchased snug so they can break-in. Wrong! Shoes should fit when you buy them.
- Stand up when measuring your feet.
Do your footwear shopping towards the end of the day after you've been up and walking for a few hours. Under these conditions your feet will be slightly larger than in the morning. End-of-the-day shopping is the best way to buy footwear.
- Remeasure your feet each time you buy new shoes.
Measure your feet each visit as your shoe size can change over time. And never buy a shoe based on size alone--try them on!


text:
Ancasta Brighton has three full time employees working at Brighton, two brokers, and an administrator.
Situated in the Marina Square the Brighton office has its own berthing pool conveniently located outside its office and an excellent promotion area. the office is within close reach to the main car parking, village shops and chandlery to mention but a few.
We have 18 dedicated offices along the south coast and Europe with over 40 ABYA trained brokers.
The moment you list your boat with this office, it is immediately available across our whole network.
Address:21 Waterfront,Brighton Marina,East Sussex, BN2 5WA
Tel: 01273 673232
Mon - Fri: 09.00am - 17.30pmSat: 09.00am - 17.00pmSun: 10.00am - 16.00pmBank Holidays: 10.00am - 16.00pm
For full information on all participating venues


text:
(Updated 8:48 a.m) A Virginia man who stood trial for firing a gun at a man at a Germantown gas station — an escalation of an argument over an available gas pump — is scheduled for sentencing Wednesday in Montgomery County Circuit Court.
Dmytro Solomatin, 27, of Reston, Va., Jan. 19 of first-degree assault and weapons offenses; he was acquitted of fist-degree attempted murder. Judge Ronald B. Rubin presided the three-day trial.
During the trial, Solomatin testified that he fired a 9 mm gun in the direction of Michael Rickley after they got into a fistfight at Freestate gas station Aug. 6, 2011.
Solomatin said he thought Rickley was trying to butt in front of him as he waited for an available gas pump. Rickley said that he made an honest mistake.
Jurors were shown surveillance footage of the men fighting on the ground, returning to their cars and what appears to be Solomatin firing a shot toward Rickley.
No one was shot. The bullet struck the tire of Rickley's Volkswagen Rabbit.
Arguments hinged on whether Solomatin or Rickley was the aggressor.
During his testimony, Solomatin claimed he was so "terrified" of Rickley that he intentionally shot the Volkswagen tire in order to scare him. He said he went to Montgomery County Police department's 5th District station to press charges against Rickley, but was arrested.
"I thought he was going to kill me,".
Prosecutors argued that Solomatin intended to shoot and kill Rickley but missed due to bad aim.
"I was in shock," . "I couldn't believe he shot at me. I was really hoping he wouldn't pull the trigger again and hit me."
Charges were not filed against Rickley.
A first-degree assault conviction can carry a sentence of 25 years, according to Maryland law.
The weapons offenses — transporting a handgun and the use of a handgun in the commission of a felony — carry mandatory sentences of at least five years.
This story has been updated since it was originally published to correct the date of Dmytro Solomatin's sentencing, which is Wednesday.


text:
August 1, 2014
It might not be a knockout blow but round one goes to the Crusaders.
Edgewood brought the state's 2nd ranked hockey team into Stoughton to take on the 5th ranked Vikings in a Southern Badger Conference battle. By the time the Crusaders skated out of town they had a decisive 5-1 victory that improved their record to 11-0 this season.
The Crusaders scored twice in the first and led 3-1 after two before putting it away with two more goals in the third.
Both teams entered the game undefeated.
NBC-15 will have an In-Depth feature story on the Crusaders unique coaching staff on the January 13th edition of Wisconsin Sports Sunday.


text: My brother lives in the SF bay area, so I already have a place to stay (I am so happy!). Now the only question is who from the family would like to accompany me. Neither he nor his wife understands FS, though she may be interested in seeing the competition. It means I could also get a ride to the arena, if she agrees to go there with me.


text:
Blog mostly dedicated to Naya Rivera and Heather Morris. Heya, Brittana are my otp even though I no longer watch Glee. This is personal blog so you can find here bit of everything. LGBT rights. Gooner till I die Heya Babies
Catching Elephant is a theme by Andy Taylor
Oooooooooooooooo. :)))))))
mikel u actin like u big shit now dont forget where you came from


text:
List Price: $94.99
PetSafe Basic Remote TrainerItem # HN-RSC194
- Range up to 75 yards
- Water resistant - battery replaceable collar receiver
- Convenient miniature hand held transmitter
- 12 levels of stimulation and 2 tone training options
- Recommended for pets over 8 lbs.
Full Description
Guarantee & Returns
Similar Dog Collars & Leashes
Hartman & Rose Italian Leather Dog Collar - Petal Pink
Hip Doggie Ultra Comfort Orange Mesh Harness Vest
$22.99 - $31.87
Pet Ego Semi-Choke Padded Dog Collar
$38.67 - $45.99
Pet Ego Tubular Calfskin Dog Harness
$41.98 - $52.99
Sport DOG Stubborn Dog Yard Trainer
Pet Ego Rolled Leather Tubular Dog Collar
$45.67 - $57.00
Suggestions for You
Customer Q & A
Be the first to ask a question about this product.
Enter your question, and one of our Customer Care experts will respond via email and also post the answer here.
Ask a Question
Email Address
Please Enter
Your Valid Email
Your Valid Email
Your Question
Please Enter
Your Question
Your Question
Sponsored Links


text:
Elementary episode 12 review: M.
Elementary's M. is the best the show has offered up so far. Here's Frances' review…
This review contains spoilers.
Had Elementary not received the full season order a couple of months ago, M. would presumably have been its final episode, and what a way to go out it would have been. Tense, revealing, poignant and leaping the 'what happened in London' arc forward by miles, it's the best fifty minutes the already-reliable show has offered up so far.
Written by creator Robert Docherty, the episode left us with a name, an enduring image, and a repeated line, all three immensely rewarding viewing. The name? Moriarty. The image? Holmes clearing away the detritus of his former revenge obsession and replacing it with that single name. The repeated line? "I'll miss this. Not this, but this. Working with you. I think what you do is amazing".
Last week, I offered some alternatives for what would cause Watson to stay with Holmes - his potential relapse topping the list - but the best and most emotionally satisfying reason didn't occur to me: that she would simply choose to. The mystery of the man, the draw of his work, and her concern for him proved too strong for her to leave. Watson's contract with Holmes Sr. not having been renewed, unbeknownst to Sherlock, she chose to stay on pro bono. Attagirl.
Anyone familiar with all that's right and good in this world and/or the work of Conan Doyle will have known from the get-go that Vinnie Jones is no Moriarty, though for the briefest of moments, I was forced to wonder. Could Elementary really have given us a Bane-like Moriarty with a taste for lager, exsanguination, and "the Arsenal"? Could Jones the Juggernaut be the virtuoso spider at the centre of a vast criminal web? Nah. (Though he must be something of a genius if, during a seventy-two-hour stay in New York, he could find three separate Arsenal matches to watch…)
Jones was of course Col. Sebastian Moran, an ex-army expert sniper in the world of Conan Doyle, and ex-marine throat-slitter in the world of Elementary. All menacing brawn and business, he didn't do a bad job to begin with (though you'd think the two Brits in the cast would have at least given notes about his Yankee use of "cell-phone" and "apartment"), but pitting his one-note performance against Miller's intense, layered display in that torture scene did him few favours.
Because Miller, it goes without saying at this point, was fantastic in the episode. Seething underneath but dangerously rational above, running on pure rage, but ultimately, rueful and melancholy, it was a captivating show from him. Doherty putting Watson's "I'll miss this" line in his mouth was clever work too, both a smart recall to the TV quote Holmes parroted at their first meeting, and the only way for him to express his admiration of her without breaking character.
M. was also fun for dropping more Conan Doyle references than any Elementary episode so far. From Moran, to the reappearance of the bees, to the reimagined Baker Street irregulars in the form of Teddy and co., not forgetting Irene Adler and the tantalising introduction to Moriarty, from start to finish it was a canon-fest.
Speaking of Moriarty, a thought occurs… (anyone not wishing to get into speculation territory avert your eyes now). In this parallel universe, could Holmes Sr be Moriarty? It would be a bold move, granted, but considering the evidence at hand, we know that Sherlock's father is extremely wealthy, well-connected, shadowy, manipulative, and fond of game-playing as we saw from his teasing non-arrival in Flight Risk. It follows doesn't it, that the DNA whence Sherlock Holmes sprang would be able to match his mental acuity? Might Holmes Sr have been responsible for the death of Irene Adler (if she is indeed dead), and subsequently, his son's devastation and self-destruction? It would be a meaty twist if so.
Conjecture aside, let's end with a doff of the cap to Elementary's makers. If M. was how we'd had to say goodbye to Jonny Lee Miller's Holmes, it would have been a fittingly strong, if frustrating end. Over the course of twelve episodes, the show has shaken off pre-broadcast criticism to attract a steady 10 million-plus US audience and evolve into exactly what CBS promised us: a new take on the Holmes and Watson characters that quickly disposed of tedious 'will they won't they?' clichés to present an easy to invest-in friendship, brought to life by smart writing and an engaging cast. Long may it continue.
Read Frances' review of the previous episode, Dirty Laundry, here.
Follow our Twitter feed for faster news and bad jokes right here. And be our Facebook chum here.
Disqus - noscript
Is that Vinnie Jones?!
JLM was outstanding in this episode ! "M" was the best epi so far ! I can't wait to see the next.
The email at the end was from M. Holmes but my money is on Mycroft...
My favorite episode so far as well.
13 episodes was CBS's initial order, so this would NOT have been the final episode outside of a full-season order. Barring the possibility, of course, that this was episode 13 and CBS showed it out of order, as number 12.
Before Sherlock or the recent Holmes movies came out, I did wonder if Mycroft was Moriarty, not knowing enough about the source material to know that this was never part of the original stories. It just made a lot of sense to me, and maybe this time it will happen, even if Mycroft is the father rather than the smarter older brother.
A great episode, loved the nods to the canon, even Vinnie jones couldn't spoil it. Still wondering if Roger Rees from the ep Flight Risk will end up being Moriarty. Is it too obvious that his father is Moriarty?
Someone put forward a theory that I found intriguing- what if Moriarty isn't just one person. It could be a name for an organisation, which would explain the unconnectedness of Moran's London killings and would also offer potential for Holmes Sr to be both Mycroft and Moriarty, which could make for some interesting plot developments.
I have to say that before the series started I had more than a few derisory thoughts on this show. From JLM as Holmes and Lucy Lui as Watson to moving the action from London to New York as well as the obvious comparisons with the excellent Sherlock.
But as the weeks have gone by I have to say that this has been an excellent series. The writers should be commended for going no where near the "will they, won't they" romance between Holmes and Watson, something I felt they wouldn't be able to help themselves putting into the show.
I was concerned that they were going to position Vinnie Jones as Moriarty, but the idea that he's a hired thug makes so much more sense.
As for Moriarty and Holmes Sr being the same person? Well Jones character says he's never met his employer, just as Watson has never met hers.
CBS has so far done a superb job of making their own show's character unique:
The Arthur Conan Doyle character ignores sex because he sees himself as a fine-tuned thinking machine and doesn't want to be distracted; the CBS Holmes uses female prostitutes, with never an apparent concern about disease or safe sex, to meet the sexual needs he thinks are repulsive but is unable to ignore on his own. ACD Holmes is very neat in his person and clothing; CBS Holmes is sloppy and sniffs his clothes to pick out the least smelly dirty ones to wear. ACD-H is devoted to truth above all else and hates ever being wrong; CBS-H sometimes hates being right. ACD-H is, in fact, almost always right; CBS-H is usually quite wrong multiple times per episode.
ACD-H deeply values friendship and takes pride in calling Watson his friend; CBS-H has pride too, but it's the kind that requires Watson to pretend to be a paid caretaker, not a friend. ACD-H is routinely open and honest about his life (except with those he is currently investigating) because he cares nothing for what others think of him; CBS-H tells lies to Watson, hides his addiction because he's afraid Gregson will think less of him, and is so afraid of others' thinking him "average" that he's willing to stab a man out of no necessity, but just to establish his reputation for unpredictability. ACD-H makes it a point of his own personal honor that any fight he is in is a fair one; CBS-H is willing to beat and stab a helpless person, not even to gain information and even after finding out this isn't the person he wants revenge on. ACD-H was a very independent person and supported himself; CBS-H is financially dependent on his father and emotionally dependent on his rehab center and his caregiver.
Perhaps ACD-H's main attribute, in addition to his intelligence, is his supreme self-control over his emotions; CBS-H is so driven by emotion (with calm just on the outside, a facade) that he can barely control himself at all, wrecking a car in a kind of temper tantrum, being unable to stop his drug use without being locked up in a rehab center, deciding to commit murder, etc, etc.
I would say that CBS is now at the point where their main character diverges sharply from pretty much any other version of Holmes ever done. So, while they may have begun by pulling publicity from other shows, they can now justifiably take credit for all the continued success their show may have.