This unit has a characteristic that makes it easier than the others in the series: the browser shows you the signals. You do not have to look for them — they are in the address bar, every time.
The problem is that they have become so familiar they are no longer read. This post brings them back into focus: what they say, which are serious, and which have ordinary explanations.
It expands on the recommendation browsing only over HTTPS.
The signals in the address bar
It is the first place to look, and in most cases the only one needed.
| What you see | What it means | Severity |
|---|---|---|
| A padlock or no indication at all | An encrypted connection: it is the norm | None |
| “Not secure” beside the address | A connection in the clear | High if you type data |
| A crossed-out padlock or a triangle | Partial encryption or a certificate problem | High |
http:// at the start | A connection in the clear, explicitly | High |
| A full-screen warning page | The browser blocked the connection | Stop |
The modern inversion is important to grasp: browsers no longer celebrate an encrypted connection — they flag the one that is not. The absence of any indication is the good case; it is the appearance of text or a symbol that has to catch your attention.
The signals in the page’s content
Some clues are not in the bar but in the page itself, and they concern step 1 of the check — the site’s identity — more than step 2.
A sign-in form appearing where it should not. A request for credentials on a page where you were doing something else, or a login box overlaid on the content.
Inconsistent graphic elements. Low-resolution logos, different typefaces from the usual ones, text with language errors. Weak clues on their own, but they add up.
A request to install something. A legitimate site rarely asks you to install a program to continue browsing.
Content that does not belong. Advertising unrelated to the site, simulated system warnings, windows imitating the operating system.
A redirect you did not ask for. You went to one site and find yourself on another.
The last two are the most significant over a connection in the clear, because they are exactly what modification in transit produces.
The signals about the network
These concern the context, not the individual site.
A sign-in page asking for more than it needs. A public network’s portal asking for the credentials of an existing service — email, a social network — instead of simple consent.
Certificate warnings on different sites on the same network. If they appear on several sites at once, the problem is not the sites: it is the network.
Traffic passing through an intermediate page. A screen appearing before every site you visit.
An open network with an almost-right name. It is not a signal of an unencrypted connection strictly speaking, but it belongs to the same context and it is covered in the unit on public networks.
What is NOT a signal
This section exists to avoid alarms that lead to ignoring the real ones.
| What | Why it is not a signal |
|---|---|
| The absence of a green padlock | Browsers no longer use one: green was removed years ago |
A site without www | It is just the operator’s choice |
| A long, complicated address | Many legitimate pages have one |
| A “free” certificate | They are as valid as paid ones |
| A site with an unusual domain ending | Uncommon extensions are no indication of fraud |
| A warning on a home device | Routers and printers almost always use unverifiable certificates |
The last row causes the most confusion: a router’s configuration page will always show a warning, because its certificate cannot be issued by a public authority. That is not a problem: it is a characteristic of those devices.
The signal worth more than all the others
There is one clue that outweighs the rest, and it is not technical: how you arrived on that page.
| How you got there | Level of attention |
|---|---|
| From bookmarks or by typing the address | Low |
| From a search | Medium: check the domain |
| From a link in an email or a message | High |
| From an automatic redirect | High |
| From a QR code | High: you cannot read it beforehand |
The last three rows have one thing in common: you did not choose the destination. That is where nearly all the problematic cases concentrate, and no padlock helps you there.
Why people stop seeing these signals
There is a psychological reason why this unit is necessary, and it is worth naming because it concerns everybody.
Browser warnings are frequent and almost always harmless. An expired certificate on an institutional site, a warning on the home printer, a hotel’s sign-in page: in the vast majority of cases there is no danger at all, and proceeding has no consequences.
The result is predictable: the brain learns that the warning means nothing. After twenty harmless warnings, the twenty-first gets closed unread. It is the same mechanism that makes alarms sounding too often ineffective, and it is documented in every context where automatic warnings are used.
Two practical countermeasures, both light.
Reduce the harmless warnings. Home device configuration pages and public network portals generate nearly all the false alarms. If you know in advance that those will produce a warning, the others become noticeable again.
Learn to tell one case apart. You do not need to classify every warning: recognising “name mismatch” is enough. It is the one that almost always indicates a real problem, and telling it from the others is sufficient to cover the cases that count.
How to react, by severity
If you see “Not secure” and you are only reading: you can carry on. A connection in the clear exposes what you exchange, and if you exchange nothing sensitive the risk is contained.
If you see “Not secure” and you are about to type something: stop. Look for the same service at the encrypted address, or postpone it to when you are on a network you control.
If a certificate warning appears: read which one. “Name mismatch” is the most serious and should be treated as a definitive no. “Expired” is nearly always the operator’s carelessness, but it is still not the moment to enter data.
If the page behaves oddly: close it and reach the site by typing the address. It is the reaction that resolves most cases, and it is quicker than any analysis.
If you have already entered data: change that service’s password and close the active sessions. Those are the two actions that close what is still open.
The signals afterwards, if something got through
The clues listed so far show up during browsing. There are others appearing afterwards, and it is worth being able to link them to the cause — because when they arrive, nobody thinks of an unencrypted connection from weeks earlier.
An unrecognised sign-in to a service. If you used that service from a public network on an unencrypted page, the link is there. It is the most direct signal.
An active session you do not recognise in the list of connected devices. It is the typical effect of a captured cookie: there was no sign-in with a password, but there is a session.
A program behaving unexpectedly after a download over an unencrypted connection. Windows appearing, changed settings, a browser opening pages you did not ask for.
A page still behaving oddly even after changing network. In that case the problem is no longer in transit: it is on the device.
The link between cause and effect here is almost always invisible, and it is why the correct reaction is not to investigate backwards but to act on what is still open: revoke the sessions and change that service’s credential.
The signal nobody looks at: what the padlock says if you open it
The padlock is not just an icon: it is a button. Clicking it opens a panel almost nobody consults, containing useful information.
What you find there, with names varying between browsers:
| Entry | What it says |
|---|---|
| Secure connection | Confirmation that encryption is active |
| Valid certificate | It opens the details: domain, issuer, expiry |
| Site permissions | What you authorised: camera, location, notifications |
| Cookies and site data | What the site stored on your device |
The most useful field is the domain written in the certificate: it is the independent confirmation of what you read in the address bar, and in case of doubt it is the place to look.
The third row is a side benefit worth the click: it is where you discover you granted a site access to your location or microphone months earlier, perhaps for a single occasion. Revoking those permissions from this panel takes two seconds.
You do not need to do it on every site. You need to know it exists, and to use it in the two cases that count: when an address does not convince you, and when you notice a site knows something about you it should not.
How this connects to the Cyber Welfare Framework
| Pillar | What this content contributes |
|---|---|
| Awareness | Knowing that the absence of a warning is the normal case |
| Skills | Telling serious warnings from the ones with ordinary explanations |
| Secure Behaviour | Raising your attention when you did not choose the destination |
Reference level: FL2 — Beginner.
Summary
- The browser no longer celebrates an encrypted connection: it flags the one that is not.
- The most serious warning is “name mismatch”; “expired” is nearly always carelessness.
- Warnings on home devices are normal and indicate no problem.
- The strongest signal is not technical: it is how you arrived on that page.
One thing to do today. Look at the address bar of the site you have open right now. If there is no danger indication, you now know that is the good case — and that is already half the work.
Related content
- Browsing only over HTTPS — the recommendation this expands on
- How to check a website is safe — the full three-step procedure
- How HTTPS works — why certain warnings appear
- Impact of an unencrypted connection — what is at stake when the signal is there
Related resources
Short reads from the Resources section, for anyone who wants to stop on a single aspect:
Start with the first step: the Cyber Welfare Programme guides you free of charge, one recommendation at a time.
