Many, if not all website owners, rely on site analytics — at least to a certain extent — to understand where their users come from.
Technically, the act of knowing which websites are referring traffic to your site is achieved via the referrer header. Now, how much information (more on that) is revealed of the website sending that traffic is dependent on what their referrer-policy is, or if none is set, what the browser’s default standard is when it comes to a referrer directive.
There are a handful of acceptable standards for referrer-policy — strict-origin-when-cross-origin being one of them. Website owners can set their own, but as stated, if none are specified, the browser’s default policy kicks in.
So What’s All the Fuss About the Strict-Origin-When-Cross-Origin Referrer-Policy?
As one of the most popular browsers out there, Google’s Chrome browser decided to change its “default” referrer to strict-origin-when-cross-origin. This took effect with the release of version 85. In a short time frame right after, Firefox did the same with their release of version 87.
The argument for tweaking the in-built referrer-policy was to offer more privacy and prevent accidental personal data leaks or extra details in the URL that sends the traffic. Again, keep in mind that websites can define their referrer-policy; this is just the new standard for most browsers now.
What Exactly Does the Strict-Origin-When-Cross-Origin Referrer-Policy Achieves?
An important sidenote: There is a technical and accurate way to say things like same-site, cross-origin, same-origin, etc. But to keep things in layperson and to understand the premise of this post, we would go as follows:
- Cross-origin is not the same website or, put another way, different websites.
- Same-origin is the same website.
The way in which the strict-origin-when-cross-origin policy grants more privacy protection & security is that it strips out all of the associated information of the URL after the website name — when one website sends traffic/users to a different website. So, for example, say the referring URL https://www.example.com/abcd-efg-123 sends traffic to this website, with a strict-origin-when-cross-origin policy in place, inside analytics, all one would see is that example.com sent traffic. NOT the exact URL.
Additionally, analytics or tracking tools can see the full URL path when a URL sends traffic to another URL on the same website. And lastly, the referrer header won’t be sent at all when navigating to non-secure destinations, such as HTTP (notice it’s not HTTPS). For a quick visual primer on this, look at the screenshot below from MDN.
You May Also Want to Check Out:
- What Is DOM and How To “Avoid an Excessive DOM Size”
- Preconnect to Required Origins: What Is rel=”preconnect”
- What Is an Early Hints 103 Status HTTP Code, and How It Helps Load Times
- About Automatic Signed Exchanges (SXGs) and LCP Load Times
- Link Rel Preload and Site Speed: A Preliminary Guide
- What Is x-content-type-options: nosniff Response Header?
- A Prefatory Guide to dns-prefetch
- Basic Differences Between a CSS ID and a CSS Class
- A Basic Introduction to HTML5 Semantic Elements
- Static and Dynamic Content: Delineating the Differences
The Impact of Strict-Origin-When-Cross-Origin Referrer Policy
The world is trying to balance the value of online platforms, technologies, and tracking, while constantly striving for bestowing the most possible privacy, security, and remediation.
The move to adopt strict-origin-when-cross-origin as the default browser referrer-policy pushes the scale towards things being more privacy-friendly and more secure; however, it dwindles the knowledge for marketers on the exactness of the URL that sent traffic. For instance, just knowing that twitter.com sent traffic is less helpful than the precise tweet that sent it.
Almost all commonly recognized browsers have switched their referrer policy to strict-origin-when-cross-origin, so marketers are aware of this event. The question then becomes: how to get around it, or how to get more insights on referrals?
There are circumventing measures to dig out more information on referrals despite the strict-origin-when-cross-origin, such as using UTM parameters. Still, many tend to forget that websites can dictate what they want their referrer policy to be. If all can collectively stipulate their referrer policy deliberately, things can become more trackable.
By the way: the Referrer policy can be defined via HTML also. See “Integration with HTML” from MDN. This post, however, is mainly angled toward the referrer-policy header and its directives — chiefly, the strict-origin-when-cross-origin.
Expert sources