Glossary
Chrome DevTools Protocol
Chrome DevTools Protocol is the channel a program uses to drive a Chromium browser and read back what it shows.
What the channel carries
A command goes in and an answer comes back over a single socket. Navigation, clicks, typing, cookies, screenshots and page script all travel the same way.
- 1
One socket per running browser
The browser publishes its own address once it has started listening, and a driver reads it from there.
- 2
Commands are grouped by area
Each area covers one part of the browser and every command names the area it belongs to.
- 3
Streams are asked for
A driver receives events only after it switches an area on, and switching one on changes the browser.
Your browser right now
These are read in the browser you are reading this in. The automation flag is the first line of almost every bot check.
Your machine, right now
- Automation flag
- measuring on your machine
- User agent
- measuring on your machine
- Platform
- measuring on your machine
Read in your browser and shown here. Nothing is sent anywhere.
The port is the part that costs you
An open debugging port asks for no password. Anything running on the same machine under the same account can drive the browser through it.
An application wide address reaches everything
One endpoint for the whole program means a driver can steer the manager window and not only a profile.
It opens only where it is needed
The main engine gives every profile its own entry point, so the application wide port stays shut.
It lives only while a window does
The entry point goes away with the profile it belongs to, and an address kept from an earlier run points at nothing.
The area a page can notice stays off
Switching on the script area makes the browser install hooks that page script can notice. Several well known bot checks do nothing but look for those.
That area is never switched on here. The other two come up only for the work that needs them and leave nothing a page can read.
Script runs with the area off
Evaluating script, navigating and sending input all work without switching anything on.
Readiness is asked for by hand
The page is asked about its own loading state instead of subscribing to a stream of lifecycle events.
Only one of the two goes down again
The lifecycle area is switched off as soon as the capture ends. The request area comes up with the first wait step and stays up until the profile closes.
The automation flag
Opening a debugging port makes Chromium report that the browser is being automated, and that single value ends a check before the fingerprint is looked at.
A launch switch clears it, and the value is read back from a real page in the real engine rather than assumed.
Often confused with
WebDriver
A different protocol with a server of its own, and a browser driven through it says so in the same flag.
An extension
An extension lives inside the page world and reaches only what the browser hands it.
A local interface
The local interface is the door opened for your own scripts. This protocol is the channel behind that door.
What this does not do
- It does not authenticate anyone. The channel trusts whoever reaches it, which is why the address never leaves this machine and belongs to one profile.
- It does not hide how a script behaves. Timing, the path of a pointer and the order of actions are read separately, and they give away automation on their own.
- It does not give the built in engine an entry point per profile. There one address serves the whole program, and the answer to a launch says so instead of pretending otherwise.
- It does not outlive the window. Close the profile and the address is gone, so a driver has to take a fresh one at every start.
Check it
Each line above is a file you can open and a stand that keeps it honest.
- The client and the area that is never switched on
- apps/desktop/src/lib/cdp.js
- The application wide port opens only for the engine that needs it
- apps/desktop/test/cdp-port-only-when-needed.js
- The automation flag is read from a real page in the real engine
- apps/desktop/test/webdriver-flag.js
- Where a profile publishes its address and where two areas come up
- apps/desktop/src/lib/forkPage.js
Questions
- Do I have to install anything to use it?
- No. The browser already speaks it, and starting a profile is what opens the entry point and hands back its address.
- Can a site see that my profile is being driven?
- Not from the channel itself while no observable area is switched on and the automation flag stays clear. What your script does with the mouse is a separate signal.
- Is the port open the whole time?
- No. It belongs to the profile window and exists for exactly as long as that window does.
- Can another program on my computer reach it?
- Anything running under your account and able to reach that address can. That is why it is never published beyond the machine itself.
- What uses it here?
- Flows, the synchronizer and your own scripts through the local interface. All three go through one client, so there is one place where the rules above hold.
Next to this
Local API
The door your scripts knock on, and what a start answers with.
Flow builder
Flows that drive a profile through this same channel.
For developers
Driving profiles from your own code, and what stays false while you do.
Build flags
The settings that decide what the engine behind the channel contains.
Drive a profile from your own script
Start a profile through the local interface and it answers with the address for that profile alone.