“I could easily have become an academic to start with,” says Charles Weir, by way of explaining how it is that relatively late in his life he’s publishing his first peer-reviewed journal articles. Weir’s long career in advancing software development is the backdrop to the Master’s degree he completed at Lancaster University in 2016 and his participation in the Why Johnny doesn’t write secure software” project. He recently completed an NCSC-funded small grant project on interventions to provide security support for developers.
Weir’s interest in secure software has developed over time through a series of career moves: he’s been a programmer and analyst; a consultant; the owner and manager of the Cumbria-based bespoke app development house Penrillian; and now he’s an academic researcher. Along the way, he was an early adopter of object-oriented programming, agile development, software patterns, and more recently secure app design when working on EE Cash on Tap, a predecessor to Android Pay. The consistent thread through all that, he says, is “the excitement of the bleeding edge, the new cutting-edge things that require you to really think things through and build things for the first time. I’m not good at repeating a task, and really like thinking things out the first time.”
Weir began his career with a physics degree from Cambridge, then, as he describes it, “went around the world with a rucksack”. On his return, he worked briefly for a computer retailer before joining Reuters’ new microprocessor group, where he had his first experience of teamwork. There, the “bleeding edge” he encountered included the BBC Micro, system design, one-way protocols, and, finally, object-oriented programming. After seven years, part of it in the US, he segued into consultancy, working for other companies in Chicago and learning more about object-oriented software. Back in the UK he joined Object Designers, a virtual consultancy company led by OO pioneers Steve Cook and John Daniels. Here everyone worked from home, visited the companies they worked with, and met up about once a month. The consultancy, he says, “gave me a chance to do some of the stuff that had been a bit theory.”
One of Weir’s customers during this period was Symbian, then hoping to conquer the world with its mobile operating system, EPOC, and when it came time to close down the consultancy Weir spent three days a week helping Symbian’s internal teams design elements of the software destined for its new phones. The release of the iPhone in 2006 ended Symbian’s hopes of dominating the mobile operating system market, but it was a forward-thinking company: the mobile landscape Symbian CEO Colly Myers described in 2000 is remarkably accurate today.
A particular technique Weir dates to that time is one he calls “Captain Oates”, after the Antarctic explorer Lawrence Oates, who famously sacrificed himself in the hopes of saving his fellow explorers. In software, Weir’s “Captain Oates” terminates when memory is running short so that other apps can keep running. This technique is now frequently used, typically as part of the operating system.
“Captain Oates” surfaced while writing the 2000 book Small Memory Software with James Noble, whom he’d met at conferences on software patterns, which came to public attention in 1994 with the publication of the book Design Patterns: Elements of Reusable Object-Oriented Software. Based on this idea of reusable design architectures coupled with their backgrounds writing software for very small devices, Weir and Noble “dug up a whole series of patterns.” As they went along, they found that these applied not only to the small, memory-constrained, matchbox-sized computers they were used to but bigger systems that had to cope with memory-taxing amounts of data, such as the system that collects satellite data for NASA.
In 2002 Weir set up the bespoke app development house Penrillian, which created apps for Vodafone – in particular, the software for the Vodafone mobile broadband dongles – and to a lesser extent for other network operators. His commercial arrangements with Symbian gave him access to the company’s source code, enabling Penrillian to do work others couldn’t.
In 1998, Weir wrote a short guide, Patterns for Designing in Teams (PDF), intended to help developers working in teams improve their work. While the guide isn’t about security specifically, it provides a basis for thinking about how to incorporate security into the design process.
“I’m very interested in teams,” Weir says. “Because I’m not naturally an easy team player, I find the intellectual question of what makes a team work very interesting. I can be fascinated by it even though naturally I’m not particularly good at it – I can be more analytic and see things that people who take them for granted just don’t.” This aligns nicely with his work as a consultant, which taught him to approach every room as if he were the stupidest person in it. “Because you usually are, in terms of what they know about. But every now and then there might be something you can help them with.”
By 2012, Weir was finding that “The market for smart people in the UK doing mobile apps had really gone.” All that work was going offshore, so Weir looked around for something that wouldn’t soon follow suit, and landed on payment apps. EE Cash on Tap was a precursor to today’s Apple/Android Pay, though the commercial and technical complexity of EE’s approach meant it never became mainstream. It was this project that sparked Weir’s interest in security: “I realised there were going to be large amounts of money floating around, and if I didn’t do a reasonable job I could be liable for all that money. That was the point at which I reached out a hand for something like the “Dummies Guide to Software Security for Programmers” and found there was a gap in the shelf, and realised that the more I looked into it the less I could find anyone supporting anybody doing this.”
Co-author James Noble suggested he get in touch with Awais Rashid, and in 2015 Weir began his masters-by-research at Lancaster. The many interviews he conducted with developers and others – “I shamelessly used connections from my previous work” – led to his paper, I’d Like to Have an Argument, Please (PDF), in which he finds that secure software development is helped when the developers are challenged from multiple directions and made to think. The paper has been well-received, and led to other peer-reviewed papers. One of these studies the differences among the responses and concludes that secure app software development is at a very early stage, and another for the FSE conference suggests using games as a teaching tool because developers are so reluctant to read books – “Angry Birds meets software security”.
What surprised him most in this work, which was brought out in the “Argument” paper, is the wide range of approaches and advice developers were using. “I had sort of assumed that there was some secret out there that everyone knew except me. It turns out there wasn’t.” While there is a lot of material to tell developers the ten top bugs of the week, what mistakes not to make, or how to use specific operating system security features, there still isn’t much telling developers how to do secure software in general, particularly in the mobile phone space. Worse, what there is tends to be rule-bound and is generally loathed by developers. Around 2010, he says, there was a shift away from the secure development processes of the past, led by Gary McGraw, who moved to measure whether security had been achieved without caring about how people got there. “He was the only person I came across who had written the book I was looking for, but it wasn’t very digestible from a developer point of view.” One of the difficulties in developing EE Cash, for example, was being told – wrongly, as it turned out – that various things couldn’t be done because they would violate EMV or PCI rules. Finding out that handed down constraints like these are excuses rather than essentials is enough to make any developer into a suspicious refusenik.
If there were magic answers to this conundrum, academic research seemed like the place to start looking. “My goal now is to change the world in one particular way, which is to get the software people write to be that small bit more secure.”