There is a substantial difference between sending a postcard and sending a letter in a sealed envelope. In the first case anybody handling the post can read what it says; in the second they cannot.
The web works the same way, and the letter separating the two cases is a single one: the s in https.
This recommendation has a peculiarity compared with the earlier ones: most of the work has already been done for you. Almost every site today uses an encrypted connection by default. What is left to do is to recognise the exceptions — and to know what encryption protects and what it does not, because a great many mistaken ideas circulate on that.
What this recommendation says
Recommendation R9 establishes that personal data or credentials should only be entered over encrypted connections, recognisable by an address starting with https://.
In practice it means three things:
- checking the address before typing anything sensitive;
- turning on, where available, the browser mode that requires encrypted connections;
- not ignoring the browser’s certificate warnings.
What it is not. It is not a guarantee that the site is trustworthy. It is a very widespread mistake, and it is worth being explicit: an encrypted connection says nobody can read what you exchange with that site. It does not say that site is honest. A fraudulent site can use a perfectly valid encrypted connection, and it almost always does.
Scope. Every time you type something you do not want to share: credentials, personal data, payment information, messages.
Why it matters
Without encryption, everything you exchange with a site travels in the clear: the pages you visit, the forms you fill in, the credentials you type. Anybody along the route — whoever runs the network you are connected to, whoever has access to the transit infrastructure — can read it.
| Benefit | Why it counts |
|---|---|
| It protects credentials in transit | A password typed in the clear is readable by anybody watching |
| It protects the content exchanged | Forms, messages, data entered |
| It prevents the content being altered | Nobody can change the page along the route |
| It verifies the server’s identity | The certificate confirms the site belongs to the domain shown |
| It makes untrusted networks usable | It is what makes a public connection acceptable |
The fourth row is the least known and as important as the first: the certificate guarantees you are really talking to the site whose name appears in the address, and not to somebody who has placed themselves in between.
The last row connects this recommendation to those on public networks: the reason a public network can be used with reasonable calm today is precisely that the traffic is encrypted site by site.
A concrete example
John is in a cafe and connects to the free network. He opens his mobile provider’s site to check his balance and enters his credentials.
The address starts with https. The traffic between his phone and the site is unreadable to anybody else on that network, including whoever runs it.
If the same site were on http, the password would have passed in the clear across a network John does not control and whose operator he does not know.
The interesting point: John did nothing special. He simply avoided going ahead when the browser would have flagged it. That is the level of attention this recommendation asks for — low, but not zero.
When to apply it
- Always when you enter credentials. It is the main case and it has no exceptions.
- On networks you do not control: cafes, hotels, airports, other people’s offices.
- Before a payment, together with checking the domain name.
- When the browser shows a warning. The warning is the moment this recommendation becomes operational.
- When you follow a link you received by message or email: that is where substituted addresses appear.
- On old or poorly maintained sites, where an unencrypted connection is still possible.
- On connected home devices — cameras, printers, routers — whose configuration pages are often in the clear.
How to apply it
- Look at the start of the address before typing anything sensitive. There must be
https://. Many browsers hide it: clicking the address bar shows it in full. - Turn on the browser’s “HTTPS-only” mode. It is a setting present in every major browser, usually in the privacy and security section: it prevents connections in the clear and asks for confirmation before going ahead.
- Do not ignore certificate warnings. When the browser says the connection is not private, it is flagging something concrete: an expired certificate, one that does not match the domain, or one issued by an entity it does not recognise.
- Read the domain name, not just the padlock. The padlock says the connection is encrypted; the domain says with whom. The second matters more than the first.
- If a site does not offer HTTPS, enter nothing. Reading is fine; typing is not.
- Check the administration pages of your home devices, which often use unencrypted connections: they should be used only from the local network.
- Update your browser. Certificate verification depends on a list of authorities that gets updated with the program.
Common mistakes to avoid
- Believing the padlock means “trustworthy site”. It means “encrypted connection”, which is a different thing.
- Ignoring a certificate warning because “it is only some site”. The warning does not distinguish: it says something or somebody does not add up.
- Looking at the padlock and not the domain. Deceptive addresses have valid certificates: it is the name that exposes them.
- Typing the address without a prefix and trusting it. Many sites redirect correctly, but the first contact can happen in the clear.
- Using unencrypted configuration pages from a public network. It is one of the few cases where traffic in the clear is still common.
- Thinking HTTPS also protects afterwards. It protects the transit. What the site does with your data once received is another question.
What HTTPS does not protect
It is worth listing, because confusion on this point produces a false sense of security.
It does not protect against a fraudulent site. If you type your details into a site imitating your bank, the encryption delivers them perfectly securely to whoever will steal them.
It does not hide which sites you visit. The content is encrypted, but the name of the site you connect to is largely visible to whoever runs the network. Encryption protects the what, not entirely the where.
It does not protect the device. If there is a program on your device recording what you type, it records it before it gets encrypted.
It says nothing about what happens afterwards. A site can receive your data securely and then store it badly.
Where traffic in the clear still hides
Since the recommendation has moved from “always check” to “recognise the exceptions”, it is worth listing the exceptions. There are few and they are identifiable.
Connected home devices. Routers, printers, cameras, thermostats, video door entry systems: their configuration pages almost always use unencrypted connections, and when they do use an encrypted one the certificate cannot be verified. It is not a defect to be corrected — it is a characteristic of that category of equipment. The practical rule: use them only from the local network and never expose them to the internet.
The sign-in portals of public networks. The screen appearing when you connect to a hotel or airport Wi-Fi is often in the clear. It is the point where some networks ask for personal data, and where an existing service’s credential must never be entered.
Old and poorly maintained sites. Archives, small organisations’ portals, dated institutional pages. Reading them causes no problems; typing something into them does.
Applications that do not go through the browser. They show no address and no padlock, so there is nothing to check. The trust moves upstream: install only from official stores, and keep the apps updated.
Addresses typed without a prefix. Writing only the site’s name, the first contact can happen in the clear before the redirect. It is a very brief window, and HTTPS-only mode removes it.
Why this recommendation has become easier
It is worth telling, because it is one of the few pieces of good news in personal security.
Ten years ago most sites travelled in the clear, certificates cost money, and checking the connection was active work for the user. Today encryption is free and automated, browsers require it, and connections in the clear are the flagged exception.
The result is that most of this recommendation’s work is done by the browser. What is left to you is little but not nothing: turning on a setting, not bypassing warnings, and — the part no technology can do for you — reading the domain name.
How this connects to the Cyber Welfare Framework
| Pillar | How it contributes |
|---|---|
| Skills | Reading an address and telling the protocol from the domain |
| Awareness | Knowing what encryption protects and what it does not |
| Secure Behaviour | Stopping at a warning instead of going around it |
Digital maturity levels.
- FL1 — Basic. The address is not looked at; warnings get bypassed to reach the content.
- FL2 — Beginner. The presence of
httpsis checked before entering credentials. - FL3 — Autonomous. HTTPS-only mode is on; the domain is read as well as the padlock.
- FL4 — Skilled. An encrypted connection and a trustworthy site are told apart with confidence; certificate warnings can be interpreted.
- FL5 — Expert-Guide. You help people who confuse the padlock with a guarantee of trustworthiness: it is by far the most widespread misunderstanding.
R9 is the premise of R10 and R11: a public network can be used because the traffic is encrypted site by site.
How to check you are applying it correctly
- When I last entered a password on a site, did I look at the start of the address?
- Is “HTTPS-only” mode on in my browser?
- If the browser showed me a certificate warning, would I know what it was saying?
Quick checklist
- ☐ I check for
https://before entering credentials or personal data - ☐ “HTTPS-only” mode is on in my main browser
- ☐ I read the domain name, not just the padlock
- ☐ I do not bypass certificate warnings
- ☐ The browser is up to date
- ☐ I know the padlock does not certify the site’s honesty
- ☐ I use my home devices’ configuration pages only from the local network
For an overall measure of where you stand, you can take the digital resilience self-assessment.
In short
HTTPS is the sealed envelope: it guarantees nobody along the route can read or alter what you exchange, and that the recipient is the one named in the address.
It does not guarantee the recipient is a good person. Encryption protects the transit; the judgement about the site stays yours — and it rests on the domain name, not on the padlock.
Something to think about. The last time you saw a “your connection is not private” warning, what did you do — did you read what it said, or look for a way to carry on anyway?
Explore this recommendation
- Impact of an unencrypted connection — what is readable when the envelope is open
- Consequences of data sent in the clear — the concrete effects
- How to check a website is safe — the full procedure, in order
- Signs of an unprotected connection — what the browser shows and what it means
- How HTTPS works — certificates, encryption and identity verification
- Traffic interception — who can get in between, and how
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.
