Bug 215356

According to a recent Intelligent Tracking Prevention (ITP) blog post[1][2], "ITP now downgrades all cross-site request referrer headers to just the page’s origin. Previously, this was only done for cross-site requests to classified domains." and "All cross-site document.referrers are downgraded to their origin. This matches the already downgraded cross-site referrer request headers."

[1]: https://webkit.org/blog/9661/preventing-tracking-prevention-tracking/
[2]: https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/

However, it seems that within an iframe, when the parent source is cross-site, that same-site navigation is _also_ restricted to origin-only referrals. Is this intentional? It is unclear in the documentation that same-site navigation within an embedded iframe will have origin-only referrals.

Reproduction steps:

1. I have created a demo[3] with the parent daylightpirates.org, and embedded two iframes, one with a same-site origin (daylightpirates.org), and one with cross-site origin (gethttpsforfree.com).
2. For each I put a link that leads to a second page of the iframed origin (e.g. same-site) which then reports the request's Referer header.
3. When the link is clicked in the gethttpsforfree.com iframe, the referrer is limited to origin-only.

[3]: Proof of concept demo: https://daylightpirates.org/iframe-referrerpolicy-test

What should happen:

1. Same-site navigation, even withing an iframe, no matter if the parent is cross-site, should be treated as same-site navigation and full referrer headers should be available.

Why this breaks things:

1. There are many third party widgets, embedded surveys, and other tools that let the users submit a form through the widget.
2. Since third-party cookies are often disabled, the embedded iframe used same-site referrer headers to provide CSRF protection so that iframed forms could still not be submitted cross-site and cross-page (preventing XSS exploits).
3. Restricting to origin-only eliminates the XSS protection and strong CSRF protection from iframe form submission in widgets, surveys, etc.

So, if this was intentional, it would be enormously helpful to understand what specific third-party tracking behavior this prevents, and help with possible alternatives to CSRF within third-party iframed tools.