Computer basics

Installing software safely

The safest thing you can do when installing software is to get the file from the maker own site, and after installing, keep the program updated. The rest of the advice is sound too, but none of it prevents as much as those two.

  • Lesson 8 of 12
  • Beginner
  • Free, no signup

The four layers that make an install safe

  • The official source

    The maker own site or the official store of your system. The most important layer, because the rest depend on it.

  • The fingerprint check

    The string you calculate yourself against the string the maker published.

  • A limited account

    Do not do daily work in an administrator account; what cannot write cannot break.

  • Updates

    The only layer that keeps working after the install, which is why it does the most.

None of these four layers is enough on its own, and no combination of them is a hundred percent. The goal is to lower the odds, not to zero them.

Last checked: Facts and tool names in this lesson are re-checked against their sources on this date.

Why where you download from matters more than what you download

A program downloaded from two different places is not necessarily the same file. The name is the same, the icon is the same, it may even show you exactly the same screens while installing. But the bytes inside it can differ, and from the outside you have no way of seeing that.

That sentence is the whole lesson. Everything else we say is a way of becoming sure about that one thing.

The maker of a program has no incentive to tamper with their own file. A site that republishes the file may or may not, and you cannot tell which. So the first rule is simple and has no exceptions: get every program from the site of whoever makes it, and if the maker has an official store, like your operating system store or an official Linux repository, take it from there.

The rule is simple and carrying it out is exactly where things go wrong. Whoever says take it from the maker own site has assumed you know which site that is. Two traps sit on that one step. First, the ad rows at the top of a search page: anyone can buy an ad on a program name, and that top row is not necessarily the maker site. Second, lookalike domains; one letter moved, or the same name under a different suffix. The eye reads the name and does not read the address, and this trap is built on exactly that.

The practical answer is two lines. Take the address from somewhere the program itself gave you, the About menu of a copy you already have or the program Wikipedia page for instance, rather than from a search result. And once you have reached the right site, bookmark it, so that next time there is no search at all.

For WordPress the same rule wears different clothes: install a plugin from the WordPress repository itself or from the site of the company that wrote it. A zip file that has been passed around in a group chat is exactly what this lesson is warning about.

A box with a green checksum seal beside a red fake with a broken seal, a blue official door behind

What a checksum is, in plain words

A checksum is a short string calculated from every single byte of a file. Think of it as the file fingerprint. Every file has its own string, and if one byte of the file changes, the string changes completely.

Completely, not slightly. A real example you can reproduce right now: the sha256 fingerprint of the word hello in lower case starts with 2cf24dba, and the same word with a capital first letter, Hello, starts with 185f8db3. One letter changed and the string bears no resemblance to the previous one. That is what makes comparing two fingerprints easy: either they match character for character or they do not, and there is no middle state.

Serious makers publish the fingerprints of their files next to the download link. You take the file, calculate its fingerprint on your own machine, and compare it with what the maker wrote. If they match, the file in your hands is the file the maker published. If they do not, delete it and download again.

Calculating it needs no special software either. On Windows certutil -hashfile setup.exe SHA256 does it, and on Mac and Linux shasum -a 256 setup.exe.

The order an install should go in

  1. Take it from the maker own site

    Not from an ad in the search results, not from a link inside an email.

    1

  2. Compare the fingerprint

    One command on your own machine, against the string the maker wrote.

    2

  3. Untick the extras while installing

    A toolbar, a second antivirus, a changed search engine. None of them is needed.

    3

  4. Leave automatic updates on

    The only step that keeps working for you after today.

    4

Step two is only possible when the maker published a fingerprint. Many do not, and then step one is all you have.

The reality of Iranian download portals

Let us be honest, because being polite here helps nobody. A large share of the software installed in Iran does not come from the maker site. The reason is understandable: many maker sites do not open from Iran, and official payment is not possible either. That is not a choice, it is a constraint.

But a constraint does not remove the risk; it only explains it. When the file does not come from the maker site, three things are lost at once. The fingerprint the maker published no longer matches your file, so the comparison tool becomes useless. The installer has usually been repackaged to get around the licence, which means somebody has been inside the file, and you do not know whether they only touched the licence or added something else too. And automatic updates usually get switched off, because an update brings the licence back; the same updates that the last section shows are the most important part of security.

Our position, said plainly: for a game or a small program that knows nothing about you, weigh the risk yourself. But for any program your passwords, your bank account or your customers data pass through, a repackaged installer is not an acceptable risk. There, if you cannot buy the official version, go and find a different program.

Free and open source alternatives, and why they are usually the safer pick

A simple piece of logic works here that people rarely spell out. A program whose official version is free has no market for a tampered copy. Nobody bothers repackaging something everyone can take from the original site for nothing. So the first rule of this lesson gets followed without any effort at all.

A few real examples that do their job: LibreOffice for documents and spreadsheets, VLC for playing video, 7-Zip for compression, and Firefox for browsing. All four are downloaded from their own sites and all four publish a fingerprint or a signature.

Now the part an advertisement never tells you: open source does not by itself mean safe. It means the code can be looked at, and that is worth something only when somebody actually looks. A large project with thousands of users and active developers has that attention; an unknown add-on whose last update was three years ago does not, and its code being open makes up for nothing.

Before you click download

Download check sheetthirty seconds

Good signs

  • The domain is the maker own domain, not something that resembles it.
  • A fingerprint or signature is published next to the download link.
  • There are release notes and the version dates run regularly.

Warning signs

  • Several download buttons on the page and no telling which is the real one.
  • The file sits in a password protected archive with the password written beside it.
  • The page tells you to switch off your antivirus before installing.
  • The file size does not match what the maker states.

These signs move the odds, no more than that. A site can carry every good sign and still hand you a tampered file.

The single most valuable habit: keeping things updated

If you are only going to do one thing from this lesson, this is it. Leave automatic updates on and do not push update prompts two weeks down the road.

The reason is that most real attacks are not freshly discovered holes; they are holes that were patched months ago and nobody installed the patch. The attacker is not looking to discover something new, they are looking for someone who has not updated yet.

An example from our own experience, written up on this site blog. WordPress 7.0.4 was a single issue security release and changed exactly one file. The hole it closed was remote code execution, but only on servers that had a particular combination of two supporting programs. Our own server had exactly that combination. For a site administrator the whole event was one update click, and for anyone who did not make that click, an open door.

Alongside it, a smaller habit that gets said too rarely: delete the software you do not use. Every installed program, even one you never open, is another surface to attack and another thing that has to stay updated. Reducing how many programs you have is itself a security measure.

The fast path, with AI

Comparing two sixty four character strings by eye is the kind of job a human gets wrong without noticing. The fast path is not a language model deciding for you; it is giving the comparison to the computer and using the model only to understand what came out. A fast, cheap model of the Flash class is enough here, and our current pick is listed in this site AI section. The trick that rarely gets said: many programs never need a manual check, because their own packaging system does it on every install.

  1. Calculate the fingerprint of the downloaded file on your own machine and copy the maker string from their download page.
  2. Give the comparison to the computer, not to your eye. One command answers yes or no and does not slip.
  3. If the program installs through a packaging system, reach for its own verify command. For WordPress that is wp core verify-checksums, and it checks the whole install in one go.
  4. Hand the output to the model and ask what each row means. Verify commands sometimes print dozens of rows and most of them are harmless.

Copy-ready recipe

Comparison without the eye:

  Windows:  certutil -hashfile setup.exe SHA256
  Mac and Linux:  echo "<maker string>  setup.exe" | shasum -a 256 -c
  WordPress:  wp core verify-checksums  and  wp plugin verify-checksums --all

The prompt, with the verify output attached:

  This is the output of a checksum verify command. For each row tell me:
  1) Does this row mean a file changed, a file was added, or only that no
     checksum was available?
  2) Which of them are normally harmless because the program writes them
     while running (logs, cache, config files), and which need looking at?
  3) If no row is worrying, say so plainly.
  Do not guess, and flag any row you do not recognise as unclear.

Before you trust the output: One point turns this recipe from a ritual into a real check: the maker string has to come from somewhere the file did not. If the same site that gave you the file also writes its fingerprint, the comparison only proves the download completed cleanly and nothing broke on the way; it does not prove the file itself is honest. Anyone who can change the file can usually change the string beside it too. And the model answer is never the last word: it reads the command output, it does not see your computer and it opens no file.

AI in this kind of work

On this topic a language model does one job well and one job it should not do at all. The good job is translating technical output: checksum verify commands and installer error messages print dozens of rows, most of them harmless, and a model sorts them far faster than you can. The bad job is described below and it is a serious one.

Tools that actually help

  • Gemini For reading verify output and sorting the rows, on its fast cheap model. Google own page says the Gemini web app runs in over 230 countries and territories, and Iran is not on that list.
  • Claude For when you want to understand why a row matters rather than only that it does, because it writes out its reasoning and reasoning can be argued with. Iran is on neither of Anthropic two supported-countries lists and there is no official payment route from Iran.
  • WP-CLI Not an AI tool, and deliberately here: the actual checksum verification is this tool job and no model can stand in for it. The model explains the output, the tool produces it.
  • RGB The access and payment layer for Iran, kept separate from the tools themselves.

Where it backfires

The job never to hand a model on this topic: asking whether some site or some file is safe. It will answer, the answer will look confident, and there is nothing behind it; the model neither opened that site nor saw that file. Worse, domain names repeat heavily in training data and a model can mistake a lookalike domain for the real one, which is exactly what this lesson warns about. The place for that question is the maker own official page. The second risk is familiar and is the same rule as the other lessons: verify output can go to a general purpose tool, but a config file, a server log, or anything with a password or key inside it cannot; whether content feeds model training depends on the plan and settings of that service, and the companies write it down, including on Google privacy page for the Gemini apps.

Sources: Google: Gemini Apps privacy Where you can use the Gemini web app Anthropic supported countries

Where this advice stops

A checksum does not prove two things, and both matter. First, it does not prove the program is harmless; it only says the file is what the maker published. If the maker themselves publishes malware, the fingerprint still matches. Second, if the comparison string comes from the same site that served the file, it shows the transfer was clean, not that the origin was. Beyond that, most Windows software publishes no checksum at all, and in that case this tool is simply not available to you; there only the official source rule remains. And this lesson is about installing software on a personal computer, not about hardening a server, which is a separate job.

From our own work

Both commands recommended in this lesson were run on this very site on 2026-09-06, and their results are quoted from those runs. The first, the WordPress core check, answered that the installation matches the published checksums. The second was more interesting and showed exactly what the limits section says: out of twenty five plugins, only five were genuinely verified. Nineteen could not be checked at all, because they are our own plugins plus two commercial ones and no checksums are published for them on the public repository; the tool neither confirms nor denies anything about them. And one failed with six rows of difference, which on inspection were all of the file added kind and all inside that plugin own storage folder: two error log files and a few folder protection files. Things the plugin writes while running, not signs of tampering. That single output is the most precise thing that can be said about checksums: it tells you what differs, and deciding whether the difference means anything is still a human job.

Real follow-up questions

Is an antivirus not enough?

It helps but it is not enough, because it works by recognising things that are already known and fresh malware is not known yet. On top of that, repackaged installers usually trigger warnings and the user learns to dismiss warnings, which creates a new risk of its own. An antivirus is the last layer, not the first.

The maker publishes no fingerprint; what should I do?

Hold the first rule harder: download only from the maker own domain and read the address carefully, because lookalike domains are built for exactly this moment. If your operating system has an official store, install from there; those stores do this check themselves and you have nothing to do.

Is a WordPress plugin I got from a group chat dangerous?

From the outside there is no answering that, and that is the answer. A WordPress plugin runs with full access to the site and the database, so if something is in it, nothing stands in its way. If it is installed on a site that matters to you, run wp plugin verify-checksums, and if the plugin is not on the public repository and you have no way to check it, the safest move is to remove and replace it.

Keep learning