These days, all major browsers have a default Referrer Policy of
...this means if a website doesn't explicitly set a different Referrer Policy, a cross-origin request (or clicking a link) will only disclose the origin (the host), but not the URL that the user came from. While this is great for user privacy, it's terrible for affiliate programs or advertising platforms that have a need to do compliance checking on the URL that clicks originated from. Without knowing the actual URL a user clicked from, it's impossible to do compliance spot checking.
What's even worse is that a malicious publisher can explicitly choose to instruct a user's browsers to not even send the default origin (the host) at their web server level like so:
Publishers can set referrer policies on a per page basis by adding a meta tag to their page:
Additionally, referrer policies can even be set on a per link basis with the
...or with the
This can make network compliance checking nearly impossible (how do you check if a page is compliant without knowing the URL of the page?).
Our search engine is able to assist with compliance checking because the spider starts at a specific URL, then checks which cookies were set (the spider does not "click" any links). If the end result is we have a cookie that should only be set when a user clicks an affiliate link or ad, we know that the site is forcing clicks/cookie stuffing and we can work backwards from there (we don't need to know the referrer because we already know where the spider started).
strict-origin-when-cross-origin
.Mozilla Referrer-Policy spec said:Send the origin, path, and querystring when performing a same-origin request. For cross-origin requests send the origin (only) when the protocol security level stays same (HTTPS→HTTPS). Don't send the Referer header to less secure destinations (HTTPS→HTTP).
Referrer-Policy - HTTP | MDN
The HTTP Referrer-Policy response header controls how much referrer information (sent with the Referer header) should be included with requests. Aside from the HTTP header, you can set this policy in HTML.developer.mozilla.org
...this means if a website doesn't explicitly set a different Referrer Policy, a cross-origin request (or clicking a link) will only disclose the origin (the host), but not the URL that the user came from. While this is great for user privacy, it's terrible for affiliate programs or advertising platforms that have a need to do compliance checking on the URL that clicks originated from. Without knowing the actual URL a user clicked from, it's impossible to do compliance spot checking.
What's even worse is that a malicious publisher can explicitly choose to instruct a user's browsers to not even send the default origin (the host) at their web server level like so:
NGINX:
add_header 'Referrer-Policy' 'no-referrer';
Apache config:
Header always set Referrer-Policy "no-referrer"
Publishers can set referrer policies on a per page basis by adding a meta tag to their page:
HTML:
<meta name="referrer" content="no-referrer" />
Additionally, referrer policies can even be set on a per link basis with the
referrerpolicy
attribute:
HTML:
<a href="http://example.com" referrerpolicy="no-referrer">…</a>
rel
attribute:
HTML:
<a href="http://example.com" rel="noreferrer">…</a>
This can make network compliance checking nearly impossible (how do you check if a page is compliant without knowing the URL of the page?).
Our search engine is able to assist with compliance checking because the spider starts at a specific URL, then checks which cookies were set (the spider does not "click" any links). If the end result is we have a cookie that should only be set when a user clicks an affiliate link or ad, we know that the site is forcing clicks/cookie stuffing and we can work backwards from there (we don't need to know the referrer because we already know where the spider started).