BaselineWatch
Desk
Your fleet and your work Fleetyour releases and the hardware they run onTriagewhat needs a decisionWatchlistthe products and platforms you runSaved searchesthe lists you come back to
This instance Sourceswhat is read, how often, under what termsDigestthe daily or weekly summary, and alerts
How it is drawn Appearancethe look and the colour schemeBrandingthe mark this instance wears
Owner sign-in

Home›Scan›Why these checks

Why these checks and what each can prove

Ads are a delivery path. The same auction that places a shoe advertisement can place code, and it has. Filtering ad delivery closes that road; it is one road, and the checks in this area say which roads are closed on this browser, this device, this network and this router, nothing more. The browser check runs in this tab; the manual guide does the rest by hand, and its steps lead back here.

On this page: Ads as a delivery path · Ad hiding · Ad requests · Filtering DNS · The router · UPnP port mappings · What the internet sees · DNS bypass and interception · Reading the device itself · Hardening, in order · Privacy signals · WebRTC addresses · The fingerprint surface · The referrer · Transport · This browser's version

Ads as a delivery path

An ad is content fetched from a third party at the moment the page loads, chosen for you by an auction that knows your identifier, your location and your device. That is also a description of a targeted exploit delivery system, and Citizen Lab's research shows it being used as one: an advertising-technology pipeline that delivered Candiru's spyware through targeted ads. Blocking the request means the code never arrives; hiding the slot means it arrived and was not shown. Ads served from the same domain as the content (Instagram, YouTube, TikTok) are not blocked by any of this, because the content and the ad are the same server.

Ad hiding

Content blockers carry generic cosmetic rules that hide any element named like an ad slot. The check plants twenty such names and two neutral ones and reads back which were hidden. It proves a blocker with cosmetic rules is active in this browser. It does not prove requests were stopped (that is the next check), and a blocker that hides nothing here may still block everything, so a zero is "not observed", never "unprotected".

  • uBlock Origin, the blocker whose generic rules these names come from
  • EasyList, the filter list most blockers carry

Ad requests

Request filtering is the control that matters, because the request is what carries a payload. The check loads images whose paths match three of EasyList's request rules, /ad_images/*$image, /adsbanner-$image and /ad_skyscraper.gif$image as the list read on 2026-10-19, between control images with identical bytes, on this server and, when the owner has named one, on one cross-site host. A load difference is evidence of request filtering; a timeout is unknown; a failure this page's own policy caused is reported as such. No advertising domain is contacted, so the test leaks nothing to an ad network.

Filtering DNS

A browser blocker protects one browser. A filtering resolver answers "no such name" for ad, tracker and malware domains for every app that uses the system DNS, which is most apps on a phone and most on a computer. The browser check can confirm two resolvers by their own self-check endpoints; the network check planned for this server will confirm any resolver by resolving canaries through it. A VPN, iCloud Private Relay or a browser's own DNS-over-HTTPS replaces the system resolver and must be checked where it is set.

By hand: the guide's DNS section for Windows, macOS, Linux, iPhone and iPad and Android.

The router

Every device on the network trusts the router for its address, its resolver and its path out. A router with a known exploited vulnerability on its LAN-side admin page is reachable by any device that joins the network, including a guest's phone; one with remote management open on the WAN side is reachable by everyone, and that is where routers on CISA's Known Exploited Vulnerabilities list are usually exploited. The password printed on the device, and the vendor's default, are in every list an attacker tries first. The guide's router section is the same on every platform: change the password, hand out the filtering resolver by DHCP, turn UPnP and remote management off, note the firmware and look it up in this site's Vulnerabilities table, where a KEV entry is one CISA has seen exploited. The router check planned for this server will read the model and firmware the gateway announces and do that matching by the hour.

By hand: the router section of the guide.

UPnP port mappings

Universal Plug and Play lets any program on the LAN ask the router to open a port from the internet to that program, without a password: the Internet Gateway Device service's AddPortMapping call is the whole mechanism. Games use it; so does anything that wants to be reachable, and so does malware that wants a way back in. A mapping to a remote-desktop, file-sharing or SSH port is a hole in the firewall that nobody approved. CERT's note on routers that accept UPnP requests on the WAN side shows the worse case, where anyone on the internet can ask. Turning UPnP off removes the mechanism; reading the table once a month catches what it opened. The scripts list the mappings with the same GetGenericPortMappingEntry call any device on the LAN may make, and never add or remove one.

By hand: the router section of the guide; the scripts' upnp row reads the table.

What the internet sees

Public indexes crawl every address and record what answered. That record is what an attacker reads before touching anything, so the first question about your address is what the index says. The guide asks Shodan's free InternetDB lookup for your public address rather than scanning from here, which keeps this product from being the thing that scans you; it is a record of what the crawlers last saw, not a live scan, and a port that UPnP opened yesterday may not be in it yet. The firewall check planned for this server will ask the same lookup once a day and treat a change as news.

By hand: the network section of the guide.

DNS bypass and interception

Network-wide filtering only covers devices that use the network's resolver. A device with a hard-coded resolver, or an app or browser using DNS over HTTPS, walks past it unless the router redirects port 53 to the filter and blocks the known public DoH endpoints. The guide's test is one lookup of an ad domain sent straight to a public resolver: a real address means the bypass is open, a sinkholed answer or a timeout means the router caught it. The opposite failure exists too: an ISP or a router that silently answers every DNS query itself, which the same lookup shows when a resolver you did not choose answers. DNS over HTTPS and DNS over TLS are the encrypted forms, worth having on the resolver you chose and worth blocking for the ones you did not.

By hand: the network section of the guide; the scripts' bypass rows run the same lookups.

Reading the device itself

A browser test sees one browser. The device scripts read what every app on the device uses: the system resolver, the hosts file, the firewall's state, what listens, and the settings that change how a target is picked. Where an ad leaves a trace, history alone misses it: cookies, cache and local storage keep the hosts an ad frame touched, and that reading against an indicator list is the next step planned for the scripts. Windows does not record DNS lookups unless its DNS-Client log is turned on, so the past is usually unrecorded; turning it on is the one setting the scripts recommend. A clean result means no finding where the script could look; spyware of this grade is built to defeat exactly this kind of check, so a concrete reason to think you were targeted is a reason to use a helpline.

By hand: the scripts on the guide index, with their checksums.

Hardening, in order

  1. Filter DNS for every app on the device and, at the router, for every device. Reduces requests to known ad and tracking domains.
  2. Lockdown Mode on iPhone, iPad and Mac for anyone likely to be targeted: limits what an attack can do if one gets through.
  3. Take away the advertising identifier: changes how a target is picked in the first place.
  4. Look at the past with the Mobile Verification Toolkit; none of the first three says whether anything already happened. Spyware of this grade is built to defeat exactly this kind of check, so a concrete reason to think you were targeted is a reason to use a helpline.

How this page is written

Each section rests on a primary document and links to it. Where a sentence is this product's reading rather than the source's words, it says "the check" or "this product". Nothing here is generated by a model. The router, exposure and bypass checks this server will run itself arrive later; the guide does them by hand today.

Privacy signals

Global Privacy Control is a header and a script property that says "do not sell or share my data". Unlike Do Not Track before it, several US privacy laws oblige a site to treat it as a valid opt-out, and regulators have fined sites that ignored it. The row reads whether this browser sends it; a browser that cannot yet (Chrome, Safari) gets no mark against it, only the fact.

WebRTC addresses

To set up a call, a browser gathers the addresses it can be reached at and offers them to the other side. A script can start that gathering without a call and read what is offered: historically the LAN address, and through a VPN the real public one. Every current browser now hides local addresses behind an mDNS name unless the user has granted camera or microphone access. This row gathers with no STUN server at all, so nothing leaves this tab, and reports which case this browser is.

The fingerprint surface

A tracker that cannot set a cookie reads what the browser reveals about itself — the exact rendering of a canvas, which fonts are installed, the screen, the time zone, the languages, the cores — and from enough of these recognises the same browser again. The surface is not a leak of any one fact; it is the stability and width of all of them together. Brave adds noise to the canvas on every draw; Firefox's resistFingerprinting and the Tor Browser round the rest to common values. The row draws the canvas twice: two different hashes mean the browser is randomising, which is the good answer.

The referrer

The Referer header tells the next site where you came from. Under the default every current browser now uses, strict-origin-when-cross-origin, another site learns the origin only and a plain-HTTP site learns nothing; a page can ask for more with a policy of its own. This row asks this server what it received, and the second origin when one is configured, so the answer is what arrived rather than what the policy says.

This browser's version

A browser release is mostly security fixes, and the vendor publishes which flaws it closed the day it ships: Chrome's release notes, Mozilla's advisories, Apple's security content. A browser behind the newest release is running code with documented holes, and an exploit for a browser flaw arrives through an ordinary page. The row reads the version this browser gives of itself — the full one through client hints on Chromium browsers, the major and minor from the user agent on Firefox and Safari — and asks this server what the vendor feeds hold. Updating is not enough: the fixes run only after the relaunch.

Transport

Whether this connection arrived over IPv6, and over which HTTP and TLS versions, is what the path between this browser and the site can do. None of it is a flaw in itself; it is what every site you visit can see, and the IPv6 answer in particular is one most people have never been shown.

  • test-ipv6.com, the fuller IPv6 test, which needs its own dual-stack hosts