What browser exposure means
Browser exposure is the set of signals a site can read or infer when a page loads. Some signals are obvious, such as screen size or language. Others come from rendering behavior, device capabilities, storage, permissions, WebRTC behavior, or route context.
Aerod separates these checks into focused apps so each result answers one question clearly.
Exposure is not the same as identification. A common browser value may reveal very little by itself, while several stable values can become more useful when combined. A result also describes the current browser session, not every browser, device, profile, or network the user operates.
Common signal groups
| Signal group | Examples | Where to check it |
|---|---|---|
| Public route | Public IP, ASN, ISP or organization, approximate location | IP Lookup |
| Browser permissions and privacy settings | Browser identity, locale, storage, permissions, privacy controls | Browser Permissions & Privacy Settings Check |
| Fingerprint surface | Rendering, WebGL, audio, fonts, screen geometry, client hints | Browser Fingerprint Check |
| WebRTC candidates | Public-looking candidates, private/local candidates, mDNS hostnames | WebRTC Leak Test |
| Route consistency | Proxy/VPN expectation, browser context, timezone, DNS, WebRTC mismatch cues | Proxy/VPN Detection |
| Media-device access | Camera preview, microphone level, selected input devices, and permission state | Online Webcam Test |
How results should be presented
Aerod should avoid alarmist language. A signal being visible does not always mean a user is compromised. The correct presentation is: visible signal, practical risk, limitation, and remediation.
For a combined sequence across these tools, follow the browser leak testing guide. The permissions and privacy settings app covers its own signal group; WebRTC candidates and the deeper fingerprint check have separate tools.
Camera and microphone checks are permission-based device tests, not fingerprint or identity tests. DNS Leak Test remains separate because a real DNS leak test needs controlled resolver-path infrastructure.
How to interpret a change
When a setting, extension, VPN, proxy, or browser profile changes, repeat the same focused test and compare one variable at a time. A changed public IP confirms that the tested request used a different public route; it does not prove that DNS, WebRTC, cookies, account state, or browser fingerprinting changed with it. Likewise, blocking one exposed browser API does not make the rest of the fingerprint surface disappear.
Unexpected results should be checked in a fresh tab and, when practical, in a second browser profile. This helps separate a persistent device or network signal from a profile-specific setting, extension, cached permission, or stored site state.
Processing boundaries
Each app should say when a check runs locally and when it needs an external network or IP-intelligence request. Permission-based camera and microphone tests should not begin until the user starts them. A browser test can describe what the page observed, but it should not claim to prove anonymity, identity, compromise, or complete protection.