Why is leaving capture on for a hosted browser suite a retention decision?

## A recording is a copy, not a view When a browser session is recorded, nothing about the recording is temporary. The session ends, the container or the device is reclaimed, the slot is freed — and a file remains, sitting on storage belonging to whoever runs the fleet. On a rented fleet that is the provider. So the setting somebody flips when they "turn video on" is not a diagnostics setting with a storage side effect. It is the thing that decides **how much material comes into existence on a machine you do not own**. That is why capture belongs in a conversation about retention at all. Retention is usually discussed as a period: how long something is kept. The other half of retention is volume: how much there is to keep. Volume is settled at capture, before any period applies to it. ## Record everything, or record when asked Fleets differ in which way round the default sits, and the difference is the whole shape of the problem: - **Record on request** — material exists only for the runs that asked for it, so the store stays close to what somebody actually intended to look at. - **Record everything** — material exists for every run, including the many green ones nobody will open. The store grows at the rate the suite runs. - **Record without being asked** — a hosted provider may simply record, as part of what it sells. Then there is no switch on your side, and the volume is decided for you. A nightly mortgage pre-approval suite is a useful case to hold in mind, because it is neither small nor interesting. Most of its runs pass. Under record-everything, each of those passing runs deposits a video of a questionnaire being filled in with applicant-shaped values — name, income, employment, existing obligations — and a log describing the same journey. Nobody watches them. They accumulate anyway. ## The gap between captured and consulted This is where the reasoning usually goes wrong. Teams think about evidence in terms of the failures they investigated, which is a handful of runs. The store grows in terms of the runs that happened, which is every run of every branch by everyone. Those two quantities diverge immediately, and the second is the one the provider is holding on your behalf. The practical consequence is that a team can be scrupulous about what it looks at and still be careless about what exists. Little in a code review shows the size of that store, a test report rarely links to the runs nobody opened, and nothing fails when it grows. ## The switch may not be yours The comfortable version of this topic is "turn capture off for the runs that do not need it". Sometimes you can. Sometimes you cannot: a hosted provider can record a session without being asked to, because the recording is part of the product rather than a favour to your harness. That possibility is precisely why the keeping period has to be **established for your account** rather than inferred from how your harness is wired. If you did not ask for the recording, you also did not choose how long it stays. Two things follow that are worth saying out loud: 1. **Configuration in your repository is not evidence about the far side.** A harness that never requests video proves only that your harness never requests video. 2. **The absence of a switch is a finding, not a dead end.** It moves the control from "capture less" to "run less of that suite there" and "agree what is kept" — slower, more deliberate levers than a flag, and ones a lead has to own. ## What is early, and therefore genuinely yours - **Whether that particular suite runs on rented infrastructure at all** — the bluntest control, and the earliest. - **Whether capture is requested**, wherever requesting is the mechanism rather than the default. - **Whether material is pulled back into storage you control**, which transfers the keeping period to you rather than shortening it. - **Whether deletion is routine**, so the passing runs' material does not sit waiting for somebody to notice it. None of those is a retention policy. They are the inputs a policy would act on, and, unlike the policy, they are parts of the system that respond to a pull request. ## Two mistakes that sound reasonable - *"It only records failures anyway."* That is a property of some configurations, not a law, and defaults move under you without a release of yours. - *"Nobody ever looks at them, so it does not matter."* Unread material is still held material. The exposure is in its existence, not in anyone's attention. ## Saying it well in an interview Frame capture as the volume half of retention. Say that a recording is a durable copy on infrastructure you do not administer; that recording everything versus recording on request decides how much of that copy exists; that the switch may not be yours, because a provider can record unasked; and that the levers which remain yours sit before the run and after the retrieval, not in the middle. Then stop, rather than guessing at what any particular supplier does.