Your customers' devices are amplifying a stranger's flood; how do you decide whether to close the service?

## Why this is a decision and not a task An engineer at a provider whose customer devices answer a connectionless service on the public internet is in an unusual position: they are being asked to spend money on somebody else's problem. There is no outage. There is no defect. Nobody internally is escalating. The request arrives from a stranger's provider, or from an abuse contact, and the honest internal reaction is that the effort competes with work that fixes problems the organisation actually feels. A principal-level answer accepts that framing rather than moralising past it, and then makes the case on grounds the organisation recognises. ## The costs of acting, stated plainly - **Support volume.** Changing a default across a large fleet of consumer devices generates contacts. On a fleet in the tens of thousands, even a small per-device contact rate is a staffing decision, not a rounding error. - **Breakage.** Some non-zero set of customers uses the thing being closed, often in ways nobody documented. You will discover them by breaking them. - **Fleet heterogeneity.** A managed fleet is rarely one build. A change may need several firmware or configuration paths, each with its own regression risk, and some devices may be old enough that no safe path exists. - **Nothing visible improves.** After the work, your service looks exactly the same to you. There is no metric that gets better on your side, which makes the work hard to defend at the next planning round. ## The costs of not acting, which are the ones that are actually yours - **Capacity you are already donating.** Every reflected answer traverses your network on its way out. You are paying for transit that carries someone else's attack. This is the strongest internal argument because it is a line item, not a principle. - **Your addresses as the apparent source.** The victim's side sees your ranges. That has consequences that arrive later and are hard to reverse: filtering by other networks, listing, and awkward conversations with enterprise customers who ask why your ranges show up in their traffic. - **Upstream and peer pressure.** Transit providers and peers have leverage and use it. Being the network that repeatedly supplies flood capacity invites filtering you did not choose and cannot tune. - **Contractual and regulatory terms.** Acceptable-use clauses run in both directions; many enterprise contracts and, increasingly, jurisdictional rules for consumer equipment impose obligations about equipment shipped and defaults set. - **It compounds.** The answerer population is the attacker's inventory. As long as you are in it, you are permanently useful to whoever is selling flood capacity this year. ## How to sequence it so it is affordable 1. **Measure the donation first.** How many of your devices answer, which request types, at what factor, and what that multiplies to in egress. A number changes the conversation from ethics to arithmetic. 2. **Change the default for new provisioning immediately.** This is nearly free, stops the population growing, and is the part nobody argues with. 3. **Stage the existing fleet.** Cohorts, with a notice period, an explicit opt-out route for customers with a genuine need, and rollback ready. Staging converts an unbounded support spike into a scheduled one. 4. **Prefer scoping to removal where a real use exists.** Answering only the networks that legitimately ask keeps the feature for its users while removing you from the reachable pool. 5. **Set a date for the tail.** Fleets without deadlines keep their tails forever. ## Who actually owns the call Not the engineer. The decision consumes support budget, touches customer-facing behaviour, and may breach an expectation set at sale, so it belongs to whoever owns the acceptable-use policy and the support cost — a product or operations owner who can also say no. The engineer's obligation is to make refusing an informed choice: here is the donated capacity, here is the exposure, here is the staged plan and its cost, and here is what we accept if we decline. Writing that down is itself the deliverable, because the question returns every time the technique comes back into fashion. ## The trap to avoid in the answer Do not answer this as though the technical remedy were the difficulty; it is not, and an interviewer asking this question already knows the remedy. Equally, do not answer it as pure ethics. The convincing answer holds both: the organisation has no self-interested reason to act, so you construct one out of the costs that genuinely land on it, and you sequence the work so that the decision-maker is choosing between two priced options rather than between a virtue and a budget.