Consent and Control
Why this matters: 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.
Key takeaway
Use a custom HTTP header to send the appropriate information to collectors. The client fills in the request header if they have already consented, and the service replies with appropriate values for the policy and collection endpoints.
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.
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.