Learn to hack online – h4x0rz and pros

Removing these videos hinders defenders much more significantly than it impairs the attackers.

Over the past week, there has been a minor furore over YouTube’s decision to block certain “hacking” videos.  According to The Register, the policy first appeared on the 5th April 2019:

“Instructional hacking and phishing: Showing users how to bypass secure computer systems or steal user credentials and personal data.”

Now, I can see why they’ve done this: it’s basic backside-covering.  YouTube – and many or the other social media outlets – come under lots of pressure from governments and other groups for failing to regulate certain content.  The sort of content to which such groups most typically object is fake news, certain pornography or child abuse material: and quite rightly.  I sympathise, sometimes, with the social media giants as they try to regulate a tidal wave of this sort or material – and I have great respect for those employees who have to view some of it – having written policies to ban this sort of thing may not deter many people from posting it, but it does mean that the social media companies have a cast-iron excuse for excising it when they come across it.

Having a similar policy to ban these types of video feels, at first blush, like the same sort of thing: you can point to your policy when groups complain that you’re hosting material that they don’t like – “those dangerous hacking videos”.

Hacking[3] videos are different, though.  The most important point is that they have a  legitimate didactic function: in other words, they’re useful for teaching.  Nor do I think that there’s a public outcry from groups wanting them banned.  In fact, they’re vital for teaching and learning about IT security, and most IT security professionals and organisations get that.  Many cybersecurity techniques are difficult to understand properly when presented as theoretical attacks and, more importantly, they are difficult to defend against without detailed explanation and knowledge.  This is the point: these instructional videos are indispensable tools to allow people not just to understand, but to invent, apply and maintain defences and mitigations against known attacks.  IT security is hard, and we need access to knowledge to help us defeat the Bad Folks[tm] who we know are out there.

“But these same Bad Folks[tm] will see these videos online and use them against us!” certain people will protest.  Well, yes, some will.  But if we ban and wipe them from widely available social media platforms, where they are available for legitimate users to study, they will be pushed underground, and although fewer people may find them, the nature of our digital infrastructure means that the reach of those few people is still enormous.

And there is an imbalance between attackers and defenders: this move exacerbates it.  Most defenders look after small numbers of systems, but most serious attackers have the ability to go after many, many systems.  By pushing these videos away from places that many defenders can learn from them, we have removed the opportunity for those who most need access to this information, whilst, at the most, raising the bar for those against who we are trying to protect.

I’m sure there are numbers of “script-kiddy” type attackers who may be deterred or have their access to these videos denied, but they are significantly less of a worry than motivated, resourced attackers: the ones that haunt many IT security folks’ worst dreams.  We shouldn’t use a mitigation against (relatively) low-risk attackers remove our ability to defend against higher risk attackers.

We know that sharing of information can be risky, but this is one of those cases in which the risks can be understood and measured against others, and it seems like a pretty simple calculation this time round.  To be clear: the (good) many need access to these videos to protect against the (malicious) few.  Removing these videos hinders the good much more significantly than it impairs the malicious, and we, as a community, should push back against this trend.


1 – it’s pronounced “few-ROAR-ray”.  And “NEEsh”.  And “CLEEK”[2].

2 – yes, I should probably calm down.

3 – I’d much rather refer to these as “cracking” videos, but I feel that we probably lost that particular battle about 20 years ago now.

What’s an HSM?

HSMs are not right for every project, but form an important part of our armoury.

Another week, another TLA[1].  This time round, it’s Hardware Security Module: an HSM.  What, then, is an HSM, what is it used for, and why should I care?  Before we go there, let’s think a bit about keys: specifically, cryptographic keys.

The way that most cryptography works these days is that the algorithms to implement a particular primitive[3] are public, and it’s generally accepted that it doesn’t matter whether you know what the algorithm is, or how it works, as it’s the security of the keys that matters.  To give an example: I plan to encrypt a piece of data under the AES algorithm[4], which allows for a particular type of (symmetric) encryption.  There are two pieces of data which are fed into the algorithm:

  1. the data you want to encrypt (the cleartext);
  2. a key that you’ve chosen to encrypt it.

Out comes one piece of data:

  1. the encrypted text (the ciphertext).

In order to decrypt the ciphertext, you feed that and the key into the AES algorithm, and the original cleartext comes out.  Everything’s great – until somebody gets hold of the key.

This is where HSMs come in.  Keys are vital, and they are vulnerable:

  • at creation time – if I can trick you into creating a key some of whose bits I can guess, I increase my chances of being able to decrypt your ciphertext;
  • during use – while you’re doing the encryption or decryption of your data, your key will be in memory, which means that if I can snoop into that memory, I can get it (see also below for information on “side channel attacks”;
  • while stored – unless you protect your key while it’s “at rest”, and waiting to be used, I may have opportunities to get it.
  • while being transferred – if you store your keys somewhere different to the place in which you’re using it, I may have an opportunity to intercept it as it moves to the place it will be used.

HSMs can help in one way or another with all of these pieces, but why do we need them?  The key reason is that there are times when you can’t be certain that the system(s) you are using for creating, using, storing and transferring keys are as secure as you’d like.  If the keys we’re talking about are for encrypting a few emails between you and your spouse, well, you might find it embarrassing if they were compromised, but if these keys are ones from which, say, you derive all of the credit cards chip keys for an entire bank, then you have a rather larger problem.  When it comes down to it, somebody with sufficient privilege on a standard computing system can look at any part of memory – unless there’s a TEE[5] (Oh, how I love my TEE (or do I?)) – and if they can look at the memory, they can see the key.

Worse than this, there are occasions when even if you can’t see into memory, you might be able to derive enough information about a key – or the ciphertext or cleartext – to be able to mount an attack on it.  Attacks of this type are generally called “side channel attacks”, and you can think of them as a little akin to being able to work out the number of cylinders and valves a car[6] engine has by listening to it through the bonnet[7].  The engine leaks information about itself, even though it’s not designed with that in mind.  HSMs are (generally) good at preventing both types of attacks: it’s what they’re designed to do.

Here, then, is a definition:

An HSM is piece of hardware with protected storage which can perform cryptographic operations attached to a system – via a network connection or other connection such as PCI – and which has physical protection from various attacks, from side attacks to somebody physically levering open the case and attaching wires to important components so that they can read the electrical signals.

Many HSMs undergo testing to get certification against certain standards such as “FIPS 140” to show their ability to withstand various types of attack.

Here are the main uses for HSMs.

Key creation

Creation of keys is, as alluded to above, a very important operation, and one where side attacks have proved very effective in the past.  HSMs can provide safe(r) key generation, and ensure appropriate levels of randomness (entropy) for the required strength of key.

Key storage

HSMs are typically designed so that if somebody tries to break into them, they will delete any keys which are stored within them, so they’re a good place to store your keys.

Cryptographic operations

Rather than putting your keys at risk by transferring them to another system, and away from the safety of the HSM, why not move the cleartext to the HSM (encrypted under a transport key, preferably), get the HSM to do the encryption with the keys that it already holds, and then send the ciphertext back (encrypted under a transport key[8])?  This reduces opportunities for attacks during transport and during use, and is a key use for HSMs.

General computing operations

Not all HSMs support this use (almost all will support the others), but if you have sensitive operations with lots of keys and algorithms – which, in the case of AI/ML, for instance, may be sensitive (unlike the cryptographic primitives we were talking about before), then it is possible to write applications specifically to run on an HSM.  This is not a simple undertaking, however, as the execution environment provided is likely to be constrained.  It is difficult to do “right”, and easy to make mistakes which may leave you with a significantly less secure environment than you had thought.

Conclusion – should I use HSMs?

HSMs are excellent as roots of trust for PKI [9] projects and similar.  Using them can be difficult, but most these days should provide a PKCS#11 interface which simplifies the most common operations.  If you have sensitive key or cryptographic requirements, designing HSM use into your system can be a sensible step, but knowing how best to use them must be part of the architecture and design stages, well before implementation.  You should also take into account that operation of HSMs must be managed very carefully, from provisioning through everyday use to de-provisioning.  Use of an HSM in the cloud may make sense, but they are expensive and do not scale particularly well.

HSMs, then, are suited to very particular use cases of highly sensitive data and operations – it is no surprise that their deployment is most common within military, government and financial settings. HSMs are not right for every project, by any means, but form an important part of our armoury for the design and operation of sensitive systems.


1 – Three Letter Acronym[2]

2 – keep up, or we’ll be here for some time.

3 – cryptographic building block.

4 – let’s pretend there’s only one type of AES for the purposes of this example.  In fact, there are a number of nuances around this example which I’m going to gloss over, but which shouldn’t be important for the point I’m making.

5 – Trusted Execution Environment.

6 – automobile, for our North American friends.

7 – hood.  Really, do we have to do this every time?

8 – why do you need to encrypt something that’s already encrypted?  Because you shouldn’t use the same key for two different operations.

9 – Public Key Infrastructure.

Why Chatham House Rulez for security

Security sometimes requires sharing – but not attribution

In June 1927, someone had a brilliant idea.  Or, at least, that’s when the idea was first codified, at a meeting of Royal Institute of International Affairs at Chatham House in London.  The idea was this: all attendees of the meeting could quote comments made at the meeting, but they weren’t allowed to say who had made the comment.

This became known as the Chatham House Rule, and the most recent incarnation is defined thus:

When a meeting, or part thereof, is held under the Chatham House Rule, participants are free to use the information received, but neither the identity nor the affiliation of the speaker(s), nor that of any other participant, may be revealed.

This is brilliantly clever.  It allows at least two things:

  1. for the sharing of information which might be sensitive to a particular entity when associated with that entity, but which is still useful when applied without that attribution;
  2. for the sharing of views or opinions which, when associated with a particular person or organisation, might cause wider issues or problems.

The upshot of this is that if somebody (say, Person A) values the expertise, opinion and experience of another person (say, Person B), then they can share that other person’s views with people who may not know Person B, or whose views on Person B may be biased by their background or associations.  This is a form of transitive trust, and situations where transitive trust are made explicit are, in my opinion, to be lauded (such trust relationships are too often implicit, rather than explicit).

The Chatham House Rule and open source

What has this got to do with open source, though?  My answer is: a lot.

Security is one of those areas which can have an interesting relationship with open source.  I’m passionately devoted to the principle that open-ness is vital to security, but there are times when this is difficult.  The first is to do with data, and the second is to do with perceived expertise.

Why data is difficult

While we all (hopefully) want to ensure that all our security-related code is open source, the same cannot be said for data.  There is absolutely a place for open data – citizen-related data is the most obvious, e.g. bus timetables, town planning information – and there’s data that we’d like to be more open, but not if it can be traced to particular entities – aggregated health information is great, but people aren’t happy about their personal health records being exposed.  The same goes for financial data – aggregated information about people’s spending and saving habits is extremely useful, but I, for one, don’t want my bank records revealed to all and sundry.

Moving specifically to security, what about data such as the number of cyber-attacks – successful and unsuccessful – against companies?  The types that we most successful?  The techniques that were used to mitigate?  All of these are vastly useful to the wider community, and there’s a need to share them more widely.  We’re seeing some initiatives to allow this already, and aggregation of this data is really important.

There comes a time, however, when particular examples are needed.  And as soon as you have somebody stand up and say “This is what happened to us”, then they’re likely to be in trouble from a number of directio

ns, which may include: their own organisation, their lawyers, their board, their customers and future attackers, who can use that information to their advantage.  This is where the Chatham House Rule can help: it allows experts to give their view and be listened to without so much danger from the parties listed above.

It also allows for other people to say “we hadn’t thought of that”, or “we’re not ready for that” or similar without putting their organisations – or their reputations – on the line.  Open source needs this, and there are times when those involved in open source security, in particular, needs to be able to share the information  they know in a way which doesn’t put their organisations in danger.

Why expertise is difficult

Another area of difficulty is expertise, or more specifically, trust in expertise.  Most organisations aim for a meritocratic approach – or say they do – at least within that organisation.  But the world is full of bias, particularly between organisations.  I may be biased against views held or expressed by a particular organisation, just because of their past history and my interactions with that company, but it is quite possible that there are views held and expressed by individuals from that company which, if separated from their attribution, I might take seriously.  I may be biased against a particular person, based on my previous interactions with him/her, or just on my underlying prejudices.  It only needs one person who does not hold my biases to represent those views, as long as they personally trust the organisation, or even just the person, expressing them, to allow me to process and value those views myself, gaining valuable insight from them.  The Chatham House Rule can allow that to happen.

In fact, the same goes for intra-organisation biases: maybe product management isn’t interested in the views of marketing, but what if there are important things to learn from within that department, that product management can’t hear because of that bias?  The Chatham House Rule allows an opportunity to get past that.

To return to open source, many contributors are employed by a particular organisation, and it can be very difficult for them to express opinions around open source when that organisation may not hold the same views, however carefully they try to separate themselves from the official line.  Even more important, in terms of security, it very well be that they can bring insights which are relevant to a particular security issue which their company is not happy about being publicly known, but which could benefit one or more open source projects.  To be clear: I’m not talking, here, about exposing information which is specifically confidential, but about sharing information with the permission of the organisation, but within specific constraints.

More on open source

There are all sorts of biases within society, and open source is, alas, not without its own.  When a group of people gets to know each other well, however, it is often the case that members of that group can forge a respect for each other which goes beyond gender, age, academic expertise, sexuality, race or the like.  This is a perfect opportunity for meetings under the Chatham House Rule: it gives this group the chance to discuss and form opinions which can be represented to their peers – or the rest of the world – without having to worry so much about any prejudices or biases that might be aimed at particular members.

Finally – a note of caution

The Chatham House Rule provides a great opportunity to share expertise and knowledge, but there is also a danger that it can allow undue weight to be expressed to anecdotes.  Stories are a great way of imparting information, but without data to back them up, they are not as trustworthy as they might be.  Because the Chatham House Rule inhibits external attribution, this does not mean that due diligence should not be applied within such a meeting to ensure that information is backed up by data.

Are my messages safe? No, but…

“Are any of these messaging services secure?”

Today brought another story about insecurity of a messenger app, and by a brilliant coincidence, I’m listening to E.L.O.’s “Secret Messages” as I start to compose this post. This article isn’t, however, about my closet 70s musical tastes[1], but about the messages you send from your mobile phone, tablet or computer to friends, families and colleagues, and how secure they are.

There are loads of options out there for messaging services, with some of the better-known including WhatsApp, Facebook Messenger, Google Chat, Signal and Telegram. Then there’s good old SMS. First question first: do I use any of these myself? Absolutely. I also indulge in Facebook, LinkedIn and Twitter. Do I trust these services? Let’s get back to this question later.

A more pressing question might be: “are any of these messaging services secure?” It turns out that this is a really simple question to answer: of course they’re not. No service is “secure”: it’s a key principle of IT security that there is no “secure”. This may sound like a glib – and frankly unhelpful – answer, but it’s not supposed to be. Once you accept that there is no perfectly secure system, you’re forced to consider what you are trying to achieve, and what risks you’re willing to take. This is a recurring theme of this blog, so regular readers shouldn’t be surprised.

Most of the popular messaging services can be thought of as consisting of at least seven components. Let’s assume that Alice is sending a message from her phone to Bob’s phone. Here’s what the various components might look like:

  1. Alice’s messenger app
  2. Alice’s phone
  3. Communications channel Alice -> server
  4. Server
  5. Communications channel server -> Bob
  6. Bob’s phone
  7. Bob’s messenger app

Each of these is a possible attack surface: combined, they make up the attack surface for what we can think of as the Alice <-> Bob and messaging system.

Let’s start in the middle, with the server. For Alice and Bob to be happy with the security of the system for their purposes, they must be happy that this server has sufficiently secure to cope with whatever risks they need to address. So, it may be that they trust that the server (which will be run, ultimately, by fallible and possibly subornable humans who also are subject to legal jurisdiction(s)) is not vulnerable. Not vulnerable to whom? Hacktivists? Criminal gangs? Commercial competitors? State actors? Legal warrants from the server’s jurisdiction? Legal warrants from Alice or Bob’s jurisdiction(s)? The likelihood of successful defence against each of these varies, and the risk posed to Alice and Bob by each is also different, and needs to be assessed, even if that assessment is “we can ignore this”.

Each of the other components is subject to similar questions. For the communication channels, we will assume that they’re encrypted, but we have to be sure that the cryptography and cryptographic protocols have been correctly implemented, and that all keys are appropriately protected by all parties. The messaging apps must be up to date, well designed and well implemented. Obviously, if they’re open source, you have a much, much better chance of being sure of the security of both software (never, ever use cryptography or protocols which have not been not open sourced and peer reviewed: just don’t). The phones in which the software is running must also be uncompromised – not to mention protected by Alice and Bob from physical tampering and delivered new to them from the manufacturer with no vulnerabilities[2].

How sure are Alice and Bob of all of the answers to all of these questions? The answer, I would submit, is pretty much always going to be “not completely”. Does this mean that Alice and Bob should not use messaging services? Not necessarily. But it does mean that they should consider what messages they should exchange via any particular messaging service. They might be happy to arrange a surprise birthday party for a colleague, but not to exchange financial details of a business deal. They might be happy to schedule a trip to visit a Non-Governmental Organisation to discuss human rights, but not to talk about specific cases over the messaging service.

This is the view that I take: I consider what information I’m happy to transfer over or store on messaging services and social media platforms. There are occasions where I may happy to pass sensitive data across messaging services, but break the data up between different services (using “different channels” in the relevant parlance): using one service for a username and another for the associated password, for instance. I still need to be careful about shared components: the two phones in the example above might qualify, but I’ve reduced the shared attack surface, and therefore the risk. I’m actually more likely to require that the password is exchanged over a phone call, and if I’m feeling particularly paranoid, I’ll use a different phone to receive that call.

My advice, therefore, is this:

  1. Keep your devices and apps up to date;
  2. Evaluate the security of your various messaging service options;
  3. Consider the types of information that you’ll be transferring and/or storing;
  4. Think about the risks you’re willing to accept;
  5. Select the appropriate option on a case by case basis:
  6. Consider using separate channels where particularly sensitive data can be split for added security.

1 – I’m also partial to 1920’s Jazz and a bit of Bluegrass, as it happens.

2 – yeah, right.

Don’t talk security: talk risk

We rush to implement the latest, greatest AI-enhanced, post-quantum container-based blockchain security solution.

We don’t do security because it’s fun. No: let me qualify that. Most of us don’t do security because it’s fun, but none of us get paid to do security because it’s fun[1]. Security isn’t a thing in itself, it’s a means to an end, and that end is to reduce risk.  This was a notable change in theme in and around the RSA Conference last week.  I’d love to say that it was reflected in the Expo, but although it got some lip service, selling point solutions still seemed to be the approach for most vendors.  We’re way overdue some industry consolidation, given the number of vendors advertising solutions which, to me, seemed almost indistinguishable.

In some of the sessions, however, and certainly in many of the conversations that I had in the “hallway track” or the more focused birds-of-a-feather type after show meetings, risk is beginning to feature large.  I ended up spending quite a lot of time with CISO folks and similar – CSO (Chief Security Officer) and CPSO (Chief Product Security Officer) were two other of the favoured titles – and risk is top of mind as we see the security landscape develop.  The reason this has happened, of course, is that we didn’t win.

What didn’t we win?  Well, any of it, really.  It’s become clear that the “it’s not if, it’s when” approach to security breaches is correct.  Given some of the huge, and long-term, breaches across some huge organisations from British Airways to the Marriott group to Citrix, and the continued experience of the industry after Sony and Equifax, nobody is confident that they can plug all of the breaches, and everybody is aware that it just takes one breach, in a part of the attack surface that you weren’t even thinking about, for you to be exposed, and to be exposed big time.

There are a variety of ways to try to manage this problem, all of which I heard expressed at the conference.  They include:

  • cultural approaches (making security everybody’s responsibility/problem, training more staff in different ways, more or less often);
  • process approaches (“shifting left” so that security is visible earlier in your projects);
  • technical approaches (too many to list, let alone understand or implement fully, and ranging from hardware to firmware to software, using Machine Learning, not using Machine Learning, relying on hardware, not relying on hardware, and pretty much everything in between);
  • design approaches (using serverless, selecting security-friendly languages, using smart contracts, not using smart contracts);
  • cryptographic approaches (trusting existing, tested, peer-reviewed primitives, combining established but underused techniques such as threshold signatures, embracing quantum-resistant algorithms, ensuring that you use “quantum-generated” entropy);
  • architectural approaches (placing all of your sensitive data in the cloud, placing none of your sensitive data in the cloud).

In the end, none of these is going to work.  Not singly, not in concert.  We must use as many of them as make sense in our environment, and ensure that we’re espousing a “defence in depth” philosophy such that no vulnerability will lay our entire estate or stack open if it is compromised.  But it’s not going to be enough.

Businesses and organisations exist to run, not to be weighed down by the encumbrance of security measure after security measure.  Hence the “as make sense in our environment” above, because there will always come a point where the balance of security measures outweighs the ability of the business to function effectively.

And that’s fine, actually.  Security people have always managed risk.  We may have forgotten this, as we rush to implement the latest, greatest AI-enhanced, post-quantum container-based blockchain security solution[2], but we’re always making a balance.  Too often that balance is “if we lose data, I’ll get fired”, though, rather than a different conversation entirely.

The people who pay our salaries are not our customers, despite what your manager and SVP of Sales may tell you.  They are the members of the Board.  Whether the relevant person on the Board is the CFO, the CISO, the CSO, the CTO or the CRO[3], they need to be able to talk to their colleagues about risk, because that’s the language that the rest of them will understand.  In fact, it’s what they talk about every day.  Whether it’s fraud risk, currency exchange risk, economic risk, terrorist risk, hostile take-over risk, reputational risk, competitive risk or one of the dozens of other types, risk is what they want to hear about.  And not security.  Security should be a way to measure, monitor and mitigate risk.  They know by now – and if they don’t, it’s the C[F|IS|S|T|R]O’s job to explain to them – that there’s always a likelihood that the security of your core product/network/sales system/whatever won’t be sufficient.  What they need to know is what risks that exposes.  Is it risk that:

  • the organisation’s intellectual property will be stolen;
  • customers’ private information will be exposed to the Internet;
  • merger and acquisition information will go to competitors;
  • payroll information will be leaked to the press – and employees;
  • sales won’t be able to take any orders for a week;
  • employees won’t be paid for a month;
  • or something completely different?

The answer (or, more likely, answers) will depend on the organisation and sector, but the risks will be there.  And the Board will be happy to hear about them.  Well, maybe that’s an overstatement, but they’ll be happier hearing about them in advance than after an attack has happened.  Because if they hear about them in advance, they can plan mitigations, whether that’s insurance, changes in systems, increased security or something else.

So we, as a security profession, need to get better a presenting the risk, and also at presenting options to the Board, so that they can make informed decisions.  We don’t always have all the information, and neither will anybody else, but the more understanding there is of what we do, and why we do it, the more we will be valued.  And there’s little risk in that.


1 – if I’m wrong about this, and you do get paid to do security because it’s fun, please contact me privately. I interested, but don’t think we should share the secret too widely.

2 – if this buzzphrase-compliant clickbait doesn’t get me page views, I don’t know what will.

3 – Chief [Financial|Information Security|Security|Technology|Risk] Officer.

Top 7 tips to improve your conference presentation

It’s all about the slides and their delivery.

Well, it’s conference season again. I’ll be off to the West Coast for DeveloperWeek, then RSA, and, I’m sure, more conferences through the coming months. I had a good old rant a few months ago about what I hate about conference speakers, so this seems like a good opportunity to talk about all the good things that I actually enjoy. Well, it might to you, but I’ve got all sorts of spleen-venting that I still want to do, so bad luck: you’re getting another rant.  This time round, rather than getting all shouty about product pitching (which was the subject of my last cross-fest[1]), this time it’s all about the slides and their delivery.

First, here’s a disclaimer, however, or maybe two. One is this: I’m not perfect[3]. I’m may well have been guilty of one or many of the points below in many or all of my presentations. If I have, I’m sorry: and I’d like to know about it, as I like to fix things.

The other is this: not everyone is excellent, or will ever be excellent, at presenting. However hard you try, it may be that it’s never going to be your top skill. That’s fine. On the other hand, if you’re not great at spelling, or you tend to zone out your audience, and you know it – in fact, if you struggle with any of the points below – then ask for help. It doesn’t need to be professional help – ask a colleague or family member, or even a friendly member of the conference staff – but ask for suggestions, and apply them.

Before we delve deeper into this topic, why is it important?  Well, people (generally) go to conferences to learn – maybe to be entertained, as well.  Most conferences require attendees or their organisations to pay, and even if they don’t, there’s an investment of time.  You owe it to the attendees to give them the best value that you can, and ignoring opportunities to improve is arrogant, rude and disrespectful.  You may not feel that bad spelling, punctuation or layout, or even poor delivery, will detract from their experience, but they all distract from the message, and can negatively impact on what people are trying to learn.  They are also unprofessional, and here’s another important point to remember about conference speaking: it’s an opportunity to showcase your expertise, or at least get other people to be enthusiastic about the things you do. If you don’t do the best you can do, you are selling yourself short, and that’s never a good thing.

Here, then, are my top seven tips to improve your conference presentations.  I’m assuming, for the purposes of this article, that you’re presenting a slidedeck at an industry presentation, though many of these points are more broadly applicable.

Layout

I’m not just talking colours and shapes, but also how much is on your slides, whether it’s in sentence or bullet format, and the rest.  Because how your slides look matters.  Not just because of your company’s or organisation’s brand, but because it directly affects how people process the information on your slides.  The appropriate amount – and type – of information to put on a slide varies based on subject, technical depth, audience, for instance, but a good rule to remember is that people will generally read the slides before they listen to you.  If you have more than about 20-30 words on a slide, realise that nobody’s going to hear a word you say until they’ve finished reading, and that’s going to take an appreciable amount of time.  If in doubt, have multiple bullets, and reveal them as you talk (and never just read what’s on the slides: what’s the point of that?).

Spelling, punctuation and grammar

You may not care about spelling, but lots of people do.  It can be distracting to many people to see bad spelling, punctuation or grammar on your slides.  Everybody makes mistakes – and that’s why it’s worth reviewing your slides and maybe getting somebody else to have a look, too.  The amount that this matters will depend on your audience – but correcting slips raises the credibility of the presentation as a whole, because mistakes reflect badly on you, whether you like it or not.

Pictures

Or graphs.  Or diagrams.  I don’t care: put something in there to break up the slides.  I’m really guilty of this: I tend to have slide after slide of text, and forget that many people will just glaze over after the first few.  So I try to find a few pictures, or, even better, relevant diagrams, and put them in.  There are lots of free-to-use pictures available (search for “creative commons” online), and make sure that you provide the correct attribution when you use them.

Style

People have different styles, and that’s fine.  Mine tends towards the jokey and possibly slightly over-enthusiastic, so I need to think about how I pitch different types of information from time to time.  Play to your strengths, but be aware of the situation.  People will remember you if you’re a bit different, and there are times for humorous t-shirts, but there are times for a jacket or tie and a more sombre approach, too.

Tone

Do. Not. Drone.  There’s just nothing worse, particularly when the presenter is just reading the information on the slides.  And after a long lunch[4], it’s so easy to nod off, or just start looking at stuff on your phone or laptop.   If you think you might suffer from a boring tone, ask people for help: practice delivering to them, and then think about how you speak.  It’s relatively easy for most people to learn to modulate their tone a little up and down with practice, and it can make all the difference.  Equally, learning when to stop to allow people to digest the information on a slide can give you – and them – a break: a change is, as they say, as good as a rest.

Delivery

I’ve already said that you mustn’t just read the words on the slides.  I’ll say it again: don’t just read the words on the slides.  Notes are fine – in fact, they’re great, as most people aren’t good at improvising – or you can learn a script, but either way, one of the most important lessons when delivering any type of information is to look at your audience.  Sometimes this is difficult – there may be little light to see them by, or you may find it nerve-wracking actually to look at your audience – so here’s a trick: pretend to look at your audience.  Choose a spot just a few centimetres[5] above where an audience member is – or might be, if you can’t see them – and speak to that.  They’ll think you’re speaking to them.  Next slide, or next bullet, move your head a little, and choose another spot.  Engaging with your audience is vital – and will actually make it easier to manage issues like tone.

Audience

This could have gone first, or could have gone last, but it’s really important.  Think about your audience.  If it’s a conference for techies, don’t use marketing diagrams.  If it’s for CEOs, don’t go into the weeds about compiler design.  If it’s for marketing folks, well, anything goes, as long as there are pictures[6].  Remember – these people have invested their time (and possibly money) in coming to see you to learn information which is relevant to them and their jobs, and you owe it to them to pitch the right sort of information, at the right level.

Summary

I really enjoy conference speaking, but I know that this isn’t true of everybody.  I often enjoy attendee conference sessions, but poor attention to any of the points above can detract from my enjoyment, the amount I learn, and how I feel about the topic and the speaker.  It’s always worth trying to improve: watch TED-talks, take notes on what your favourite speakers do, and practice.


1 – I’m pathetically amused that my spollcheeker[2] wanted that word to be “cross-stitch”.

2 – yes, it was intentional.

3 – just ask my wife.

4 – or during the first session after the conference party the night before – a terrible slot to land.

5 – or slightly fewer inches.

6 – this is mean and unfair to my marketing colleagues.  I apologise.  A bit.

The Twelve Days of Work-Life Balance

12 tips for working at home over the holidays

Disclaimer: the author refuses to take any blame for any resulting disciplinary or legal action taken against readers who follow any of the suggestions in this article.

There’s a good chance that things slow down for the holiday season at your organisation or company[1], and as they do, there’s a corresponding[2] chance that you may end up not going into the office for some of the upcoming days.  Some workplaces expect you to turn up to work in the office unless you’re officially on holiday, while others allow or encourage workers to be based at home and perform their duties there for all or some of the period.  It’s those people who will be spending time at home who are targeted by this article.

Working from home is an opportunity to bunk off and is a complete wheeze a privilege and responsibility to be taken seriously.  There are, however, some important techniques that you should take on board to ensure not only that you continue to be productive but, even more important, that you continue to be seen to be productive.  I’ve split my tips up into helpful headings for your ease of use.

Video calls

Tip 1 (for those who shave): you don’t need to.  Yes, the resolution on webcams has increased significantly, but who’s going to care if it looks like you’ve just rolled out of bed?  The fact that you’ve even bothered shows your commitment to the meeting you’re attending.

Tip 2 (for those who wear make-up): far be it from me to dictate whether you wear make-up or not to meetings.  But if you choose to, there’s no need to refresh last night’s make-up in the morning.  If you’ve staggered home late, you may not have got round to removing your party lipstick and mascara, and it may even have smudged or run a bit: don’t worry.  It’ll look “festive” in the morning, and will encourage a relaxed atmosphere at the meeting.

Tip 3 (for coffee drinkers): you may need an extra cup of coffee in the afternoon, to get you through the day.  Who’s going to know if you add a shot to it?  It’ll keep you warm, and possibly upright.  My wife swears by Baileys.  Or Irish Whiskey.  Or gin.  Pretty much anything, in fact.

Tip 4 (for non-coffee drinkers): cocktails are a no-no for video conferences, unless approved by management (sorry).  However, there are a number of other options to explore.  A Long Island Iced Tea looks like, well, an iced tea.  Whisky (or whiskey) can look like normal tea, and my personal favourite, cherry brandy, looks like a child’s fruit cordial that you didn’t dilute sufficiently.  And tastes fairly similar.

Tip 5 (for clothes wearers): few organisations (of which I’m aware, anyway) have adopted a non-clothing policy for video-calls.  Clothes are required.  My favourite option is to wear a festive jumper, but this is only fun if it has woven-in flashing lights which can distract your fellow participants[3].  Coordinating the periodicity of the flashing with colleagues gets you bonus points.

Tip 6 (also for clothes wearers): wear something on your bottom half.  I know you think you may not be getting up during the call, but when a small child vomits in the background, the postal worker arrives at the door, or you just need another cup of coffee or “beverage” (see tips 3 & 4) to get you through the next two hours, you’ll be grateful for this advice.

Teleconferences (non-video)

Tip 7: use a chat channel to have a side conversation with your peers. You can have hilarious discussions about the intellectual capacity and likely parentage of your management, or even better, play a game of meeting bingo.

Tip 8: the mute button is for cowards.  Yes, wind can be a problem after an over-indulgence at the pub, club or party the night before, and microphones can be quite sensitive these days, but who’s to know it’s you[4]?

Emails

Tip 9: the best time to respond to an email is when you receive it, right?  This will show everybody how devoted you are to your job.  So if it arrives after you’ve already partaken of a brew or two down the pub, or sampled the herbal opportunities recently decriminalised in your state in your bedroom, then replying immediately will almost certainly be considered responsible and professional.  And auto-correct will almost certainly act in your favour: after all, your boss really is a complete duck, yes?

Tip 10: pepper your emails with poor festive puns[5].  It’s just what you do.

Family

Tip 11: you may have agreed to “work” over this period as an excuse to avoid spending too much time with the family[6], but there’s always the chance that they will barge into your office, throw up in the hall (see tip 6), or just fall asleep on your keyboard[7].  Invest in a lock on your office door, or work somewhere out of range[8].  Your work is important, and you must guard against unwanted interruptions, such as being awoken from an important doze.

Productivity

Tip 12: it’s your responsibility, when working from home, to ensure that you maintain your productivity.  But breaks are important.  There’s a tricky balance here between protecting your time from the family (you don’t want them to notice that you’re not online 100% of the time) and taking sensible amounts of breaks.  Assuming that you’ve taken my advice about locking your office door, then placing an XBox or similar gaming console on your desk next to your work computer is a great way of allowing yourself some downtime without risking the wrath of your family (assuming careful monitor placement and controller handling).

Tip 12a (extra tip!): if you’re not careful, too much time hidden away from the family will get you in trouble.  My piece of advice here is to offer to help.  But on your own terms.  Rushing out of your office[9], looking harried and then announcing “I’ve got ten minutes until my next call, and I’m feeling guilty: is there anything I can do?” can gain you useful credit without the risk of your having to do anything too taxing.

Summary[10]

You can maintain a productive and professional workplace at home if called to do so by your organisation.  It is your responsibility to balance the needs of work with your needs and, of course, the needs of your family.

Have a Merry Christmas (or other festival) and a Happy New Year (whenever it falls for you)!


1 – this is generally a Judaeo-Christian set of holidays, but I hope that this article is relevant to most holidays: religious, national, regional or secular.

2 – and possibly correlateable, though check out one of my favourite XKCD comics: https://xkcd.com/552/.

3 – owners of luxuriant beards or heads of hair may prefer to weave flashing fairy lights into their hair for a similar effect.

4 – except for the small matter of the little indicator against each participant’s name which shows who’s “talking”.

5 – “Your presents is requested.”  “But wait—there’s myrrh.” You get the idea.

6 – “Sorry, darling, I know your parents are here, but a really critical bug came in, and I’m the only one who can look at it in time…”

7 – mainly a problem for owners of cats or teenagers.

8 – try searching for “Where’s a pub near me that’s open now?”.

9 – don’t forget to lock it again, in case a child notices and purloins that gaming console.

10 – in the Southern Hemisphere, at least.  Sorry: see [5].