Sniffing out tracking beacons using free network analysis tools
Picture yourself at a servo in Geelong grabbing a flat white before the slow crawl up the M1, and your phone buzzes because yet another site is shipping data you didn't ask for. Tracking beacons are the small invisible pings a webpage fires the moment it loads, often without telling you. They tell a server you arrived, what you looked at, and sometimes where you went next.
For Australians worried about how their data is handled under the Privacy Act and the Notifiable Data Breaches scheme, knowing which domains phone home matters more than ever. The good news is you don't need enterprise gear. A laptop, a quiet connection, and a free packet capture program will do the job.
This guide walks through the practical steps of pointing a network analysis tool at a domain, recording what it sends, and reading the trail. It's aimed at anyone who wants to be more sceptical about the websites they visit, from IT students in Brisbane to small business owners in Adelaide wondering why their landing page leaks to third parties.
What a tracking beacon actually is
A beacon is any small request a webpage makes once it has your browser. The classic form is a one-by-one pixel image, which loads invisibly and quietly tells a server you are there. Modern versions use JavaScript that fires when you scroll, hover, or close a tab. Some even reach for browser fingerprinting, stitching fonts, screen size, and time zone into a profile.
Because Australia does not yet have a single uniform cookie law like parts of Europe, much of the policing falls on the Privacy Act 1988 and the work of the Office of the Australian Information Commissioner. That makes it worth knowing exactly which third parties are pinged when you load a page. If a domain claims to be a local council site but quietly calls overseas ad networks, that's a signal worth chasing.
Getting Wireshark running on a quiet connection
Wireshark is the de facto free tool for this job. Install it on a laptop, plug in via Ethernet if you can, and pick the right network interface before you start. Wi-Fi on a flaky NBN link in a share house in Fitzroy will drop packets and leave you chasing ghosts.
Close every other app, including cloud backups and chat clients, then begin the capture. Open the site you want to test in a fresh browser profile, browse for a minute, and stop the recording. Save the file somewhere obvious with a name like domain-check-2026.pcap. Working in a folder you can find later saves pain when the arvo coffee wears off and you need to revisit the capture.
Reading the DNS chatter first
Before you even look at payloads, start with DNS. In Wireshark, type dns into the display filter and you'll see every hostname your machine tried to resolve while the page was open. A simple news site might hit a handful of names: its own, a content delivery network, maybe an analytics provider. A noisier one resolves dozens.
Look up any host you don't recognise through SecurityTrails or even a quick search. A favicon that doesn't match the site's claimed identity is one of the small tells that something is off; the analysis at favicon mismatch and branding shows how a mismatched icon can hint at broader inconsistency. The same idea applies at the network layer. If the favicon on a brisbane-courier page is being served from a totally unrelated origin, the beacon list deserves a closer read.
Adding TLS handshakes to the picture
Once you have the DNS list, switch the filter to tls.handshake to see every secure connection your browser tried to make. The Server Name Indication field inside the handshake spells out the hostname, even though the traffic stays encrypted. This is how you confirm a request really went where DNS said it would.
You can also right-click a TLS handshake and follow the stream to look at the certificate. A valid certificate is not a guarantee of good behaviour, but a self-signed cert or one issued for the wrong domain is a bright red flag, especially on a site that purports to be a local government portal in Canberra. Pair this with the DNS view and you have a solid map of who is being contacted and whether the connections were actually established.
Browser dev tools as a lighter check
Not every investigation needs Wireshark. Chrome, Firefox, and Safari all ship with a Network panel that records the same beacons at a higher level. Open dev tools, switch to the Network tab, sort by domain, and reload. Third-party calls jump out fast because they don't match the site you are visiting.
From there you can right-click any request and block the domain, then reload to see whether the page still works. It's a quick way to test, say, whether the live-auction widget on a real estate portal genuinely needs to phone a tracking vendor in Singapore to display a property listing. For a casual brekkie check before lodging a complaint with ACMA, this is often enough.
Sorting real beacons from CDN and ad noise
The hard part is telling the difference between a tracking beacon and a legitimate performance call. A site loading JavaScript from cdn.jsdelivr.net or images from Cloudflare is not the same as a site firing off a Facebook pixel the moment you land. Build a small whitelist of domains you trust for delivery and infrastructure, and treat anything outside that list as suspect.
Aussie-specific examples help. A news site in Hobart might legitimately call live.au.syndic8.io for syndicated stories. A small retailer in Parramatta might rely on static.auspost.com.au for shipping calculators. Anything outside that pattern — a sports blog pinging a Russian ad network, for example — is worth flagging in your notes so you can raise it with the site owner or, where appropriate, with the regulator.
Turning the capture into a usable answer
Once you have a clean capture, export the filtered list of third-party hosts into a spreadsheet and revisit the site over a few days. Beacons sometimes only fire on certain pages, after you scroll, or when you return a second time. Patterns matter more than single captures.
If the picture is consistent, take it back to whoever runs the site. Many site owners genuinely do not know what their marketing tag manager is configured to send, especially when contractors come and go. A polite note listing the domains, the timing, and a few packet timestamps is usually more productive than a public stoush. If the site is yours and you want it cleaned up, the same notes become a punch list for your developer.
What to take away: a free packet capture tool, a steady connection, and a methodical read of DNS and TLS will tell you more about a domain's habits than any privacy policy ever will. Once you know how to read the traffic, a strange domain stops being a mystery.