Welcome to Basic Computing’s Learning Hub. What will you learn today?WelcomeWelcome to Basic Computing’s Learning Hub.What will you learn today?
EVERYDAY SECURITY BASICS · LESSON 04
Browse the web safely
FREE LESSON
10 minutesCommon browsers on Windows 11; controls vary by browserBeginner
Section 1 of 410 minutes
Learn at your own pace
UNDERSTAND THE IDEA
Look beyond a convincing page
A teaching illustration, not a browser screenshot. The decorative QR pattern is not for scanning. A padlock protects the connection, not the honesty of the website.
What am I going to do?
You are going to explore nine illustrated topics, make choices in six fictional browsing situations and answer three questions about safer browsing.
What will I learn?
You will be able to distinguish a website domain from misleading surrounding words and choose a separate way to check an uncertain request.
Preparing the illustrated parts…
WORK THROUGH AN EXAMPLE
Compare the addresses
Work through six fictional examples. Choose an answer and click Check answer. Read the result and the highlighted address explanation. After each of the first five correct answers, click Next example. When all six are correct, click Continue below. Nothing opens a real website. With a keyboard, use Tab to reach the choices, arrow keys to select, then Tab and Enter to check.
Read the six destination examples
These are fictional teaching addresses, not links. The highlighted part is the actual domain. A domain match alone does not prove a request is safe.
1. A page for upcoming events
You previously checked the bookshop’s domain through a trusted source. It is books.example. You are comparing the address of its events page.
https://books.example/events
The domain is books.example. The slash starts /events, which is a page location. This address uses the expected domain. That describes the address structure; it does not prove every request on the page is honest.
2. An events section with an extra name
The bookshop’s known domain is still books.example. This events address includes an extra section. Compare the complete address.
https://events.books.example
The complete books.example domain stays together at the end of this website name. The events section before it is a subdomain beneath books.example. A matching domain still does not guarantee that a request is safe.
3. A message about your booking
You booked an event with the shop whose known domain is books.example. A message offers a destination for checking the booking.
View your booking using the address below.
https://books.example.signin.example/booking
The actual domain is signin.example. The familiar books.example words have been placed before that different domain. Leave this message’s destination alone and check through the bookshop’s usual app or previously checked address.
4. A name that looks nearly the same
You expect books.example. Read every dot in this address rather than joining the letters together in your mind.
https://bo.oks.example/events
The actual domain is oks.example. The bo section is a subdomain beneath it. The dot splits the familiar-looking word: bo.oks.example is different from books.example. Use the address you already checked instead.
5. A QR code in an unexpected message
An unexpected message says to scan a QR code to confirm your bookshop ticket. Your phone shows this destination preview. The bookshop’s known domain is books.example. No code is shown or needs scanning here.
Scan to confirm your ticket today.
https://ticket-check.example/confirm
The preview leads to ticket-check.example, which differs from books.example. A QR code is another way to reach a destination, not a check of who controls it. Use the shop’s usual app or previously checked address to investigate the ticket independently.
6. A button about your order
A message about your book order shows the familiar name books.example in its button wording. The destination preview below shows where that button would lead. Compare it with the known books.example domain.
Button wording: View my order at books.example
https://orders.example/books.example
The actual domain is orders.example. Here books.example appears after the slash as part of a page location, and also in the message’s button words. Neither changes the destination’s domain. Check the order through a route you already trust.
MAKE SENSE OF IT
Check your understanding
Click Start 3 questions. Choose an answer by clicking its circle, then click Check answer. Read the result and explanation. You can change a wrong answer and check again. After each of the first two correct answers, click Next question. After all three, click Continue below. With a keyboard, Tab reaches the choices, arrow keys select an answer, and Tab then Enter activates a button.
In guided learning, click Start 3 questions to receive a selection from this lesson. Click the circle beside an answer, then click Check answer. Read the feedback and try again if needed. Click Next question after each correct answer. Answer all 3 correctly to continue.
Returning to guided learning keeps the questions and answers in your current attempt.
Read all 10 questions and explanations
In https://loans.example/account, which part names the website rather than the page location or connection method?
Answer: loans.example
loans.example names the website. The /account part is a page location, and https describes the connection method.
A shop’s known domain is books.example. What does events.books.example tell you?
Answer: It names a subdomain beneath books.example, but the request still needs judgement.
The extra section is before the complete books.example domain. That explains the address structure; it does not guarantee an honest page or request.
You expected books.example. The address instead shows books.example.signin.example. Which reading is correct?
Answer: The familiar name is placed beneath the different domain signin.example.
The website name continues after books.example, ending in signin.example. Dots in the website name are different from the slash that begins a page location.
You expected books.example, but the page address is https://signin.example/books.example. What does the ending show?
Answer: A page location on signin.example, not the bookshop’s domain.
After the slash, books.example is part of a page location on signin.example. A familiar name in that position does not change which site you reached.
Two website names both end in .co.uk. What can you conclude from that ending alone?
Answer: They share an ending; you still need to compare each complete organisation domain.
Many unrelated organisations use .co.uk. It has two parts, so a rule that always takes the last two parts would miss the organisation’s own name.
A payment page uses HTTPS. What protection does that provide?
Answer: Encryption for information travelling to that site, without proving the operator is honest.
HTTPS protects the connection. A dishonest website can use it too, so the address and the reason for a payment still need checking.
A message’s button says View my order, but the shown destination differs from the shop address you know. What should you do?
Answer: Check the order through the shop’s usual app or an address you already verified.
Button wording and HTTPS do not verify the destination or request. Use a route independent of that message to check your order.
You are unsure about a message. It offers both a link and a QR code for the same action. Does choosing the code settle your concern?
Answer: No. The code can lead to a website too, so use the same caution.
A QR code is another way to reach a destination. It does not establish who created that destination or whether the request is genuine.
You search for an organisation and the top result uses its name and logo. Which check matters before entering account details?
Answer: Compare the destination with the organisation’s address from an independent source you already trust.
Search position, titles and logos are not proof of identity. The destination and the source you use to confirm it matter.
You follow a sign-in link and the browser warns that the connection is not private. What is the useful next step?
Answer: Stop and check through the service’s known app or trusted support route.
Do not use the page or message to justify bypassing a browser warning. Return to a known route or get help before entering private information.
USE WHAT YOU HAVE LEARNED
Practise noticing the address
This observation is optional. You can finish using the fictional examples. Do not visit any .example address, open a suspicious message or enter a password for this lesson.
1
If you already have a page open from a service you normally use, look at the browser’s address bar near the top. Hold Ctrl and press L, then release both keys, to select the address. This does not follow a link or open another page.
2
Look for the website’s name and any page location after a slash. Compare the complete domain with an address you previously checked, if you have one. If the address is unfamiliar or confusing, stop the observation rather than guessing who controls it.
3
Press Escape without typing or pressing Enter. You do not need to change the address, sign in or make a payment. To close the browser window when finished, click its X at the top right.
4
Think of a separate route you could use if a message worried you, such as the service’s existing app or contact details on an earlier trusted statement. You do not need to send a message or make a call now.
Finding matching words is not a safety certificate. Use the known route and consider the request itself. The lesson does not inspect your browser or verify any real website.
Progress is saved in this browser on this device.
Prefer a more personal, one-to-one lesson? Basic Computing can help. Explore our services.
Choose a topic below to open its explanation. You can return to any topic.
Choose a picture above to read about that topic. You can explore in any order and return to a picture whenever you want.
Take your time. When you are ready, use Continue below to move to the next section.
