Installing software, and what you are trusting

Almost everything you've done in this course so far could be undone. You moved files, you typed commands, you read what came back, and if you got it wrong you could put it back.

Lesson 6 was the one exception, and it's worth remembering what it cost: a single > truncates a file before it writes, with no warning and no undo. That took back one file.

This lesson is about the act that can take back the whole machine. You have already performed it once, in lesson 4, when you installed a shell, and that lesson said at the time that the question of what you were trusting would come back.

What installing actually does

Start with the thing nobody says out loud.

When you run a program, it can do whatever you can do. It can read every file you can read. It can change every file you can change. It can send anything on that machine to anywhere on the internet, using the connection you drew in lesson 7, and none of the parties on that path will find anything unusual about it, because a program sending data is the ordinary case.

That is not a flaw. It's how a computer works, and it's why a word processor can open your documents without asking permission for each one.

There is one exception, and it's the reason app stores exist at all. Software from a store usually runs inside a boundary the system enforces, a sandbox, so it can only reach what you hand it rather than everything you can reach. That is the ordinary case on a phone and a common one for store software on a desktop. Everywhere else, and for everything else in this lesson, assume the plain case: a program you run has your access.

But notice what it means. The decision about whether a program should have all of that is made once, at the moment you install it, by you, on the basis of whatever you knew at the time. Nothing about clicking a button called "Install" communicates any of this, and there is no undo. Once it has run, it has had your access.

And there is a second level above that one, which the next section is about.

The four parties, and how each one fails

This is the part your list at the top was probably missing. Installing something is not trusting one party. It is trusting four, and they are genuinely separate people who fail in genuinely different ways.

One. Whoever wrote the code. They chose what it does. They may have written something hostile on purpose, which is rare, or something careless, which is not rare at all.

Two. Whoever built it into the thing you downloaded. Source code and a running program are different objects, and somebody turned the first into the second. That is often the same people who wrote it and sometimes not. A build machine that has been interfered with produces a program that does not match the code anybody reviewed.

Three. Whoever hosts it. The file sits on a server. Somebody runs that server, and if they are careless or compromised, the file you fetch is not the file that was put there.

Four. Whoever told you where to find it. This one is almost never on anybody's list, and it's the one no route can check for you. You didn't know the address. Something told you: a search result, a link in a forum, a colleague, an advertisement.

Four parties, four different failures. Set them against your three routes to installing something.

Three routes, and what each one checks

Two named examples of each, so the words are not abstract. App store: Apple's App Store, Google Play. Package manager: apt on a Debian or Ubuntu system, which installs from a distribution's own repository; pip, which installs from a language index rather than a distribution. Download from a website: anything you fetch with a browser and open yourself.

The second row is the one to read twice, because it is not one claim. On a Linux distribution a maintainer builds the software from source and the archive's key signs the result, so something really did check the build. On a language index like the one pip uses, nobody did. Whoever holds the account uploads whatever they like, and the index serves it. That distinction matters in three sections' time, because the lesson's own example of the second attack lives on exactly that kind of index.

The last column is the other one worth a look. A download from a website checks nothing at all unless you check it yourself, and what you have to check is the address bar, which is lesson 8's reading habit doing its second job.

Signatures, and the thing they do not say

Two words first, because this course has used neither.

A key here is a long secret number that only its holder has. A signature is a small block attached to a file that the holder's key produces, which anybody can check with a matching public half and nobody else could have made.

So a signed program comes with a cryptographic claim, and it's worth being exact about the wording, because the wording is the whole thing.

This build came from the holder of that key.

That is the whole of it. Read it again and notice everything it does not say. It does not say the program is safe. It does not say the key's holder is honest, or that they are who their name suggests, or that the program does what it claims. It says the same kind of thing the padlock in lesson 8 said: something about origin, nothing about worth.

The parallel is exact, and so is the failure. A padlock proves control of a domain. A signature proves control of a key. In both cases the attacker who wants one can have one, because both are available to anybody who asks properly.

The two attacks, and both are on names

The advertisement above the result

You search for a program. The first thing on the page is a paid advertisement. It carries the program's name, its logo, and a link that looks correct.

That placement was bought. Whatever checks the ad network ran before selling it, and they do run some, none of them was the check you needed, which is "did this advertiser write this software".

So the fourth party in your chain, the one that told you where to go, was replaced by whoever bought the space above the result you wanted. Most of the time that's harmless, because the advertiser is the real project. When it isn't, you arrive at a site that looks right, download something that installs cleanly, and get a working program, because a program that didn't work would be reported within the hour.

This course hasn't researched search-ad malvertising as a topic, so take the mechanism above and not any claim about how often it happens. The defence below doesn't depend on the frequency.

The defence costs nothing and it is the habit from lesson 8: read the address before you download, not after. Find the first single slash, read leftwards past the ending, and check that what you get is the project's actual domain. If you do not know the project's actual domain, that is the thing to find out first, and a search result is not where to find it.

The name one keystroke away

The second attack works on the other kind of name.

When you install from a package manager, you type a name. Somebody has registered a name one keystroke away from the popular one: pygaqme where you meant pygame is the standard illustration.¹ They didn't register that hopefully. They registered it because some share of people will mistype the real one, and they don't need to know the share.

And notice where this attack lives. It's a language index, the cell in the table where nobody checked the build, and both names are validly registered, so there is no check a name-based system could make that would tell them apart.

The dangerous version of it installs and works, often by carrying the real package along with whatever else it brings, so everything you expected to happen happens. Nothing fails. Nothing warns you.

This is the third time in this course that the same idea has come round, and it is worth naming. Lesson 3 taught that a name is not the thing it names, which is why statement.pdf.exe is a program. Lesson 8 taught that a domain is a name somebody registered, which is why a padlock proves nothing about a bank. This lesson says the same of a package name. A name is a claim made by whoever registered it first, and in all three cases the attack is to register a name that reads like a different one.

What an administrator password grants

Now the second level.

Some installations ask for your password. Most people read the prompt as "this is the normal way to install things" and type it, which is not unreasonable, because it is the normal way to install things.

Be exact about what it grants. Running a program gives it your access, which is what the first section was about. An administrator password gives it power over the system itself: the ability to change what happens before you log in, to change what every other user of the machine sees, and to install things that keep running whether you are there or not.

And now read the prompt again. It names a program. Sometimes it names a company. It does not tell you what will be done with the power it is asking for, because the operating system does not know either. It is asking whether you agree, and you have to answer from what you already knew.

So the decision is made before the prompt appears or it is not made at all. Three things you can check beforehand:

What is this program? Not the name on the prompt, the thing itself. Do you know what it is for?

Where did it come from? Which of the three routes, and if it was a download, did you read the address?

Does it plausibly need this? A program that manages disks or drivers or system settings has a reason to ask. A photo editor asking to change the system is a question, not necessarily an answer, but a question.

And in a terminal, the same thing has a name. You'll meet sudo the moment you follow any set of instructions on the internet, and it's this, exactly this: run the next thing with power over the system. The rule doesn't change because the prompt has become a word. Nobody should type it because a web page told them to, and the decision is the one above, made before the word appears.

And then the honest part, which the rest of this lesson has been building towards: you cannot check the fourth thing. You cannot verify what the program will do with the access once it has it. There is no procedure. Nobody has one.

That is not a counsel of despair, and it is the reason the next section exists.

What the people who do this for a living actually do

You met these two lists on the first page of lesson 1, so this is a recall and not a reveal. In 2015, Ion, Reeder and Consolvo asked 231 security experts and 294 non-experts what they did to stay safe online.² The experts' three most-reported practices were installing software updates, using two-factor authentication and using a password manager. The non-experts' were antivirus software, visiting only known websites, and changing passwords frequently. Nothing appeared on both lists.

Two things about it are new here, and they are why it comes back.

The first is a limitation worth having before you lean on it. Both columns are what people said they do. They are self-reports of habit, not measurements of what works, and a study of habits cannot tell you which habits are effective. So the thing to carry is the divergence itself, that two populations asked one question shared not one answer, and I'm using the ranking for that and nothing finer. The per-practice percentages are in the paper, the research behind this course read only the abstract, so they are not here.²

The second is why the list belongs in this lesson, rather than in lesson 10 with the other two items on it. Installing updates is the top expert answer, and it is the structural answer to the problem the last section couldn't solve. You can't verify what a program will do. You can make sure the holes a bad one would use are already closed. That works while you aren't paying attention, which is the only kind of defence that works at three in the afternoon on a busy day.

What people get wrong

"If it is in the app store it is safe." A store checks against a policy and hosts the file itself, which is real and is better than nothing. It does not audit what the code does. Look back at the table: the store's strongest column is the one about hosting, and the weakest is the same one as everywhere else.

"The first search result is the official site." The first result is often a paid advertisement, and the auction that decided it asked who would pay rather than who wrote the software.

"A signed installer is a safe installer." A signature says this build came from the holder of that key. It is a claim about origin, in the same family as the padlock in lesson 8, and origin is not safety.

"I will run it and see." There is no seeing. A hostile program that announced itself would be a failed one, and the whole design is that it works exactly as expected while doing something else.

"I am careful about what I click, so I do not need antivirus." This is the buggy software model from Wash's 2010 study, held by 9 of his 33 respondents: a virus is something you have to download and run, so if you are careful about what you click, you are covered.³ It is half right, which is exactly what makes it dangerous. Care does prevent a great deal. What it does not cover is a program you deliberately and correctly installed whose update was later compromised, or a hostile file opened by a program you trust. Neither of those involves clicking anything careless.

"Updates are how they force new features on you." This one is a real complaint and deserves a straight answer rather than a lecture. Sometimes it is true: an update arrives, the interface has been rearranged, and nobody asked. That is a genuine annoyance and pretending otherwise is why security advice gets ignored.

The answer is that most updates are not that. A security update closes a specific hole that somebody outside the company found and reported, and it is the top item on the expert list above for a reason. Where your system lets you separate security updates from feature updates, take the first automatically and the second when you feel like it. Where it does not, the trade is real and you are making it knowingly, which is better than making it by accident.

The contested one: do you need antivirus?

This is a genuine disagreement among people who know what they are talking about, so both sides are below at full strength, rather than a verdict dressed up as one.

For. Two independent testing laboratories, AV-TEST and AV-Comparatives, test these products in controlled conditions, and in those tests both the paid products and the protection built into a current operating system, Microsoft Defender on Windows, catch very nearly everything.⁴ Layered detection genuinely catches things that care doesn't, which is precisely the flaw in the buggy-software model above: a compromised update, and a hostile file opened by a program you trust, are both things a scanner can see and carefulness cannot. The floor is high, and on a current system it's free and already switched on.

Against, and this is the position consumer coverage almost never states. Google's Project Zero team, and Tavis Ormandy in particular, has argued that antivirus products themselves present a large and easily reached attack surface.⁴ The mechanism is worth having in plain words. To look inside a file, the product has to take the file apart, and taking hostile files apart is where security bugs live. That code runs with full power over the machine, and without the walls a browser is given for the same job. So the argument isn't that antivirus fails to detect malware. It's that a program with full power that pulls apart every untrusted file you receive is close to the last thing you'd choose to add.

The read level, on both sides, because it's the same one. The research behind this course read all of this at summary level: no AV-TEST or AV-Comparatives report was opened, and Ormandy's own writing was read only as quoted by others.⁴ So what you get here is the shape of the disagreement, which is stable, and no laboratory score, which would be out of date next quarter anyway.

Where that leaves a home user. Leave the protection built into your operating system switched on. It's doing real work, it costs nothing, and the For side above is the reason. What's much less clear is the value of adding a third product on top of it, and the interesting reason for hesitating is a security argument rather than a money-saving one, which is the opposite of how the question is usually put.

And whatever you decide: never turn a security feature off to get something to install. Not macOS's Gatekeeper, not Windows SmartScreen, not your antivirus. If a program can't be installed without switching off the thing that's there to check it, the thing to change is your mind about the program.

Practice

Connections

Lesson 3 taught that a name is not the thing it names. This lesson is the second half of that idea: statement.pdf.exe and pygaqme are the same trick in two different naming systems.

Lesson 4 installed one thing, the shell, and said at the time that the question of what you were trusting would come back. This is it.

Lesson 8 gave you the address-reading habit and the shape of a claim about origin. Both do a second job here, and the signature is the padlock's exact counterpart: a proof of control, offered as if it were a recommendation.

Lesson 5 promised this lesson by name. When python3 --version came back not found and the fix was to go and install something, it said you would come back here to ask what exactly you were trusting. Now you can answer it in four parts, and the answer for Python is a good one to work through, because python.org is a project whose real domain is easy to find and easy to confuse.

Lesson 1 supplied the folk models this lesson's antivirus misconception uses, and the two lists that come back in the middle of it.

Lesson 10 is passwords, and it is where the second and third items on that expert list get a lesson of their own. The list is the reason they are worth one.

Lesson 11 asks the same four-party question about a message instead of a program. Who wrote it, who sent it, who hosts what it points at, and who told you it was worth opening.

Go deeper

• Wash, "Folk Models of Home Computer Security" (2010), free. Table 3 is the one to find: twelve pieces of standard security advice against eight folk models, with each marked important, maybe or not necessary. It is the best single page in this field for understanding why sensible people decline good advice.
• Ion, Reeder and Consolvo, "'...No one Can Hack My Mind'" (2015), free from the symposium. The abstract page carries the two lists. Read the paper itself if you want the parts this lesson could not use.

Sources

1. Recorded in this course's research/SOURCES.md under the safety rule "name the thing you are trusting, every time software is installed": typosquatted package names such as pygaqme for pygame are the standard technique. Read at search-summary level. The widely quoted count of malicious packages found in 2025 comes from a report that was identified and not opened, so no count appears in this lesson, as the callout above says. The technique is what this lesson teaches and it does not rest on a figure.
2. Iulia Ion, Rob Reeder and Sunny Consolvo, "'...No one Can Hack My Mind': Comparing Expert and Non-Expert Security Practices", Symposium on Usable Privacy and Security, 2015. Read: the USENIX abstract page in full; the proceedings PDF was not opened. Supplies the 231 experts and 294 non-experts, and the three most-reported practices in each group in order, which is what the table above prints. Per-practice percentages are deliberately not used, because they are in the paper and the paper was not opened; the lesson says so in its own text rather than only here. The study won the 2023 SOUPS Impact Award. That both columns are self-reported habit rather than measured effect is the paper's own framing and is stated in the lesson.
3. Rick Wash, "Folk Models of Home Computer Security", Symposium on Usable Privacy and Security, 2010, pages 1 to 11. Read in full. Supplies the viruses are buggy software model and the count of 9 of 33 respondents holding it, along with its content: that viruses must be deliberately downloaded and executed, so that care about what you click makes antivirus unnecessary. Wash's 33 interviews averaged 45 minutes, were conducted in 2007 and 2008 in three midwestern American cities, and screened out anyone with computer training. Lesson 1 uses the same paper for the hacker models and the botnet argument.
4. The antivirus disagreement is recorded in this course's research/SOURCES.md as a contested empirical question. Read at search-summary level throughout: no AV-TEST or AV-Comparatives report was opened, and Tavis Ormandy's own writing was read only as quoted in secondary coverage. That is why this lesson prints the shape of the argument and no laboratory score, and says so in its own text. What the file records is that independent lab testing shows built-in and paid products both catching very nearly everything in controlled tests, and that the Project Zero argument is about attack surface: antivirus parses hostile input at high privilege without sandboxing, which increases exposure to targeted attacks.