You ask a hosted browser provider to delete a run's recordings — what can you actually verify?

## What "delete" means across a boundary you do not administer On a machine you run, deletion is an instruction: you issue it, the system carries it out, and you can inspect the result. On a machine somebody else runs, deletion is a **request**. Something happens in response, and you observe a consequence — but the mechanism, the copies it did or did not reach, and the record it left sit behind a boundary you cannot cross. That difference is not pedantry. It changes what you may honestly say afterwards. "We deleted the recordings" and "we asked for the recordings to be deleted and they are no longer retrievable" are different sentences, and only the second one is a claim you can support. ## What you can observe The observable surface is narrow but real, and it is worth using deliberately: - **The reference stops resolving.** Whatever identifier your report holds for the artefact no longer returns it. That is a genuine, repeatable check. - **It stops appearing where it was listed.** The run's material is absent from the account's own view of its history. - **The check can be automated.** Re-requesting a reference and asserting the failure turns a one-off reassurance into something a job can confirm on a schedule. That gives you evidence of **unreachability through your own access path**, which is a different and smaller claim than destruction. It is still the right check to build, because it is the one that would catch the case where nothing happened at all. ## What you cannot observe Everything the interface does not expose: - Copies held for the supplier's own operational purposes. - Backups and replicas taken before the request, and whatever schedule governs those. - Anything derived from the material rather than the material itself. - Whether the same content was reachable to anyone else in the interval before you asked. None of that is an accusation of bad faith; it is the ordinary consequence of running work on infrastructure you do not administer, and it is why the agreement is the part of this with force behind it. An undertaking you can point to beats an inference drawn from a page that stopped loading. ## The open contrast, where deletion really is a command It helps to see the same problem on a fleet that is fully yours. **Selenoid**, a self-hosted session-container grid that declares itself **unmaintained** in its own README, states in its video documentation that it intentionally has no built-in logic to automatically remove old video files. It hands the operator two ways to bound storage instead: a scheduled sweep of older files, and a removal request sent per file, which its documentation suggests issuing from passing test cases. | | fleet you operate | fleet you rent | |---|---|---| | deletion is | an instruction you execute | a request you make | | the evidence is | the file is gone from a disk you can inspect | a reference that stops resolving | | what expires by itself | whatever your sweep enforces, and nothing else | a period set on the supplier's side, which you must establish | | who is accountable | you, visibly | you, through an agreement | The second column is not worse in every respect: a supplier that expires material on a schedule is doing work you would otherwise do. Where it is clearly worse is verifiability, which is the respect this question turns on. ## Making deletion routine rather than exceptional The strongest move is to shrink what any deletion request has to cover, and to make removal part of ordinary operation: 1. **Delete on success.** Most of a nightly mortgage pre-approval suite's runs pass and nobody will ever open their recordings. Removing that material at teardown, while the run's identifiers are in hand, is cheap and needs no incident to trigger it. 2. **Keep failures deliberately, not by default.** What survives should be what somebody decided to keep, with a reason attached. 3. **Capture less in the first place.** Volume is settled before any period applies, so the cheapest deletion is the recording that never existed. 4. **Record what you could and could not confirm.** When you do make a removal request, note the reference you checked and the fact that unreachability, not destruction, is what you observed. ## Reporting it honestly Sooner or later somebody senior asks whether the material is gone. The answer that survives scrutiny has three parts: what you asked for, what you observed, and what remains outside your view. "It is no longer retrievable through our account, and the supplier's undertaking covers the rest" is defensible. "It is deleted" is a claim about somebody else's systems that you are not placed to make, and an auditor will find the gap faster than you will. ## The part that is easy to get backwards A deletion request is a control, but a **late** one, and late controls on this boundary are weak. What makes it stronger happens earlier: not recording what you did not need, not running that suite on rented infrastructure at all, and agreeing in advance what the supplier keeps. By the time you ask for removal, the exposure has already lasted however long it lasted, and no request shortens that interval retroactively.