Sourcebuster.js | Hacker News Reader

Sourcebuster.js

sbjs.rocks

89 pointsddispaltro35 comments

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 »

This absolutely doesn’t do that though.

Surely someone will, has and is. As over arcing as the first comment seems, I'd tend to agree.

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.

Just using it for what?

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.

To be clear, this "buster" isn't breaking any browser boundaries. It just uses whatever referer header the page gets from the browser.

Looks like it also parses UTM params but yea, it's not doing anything special or nefarious.

I thought it was a reference to the film The Big Hit.

The ‘busting’ part is just making sure that the original source is available during future visits.

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.

Hmm. I thought browsers stopped giving out referrer years ago ... !?

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.

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.

Which seems to happen here: https://news.ycombinator.com/item?id=19295836 -> http://sbjs.rocks/#/

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”

https://tools.ietf.org/html/rfc7231#section-5.5.2

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.

https://developers.google.com/web/tools/lighthouse/audits/no...

I think that was just cutting off the path from the referrer data.

I clicked the link through feedly but it said my source was direct

Because you went from a https site to a non secure one (http://sbjs.rocks) so the referer header was hidden.

See: https://en.wikipedia.org/wiki/HTTP_referer#Referer_hiding

I did the same but it worked for me (said hn), why didn't it work for the parent but it did for me?

Same for me and I’m curious why (Safari on iPhone)

I believe it's due to HN including this:

  <meta name="referrer" content="origin">

Not in the latest Chrome (Windows). Right-click, open in new window:

> Your source is news.ycombinator.com

Though it is noted in the usage:

> When a visitor come from https web-site to http, a request doesn’t have a referer.

This seems pretty fragile. I visited first from Feedly and then from HN and both times it counted my visit as "direct" (ie no referrer).

Or is this just Firefox kicking ass?

Your source is: direct visit.

No, I clicked a link from 2 different domains (my rss reader and here) - so that means my browser privacy addons work? :)

For a while I had referrers turned off in firefox almost everything still works but it did set off a few anti bot scripts on larger websites.

Anyone know why chrome does not have an option to turn off the Referer header globally?

Because many websites will get upset if you don't have your referrer available to track you /shrug

Reply on news.ycombinator.com