MyIPScan
Home>Methodology
Methodology v1.1

MyIPScan Methodology v1.1

How MyIPScan estimates visible browser/session exposure, explains confidence, builds Safe Copy summaries, and labels the limits of each diagnostic.

Methodology version: v1.1, published May 24, 2026. This methodology can evolve as tools, browsers, VPN behavior, and safe reporting features change.

Short version

  • MyIPScan checks visible signals from your current browser session and network context.
  • The public label is an exposure estimate. Higher means more visible signals may need review.
  • A clean result is not a privacy certification and does not show that every security condition or leak path was checked.
  • Safe Copy exports use safe summary categories and remove raw technical identifiers.

What MyIPScan checks

MyIPScan combines focused diagnostics for signals a website, browser API, or limited public lookup can observe. The core privacy path checks IP and network context, DNS resolver or route signals, WebRTC candidate behavior, IPv4 and IPv6 visibility, browser and user-agent summary signals, browser fingerprint surfaces, and GPC or DNT where a browser exposes them.

Other tools cover DNS records, domain and certificate context, website security and SEO signals, email authentication records, and local utilities. Those tools are limited diagnostics too; they are not full security audits.

What the exposure estimate means

MyIPScan displays an exposure estimate from 0 to 100. A higher estimate means more visible browser/session signals may need review. A lower estimate means fewer review flags were found among the checks that ran.

The estimate is a review signal, not a certification. Unknown signals are not treated as safe, and they are not treated as automatic failures. Unknown signals reduce confidence because the diagnostic has less evidence.

Confidence levels

  • High confidence: enough core signals were available to classify the current browser session.
  • Medium confidence: some signals were unavailable, mixed, or limited, but the result still has useful context.
  • Low confidence: the diagnostic is incomplete or several signals were unavailable.

Low confidence is not the same as unsafe. Unknown is also not the same as safe. It means you should interpret the result with more caution and, when possible, run related focused checks.

Why results can vary

Browser APIs, VPN apps, DNS resolvers, operating systems, routers, captive portals, CDN edge location, public lookup providers, and network policy can change what is visible between runs. Treat results as current-session review signals and retest after setup changes.

Risk flags and review labels

Risk flags use cautious labels such as review needed, visible signal, limited signal, unknown, or inconclusive. A flag means a signal may deserve review in your current setup. It does not automatically mean harm, tracking, or VPN failure.

Safe Copy

Safe Copy is a safe summary of the current browser/session result. It is designed for understanding, retesting, and sharing reduced categories. It is not a certificate, a provider audit, a VPN ranking, or a privacy certification.

The receipt can show the exposure estimate, estimate type, label, confidence, safe signal categories, review flags, limitations, related checks, and methodology link. The visible diagnostic page may still display raw current-session details needed for the tool itself, but receipt copy, share text, and PNG export use a reduced view model.

Safe share and export rules

Receipt copy, safe share text, and PNG export remove raw sensitive values before export. Exported receipt content must not include the full IP address, full IPv6 address, exact city, latitude or longitude, full user-agent string, raw fingerprint value, fingerprint hash, raw DNS resolver IP, raw WebRTC candidate string, or persistent identifier.

If the receipt safety validation sees a sensitive-looking key or value, export actions fail closed instead of copying or drawing that payload.

Storage and data handling in this flow

The unified diagnostic and receipt flow is generated at runtime in the browser. Legacy raw diagnostic storage for IP history, shared estimate state, homepage before/after snapshots, and DNS before/after snapshots has been removed or neutralized. The receipt does not create a persistent user ID and does not use localStorage, sessionStorage, cookies, IndexedDB, or Cache API.

No telemetry was enabled by the growth-engine receipt flow. Existing analytics and hosting behavior are separate from the receipt feature. This methodology describes the in-browser diagnostic and receipt flow, not every infrastructure log that may exist at a hosting, CDN, security, DNS, STUN, analytics, or third-party lookup provider level.

How the IP check works

The IP check calls /api/ip, implemented as a Cloudflare Pages Function. It reads request metadata such as the public IP address, reduced browser context when available, Cloudflare country or ASN fields when available, and edge metadata.

The function can make server-side IP enrichment requests to providers such as ipwho.is, ipapi.co, or ipwhois.app. Location, ISP, ASN, and VPN/proxy hints are approximate and best-effort. Websites normally need a public IP to respond; IP visibility alone is not automatically a leak.

How the VPN leak test works

The VPN leak test is a guided diagnostic that combines public IP, DNS, WebRTC, IPv6, and browser-signal checks. It can highlight signals that look inconsistent with the route you expected, but it does not certify a VPN provider, test every server, inspect every app, or cover every device and network.

Use before/after comparison as a local session aid: run a baseline, change VPN or network state, rerun, and compare visible categories. A clean current-session result is not a privacy certification and does not show that every leak path was checked.

How the DNS leak test works

The DNS leak test fetches public DNS-over-HTTPS resolver-signal services that can report resolver IP signals. The tool compares returned resolver signals against known public resolver patterns and labels unknown, IPv6, mixed, or unexpected signals as values to review against expected VPN and browser DNS settings.

The page also calls the MyIPScan DNS Lookup API as a server-side control lookup. That control confirms the API path through a free public DoH resolver; it does not represent every browser, operating system, router, VPN, or app resolver route. The current DNS leak test does not use authoritative DNS capture.

DNS limitations

  • Resolver IPs may represent VPN DNS, ISP DNS, public DNS, enterprise DNS, or browser/OS secure-DNS behavior.
  • A public DoH response is not the same as authoritative DNS capture.
  • Network policy, browser privacy settings, CORS, captive portals, resolver forwarding, and VPN app settings can affect results.
  • A clean DNS result only describes the resolver signals that were checked.

How the WebRTC leak test works

The WebRTC test creates an RTCPeerConnection, gathers ICE candidates, and reads address-like values surfaced by the browser. The current script uses the public STUN server stun:stun.l.google.com:19302. Modern browsers may mask local IPs with mDNS or hide candidates.

Local or limited candidates are not the same as public IP exposure. WebRTC behavior can vary by browser, device, extension, permission state, VPN app, and network.

How the IPv6 leak test works

The IPv6 test checks the IP API response and WebRTC candidate signals for IPv6 visibility. IPv6 visibility can be normal on dual-stack networks. It may need review when VPN or privacy routing is expected, especially if a global IPv6 route appears outside the expected path.

Results depend on ISP, browser, operating system, router, VPN, split-tunnel rules, and network policy.

How the browser fingerprint demo works

The browser fingerprint tools read standard browser APIs such as user-agent summary, language, timezone, screen size, canvas, WebGL, audio, fonts, hardware concurrency, privacy preference signals, and client hints where the browser exposes them.

The overview computes a local demonstration value to explain browser surfaces. It does not use a comparison dataset, does not identify a person by itself, and does not prove that another website will see the same value.

Website, domain, and email diagnostics

Website, DNS, domain, certificate, structured data, metadata, robots, sitemap, SPF, DMARC, MX, and email header tools inspect selected public records or submitted values. They can help find configuration signals, but they do not replace full deliverability, compliance, incident-response, or security review.

What MyIPScan does not certify

  • It does not certify anonymity.
  • It does not review every security condition.
  • It does not show that every leak path is absent.
  • It does not identify a person.
  • It does not certify a VPN provider.
  • It does not test every VPN server, app, device, browser, operating system, router, ISP, or network.
  • It does not replace a full privacy, security, legal, compliance, or incident-response audit.

How to use results responsibly

  1. Run the homepage diagnostic or VPN Leak Test for a broad session view.
  2. Use focused tools for DNS, WebRTC, IPv6, browser fingerprint, and IP context when a signal needs review.
  3. Repeat the test after VPN, browser, DNS, extension, device, or network changes.
  4. Use Safe Copy for reduced summaries only, not as a permanent guarantee.
  5. Review methodology and tool limitations before making operational decisions.

Future aggregate reports

Future public reports may use privacy-safe aggregate categories only if that collection is implemented, documented, and tested. This page does not imply telemetry is currently enabled for the growth-engine receipt flow and does not claim an existing aggregate dataset.

Related diagnostics and policies

Corrections

You can inspect your browser Network panel while running each tool. For corrections, send the page URL and specific behavior to hello@myipscan.net.