Not obtuse at all! It’s actually not so easy to describe what this is and it took us a while to come up with correct language, and understanding of how to express it even after we knew what it was and had built it: it took us some time to figure out how to communicate that.
To answer you: I believe these instrumentation/automation protocols/methods like Selenium/W3C WebDriver Protocol/Remote Debugger Protocol, do not themselves provide user interfaces for controlling their functions, but rather expose APIs.
BrowserBox itself uses such a protocol under the hood, but also provides a user interface (that funnily enough looks like a regular browser~~because I wasn’t creative enough to invent a better set of UX interactions/affordances than those already expressed in regular web browser, heh :)).
In effect, BrowserBox turns the browser experience into a client server application. And BrowserBox is to those instrumentation/automation APIs, as a front end Client is to a Web application API.
That’s a slight simplification because BrowserBox contains a significant server component, however, it’s a useful way to think about it.
