detection: fingerprint.com

[shockme]

Reproduction

https://fingerprint.com/

Observed vs expected

Fortress is detected on my residential IP

vs. Brave, on the same IP:

On each page goto/reload, I see:

ERROR:services/network/p2p/socket_manager.cc:139] Failed to resolve address for use1-turn.fpjs.io., errorcode: -105

in the container logs. I assume that's responsible for the VPN detected message. Using the python interpreter in the container I confirmed that use1-turn.fpjs.io is correctly resolved in the container.

Docker image info:

REPOSITORY                                           TAG            IMAGE ID
tilion/fortress                                      latest         b66d1cc6fa65

How you launched Fortress

docker run -p 9222:9222 tilion/fortress

Host OS and egress

Ubuntu 22.04 Residential IP

Confirm

• I verified this reproduces on a non-datacenter IP (or IP is not the factor here).

[arham766]

Thanks for the report - working on it. I'll update here once the fix is live.

[shockme]

Thanks for the quick reply! FYI, I was testing the fix and even after pulling the new image and setting the timezone, the only thing that changed was that VPN score decreased from 37 → 34.

[arham766]

Fixed and live now — pull tilion/fortress:latest (or :151).

Root cause: the default persona was picking a random-country timezone/locale that didn't match your egress IP. Anti-bot VPN detectors compare the browser's timezone against the IP's geolocation, so a mismatch reads as "VPN" even on a clean residential IP. (The use1-turn.fpjs.io WebRTC log line turned out to be a red herring — stock Chrome logs the same -105 on IPv4-only STUN/TURN hosts and isn't flagged.)

The fix: the container now geo-matches the persona's timezone/country to your egress IP automatically, so the clock lines up with the network. If you route through a proxy, pin it to your exit region instead:

docker run -p 9222:9222 tilion/fortress --uxr-country=US --uxr-timezone=America/New_York

Give it a fresh pull and let me know if fingerprint.com still flags VPN on your residential IP. Thanks again for the report 🙏

[shockme]

Unfortunately, even after pulling latest and setting --uxr-country and --uxr-timezone it still flags it as "VPN detection", "Tampering detection" and "Virtual machine detection"; total score 34. The browser is identified as "Chromium-Based Browser Not Available".

[shockme]

Trying to debug this, I'm running
TILION_NO_DEFAULTS=1 ~/Apps/tillion-fortress/tillion --remote-debugging-port=9222 --user-data-dir=/tmp/p --uxr-platform="Linux x86_64" --uxr-ua-platform=Linux --uxr-ua-os="X11; Linux" --uxr-ua-platform-version="150.0.0" --uxr-ua-brand="Google Chrome"
and fingerprint.com reports
"user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/149.0.0.0 Safari/537.36".
Something is off.

[shockme]

Also, the startup script uses TILLION_* vars, not TILION_* as the README specifies. Note the double L.

[arham766]

Fixed in the latest release - pull tilion/fortress:latest, or pip install -U tilion-fortress.

Two bugs were in play:

1. The launcher checked TILLION_NO_DEFAULTS (two L), not TILION_ as the README says, so your TILION_NO_DEFAULTS=1 was ignored and the default Windows persona was still injected.
2. Explicit --uxr-ua-os / --uxr-ua-platform were being overwritten by the generated persona, so the UA string stayed Windows even with your Linux flags. That UA-vs-platform mismatch is what read as tampering.

Both are fixed. --uxr-ua-os="X11; Linux x86_64" now produces a coherent Linux persona across the UA string, Sec-CH-UA-Platform and navigator.platform (verified on the published image).

The VM and VPN flags are environmental - VM/container detection and IP reputation - not something the browser can spoof away. Also worth noting: a Linux desktop persona is rarer than the default Windows one, so unless you specifically need Linux, leaving the platform default is stealthier.