A hosted browser provider's account key starts sessions — what else does it open?
answer
- the key names an account
- more doors than the one used
- console, history, artefacts, capacity
- evidence from runs you never started
- packaging, so measure it yourself
basics
~20 sAn account key at a hosted browser provider is scoped to the account, not the run, so treat the console, the run history, the recordings and logs those runs left, and the capacity as surfaces to measure.
solid answer
~50 sTreat a browser-cloud credential as a key to a **workspace**, not to a run. The same value that opens a session commonly also reaches the provider's own web surface, the history of runs other people on the account started, the recordings and logs those runs produced, and the capacity the account is entitled to spend. How much it reaches is a packaging decision rather than a property of the mechanism, and the open analogues bracket the range. Selenoid UI, unmaintained by its own README, wraps its whole route table in a single htpasswd check when it is given a users file and applies no authentication at all when it is not. Ggr (unmaintained) puts session creation and its `/video/`, `/logs/` and `/download/` paths behind the same authenticator. So enumerate what your own key reaches by trying it, and keep that list beside the credential.
go deeper
Be ready to say, without hesitating, that the credential identifies an account rather than a run, and to name a couple of surfaces beyond session creation that it is likely to open.
Expect to be asked how you would list what your own key reaches. Describe trying each surface from a clean machine and writing down the result, rather than quoting a vendor description back at the interviewer.
You will be asked what follows from the width. Tie the credential's handling and storage to the widest surface it opens, and be prepared to say which surfaces you would ask the vendor to close.
Own the question of whether one credential per organisation is the right structure at all. Be ready to argue the trade between fewer secrets to manage and a smaller radius for each one.
## The credential is scoped to an account, never to a run A hosted browser provider issues a tenant a long-lived name-and-key pair, and that pair identifies an **account**. Nothing in the mechanism binds it to a suite, a branch, a pipeline or a person. When the document-review suite for a law firm's matter workspace opens a remote session, the provider is not deciding whether *this run* is allowed; it is deciding whether *this is the account*. Once that answer is yes, the caller reaches what that account reaches, unless a narrower credential was arranged and verified. So the useful interview question is never "can my key start a session" but "what is the complete list of things it reaches, and how did you find out". BrowserStack, Sauce Labs and LambdaTest are closed products: no source, schema or artefact settles that list from the outside, which makes the second half of the question the part that separates candidates. ## The surfaces one key commonly reaches - **Session creation** — the capability you actually meant to buy. - **The provider's own web surface** — including whatever account settings it lets the account change. - **A run history** — the record of sessions started on the account, not only the ones your pipeline started. - **Stored artefacts** — recordings, log files and downloaded files those runs left behind. - **A live view** — the screen of a session while that session is still open. - **Capacity and spend** — drawn from one account-level pool, so any holder of the key draws on it. - **Entitlement information** — what the account is permitted to ask for, which the account can usually read back. None of those is guaranteed and none is forbidden. The radius is a packaging choice somebody made, and the work is to measure it rather than assume it. ## The open analogues bracket the range A pair of unmaintained Aerokube projects implement the same shape in readable source, at opposite ends of it. | implementation | what a single credential covers | |---|---| | Selenoid UI (unmaintained) | the whole route table — the served console, the live event stream, the live-view socket, the video path and the WebDriver route — behind one htpasswd check, and **no check at all** when it is started without a users file | | Ggr (unmaintained) | session creation and its `/video/`, `/logs/` and `/download/` paths behind one authenticator — while the route carrying an existing session's later commands, the live-view socket and the developer-tools route sit behind **none**, and a guest mode makes some browsers reachable with no credential | Selenoid UI (unmaintained) installs its htpasswd provider only inside a conditional on the users setting, so started without one it authenticates nobody. Ggr (unmaintained) constructs an authenticator, wraps only part of its route table in it, and even there routes through a wrapper that honours a guest mode and a header-borne root token. Selenoid itself (unmaintained) wraps none of its own routes in an authenticator; it reads a basic-auth username only to label log lines. **"One key unlocks everything" is therefore a claim about packaging, not a law of remote grids** — and stated as a law it is an overstatement of a true model. ## What a tenant can observe, and what must be established You cannot assert what a closed provider's internal access model is: what its roles are called, what any given arrangement separates, what its web surface shows to whom. You can observe behaviour, and that is what to rely on. 1. Take a credential the account holds and, from a clean machine with nothing cached, try each surface in turn: start a session, open the web surface, list history, fetch an artefact belonging to a run this credential did not start. 2. Write down what succeeded. That written list, and not a brochure, is the credential's blast radius. 3. Ask the vendor in writing what separation is available between teams or pipelines, and whether a credential can be narrowed to a subset of the surfaces you found. 4. Re-run the check after any account change, because a radius can widen without anyone telling you. ## Why the width matters for a document-review suite A matter workspace is full of client material, and a suite that exercises it types realistic content into a real browser running on somebody else's hardware. If the account key reaches recordings, then the key reaches pictures of that content, and so does every other holder of the key. The conclusion is not "do not use a provider"; it is that a credential's value is set by the widest surface it opens and not by the narrowest thing your pipeline happens to use it for. - Handle and store the key according to the widest surface, not the intended one. - Keep the enumerated list beside the key, and review it when the account changes. - Until you have shown otherwise, assume an artefact is reachable by every holder of the key. - Separate what the key must reach from what it merely reaches, and ask the vendor to close the gap. The candidate who answers "it opens a session" has described the feature. The candidate who answers "it opens the account, and here is how I listed what that means for us" has described the risk.
- How would you actually find out what your provider credential reaches?Empirically, from a clean machine. Take a credential the account holds and try each surface in turn: create a session, open the provider's web surface, list run history, fetch an artefact belonging to a run that credential did not start, open a live view. Write down what succeeded. That list is the blast radius, and it is worth re-checking whenever the account changes, because the radius can widen quietly.
- Why is "one key unlocks everything" an overstatement rather than a rule?Because it describes how a product was packaged, not how remote grids must work. Selenoid UI, unmaintained by its own README, applies no authentication at all when it is started without a users file, and Ggr (unmaintained) ships a deliberate guest mode where some browsers are reachable with no credential. The width of what a credential opens is a configuration decision, which is exactly why it must be measured rather than assumed.
- Does a narrow intended use make a broad credential safer to handle?No. The value of a credential is set by the widest surface it opens, not by the narrowest thing your pipeline does with it. A key used only to start sessions but capable of reaching recordings and account settings is a recordings-and-settings key that happens to be used modestly. Handle it according to its reach, and ask the vendor whether a narrower credential is available.
saying these in an interview costs you the question
- Says the key only creates sessions
- Assumes the provider separates teams by default
- Claims one key always unlocks everything, as a rule
- Rates the key by what the suite uses, not what it reaches
- Treats the vendor's description as proof of what is reachable