Can you clarify what a user-agent is meant to do on receiving this header, if anything?

This issue came up during Chromium Security & Privacy review of this issue, and we were unclear whether the spec is meant to apply to browsers / user agents or not. The spec seems primarily concerned with "downstream services", but the last example in the explainer shows a web browser echoing a "W3C Trace ID" back to a server, which would make this functionality cookie-equivalent. However, the implications of being cookie-like (life time? origin bound? which permissions apply?) do not seem to be spelled out clearly.

Can you clarify what a user-agent is meant to do on receiving this header, if anything?

For the baggage header, the user-agent will not do anything other than send the header. In version 1, there is no response header and we have no plans to introduce one in future versions at the moment.

This issue came up during Chromium Security & Privacy review of this issue, and we were unclear whether the spec is meant to apply to browsers / user agents or not.

Other than sending the baggage header just like any other header, the user-agent has no responsibilities. It is conceivable that a user-agent would want to add baggage entries, but that is not part of the specification.

The spec seems primarily concerned with "downstream services", but the last example in the explainer shows a web browser echoing a "W3C Trace ID" back to a server, which would make this functionality cookie-equivalent. However, the implications of being cookie-like (life time? origin bound? which permissions apply?) do not seem to be spelled out clearly.

The "W3C Trace ID" is part of the separate but related W3C Trace Context specification which is not a part of the baggage specification which we are asking to be reviewed.

For the baggage header, the user-agent will not do anything other than send the header.

This on its own is concerning security-wise and should be covered in the spec and explainer. For example, what happens on cross-origin requests (e.g. those made in no-cors mode): would the baggage header be included? How should cross-origin redirects be handled?

I think a conceptually simple way to address this could be to guarantee that the baggage header can only be attached on requests that are same-origin to the response that included the baggage information. The spec already mentions that baggage data "does not leak beyond defined trust boundaries" but my guess is that the folks working on this need to put a little more thought into how this would work on the web.

Hi @SergeyKanzhelev - thanks for sending us this. We're still looking for some more info related to security & privacy - specifically the response to the questionnaire... Also can you be a bit more clear on how you "forbid encoding user identifiable data"?

Hi, I didn't see any reference to Structured Headers, can your header format be expressed this way?

Also can you please let us know the multistakeholder status on this? What is the implementation status across other engines/browsers?

@torgo, thank you for drawing this to PING's attention by adding a privacy-tracker label.

As a reminder for the WG, when you're ready for a PING review, please follow the instructions at https://www.w3.org/Guide/documentreview/#how_to_get_horizontal_review

Sorry for the long delay in replies.

For the baggage header, the user-agent will not do anything other than send the header.

This on its own is concerning security-wise and should be covered in the spec and explainer. For example, what happens on cross-origin requests (e.g. those made in no-cors mode): would the baggage header be included? How should cross-origin redirects be handled?

At the moment there are no plans to implement baggage as part of the user-agent. It will typically be done in the JavaScript library executing on the page. This JavaScript library will need to be configured to account for cors correctly.

I think a conceptually simple way to address this could be to guarantee that the baggage header can only be attached on requests that are same-origin to the response that included the baggage information. The spec already mentions that baggage data "does not leak beyond defined trust boundaries" but my guess is that the folks working on this need to put a little more thought into how this would work on the web.

We believe that defining the trust boundaries is not the part of specification, thus no specific details on how to implement cors or configure trust boundaries in the web. Trust boundaries, especially involving many components of a distributed application, are typically very specific to the application and cannot be easily generalized as a specification. This, however, may be a whole new topic for the distributed tracing working group for the future exploration.

We're still looking for some more info related to security & privacy - specifically the response to the questionnaire... Also can you be a bit more clear on how you "forbid encoding user identifiable data"?

I think this is referring to the privacy section of a specification. Specification does not solve the problem of what data will be propagated thru the distributed application components. It solves the problem of standardizing the way data is propagated so centralized solutions may be developed to inspect and secure this propagation. Many tools today allow to propagate this information using custom headers which are vendor specific and not clearly documented. So users of these tools have less control over the data being transmitted. When tools will follow the spec, it will be easier for user to control what is transmitted.

I didn't see any reference to Structured Headers, can your header format be expressed this way?

We had an extensive discussions on whether to use structured headers for this or not. For multiple reasons we decided to proceed with the cookies-like format and not support strongly typed values. I cannot find the rationale clearly documented, I will take this as an action item

Hi @SergeyKanzhelev. We are looking at this in our W3CTAG breakout, and a couple of questions have come up.

1. Who is the user for this? What need of theirs is it meeting? It would help us a lot of if you could put those points in your explainer.

2. We are concerned about the privacy/security implications of opening up a metadata channel that the user can't control. Have you thought through any attack scenarios? And if so, what are your thoughts on how to make them less likely to happen?

The security and privacy sections of your spec talk about the responsibilities of application owners and systems. Does your approach let users protect themselves too? Or might it be easier to track them with your proposal?

We'd be grateful for your thoughts on those. Thanks!

At the moment there are no plans to implement baggage as part of the user-agent. It will typically be done in the JavaScript library executing on the page. This JavaScript library will need to be configured to account for cors correctly.

I'm having a bit of difficulty reconciling this with the description in the explainer: "We also propose a response header which can be used to report a trace ID back to the caller to ... correlate the initial page load of a browser and all subsequent requests to a server side trace" and "The browser uses this information to provide a trace ID for all subsequent requests within this one load cycle".

From your explanation above I understand that the user's browser would simply ignore the header and the responsibility of propagating the baggage value would be on the client-side JS executing on a given page. This brings up a few thoughts:

1. How will scripts executing on a page learn the value of the baggage header? Are you also proposing a JS API to get this data?
2. This means that the baggage will -- in practice -- be propagated only for a subset of requests made by a given page, and will exclude no-cors resource loads. I think this means that the value will only be propagated for programmatic loads using the fetch() API if the caller makes sure to add the baggage header.
3. Pages with some third-party resources that don't opt in via Access-Control-Allow-Headers may have a hard time enabling this. My guess is that most pages are in this situation.

@hadleybeeman thank you for your questions and sorry for delay.

1. Who is the user for this? What need of theirs is it meeting? It would help us a lot of if you could put those points in your explainer.

The user for Baggage is an application developers or authors or third party tools installed to these applications. Baggage is a mechanism that enables specific scenarios of information propagation across components of a distributed system. By standardizing it we are simplifying implementation of these scenarios as well as giving application developers some mechanisms or verification on what is shared between systems. At present, custom headers are often used which makes is harder to audit universally.

2. We are concerned about the privacy/security implications of opening up a metadata channel that the user can't control. Have you thought through any attack scenarios? And if so, what are your thoughts on how to make them less likely to happen?

At present those scenarios are often implemented using custom headers, which makes it harder to control. We expect the most implementation will want to switch to unified approach that will offer a better compatibility across vendors and components. And this will make audit and control of what metadata is shared easier.

The security and privacy sections of your spec talk about the responsibilities of application owners and systems. Does your approach let users protect themselves too? Or might it be easier to track them with your proposal?

End users must rely on application authors for protection. Similar how it happens with any custom headers application author may decide to send today, there is no mechanism to control what will be sent via the baggage header. In future if baggage will be widely used on browsers in JS libraries, browsers may consider restricting where baggage headers will be send.

1. How will scripts executing on a page learn the value of the baggage header? Are you also proposing a JS API to get this data?

Today we only support ajax calls inside a single page load. We do not propose a JS API for the actual page loads at this point. We were considering using Server-Timing header to return some correlation data from the server back to the page, but this is not something we are actively working on.

2. This means that the baggage will -- in practice -- be propagated only for a subset of requests made by a given page, and will exclude no-cors resource loads. I think this means that the value will only be propagated for programmatic loads using the fetch() API if the caller makes sure to add the baggage header.

Yes, implementations will be JS Library-specific.

3. Pages with some third-party resources that don't opt in via Access-Control-Allow-Headers may have a hard time enabling this. My guess is that most pages are in this situation.

Yes, this standard makes situation a little bit better as it defines a unified header when in the past custom headers were typically used. It will be easier to ask Access-Control-Allow-Headers to enable baggage than any vendor-specific headers. And we may provide some helper methods for this. We had conversation about including Distributed Tracing Working Group headers to the default set of allowed headers. But I don't think this will be happening short term

Hello TAG review team. This is just a friendly ping to see what the current status of this review is. Please let me know if you're waiting on anything from us (Distributed Tracing WG) at this point.

@dyladan thanks for the ping, we’ll get back to this next week

I see that you currently support key/value pairs and properties. Do you expect this to cover all your use-cases?

As far as I could see this looks like a subset of structured headers - is that the case? I think this should either use structured headers or a strict subset

We're also missing info on multi-stakeholder support. I can't find this on Chrome Status. @dyladan @SergeyKanzhelev can you comment?

Thanks for the thorough reply to my earlier questions, @SergeyKanzhelev! They were helpful. For what it's worth though, I still didn't really get the use case you're trying to support until I looked at the working group's charter. You might want to take a bit of the scope section from the charter to set the scene in your explainer.

Also, we've been talking about the name of the feature. Baggage is definitely a US/UK idiom, and may not be intuitive to anyone who hasn't been focusing on distributed tracing. Might it be useful to use something like Trace ID additional header? (Maybe best to do some user research on this — the important thing is that it's immediately understandable to as many of your users as possible.)

And finally, in the privacy vein, we talked about whether it would be good for this to behave differently in private/incognito browsing mode. It struck us that there is nothing to stop the application provider from sending headers derived from information tied to the machine or usual user (their IP address, their user ID, etc.). We wondered if it might make sense to ask user agents to ignore the trace ID altogether in when in private/incognito mode, so that the user's experience isn't tied to the experience that same user (or whoever they share a browser with) gets when not in private/incognito mode. What are your thoughts on this?

Also, is there a reason why, in the ABNF, you refer to rfc2616 and rfc7230? Why not using the same source (ideally the latest) for all the definitions?

In the Privacy & Security Section it states "As such, the baggage header can contain user-identifiable data. Systems MUST ensure that the baggage header does not leak beyond defined trust boundaries and they MUST ensure that the channel that is used to transport potentially user-identifiable data is secured." But the term "trust boundaries" is not itself defined in the document. Also maybe you should refernece secure contexts directly instead of just saying "secured" to be clear about what you mean by secured here?

We're also still waiting for a response on the issues raised by Hadley about incognito mode and naming.

Regarding this comment: https://github.com/w3ctag/design-reviews/issues/650#issuecomment-969128971: we don't require any browser support for this specification as this is implemented in JavaScript (e.g. OpenTelemetry JS SDKs). OpenTelemetry SDKs across multiple languages implement Baggage specification.

Hello TAG Review Team: Thanks for your review comments above, I want to consolidate the list of questions discussed above and the current status:

1. Naming: https://github.com/w3c/baggage/issues/83: Response tracked as part of this issue.
2. Private Browsing mode: https://github.com/w3c/baggage/issues/84: Response tracked as part of this issue.
3. Multi-stakeholder support: Covered as part of this response at https://github.com/w3ctag/design-reviews/issues/650#issuecomment-1040777563
4. Structured Headers: Covered as part of this response at https://github.com/w3ctag/design-reviews/issues/650#issuecomment-909543300
5. Reference to the right RFC (https://github.com/w3ctag/design-reviews/issues/650#issuecomment-969290866): We have addressed this feedback as part of https://github.com/w3c/baggage/pull/79.

Please let us know your thoughts on the above and if you have any additional comments/ questions.

Hi @kalyanaj - thank you so much for preparing that summary addressing all the issues that were raised. We're just coming back to this today at our face-to-face meeting. We're happy with the responses you've provided. We'd still like to see some additional justification re: the structured headers topic (documented in your spec). However we're broadly happy with this.