Is it OK to let the publishers know the SXG distributor's URL?

[horo-t]

I have stopped working on Signed Exchange Reporting for publishers. w3c/network-error-logging#99 (comment)
This is mainly because it is not clear whether is it OK to let the publisher know the distributor's URL.

If my understanding is correct, we can't know redirecting URLs.
The publisher can only know "aggregator.example/feed" using referrer in this case:

• aggregator.example/feed -> redirect.example/publisher.example/article (returns 301 redirect) -> publisher.example/article

So I think it sounds reasonable not to let the publisher know the SXG distributor's URL.

And also if the publishers can know the distributor's URL, this can be used for user tracking.
Example:
https://TRACKING_ID.distributor.example/publisher.example/article.html.sxg
https://distributor.example/TRACKING_ID/publisher.example/article.html.sxg
I think we should avoid adding new features which can be used for user tracking.

[yoavweiss]

Is the above different from the distributor adding an <a ping="publisher.example/collection_endpoint/TRACKING_ID"> to the SXG link?

[horo-t]

From the user tracking point of view, it is almost same.

[yoavweiss]

Well, since we enable ping attributes, onclick events, redirections and multiple other ways of communicating that information out-of-band, I don't see why we'd want to block this particular one.

[sleevi]

I’m not sure I see how you see those others as substantively similar. They seem very different than what I’ve seen discussed/proposed. For example, `ping` lets you initiate as the outgoing link - but the proposal here does not establish any relationship between the distributor and the link provider. Further, `ping` let’s you notify that a link is being followed, but not the final target of that link. I think it’s unlikely to sway anyone to simply state that there are parallels, because it doesn’t establish the parallels, nor that those current behaviours are desired. A more thorough analysis would be useful, if that is the one to justify this.

[yoavweiss]

Maybe I misunderstood the threat model. Are we worried that publishers will know about tracking IDs without the distributor actively communicating them?

[sleevi]

Fair point. I don't think we've articulated a particular threat model or set of threat models. The question is, as I understood it, trying to articulate the potential risks.

We've got at least four parties in play:

• The Publisher, the provider of the SXG
• The Distributor, the hoster of the SXG resource
• The "Sender", the one who provides the outbound link or initiates loading of SXG (I hesitate to use the term aggregator, as I think it implies a particular type of Sender)
• The User, for whom we are the agent.

One potential risk is, as @horo-t noted, about active collusion between Publisher and Distributor in a way that allows them to exchange information.

• As you note, if the Sender is colluding, then there's no need for the Publisher to have special capabilities / adding special capabilities does not change this, since they can always get the information out-of-band from the Sender.
• However, if the Sender is not colluding / party to the threat, then I think this changes the calclus

Another potential risk is where the User does not wish the Publisher to learn about the Distributor they're using, especially if it may reveal the User's activity with the Sender. This is one of the tensions we noted early on with reporting the Distributor to the Publisher - whether or not it aligns with the user's interests, or whether it allows the Publisher to learn information about the User based on the Distributor.

I'm sure there are other scenarios being overlooked here, but I think it's a fair point that we're likely talking about different things, but which collectively go to identify whether or not it's OK.

[jyasskin]

#424 has an attempt to build an anti-tracking threat model, although I'm sure it's incomplete. In particular, there's only a tracking risk if the same request or JS environment exposes both the Distributor's tracking ID and the Publisher's tracking ID. Simply sending https://DISTRIBUTOR_TRACKING_ID.distributor.example/publisher.example/article.html.sxg to the publisher with no other information isn't enough, since it doesn't include the publisher's tracking ID.

<a ping> is specified to include credentials, so anyone trying to block tracking will need to change that along with any restrictions on reporting the distributor URL to the publisher. I think we should design for uncertainty in how far that effort will go, rather than assuming we need to pre-emptively block all communication via this one channel.

#424 doesn't cover the worry about the Publisher learning things about the User's interaction with the Sender because that's a more immediate risk than anti-tracking (i.e. fixing it doesn't assume a pile of other changes to the web platform). We should also write that more immediate threat model. If someone other than me can volunteer, it'll get done faster.

[sleevi]

Simply sending https://DISTRIBUTOR_TRACKING_ID.distributor.example/publisher.example/article.html.sxg to the publisher with no other information isn't enough, since it doesn't include the publisher's tracking ID.

I'm not sure that analysis is correct. When the SXG is loaded, the Publisher's JS will have access to localState and other storage mechanisms, and thus if the Distributor ID is exposed, can link that with the Publisher ID stored in localStorage and link them, right?

We talked a little about this in #347, in the context of what information about the content the Distributor can infer, as well as what affects the Distributor can have on the Publisher and how it loads its content.

[jyasskin]

@sleevi I think having the DISTRIBUTOR_TRACKING_ID in the publisher's javascript context is "with other information", but I want us to be clear that it's the combination that enables tracking. Maybe browsers that want to prevent identifier correlation can block JS access to the full URL but still send reports to the publisher via credential-less HTTP requests, for example.

[igrigorik]

Re, linking+tracking: we briefly explored this in the Navigation Timing thread, but I'll reiterate it here as well.. We don't necessarily need to expose the full distributor URL to satisfy some of the core use cases from a publisher's perspective: providing the origin, or even just the eTLD+1 if we're concerned about tracking ID being embedded in the subdomain, is likely good enough.

In absence of any signals about the distributor, my fear is that the publishers would simply default to whitelisting a small set of distributors that "they trust" — e.g. trust not to have negative impact on user experience, expect insights from distributors about such page loads in return, etc.