DEV Community: Alex david du

What Really Happens When You Join Public Wi-Fi (And How To Stay Safe Anyway)

Alex david du — Thu, 04 Dec 2025 21:15:01 +0000

You are at an airport, your flight is delayed, and the free Wi-Fi pops up. You tap Connect, your phone shows the little Wi-Fi icon, and you are scrolling in seconds. No alarms, no pop-ups, nothing that feels risky.

But the moment you join that network, your traffic starts sharing the same air as everyone else at that gate. The real question is not “Is public Wi-Fi evil?” but “What can other people actually see, and what small habits keep that from turning into trouble?”

Most of the answer comes down to encryption. Modern sites and apps use HTTPS to wrap your data so anyone sitting on the same network only sees scrambled noise instead of passwords and messages. If you prefer the protocol view, this overview of HTTPS from Cloudflare shows how TLS turns readable traffic into ciphertext on untrusted networks.

When you join a public network like airport Wi-Fi, a few things happen quickly in the background:

Your phone or laptop joins the same local network as everyone else nearby.
It starts sending and receiving packets through a router you do not control.
Each app then talks to its own servers, usually over an encrypted connection.

That last part is the important one. If a site uses HTTPS correctly, the contents of the page, your login, and your cookies are encrypted between your device and the site’s server. Someone on the same Wi-Fi can usually tell which service you are talking to, and roughly how much data you move, but not what you are reading or typing.

If a site does not use HTTPS, anything you send can be read in plain text by someone running a cheap packet sniffer on that same network. That is when public Wi-Fi goes from mildly noisy to genuinely unsafe.

Where the real danger comes from

The scary parts of public Wi-Fi are less about magic hacks and more about boring tricks that still work far too often.

Fake networks that look almost right.
Attackers set up a hotspot called something like Airport_Free_WiFi and wait. If you connect, they sit in the middle of your traffic. They may not be able to crack HTTPS, but they can try to push you to fake login pages, shady downloads, or sites that drop back to insecure HTTP.

Websites and apps that still skip HTTPS.
Some old admin panels, tiny websites, or badly configured apps still send logins over plain HTTP. On public Wi-Fi, that is basically handing your password to whoever is listening. Modern browsers mark this as “Not secure,” so treat that label as a hard stop when you are on shared networks.

Warnings you click past on autopilot.
A forged certificate, a domain name that is slightly off, or a big red browser warning is often your only hint that something is wrong with the connection. Ignoring those on home Wi-Fi is bad. Ignoring them on airport Wi-Fi is worse.

Habits that make public Wi-Fi mostly fine

You do not need to panic every time you leave your home network. A few simple habits get you most of the safety without turning you into the office security person.

1. Save the sensitive stuff for mobile data or trusted networks.
Reading blogs or checking the news on public Wi-Fi is usually fine. For banking, password resets, or changing security settings, it is safer to flip over to mobile data for those two minutes, then come back.

2. Always glance at the address bar before you log in.
Check that the address starts with https://, the domain name is spelled exactly right, and there is no warning icon. If anything feels off, back out. That tiny pause is what stops you from handing your main email password to a fake page.

3. Use a VPN when the network feels sketchy.
On networks you do not trust at all, a VPN gives you an extra encrypted tunnel, so the local Wi-Fi only sees a single encrypted stream instead of every site you visit. It is not perfect, but it cuts down what a random hotspot owner can learn about you.

4. Lock down the device in your hands.
Turn off file sharing and “discoverable” modes in public places, keep system updates on, and use strong unique passwords with two-factor authentication. If someone does steal a password from an old site, that one password should not open everything else.

5. Understand the padlock once, then rely on it.
You do not need to memorize every detail of TLS, but having a clear picture of what encryption does makes those browser warnings easier to respect. A good mental model is to see it as a lock that turns your message into unreadable ciphertext anywhere outside your device and the service you are talking to. If you want that idea in plain language, this explanation of encryption with real examples walks through how modern ciphers and keys keep casual eavesdroppers out.

Public Wi-Fi will probably never feel as calm as your home router, and that is fine. Treat the network like a busy hallway instead of your living room, lean on encrypted connections, and be picky about where you type high-stakes passwords. Do that, and most airport Wi-Fi sessions are just boring packets no one can turn back into your late-night messages or credit card number.

Don’t Just Prompt, Learn The Why Behind The Code

Alex david du — Sat, 20 Sep 2025 16:35:22 +0000

I love how fast AI lets me move now. I can ask for a page, a form, or a test, and get a working start in minutes. But speed is not the goal. If I do not understand the why behind the code, I am just pasting blocks and hoping they hold.

A few years ago this was slow. I spent weekends wiring auth and basic CRUD. Even a sign in flow could take a week. Today I can set that up in hours, as long as I know what I am asking for and how it should work.

Before, the painful parts

Back then I did a lot by hand. I wrote forms from scratch, wired inputs, and fixed tiny bugs that only showed up in the browser. I built auth, login, signup, reset, email, and roles. None of it was fun. It was a lot of time for very little visible progress.

Docs were scattered. I jumped between tabs to find one missing line. Versions did not match. A simple change in a package broke something else. I kept notes just to remember what worked last time.

Testing was slow to start. I set up the runner, picked a library, and wrote helpers before I could test one rule. I knew I should do it, but it ate a full evening.

Most weekends went to glue. Not new features. Not the real problem. Just the pieces that every app needs.

For the bigger industry shift behind this, here is more of the market view: AI is changing SaaS for everyone.

Where AI helps today

It cuts the busy work. I still decide what the feature should do, but I do not start from a blank file.

I describe the screen and the rules it must follow. I get a first pass with inputs, validation, and a clean layout. I outline the data and the flow. I get handlers, routes, and basic tests. I paste an error with the stack trace. I get a fix plus a short reason.

Docs are quicker too. Instead of ten tabs, I ask for the exact call and a small example. I still check the official docs, but I land on the right line faster.

Refactors are lighter. I can take a long function and ask for smaller parts with better names. I keep what fits my style and drop the rest.

The key is simple. I bring the goal, the inputs, and the checks. AI drafts the middle. I read it, learn from it, and make it match how the app should work.

Where AI can hurt if you are not careful

It can look correct and still be wrong. Code that runs is not always code you should ship. Silent bugs slip in when you copy without checking the logic.

Security can suffer. Quick snippets skip auth checks, rate limits, and input rules. If you do not review those parts, you invite trouble.

Docs drift. Models mix versions and old APIs. You get answers that look current but are not. Always check the real docs before you trust a call.

Costs creep. More API calls, bigger prompts, extra tokens during experiments. It feels small until the bill shows up.

Style gets messy. If you accept every suggestion, your code reads like five people wrote it. Pick a pattern and stick to it.

The fix is simple. Keep ownership. Ask for reasons, not just code. Check auth paths. Run tests. Compare with live docs. If you cannot explain a line, pause and learn it before you merge.

The real key, learn while you use AI

I do not ask for code first. I write down the goal, the inputs, and how I will check it works. Then I ask.

I read the output like feedback from a mentor. What files changed, what each function does, where data comes from and where it goes. If I cannot explain it in plain words, I slow down and learn that part.

Simple loop I follow:

Write the goal in one line.
List inputs and rules.
Ask for a small piece, not the whole app.
Run it and read it.
Explain it back in my own words.
Add tests for the rules.
Move to the next small piece.

This way I build and learn at the same time. AI gives me speed. My understanding keeps the result correct and easy to change later.

What matters

Knowledge is the edge. Tools can draft a page, but knowing the goal, the inputs, the rules, and the checks turns drafts into real progress. Build small, read what you get, test the paths that matter, and keep learning as you go.