本頁面暫無您所用語言的版本，您正在閱讀英文原文。
Glossary
V8 JavaScript engine
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.
此刻您的裝置
- Timezone
- 正在您的裝置上測量
- Offset in hours
- 正在您的裝置上測量
- Language
- 正在您的裝置上測量
- Device memory
- 正在您的裝置上測量
在您的瀏覽器中讀取並在此顯示，不會傳送到任何地方。
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.
See the memory numbers your profile reports
The self-test runs inside a profile and shows all 29 readings, green and red alike.