Piggy backing off of this post. I'd like to take the opportunity to remind people of the security hazards of referrer addresses and keeping sensitive information out of your query parameters. If you have third party images or third party links on your site, sensitive user information is leaked through the referrer address if the data is in your GET parameters. If you have an OAuth scheme, double check to make sure you don't have external links or third party images in your login/redirect/authentication process. Sensitive information should ALWAYS be sent via POST request and your referer policy should be set appropriately. Read more here: https://developer.mozilla.org/en-US/docs/Web/Security/Refere...
I just love it when I enter a store and someone who followed me go tell the seller all the shops I visited, what I shopped, for how long, what I searched and what I read
We have to stop this non-sense, and stop calling this « innovation »
No, this absolutely does form part of the marketing loop.
Profiling visitors based on their referrer to —quoting TFA— "show relevant content" is exactly this sort of creepy nonsense that leads to you (store owner) knowing where I do my research and being able to infer more about me than I've explicitly told you.
To me just using referral data is not creepy at all. All this script does is keep track of where people are coming from. It's not using questionable tricks, it's not building profiles and it's not combining or using other data. All it know is you're an anonymous visitor that came through source X.
We're arguing slightly different things. Sure, guns don't kill people. Referrer as an aggregate statistic, on its own is pretty harmless. This script doesn't even phone home on its own.
But it's what you do with that data. How you collect it. What you collect with it. How you aggregate, or infer from it. Modern sales funnelling and marketing is all sold around targeting users. That's what this all feeds into.
Referrer data has a lot of non-shady uses and it is really useful. That's why we have GDPR, so we can use referrer data as intended by preventing people from combining data.
Also, I don't think you can equate this with guns.
Try equating it with metal. Yes, you can make it into a gun, but you need to have lot of different things in place before you can use it to do harm.
Referrer data is completely anonymous. If you want to combine it into a profile, you need layers and layers of complexity and other data before you have something you can use it to target users based on their interests. With GDPR, this is illegal without consent anyway so I think you're overreacting.
I don't get the point of this in a client script. What does it do that can't be done server side with the http headers? Maybe it can be useful inside SPAs but this sort of info should be immutable and read only which is next to impossible on front facing apps.
You can still emulate the Referer header in order to trick the server side. It's easier to do this on the client side in order to avoid complexity on server-side because the servers need to be aware of all the browsers used by the client.
Makes no sense. What complexity are you talking about? You get that info on the client to create another request to the server in order to send it over?
Unless you're only tracking the pageview events, it's not an additional request. Most of the analytics SDKs use either XHR or Pixel tracking. It's often easier to build up a separate analytics pipeline rather than using the backend server logs.
I've been looking at the Chameleon extension recently. Anyone have any experience with it? Apparently it spoofs a ton of stuff to make tracking harder.
No, however, the idea is that if the link is target _blank then you are supposed to add a rel attribute, commonly given as rel="noopener noreferrer" in most articles you read. Common content management systems such as Wordpress and Drupal do this for you.
Nobody has yet died due to some programmer carelessly not having 'noreferrer' set in the 'rel' attribute of a link that opens in another tab but, if you want to get 100% on Google's Lighthouse audit tool, then it really does matter.
The Google article is worth the read as it makes it clear that the oft-cited rel="noopener noreferrer" is wrong. The thing is that 'noreferrer' is a superset of 'noopener' so you only actually need rel="noreferrer" without the 'noopener' bit.
The 'opener' said no to is 'window.opener' in Javascript. This probably was brilliant in the days of frames and has lurked in the specs ever since.
In particular:
“A user agent must not send a referrer header field in an unsecured HTTP request if the referring page was received with a secure protocol”
There are options to control the referrer in various places, but it is still included by default. The only situation I can think of where its blocked by default is when navigating from https to http.
I've seen social networks use noreferrer on their links, but they're still a browser feature nonetheless. Referrers are also always sent for image tags and remote resources.
