Print and be damned

The private sector, as everybody knows, has clear and customer-friendly systems and services, because the customer is king. The public sector, on the other hand, revels in the obscure and incomprehensible because… well, just because.

And so it was with a light heart that I set out to fix a security flaw in my printer (one of those chores which never existed until Moore’s law came along to free us from drudgery).

The rest of this post sets out the process in mind numbing detail, partly as minor therapy for me, but more importantly because as with several recent posts, telling these stories is a powerful way of bringing to life why service design is not just an affectation and because every one of them is a reminder that we are constantly at risk of inflicting this pain unless we are as constantly vigilant in avoiding it. Fixing printers, opening bank accounts and paying for parking permits don’t on the surface seem to have much in common, but in each case the problem was not that the task could not be completed, it was that there was no sign that anybody involved in designing the service had ever systematically worked through what it would be like to do it as an ordinary user.

The blow by blow account which follows is a fairly grim one, but there is some good news. I went through this process and wrote the account back in January but never quite finished it. Quickly checking the links today shows that the process is now not quite as bad as it was then, with broken links fixed, cumbersome steps made slicker and FTP documents converted into web pages (it also reveals that the printer needs updating again, but lets not worry about that for now).

But that in turn throws up an interesting question about agile approaches. Iterate, then iterate again say the GDS design principles:

The best way to build effective services is to start small and iterate wildly. Release Minimum Viable Products early, test them with real users, move from Alpha to Beta to Launch adding features and refinements based on feedback from real users.

I am with them on that, not least because of the risk they identify in the small print of bottleneck by specification. There is a risk the other way too, though: how good does it have to be to reach the minimum standard? Is anything functional good enough for a first attempt? If we are feeling relatively generous, we can set the bar fairly low for publishing a security alert where there may be real urgency (though it’s not as if this was the first time there had ever been a security alert), but there is a cost. If it was bad enough the first time, it doesn’t matter how good it gets by the second or third time, because I won’t be back to see. Not so much of an issue, perhaps, for an obscure bit of technical support, but critically important in trying to establish a customer relationship.

So the thing which is too often missed in the practice, rather than the rhetoric, of minimum viable products (though not, to be clear, by GDS) is that the minimum is about scope more than it is about quality. That’s not to say that further iterations won’t improve quality; done well of course they will. It is that iteration and user feedback are no substitute for not having done a good enough job in the first place.

And so to the quest through a land of magic and adventure…

The first stop was the HP support document, snappily titled, HPSBPI02728 SSRT100692 rev.2 – Certain HP Printers and HP Digital Senders, Remote Firmware Update Enabled by Default. My printer was listed as one which was vulnerable and eventually we come to the instructions for what to do about it:

How to Download the Firmware Update

Browse to www.hp.com/go/support then:

• Select “Drivers & Software”
• Enter the product name listed in the table above into the search field
• Click on “Search”
• If the search returns a list of products click on the appropriate product
• Under “Select operating system” click on “Cross operating system (BIOS, Firmware, Diagnostics, etc.)”
  If the “Cross operating system …” link is not present, select any Windows operating system from the list.
• Select the appropriate firmware update under “Firmware”

That’s not exactly slick. Since most of this starting page consists of the list of affected printers, just how hard would it have been to link each one directly to where the appropriate firmware was to be found? Never mind: let’s jut click the link.
Rather unfortunately, that link turns out to be broken, though including an impressive level of self-referential analysis:

If you clicked on a link to get here, there may be a problem with the link.

Well, yes.

All is not lost, though, as there is a search box at the top of the page. Putting in the model number of the printer should do the trick – and indeed it does. That gives me 135 search results and a helpful offer to narrow them down to drivers and software.

Accepting that offer filters the results down to fifteen – and top of the list are firmware updates. Excellent. Except that the most recent files listed are dated 2 October and the vulnerability was first announced on 30 November and checking back to the list on the support bulletin tells me that the version I want is dated 14 December. It’s definitely not in this list.

But here is another obscure but potentially helpful message:

The following is a list of documents that match “p2055″. Alternatively, you may click here to search for products that match “p2055″.

And, with a few more clicks, we reach another set of drivers and software results, which doesn’t include the October firmware update, but does include the December version which is the one we need. The end is now in sight. Or perhaps not. The firmware update itself is fairly straightforward to install, and once that has finished, perhaps we can stop with a sense of a job well done.

Or perhaps not. Because the point of the firmware update is to allow remote updating to be turned off. There is still the matter of doing the actual turning off.

To find out how to do that – and remember that at this point there is not the slightest indication on screen that there is anything further which needs doing – we have to go back to the original support document. Buried towards the end, it tells us:

How to Disable the Remote Firmware Update (RFU)

For instructions about how to disable the RFU please refer to the following document: Configuring Remote Firmware Update on HP Printers and Multifunction Devices

The document is available using ftp:

ftp.usa.hp.com
account: sb02728
password: Secure12

or

ftp://sb02728:[email protected]/

File name: Configuring Remote Firmware Update on HP Printing Devices.pdf

So to get the critical instructions, it’s necessary to get a pdf document from a password protected ftp listing. Can they be serious? Yes, it turns out, they can be and are.

With document in hand, it’s now just a matter of working out what to do. There are apparently three possible methods, depending on which printer. The first uses something called the HP Webjet Admin fleet management tool. That sounds a bit heavy duty for my simple home printer, so let’s press on. The next suggestion is the Embedded Web Server method. That sounds more promising: my printer has definitely got one of those. So this is what to do:

1. Open the EWS configuration interface by entering the device IP address in a web browser
2. Select the Settings Tab
3. Select Security Menu

Easy. Or at least the first two steps were easy: my computer doesn’t have a security menu and the screen looks quite different from the picture in the instructions. So the last step is impossible.

Then, after those two methods have been described – and only then – there is a list of printers showing which method applies to which printer. Mine it seems is sufficiently at the cheap and nasty end of the range that what is needed can only be done by poking buttons on the printer itself. Job eventually done.

Original post