Testing a fingerprint before work

Test the profile before you open work. The test is whether the story still agrees with itself: exit, clock, pin, cookies, GPU family, and whether quit-and-open kept the same person. It is not a recipe for passing a public fingerprint lab. A green checker is not authorization. A red checker is not a ban.

If you do not have a right to the account, stop. This checklist will not create that right.

What I am testing

I am testing a local Windows profile I already meant to use. The public channel is Windows 10 and 11 x64. Each profile is a folder under the local store, a seed, and an optional HTTP or SOCKS5 you brought. There is no account and no cloud sync.

What browser fingerprinting actually measures is the bundle. I want the bundle to be one person. I do not want a unique hash in a vendor sample.

The Browser fingerprinting cluster already refused trophy hunts. This page is the operator order of operations.

The order I actually use

The hop check is TCP connect only. It does not prove auth succeeded. If the exit is wrong, do not open work to "see what happens." On start we update timezone, locale, languages, and the pin from ip-api.com. At CDP apply the page may probe ip-api.com or geojs.io again. That traffic leaves the machine.

The GPU renderer has to match the user agent. A mobile user agent on a desktop profile and a macOS fingerprint on a Windows host fail here on purpose. If I painted a new fingerprint on the same folder, I still have the old login. The test is "is this the person I meant," not "did the hash change."

What I refuse to do in this checklist

I refuse to chase Pixelscan, IPhey, BrowserScan, or CreepJS to green. Those pages are maps. I may open a map to name a contradiction. I will not stay until a vendor smiles. We have no published pass rates. I will not invent a target score.

I refuse to treat a digital footprint as a canvas problem. Accounts, emails, and payment instruments are a different job. Clearing a hash does not clear a login graph.

I refuse to treat Topics or CHIPS as a pre-work test. Those are tracking replacements. They are not the profile.

I refuse to reseed because a lab looked sad. A seed is a decision to remain. The surfaces we actually cover are applied to stay put, not to reroll for a screenshot.

What the product will and will not change for you

The inject and CDP path can override UA, hints, platform, locale, timezone, screen, cores, memory, WebGL, WebGPU, canvas, fonts, client rects, audio, WebRTC policy, geolocation, media device IDs, plugins, battery, network information, speech voices, permissions, bluetooth presence, window.chrome, webdriver, and Do Not Track.

Partial layers stay partial. JA3 and JA4 need a patched BoringSSL tree. Font raster needs the custom core plus a font list. Process name aliasing is optional and Windows-specific. When the Chromium 131 core is missing, launch falls back to system Chrome or Edge with JS and CDP spoof only.

Ads, updates, and geo lookups can leave the machine. Profile folders are not uploaded by a MaskWright API in the code we reviewed. I still test as if the work site can see the tab. That is the point of the checklist.

How I want you to leave this page

Run the six steps. Write down forks that name two APIs. Fix the story you meant. Relaunch once. Then open the authorized work.

If a public lab still has a red row that does not name a fork, close it. The job was the profile, not the badge.

FAQ

Is this a pass-the-lab recipe? No. It is leaks, geo, and coherence for a profile you already have a right to open.

Does a TCP connectivity check prove the proxy works? No. It does not prove HTTP or SOCKS5 auth succeeded.

Should I reseed if a checker looks sad? No. A seed is a decision to remain. Fix the story or leave the surface on host truth.