w3c/trace-context

When headers should be propagated in browsers should be made more clear

pes10k opened this issue · 2 comments

pes10k commented

This issue is filed from PING review #103

Currently the spec doesn't clearly specify when the trace headers should be propagated. For example, its not clear if the headers should be propagated in some, all, or none of the following cases:

  1. User loads website, initial site HTML includes JS, and the execution of that JS immediately causes an image to be fetched. Should the headers be included on the image request?
  2. User loads website, initial site HTML includes JS, and the execution of that JS causes an image to be fetched at some later time (say, 30 seconds later after a timer triggers) Should the headers be included on the image request?
  3. User loads website, site HTML includes JS, and in response to some user action at some undefined later point, the JS causes an to be fetched. Should the headers be included on the image request?
  4. User loads website, and then clicks on a link and navigates to another page on the same origin. Should the headers be included on the navigation request?
  5. User loads website, and then clicks on a link and navigates to another page on the same site. Should the headers be included on the navigation request?
  6. User loads website, and then clicks on a link and navigates to another page on a different site. Should the headers be included on the navigation request?

The above isn't intended as a complete list of cases, just as examples that seem ambiguous after several readings of the proposal (and where different decisions would have widely varying privacy impacts).

The spec should clearly define where the boundaries for propagating the tracecontext headers lies, so that its unambiguous when (and when not) browsers should send them. I dont think the full privacy impact of the proposal is clear w/o those details.

kalyanaj commented

Per discussion in the DT working group meeting on 11/22/2022:

At this point, user agents (browsers) are not a target implementation for this specification. We haven't defined the aspects pertaining to browsers and will need to get their inputs and a prototype implementation to even begin specifying it for them.

We will make an editorial update to make it explicit that this specification is not targeted at browsers and that it is undefined - it is out of scope for level 1 and 2 of this spec. The specification supports server-server communication along with client (e.g., Javascript code in browser-server communication).

pes10k commented

We will make an editorial update to make it explicit that this specification is not targeted at browsers

I think that would be a very positive change. At least two places where it'd be good to clarify this are https://github.com/w3c/distributed-tracing-wg/blob/main/EXPLAINER.md#can-a-response-header-returned-to-the-browser-be-used-to-identify-users and in the privacy considerations section where it discusses single page browser applications