An outsider-set field makes your assistant's answers carry a fetch-triggering reference — who owns that finding?
answer
- three candidate owners, not one
- cost asymmetry decides, not correctness
- a negative over an unenumerable population
- scoped to surfaces, versions and a date
- an assurance with no re-test cadence expires
basics
~20 sThree teams could own it: whoever accepts the field, whoever emits the answer, and whoever ships the renderer that fetches. The call is made on cost asymmetry, and it is a recorded decision rather than a technical fact.
solid answer
~50 sSay what you can defend, and name who is deciding. The pipeline puts outsider-controlled text into an answer; some downstream renderer performs a fetch while displaying it. Three teams could own that: whoever accepts the field, whoever emits the answer, and whoever ships the surface. The call is usually made on cost asymmetry — one change where the answer is produced, against enumerating and constraining N surfaces, some outside the company — and that is a decision to record, not a fact to assert. On assurance, only a scoped negative is honest: no request observed in the surfaces tested, at those versions, on that date. A claim about a population you cannot enumerate has no basis, and it expires — a client update can create the channel next month, so the claim needs a re-test cadence somebody funds or it decays into folklore.
go deeper
Recall that the software performing the fetch may not be the software your team ships, so who owns the problem is not obvious from the technical facts alone.
Explain why an assurance about render-time behaviour has to be scoped to specific surfaces and versions, and why a client update can change the answer.
Show how you would collect the evidence that makes the ownership conversation possible: per-surface fixture results, a measured placement rate, and an explicit list of untested surfaces.
Own the decision itself — state that cost asymmetry rather than correctness is allocating the finding, scope and date-stamp any assurance, fund its re-test, and make the disclosure call to surface owners deliberately.
## The shape of the problem A data-analysis assistant answers over database rows. One free-text column is filled in by outsiders through a public form. The assistant quotes it. The answers are consumed in places the assistant's team does not ship and has never inventoried: a dashboard tile, a mobile client, a chat surface that expands references into previews, an emailed digest. A finding says that in at least one of those places, displaying an answer performed a request to a host the outsider controls. Every technical fact in that paragraph is settled. What is unsettled is organisational, and that is the interview question. ## Three candidate owners, and why each has a case | Candidate owner | Their case | Their objection | | --- | --- | --- | | The team that accepts the field | untrusted input entered here and was never marked as such | they accept text from the public by design; that is the product | | The team that emits the answer | their pipeline moved outsider text into content consumed by unknown programs | they emit text, not requests; they ship no renderer | | The teams that ship the surfaces | their software issued the network request | they render content, and they did not choose to display this | None of these is obviously right, which is why it is a judgment. What usually decides it is not correctness but **cost asymmetry**: one change in one pipeline owned by one team, against enumerating every rendering surface, negotiating with the ones outside the company, and tracking their release cadences forever. When one side of the ledger is a week and the other is unbounded and shared, the finding lands on the cheap side. That is a legitimate way to decide. It is not a legitimate thing to *disguise* as a technical conclusion, and a lead who writes it down as a decision — with the reasoning and the named owner — is doing the job. ## What may honestly be claimed afterwards Only a scoped negative. *In the four surfaces we tested, at those versions, on that date, displaying an answer produced no request.* Everything wider is unfounded: - You cannot claim a negative over a population you cannot enumerate. If nobody knows how many places consume these answers, no statement about all of them has evidence behind it. - The claim has an expiry. Rendering behaviour is a property of client releases you do not control; a surface that resolved nothing last quarter may expand previews after an update. An assurance without a re-test cadence is a snapshot being read as a guarantee. - The claim is per-surface, not per-product. One tested client says nothing about the next. The organisational consequence is that somebody has to fund the re-test, or the claim should not be made at all. A lead who accepts the assurance without funding its maintenance has bought folklore. ## The disclosure call The finding also says something about somebody else's renderer — possibly a vendor's. Telling them has costs: they may not act, the detail is useful to people other than them, and the conversation puts your own pipeline's handling of untrusted text on the table. Not telling them leaves a property of their product unknown to its owner. There is no universally right answer; what is expected is that the call is made deliberately, by someone who can own it, rather than by default through silence. ## The failure modes to name - **Declaring the surfaces out of scope.** Sometimes correct, but only when recorded as an accepted risk with a named owner and a review date. *Not our bug* with no record is how a finding disappears without anyone deciding anything. - **Severity from a single observation.** One logged request does not establish reach, and a severity that outruns its evidence gets the next report discounted. - **Booking a byte limit or a click assumption as a mitigation.** Both are arguments about attacker convenience, not about whether the channel exists. - **Claiming coverage from one tested client.** The most common way an assurance becomes false without anyone lying. ## What good sounds like in the room Name the three candidate owners. State the cost asymmetry openly and say that it, not correctness, is deciding. Scope the assurance to surfaces, versions and a date. Attach a re-test cadence and say who pays for it. Make the disclosure call explicitly. Then let the owner accept or refuse the residual risk in writing — because the one outcome you cannot defend is a finding that was closed by nobody in particular.
- The surface owners say they render what they are given and this is not their bug. What do you say?That both statements can be true and the risk still exists. Their software performs the request, so the capability is theirs to describe; the untrusted text is ours to account for. I would ask them for one factual thing — what their client resolves while drawing, at which versions — because that is knowledge only they hold, and then decide ownership on cost, in writing, with their answer recorded.
- Leadership wants a statement that customer data cannot leak this way. What can you sign?A scoped one: in the surfaces we tested, at those versions, on that date, no request was observed, and the placement rate for untrusted text reaching an answer was measured at X. I cannot sign a statement about surfaces nobody has enumerated, and I would say that the statement expires with the next client release unless somebody funds a re-test cadence.
- Is it defensible to declare the unowned surfaces out of scope?Yes, if it is a recorded acceptance rather than a dismissal. That means a named owner, the reasoning, the residual risk stated in plain terms, and a review date. What is not defensible is closing the finding as not-our-bug with no record, because then nobody has actually decided anything and the next person to find it starts from zero.
saying these in an interview costs you the question
- Asserts an ownership call as a technical conclusion
- Claims a negative over surfaces nobody has enumerated
- Treats a point-in-time test result as a standing guarantee
- Closes the finding as not our bug with no record
- Assigns severity from one observation to the whole user base