Open Bug 1648621 Opened 4 years ago Updated 2 years ago

Align document.referrer url decoration detection with HTTP Referrer and Referrer Policy

Categories

(Core :: Privacy: Anti-Tracking, enhancement, P3)

enhancement

Tracking

()

Webcompat Priority P3

People

(Reporter: englehardt, Unassigned)

References

Details

In Bug 1568341 we added url decoration protection to document.referrer. The protection is meant to prevent the following attack: tracker.example gets visited as a first party and appends an id in the query parameter of outbound links from their website (e.g., clickid). tracker.example is also embedded in the main context of many websites, say A.example and B.example. Let's say a user navigates from tracker.example to A.example and then to B.example. The top-level urls would look something like:

tracker.example --> A.example?clickid=XYZ --> B.example

If tracker.example has resources embedded in the main context of B.example, then those resources could check document.referrer to retrieve clickid. To protect against this we cut down the referrer to site when we detect that it contains one of the tokens.

It would be great to update this in two ways:

  1. Align the HTTP Referer header sent to B.example upon navigation with the one exposed via document.referrer within the main context of the page. This prevents site B from cooperatively sharing the ID with the tracker.
  2. Migrate from our custom referrer trimming to one of the currently supported referrer policies. Applying non-standard trimming to the referrer allows a tracker on B.example to differentiate between the condition where the referrer was trimmed because of a query parameter (in this case, only Facebook's) and those trimmed by a referrer policy.
Webcompat Priority: --- → ?
Webcompat Priority: ? → P3
You need to log in before you can comment on or make changes to this bug.