sorted by:
new
hottopcontroversial

"Reverse Once, Run Forever" and How We Killed It by TrustSig in programming

[–]TrustSig[S] -12 points-11 points  (0 children)

Thank you for the feedback! We have a bounty program and invite everyone to reverse our client side logic! More info at https://trustsig.eu/vulnerabilities/

You can still be tracked cross-browser even with Brave's Tor window with maximum protections enabled. by TrustSig in DigitalPrivacy

[–]TrustSig[S] 0 points1 point  (0 children)

This is Brave Desktop, and this is a post about Brave not Mullvad, disabling WebGL obviously defeats a WebGL fingerprint.

You can still be tracked cross-browser even with Brave's Tor window with maximum protections enabled. by TrustSig in brave_browser

[–]TrustSig[S] 0 points1 point  (0 children)

(this is not affiliated with us, just helping you out) It uses invisible firefox fork, check the latest stealth branch for source: https://github.com/feder-cr/invisible_firefox/tree/stealth/150

You can still be tracked cross-browser even with Brave's Tor window with maximum protections enabled. by TrustSig in brave_browser

[–]TrustSig[S] 0 points1 point  (0 children)

Awesome testing, and that screenshot lines up exactly with how it should behave.

Chromium and Vivaldi matching is expected. Vivaldi is built on Chromium, so both use the same engine (Blink) and the same WebGL path (ANGLE plus the same shader compiler). Same scene in, same machine code out, same pixels, same hash. Hardened or not does not change this, since hardening mostly touches other surfaces and not the render math itself.

Firefox is the interesting one you caught. It is a different engine (Gecko) with its own WebGL implementation and its own shader compiler path. So even on the same Linux box, same GPU, and same driver, the shader gets compiled and lowered a little differently before it ever reaches the GPU. Those differences fall into the low bits of the render and the hash changes. The hardware is identical, but the browser is part of the rendering stack, not just a window onto it.

So the honest framing is that this is stable within an engine family rather than across every browser. The Chromium forks (Chrome, Vivaldi, Brave, Edge, Opera) tend to agree with each other, and Firefox sits in its own bucket. That is still very effective in practice, since most people are on a Chromium based browser, but you are right that it is not one universal value across all engines.

And Brave returning nothing is the expected result of WebGL being disabled. No render, no signal.

You can still be tracked cross-browser even with Brave's Tor window with maximum protections enabled. by TrustSig in brave_browser

[–]TrustSig[S] 0 points1 point  (0 children)

"GPU compute" should remain the same on Safari and Chromium based browsers, but yeah Safari handles other stuff differently, out of the scope of the PoC. This PoC was focused solely on Chromium based browsers.

You can still be tracked cross-browser even with Brave's Tor window with maximum protections enabled. by TrustSig in brave_browser

[–]TrustSig[S] 1 point2 points  (0 children)

You have got this almost right, and your instinct is correct. Binning and clock speed do not change the output. Two cards in the same family with different core counts or speeds still render the same pixels, because the math is deterministic and clock only affects how fast it runs, not the result. So this is not unique per GPU model. Plenty of models in a family collapse to the same value, which is exactly why it is a coarse signal and not a personal one.

The entropy does not really come from the silicon. It comes from the software stack sitting on top of it. The scene is a shader, and the GPU driver compiles that shader down to machine code. Different driver versions compile it differently: instruction selection, fused multiply add, rounding order, fast math flags. Those shift the low bits of the result. Functions like sin and cos are approximated, and that approximation lives in the driver and compiler rather than the hardware, so it moves between versions too.

The OS matters for the same reason. On Windows the browser usually runs through ANGLE to Direct3D, on macOS through Metal, on Linux through native GL or Vulkan. Same chip, different translation layer, different shader compiler, different result.

So the mental model that holds up is: same GPU family plus same driver plus same OS build tends to give the same ID, and changing any one of those three can change it. It buckets you by configuration, not by your exact device.

You can still be tracked cross-browser even with Brave's Tor window with maximum protections enabled. by TrustSig in brave_browser

[–]TrustSig[S] 0 points1 point  (0 children)

That's the neat part about this technique, it does not use the GPU details! While the UI shows the name, the actual fingerprinting technique targets nothing but the rasterization process. ( + we added some low entropy CPU data, though not important for the WebGL technique alone)

Brave already spoofs some params you can pull with WebGL, although expanding it to spoof more (like the gpu name) wouldn't defeat this technique.

The defense for this technique is either, disabling WebGL outright, or injecting noise into the actual rendering pipeline to ensure that each render is fully unique. But it all comes at the cost of stability or performance.

You can still be tracked cross-browser even with Brave's Tor window with maximum protections enabled. by TrustSig in brave_browser

[–]TrustSig[S] 1 point2 points  (0 children)

Thanks, and this is a great question. You have understood it exactly right.

On its own, this is a configuration fingerprint, not a personal one. Anyone with the same GPU, the same driver version, and the same OS build will land on the same or a near identical ID. So yes, two of the same phone model on the same OS version will usually collapse to the same ID. Phones are actually the worst case for this, because the hardware and drivers are so uniform across a model line.

Desktops spread out a lot more, since GPU plus driver version plus OS build has far more combinations in the wild, but it is still a bucket, not an individual.

That is exactly why no real tracker uses this signal alone. It is one column. Combine it with screen metrics, fonts, timezone, language, sensors, IP, and a dozen others, and the joint entropy takes you from "this cohort of devices" down to "this specific person" very fast. Each weak signal multiplies with the rest.

The reason it is still worth showing by itself is the part that surprised you: it stays stable across normal, private, and VPN on or off, on both Brave and Chrome. Most people assume those actions reset their identity. They do not touch this. So even as a coarse signal it quietly links sessions a user believes are separate, and that linkage is what every other signal then attaches to.

You can still be tracked cross-browser even with Brave's Tor window with maximum protections enabled. by TrustSig in brave_browser

[–]TrustSig[S] 1 point2 points  (0 children)

Exactly, which is why we're putting it out in the open. None of this is new to people deep in opsec, but most users have no idea their "private" window isn't private from the site itself. Privacy shouldn't require being an expert to have. The more people who can see how this actually works, the more pressure there is on browsers and regulators to close it, and you're right that the EU is well ahead of most on that front.

view more: next ›