Tej strony nie ma jeszcze w Twoim języku. Czytasz tekst angielski.
Glossary
Worker realm leak
A worker realm leak is a difference in the fingerprint between a page and a background thread that the page started.
What a worker is
A worker is a thread a page starts for work that would otherwise freeze the window. It has no page, no screen and no access to what you see.
It does have a navigator, and that navigator answers for the processor count, the platform, the languages and the memory.
How a site takes it
Three lines of script are enough, and the reply arrives as plain data through a message rather than as anything the page has to parse.
- 1
Builds the worker in memory
The code for it is assembled as text and started without ever being fetched from an address.
- 2
Asks for the same names
Cores and platform first, because those are the two that move when a fingerprint is being rewritten.
- 3
Holds the reply against the page
One machine answers once. Two answers describe a browser rather than a computer.
Your page right now
These four are read in the document of this page, and nothing about them leaves your browser.
A worker started here would be handed the same four names, and its reply compared with what you see.
Twoje urządzenie, w tej chwili
- Logical processors
- pomiar na Twoim urządzeniu
- Platform
- pomiar na Twoim urządzeniu
- Languages
- pomiar na Twoim urządzeniu
- Device memory
- pomiar na Twoim urządzeniu
Odczytane w Twojej przeglądarce i pokazane tutaj. Nic nie jest nigdzie wysyłane.
Why a worker is hard to cover
A worker's code can live at an address of its own, and page script cannot rewrite what the browser fetches from there.
So a defence written inside the page covers the workers it can see and misses the rest, and half of them is worse than none of them.
Half covered is a proof
A site that gets profile values from one worker and machine values from another holds evidence of tampering rather than a browser to measure.
There is nothing to install into
Tricks that place values on the page have no page here. A worker has no document and no window of its own.
The answer never passes through the page
Values come back through a message as copied data, so nothing in the page sees them on the way.
Where the values come from
On our engine the page navigator and the worker navigator sit on one common base, and the profile values are answered there.
The seed arrives on the launch line before any code runs, so every thread of the browser reads the same values without being told to.
Inherited rather than copied
Nothing has to travel from the page into the thread, so there is no moment when one of them is already changed and the other is not.
A second worker changes nothing
Ten threads answer the way one thread does, because none of them is answering for itself.
The self-test asks a real one
Inside a profile the fingerprint self-test starts a worker and compares its reply with the document.
Often confused with
Iframe realm leak
A frame is the other realm on the same page. It is reached differently and it carries a screen and a document.
Service worker
That one outlives the tab and deals with requests and stored replies. It is a storage question rather than a fingerprint one.
Hardware concurrency
The value a worker is asked for most often, and a term with a page of its own.
What this does not do
- It is not covered on the built-in engine. That realm is left answering for the machine on purpose, because reaching some of the ways a worker can be started and not the others would hand a site the proof instead of the values.
- It does not give a worker values of its own. One profile is one machine, and a thread that disagrees with its page is exactly what is being looked for.
- It does not stop a site from starting workers. They are ordinary parts of ordinary pages, and a browser without them would be the stranger sight.
- It does not settle anything outside the fingerprint. Behaviour and address reputation close more accounts than every realm on this page put together.
Check it
Every claim above comes from a file you can open.
- The worker check the self-test runs
- apps/desktop/src/lib/fpAudit.js
- What the shipping build answered in the thread and in the document
- engine/приёмка-отчёт.json
- One common base under both navigators
- engine/patches/armanos-fp.cumulative.diff
- Where the limit of the built-in engine is written down
- apps/desktop/src/injected/fingerprint.js
Questions
- Can a site start a worker without telling me?
- Yes. No permission is asked and nothing appears on the page, and most sites you use already start several for ordinary work.
- Does a worker see my cookies?
- Not the way a page does. It is asked about the machine here, and that is a different question from what is stored for the site.
- Why not just answer in the page and be done?
- Because the worker is a separate world that never reads the page. Whatever is changed there is simply not present when the thread starts.
- Would turning workers off help?
- It would make the browser rarer than any value inside it. A page that starts a worker and gets nothing back knows something is wrong with the browser.
- How do I see mine?
- The self-test inside a profile starts a worker and compares it with the page. It is one of the 29 measurements that run there.
See what a thread answers in your profile
The fingerprint self-test runs inside a profile and shows all 29 measurements, green and red alike.