Consent and Control
In one line: the agent runs on someone else's device. Before any of the mechanism matters, the user has to have agreed to it — and the way that agreement is expressed constrains the design.
The handshake
Two properties fall out of doing it this way:
- Consent comes first. The header is only sent if the user has already agreed — the client opts in, the service does not opt them in.
- The service configures the agent dynamically. Policy and collection endpoints are supplied in the response rather than hard-coded, so they can change without shipping a new client.
The browser problem
Though a client accesses the service via a browser, a specific browser should know about this feature to appropriately fill in the header information in the HTTP requests.
That is a real constraint: a custom header only works if the client software implements it. You cannot make an arbitrary browser report errors to you.
For organizations that make browsers and provide services — for example, Chromium-based browsers — such features can be incorporated and standardized over time.
| Client type | Can it report? | Why |
|---|---|---|
| Browser you control (or influence) | The feature can be built in and standardized over time | |
| Arbitrary third-party browser | It has no knowledge of your custom header | |
| Client-side application you control | You ship the code — headers are trivial to include |
Another solution is to use a client-side application that the service controls, and then these headers can easily be included over HTTP.
This is why native apps have better observability than websites
If you ship the client, you decide what it reports, when, and to where. If your client is someone else's browser, you are limited to what that browser chooses to support.
It explains a pattern you can observe in the industry: companies with a native app usually have far better visibility into client-side failures than companies that are web-only, and it is not because they are better engineers — they simply own more of the stack.
Worth raising in an interview when asked how you would detect client-side errors: "do we control the client?" changes the answer materially.
Key takeaway
Consent gates the header; the header triggers the service to supply policy and endpoints. Owning the client removes the standardization problem entirely — which is often the deciding factor in how much client-side visibility you can actually get.
Interview signal by level
| Level | What a strong answer sounds like |
|---|---|
| L4 | "We'd ask users to opt in to error reporting." |
| L5 | Describes the mechanism: "a custom HTTP header signals the client supports reporting, and the service responds with the policy and collector endpoint." |
| Staff+ | Raises client ownership and revocability: "whether we control the client changes this completely — a custom header needs browser support, but in our own app it's trivial. And I'd deliver the collector endpoint as data in the response, so we can move collectors during an incident without shipping a client." |
Next: making sure the report can actually get out.