Referrer trimming

[englehardt]

Referrers leak information about a user's browsing activity cross-site. Browser vendors have deployed a variety of mitigations to this vulnerability, ranging from spoofing the referrer to be same-origin to changing the default referrer policy.

Current status (please correct or add to this):

Last update: 2021-04-12

Firefox

• Referrers default to strict-origin-when-cross-origin.
• Trim document.referrer down to eTLD+1 when we observe tokens that can be used to circumvent our cross-site tracking protections.

Chrome

Referrers default to strict-origin-when-cross-origin.

Safari

• All cross-site subresource HTTP referrers are trimmed to the page's origin. This matches strict-origin-when-cross-origin, but sites can not override this setting.
• Trim all cross-site document.referrer to the page's origin.
• Trim document.referrer to eTLD+1 if the referrer has link decoration and the user was navigated from a domain classified by ITP. See ITP 2.3.

Brave

From this doc: Referrer values default to strict-origin-when-cross-origin and can only be tightened via referrer policy, not weakened.

Edge

Referrers default to strict-origin-when-cross-origin.

Future path

At the very least it seems like we can align on defaulting to strict-origin-when-cross-origin (see also: w3c/webappsec-referrer-policy#125). But even this default can still be overwritten by motivated adversaries. This leads to the question of why only change the default, and not permanently trim cross-site referrers with no way to override?

• Do we expect to see a lot of breakage?
• Are there legitimate uses of full cross-site referrers that we want to continue to support?
• Can we somehow prevent abuse but still allow some parties to receive full referrer?

[johnwilander]

Safari

• All cross-site referrers are trimmed to the page's origin. I assume this matches the strict-origin-when-cross-origin, but Apple's blog post is not specific. From what I can tell, sites can not override this setting.

This is correct. However, ITP also detects if link decoration tracking is potentially happening and in that case downgrades document.referrer to eTLD+1.

[englehardt]

Safari

• All cross-site referrers are trimmed to the page's origin. I assume this matches the strict-origin-when-cross-origin, but Apple's blog post is not specific. From what I can tell, sites can not override this setting.

This is correct. However, ITP also detects if link decoration tracking is potentially happening and in that case downgrades document.referrer to eTLD+1.

Thanks! I've updated the original post with a link to https://webkit.org/blog/9521/intelligent-tracking-prevention-2-3/.

[krgovind]

Chrome

• Has experimented with setting the default referrer policy to strict-origin-when-cross-origin. Not sure of the current status here.

Correct, we have experimented with strict-origin-when-cross-origin as the default referrer policy on canary, dev, and beta channels. We did not receive reports of breakage during the experiment period. However, we have currently paused plans to gradually roll out to the stable channel due to the ongoing global pandemic. This is because there is still the possibility that this will break some sites. We are tentatively planning a roll-out in M84, and will keep our status page updated.

• Do we expect to see a lot of breakage?
• Are there legitimate uses of full cross-site referrers that we want to continue to support?
• Can we somehow prevent abuse but still allow some parties to receive full referrer?

We are also interested in the answers to these questions.

[erik-anderson]

The Edge team has been experimenting with defaulting to strict-origin-when-cross-origin in our Dev and Canary channels. We haven't seen a large amount of breakage, but we have found some.

Examples:

1. A payment processing service which reviews the referrer info to decide if it wants to allow a transaction. It is apparently using the path component as well in its current check. The Edge team has notified the payment processor to ask them to fix it ahead of a broader rollout.
2. A Microsoft-owned iframe-embeddable video player that does some configuration of the response based on the referrer info. When it doesn't see a path component, it falls back to an invalid base URL. We've engaged with the site owner to ask them to address it.
3. A site that uses links from a github repo markdown file to a different domain that they own which then turns around and load resources from a https://raw.githubusercontent.com/ URL which has a path component based on the referrer info from the github page.

These issues are often subtle and, in many cases, the site can be changed to adjust to the fact that it's not seeing the same info in the referrer. Of the list above, the first two are legitimate uses of referrer but potentially don't need the same level of detail. For the third, given the developer presumably won't be able to change github's referrer policy, it may be more challenging for them to develop a workaround independently.

[pes10k]

FWIW here, Brave is now shipping a modified referrer policy, similar to the above. The flow-chart is in our wiki, but basically (simplified):

1. never send referrer on cross origin GET navigations
2. otherwise, default to strict-origin-when-cross-origin. Treat strict-origin-when-cross-origin as a floor. We respect site requests for more permissive restrictive policies, but modify more permissive policies to strict-origin-when-cross-origin.

If the brave desc in the issue text could be updated, that'd be appreciated :)

[annevk]

cc @domfarolino

[krgovind]

2. otherwise, default to strict-origin-when-cross-origin. Treat strict-origin-when-cross-origin as a floor. We respect site requests for more permissive policies, but modify more permissive policies to strict-origin-when-cross-origin.

@pes10k - Did you mean to say "We respect site requests for more restrictive policies"?

[pes10k]

@krgovind ah yes, of course, fixed . Thank you for catching that :)

[atjn]

Safari

• All cross-site referrers are trimmed to the page's origin. I assume this matches the strict-origin-when-cross-origin, but Apple's blog post is not specific. From what I can tell, sites can not override this setting.

This is correct. However, ITP also detects if link decoration tracking is potentially happening and in that case downgrades document.referrer to eTLD+1.

@johnwilander but Safari does not trim the referrer header when navigating to an external site. I don't think this description makes that clear. The blog post is not super explicit either, and had me confused for quite a while.

[krgovind]

Safari

• All cross-site referrers are trimmed to the page's origin. I assume this matches the strict-origin-when-cross-origin, but Apple's blog post is not specific. From what I can tell, sites can not override this setting.

This is correct. However, ITP also detects if link decoration tracking is potentially happening and in that case downgrades document.referrer to eTLD+1.

@johnwilander but Safari does not trim the referrer header when navigating to an external site. I don't think this description makes that clear. The blog post is not super explicit either, and had me confused for quite a while.

@johnwilander - Could you clarify what referrers are trimmed by Safari? In addition to the navigations mentioned by the previous post, we found some inconsistencies with subresources.

@maudnals found the following by testing with Safari on desktop and iOS, with ITP enabled:

• Referrers are capped on cross-origin iframes, but not on other cross-origin subresources such as <img> elements.
• The element-level referrerpolicy specification is not honored consistently (even when the policy is more restrictive than the page-level specification). See her post on webkit-dev.

[renebaudisch]

Hi everybody.
I was wondering how this will affect HTML5 creatives as they use link decoration for transporting clickurl and maybe clicktarget as defined in an official IAB doc under point 3.10.

[krgovind]

Hi everybody.
I was wondering how this will affect HTML5 creatives as they use link decoration for transporting clickurl and maybe clicktarget as defined in an official IAB doc under point 3.10.

@renebaudisch Thanks for asking! For those of us not familiar with the document, could you explain what clickurl and clicktarget are? Is clickurl the content page that the ad is embedded on, and clicktarget the advertiser/destination page that the user goes to when they click on the ad?

I'm guessing clickurl is more relevant to this discussion, since it is equivalent to the Referer header that is sent to the embedded ad?

Could you help us understand the use-cases that need the full page URL?

[renebaudisch]

@krgovind sure I will, but it seems I also have to clarify the ecosystem of HTML5 ad distribution.

To deliver ads on publisher websites an adserver is used.
Besides GoogleAdManager aka DFP there are some more like Xandr, SmartAdServer and others.
These adservers are used to deliver ads and when render them also count them in their system
to be able to bill the advertiser.

Counting deliveries therefore is easy, but adservers also count clicks.
An HTML5 creative is computed at some creative agency and shall be used
by the advertiser to provide it to different publisher/marketers and
theirfore surely to different adserver that all uses different counting urls.

Because of this there is a need to an option to pass the delivering adservers counting url to the creative.
The creative itself then can read that information and use it.
The information is meant to be used in an a-tag or window.open,
where clicktag is the href and target the a-tags target like "_blank".

As we use Xandr I can provide you an example url of a hosted creative that uses that feature.

https://vcdn.adnxs.com/p/creative-html/b0/68/91/99/b0689199-f8cc-4cc0-93c9-32ed670ba7bb/index.html?clicktag=https%3A%2F%2Fams1-ib.adnxs.com%2Fclick%3FUTHO30RbjUBRMc7fRFuNQAAAAAAAAOA_UTHO30RbjUBRMc7fRFuNQI1cIjU0qdsJ_ozZZWnK0A0h2HZfAAAAAKd0sACPHgAAjx4AAAIAAACR_QoHPhQUAAAAAABVU0QARVVSAOgD6ANKpgAAAAABAQMCAAAAALMAtyPPMAAAAAA.%2Fbcr%3DAAAAAAAA8D8%3D%2Fcnd%3D%2521VhJKtgiEyO4TEJH7qzgYvqhQIAQoADEAAAAAAACJQDoJQU1TMTo0MzIyQO4lSVXBqKROQOs_UQAAAAAAAAAAWQAAAAAAAAAAYQAAAAAAAAAAaQAAAAAAAAAAcQAAAAAAAAAAeAA.%2Fcca%3DNzgyMyNBTVMxOjQzMjI%3D%2Fbn%3D83983%2Ftest%3D1%2Fclickenc%3Dhttps%3A%2F%2Fwww.partnerdesfussballs.de&target=_blank&frameId=sky_rlSlot_frame1

When the user clicks that ad, the ad will take the clicktag from the decoration and invoke it.
It will open a Xandr page for counting and then redirect to the value after the encoded clickenc param.

Sure this can be changed and adopted to be done by postMessage,
but since the IAB standard is not designed to use postMessage
I'm afraid that this change will break the click counting
for all HTML5 creatives designed that way including those we host.