Cette page n’existe pas encore dans votre langue. Vous lisez le texte anglais.
Glossary
WebGPU fingerprint
A WebGPU fingerprint is an identifier a site builds from what the newer graphics interface reports and renders.
How a site takes it
Nothing appears on the page and no permission is asked. The work happens on a texture that is never shown and leaves the interface as plain numbers.
- 1
Asks for a device
The interface hands over an adapter and a device, and reports what that device is able to do.
- 2
Renders into a texture
A flat fill is enough. The frame is produced by the same hardware WebGL draws with.
- 3
Copies the texture into a buffer
The page maps that buffer as an array of bytes, and those bytes are the snapshot.
Why it needs its own work
The older road ends at a canvas and this one ends at a buffer. Work applied where pixels are handed to a canvas never reaches bytes handed over as an array.
That gap is enough for a page to hold a contradiction. One machine described two ways, with only one of the descriptions covered, is a stronger reading than either description alone. The page picks which road to take, and it picks after the build has shipped.
What our engine does
The snapshot is altered where the image reaches the page, and the alteration follows the profile seed. One profile therefore answers the same way twice, and two profiles do not answer alike.
Only buffers that carried an image are touched. A buffer used for ordinary computation comes back exactly as the device produced it, because spoiling a result would break the page rather than protect it. The buffer remembers which part of it a picture was copied into, and a later write over that part clears the mark for exactly the bytes it covered.
How the build is measured
The run takes its own snapshot through the interface and reads it back several ways. Each line reports its own value rather than a verdict, and one red line is enough to stop a build.
Two snapshots agree
The same picture taken twice has to come back identical. A value that moves between two reads is itself the reading a page is looking for.
The snapshot is not the clean fill
A flat fill has to come back changed. Unchanged bytes mean the road is open and the work is not reaching it.
Reading in pieces changes nothing
The interface lets a page map one buffer in adjacent windows. Bytes taken that way have to be altered too and have to match the bytes taken whole.
A line that cannot be measured fails
On a machine with no graphics device the browser switches the interface off. The run then reports the line as not measured and the build is not accepted.
Often confused with
WebGL fingerprint
The older interface reaches the same hardware through its own calls. A build can cover one road and leave the other one answering.
Canvas fingerprint
That surface is drawn in two dimensions by the browser itself. Different code, different values and a separate defence.
The adapter description
What the adapter says about itself arrives from its own call, not from the image it renders. Our work covers the image.
What this does not do
- It does not change what the adapter says about itself. That description comes from its own call and is not derived from the profile seed.
- It does not touch ordinary computation. Buffers that never carried an image come back exactly as the device produced them, because a wrong number there breaks the page.
- It does not appear as a line in the self-test inside a profile. This road is measured when a build is accepted rather than on every launch, so the report you see in the app does not carry it.
- It does not undo a link that already exists. Two accounts opened from one profile stay linked whatever the graphics answer afterwards.
Check it
Everything above comes from a file you can open.
- Where the snapshot road is covered
- engine/patches/armanos-fp-0013-webgpu.diff
- What the run requires of a build
- engine/scripts/engine-invariants.js
- A build is not accepted until these hold
- engine/scripts/accept-engine.js
- The measurement itself runs in a real browser
- apps/desktop/test/обмеры-исполняются-в-браузере.js
Questions
- Is WebGPU just a newer WebGL?
- For a page that wants your hardware it is a second road to the same answer. The calls differ, the read path differs, and the reading has to be covered on its own.
- Does work on the canvas cover this?
- No. Canvas work applies where pixels are handed to a canvas, and this snapshot leaves as an array of bytes read out of a buffer.
- Can I just switch WebGPU off?
- A browser without it exists, and on a machine with no graphics device the browser switches it off by itself. Absence next to a claim of a current build is a contradiction a page can read.
- Why not alter every buffer?
- Because most buffers carry computation rather than pictures. Changing those numbers would break what the page is doing and protect nothing at all.
- What happens when the run gets no device?
- The line is reported as not measured and the build is not accepted. A quiet pass there would sell an unmeasured road as a verified one.
See what the engine answers
The engine page lists every surface the build covers and names the run that has to pass before it ships.