1648166 - document.referrer of iframe is different if top level URL contains fbclid

Status: RESOLVED WONTFIX

(Core :: Privacy: Anti-Tracking, defect)

Description

[elliott]

Attachment: screenshot of console showing error while attempting to postMessage parent

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:77.0) Gecko/20100101 Firefox/77.0

Steps to reproduce:

In a JavaScript file within an iframe, console.log the document.referrer from within the iframe

Actual results:

logging document.referrer returns a different string if fbclid is included in the top level URL

Expected results:

document.referrer should represent the document referrer regardles of the url

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[Mirko Brodesser (:mbrodesser-Igalia)]

Attachment: outer_frame.html

Comment 3

[Mirko Brodesser (:mbrodesser-Igalia)]

Attachment: inner_frame.html

Comment 4

[Mirko Brodesser (:mbrodesser-Igalia)]

Reproducible with the attached pages, requires running a web server (e.g. python -m SimpleHTTPServer).

Comment 5

[Mirko Brodesser (:mbrodesser-Igalia)]

The problem isn't specific to "fbclid", it also doesn't work for other key-value pairs.

Chrome doesn't drop the key-value pairs.

Comment 6

[Anne (:annevk)]

Can reproduce by navigating to https://software.hixie.ch/utilities/js/live-dom-viewer/?fbclid and then pasting <iframe srcdoc="<script>alert(document.referrer)</script>"> into the text field containing fbclid. (It alerts the site even, not the origin. Doesn't happen for other strings, such as fbcli.)

Comment 7

[Mirko Brodesser (:mbrodesser-Igalia)]

It seems Johann will be away for a longer time. ni?'ing Gary additionally.

Comment 8

[Anne (:annevk)]

It seems this was intentional per bug 1568341, though it's rather surprising as it's not standardized and returning the site (instead of origin) isn't part of Referrer Policy.

It also doesn't seem sufficient as a mitigation as the Referer header still includes the full URL.

Comment 9

[Steven Englehardt [:englehardt]]

Thanks for the report. As Anne said this is intentional as part of our tracking protection. I filed Bug 1648622 to capture two possible enhancements to the protection. In particular, switching our trimming from eTLD+1 to origin seems like it would fix the issues Comment 0 is running into and wouldn't relax the protections.