The thoughts of a 'Ranting Loon'

Socio-technical design realities

2011-05-18T12:38:00.004+01:00

A hard problem is specified, in order to make it tractable it is broken down into software components. These components get reified into human and managerial structures in the organisation responsible for building the system.

Overtime these abstraction or managerial boundaries impede the development of new features and ideas. In a user focused organisation, communication between the teams tends to lead. New human connections are formed, followed or coupled with new technical connections. These lead to exciting new user-facing innovations.

More hierarchical, less user-focused, organisations tend to be incapable of supporting the new social dynamics, and so try to enforce their socio-technical boundaries, occasionally with security mechanisms. The only benefit they reap from this, is that rather than incrementally adapting, they are replaced wholesale by a different organisation that views the separation differently.

As such, the oscillation that is typical in large business between horizontal and vertical orientation is reflected directly in the oscillation in software structures as new ideas are negotiated around the abstraction boundaries (see e.g. the oscillation between objects and aspects, or mocking). The lack of such oscillation doesn’t imply that the design was somehow ‘right’ to start with, only that the organisation was too inflexible to adapt to the needs of its users.

The oscillation cycle is both healthy, and endemic across technical aspects of IT systems. See for example:

The separation between processes in an operating system, first hard, then IPC, then DMA, then Virtual Machine Monitors
The separation between the ‘compile’ and ‘execute’ phases of a language. Then dynamic class loading and dynamic languages. Then NEX bits.
The separation of browser from operating system. Then ActiveX. Then Windows Isolation Mode. Then Chrome. Then Native Client....

This isn’t a failure, it’s a design process. The question is, we oscillating enough? How can we oscillate faster?

Broken Social Protocols: Chip and Pin

2007-04-21T15:56:00.000+01:00

The UK's move to Chip and (s)Pin has been greeted with criticism from elements of the security community. However most of the usability criticisms have been focused on two problems:

1. Memorability of four digit codes

2. Usability of terminals, which generally is very poor.

However, I argue there is a much more insideous usability problem with Chip and Pin which comes from using a broken social protocol. To start with, let's considered what happened with Card and Signature, the old system.

Merchant -> Customer: Cost
Customer -> Merchant: (Card and Signature)
Merchant -> Customer: (Reciept and Copy) (includes Cost)

*Customer checks cost
Customer Signs reciept and copy

Customer -> Merchant: Reciept and Copy with Signature

*Merchant verifies signature

Merchant -> Customer: Card + Receipt

Items marked with a '*' are optional steps. One of the main problems with this protocol is that really security is managed by the user possessing the card What you have authentication, rather than the signature matching What you are authentication. So just about any signature would do.

Chip and Pin promises to replace this with What you know authentication, based on a four digit number. However, I assert that the social protocol used to handle Chip and Pin is broken.

The first problem we have with describing the Chip and Pin protocol is, there isn't one. Consider the most basic operation:

(I'm using Point of Sale Terminal to refer to the thing that the merchant uses, and Chip and Pin Terminal to be the thing the customer enters a pin number into)

--Phase 1--

Merchant -> Point of Sale Terminal: Cost
Point of Sale Terminal -> Chip and Pin Terminal: Cost

Customer verifies cost

--Phase 2--

Customer -> Chip and Pin Terminal: Card
Customer -> Chip and Pin Terminal: Pin

(Assuming correct, authorised etc.)

Delay

--Phase 3--

(Concurrent) Chip and Pin Terminal: 'Remove Card'
(Concurrent) Merchant -> Customer: Receipt
(Concurrent) Collect shopping

--End--

So this looks OK?

Well there are a litany of problems:

Phase 1 is not at all standardised. In some systems the merchant enters the data into the console and pre-accepts the amount so the user has no idea how much they're actually paying for until the receipt is produced, in others the user gets to approve it by pressing a key, others just type in the pin. This is very poor usability, though considering how poor the rest of the protocol is forcing the user to think may actually help security(!!)

Phase 2 is where most of the previous usability work has been done. Problems with shoulder surfing, exclusion of blind people, people with dispraxia etc. But it's been covered elsewhere, I'm going to ignore it. The delay at the end is important though (see later)

Phase 3 here things get really dodgy. Notice, that the three items occur in parallel.

And there is a delay between entering the pin, and being able to remove the card.

The delay matters, because the customer gets bored, and rather than only waiting for the prompt to remove the card, starts collecting their shopping. So the customer is faced with:

-> Collecting their shopping (completion of task)

-> A person handing them something

-> A machine with some unreadably low contrast text which changed from 'please wait' to 'remove card'. The environment is noisy, and visually distracting and the shopper may well be stressed.

There are intuitive reasons why this is bad, but there is also, at least one, fairly sound psychological problem.

POST-COMPLETION Errors

Consider another task, withdrawing cash from an ATM in the UK. The machine won't give you your cash until you take your card. Why? To stop you getting your cash (completing the task that you went to the ATM for), and then leaving without collecting your card as your mind has moved on to whatever you're wanting to do next.

Again, consider Card + Signature, the old scheme. Here, you don't get your card back until the merchant has looked at it. The process is sequential, you're not doing anything else, you've handed the merchant your card and are expecting it back in a second or so. Further, you've given it to a person, most polite people will pay more attention to a human than they will to a machine. Further, the merchant has a tangible reminder to give you your card back. Not only that, but you gave them your card, this imbues an unspoken responsibility to take care of it, including giving it back to you. All the cues point the right way.

But in Chip and Pin none of this happens. As mentioned above the user has at least three competing actions:

1. A person is giving them their receipt. (This takes precedence over machine interaction)

2. You're collecting your shopping. This completes the activity you were there to do in the first place. You probably do this whilst you're waiting as the delay between pin entry and remove card is long, several seconds

3. The (unreadable) text on the chip and pin terminal changes.

----

And now the shocking news. People leave their cards behind (Post Completion Error). Chip and Pin has been around for short while, maybe about a year and a bit. In the past month, I've now seen 3 people leave their cards behind. In 10 odd years I've been watching people use signatures, I never saw this happen.

Observations:

If a security system can't survive Murphy (Random chance), it will break horribly under Satan (malice). There are any number of things that a merchant who wanted to steal cards could do. E.g. they notice you're about to retrieve your card, so they hand you your shopping or receipt to interrupt the process. They then remove your card after you've left. They're already stolen your pin number by watching you type it in.

It's not surprising that this didn't emerge for a while, at first people were going through this process consciously, it's a kind of damning indication that it took so long; 12 months to learn how to do a task that you perform several times a day is not great.

----

So what can we do about this?

The Post Office seems to be one of the very few organisations who has put some thought into Chip and Pin. They're terminals are big, tolerably easy to read, though they could be better and have easy to cover number pad, and they beep at you when they want you to remove your card.

It's not a fix to what is fundamentally a protocol that doesn't encourage the correct process, but it's certainly a lot better. Kudos to the Post Office.

----

So Chip and Pin is not only very dubious from a technical security perspective, it's also fundamentally worse from a social interaction perspective. It's so bad, that failures happen by accident. I hate to think how many Cards and Pins a smartly dressed attractive shop assistant could steal.

Beware of RAW files

2007-03-13T20:34:00.000Z

The cat is now well and truely out of the bag. On the 17th of December 2006, I reported over 15 suspected vulnerabilities to a range of software vendors reporting problems with handling malformed Camera RAW Files.

In the last two weeks we've seen Microsoft patch IView Media Pro where the version history (http://downloads.iview-multimedia.com/ivmp313vh.pdf) 'Fixed crash caused by importing corrupt DNG files.'.

Their internal analysis indicated that it was a reliability issue that did not require a security patch. All good. :-)

And today, Apple have issued a security patch to their operating system(s) (http://docs.info.apple.com/article.html?artnum=61798)
CVE-ID: CVE-2007-0733

I would advise users of Mac OS X or Mac OS X Server v10.4 -> 10.4.8 to schedule this patch for testing and rolling out.

Several other vendors are still working on patches, so clearly their problems will not be discussed, however by now the 'bad guys' have several information sources that there is an attack vector, so without discussing specifics that might harm the vendors still working on fixes, it's worth considering a few precautions we should all be taking over the handling of raw files.

**Digital Camera RAW files should be treated as if they were programs**

Therefore, you should not download unsolicited camera RAW files (either from the web, form peer to peer software or from email attachments). Even placing such a file in a folder may be enough to cause hostile code to execute.

Many of the potentially vulnerable mechanisms have no automatic patching mechanism, it is therefore important that you check to see if the maker of your software has released any updates. However in many cases they have not yet, so your only protection is being very careful with RAW files.

If you are an organisation that routinely handles 3rd party RAW files extra security measures are definitely in order. If you contact me I will be happy to discuss your requirements with you. Contact details are
here

A more detailed discussion on some aspects of the problem will follow later...

The Moral Hazard of Apple

2007-02-05T07:53:00.000Z

Paraphrase:
"Seriously, I've got this virus, stay well back"
"Not really, I'm a Mac"

Apple's latest adverts are annoying me.

Personally, I dislike negative marketing, if Apple are as amazingly much better as they claim, and their ~5% market share shows, then please can they talk about what they're doing right, not what Microsoft are doing wrong, and that's leaving aside the very dubious factual accuracy of much of what they have to say...

But beyond this, there are a couple of more serious points.

1. Homogeneity is bad for security. Irish potato farmers and NATO (sorry, can't find the reference) both understand this. As I suspect do Microsoft. Their monopoly hurts the security of their product by providing a high value target and a rapid adoption platform for infectious diseases.

2. Apple are creating a Moral Hazard. By redistributing the perceived risk they are encouraging unsafe behaviour. This is fine for them when they have a tiny market share, and so no real security threats (though a very large list of security problems), but if they ever became a more substantial force, and have spent the past years 'educating' their users that they're 'safe' because they're using a white computer, then they will have a huge problem and just performed society generally a serious dis-service.

So Apple, be different, it's good for both of us, but don't claim that you're better because you're different.

Oracle. Unbreakable 50+ different ways last quarter. Need I say more?

Is reliability harmful?

2006-11-04T23:22:00.000Z

Over time I've become increasingly concerned about the 'acquisition' of non-critical technologies for life/mission-critical purposes. I view this trend, and the lack of rational thought that is applied as a serious trend in the use of technology within society.

The story is usually the same.

First comes the idea. It's usually a bright idea, often from a bunch of off the wall researchers. Implementations are concept demonstrators, developed for research flexibility and rapid implementations.

Second comes the commercial application. Often, this looks disturbingly like the concept demonstrator, if we're lucky it's a hardened implementation that has actually been tested.

Third comes the impact of network economics. The value of the product to the user = n^2 for the number of users, n. This results in rapid explosive growth. During this time the technology 'crosses the chasm' into a serious product. However, it has to maintain backwards compatibility, the golden handcuffs click into place. The technology's fate is all but sealed for many years. (e.g. the address space of IP)

Forth comes acceptance. The technology becomes integrated into the way the society that uses exists. We start relying on the technology, expecting it to be there, 24/7/365.

In phase 1, the system is so unreliable that it barely works outside the lab, there is no perceived threat. It's so difficult to get the darn thing working, that no-one really cares about large-scale reliability.

Phase 2, it's a nascent technology, it's a cool gadget, no-one would rely on it.

Phase 3, OK, so it's a commercial technology, it works almost everytime that you turn it on. If it doesn't people put in a lot of effort to make it work.

Phase 4, it's too late. Huge effort is poured into engineering reliability in the system, If we're unlucky people die because our reliance on the technology, but society cannot excise the technology even if it wanted. People can be told not to rely on it all you like, it will do no good.

So, without any serious consideration being given, we've gone from a research toy, to something that your life may depend on, if you're lucky it might just be something that will inconvenience you or loose you money if it's not there.

Consider some examples:

Mild: Digital photography

Do you rely on your digital cameras? How about your computer? How would you feel if it all went away, tomorrow. Are you sure you don't rely on digital photography? As far as I can tell, lots of people do.

More serious example:

When you dial 999 (UK) or 911 (US) do you expect anyone to answer the phone? Why? You're relying on a system with multiple single points of failure, but it's been around for a while, people understand that we need it, a serious amount of effort has gone into maintenance of uptime, and there are various hacks which attempt to give emergency traffic priority.

Don't delude yourself, the availability of the emergency services is not guaranteed by the technology, you are relying on a high-reliability statistic, and that is all.

There are multiple ways for people to Denial Of Service attack the emergency services, we can but thank our luck that none of them appear to have been seriously exploited, yet. This is evidence based (which obviously cannot be discussed) and not merely speculation based.

And this is a mature technology!

Mobile telephony was not intended for emergency sensitive use. It was not supposed to carry life-critical traffic, and yet it now does. If anything I suspect that people rely on mobile phones more than landlines in many places now.

People in Downing College complain loudly when the Internet is unavailable for 1.5 days in a month? Comments like "I can't do without it", "I feel lost", "I can't get on with my work". Estimates as to impact of actual failure of the Internet include economic collapse of event tangentially related companies like insurance companies within a week.

Not bad, for a technology described by a networking expert as "a toy that no-one was ever supposed to actually use".

Also Consider also that most of the Internet runs on PCs, running Windows and UNIX, the very things that you're concerned about the reliability of when they store your work/photos.......

The same applies all over the place. Even the reliability paranoid military have struggled to resist the appeal of consumer end products.

--

The same attitude applies to software.

I have worked on multiple projects that were not life-critical certified, but because they almost never failed, people grew to depend on them. In the bad cases you hear things like "It's OK, they'll fall back to paper if it fails"

Even in the more optimistic cases when they had backup systems, they aren't used for years.

Even if we assume the optimistic case, that failures are randomly distributed, can you remember how to do something that you haven't done for 5 years? Can you remember how manage styles in MS Word 2.0 without looking?

Can you remember how OLE embedding worked in Windows 3.0?

And this is the ideal situation. Realistically during failures you're likely to would be working under stress possibly in a hostile, noisy, distracting environment. Experiments show that humans get almost everything that isn't purely internalised wrong in such circumstances (E.g. Three Mile Island)

My point is this:

"This technology is not certified for life critical use" is an exercise in blame management, it is technically and sociologically vacuous.

And the implication for design?

Should we deliberately design our systems to periodically fail to make sure they're not being relied on? I gather Tescos does this, every year they run an unscheduled real disaster test by pulling certain power cables.

I think that we should at least think about it.....

I finally understand

2006-09-05T01:28:00.000+01:00

It's 01:23 in the morning, I'm sitting waiting for my compiler to finish the latest test case as why my application randomly quits when I modify a CPU flag.

Until tonight, I didn't understand why people complained about the speed of C++ compilers.

I now get it.

Ten years of Cognitive Dimensions

2006-08-18T15:07:00.000+01:00

The Special CDs issue of JVLC has been published. :-)

I have a paper co-authored in it with Thomas Green, Ann Blanford, Chris Roast and Steven Clarke.

Full text available here.

(www.sciencedirect.com/science/journal/1045926X)

In it, I argue for the seperation of cognitive and information structural concerns in the Cognitive Dimensions framework, and use the resultant 'refactored' dimension set to bring new clarity to some complex cognitive problems.

The work has directly influenced my current work on Cognitive modelling of Security that I'm currently writing up. I believe that it offers a powerful view, esp. for modelling security critical user interfaces.

Thanks to my co-authors and Alan Blackwell.

When you're standing in deep water

2006-07-13T23:50:00.000+01:00

About 18 months ago, around the 10th of Jan, 2005, I experienced what I would now euphemistically describe as an 'unmanaged data loss incident'. My secondary hard disk died, whilst copying data to a DVD. I lost ~1000 photos. A healthy dose of black magic and many tense hours with a data recovery tool resurrected ~95% of the data.

I learnt many lessons that day, several of which have been repeatedly confirmed over the intervening year and a half. This year, as a Student IT person I have seen several upset people with failed machines.

To summarise the lessons learnt, from this and security assurance work:

Backup the right things

People backup what they think they would be upset about if they lost. This is often the wrong thing. People backup things they perceive as having financial value, such as work, but when the data goes away, they care more about their photos.

Things with emotional value require backups as well.

Make it easy

If your backups aren’t quick and easy to do, you won’t do them. We see this in security time and time again, if security features get in the way, they’re going to get ‘temporarily disabled’. It’s amazing how long temporarily can be.

Viscosity is your worst enemy. I will have more to say about this another day.

Manage the data volumes

‘But I’ve got so many photos, I can’t backup them’

Tell me about it. I currently have 205Gb of original and derived files, increasing at 20-50Gb a month, dependent on the number of jobs I do and how much time I have.

I’ve been using a split Originals | Processed structure with the obvious (to a pre-metadata age Compsci), approach of putting each shoot in a folder with a hierarchical (Year – Month – Date & Title). Backups were run based on a list of folders on each incrementally numbered DVD. However this approach is no longer sufficient:

-> I often have folders which exceed 4.7Gb.

-> I now shoot with multiple cameras, with intersecting namespaces.

-> My files names have started wrapping around, making filenames non-unique, even from the same camera.

-> Finding files by date is becoming increasingly difficult.

-> Synchronising derived files in backups is effectively impossible. I am creating derived files of originals that are over a year old, this means tracing which DVD backups are now out of date and replacing them, over splitting them into multiple DVDs. This is inefficient in terms to time and consumed volumes of media. Restoration from a serious fire would be terrible at the moment, probably involving 100+ hours of work.

So, it’s time to migrate to a Metadata Driven Workflow. This is my first use of metadata in anger, and I’m concerned as to how well it will work. The basic idea is:

Camera -> Download folders. (Fast temp backup to secondary disk)
Merge/Sort -> Task folder (Merge based on data-time-serial, to prevent file name collisions from different cameras)
Working folder backup (Network drive temp backup)

--
Rate, Apply Metadata, Apply Camera Raw settings
--

Split RAW into incremental ‘data buckets’, each of which will fit on a DVD
Create DNG files from RAW, split to DNG buckets
Burn RAW buckets to DVD (Store offsite)
Burn DNG buckets to DVD (Separate at separate offsite location)
Move DNG into archive or process to derived files

There are other various complications, but that’s the general idea. Details and reflections later will be given later. The system is currently in preliminary testing prior to a full migration.

Manage obsolescence

Obvious: DVDs decay, get bleached, suffer heat/moisture exposure. So be prepared to regenerate them, by reburning.

Not so obvious: JPEG files will probably still be readable in 5 years, possibly even 15. I would not like to say the same about Canon CR2, or Sony SRF files. Hence I’m using DNG, which I think, if the worst came to the worst, I could write a parser for.

However, you should plan to systematically migrate data to new formats if you want to be able to painlessly access your data in a decade.

Manage security implications

Several issues here. One that is globally relevant, others that may be less so.

Attacks to a local machine, be they viruses, or something more serious can cause soft damage to files. These may not be detected, propagated into files which are then backed up, so instead of backing up the data, the corruption and the virus are being backed up. User error may cause similar problems.

[Removes rant on how people who ignore user error in managing backups should be banned from working in the area :-)]

This problem can be helped by using ‘immutable media’ such as DVD, which can’t be practically changed. However it only protects from when the DVD is written. General good computing techniques are also required, run as a low privilege user, run machine protection software etc. etc.

And then there’s this problem’s big nasty brother, confidentiality. For many, this will be less of a problem, but I manage a lot of confidential and protected information. It’s no use in making data accessible in the advent of a serious problem, if all an attacker needs to do to get the data is intercept one of these streams, or compromise a machine, or force a system into a recovery mode. Backup/Failover systems often interact with security in a seriously bad way. I will have more to say on this in the future as well.

I am not going to discuss my solution to this, but suffice to say, it is amongst the hardest of the problem, calling for a sophisticated network protection architecture, strong applications of crypto to move trust around, and aggressive audit logging.

Disaster Recovery Simulations

I don’t trust anything until I’ve tested it. I’m planning my first major disaster recovery test shortly after the migration completes later this month. Time to find my mistakes in a controlled manner :-)

Threat model

But, having said all this, be realistic, understand the threats, the potential harm and choose sensible solutions. There’s no point in spending all your time doing backups, rather than producing work to backup.

I have multiple scenarios and goals, the non-security threat model is:

Threat: Single hardware failure (e.g. Disk crash)
Maximum accepted loss: 24 hours work

Threat: Location failure (e.g. Fire, flood, lightning)
Maximum accepted loss: 7 days work

I consider multiple location failure to be a security problem, not a reliability one.

So that’s the idea, now we’ll see how well it will go.

The estimated initial cost (ignoring the time and ongoing maintenance costs(!!!!)) of all this is:

If the photos are kept unprocessed, 60p per GB of originals (CR2)
If the photos are processed, £3 per GB of originals (CR2)

I thought the film was supposed to be free with digital cameras?

MetaBlogging

2006-06-14T19:18:00.000+01:00

Inspired by the sterling examples provided by others and further others I have finally made a fledgling entry into the world of blogging.

In a moment of revision induced boredom, combined with the guilt of ignoring Marc Eisenstadt for too long, and my replies to others' blogs becoming as long as a blog in itself, I decided, reluctantly, that I will blog.

From there it became a question of choosing a provider. I could handcode it myself?

Rejected; out of laziness, incompetence and a general admittance that I'm very afraid of writing web-software. Besides, it seems like a very economically dubious thing to do...

The idea of letting other people run bits of my website for me, is still somewhat alien to me, despite my generally positive and always professional experiences over at Smugmug it is still with some trepidation, not to mention outright terror that I let someone else control a fraction of a website that contains my content.

Wordpress seemed nice, but inflexible unless I was hosting it myself. My hosting infrastructure is all set up to handle ASP.NET not PHP, and again the knowledge of my ignorance, and general reluctance to spend yet more on hosting counted against this.

So Blogger it is, for now at least...

This whole thing seems unclear to me:

If I do blog, will anyone read?

Can I blog about most of what I find interesting?

Do I wish to blog about much of what I find interesting?

How does blogging fit in between my carefully managed opinions for the world, and the ranting discourses that my friends kindly suffer?

How will a blog cope with being interspersed by comments on garden parties, and discussions of information efficient communication by SMS?

Blah....

A Brave New World indeed....