100th video up

Just six months ago, I started a YouTube channel, What is cybersecurity?, to provide short videos (most are under 4 minutes and all are currently well under 10 minutes) discussing topics and issues in cybersecurity. I’ve spent 25+ years in the field (well before anyone called it “cybersecurity”) and had been wondering how people get into it these days. In particular, I’m aware that not everyone processes information in the same way, and that for many people, short video content is there preferred way of gaining new knowledge. So I decided that this was what I’d do: create short videos, publish frequently and see how it went.

Today, the 100th video was published: What is data privacy?

To celebrate this, here’s a post describing various aspects of the process.

Methodology

I thought it might be interesting to people to understand how I’ve gone about choosing the topics for videos. When I decided to do this, I created a long list of topics (the initial list was over 150) and realised very early on that I was going to have to start with simple issues and build up to more complicated ones if I wanted to be able to address sophisticated concepts. This meant that I’ve started off with some of the basic building blocks in computing which aren’t specifically security-related, just because I wanted to be able to provide basic starting points for people coming to the field.

I was slightly concerned when I started that I’d run out of ideas for topics: this hasn’t been a problem, and I don’t expect it to be any time in the future. Currently, with 100 videos published, I have over 250 topics that I want to cover (which I haven’t recorded yet). Whenever I come across a topic or concept, I add it to the list. There are few books that I mine for ideas, of which the most notable are:

  • Trust in Computer Systems and the Cloud – Mike Bursell (my book!)
  • Security Enginineering (3rd edition) – Ross Anderson
  • CISSP Exam Guide (9th edition) – Fernando Maymi, Shon Harris

As mentioned above, the videos are all short, and, so far, they’re all single-takes, in that each is a single recording, without editing pieces together. That doesn’t mean that I don’t have to re-record quite frequently – I’d say, on average, that 50% of videos require two or more takes to get right.

Audience

Who do I expect to be my audience? These are the personae that I’ve targeted to start with:

  • undergraduates reading Computer Science or similar, with an interest in cybersecurity
  • masters students looking to move into cybersecurity
  • computing professionals wanting more information on specific cybersecurity topics
  • managers or professionals in non-computing roles looking for a definition or explanation of a particular term
  • (after looking at UK students) A level students in Computer Science

Playlists

YouTube encourages you to create playlists to help people find related topics on your channel. These are the playlists that I currently have (I expect to create more as I get into more complex topics):

Cybersecurity concepts compared takes two or more topics and draws out the differences (and similarities). There are so many complex topics in cybersecurity which are really close to each other and it’s not always easy to differentiate them.

Equipment and software

Here’s the equipment and software I’m using.

Equipment

System: AMD Ryzen 9 3900X 12-Core Processor, 32GB RAM

Camera: Razer Kiyo Pro (though currently I’m trying out a Sony ZV-E10, which provides lovely video, but requires a 175ms audio delay due to USB streaming processing performance)

Microphone: audio-technica AT2035

Pre-amp: Art Tube MP-Studio V3

Software

Operating system: Fedora 39 Workstation

Studio: OBS Studio

Transcription: Buzz

Audio stripping: ffmpeg and some very light bash scripting

Thumbnails: Canva

More Rusty thoughts

I do feel that I’m now actually programming in Rust. And I like it.

I wrote an article a couple of weeks ago – 5 Rust reflections (from Java) – about learning Rust, and specifically, about moving to Rust from Java. I talked about five particular points:

  1. Rust feels familiar
  2. References make sense
  3. Ownership will make sense
  4. Cargo is helpful
  5. The compiler is amazing

I absolutely stand by all of these, but I’ve got a little more to say, because I now feel like a Rustacean[1], in that:

  • I don’t feel like programming in anything else ever again;
  • I’ve moved away from simple incantations.

What do I mean by these two statemetents? Well, the first is pretty simple: Rust feels like the place to be. It’s well-structured, it’s expressive, it helps you do the right thing[2], it’s got great documentation and tools, and there’s a fantastic community. And, of course, it’s all open source, which is something that I care about deeply.

And the second thing? Well, I decided that in order to learn Rust properly, I should take an existing project that I had originally written in Java and reimplement it in hopefully fairly idiomatic Rust. Sometime in the middle of last week, I started fixing mistakes – and making mistakes – around implementation, rather than around syntax. And I wasn’t just copying text from tutorials or making minor, seemingly random changes to my code based on the compiler output. In other words, I was getting things to compile, understanding why they compiled, and then just making programming mistakes[3].

This is a big step forward. When you start learning a language, it’s easy just to copy and paste text that you’ve seen elsewhere, or fiddle with unfamiliar constructs until they – sort of – work. Using code – or producing code -that you don’t really understand, but seems to work, is sometimes referred to as “using incantations” (from the idea that most magicians in fiction, film and gaming reciti collections of magic words which “just work” without really understanding what they’re doing or what the combination of words actually means). Some languages[4] are particularly prone to this sort of approach, but many – most? – people learning a new language will be prone to doing this when they start out, just because they want things to work.

And last night, I was up till 1am implementing a new feature – accepting command-line input – which I really couldn’t get my head round. I’d spent quite a lot of time on it (including looking for, and failing to find, some appropriate incantations), and then asked for some help on a rust-lang channel inhabited by some people I know. A number of people had made some suggestions about what had been going wrong, and one person in particular was enormously helpful in picking apart some of the suggestions so that I understood them better. He explained quite a lot, but finished with “I don’t know the return type of the hash function you’re calling – I think this is a good spot for you to figure this piece out on your own.”

This was just what I needed – and any learner of anything, including programming languages, needs. So when I had to go downstairs at midnight to let the dog out, I decided to stay down and see if I could work things out for myself. And I did. I took the suggestions that people had made, understood out what they were doing, tried to divine what they should be doing, worked out how they should be doing it, and then found the right way of making it happen.

I’ve still got lots to learn, and I’ll make lots of mistakes still, but I now feel that I’m in a place to find my way through those mistakes (with a little help along the way, probably – thanks to everyone who’s already pointed me in the right direction). But I do feel that I’m now actually programming in Rust. And I like it.


1 – this is what Rust programmers call themselves.

2 – it’s almost impossible to stop people doing the wrong thing entirely, but encouraging people do to the right thing is great. In fact, Rust goes further, and actually makes it difficult to do the wrong thing in many situations. You really have to try quite hard to do bad things in Rust.

3 – I found a particularly egregious off-by-one error in my code, for instance, which had nothing to do with Rust, and everything to do with my not paying enough attention to the program flow.

4 – *cough* Perl *cough*