Skip to content

Glossary

Chrome DevTools Protocol

Every automation tool built for this class of browser speaks it. How the channel is opened decides who else on your machine can use it and whether a page can tell it is there.

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. 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. 2

    Commands are grouped by area

    Each area covers one part of the browser and every command names the area it belongs to.

  3. 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.

Drive a profile from your own script

Start a profile through the local interface and it answers with the address for that profile alone.