Trang này chưa có bằng ngôn ngữ của bạn. Bạn đang đọc bản tiếng Anh.
Glossary
Stealth plugin
A stealth plugin is an add-on for an automation framework that rewrites browser values in the page to hide a script.
What it changes and when
It is loaded as a script that runs before the site's own and overwrites values the engine has already decided. The list it goes through is short and widely known, which is part of the problem.
The automation reading
The value that says a script is at the controls is set back to false.
The plugin list and the languages
Empty arrays are filled with the values a plain browser would carry.
The graphics strings
Vendor and renderer are answered from a table rather than from a driver.
The browser object
Fields an ordinary build carries are added back so that their absence is not noticed.
Why the patch reads as a patch
A replaced function is a new function, and several ordinary reads say so out loud.
The source prints
Asking a function for its own text returns the replacement instead of the native marker.
The name and the arity differ
A built-in carries a fixed name and argument count, and a hand written stand-in rarely copies both.
The shape of the property changes
A value that was a getter on a prototype becomes an ordinary field on the object.
A fresh realm is untouched
A new frame or a worker starts a clean world, and a page reads the original values there.
Your browser right now
These four are the values such an add-on usually rewrites, read here in your own browser.
The plugin row is a count rather than a list, because the count alone is already a signal.
Máy của bạn, ngay lúc này
- Automation reading
- đang đo trên máy của bạn
- Plugins reported
- đang đo trên máy của bạn
- Graphics vendor
- đang đo trên máy của bạn
- Graphics renderer
- đang đo trên máy của bạn
Được đọc trong trình duyệt của bạn và hiển thị tại đây. Không có gì được gửi đi.
Where our answers come from
The values a profile reports are set inside the engine from a seed handed to it on the launch line. They are in place before any script on the page runs, and they come out of that one seed together, so the parts agree with one another.
So there is no second answer for a page to compare against the first. A fresh frame or a worker opens with the same values as the window above it, and those values read as ordinary native code.
What still runs in the page
One layer does run in the page here, and the identity is not its job. It holds back the request a tracker fires as you leave a page and the read receipt a chat sends back.
Each build also declares which of these surfaces it answers itself, and a surface it does not answer is covered from the page until a build does. On the engine shipping today nothing of the identity is left to the page.
| Where it is answered | What lives there |
|---|---|
| Inside the engine | The line, the fields beside it, the screen, the card, the fonts, the clock |
| In the page | Tracker beacons on unload and chat read receipts |
| Reported back to the app | A count, over a name drawn fresh at every launch |
Often confused with
An antidetect browser
A whole browser built to answer as one machine, rather than a page script correcting one after the fact.
A browser extension
Something you install for yourself, which a site can often notice by what it changes on the page.
Headless mode
A browser with no window, which is a separate tell from anything a patch rewrites.
What this does not do
- The app ships no add-on of this kind for a framework, and none is needed here. Puppeteer and Playwright connect to a profile that is already running, and the answers stay the engine's.
- It does not hide the rhythm of a script. Even pauses, identical paths and a session that never hesitates are read long after the values are settled.
- It does not cover a browser the app did not start. Your everyday browser answers for itself, and the panel above is reading exactly that.
- It does not undo a link that already exists. Two accounts opened from one profile stay linked whatever a script rewrites afterwards.
Check it
Everything above comes from a file you can open.
- Where the identity is decided
- apps/desktop/src/lib/forkEngine.js · engine/приёмка-отчёт.json
- What the build applies to the engine
- engine/patches/series · engine/patches/armanos-fp.cumulative.diff
- What the page half touches and what it leaves alone
- apps/desktop/src/lib/дыры-страницы.js · apps/desktop/test/дыры-движка-закрыты.js
- The in-page half never names the product
- apps/desktop/src/lib/cdp.js · apps/desktop/test/fork-extension-stealth.js
Questions
- Do I need one with a profile here?
- No. The values come from the engine before your script connects, and attaching a framework does not change any of them.
- Why is patching in the page weaker?
- Because it happens after the engine has answered and in a place the page can inspect. Both the original and the replacement are within reach of the same site.
- Does anything of yours run in the page?
- Yes, and it is worth naming: a small layer for tracker beacons and read receipts. Which surfaces it touches depends on what the engine already answers, and on the engine shipping today the identity is none of them.
- Can I still drive a profile with Puppeteer or Playwright?
- Yes, through the profile's own automation address while it is open. The app's own driving never turns on the reading channel a page can watch, and a framework turns it on as a matter of course.
- Does an open automation channel give a profile away?
- The reading that would say so is answered false, and the acceptance run reads that value from a real page on the real engine.
Next to this
Drive a profile without a patch
A profile answers from the engine, and your framework connects to it over its own address while it is open.