Define link decoration, navigational tracking, and bounce tracking.

[jyasskin]

This also adds a rough introduction.

---

Preview (#intro) (#terminology) | Diff

[pes10k]

I suggest removing this example, or at least describing it differently, as it conflates two things. Changing the numbers could change the content of the destination page and also uniquely describe the user.

[jyasskin]

I think it's an important example for demonstrating what's hard about navigational-tracking mitigations, but I'm happy to describe it differently.

In this case, the numbers do not encode user-identifying information, and modifying them to embed a user ID wouldn't successfully communicate a user ID to anyone (since nobody's listening within google.com/maps to decode the user ID). But it's hard for an automated system inside a browser to prove that, and even hard for humans reading the URL to be confident of it.

Is that the better description? That there's enough information here (10+ digits) to identify a user, but it's used to identify a place instead, and removing enough digits to prevent it from identifying a user would prevent it from serving its purpose of identifying the right place?

[pes10k]

What would you think of calling it an "ambiguous" case, with additional text similar to what you've written above?

[jyasskin]

I'd like to eventually get to a place where it's not ambiguous, but I think that's going to take more CG discussion. I've filed an issue to drive that discussion and referred to it here.

[johannhof]

What about cases like https://example.com/login?returnto=item/12345 or https://example.com/auth/callback?token=1234567? By your definition, would these fall in the "necessary to identify the page" category or be acceptable link decoration? I guess I'm wondering if we should extend this definition to include parameters that "enable user-exposed functionality on the page" or something like that.

[jyasskin]

I feel like those are both (acceptable) link decoration, but the first (https://example.com/login?returnto=item/12345) seems "necessary to identify the page a user wants to navigate to" and so wouldn't be counted as link decoration under my definition. That could indicate a problem with the definition or a problem with my intuition. 🙃 Do you have a sense for which it is?

The second (https://example.com/auth/callback?token=1234567) is necessary for the page to work, but that can be true for any decoration with the cooperation of the target page, so I want to ensure that the definition can include such cases. The token doesn't identify which page the user wants to see, so I think it counts as "extra information" in the current definition, and so is link decoration. That seems correct to me.

I've added these to the examples, but I haven't filed github issues for them yet, pending your thoughts.

[johannhof]

I feel like those are both (acceptable) link decoration, but the first (https://example.com/login?returnto=item/12345) seems "necessary to identify the page a user wants to navigate to" and so wouldn't be counted as link decoration under my definition. That could indicate a problem with the definition or a problem with my intuition. 🙃 Do you have a sense for which it is?

The second (https://example.com/auth/callback?token=1234567) is necessary for the page to work, but that can be true for any decoration with the cooperation of the target page, so I want to ensure that the definition can include such cases. The token doesn't identify which page the user wants to see, so I think it counts as "extra information" in the current definition, and so is link decoration. That seems correct to me.

I've added these to the examples, but I haven't filed github issues for them yet, pending your thoughts.

I agree with you that both are cases of link decoration by your current definition, and it might make sense to keep that definition broader for now.

I wanted to see if we could narrow down the definition of link decoration to the point where any "acceptable" use of parameters is excluded. Thinking about writing browser policy against navigational tracking, it would be great if we had a way to define it without having to carve out cases like auth callback or unsubscribe where it fits the definition but is still somehow acceptable.

But you're right that theoretically any decoration can be constructed to provide some functionality on the site, so I don't have a good solution for this, either. I'm fine with discussing this problem ("can we define acceptable use of navigational tracking?") separately.

[jyasskin]

One thing I'm trying to do with these definitions is to make "link decoration" the sometimes-acceptable thing, and "navigational tracking" be the never-acceptable thing. Your login-related examples do explore some edge cases in even making navigational tracking never-acceptable. I've filed #8 to discuss that further, but I hope to merge these rough definitions before completely figuring that out.