A guide to the guides: reviewing training resources

If you teach digital security to other people, the teaching materials themselves need a review. An old guide, or one written for a completely different threat, can mislead as much as having no teaching at all. This page is about how to judge materials before you use them; it is not an advertisement for one particular collection.

Examples of practical topics in this same set — such as creating strong passwords, encrypting stored files, communication tool resources and the quick device list — should be reviewed with the same questions; stale menus and a shifted threat model can affect your own pages too.

What to look for in a teaching resource

• Date: Does it talk about current versions of operating systems and apps, or about settings that changed years ago?
• Threat model: Was it written for a journalist under threat or for an ordinary family? The same script does not work for everyone.
• Author and maintenance: Who wrote it, is it still updated, and is there a way to report mistakes?
• Testing: Walk through the steps yourself on a device like the ones your audience uses.
• Language and context: Does it recommend tools people can actually install? A translation that only keeps Western app names may be useless to the reader.
• Licence: If you want to translate or adapt the materials, check whether you are allowed to. Some teaching resources are published under open licences such as Creative Commons licences, which say clearly how you may change and share them; others do not give that permission.

Materials that advertise a single product, or that use excess fear to sell a service, are usually weak for group teaching. Prefer a source that also states a tool’s limits, not only its strengths.

Take the date more seriously than a polished title

App interfaces change every year. A path that was right in 2018 may now send the reader to a removed menu and weaken trust in the rest of the lesson as well.

1. Find the publication date and the date of the last review. If the page only has a copyright line at the bottom, do not treat that as a content review.
2. Check menu names on a device like the participants’ devices.
3. If the resource talks about a version that is no longer supported — for example an operating system whose patch cycle has ended — set that section aside or rewrite it.
4. Do not treat a screenshot as permanent evidence; an old image can look fine and still be wrong.

Do not read the threat model off the cover

Teaching written for someone whose device might be inspected is not the same as teaching written for a family facing everyday phishing. Mixing the two without saying so either scares everyone or underestimates someone who faces a higher risk.

1. Ask what device, what network and what legal or social consequence your audience actually lives with.
2. If the source assumes everyone can install an app from a particular store, check whether that is true for your class.
3. Remove exercises that pull the audience into unnecessary high-risk work.
4. Tell participants which parts are for “everyone” and which are only for a particular situation.

Read the licence before you translate or adapt

If you only link to a resource, the question is usually simpler. If you want to translate the text, shorten it, replace screenshots or mix in local examples, you have to see what permission the rights holder gave. The page on Creative Commons licence types explains a common framework for open licences; it does not replace reading the licence on that specific file.

1. Find the licence on the work itself, not only on the publisher’s general website.
2. If the licence is from the Creative Commons family, see which one it is: CC BY usually allows sharing and adaptation with credit; CC BY-SA adds a share-alike condition; CC BY-NC limits commercial use; CC BY-ND does not allow adaptations. Combinations of these conditions also exist.
3. Give credit the way the licence asks: title, author, source and the licence itself.
4. If you changed something, say what you adapted so a reader does not confuse your version with the original.
5. If there is no licence, or the work is “all rights reserved,” do not translate or republish it at length without permission; you can still link to the original.

The word “open” on a cover does not mean every change is allowed. Do not treat CC BY-ND as if it were CC BY.

Run the materials yourself once

Silent reading is not enough. A lesson that flows on paper may stop on a participant’s phone.

1. Walk the steps on the same device family the audience uses: Android with Android, iPhone with iPhone.
2. Time the real run so the session is not packed too tightly.
3. Say in advance where a real account, a phone number or a payment will be required.
4. If a step fails, fix it in the text before class rather than with a rushed spoken note.

Public-sector extras such as CISA’s training section may have been written for a different context. Judge them by date and threat model as well, not by the institution’s name.

Do not turn the class into a shop window for one product

A source that calls one app “the only safe way,” or that sells a service through extreme fear, is weak for a group. It is better to name more than one path and the limits of each so a participant can adapt the advice to their own life.

1. Do not hand out a mandatory install list; give an order of priority.
2. Do not recommend a tool whose upkeep you do not understand.
3. Do not promise complete immunity.
4. If you include a comparison, write down the criteria.

Keep the source alive after class as well

A handout that is printed once and never looked at again quickly turns into anti-teaching. A short review appointment is better than a full rewrite every year.

1. After each large change in the operating system or the main app of the class, walk again through the three paths you teach most.
2. Ask participants to tell you if a menu has changed; that is part of maintenance.
3. Remove the stale version from the shared folder, or mark it so it is no longer taught.
4. If you correct a place and the licence allows it, apply the same change in the version other people take from you.

Review frightening statistics and quotations separately

Some handouts start with a large number about being “hacked.” If the source quotes a figure, see where it came from and which year it belongs to. A number without a source, used to frighten a group, is not suitable teaching.

1. Include statistic-like claims only when you can show where they came from.
2. Do not tell the story of a famous attack without its time context; tools and patches have changed since then.
3. If an example is there to show a tool’s limit, state the limit rather than calling the tool useless outright.

The order of a short review

You do not need a long research paper for every file. A regular thirty- to forty-minute pass before class catches most of the dangerous errors.

1. Write the date and the licence at the top of your own note sheet.
2. Summarise in one sentence the threat model the author assumed, and compare it with your audience.
3. Run the three main practical paths on a sample device.
4. Mark tools the group cannot install, so they can be replaced or removed.
5. If you are translating, decide there what you will adapt, and write that in the source note.

Keep what you republish separate from the original

Your own notes, local examples and any path you changed in class should be distinguishable from the original text. That respects the author and also stops participants getting confused.

1. If a Creative Commons licence allows changes, still say which changes your version contains.
2. Take a fresh screenshot with a date so nobody treats it as years old.
3. Put a link to the original near the title so someone who wants the first source can reach it easily.

Common mistakes

• Teaching from a years-old guide without checking the menus.
• A word-for-word translation of an app list the audience cannot install.
• Ignoring the licence and then publishing an adapted version.
• Frightening the group in order to sell a service.
• Assuming one threat scenario is enough for everyone.

What to do today

1. Review one resource you currently teach against its date and threat model.
2. Run the practical steps once on a device like your participants’ devices.
3. If you want to translate or shorten it, read the licence and, if it is Creative Commons, note the exact type — including CC BY.
4. Tell participants to adapt the advice to their own situation rather than installing an entire list.
5. Write your own review date on the version you hand out.
6. Remove the stale version from the shared folder so it is not taught again.

The aim of this page is not to promote one particular collection. It is that before you stand in front of a group, you have seen the source’s date, threat, licence and practical paths yourself, and that if Creative Commons — including CC BY — or another open licence is involved, you have understood the exact limit on changes and on credit.