What Your Device Announces to a Network Before You Open Anything
Between tapping a network’s name and opening anything at all, your device sends a short series of messages introducing itself. It asks for an address and usually attaches its own name to the request. It asks in a pattern characteristic of what it is. Depending on its settings it advertises services it is willing to provide, and it asks the segment out loud for the hardware addresses of whatever it wants to reach. A VPN covers none of this, and no VPN could, because none of it is travelling anywhere a tunnel goes.
That makes it an unusual privacy topic for this site: the audience for these messages is small and specifically local, the disclosures are more concrete than most people assume, and — unlike almost everything above this layer — several of them are genuinely under your control.
The address request arrives with a name on it
A device with no address yet cannot address anything, so its first message is a broadcast to the whole segment asking for configuration. Whatever hands out addresses answers, and the exchange ends with your device holding an address, a gateway, a mask, and a list of resolvers.
The request usually carries your device’s own hostname as an optional field, which is why a router’s client list shows recognisable entries rather than a column of numbers. That name was set once, probably during first-time setup, probably by you or by a phone that suggested a default containing your first name. It is then repeated to every network the device joins, for as long as you own it.
This is the disclosure worth acting on, because it is stable in exactly the way a hardware identifier is not. If your adapter presents a different value on every network but the accompanying name stays the same, the name is now the more reliable way to recognise your device — a point that pairs directly with what MAC address randomization hides.
The shape of the request says what kind of device asked
Two devices asking for the same configuration do not ask in the same way. The set of options a client requests, the order it lists them in, and whether it includes a vendor or client identifier all vary between operating system families and between versions of one family.
The consequence is that the exchange narrows down what joined the network even with no name attached: a phone, a laptop, a games console, a set-top box, a device running an old release. Nothing about this is hidden or clever; it is a side effect of independent implementations of the same protocol making different choices.
It is also the one item on this page you cannot meaningfully edit. Renaming a device is a settings change; making it request configuration like some other kind of device is not something consumer software exposes, and it is not worth pursuing.
Announcements nobody asked you for
Service discovery works by shouting. A device offering file sharing, printing, screen mirroring, media playback, or remote access advertises that fact to a multicast address that every other device on the segment receives, along with a service type, a port, and a name.
On your own network this is the machinery that makes a printer appear in a print dialogue without configuration. On a network you do not control, the same machinery tells every other device present that a particular named machine is here and offering these specific services. Discovery protocols with different designs behave the same way in this respect: the advertisement goes to the local segment, unencrypted, unsolicited, and repeatedly.
The audience is worth being precise about. It is not the network operator alone — it is everything else attached to that segment, including other guests, unless the network separates clients from each other, which is the subject of what a guest network actually separates.
Address resolution is a conversation held in public
To send anything to a device on the same segment, including the gateway, your device has to ask which hardware address holds a given network address. That question is a broadcast, and on many networks so is the answer.
Two things follow. First, the outline of your local activity is visible: which local addresses you are trying to reach, and how often. Second, this continues while a tunnel is up, because the tunnel’s own encapsulated packets still have to be handed to the gateway, and handing anything to the gateway means knowing its hardware address. A quiet device and a busy one look different from the segment even when everything the busy one sends is encrypted.
Why a tunnel cannot cover any of it
There are two independent reasons, and each would be enough on its own.
The first is layering. A tunnel takes traffic destined for somewhere else, wraps it, and hands the wrapper to the gateway. Traffic that was never going past the gateway is never offered to it — the address request, the multicast advertisements, and the neighbour queries are all addressed to the segment and answered on the segment. There is nothing for the tunnel to intercept.
The second is ordering. The tunnel cannot exist until your device has an address, a gateway, and usually a resolved name for the VPN server. Every message described above happens first, by necessity. A client that fails closed protects the traffic that comes after it, not the introduction that had to happen before it — see how a VPN kill switch fails closed for what that guarantee does and does not extend to.
What is actually worth changing
- Rename your devices. Pick something that identifies the device to you and nothing else to anyone. Do it on every device you carry, once, and it is done for the life of the hardware.
- Turn off sharing and discovery when you are not on your own network. Most systems group these as file sharing, printer sharing, media sharing, and remote access. Off by default, on when needed, is the right shape.
- Leave hardware address randomization on everywhere except networks where you want the device recognised.
- Put devices you cannot configure somewhere separate, since a smart appliance that advertises loudly and has no settings page is a fixed quantity you can only isolate.
- Do not chase the option fingerprint. It is real and it is not addressable.
Keeping the scope straight
Everything on this page is visible to the network in front of you and to nothing beyond it. No website learns your device name from an ordinary connection, your access provider does not see your multicast advertisements, and none of it appears in what a destination logs about you.
That is the same discipline that makes the rest of this site’s advice work: name the observer first, then pick the layer. The tunnel answers for the path; this layer answers for the room. Reaching for one when you meant the other is how people end up protected against the wrong party, and it is why reading your own network settings is a better first move than installing anything.