V8 JavaScript engine

Every fingerprinting check you have read about is JavaScript, and this is what executes it. A few numbers it keeps about its own memory reach the page, and they have to agree with the machine a profile claims.

V8 is the JavaScript engine inside Chromium, and it runs every script a site uses to ask about your machine.

What the JavaScript engine does

V8 compiles and runs the script on a page and the WebAssembly a page brings with it. It also owns the heap those scripts allocate in and the collector that cleans it.

Two pieces of it are visible to a fingerprint. The internationalisation part answers about zone and locale, and one memory number is exposed to the page directly.

Compile and run
Script and WebAssembly arrive here, so a check written in either lands in the same place.
The heap and its collector
Objects a page makes live in a heap whose ceiling comes from how much memory the machine has.
Zone and locale formatting
Dates, numbers and the resolved timezone a page reads are formatted by this engine.

The zone and the language right now

The zone and the language below are formatted by this engine in the browser you are reading in. The memory line is the number its heap ceiling has to agree with.

Perangkat Anda, saat ini

Timezone: mengukur di perangkat Anda
Offset in hours: mengukur di perangkat Anda
Language: mengukur di perangkat Anda
Device memory: mengukur di perangkat Anda

Dibaca di peramban Anda dan ditampilkan di sini. Tidak ada yang dikirim ke mana pun.

One heap ceiling a page can read

A page may ask for the ceiling of the script heap. That ceiling is derived from the physical memory of the machine, which makes it a reading about hardware rather than about script.

So it has to agree with the memory a profile declares. A profile claiming one amount while reporting a ceiling sized for another is a mismatch a single line of script finds.

Derived from physical memory
The old generation is a fixed fraction of what the machine has, held between a floor and a ceiling.
Two lawful shapes
It comes exact when the process is locked to one site and rounded to a step otherwise.
Phones and desktops differ
The fraction is not the same on a phone, so a mobile profile is computed by the mobile rule.

What our patch set leaves alone

The build applies its patches in a fixed order, and together they name every file they touch. Not one of those files belongs to the JavaScript engine, so script runs exactly as it does in a plain build.

That is a decision and not an omission. Altering how arithmetic rounds or how time is measured would be a difference no real machine has.

Where the heap ceiling is corrected

The profile's number is computed in the app by the engine's own rule, taken from the sources of this tree, and travels with the rest of the seed.

The correction is applied where the page reads the value and nowhere else. When the declared memory already agrees with the real one, the value is left untouched.

1
The app computes the number
It follows the rule the engine uses, including the floor and the ceiling it clamps to.
2
The seed carries it at launch
It rides with the device story, so it cannot drift from the memory the profile declares.
3
The reading is adjusted once
Only the part that comes from the machine is replaced, and the rest of the number stays.

Often confused with

JavaScript
The language itself. This is one implementation of it, and implementations differ in rounding and error text.
Blink
The rendering engine beside it. That one answers the names a script asks for, this one runs the script.
WebAssembly
A second form this engine executes. It arrives compiled, and a check written in it reaches the same place.

What this does not do

We change nothing about how a script executes. No jitter added to timing, no altered arithmetic, no slowed down loops.
It does not hide that a script is running. A page can time its own code and count its own work, and nothing here touches that.
The heap ceiling is aligned with the profile and nothing more. It reserves no memory and does not change how much a profile may use.
It has no opinion about the address you arrive from or about the history of the account you sign into.

Check it

Each line above is a file you can open.

The heap rule taken from the sources of this tree: packages/shared/src/index.js
The correction lands where the page reads the value: engine/patches/armanos-fp-0014-memory.diff
The self-test measures the ceiling in a real browser: apps/desktop/src/lib/fpAudit.js · apps/desktop/test/fp-audit.js
Every patch the build applies and its place in line: engine/patches/series

Questions

Is V8 the same thing as JavaScript?: No. JavaScript is the language, and this is one engine that implements it. Other browsers ship other implementations of the same language.
Does the antidetect work happen in the JavaScript engine?: No. Every file our build patches belongs to the rendering engine and the two layers above it, and the patches themselves are open for you to read.
Can a page read how much memory my computer has?: It can read a ceiling for the script heap, which is derived from physical memory. That is why the number has to match the memory a profile declares.
Does it run WebAssembly as well?: Yes. Both forms arrive at the same engine, so moving a check into WebAssembly changes nothing about where it lands.
Should a browser fake how fast it runs?: No. Speed that does not match the rest of the machine is a signal of its own, and a page can measure it in a loop that costs nothing.

Next to this

See the memory numbers your profile reports

The self-test runs inside a profile and shows all 29 readings, green and red alike.

Download ARMANOS Our browser engine